Add CTO Case candidate PRD

CONTEXT.md

@@ -0,0 +1,26 @@
+# Cortex OS CTO Context
+
+This context defines local product language for the Cortex OS CTO planning workspace.
+It is child-local glossary language and does not create Core authority.
+
+## Language
+
+**CTO Product Surface**:
+A governed operator-facing product area for delegating bounded code-change work while preserving Cortex OS authority, evidence, and approval rules.
+_Avoid_: CTO app, autonomous developer, coding bot
+
+**Case Candidate Backend**:
+The proposed Case-based execution backend for real-repo code-change work, admitted only after adapter proof, validator coverage, and governed routing.
+_Avoid_: Case default, Case authority, replacement kernel
+
+**CTO Harness**:
+The adapter conformance and evidence validation module that normalizes backend behavior into a stable CTO evidence interface.
+_Avoid_: execution authority, final reviewer, product readiness proof
+
+**Harness Evidence Interface**:
+The stable artifact and event contract used to compare backends and prove bounded execution results.
+_Avoid_: loose evidence bundle, backend logs, success claim
+
+**Target Repository**:
+The owned source repository receiving bounded, approved, evidence-producing code changes.
+_Avoid_: vendor source, hidden workspace, disposable scratch by default

README.md

@@ -17,7 +17,7 @@ Core promotes only through SOT route.
 
 ## Status
 
-This workspace is draft and child-local. It is not registered Core authority.
+This workspace is registered as a child-local planning workspace. Registration does not grant Core authority.
 
 ## Layout
 
@@ -40,4 +40,3 @@ This workspace is draft and child-local. It is not registered Core authority.
 ```bash
 python3 tools/validate_cto_child.py
 ```
-

WORKBOARD.yaml

@@ -4,3 +4,38 @@ items:
     status: candidate
     source: sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md
     owner: jp
+  - id: CTO-WORK-002
+    title: CTO Case Candidate Backend PRD
+    status: candidate
+    source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-PRD.md
+    owner: jp
+  - id: CTO-WORK-003
+    title: Planning Validator Coverage
+    status: candidate
+    source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md
+    owner: jp
+  - id: CTO-WORK-004
+    title: Harness Evidence Interface Contract
+    status: candidate
+    source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md
+    owner: jp
+  - id: CTO-WORK-005
+    title: Case Source Admission Record
+    status: candidate
+    source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md
+    owner: jp
+  - id: CTO-WORK-006
+    title: Case Adapter Contract And Eligibility Decision
+    status: candidate
+    source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md
+    owner: jp
+  - id: CTO-WORK-007
+    title: Case Failure Fixture Matrix
+    status: candidate
+    source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md
+    owner: jp
+  - id: CTO-WORK-008
+    title: Staged Proof Gate Records
+    status: candidate
+    source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md
+    owner: jp

sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md

@@ -15,7 +15,7 @@ description: Child-local brief for making Case the default CTO execution backend
 
 ## Thesis
 
-Case should be the default real-repo execution backend for the Cortex OS CTO product surface.
+Case is the leading candidate default real-repo execution backend for the Cortex OS CTO product surface, pending adapter proof, source admission, validator coverage, and governed Core route.
 
 Cortex OS should govern Case. Cortex OS should not be built on Case.
 
@@ -51,10 +51,10 @@ Core promotes only through SOT route.
 | SOT authority: Standards, Protocols, Registries, Validators, Evidence rules      |
 +---------------------------------------+----------------------------------------+
                                         |
-                                        | emits governed Work Packet
+                                        | emits candidate work packet
                                         v
 +--------------------------------------------------------------------------------+
-| Cortex Work Packet                                                              |
+| Candidate Cortex Work Packet                                                    |
 | route, authority basis, repo scope, allowed paths, forbidden actions, risk,      |
 | success criteria, evidence expectations, approval policy                         |
 +--------------------------+-----------------------------------------------------+
@@ -87,7 +87,7 @@ Core promotes only through SOT route.
 
 ## Execution Rule
 
-Case is the CTO execution backend, not the CTO authority layer.
+Case is the candidate CTO execution backend, not the CTO authority layer.
 
 The first integration target should be:
 
