87 lines
4.6 KiB
Markdown
87 lines
4.6 KiB
Markdown
---
|
|
name: cto-hermes-control-surface-prd
|
|
tier: local
|
|
status: draft
|
|
owner: jp
|
|
source: WORKBOARD.yaml next ROI after CTO-WORK-043
|
|
created: 2026-06-01
|
|
last_reviewed: 2026-06-01
|
|
lifecycle_classification: planning
|
|
core_promotion_status: not-promoted
|
|
description: Child-local PRD for a Hermes-visible CTO Harness control summary surface.
|
|
---
|
|
|
|
# CTO Hermes Control Surface PRD
|
|
|
|
Local planning SOT only. Not a Core Protocol. Not active Core authority.
|
|
|
|
## Problem Statement
|
|
|
|
The Case proof ladder is validated through Stage 6, but the operator surface still has to inspect raw harness commands and scattered runtime artifacts. That makes Hermes weak as the control and replay layer. JP needs a compact Hermes-facing summary that shows proof state, candidate-default status, blocked comparison lanes, replay artifact paths, and next action without giving Hermes or Case authority.
|
|
|
|
## Solution
|
|
|
|
Add a read-oriented Hermes Control Surface summary behind the CTO Harness. Hermes controls visibility, approval, and replay; Cortex remains SOT authority; CTO routes; Harness proves; Case executes only after proof. The first slice is a deterministic `webui-summary.sh --json` contract that exposes current Harness health, Stage 6 candidate-default comparison status, proof artifact paths, blocked-lane rationale, and default-activation status.
|
|
|
|
## Scope
|
|
|
|
- Define a Hermes-facing CTO Harness summary contract.
|
|
- Keep the surface backed by Harness Evidence Interface artifacts.
|
|
- Expose proof ladder status through Stage 6.
|
|
- Expose candidate-default eligibility separately from runtime default activation.
|
|
- Expose replay paths for matrix, Stage 6 comparison, and failure closure reports.
|
|
- Expose blocked Codex/Pi lane rationale when deterministic validation does not run those lanes.
|
|
- Keep fake as default validation lane.
|
|
|
|
## Non-Goals
|
|
|
|
- Do not build a full Hermes WebUI panel in this slice.
|
|
- Do not add approval mutation actions.
|
|
- Do not activate Case as default backend.
|
|
- Do not promote child-local CTO artifacts into Core.
|
|
- Do not mutate Target Repositories, vendor source, external developer repositories, or Cortex Core.
|
|
- Do not store secrets, endpoints, or credential values in reports.
|
|
|
|
## User Stories
|
|
|
|
1. As JP, I want one Hermes-facing summary of CTO Harness state, so that I can inspect proof without reading raw logs.
|
|
2. As Hermes, I want replay artifact paths, so that a future panel can link to evidence instead of reinterpreting backend logs.
|
|
3. As CTO, I want candidate-default status separated from default activation, so that Case cannot become authority by wording.
|
|
4. As Harness, I want the control surface generated from validated evidence, so that UI state stays proof-backed.
|
|
5. As Cortex, I want the summary to remain child-local and non-authoritative, so that Core SOT remains the authority layer.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] PRD states Hermes controls visibility, approval, and replay but does not govern.
|
|
- [ ] PRD requires the surface to be backed by Harness Evidence Interface artifacts.
|
|
- [ ] PRD requires proof ladder status through Stage 6.
|
|
- [ ] PRD separates candidate-default eligibility from runtime default activation.
|
|
- [ ] PRD requires replay paths for matrix and Stage 6 comparison evidence.
|
|
- [ ] PRD requires blocked comparison lanes to include rationale.
|
|
- [ ] PRD forbids secrets, endpoints, credentials, Target Repository mutation, vendor-source mutation, external developer repository mutation, and Core mutation.
|
|
- [ ] Local CTO validator checks the PRD and issue artifact.
|
|
|
|
## Validation
|
|
|
|
Planning validator: `python3 tools/validate_cto_child.py`.
|
|
|
|
Implementation validator planned for Hermes: `python3 harness/runner/validate-webui-summary.py --json`, then `harness/evals/health.sh --json` after focused validation passes.
|
|
|
|
## Risks
|
|
|
|
- Summary fields may be mistaken for Core authority.
|
|
- UI consumers may treat candidate-default eligibility as runtime default activation.
|
|
- Artifact paths may become stale if not generated from fresh Harness runs.
|
|
- A broad WebUI implementation now would overreach before the summary contract is stable.
|
|
|
|
## Dependencies
|
|
|
|
- Stage 6 candidate-default comparison proof is validated.
|
|
- Harness Evidence Interface remains active.
|
|
- Hermes CTO harness commands remain the evidence source.
|
|
- Future WebUI work consumes this summary instead of raw backend logs.
|
|
|
|
## Success Definition
|
|
|
|
This slice succeeds when Hermes can consume one Harness-generated summary showing proof ladder state, Stage 6 candidate-default evidence, blocked-lane rationale, replay paths, next action, and default activation false, without changing authority, mutating repositories, or bypassing Harness validation.
|