---
name: cto-case-stage1-gated-engine-prd
tier: local
status: draft
owner: jp
source: .sot/03-PROTOCOLS/CTO-CASE-STAGED-PROOF-GATES.md
created: 2026-05-31
last_reviewed: 2026-05-31
lifecycle_classification: planning
core_promotion_status: not-promoted
description: 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 `case` as a gated backend in the future harness implementation.
- Require `CTO_HARNESS_ALLOW_CASE=1` before `--engine case` can 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/harness` after 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`.
- `case` is disabled by default.
- Missing gate produces blocked status, not warning.
- Harness evidence includes `report.json`, `report.md`, `events.normalized.jsonl`, `trace.jsonl`, no-op `patch.diff`, no-op `test.log`, and `backend/case-gate.log`.
- Report records `backend: case`, `status: blocked`, `backend_exit_code`, `blockers`, artifact paths, digests, freshness proof, `source_admission_status: not_admitted`, and `case_process_started: false`.
- Normalized events include `run.started`, `task.contract.created`, `backend.gate.blocked`, and `run.completed`.
- `backend.gate.blocked` includes `backend`, `gate`, `reason`, `mutation_mode`, and `case_executed: false`.
- Stage 1 blocked preflight may omit patch, diff, and verification events only when `report.json` records explicit `not_applicable` reasons.
- 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 case` is rejected unless `CTO_HARNESS_ALLOW_CASE=1`.
- Validator proves fake remains the default validation lane.
- Validator proves `case` is selected through the same engine dispatch path as `fake`, `codex`, and `pi`; 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 `case` registration, 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 case` without env emits blocked evidence; `CTO_HARNESS_ALLOW_CASE=1 --engine case` still 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 `case` available 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.