@@ -98,9 +98,9 @@ cto/harness/runner/case-engine.sh
 The adapter must map:
 
 ```text
-Cortex Work Packet -> Case task file
+Candidate Cortex Work Packet -> Case task file
 Case events/logs -> CTO event envelope
-Case result -> Cortex evidence packet
+Case result -> CTO Harness evidence packet
 ```
 
 ## Preserve From Existing CTO Work
@@ -116,13 +116,21 @@ Case result -> Cortex evidence packet
 
 ## Decision Candidate
 
-Adopt Case as the default real-repo code-change backend for CTO.
+Adopt Case as the leading candidate default real-repo code-change backend for CTO after proof.
 
 Keep the existing CTO harness as the adapter and compliance test surface.
 
+## Default Eligibility Gate
+
+Case is not default until adapter validation, harness parity, allowed-path proof, approval-gate proof, source admission, failure-mode fixtures, artifact hashes, and staged execution evidence pass.
+
+## Candidate Term Notice
+
+Candidate Cortex Work Packet is not a promoted Core object class. Until Core promotes it, use existing PRD, SOT Issue, task contract, and case contract language.
+
 ## Open Questions
 
-- Which Case task fields map directly to Cortex Work Packet fields?
+- Which Case task fields map directly to Candidate Cortex Work Packet fields?
 - Which Case events need normalization into CTO event envelopes?
 - Where should Case runtime artifacts be stored for child-local evidence?
 - Which approval gates stay in Hermes WebUI versus Case?
@@ -131,4 +139,3 @@ Keep the existing CTO harness as the adapter and compliance test surface.
 ## Non-Authority Notice
 
 This brief is child-local planning. It does not promote Case, Hermes CTO, or the CTO harness into Core authority.
-

sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md

