---
name: cto-case-candidate-backend-prd
tier: local
status: draft
owner: jp
source: conversation
created: 2026-05-31
last_reviewed: 2026-05-31
lifecycle_classification: planning
core_promotion_status: not-promoted
description: Child-local PRD for evaluating Case as the leading candidate backend for the Cortex OS CTO Product Surface.
---

# CTO Case Candidate Backend PRD

Local planning SOT only. Not a Core Protocol. Not active Core authority.

## Problem Statement

JP wants a Cortex OS CTO Product Surface that can delegate code-change work without losing Cortex OS authority, Target Repository ownership, evidence quality, or human approval. The current CTO planning brief captures the strategic shape, but it is too easy to misread Case as an approved default backend. Case must instead earn candidate-default status through adapter proof, source admission, validator coverage, and staged execution evidence.

## Solution

Make Case the leading Case Candidate Backend behind the CTO Harness seam. Cortex OS remains the authority layer. Hermes remains the planned control and visualization surface. The CTO Product Surface interprets risk, selects eligible backends, and escalates when needed. The CTO Harness owns the Harness Evidence Interface and proves backend conformance. Case may execute only as a gated adapter that emits normalized evidence.

The first valuable outcome is not real-repo automation. The first valuable outcome is a Core-compliant, child-local PRD and issue sequence that prevents false authority claims while defining the minimum proof path for Case.

## User Stories

1. As JP, I want Cortex OS to remain the authority layer, so that backend execution cannot override Core SOT, lifecycle, or promotion rules.
2. As JP, I want planned Hermes control and replay after a routed WebUI Product Panel contract, so that I can later supervise CTO execution without reading raw backend logs.
3. As JP, I want CTO to interpret risk and backend eligibility, so that Case does not decide its own authority.
4. As JP, I want the CTO Harness to own evidence validation, so that every backend is compared through one stable interface.
5. As JP, I want Case treated as a candidate default, so that default status is earned by proof rather than assumed by enthusiasm.
6. As a future agent, I want exact authority wording, so that I do not promote Case, Hermes, or CTO behavior into Core accidentally.
7. As a future agent, I want a staged proof sequence, so that real-repo mutation is not attempted before artificial and sandbox evidence exists.
8. As a Target Repository owner, I want allowed-path and forbidden-action controls, so that code changes stay bounded.
9. As a reviewer, I want artifact hashes and normalized events, so that success claims can be checked independently.
10. As a maintainer, I want raw backend logs kept behind the Harness Evidence Interface, so that Case internals do not leak into Hermes or Core.
11. As a maintainer, I want failure modes specified, so that no-diff, failed tests, disallowed writes, missing events, rejected reviews, denied approvals, timeouts, and dirty worktrees fail closed.
12. As a Core reviewer, I want source admission for Case, so that source URL, pinned version, license note, and source lock exist before real-repo execution.
13. As JP, I want the Target Repository to stay owned and protected, so that vendors and external developers do not lose control of their source.

## Implementation Decisions

- Case is the Case Candidate Backend, not Cortex OS authority.
- CTO Harness owns the Harness Evidence Interface. Case supplies logs and results; the harness normalizes and validates them.
- CTO owns backend eligibility. Case must not decide whether it is allowed to run.
- Hermes may become the visual control surface after a routed WebUI Product Panel contract. This PRD does not authorize new WebUI Runtime behavior.
- Candidate Cortex Work Packet is an unpromoted term. Until Core promotes it, use existing PRD, SOT Issue, task contract, and case contract language.
- The first implementation seam is the existing harness engine seam. Case should be added as a gated backend adapter only after a child-local issue defines its contract.
- Case adapter output must preserve the existing harness evidence shape: report, normalized events, patch, test log, trace, changed files, blockers, and backend-specific raw logs under a backend artifact directory.
- Default eligibility requires staged proof: gated Case engine, artificial fixture, copied repo fixture, disposable sandbox repo, owned noncritical repo, then candidate default.
- Real-repo mutation is default-denied. It requires clean worktree policy, allowed paths, forbidden actions, branch policy, approval event, no direct push unless explicitly allowed, no secret reads, and no vendor-source edits unless explicitly allowed.
- Case may recommend; CTO Harness records; Hermes or operator approval is the only human approval signal. No merge, push, deploy, close, or real-repo mutation is allowed without explicit task-contract permission.
- The CTO Product Surface must emit an Eligibility Decision before selecting a backend. The decision records selected backend, denied backends, risk class, required gates, allowed mutation mode, reasons, and escalation path.

## Harness Evidence Interface Requirements

The Case adapter is not accepted until it preserves the existing CTO Harness seam:

