cto/.sot/03-PROTOCOLS/CTO-CORE-PROMOTION-DECISION-PACKET-PRD.md
2026-06-02 07:00:34 -04:00

9.1 KiB

name status lifecycle_classification owner created last_reviewed core_promotion_status source
CTO Core Promotion Decision Packet PRD validated sot jp 2026-06-02 2026-06-02 not-promoted .sot/03-PROTOCOLS/CTO-CASE-STAGE6-REPEATABILITY-REFRESH-EVIDENCE.md

CTO Core Promotion Decision Packet PRD

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

Core Promotion Decision Packet.

Problem Statement

CTO now has validated child-local evidence through Stage 6 repeatability: two governed Stage 5 Case passes, a read-only Stage 6 repeatability refresh, Hermes Control Surface replay data, runtime default activation false, and Core promotion status not-promoted. Without one compact decision packet, the next operator or Core route has to reconstruct readiness from many artifacts and can misread candidate-default readiness as promotion or runtime default authority.

Solution

Create a child-local Core Promotion Decision Packet that maps validated CTO evidence to one future governed Core review decision. The packet records decision_status: core_promotion_requested, ready_for_core_review: true, candidate_default_repeatability_eligible: true, runtime_default_activation: false, and core_promotion_status: not-promoted. It recommends opening a separate governed Core PRD route if JP or a governed Core route chooses to pursue promotion. It does not mutate Core, promote CTO artifacts, activate Case as runtime default, or authorize another Case run.

Scope

  • Register CTO-WORK-085, CTO-WORK-086, CTO-WORK-087, and CTO-WORK-088.
  • Define the packet as child-local CTO planning only.
  • Define allowed decision states: not_decided, core_promotion_requested, and core_promotion_deferred.
  • Set the current decision state to core_promotion_requested as a request for Core review, not as promotion approval.
  • Map evidence from CTO-WORK-071, CTO-WORK-075, CTO-WORK-077, CTO-WORK-080, CTO-WORK-081, CTO-WORK-082, CTO-WORK-083, and CTO-WORK-084.
  • Include repeatability_count: 2.
  • Include repeatability_status: pass.
  • Include candidate_default_repeatability_eligible: true.
  • Include runtime_default_activation: false.
  • Include Core promotion status not-promoted.
  • Reference the Stage 6 repeatability comparison artifact.
  • Reference the Hermes WebUI summary artifact.
  • Record the recommended next decision as open_governed_core_prd_route.
  • State Core Sequence Protocol route required before any Core mutation.
  • State Core validator coverage required before any Core promotion claim.
  • State runtime default activation requires a separate governed Core route.
  • State no new target repository mutation occurs.
  • State no Core file mutation occurs in this CTO slice.
  • Preserve secrets, endpoints, credential values, and raw Target Repository content out of SOT.

Non-Goals

  • Do not promote CTO artifacts into Core.
  • Do not activate Case as default backend.
  • Do not run Case.
  • Do not mutate target repositories.
  • Do not mutate ../core/.
  • Do not edit upstream hermes-webui.
  • Do not edit upstream hermes-agent.
  • Do not create Runtime behavior.
  • Do not create a new backend, provider, adapter, harness command, or WebUI control.
  • Do not push, merge, deploy, close, PR open, issue close, public publication, vendor-source mutation, external developer repository mutation, unowned repository mutation, endpoint exposure, secret exposure, credential exposure, or raw Target Repository content exposure.
  • Do not treat Case, Hermes, Pi, Codex, Harness, or CTO as Cortex OS authority.

User Stories

  1. As JP, I want one compact readiness packet, so that I can decide whether to open a governed Core review without reading every CTO artifact first.
  2. As Cortex OS Core, I want child-local evidence to remain child-local until routed, so that promotion cannot happen by wording.
  3. As CTO, I want candidate-default readiness separated from runtime default activation, so that repeatability evidence cannot become execution authority.
  4. As Hermes, I want replay paths preserved in the packet, so that proof can be inspected without copying runtime artifacts into SOT.
  5. As a future Core agent, I want explicit blockers and required validators, so that a Core PRD route can start from a clear contract.