@@ -0,0 +1,164 @@
+---
+name: cto-case-candidate-backend-issues
+tier: local
+status: draft
+owner: jp
+source: sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-PRD.md
+created: 2026-05-31
+last_reviewed: 2026-05-31
+lifecycle_classification: planning
+core_promotion_status: not-promoted
+description: Child-local issue sequence for evaluating Case as a candidate CTO backend without granting Core authority.
+---
+
+# CTO Case Candidate Backend Issues
+
+Local planning SOT only. Not a Core Protocol. Not active Core authority.
+
+## Issue Sequence
+
+### CTO-WORK-003 - Planning Validator Coverage
+
+Type: AFK
+
+Blocked by: CTO-WORK-002
+
+User stories covered: 1, 5, 6, 12
+
+What to build: Extend child-local validation so the CTO workspace cannot pass planning validation if the PRD or this issue artifact is missing, stale, or authority-drifting.
+
+Acceptance criteria:
+
+- [ ] `validate_cto_child.py` requires the PRD and issue artifact.
+- [ ] Validator checks `core_promotion_status: not-promoted` on PRD and issue artifact.
+- [ ] Validator checks local-planning disclaimer on PRD and issue artifact.
+- [ ] Validator checks candidate-backend wording and rejects a plain default-backend claim.
+- [ ] Validator checks `WORKBOARD.yaml` contains PRD and issue entries.
+- [ ] Validation remains planning-only and does not claim backend readiness.
+
+Allowed files: CTO child workspace planning docs and local validator only.
+
+Validator: `python3 tools/validate_cto_child.py`
+
+Done evidence: validator JSON, clean worktree, commit.
+
+### CTO-WORK-004 - Harness Evidence Interface Contract
+
+Type: AFK
+
+Blocked by: CTO-WORK-003
+
+User stories covered: 4, 9, 10, 11
+
+What to build: Define the stable Harness Evidence Interface that any Case adapter must satisfy before execution work starts.
+
+Acceptance criteria:
+
+- [ ] Contract names exact required artifacts: `report.json`, `report.md`, `events.normalized.jsonl`, `patch.diff`, `test.log`, `trace.jsonl`, and backend raw logs.
+- [ ] Contract names required `report.json` fields: run start, run end, backend exit code, changed files, blockers, pass/fail status, artifact paths, and digest manifest.
+- [ ] Contract requires SHA-256 digests and freshness proof.
+- [ ] Contract defines fail-closed semantics and nonzero exit behavior.
+- [ ] Contract defines approval events: `approval.requested`, `approval.granted`, `approval.denied`.
+
+Allowed files: CTO child workspace planning docs only.
+
+Validator: `python3 tools/validate_cto_child.py`
+
+Done evidence: contract artifact, validator JSON, clean worktree, commit.
+
+### CTO-WORK-005 - Case Source Admission Record
+
+Type: AFK
+
+Blocked by: CTO-WORK-003
+
+User stories covered: 1, 12, 13
+
+What to build: Define and record the source admission shape required before any non-artificial Case run.
+
+Acceptance criteria:
+
+- [ ] Source admission fields include source URL, pinned commit or tag, license note, retrieval date, retrieval command, integrity hash or source-lock reference, allowed execution mode, and protected-source boundary.
+- [ ] Source update rule records previous and new source IDs.
+- [ ] Source admission remains child-local and does not mutate vendor source.
+- [ ] Validator checks the planning artifact exists before later Case adapter candidacy.
+
+Allowed files: CTO child workspace planning docs and local validator only.
+
+Validator: `python3 tools/validate_cto_child.py`
+
+Done evidence: source admission artifact, validator JSON, clean worktree, commit.
+
+### CTO-WORK-006 - Case Adapter Contract And Eligibility Decision
+
+Type: AFK
+
+Blocked by: CTO-WORK-004, CTO-WORK-005
+
+User stories covered: 3, 4, 8, 10
+
+What to build: Define the Case adapter contract and CTO Eligibility Decision without implementing real backend execution.
+
+Acceptance criteria:
+
+- [ ] Contract requires `case` to be registered as a gated engine before execution.
+- [ ] Contract requires the harness to accept `--engine case` only when explicitly enabled.
+- [ ] Contract prevents a parallel runner path outside the existing harness seam.
+- [ ] Eligibility Decision records selected backend, denied backends, risk class, required gates, allowed mutation mode, reasons, and escalation path.
+- [ ] Case may recommend but cannot approve itself or select its own authority.
+
+Allowed files: CTO child workspace planning docs only.
+
+Validator: `python3 tools/validate_cto_child.py`
+
+Done evidence: adapter contract artifact, validator JSON, clean worktree, commit.
+
+### CTO-WORK-007 - Case Failure Fixture Matrix
+
+Type: AFK
+
+Blocked by: CTO-WORK-004, CTO-WORK-006
+
+User stories covered: 8, 9, 11, 13
+
+What to build: Define the required failure fixtures for later Case adapter testing.
+
+Acceptance criteria:
+
+- [ ] Matrix includes 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.
+- [ ] Each row names expected blocker reason, normalized event, report status, and exit behavior.
+- [ ] Each row maps to the Harness Evidence Interface.
+- [ ] Matrix is planning-only and does not run Case.
+
+Allowed files: CTO child workspace planning docs only.
+
+Validator: `python3 tools/validate_cto_child.py`
+
+Done evidence: failure matrix artifact, validator JSON, clean worktree, commit.
+
+### CTO-WORK-008 - Staged Proof Gate Records
+
+Type: AFK
+
+Blocked by: CTO-WORK-004, CTO-WORK-006, CTO-WORK-007
+
+User stories covered: 5, 7, 8, 9, 13
+
+What to build: Define per-stage entry and exit records for Case candidate progression.
+
+Acceptance criteria:
+
+- [ ] Records cover gated engine, artificial fixture, copied repo fixture, disposable sandbox repo, owned noncritical repo, and candidate default.
+- [ ] Each stage names allowed mutation scope, required artifacts, validator, failure modes, and promotion condition.
+- [ ] Candidate default requires comparison against fake, Codex, and Pi where applicable.
+- [ ] Records state that default status is earned, not assumed.
+
+Allowed files: CTO child workspace planning docs only.
+
+Validator: `python3 tools/validate_cto_child.py`
+
+Done evidence: staged gate artifact, validator JSON, clean worktree, commit.
+
+## Granularity Check
+
+This sequence is intentionally planning-heavy. It avoids implementing Case until the evidence interface, source admission, adapter contract, failure matrix, and staged proof gates are explicit.

sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-PRD.md

@@ -0,0 +1,160 @@
+---
+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.

tools/validate_cto_child.py

@@ -13,8 +13,11 @@ REQUIRED_FILES = [
     "AGENTS.md",
     "README.md",
     "WORKBOARD.yaml",
+    "CONTEXT.md",
     "sot/00-START/CTO-WORKSPACE-INTENT.md",
     "sot/03-PROTOCOLS/CTO-CASE-BACKEND-BRIEF.md",
+    "sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-PRD.md",
+    "sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md",
 ]
 
 REQUIRED_BRIEF_PHRASES = [
@@ -23,10 +26,36 @@ REQUIRED_BRIEF_PHRASES = [
     "Case executes.",
     "Harness proves.",
     "Core promotes only through SOT route.",
-    "Case is the CTO execution backend, not the CTO authority layer.",
+    "Case is the candidate CTO execution backend, not the CTO authority layer.",
     "This brief is child-local planning.",
 ]
 
+REQUIRED_PRD_PHRASES = [
+    "Local planning SOT only. Not a Core Protocol. Not active Core authority.",
+    "Case Candidate Backend",
+    "Harness Evidence Interface",
+    "Case may recommend; CTO Harness records; Hermes or operator approval is the only human approval signal.",
+    "Candidate Cortex Work Packet is an unpromoted term.",
+    "Staged Proof Gates",
+    "Source Admission Requirements",
+    "Failure-Mode Matrix",
+    "Fake remains the default validation lane.",
+]
+
+FORBIDDEN_PRD_PHRASES = [
+    "Case should be the default real-repo execution backend",
+    "Case is the default real-repo execution backend",
+]
+
+REQUIRED_ISSUE_IDS = [
+    "CTO-WORK-003",
+    "CTO-WORK-004",
+    "CTO-WORK-005",
+    "CTO-WORK-006",
+    "CTO-WORK-007",
+    "CTO-WORK-008",
+]
+
 
 def main() -> int:
     checked: list[str] = []
@@ -48,6 +77,40 @@ def main() -> int:
         if "core_promotion_status: not-promoted" not in text:
             errors.append("brief_missing_not_promoted_frontmatter")
 
+    prd = ROOT / "sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-PRD.md"
+    if prd.is_file():
+        text = prd.read_text(encoding="utf-8")
+        for phrase in REQUIRED_PRD_PHRASES:
+            checked.append(f"prd_phrase:{phrase}")
+            if phrase not in text:
+                errors.append(f"missing_prd_phrase:{phrase}")
+        for phrase in FORBIDDEN_PRD_PHRASES:
+            checked.append(f"prd_forbidden_phrase:{phrase}")
+            if phrase in text:
+                errors.append(f"forbidden_prd_phrase:{phrase}")
+        if "core_promotion_status: not-promoted" not in text:
+            errors.append("prd_missing_not_promoted_frontmatter")
+
+    issues = ROOT / "sot/03-PROTOCOLS/CTO-CASE-CANDIDATE-BACKEND-ISSUES.md"
+    if issues.is_file():
+        text = issues.read_text(encoding="utf-8")
+        if "Local planning SOT only. Not a Core Protocol. Not active Core authority." not in text:
+            errors.append("issues_missing_local_planning_notice")
+        if "core_promotion_status: not-promoted" not in text:
+            errors.append("issues_missing_not_promoted_frontmatter")
+        for issue_id in REQUIRED_ISSUE_IDS:
+            checked.append(f"issue_id:{issue_id}")
+            if issue_id not in text:
+                errors.append(f"missing_issue_id:{issue_id}")
+
+    board = ROOT / "WORKBOARD.yaml"
+    if board.is_file():
+        text = board.read_text(encoding="utf-8")
+        for issue_id in ["CTO-WORK-002", *REQUIRED_ISSUE_IDS]:
+            checked.append(f"workboard_id:{issue_id}")
+            if issue_id not in text:
+                errors.append(f"missing_workboard_id:{issue_id}")
+
     payload = {
         "ok": not errors,
         "validator": "cto-child-v1",