Create CTO planning workspace
This commit is contained in:
Svrnty
@@ -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.
|
||||
|
||||
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user