Implementation Decisions

  • The packet is a SOT document in the CTO workspace, not a generated artifact and not a Core Protocol.
  • The packet is the interface for this slice; no runtime module, adapter, or new command is introduced.
  • The decision record uses only not_decided, core_promotion_requested, and core_promotion_deferred.
  • The packet records ready_for_core_review: true rather than promoted, approved, or runtime_default_active.
  • The packet maps evidence by Workboard IDs and replay artifact paths instead of copying runtime JSON, proof logs, or raw Target Repository content.
  • The packet's next action is a decision route: open_governed_core_prd_route.
  • Any later promotion must happen from the Core workspace under the Core Sequence Protocol, Core object classification, Core validators, and Core Evidence.

Testing Decisions

  • Test at the highest existing seam: python3 tools/validate_cto_child.py.
  • Validator coverage must require the packet files, Workboard IDs, readiness fields, authority guards, replay paths, and forbidden-action language.
  • Core caveman prose discipline remains required before claim or final answer.
  • No Harness aggregate is required for this slice because no Hermes, Harness, Case, or Target Repository behavior changes.

Challenge Review

  • $zoom-out: accepted. The packet maps the vertical chain: Cortex governs, CTO routes, Hermes controls, Harness proves, Case executes, Target Repository stays owned.
  • $improve-codebase-architecture: accepted. The deepest useful interface is the existing SOT plus validator seam; adding a runtime abstraction would create shallow machinery.
  • $grill-with-docs: accepted. Core Promotion Decision Packet is added to CONTEXT.md, and the canonical readiness term is ready_for_core_review.
  • Reviewer feedback accepted: use a separate decision record and closeout so the decision state is fail-closed and the validation proof is explicit.
  • Reviewer feedback accepted: preserve exact guard phrases No Core promotion occurs., Do not activate Case as default backend., and This closeout does not authorize another Case run.
  • Rejected feedback: promote directly into Core now. This is an irreversible authority choice and requires a governed Core route.
  • Rejected feedback: activate Case as runtime default now. Repeatability proves review readiness only; default activation needs separate Core authority.

Acceptance Criteria

  • WORKBOARD.yaml records CTO-WORK-085, CTO-WORK-086, CTO-WORK-087, and CTO-WORK-088 as validated.
  • CONTEXT.md defines Core Promotion Decision Packet.
  • The PRD, issue sequence, decision record, and closeout all state Local planning SOT only. Not a Core Protocol. Not active Core authority.
  • The decision record defines only not_decided, core_promotion_requested, and core_promotion_deferred.
  • The packet records decision_status: core_promotion_requested.
  • The packet records ready_for_core_review: true.
  • The packet records candidate_default_repeatability_eligible: true.
  • The packet records repeatability_count: 2.
  • The packet records repeatability_status: pass.
  • The packet records runtime_default_activation: false.
  • The packet records core_promotion_status: not-promoted.
  • The packet records recommended_next_decision: open_governed_core_prd_route.
  • The packet states Core Sequence Protocol route required.
  • The packet states Core validator coverage required.
  • The packet states runtime default activation requires a separate governed Core route.
  • The packet references the Stage 6 repeatability comparison artifact.
  • The packet references the Hermes WebUI summary artifact.
  • The packet states no Core mutation, no Target Repository mutation, no Case execution, and no default activation occur in this slice.
  • The CTO validator checks the PRD, issue sequence, decision record, closeout, and Workboard statuses.

Validation

  • python3 tools/validate_cto_child.py
  • python3 /home/svrnty/workspaces/cortex-os/core/tools/check_s69_caveman_prose_discipline.py

Risks And Dependencies

  • Readiness language can be misread as promotion. Mitigation: require ready_for_core_review, core_promotion_status: not-promoted, and runtime default activation false.
  • The future Core route can conflict with current Core Sequence Protocol priorities. Mitigation: the packet recommends review only and requires Core Sequence Protocol routing before Core mutation.
  • Evidence paths can drift. Mitigation: packet records exact replay artifact paths and Workboard IDs.
  • New CTO text can overstate authority. Mitigation: CTO validator requires authority guard phrases and forbidden-action language.

Success Definition

CTO has one validated Core Promotion Decision Packet that says candidate-default evidence is ready for Core review, while Core promotion remains not-promoted, runtime default activation remains false, no Core or Target Repository mutation occurs, and any promotion must begin as a separate governed Core PRD route.