hermes/cto
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Create CTO planning workspace

Browse Source
This commit is contained in:
Svrnty 2026-05-31 18:15:20 -04:00
commit 3f0821747e
7 changed files with 322 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.gitignore vendored Normal file
View File

@ -0,0 +1,5 @@
__pycache__/
*.pyc
.pytest_cache/
.DS_Store

40
AGENTS.md Normal file
View File

@ -0,0 +1,40 @@
# Cortex OS CTO Workspace Agent Rules
This workspace is a child-local planning workspace for the Cortex OS CTO product line.
It is not Cortex OS Core authority. It is not a Cortex OS Instance. It is not a Runtime. It is not a Host Runtime.
## Authority Order
1. `/home/svrnty/workspaces/cortex-os/core` active SOT.
2. `/home/svrnty/workspaces/cortex-os/core/AGENTS.md`.
3. This file.
4. `README.md`, `WORKBOARD.yaml`, local `sot/`, and local tools.
5. Chat/session memory.
## Workspace Classification
Use this workspace for child-local CTO planning, adapter design, transportability briefs, and validation scaffolds.
Do not claim Core authority from this workspace. Promotion into Core requires a governed Core route.
## Editing Rule
Before editing, classify the work and keep it inside this workspace unless Core explicitly routes promotion.
After editing, run:
```bash
python3 tools/validate_cto_child.py
```
For governance text, follow Core caveman prose discipline.
## Protected Boundaries
- Do not mutate `../core/` from this workspace.
- Do not mutate vendor source.
- Do not mutate external developer repositories.
- Do not create Runtime behavior without a Core-approved route.
- Do not treat Case, Hermes, Pi, Codex, or any execution backend as Cortex OS authority.

43
README.md Normal file
View File

