cto/sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md
2026-05-31 18:15:20 -04:00

135 lines
5.4 KiB
Markdown

---
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.