5.4 KiB
| name | tier | status | owner | source | created | last_reviewed | lifecycle_classification | core_promotion_status | description |
|---|---|---|---|---|---|---|---|---|---|
| cto-case-stage1-gated-engine-prd | local | draft | jp | .sot/03-PROTOCOLS/CTO-CASE-STAGED-PROOF-GATES.md | 2026-05-31 | 2026-05-31 | planning | not-promoted | Child-local PRD for Stage 1 gated Case engine proof with no mutation and no Case execution. |
CTO Case Stage 1 Gated Engine PRD
Local planning SOT only. Not a Core Protocol. Not active Core authority.
Problem Statement
The CTO planning path now defines the Case candidate backend, evidence interface, source admission record, adapter contract, failure matrix, and staged proof gates. The next risk is jumping from planning into executable Case integration too broadly. Stage 1 must prove only the smallest safe executable behavior: the harness can recognize a gated case backend, reject it by default, and produce evidence for that rejection without mutating source or running Case.
Solution
Define a no-mutation Stage 1 implementation slice for the Hermes CTO harness route. The slice creates a no-op gated case backend path that proves default-deny behavior and evidence emission. It does not run Case, does not inspect target repositories, does not patch files, and does not broaden Hermes WebUI behavior.
Scope
- Register
caseas a gated backend in the future harness implementation. - Require
CTO_HARNESS_ALLOW_CASE=1before--engine casecan proceed past the Stage 1 gate. - Produce a blocked report when the gate is missing.
- Produce normalized events and artifacts for the blocked preflight.
- Prove no source mutation.
- Keep fake as the default validation lane.
- Route future implementation through
/home/svrnty/workspaces/hermes/cto/harnessafter reading that workspace guidance and validators.
Non-Goals
- Do not run Case.
- Do not create real PRs.
- Do not mutate a Target Repository.
- Do not add WebUI Product behavior.
- Do not resolve the Case license blocker.
- Do not implement artificial fixture execution.
- Do not promote any artifact into Core.
- Do not vendor Case source.
Acceptance Criteria
- Stage 1 keeps allowed mutation scope as
none. caseis disabled by default.- Missing gate produces blocked status, not warning.
- Harness evidence includes
report.json,report.md,events.normalized.jsonl,trace.jsonl, no-oppatch.diff, no-optest.log, andbackend/case-gate.log. - Report records
backend: case,status: blocked,backend_exit_code,blockers, artifact paths, digests, freshness proof,source_admission_status: not_admitted, andcase_process_started: false. - Normalized events include
run.started,task.contract.created,backend.gate.blocked, andrun.completed. backend.gate.blockedincludesbackend,gate,reason,mutation_mode, andcase_executed: false.- Stage 1 blocked preflight may omit patch, diff, and verification events only when
report.jsonrecords explicitnot_applicablereasons. - Stage 1 gate runs before case workspace copy,
git init, runner invocation, target repository inspection, or Case process start. - No files under harness source checkout, target repo, Case source, vendor source, or Cortex Core are changed by the Stage 1 run. Only runtime artifact directory writes are allowed.
- Implementation-time edits may touch only the routed harness files named by the implementation issue.
- Validator proves
--engine caseis rejected unlessCTO_HARNESS_ALLOW_CASE=1. - Validator proves fake remains the default validation lane.
- Validator proves
caseis selected through the same engine dispatch path asfake,codex, andpi; no separate command, script path, or special-case bypass. - Implementation remains outside Cortex OS Core and does not claim Runtime or product readiness.
Validation
- Focused Stage 1 validator must check gated
caseregistration, default-deny behavior, required artifact set, normalized events, no source mutation, fake default retention, and blocked status. - Focused Stage 1 validator must run command-level checks: default harness without engine still selects
fake;--engine casewithout env emits blocked evidence;CTO_HARNESS_ALLOW_CASE=1 --engine casestill does not run Case in Stage 1. - Focused Stage 1 validator must inspect
harness.yaml, CLI usage text, argument validation, and engine dispatch. - Existing child-local CTO validator must require this PRD and issue artifact before later Stage 1 implementation is considered governed.
- Post-implementation validation must run the focused Stage 1 validator before any broader harness validation.
Risks
- A no-op adapter can be mistaken for Case execution.
- A gate can become warning-only instead of blocking.
- Evidence can become path-only without digest or freshness proof.
- Harness code can accidentally make
caseavailable by default. - Stage 1 success can be misused to justify artificial fixture or real-repo work.
Dependencies
- Validated Harness Evidence Interface Contract.
- Validated Case Adapter Contract.
- Validated Case Failure Fixture Matrix.
- Validated Staged Proof Gate Records.
- Future implementation route in the harness workspace.
- Focused Stage 1 validator spec or stub before implementation edits.
Success Definition
Stage 1 is successful when the future harness can prove case is recognized as a backend, denied by default, evidence-producing, and non-mutating. Stage 1 does not make Case executable and does not resolve Case source admission.