- `case` is registered as a gated engine.
- The harness accepts `--engine case` without creating a parallel runner path.
- `case-engine.sh` is gated by explicit environment or configuration.
- Each run writes `report.json`, `report.md`, `events.normalized.jsonl`, `patch.diff`, `test.log`, and `trace.jsonl`.
- Backend-specific raw logs live under a backend artifact directory.
- `report.json` records run start, run end, backend exit code, changed files, blockers, pass/fail status, and artifact paths.
- `report.json` records SHA-256 digests for `report.json`, `events.normalized.jsonl`, `patch.diff`, `test.log`, `trace.jsonl`, and raw backend logs.
- Digest evidence includes freshness proof by comparing run start time with artifact write time or check time.
- Required approval events before live mutation are `approval.requested`, `approval.granted`, and `approval.denied`. Denial is terminal and fail-closed.
- Fail-closed states produce a blocker reason, normalized event, report status, and nonzero exit where appropriate.

## Source Admission Requirements

Before any non-artificial Case run, a source admission record must exist with:

- source URL;
- pinned commit or tag;
- license note;
- retrieval date;
- retrieval command;
- integrity hash or source-lock reference;
- allowed execution mode;
- protected-source boundary;
- previous and new source IDs when the pinned Case version changes.

Changing the pinned Case source requires rerunning adapter fixtures and recording previous and new source IDs in evidence.

## Staged Proof Gates

| Stage | Allowed mutation scope | Required exit evidence | Promotion condition |
| --- | --- | --- | --- |
| Gated Case engine | none | gated engine registration, default-deny proof, no-op preflight report | Harness accepts `--engine case` only when explicitly enabled |
| Artificial fixture | copied artificial case only | full Harness Evidence Interface, allowed-write proof, hash proof | matches existing fake fixture behavior |
| Copied repo fixture | copied local repository fixture only | clean start/end proof, diff proof, tests, failure fixtures | no source repo mutation |
| Disposable sandbox repo | disposable repository only | branch policy, approval event, failure matrix | no hidden mutation, fail-closed behavior |
| Owned noncritical repo | explicitly owned low-risk repository | source admission, approval, allowed paths, replayable evidence | operator accepts bounded proof |
| Candidate default | scoped real-repo use only | comparison against fake/Codex/Pi where applicable | matches or beats existing lanes on report shape, event validity, allowed-path compliance, failure closure, and artifact completeness |

## Failure-Mode Matrix

Later adapter work must include fixtures for: no diff, disallowed file, failed tests, missing test command, missing event, reviewer reject, approval denied, timeout, dirty starting tree, dirty ending tree, artifact write failure, and provider unavailable.

## Acceptance Criteria

- The PRD states that Case is a candidate backend and not Cortex OS authority.
- The PRD defines Cortex, Hermes, CTO, Harness, Case, and Target Repository responsibilities without authority drift.
- The PRD names the CTO Harness as owner of the evidence interface.
- The PRD includes staged proof before default eligibility.
- The PRD requires source admission before real-repo Case execution.
- The PRD requires allowed-path, approval-gate, failure-mode, and artifact-hash proof.
- The PRD defines the Harness Evidence Interface with exact artifacts, digest requirements, approval events, and fail-closed behavior.
- The PRD defines source admission fields and source-lock update behavior.
- The PRD defines staged proof gates with allowed mutation scope, exit evidence, and promotion conditions.
- A child-local issue artifact exists, is linked from `WORKBOARD.yaml`, and each issue maps to one or more PRD acceptance criteria.
- Fake remains the default validation lane. Case candidate status requires comparison against existing fake, Codex, and Pi lanes where applicable rather than replacing them.
- The PRD does not authorize Runtime behavior, WebUI Product behavior, Core promotion, real-repo mutation, merge, deploy, push, or vendor-source mutation.
- Local CTO validation remains green after adding PRD and issue artifacts.

## Validation

- Run `python3 tools/validate_cto_child.py` for the child-local workspace.
- Run focused review against the PRD for Core-compliance, architecture fit, missing constraints, testability, and sequence.
- Before merge, inspect the sandcastle worktree status and the target `cto` worktree status.
- After merge, run `python3 tools/validate_cto_child.py` in the registered `cto` child workspace.

## Risks

- Case default language could create false product-readiness.
- A shallow Case adapter could leak Case lifecycle details into Hermes and Core.
- A weak validator could prove words instead of backend safety.
- Real-repo mutation could outrun artificial, copied, and sandbox proof.
- Case source could drift without pinned source admission.
- Duplicate approval gates between Hermes and Case could create false safety.

## Dependencies

- Existing CTO child workspace registration.
- Existing CTO Harness evidence discipline in Hermes.
- Source admission details for Case.
- Later child-local adapter contract and validator.
- Later governed Core route before promotion.

## Success Definition

The CTO Product Surface has a Core-compliant planning path for evaluating Case as a candidate backend while preserving governance, observability, reversibility, evidence, allowed-path control, and JP approval. No default backend claim exists until the staged proof sequence passes.

## Out of Scope

- Implementing `case-engine.sh`.
- Running Case against a real repository.
- Promoting any CTO artifact into Core.
- Adding WebUI Product behavior.
- Merging, deploying, pushing, or closing PRs.
- Mutating vendor source or external developer repositories.
- Replacing Pi, Codex, or existing fake comparative lanes.

## Further Notes

Keep fake as the default validation lane until Case earns candidate-default status. Keep Codex and Pi comparative lanes so Case can be measured rather than trusted.