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

Add first real governed workflow route

Browse Source
This commit is contained in:
Svrnty
2026-06-01 06:30:28 -04:00
parent 0c30d27b06
commit 451f626fb6
6 changed files with 246 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.sot/03-PROTOCOLS/CTO-FIRST-REAL-GOVERNED-WORKFLOW-ISSUES.md
+72
View File
@@ -0,0 +1,72 @@
---
name: cto-first-real-governed-workflow-issues
tier: local
status: draft
owner: jp
source: .sot/03-PROTOCOLS/CTO-FIRST-REAL-GOVERNED-WORKFLOW-PRD.md
created: 2026-06-01
last_reviewed: 2026-06-01
lifecycle_classification: planning
core_promotion_status: not-promoted
description: Child-local issue sequence for the first real governed CTO workflow delegation.
---
# CTO First Real Governed Workflow Issues
Local planning SOT only. Not a Core Protocol. Not active Core authority.
## Issue Sequence
### CTO-WORK-048 - First Real Governed Workflow PRD
Type: AFK
Status: validated.
Blocked by: CTO-WORK-047
What to build: Define the gated route for one real governed coding workflow without executing it or changing backend default status.
Acceptance criteria:
- [x] PRD requires precise brief or issue.
- [x] PRD requires current Target Repository admission.
- [x] PRD requires JP/Hermes approval before mutation.
- [x] PRD requires Case execution through CTO Harness only.
- [x] PRD requires Harness Evidence Interface artifacts for acceptance.
- [x] PRD requires Hermes Control Surface replay paths after execution.
- [x] PRD keeps runtime default activation false.
- [x] Local CTO validator checks the PRD.
Validator: `python3 tools/validate_cto_child.py`
### CTO-WORK-049 - First Real Governed Workflow Execution
Type: HITL
Status: candidate.
Blocked by: CTO-WORK-048
What to build: Execute one bounded real coding task through CTO, Hermes approval, CTO Harness, and Case, then record evidence without activating Case as default.
Acceptance criteria:
- [ ] A concrete owned low-risk Target Repository is selected.
- [ ] Target Repository admission is current and references no secrets.
- [ ] A precise task contract exists with allowed paths, forbidden actions, success criteria, validation command, and rollback expectation.
- [ ] JP/Hermes approval is recorded before mutation.
- [ ] Case runs only through CTO Harness.
- [ ] Runtime default activation remains false.
- [ ] Harness Evidence Interface artifacts exist and pass focused validation.
- [ ] Hermes Control Surface exposes replay paths for the run.
- [ ] Operator acceptance or rejection is recorded after verification.
- [ ] Aggregate Harness health passes once before merge and once after merge.
Validator: future focused real-workflow Harness validator, then `harness/evals/health.sh --json`.
Human gate: JP must approve the concrete Target Repository and task contract before execution.
## Granularity Check
This is intentionally two slices. `CTO-WORK-048` is planning and route definition. `CTO-WORK-049` is the first real execution and remains candidate because it needs JP approval and runtime target selection.
.sot/03-PROTOCOLS/CTO-FIRST-REAL-GOVERNED-WORKFLOW-PRD.md
+106
View File
@@ -0,0 +1,106 @@
---
name: cto-first-real-governed-workflow-prd
tier: local
status: validated
owner: jp
source: WORKBOARD.yaml next ROI after CTO-WORK-047
created: 2026-06-01
last_reviewed: 2026-06-01
lifecycle_classification: planning
core_promotion_status: not-promoted
description: Child-local PRD for the first real governed workflow delegation through CTO, Hermes, Harness, and Case.
---
# CTO First Real Governed Workflow PRD
Local planning SOT only. Not a Core Protocol. Not active Core authority.
## Problem Statement
The CTO product surface has proof through Stage 6 and a Hermes-facing control summary, but it has not yet proven one real governed workflow from precise brief to bounded code change using the full operator path.
The next useful proof is not another synthetic stage. It is one low-risk real task that shows Cortex governs, Hermes controls, CTO routes, Harness proves, and Case executes only after proof and approval.
## Solution
Define a first real Governed Workflow Delegation route. The route must start from a precise task contract, use an explicitly admitted owned low-risk Target Repository, require JP approval before mutation, execute only through the CTO Harness Case seam, and accept completion only from Harness Evidence Interface artifacts.
This PRD does not run the workflow. It defines the gates required before `CTO-WORK-049` may execute.
## Scope
- Define the first real governed workflow route.
- Require a precise brief, PRD or issue, architecture notes when relevant, allowed paths, forbidden actions, success criteria, validation command, and rollback expectation.
- Require Target Repository admission to be current, owned, noncritical, and low risk.
- Require Hermes/operator approval before mutation.
- Require CTO to select only an eligible backend.
- Require Case to execute only behind the CTO Harness seam.
- Require Harness Evidence Interface artifacts for acceptance.
- Require Hermes Control Surface replay paths after execution.
- Keep runtime default activation false.
## Non-Goals
- Do not activate Case as default backend.
- Do not promote CTO artifacts into Core.
- Do not execute against Cortex Core, vendor source, external developer repositories, production repositories, critical repositories, or unowned repositories.
- Do not allow push, merge, deploy, close, PR open, issue close, public publication, credential change, or infrastructure mutation.
- Do not treat model/provider availability as proof of workflow safety.
- Do not let Case choose its own target, scope, authority, approval, or success criteria.
## User Stories
1. As JP, I want one real governed coding workflow, so that the CTO product surface proves end-to-end usefulness beyond synthetic fixtures.
2. As Cortex, I want the workflow bounded by existing SOT and validator discipline, so that execution does not create authority drift.
3. As Hermes, I want approval and replay paths, so that operator control is visible before and after mutation.
4. As CTO, I want backend eligibility checked before execution, so that routing is explicit and reversible.
5. As Harness, I want all acceptance to come from standard artifacts, so that success is evidence-backed and auditable.
6. As a Target Repository owner, I want allowed-path and forbidden-action enforcement, so that the workflow cannot widen scope during execution.
## Acceptance Criteria
- `CTO-WORK-049` stays candidate until a concrete Target Repository and task contract are admitted.
- The route requires a precise brief or issue before execution.
- The route requires current Target Repository admission.
- The route requires JP/Hermes approval before mutation.
- The route requires Case execution through CTO Harness only.
- The route requires runtime default activation to remain false.
- The route requires allowed-path and forbidden-action proof.
- The route requires tests or an explicit no-test rationale before acceptance.
- The route requires Harness Evidence Interface artifacts: `report.json`, `report.md`, `events.normalized.jsonl`, `trace.jsonl`, `patch.diff`, `test.log`, backend logs, artifact digests, and freshness proof.
- The route requires Hermes Control Surface replay paths after execution.
- The route requires operator acceptance or rejection after verification.
- The route fails closed for missing approval, missing target admission, dirty starting tree, disallowed path, forbidden action, failed validation, provider failure, timeout, dirty ending tree, or missing operator outcome.
- Local CTO validator checks this PRD and issue artifact.
## Validation
Planning validator:
```bash
python3 tools/validate_cto_child.py
```
Execution validator for `CTO-WORK-049` is not satisfied by this PRD. It must be a future focused Harness command that proves the real workflow artifact path and then `harness/evals/health.sh --json` once before merge and once after merge.
## Risks
- Overclaiming this PRD as execution proof. Mitigation: keep `CTO-WORK-049` candidate.
- Target scope drift. Mitigation: require admission, allowed paths, and forbidden actions before mutation.
- Approval drift. Mitigation: require JP/Hermes approval before mutation and operator outcome after verification.
- Evidence drift. Mitigation: accept only Harness Evidence Interface artifacts.
- Default drift. Mitigation: runtime default activation remains false.
## Dependencies
- `CTO-WORK-043` Stage 6 candidate-default comparison is validated.
- `CTO-WORK-045` Hermes Control Surface summary is validated.
- `CTO-WORK-047` architecture brief closeout is validated.
- A concrete owned low-risk Target Repository is selected and admitted.
- A precise task contract exists.
- Runtime Case/provider configuration is available without committing secrets or endpoint values.
- JP approval is recorded before mutation.
## Success Definition
This PRD succeeds when the first real Governed Workflow Delegation route is specified as a candidate execution item with all gates explicit, no authority drift, no default activation, and no execution claim before runtime evidence exists.