@ -0,0 +1,43 @@
# Cortex OS CTO
This workspace holds child-local planning for a Cortex OS CTO product surface.
The current thesis:
```text
Cortex governs.
Hermes controls.
CTO routes.
Case executes.
Harness proves.
Target repo stays owned.
Evidence records.
Core promotes only through SOT route.
```
## Status
This workspace is draft and child-local. It is not registered Core authority.
## Layout
```text
.
|-- AGENTS.md
|-- README.md
|-- WORKBOARD.yaml
|-- sot/
| |-- 00-START/
| | `-- CTO-WORKSPACE-INTENT.md
| `-- 03-PROTOCOLS/
| `-- CTO-CASE-BACKEND-BRIEF.md
`-- tools/
`-- validate_cto_child.py
```
## Local Validation
```bash
python3 tools/validate_cto_child.py
```

6
WORKBOARD.yaml Normal file
View File

@ -0,0 +1,6 @@
items:
- id: CTO-WORK-001
title: CTO Case Backend Architecture Brief
status: candidate
source: sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md
owner: jp

31
sot/00-START/CTO-WORKSPACE-INTENT.md Normal file
View File

@ -0,0 +1,31 @@
---
name: cto-workspace-intent
tier: local
status: draft
owner: jp
source: conversation
created: 2026-05-31
last_reviewed: 2026-05-31
lifecycle_classification: planning
core_promotion_status: not-promoted
description: Child-local workspace intent for Cortex OS CTO planning.
---
# CTO Workspace Intent
This workspace holds planning artifacts for a Cortex OS CTO product surface.
It is child-local. It does not create Core SOT authority.
## Purpose
- Define the CTO product boundary.
- Design the Hermes CTO control layer.
- Evaluate Case as the default code-change execution backend.
- Preserve Cortex OS authority separation.
- Produce route-ready briefs for later Core promotion.
## Non-Authority Notice
Artifacts here are planning outputs. Core promotion requires a governed Core route, Core validator coverage, and Evidence.

134
sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md Normal file
View File

@ -0,0 +1,134 @@
---
name: cto-case-backend-brief
tier: local
status: draft
owner: jp
source: conversation
created: 2026-05-31
last_reviewed: 2026-05-31
lifecycle_classification: planning
core_promotion_status: not-promoted
description: Child-local brief for making Case the default CTO execution backend while Cortex OS keeps authority.
---
# CTO Case Backend Brief
## Thesis
Case should be the default real-repo execution backend for the Cortex OS CTO product surface.
Cortex OS should govern Case. Cortex OS should not be built on Case.
## Core Position
```text
Cortex governs.
Hermes controls.
CTO routes.
Case executes.
Harness proves.
Target repo stays owned.
Evidence records.
Core promotes only through SOT route.
```
## Authority Model
| Block | Governs | Must not govern |
| --- | --- | --- |
| Cortex OS Core | SOT authority, routing, lifecycle, terminology, validators, evidence rules, promotion rules | Agent implementation, vendor internals, PR implementation |
| Hermes WebUI | Visual control, sessions, approvals, event replay, operator status | Core SOT authority, backend execution semantics |
| Hermes CTO Profile | Technical role, task contract, risk interpretation, backend selection, JP escalation | Core promotion, deploy authority, vendor source |
| CTO Harness | Adapter compliance, event validation, artifact validation, backend conformance | Final authority, product readiness claim |
| Case | Code-change pipeline, PR lifecycle, verifier/reviewer gates, retrospective learning | Cortex authority, JP approval, Core promotion |
| Target Repository | Owned source and local project contract | Cortex authority transfer, hidden mutation |
## Target Architecture
```text
+--------------------------------------------------------------------------------+
| Cortex OS Core |
| SOT authority: Standards, Protocols, Registries, Validators, Evidence rules |
+---------------------------------------+----------------------------------------+
|
| emits governed Work Packet
v
+--------------------------------------------------------------------------------+
| Cortex Work Packet |
| route, authority basis, repo scope, allowed paths, forbidden actions, risk, |
| success criteria, evidence expectations, approval policy |
+--------------------------+-----------------------------------------------------+
|
v
+--------------------------------------------------------------------------------+
| Hermes CTO Profile |
| task contract, backend selection, risk gates, JP escalation, status |
+--------------------------+-----------------------------+--------------------+
| |
| invokes adapter | emits events
v v
+------------------------------------------------+ +----------------------------+
| CTO Harness | | Hermes WebUI |
| validates backend conformance | | control and replay surface |
+--------------------+---------------------------+ +----------------------------+
|
v
+--------------------------------------------------------------------------------+
| Case Backend |
| scout -> implementer -> verifier -> reviewer -> closer -> retrospective |
+--------------------------+-----------------------------------------------------+
|
v
+--------------------------------------------------------------------------------+
| Target Repository |
| bounded mutation through PR, diff, logs, tests, review, and evidence |
+--------------------------------------------------------------------------------+
```
## Execution Rule
Case is the CTO execution backend, not the CTO authority layer.
The first integration target should be:
```text
cto/harness/runner/case-engine.sh
```
The adapter must map:
```text
Cortex Work Packet -> Case task file
Case events/logs -> CTO event envelope
Case result -> Cortex evidence packet
```
## Preserve From Existing CTO Work
- CTO event vocabulary.
- Approval gates.
- Task contract shape.
- Runtime artifact directory discipline.
- Allowed-path validation.
- Health, status, and WebUI summary commands.
- Fake deterministic cases.
- Codex and Pi comparative lanes.
## Decision Candidate
Adopt Case as the default real-repo code-change backend for CTO.
Keep the existing CTO harness as the adapter and compliance test surface.
## Open Questions
- Which Case task fields map directly to Cortex Work Packet fields?
- Which Case events need normalization into CTO event envelopes?
- Where should Case runtime artifacts be stored for child-local evidence?
- Which approval gates stay in Hermes WebUI versus Case?
- What focused validator proves Case adapter compliance without claiming Core promotion?
## Non-Authority Notice
This brief is child-local planning. It does not promote Case, Hermes CTO, or the CTO harness into Core authority.

63
tools/validate_cto_child.py Normal file
View File

@ -0,0 +1,63 @@
#!/usr/bin/env python3
"""Validate the child-local Cortex OS CTO workspace."""
from __future__ import annotations
import json
from pathlib import Path
ROOT = Path(__file__).resolve().parents[1]
REQUIRED_FILES = [
"AGENTS.md",
"README.md",
"WORKBOARD.yaml",
"sot/00-START/CTO-WORKSPACE-INTENT.md",
"sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md",
]
REQUIRED_BRIEF_PHRASES = [
"Cortex governs.",
"Hermes controls.",
"Case executes.",
"Harness proves.",
"Core promotes only through SOT route.",
"Case is the CTO execution backend, not the CTO authority layer.",
"This brief is child-local planning.",
]
def main() -> int:
checked: list[str] = []
errors: list[str] = []
for rel in REQUIRED_FILES:
path = ROOT / rel
checked.append(rel)
if not path.is_file():
errors.append(f"missing_required_file:{rel}")
brief = ROOT / "sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md"
if brief.is_file():
text = brief.read_text(encoding="utf-8")
for phrase in REQUIRED_BRIEF_PHRASES:
checked.append(f"brief_phrase:{phrase}")
if phrase not in text:
errors.append(f"missing_brief_phrase:{phrase}")
if "core_promotion_status: not-promoted" not in text:
errors.append("brief_missing_not_promoted_frontmatter")
payload = {
"ok": not errors,
"validator": "cto-child-v1",
"checked": checked,
"errors": errors,
"warnings": [],
}
print(json.dumps(payload, indent=2, sort_keys=True))
return 0 if not errors else 1
if __name__ == "__main__":
raise SystemExit(main())