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

Add Case Stage 6 candidate default planning

Browse Source
This commit is contained in:
Svrnty
2026-06-01 06:10:15 -04:00
parent 0116ed2ec3
commit 0996df1bf9
6 changed files with 265 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.sot/03-PROTOCOLS/CTO-CASE-STAGE6-CANDIDATE-DEFAULT-ISSUES.md
+88
View File
@@ -0,0 +1,88 @@
---
name: cto-case-stage6-candidate-default-issues
tier: local
status: draft
owner: jp
source: .sot/03-PROTOCOLS/CTO-CASE-STAGE6-CANDIDATE-DEFAULT-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 Stage 6 Case candidate-default comparison proof.
---
# CTO Case Stage 6 Candidate Default Issues
Local planning SOT only. Not a Core Protocol. Not active Core authority.
## Issue Sequence
### CTO-WORK-042 - Stage 6 Candidate Default PRD
Type: AFK
Status: validated.
Blocked by: CTO-WORK-038
User stories covered: CTO Case Candidate Backend PRD stories 1, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13.
What to build: Define the Stage 6 candidate-default comparison proof before implementation starts.
Acceptance criteria:
- [x] PRD states Stage 6 allowed mutation scope is `scoped real-repo use only`.
- [x] PRD requires Stage 5 validation before Stage 6.
- [x] PRD requires comparison against fake, Codex, and Pi where applicable.
- [x] PRD requires Harness Evidence Interface comparison, not raw backend logs alone.
- [x] PRD requires report shape, event validity, allowed-path compliance, failure closure, and artifact completeness comparison.
- [x] PRD requires current Case source admission.
- [x] PRD requires failure matrix coverage or explicit blocked rationale.
- [x] PRD requires operator acceptance after comparison proof.
- [x] PRD forbids treating Stage 6 as default activation, Core promotion, Runtime authorization, or permission for push, merge, deploy, close, PR open, issue close, public publication, vendor-source mutation, or unowned repository mutation.
- [x] Local CTO validator checks Stage 6 PRD and issue artifact.
Allowed files: CTO child workspace planning docs and local validator only.
Validator: `python3 tools/validate_cto_child.py`
Done evidence: PRD, issue artifact, validator JSON, clean worktree, commit.
### CTO-WORK-043 - Stage 6 Harness Candidate Default Comparison Route
Type: HITL
Status: candidate.
Blocked by: CTO-WORK-042
User stories covered: CTO Case Candidate Backend PRD stories 1, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13.
What to build: In `/home/svrnty/workspaces/hermes/cto/harness`, implement the Stage 6 candidate-default comparison route behind the existing Harness seam.
Acceptance criteria:
- [ ] `case` remains disabled by default.
- [ ] Stage 6 requires Stage 5 proof evidence before comparison.
- [ ] Candidate-default comparison runs or imports evidence for fake, Codex, and Pi where applicable.
- [ ] Missing comparison lane is recorded as explicitly blocked with rationale, not silently ignored.
- [ ] Comparison output records report shape parity.
- [ ] Comparison output records event validity parity.
- [ ] Comparison output records allowed-path compliance parity.
- [ ] Comparison output records failure closure parity.
- [ ] Comparison output records artifact completeness parity.
- [ ] Case source admission freshness is recorded.
- [ ] Failure matrix coverage is complete or explicitly blocked with rationale.
- [ ] Operator acceptance or rejection is recorded after comparison proof.
- [ ] Candidate-default status is recorded as evidence only; no runtime default, Core promotion, push, merge, deploy, close, PR open, issue close, public publication, vendor-source mutation, or unowned repository mutation occurs.
- [ ] Fake remains the default validation lane and broad health remains green after focused Stage 6 validation.
Allowed files: Hermes CTO harness comparison validator, Harness docs, and tests. WebUI, Core, Case source, vendor source, unowned repositories, critical repositories, production repositories, and external developer repositories are forbidden.
Validator: `python3 harness/runner/validate-case-stage6.py --harness-root harness --json`, then `harness/evals/health.sh --json`.
Done evidence: Stage 6 comparison report, blocked-lane rationale where applicable, source freshness proof, failure matrix coverage proof, operator outcome, artifact digests, clean worktree, commit.
## Granularity Check
This is intentionally two slices: one planning route and one executable Harness comparison route. Stage 6 is not over-granular because it is the first point where Case can be discussed as candidate default, and it must separate evidence comparison from runtime default activation.
.sot/03-PROTOCOLS/CTO-CASE-STAGE6-CANDIDATE-DEFAULT-PRD.md
+101
View File
@@ -0,0 +1,101 @@
---
name: cto-case-stage6-candidate-default-prd
tier: local
status: draft
owner: jp
source: .sot/03-PROTOCOLS/CTO-CASE-STAGED-PROOF-GATES.md
created: 2026-06-01
last_reviewed: 2026-06-01
lifecycle_classification: planning
core_promotion_status: not-promoted
description: Child-local PRD for Stage 6 Case candidate-default comparison proof.
---
# CTO Case Stage 6 Candidate Default PRD
Local planning SOT only. Not a Core Protocol. Not active Core authority.
## Problem Statement
Stage 5 proves Case can change an explicitly owned low-risk Target Repository under Harness control. That is not enough to make Case the default backend. The remaining problem is comparison: Case can be discussed as candidate default only if it matches or beats the existing lanes on evidence completeness, failure closure, and bounded execution behavior.
## Solution
Define Stage 6 as a comparison and default-candidacy gate behind the existing CTO Harness seam. Stage 6 allowed mutation scope is `scoped real-repo use only`. Case remains disabled by default until comparison evidence exists against fake, Codex, and Pi where applicable. The CTO Product Surface may record candidate-default eligibility only after the Harness proves report shape, event validity, allowed-path compliance, failure closure, artifact completeness, source freshness, and operator acceptance.
## Scope
- Define Stage 6 entry gates, non-goals, acceptance criteria, validation, risks, dependencies, and success definition.
- Require Stage 5 validation before Stage 6.
- Require comparison fixtures for fake, Codex, and Pi where applicable.
- Require current Case source admission before any candidate-default claim.
- Require complete failure matrix coverage or explicit blocked rationale for each uncovered row.
- Require candidate-default evidence to use the Harness Evidence Interface.
- Require operator acceptance after comparison proof.
- Keep Core promotion, runtime default switching, merge, deploy, push, and close out of scope.
## Non-Goals
- Do not make Case the default backend.
- Do not authorize production, critical, customer, vendor, external developer, or unowned repository mutation.
- Do not promote any CTO artifact into Core.
- Do not add Hermes WebUI Runtime behavior.
- Do not remove fake, Codex, or Pi comparison lanes.
- Do not treat one passing owned-repo run as candidate-default proof.
- Do not let Case choose its own eligibility, authority, target, model, or approval.
## User Stories
1. As JP, I want Case compared against existing lanes before default candidacy, so that stronger coding behavior does not bypass evidence discipline.
2. As Cortex, I want candidate-default claims to remain child-local until Core promotion, so that execution backend choice cannot create authority.
3. As Hermes, I want comparison proof to be replayable through Harness artifacts, so that operator control and visualization remain grounded in evidence.
4. As CTO, I want backend eligibility separated from backend execution, so that Case cannot approve itself.
5. As CTO Harness, I want the same evidence interface across fake, Codex, Pi, and Case, so that comparison is mechanical rather than conversational.
6. As a Target Repository owner, I want allowed-path and forbidden-action proof preserved in Stage 6, so that scoped real-repo use stays bounded.
7. As a reviewer, I want failure matrix closure before default candidacy, so that known bad states fail closed.
## Acceptance Criteria
- [ ] Stage 6 requires Stage 5 validation evidence before candidate-default comparison.
- [ ] Stage 6 allowed mutation scope is `scoped real-repo use only`.
- [ ] Case remains disabled by default until Stage 6 evidence is recorded.
- [ ] Candidate-default proof compares Case against fake, Codex, and Pi where applicable.
- [ ] Comparison evidence uses the Harness Evidence Interface, not raw backend logs alone.
- [ ] Case matches or beats existing lanes on report shape.
- [ ] Case matches or beats existing lanes on event validity.
- [ ] Case matches or beats existing lanes on allowed-path compliance.
- [ ] Case matches or beats existing lanes on failure closure.
- [ ] Case matches or beats existing lanes on artifact completeness.
- [ ] Case source admission freshness is recorded.
- [ ] Failure matrix rows are covered or explicitly blocked with rationale.
- [ ] Operator acceptance is recorded after comparison proof.
- [ ] No push, merge, deploy, close, PR open, issue close, public publication, Core mutation, vendor-source mutation, or unowned repository mutation is authorized.
- [ ] Local CTO validator checks Stage 6 PRD and issue artifacts.
## Validation
Planning validator: `python3 tools/validate_cto_child.py`.
Implementation validator planned for Hermes: `python3 harness/runner/validate-case-stage6.py --harness-root harness --json`, then `harness/evals/health.sh --json` after focused Stage 6 validation passes.
## Risks
- Candidate-default language may be mistaken for default backend activation.
- Comparison may be too weak if it checks only pass status and not evidence completeness.
- Codex or Pi may be unavailable in a specific environment; that must become explicit `where applicable` rationale, not silent omission.
- Failure matrix gaps may be hidden by green happy-path runs.
- Source admission may become stale after earlier Stage 5 proof.
## Dependencies
- Stage 5 owned noncritical repository proof is validated.
- Harness Evidence Interface contract remains active.
- Case source admission record remains current.
- Case adapter contract remains active.
- Failure fixture matrix remains active.
- Existing fake lane remains the default validation lane.
- Codex and Pi comparison lanes are used where applicable or explicitly blocked with rationale.
## Success Definition
Stage 6 is successful when the CTO Product Surface can record Case as a candidate-default backend only after Harness comparison evidence proves Case matches or beats fake, Codex, and Pi where applicable on report shape, event validity, allowed-path compliance, failure closure, and artifact completeness, with current source admission, failure matrix coverage, operator acceptance, and no authority drift.
.sot/03-PROTOCOLS/CTO-CASE-STAGED-PROOF-GATES.md
+7
View File
@@ -304,6 +304,8 @@ Promotion condition:
## Stage 6 - Candidate Default
Status: planned. Execution remains candidate until `CTO-WORK-043` produces Harness comparison evidence after Stage 6 PRD validation.
Entry gates:
- Stage 5 is validated.
@@ -337,6 +339,11 @@ Promotion condition:
- Case may be discussed as candidate default only after comparison evidence shows it matches or beats fake, Codex, and Pi where applicable on evidence completeness and failure closure.
Planning evidence:
- Stage 6 PRD: `.sot/03-PROTOCOLS/CTO-CASE-STAGE6-CANDIDATE-DEFAULT-PRD.md`.
- Stage 6 issues: `.sot/03-PROTOCOLS/CTO-CASE-STAGE6-CANDIDATE-DEFAULT-ISSUES.md`.
## Final Guard
These staged proof gates do not implement Case and do not authorize execution. They define the minimum route for later implementation.