107 lines
5.9 KiB
Markdown
107 lines
5.9 KiB
Markdown
---
|
|
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.
|