메뉴
δ role-skill. Owns the two-sided coherence-cell membrane (outward boundary decision on receipt + V verdict; inward implementation-contract enrichment at dispatch) and the override authority that compose with V's verdict per RECEIPT-VALIDATION.md.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
A recursive coherence methodology for cnos cell architectures and cell executions. It measures the three-cell system, each cell's CCNF kernel, typed contract/evidence surfaces, cell and wave FSMs, and an actual receipt stream without allowing a strong local layer to average away a broken cross-level projection.
Coherence-Driven Development. Use for substantial changes that require explicit selection, artifact flow, review, release, and post-release closure.
Measurement fixture for State-A execution path validation.
Measurement fixture for State-A execution-mode validation.
Measurement fixture for TSC-compatible methodology validation.
Measurement fixture for TSC-compatible methodology validation.
| name | delta |
| description | δ role-skill. Owns the two-sided coherence-cell membrane (outward boundary decision on receipt + V verdict; inward implementation-contract enrichment at dispatch) and the override authority that compose with V's verdict per RECEIPT-VALIDATION.md. |
| artifact_class | skill |
| kata_surface | embedded |
| governing_question | What does δ-as-role decide at the cell's boundary — both the receipt-facing outward gate and the dispatch-facing inward enrichment — and what authority does δ hold over override? |
| visibility | internal |
| parent | cdd |
| triggers | ["boundary","membrane","override","receipt","verdict","gate","dispatch-enrichment","implementation-contract"] |
| scope | role-local |
| inputs | ["typed receipt emitted by γ at close-out (RECEIPT-VALIDATION.md §Validation Interface)","ValidationVerdict emitted by V (RECEIPT-VALIDATION.md §Output contract)","γ-authored dispatch prompts containing the `## Implementation contract` section (wire-format at cnos.handoff/skills/handoff/dispatch/SKILL.md; γ-side authoring at gamma/SKILL.md §2.5)","repo conventions (language, package scoping, integration-target, etc. — for inward enrichment)"] |
| outputs | ["BoundaryDecision recorded against (receipt, verdict) — one of {accept, release, override, reject, repair_dispatch}","dispatch-prompt enrichment when γ leaves implementation-contract rows unpopulated (or escalation to operator-as-human when undecidable)","override declarations with structured override block when proceeding against non-PASS verdict"] |
| requires | ["active CDD cycle exists with a closed cell at scope n (receipt + verdict materialised)","or: active γ dispatch prompt awaiting δ's pre-routing enrichment"] |
| calls | ["RECEIPT-VALIDATION.md","COHERENCE-CELL-NORMAL-FORM.md","operator/SKILL.md"] |
δ is the coherence cell's boundary — the actor that decides what crosses from scope n to scope n+1, and the actor that enriches what crosses from γ's protocol-level contract into α's executable dispatch.
δ is a two-sided membrane:
δ as two-sided membrane:
outward: receipt + V verdict → parent-scope boundary decision (§1)
(V dereferences evidence from the receipt; δ records
a BoundaryDecision against the verdict)
inward: γ contract → α-ready dispatch (§2)
(implementation-contract enrichment happens here:
γ writes protocol-level; δ pins implementation-level)
COHERENCE-CELL-NORMAL-FORM.md (CCNF) names δ at step 5 of the kernel — δ reads the receipt and V's verdict and records a BoundaryDecision. RECEIPT-VALIDATION.md freezes the typed interface: V emits a ValidationVerdict; δ emits a BoundaryDecision; the two surfaces are independent and compose by an explicit rule (§4 below). The δ-inward function is the complementary face — the dispatch-time enrichment that pins the implementation-contract axes γ's protocol-level contract leaves unpinned.
δ-the-role lives here. δ-as-actor in a running CDD cycle (γ=δ collapse cases, dispatch coordination, gate routing) lives in operator/SKILL.md; the harness substrate (dispatch invocation, observability, identity, polling, timeout recovery) lives in harness/SKILL.md (Phase 4b of cnos#366, landed at cnos#398); release-effector mechanics live in release-effector/SKILL.md (Phase 4c of cnos#366, landed at cnos#399). The four surfaces are deliberately separate: the role-skill is portable (any role-scope ladder instantiation per ROLES.md can carry it); the substrate skills are the substrate-specific realizations on the current substrate (per CCNF §Two-Layer Separation: kernel is the what, realization is the how-on-this-substrate).
First-time operator? The dispatch-coordination layer (γ=δ collapse, single-session vs multi-session, harness quiescence, timeout recovery) is in
operator/SKILL.md(coordination) +harness/SKILL.md(mechanics). δ-the-role's authority and policy live here.
The outward face of δ runs after γ closes the cell and emits the receipt. V validates the receipt against the contract (per CCNF step 4 + RECEIPT-VALIDATION.md §Q1) and emits a ValidationVerdict. δ then records a BoundaryDecision — the outward act that determines whether and how the closed cell crosses to scope n+1.
γ closes cell → closed_cell exists; receipt drafted
γ emits receipt → receipt exists; cell is "closed", not "accepted"
δ invokes V on receipt → V emits ValidationVerdict
δ records BoundaryDecision → {accept | release | override | reject | repair_dispatch}
ACCEPTED → receipt transmissible to parent scope
(Per RECEIPT-VALIDATION.md §Q1 ordering rule. V is a typed predicate exposed as a capability per §Q2; δ invokes the capability, not the operator-facing cn-cdd-verify command.)
δ-as-role holds authority for the platform actions that cross the boundary. The mechanics of executing these actions live in three companion surfaces: operator/SKILL.md §3 (gate-action confirmation protocol, request-vs-observation discipline); harness/SKILL.md (dispatch invocation, observability, identity, polling, timeout recovery — landed via Phase 4b of cnos#366, cycle/398); release-effector/SKILL.md (scripts/release.sh invocation, post-push CI polling, recovery runbook, branch deletes — landed via Phase 4c of cnos#366, cycle/399). The authority-naming surface lives here:
| Action | Authority | Mechanics location |
|---|---|---|
| Pre-merge gate validation | δ authorises; γ requests via scripts/validate-release-gate.sh --mode pre-merge (cnos.cds/skills/cds/CDS.md §"Artifact contract" → §"Ownership matrix" + gamma/SKILL.md §2.10) | operator/SKILL.md §3.1 |
| Push β-approved merge to main | δ executes on β's behalf when env/auth blocks β; this is execution of β's integration authority, not δ approval | operator/SKILL.md §3.1 |
| Release-boundary preflight | δ verifies merge commit, release artifacts, tag/deploy preconditions, platform readiness; decision is proceed / request changes / override (cnos.cds/skills/cds/CDS.md §"Development lifecycle" → §"Step table" Step 9 — δ gate) | operator/SKILL.md §3.1 |
| Tag push + release | δ is sole tag-author — β does not tag; only δ creates tags per cycle | release-effector/SKILL.md |
| Branch delete | After cycle closure and merge | release-effector/SKILL.md §5 |
| Issue filing on external repos | Cross-project dependency | operator/SKILL.md §3.1 |
| Force push | Rebase required with env constraints | operator/SKILL.md §3.1 |
| Auth refresh | Token/permission expiry | operator/SKILL.md §3.1 |
The role-policy that governs the release boundary: the triad's work is not complete until tagged. Untagged post-cycle patches on main are an open boundary — the triad's output is still entangled with whatever comes next. The tag is the disconnection point. δ-as-role commits to this property; the scripts/release.sh runbook lives in release-effector/SKILL.md (Phase 4c of cnos#366 — landed via cycle/399; the doctrinal frame stays at operator/SKILL.md §3.4).
δ blocks release completion until CI is green and owns recovery on red. This is δ-role policy:
The gate does not close until CI is green or δ explicitly records an override (§3).
Gate actions fire when a role requests them, not when δ notices they're needed. Observing that a tag isn't pushed or a branch exists is not a gate trigger — γ's explicit request is.
After executing a gate action, confirm to the requesting role that the action completed.
git push origin 3.59.0 — confirmed on remote"The disconnect tag (cf. operator/SKILL.md §3.4 for the runbook) is git-observable. γ and all future agents can see it. No separate completion signal is needed — the tag appearing on main IS the proof that all gate actions completed and the cycle is disconnected.
For mid-cycle gate actions (tag push before the disconnect, branch cleanup), confirm completion to the requesting role per §1.3. But the disconnect tag itself needs no announcement — it speaks for itself.
Per CCNF §Cell Outcomes, the closed cell at scope n terminates in one of four outcomes, determined by (verdictₙ, decisionₙ). δ records decisionₙ as one of five enumerants; the outcome is the (verdict, decision) pair:
decisionₙ (δ records) | When | CCNF outcome |
|---|---|---|
accept | verdictₙ = PASS and the cell is transmissible to scope n+1 without release-boundary semantics | accepted |
release | verdictₙ = PASS and the cell ships as a release boundary (tag + downstream-distributable disconnection) | accepted |
override | verdictₙ ≠ PASS and δ proceeds anyway by recording a structured override block (§3 below) | degraded |
reject | δ refuses transmission for boundary-policy reasons; the cell terminates at scope n with no projection | blocked |
repair_dispatch | The cell stays open at scope n; a child cell at scope n runs under a repair contract; on child accept γₙ re-emits a fresh receiptₙ and steps 4–5 re-fire (CCNF §Recursion Modes) | blocked (within-scope) |
The (PASS, override) and (non-PASS, accept/release) pairs are invalid per CCNF §Cell Outcomes — these are non-terminal states; δ re-decides until the outcome is one of {accepted, degraded, blocked}.
The inward face of δ runs at dispatch time, before α is routed. γ writes the protocol-level contract (gap, ACs, oracle, evidence). γ also writes the 7-axis ## Implementation contract section into the α prompt. δ reviews that section before routing, fills any unpopulated row per repo conventions (logging the enrichment in .cdd/unreleased/{N}/gamma-clarification.md), or blocks dispatch and escalates to operator-as-human when a row is genuinely undecidable. Implementation-contract decisions belong to δ; α MUST NOT improvise.
Canonical doctrine lives at cnos.handoff/skills/handoff/dispatch/SKILL.md (Sub 3 of cnos#404, shipped under cnos#417). That skill owns:
δ's role-local realization here: δ is the actor that performs the inward review at routing time. The doctrine — what δ is responsible for, why δ holds this authority rather than γ alone, how the contract distributes across γ/α/β — lives at the canonical handoff path. The two-sided framing of δ (outward §1 + inward §2) remains the membrane's core; this section is the inward half, with doctrine sourced from cnos.handoff and execution executed here.
The inward-membrane substance landed as Phase 4a of cnos#366 (cycle/397) in this file; Sub 3 of cnos#404 (cycle/417) extracts the doctrine into cnos.handoff/skills/handoff/dispatch/SKILL.md alongside the dispatch-prompt template and the four-surface mesh declaration. This section is now a pointer; the role-local realization (δ-as-actor at routing time) stays here. Phase 4b — harness substrate landed in harness/SKILL.md via cnos#398 (cycle/398). Phase 4c — release-effector mechanics landed in release-effector/SKILL.md via cnos#399 (cycle/399). Phase 5 — γ shrink landed at cnos#400 (cycle/400). The complete two-sided framing (outward §1 + inward §2 of this file) is preserved; the doctrine for §2 is sourced from handoff.
Override is a degraded boundary action; it is never a form of validity, and it never rewrites V's verdict. This is the load-bearing freeze from RECEIPT-VALIDATION.md §Q4 (cnos#367) — restated here as δ-role doctrine because δ is the actor that records overrides.
An override is a structured override: block inside the receipt's boundary block, populated by δ when δ records a BoundaryDecision of override against a non-PASS ValidationVerdict. The validation block of the receipt continues to carry V's original verdict unchanged — override does not rewrite, mask, or replace the ValidationVerdict. The presence of a non-null boundary.override is the structural signal to every downstream consumer that the receipt closed in degraded state.
Three explicit failure modes if the design or implementation drifts:
ValidationVerdict. The validation block carries V's emitted verdict. validation.result stays at FAIL; validation.failures stays populated. δ does not edit, redact, or replace V's verdict. The verdict is what V saw; the override is what δ did with it. The two are separate fields with separate authors.validation.result == FAIL and boundary.override is populated is not equivalent to a receipt where validation.result == PASS and boundary.override == null. Downstream V at scope n+1 — reading the n-receipt as evidence — must distinguish these two cases. Treating a degraded n-receipt as PASS-equivalent would let degradation propagate silently into the parent scope.OVERRIDE-PASS as a ValidationVerdict. V emits PASS, FAIL, and possibly WARN. There is no OVERRIDE-PASS value. Override lives in the BoundaryDecision shape (an enumerant of what δ decided), not in the ValidationVerdict shape (an enumerant of what V observed). Fusing them would let δ-side decisions reach back and rewrite V-side observations.A receipt is degraded ⇔ boundary.override != null.
A receipt is PASS-equivalent ⇔ validation.result == PASS AND boundary.override == null.
Every downstream consumer of a receipt — including:
- the parent scope's V (V at scope n+1)
- the parent scope's δ
- operators auditing the cycle
- cn-cdd-verify when reading a closed cycle
— MUST check both validation.result and boundary.override before
treating the receipt as a clean closure. Reading only one of the
two fields is incorrect.
The biconditional form is load-bearing. A consumer that checks only validation.result == PASS and assumes clean closure is incorrect (it misses degraded cells V did not approve). A consumer that checks only boundary.override == null and assumes clean closure is also incorrect (it misses cells where V emitted FAIL but no override exists — which is itself an incomplete-closure state per COHERENCE-CELL.md §Receipt Validity: "A missing override block plus a non-PASS V is not a receipt — it is an incomplete closure"). Both fields must be checked together.
The δ-as-role may override a triad decision (or proceed past a non-PASS verdict) when:
Override is for information asymmetry or hard constraints, not preference.
Per cnos.cds/skills/cds/CDS.md §"Field 6: Actor collapse rule" and operator/SKILL.md §3.4 (override protocol): the reassignment must name the target agent and the reason. No implicit drift.
State:
When the override is against a non-PASS ValidationVerdict, populate the structured override: block in the receipt's boundary block with at minimum:
actor — δ identity (e.g. delta@cdd.cnos)justification — narrative reason for the overrideoriginal_validation_verdict — V's emitted verdict or a typed reference to itfailed_predicates_overridden — list of the specific failed predicate refs the override covers (blanket "override all failures" is forbidden)degraded_state — trueExamples:
failed_predicates_overridden: [release_ci_smoke]; validation.result remains as V emitted; downstream V at scope n+1 reads degraded matter."The two surfaces are independent and must not be fused. Per RECEIPT-VALIDATION.md §"ValidationVerdict vs BoundaryDecision":
| Surface | Emitted by | Describes | Lives in receipt block |
|---|---|---|---|
ValidationVerdict | V (the predicate) | Whether the receipt satisfies the contract+evidence predicates | validation |
BoundaryDecision | δ (this role) | What δ decided to do with the receipt at the boundary | boundary |
The composition rule binds them but does not collapse them. Three explicit constraints follow:
validation block of the receipt is V-owned; the boundary block is δ-owned.validation.verdict == PASS AND boundary.override == null (§3.2). Either condition failing makes the receipt non-PASS-equivalent.For the embedded kata exercising override (Kata B — "α stuck on AC3 due to undocumented API change"), see operator/SKILL.md §9.
Per RECEIPT-VALIDATION.md §Validation Interface, the composition rule:
ValidationVerdict.verdict == PASS
→ δ may record BoundaryDecision in {accept, release}
→ δ may also record BoundaryDecision in {reject, repair_dispatch} if boundary-policy
reasons orthogonal to V demand it (release freeze, downstream readiness check)
ValidationVerdict.verdict == FAIL
→ δ may record BoundaryDecision in {reject, repair_dispatch}
→ δ may record BoundaryDecision == override only as a degraded boundary action,
with the override block populated per §3. boundary.override != null is the
structural signal that downstream consumers MUST detect.
V makes acceptance available to δ on PASS; V does not make acceptance automatic. δ holds final gate authority over what crosses the boundary, and the BoundaryDecision is what δ records after consulting the verdict.
For the four closed-cell outcomes (accepted, degraded, blocked, invalid) and the within-scope vs cross-scope recursion modes, see COHERENCE-CELL-NORMAL-FORM.md §Cell Outcomes and §Recursion Modes.
These are role boundaries at the role-skill level (CCNF kernel surface). For the dispatch-coordinator role boundaries (δ-as-actor's coordinator hat in γ=δ collapse cases), see operator/SKILL.md §6.
repair_dispatch the cell to recompute its matter.operator/SKILL.md — δ-as-actor coordinator surface. Dispatch loop, γ=δ collapse rules, wait discipline, dispatch configurations doctrine, embedded kata, wave coordination. Cross-references harness/SKILL.md for dispatch / observability / polling / identity / timeout-recovery mechanics; cross-references release-effector/SKILL.md for release mechanics.harness/SKILL.md — Phase 4b substrate: dispatch invocation (claude -p / cn dispatch), JSONL observability contract, worktree management, per-actor git identity (worktree-local under extensions.worktreeConfig), polling and wake-up forms (Monitor-wrapped transition loops, reachability re-probes), branch-retry mechanics, timeout recovery. Landed via cnos#398.release-effector/SKILL.md — δ-side release mechanics: scripts/release.sh invocation, bare-X.Y.Z tag policy, post-push CI polling, CI-red recovery runbook, branch deletes. Landed via Phase 4c of cnos#366 (cycle/399). δ-as-role authority for the release boundary is named in §1.1 above; mechanics live in release-effector.RECEIPT-VALIDATION.md — frozen typed-interface design for V, the verdict-vs-decision distinction, and the override field shape (§Q4). Binding once Phase 3 of cnos#366 lands V as a working predicate.COHERENCE-CELL-NORMAL-FORM.md — kernel doctrine. δ's signature at step 5 (no evidence); the four cell outcomes; the two recursion modes; the three scope-lift projections.COHERENCE-CELL.md — predecessor doctrine. δ Boundary Complex; trust grammar; the prediction of the δ split this cycle implements.cnos.handoff/skills/handoff/dispatch/SKILL.md — canonical wire-format + 7-axis implementation-contract schema + δ-as-inward-membrane doctrine + four-surface mesh declaration. Sub 3 of cnos#404, shipped under cnos#417; the role-side surfaces below are its consumer-side realizations.gamma/SKILL.md §2.5 — γ-template side of the implementation-contract mesh (consumer realization).alpha/SKILL.md §3.6 — α-constraint side of the implementation-contract mesh (consumer realization).beta/SKILL.md §Role Rules Rule 7 — β-verification side of the implementation-contract mesh (consumer realization).release/SKILL.md and post-release/SKILL.md — β-side release authoring (RELEASE.md, CHANGELOG, version decision) and γ-side post-release assessment; release-effector cross-references both as upstream context for the δ-side mechanics it executes.This file (delta/SKILL.md) is Phase 4a of cnos#366. It carries:
Phase 4b — harness substrate (landed). Dispatch invocation shells and observability contract, per-actor git identity with worktree-aware writes, parallel-α worktree pre-creation, polling and wake-up forms, branch-retry under push restrictions, and timeout recovery — previously authored as inline shell prose in the δ-coordinator surface — have landed in harness/SKILL.md as Phase 4b of cnos#366 (cycle/398).
Phase 4c — release-effector mechanics (landed). The release-effector mechanics formerly living in operator/SKILL.md §3.4 (the single-command release script invocation, post-push CI polling, the recovery runbook, branch deletes, manual-tag prohibition) have landed in release-effector/SKILL.md as Phase 4c of cnos#366 (cycle/399). The β-side authoring stays in release/SKILL.md (§2.4 CHANGELOG, §2.5 RELEASE.md, §2.5a cycle-dir move, pre-release validators); release-effector handles the δ-side mechanics only.
Phase 5 — γ shrink (landed). gamma/SKILL.md reduced to coordination + closure + triage doctrine; runtime supervision mechanics (polling shell, dispatch invocation shells, branch pre-flight bash) now cross-reference harness/SKILL.md and release-effector/SKILL.md rather than restating. Landed via cnos#400 (cycle/400).
All three substrate surfaces are now landed. δ-as-role's authority over the platform actions is named in §1.1 above; the harness substrate lives in harness/SKILL.md; release-effector mechanics live in release-effector/SKILL.md; operator-as-coordinator routing discipline (gate-action confirmation, request-vs-observation) lives in operator/SKILL.md §3.
Canonical doctrine: docs/papers/BOX-AND-THE-RUNNER.md (cnos#425, this section's authoring cycle). Landed alongside this section under the doctrine-before-first-use rule: the essay, this skill section, the first workflow artifact, and the first instantiated receipt all land in the same commit-set; the workflow's push trigger only fires post-merge, by which point the doctrine governs.
δ-class rule: Any artifact an agent commits that, when present on its branch, causes another body to execute is a δ-class effect surface. δ holds authority over its authoring, not just over the receipt that closes the cell containing it.
The pattern covers, at minimum: .github/workflows/*.yml files; deploy hooks; extension manifests with execution permissions; scheduled-job definitions; webhook handlers; MCP server registrations; release-effector invocation scripts the agent authors rather than invokes. The class is artifacts that cause another body to execute — the local-shell case is one body; remote runners, deploy hooks, third-party services, and host-process extensions are other bodies. δ's authority extends to every body the agent's writes can reach, not just the body the harness can see.
The reason the rule sits in δ-as-role rather than in α-as-producer is that the effect crosses a boundary the producer cannot validate by itself. α writes the YAML; α cannot inspect the runner that will execute it. β reviews the YAML; β cannot replay the future run. Only δ-as-role, whose signature is the boundary decision, can name what authority the runner has, where it runs, and who may accept the result. The 6-field receipt is δ's surface for recording that naming.
When δ-as-role approves the authoring of any remote-runner-triggering artifact, δ requires a receipt with six fields (per BOX-AND-THE-RUNNER.md §"The 6-field receipt convention"):
| Field | Content |
|---|---|
| 1. Who asked | Operator session + directive, or upstream-cell receipt ref. Agent-initiated remote-runner moves without an upstream request are forbidden. |
| 2. What runs | The actual commands the remote body will execute, at command granularity (not "publishes release" — list git tag -f X Y, git push --force origin X, etc.). |
| 3. Where it runs | The execution environment (ubuntu-latest on GitHub Actions; a self-hosted runner; a third-party service). |
| 4. What authority | The token, scopes, secrets, and credentials the runner has access to (GITHUB_TOKEN with contents: write; deploy keys; cloud OIDC roles). |
| 5. Evidence | The artifact that proves the run happened (workflow run URL; release URL; deployment ID). May be a post-run-fillable placeholder authored before the run, with the shape of the evidence named in advance. |
| 6. Who may accept | The actor (operator or named cell) authorized to declare the remote run a success, with the acceptance criterion. |
Receipt path: .cdd/unreleased/{N}/remote-runner-receipt-{handle}.md for the issue cycle that authors the artifact. The receipt moves with the cycle into the release directory at cycle close.
The receipt and the doctrine citation must land with or before the artifact that will trigger execution. There must be no window in which a remote-runner-triggering artifact exists on a branch that can reach an executing runner without the accompanying receipt also existing on that branch. For push-triggered workflows, the artifact and the receipt commit together; for branch-protected workflows whose dispatch is gated, the receipt may pre-land but the artifact must not pre-land alone.
Concretely, when γ dispatches a cycle that will author a remote-runner artifact, δ at the inward membrane (§2) pins this discipline into the implementation contract: the dispatch-prompt names the receipt as a required artifact, and α-side closure is incomplete without it. β verifies presence + 6-field completeness at R1 review.
When the remote-runner artifact is one-shot (a release-fix workflow; a single migration job; an infrastructure repair), the artifact MUST contain a final step that deletes itself from the repository after the work completes (git rm + git commit + git push). This is boundary discipline applied to the effect surface itself: the artifact does not persist beyond its declared single use, so the latent-execution authority closes after the run rather than remaining open. Persistent workflows (regularly-scheduled jobs, ongoing CI) do not self-delete; they are declared persistent at authoring time and the receipt's "Who may accept" field names the actor that owns the ongoing schedule.
The remote-runner receipt is one piece of evidence inside the cell's full receipt at close-out. V (per §4) validates the cycle receipt; the remote-runner sub-receipt is a typed evidence ref V dereferences when the cycle's matter includes a remote-runner-triggering artifact. δ records the BoundaryDecision against V's verdict per §1.5 as normal; the override block (§3) is populated if δ accepts the cycle despite a non-PASS verdict on the remote-runner receipt (e.g. the post-run evidence is missing and the acceptor has not yet declared acceptance).
The remote-runner receipt does not replace V or the BoundaryDecision — it is the surface that makes the authoring of the effect artifact legible. The cycle-level V/δ wall still gates whether the cycle as a whole closes accepted, degraded, blocked, or invalid.
release-effector/SKILL.md) governs locally-invoked release moves with release-boundary authority; the remote-runner rule governs runner-invoked moves on any boundary. The two surfaces overlap for any release-fix that uses a remote runner (cnos#425 is the first such case); the receipt cites both skills as governing.cnos#425 is the first cycle to author a remote-runner artifact under this doctrine. The artifact is .github/workflows/repoint-3.82.0.yml (one-shot; self-deleting); the receipt is .cdd/unreleased/425/remote-runner-receipt-3.82.0.md (6 fields filled, evidence as post-run-fillable placeholder); the effect is force-moving the 3.82.0 tag to fd1d654e so release.yml publishes the GH release with the correct root RELEASE.md body. The doctrine + skill section + workflow + receipt land in the same commit-set per §8.2; the post-merge push triggers the workflow under doctrine.
This section is the production-mode δ contract: what δ does when a package-owned dispatch wake (per cnos.core/skills/agent/dispatch-protocol/SKILL.md §Algorithm step 6 "Launch") hands δ a claimed cell. The wake claims; δ runs the cell. Sections §1–§8 above describe δ in receipt/dispatch/override/release contexts; this section names how δ behaves when the invocation carrier is a substrate firing of a dispatch wake rather than a human operator at the loop.
Lands the forward-reference in the body of cnos.cds/orchestrators/cds-dispatch/SKILL.md (the wake's prompt body, which forward-references this section: "δ's wake-invoked mode is the contract that lands in cnos#467 Sub 5"). The reference dispatch wake is cds-dispatch (cnos#483); δ wake-invoked mode is protocol-agnostic at the framework level — any future dispatch wake (cdr-dispatch, cdw-dispatch) invokes the same δ contract.
Two empirical patterns exist in the wave; the amendment names the destination pattern, citing the empirical pattern as input observation. They are not interchangeable.
| Mode | Driver | Invocation context | Empirical witness |
|---|---|---|---|
| bootstrap-δ | a γ-interface Claude Code session (operator at the loop); γ-the-driver also wears the δ-the-orchestrator hat in this session | δ has a parent session that holds chat-state across role spawns; γ/α/β are spawned as Agent sub-sessions of that parent | cycle/470, cycle/476, cycle/485, cycle/486 (this cycle is one) — observed at .cdd/releases/docs/2026-06-21/{470,476}/ and .cdd/unreleased/{485,486}/ |
| wake-invoked-δ | a single substrate firing of a dispatch wake; δ is the agent the wake-firing starts; no parent session | δ's entire input is the claimed cell's issue body + the cycle branch + .cdd/unreleased/{N}/ tree; chat-state does NOT carry across role spawns | not yet observed in production; lands as a destination contract via Sub 5C (cnos#487) |
The two patterns share the cell-procedure surface (γ scaffolds, α implements, β reviews, δ routes), and bootstrap-δ supplies empirical evidence for what context each role needs. They diverge structurally on one axis: bootstrap-δ has a coordinating session that survives across role spawns; wake-invoked-δ does not. Every contract clause in §9.2–§9.7 is written for wake-invoked-δ. A clause that only works under bootstrap-δ (i.e. requires a parent session's chat-state) is a contract defect — name it as such, do not embed it.
In bootstrap-δ, γ-the-driver implicitly violates the "δ dispatches every role" invariant (§9.3 below) because γ-the-driver is also δ-the-orchestrator. The amendment surfaces this honestly; the production routing sequence separates the two roles.
When a dispatch wake's claim sequence completes (per dispatch-protocol/SKILL.md §2.2 steps 1–5) and the launch step (step 6) hands the claimed cell to the matching package runtime, the package runtime invokes δ wake-invoked mode with five named inputs. δ MUST be able to act on each input by reading the cycle branch state and the named source files; δ MUST NOT depend on any chat-state, environment variable, or session-local memory beyond these five.
| # | Input | Semantics |
|---|---|---|
| 1 | claimed-issue-number | The repository issue number the wake claimed at dispatch-protocol/SKILL.md §2.2 step 4. δ reads this issue's body as the cell-shaped specification per cdd/issue/SKILL.md §"Minimal output pattern". The body's Mode + Gap + Impact + Source-of-truth + Constraints + ACs + Proof/rejection + Cross-references fields are the cell's contract; δ does NOT improvise additions. |
| 2 | protocol identifier | The qualifier identifying which concrete protocol owns this cell (e.g. cds, cdr, future cdw). δ uses this to locate the concrete protocol's selection/lifecycle skills inside the runtime package (input #5 below). The claimed cell's protocol:{P} label is authoritative; the wake guarantees P matches its owning protocol per dispatch-protocol/SKILL.md §3.7. |
| 3 | current main SHA | The repository's main HEAD commit at wake-firing time. This is the base δ uses to compute the cycle branch (cycle/{N} from main@<sha>) and the SHA δ pins in gamma-scaffold.md for "verify-cited-sha against filesystem state" discipline. δ verifies this SHA against the working tree before dispatching γ (see §9.6 R0 step 1). |
| 4 | wake run id | The substrate-emitted identifier for this wake firing. δ records it in the claim trail and surfaces it in return-token comments so operators can correlate cycle progress with the substrate firing that produced it. δ does NOT decode or parse the run id — δ treats it as an opaque identifier the wake supplies. |
| 5 | package-runtime context | The path to the concrete protocol's skills (e.g. for protocol:cds → src/packages/cnos.cds/skills/cds/ covering selection, lifecycle, etc.) plus the framework's own role-skill paths (src/packages/cnos.cdd/skills/cdd/{gamma,alpha,beta,delta,issue,SKILL.md}). δ exposes these as Tier-3-loadable paths to γ/α/β at spawn time; δ does NOT pre-load them itself. |
The five inputs together fully specify the cell: who (1), under what protocol (2), against what repo state (3), in what wake firing (4), with what runtime skills available (5). Anything not on this list — chat history, prior Agent sub-session memory, the operator's local environment — δ MUST NOT depend on.
The production invariant is: δ dispatches every role; γ does not spawn α/β. This is the binding routing rule. γ scaffolds (or closes out) and exits; δ dispatches α; α implements and exits; δ dispatches β; β reviews and exits; δ iterates by re-dispatching α (or γ, if a scaffold-side ambiguity surfaces).
bootstrap-δ collapses γ-the-driver with δ-the-orchestrator and implicitly spawns α/β from the γ-driver session; this is an empirical case, not the destination architecture. Per the operator directive that authored cnos#486: the production wake-invoked routing keeps γ and δ structurally distinct even when both are agent sub-processes — γ produces prompts as scaffold artifacts; δ dispatches each role from the wake-firing's δ-agent.
The discrete sequence:
cycle/{N}); the package-runtime context (Tier-3 paths). γ's job per gamma/SKILL.md §2.5 Steps 3a–3b is to verify the SHA against the working tree, create the cycle branch from main@<sha>, author .cdd/unreleased/{N}/gamma-scaffold.md (with the per-AC oracle list, the source-of-truth table, the α prompt, the β prompt, the scope guardrails, and the friction notes), commit, push, and exit. γ does NOT spawn α; γ writes the α-prompt as a scaffold artifact and returns control to δ..cdd/unreleased/{N}/beta-review.md §R[N-1]. α's job per alpha/SKILL.md §2.1 (dispatch intake), §2.5 (self-coherence), §2.6 (pre-review gate), §2.7 (request review) is to implement, write .cdd/unreleased/{N}/self-coherence.md §R[N], commit, push, append the review-readiness signal, and exit. α does NOT spawn β.beta/SKILL.md §"Phase map" + §"Pre-merge gate" + §"Role Rules" is to walk the AC oracle list independently, write .cdd/unreleased/{N}/beta-review.md §R[N] with verdict + findings, commit, push, and exit. β does NOT spawn α.verdict: iterate, δ re-dispatches α at step 2 with β's findings appended; the cell stays status:in-progress (the wake observes via §9.5 token discipline). If verdict: converge, δ dispatches γ once more for closeouts (γ-closeout per gamma/SKILL.md §2.7) and α/β for their closeouts; then δ writes the status:review return token (§9.6)..cdd/unreleased/{N}/gamma-closeout.md (process-gap audit per gamma/SKILL.md §2.7 triage), and may file follow-up issues for any unaddressed friction. α and β similarly produce their closeouts per their role skills. δ does NOT author closeout content; δ dispatches the role that owns each closeout.Per-role context discipline (no hidden state across spawns):
| Role | Spawn-context — what the role receives |
|---|---|
| γ receives | issue number, protocol id, main SHA, cycle branch name, package-runtime context (Tier-3 paths). On closeout: the converge signal + cycle branch HEAD. |
| α receives | cycle branch HEAD, scaffold path, source-of-truth list, issue body, on R[N≥1] β's findings under .cdd/unreleased/{N}/beta-review.md §R[N-1]. |
| β receives | cycle branch HEAD, scaffold path, α's .cdd/unreleased/{N}/self-coherence.md §R[N], source-of-truth list, issue body. |
The cycle branch + .cdd/unreleased/{N}/ tree carries everything each role needs; no role consults hidden state. Empirical anchor: cycle/470's R1 finding F1 (broken relative-link path in α's prompt template — .cdd/releases/docs/2026-06-21/470/beta-review.md §R1 records the 6-vs-5 dot-segment substantive ambiguity) demonstrated that γ-scaffold-side substantive precision is necessary: without sha-pinned + path-verified scaffolding, α's R0 inherits ambiguity that β must surface as a finding. cycle/476's R1–R3 iteration (.cdd/releases/docs/2026-06-21/476/beta-review.md) demonstrated the same principle in the CI mechanism class: γ scaffold's CI-step preconditions must be filesystem-verified, not assumed. The wake-invoked routing applies this discipline structurally — γ verifies; α implements against verified state; β re-verifies independently.
The wake must be able to observe round progress without reading chat-state or asking the substrate to inspect agent memory. The discipline is: R[N] is wake-observable via the cycle branch state, with issue-comment signals as the human-observable secondary mechanism mapped to dispatch-protocol lifecycle transitions.
v0 pinned mechanism — hybrid (branch-state primary; issue-comment secondary):
| Layer | Mechanism | What it records |
|---|---|---|
| Primary | cycle branch + .cdd/unreleased/{N}/ tree | The branch's HEAD commit reflects the latest role artifact. .cdd/unreleased/{N}/self-coherence.md §R[N] and .cdd/unreleased/{N}/beta-review.md §R[N] are the canonical per-round records. The branch state IS the iteration state — no separate ledger. |
| Secondary | issue comments on the claimed cell | Human-observable convergence signals at the four named lifecycle transitions per dispatch-protocol/SKILL.md §2.4. δ writes a comment at each transition (claim record; β converge; hard block; race release) so operators see cycle progress without walking the branch. |
| Not pinned for v0 | .cdd/unreleased/{N}/*.R{N}.json machine-readable round artifacts | Adds machinery without observable benefit at v0; the branch state + the markdown section headers already give the same observability. A future cycle may pin this if/when a downstream consumer needs machine-readable per-round metadata. |
The per-round artifact set names the wake-observable contract: at R[N], the branch carries the artifacts §9.5 enumerates; the wake confirms round-complete by reading those paths. R[N] is not a token δ writes to a separate ledger — R[N] is the branch state at the moment the round's artifacts are committed and pushed.
Why this is wake-observable without chat-state: the substrate can (and does, on every wake firing) git fetch origin cycle/{N} and git ls-tree -r origin/cycle/{N} .cdd/unreleased/{N}/ to read the round-state. The substrate can read issue comments via the substrate's issue API to surface the lifecycle signals. Neither requires reading agent memory; both work from a fresh wake firing with no prior session context.
Empirical anchors: cycle/470 ran R0 → R1 → R2 (.cdd/releases/docs/2026-06-21/470/self-coherence.md + beta-review.md both carry R0/R1/R2 section headers — branch-state record of each round). cycle/476 ran R0 → R1 → R2 → R3 (.cdd/releases/docs/2026-06-21/476/); the 3-round class-trap recurrence per cnos#478 surfaced the requirement that R[N] must be wake-observable. Without R[N] visibility on the branch, the wake cannot distinguish a CI mechanism flake (mechanical) from a substantive review iteration (doctrinal). cycle/485 ran R0 only (.cdd/unreleased/485/ — first R0-converge under the cnos#478 mechanical-injection discipline; empirical evidence that the per-CI-step audit format absorbs the bash-e class-trap class).
.cdd/unreleased/{N}/)At each R[N] boundary, the cycle branch MUST carry the artifacts named below. The wake confirms a round complete by reading these paths; the matching package's release-time tooling (per cdd/SKILL.md artifact contract) lifts them into .cdd/releases/docs/<date>/{N}/ on merge.
Seven canonical artifact classes per cnos.cds/orchestrators/cds-dispatch/SKILL.md frontmatter wake.output.artifact_class_taxonomy:
| Boundary | Required artifacts at .cdd/unreleased/{N}/ |
|---|---|
| R0 | gamma-scaffold.md (authored by γ; the per-AC oracle list, source-of-truth table, α prompt, β prompt, scope guardrails, friction notes) |
| R[N≥1] | gamma-scaffold.md (unchanged from R0 unless a scaffold-side ambiguity surfaces) + self-coherence.md with appended §R[N] section (authored by α; AC verification + review-ready signal) + beta-review.md with appended §R[N] verdict (authored by β; verdict + findings if any) |
| converge | gamma-scaffold.md + self-coherence.md (all §R[N] sections; converge-ready signal at the last) + beta-review.md (all §R[N] sections; final verdict: converge) + alpha-closeout.md (authored by α; cycle-level retrospective per alpha/SKILL.md §2.8) + beta-closeout.md (authored by β; review-side retrospective) + gamma-closeout.md (authored by γ; process-gap audit per gamma/SKILL.md §2.7) + optionally post-release-assessment.md (PRA — scope-dependent per the cds-dispatch manifest's artifact_class_notes: "only cycles with explicit retrospective value carry it") |
R[N≥1] iteration is an internal cell loop — the cell stays status:in-progress while β-α loops continue (per cds-dispatch/SKILL.md §"Lifecycle transitions" and dispatch-protocol/SKILL.md §3.6). External lifecycle states (status:changes) are the operator/planner's authority post-status:review; β iteration is NOT a status:changes transition.
On converge, after β writes the final verdict: converge and the three closeouts land on the branch, δ writes the status:review return token (§9.6).
δ writes back to the wake at four named lifecycle transitions; these map exactly onto dispatch-protocol/SKILL.md (cnos#454) §2.4 and cnos.cds/orchestrators/cds-dispatch/SKILL.md frontmatter wake.responsibilities #5. δ MUST NOT invent new transitions; δ consumes the dispatch-protocol's transition set.
| Return token | Wake-observable mechanism | When δ writes it |
|---|---|---|
| status:review | a request for the status:in-progress → status:review transition on the claimed cell (cn issues fsm evaluate --issue {N} --apply, cnos#569 Phase 2 — δ does NOT write the label directly) + an issue comment naming the cycle-PR URL | After β's verdict: converge lands on the branch and all closeouts are present (§9.5 converge boundary). δ opens (or updates) a cycle-PR scoped to the claimed cell, ensures REVIEW-REQUEST.yml and the closeout matter exist, then runs cn issues fsm evaluate --issue {N} --apply — the FSM applies status:review only when its guards pass (PR and/or commits beyond base, plus REVIEW-REQUEST.yml) — and writes the PR-URL comment. δ still decides when to request the transition; the FSM decides whether the guards allow it. |
| status:blocked + reason | label transition status:in-progress → status:blocked + an issue comment naming the block class (external dependency, missing precondition, infra failure, irrecoverable substrate timeout) | When δ encounters a hard block mid-cycle: a precondition the wake-invoked mode cannot satisfy (e.g. γ's SHA-pin verification fails against the working tree; a referenced source file is broken on main; the AC oracle is genuinely ambiguous in a way the scaffold did not resolve). The block-reason comment is verbose enough that the operator can decide whether to repair-and-re-dispatch or to escalate. |
| claim release (race) | label transition status:in-progress → status:todo + an issue comment naming the race detection per dispatch-protocol/SKILL.md §2.2 step 5 | When δ's first action — re-verify the claim is still valid — surfaces drift. This is the wake's own race-guard; δ honors it by releasing the claim without invoking γ. (In practice this fires inside the wake's claim sequence, before δ is fully spawned; the contract names it for completeness because a delayed re-verify by δ at spawn time is a defensive option.) |
| cycle-PR URL | included in the status:review transition comment; not a separate token | δ writes the PR URL into the same comment that announces the converge transition so operators / observers have a single discoverable artifact. |
Carve-out — status:changes is EXTERNAL (with mechanical translator). The dispatch wake does NOT transition out of status:review and δ does NOT write status:changes from status:in-progress. status:changes is the operator/planner's authority on review-rejection AFTER the cell shipped to status:review (per cds-dispatch/SKILL.md §"Lifecycle transitions"; dispatch-protocol/SKILL.md §2.4). β iteration is internal — the cell stays status:in-progress during β-α loops; only β converge advances the cell out of that state. Future readers must not conflate β iteration with external rejection; the four return tokens above are the complete set δ writes.
Reconciliation with cn cell return (cnos#500). cn cell return --verdict iterate (or --verdict reject) applies the status:review → status:changes transition on behalf of the operator's stated verdict. The operator is still the authority; cn cell return is the mechanical translator of that authority into a label transition. This does NOT change the carve-out: the dispatch wake still never writes status:changes; δ's four return tokens are still the complete set δ writes during a wake-invoked cycle. cn cell return is an operator-facing CLI command, not a wake-internal mechanism — the operator invokes it (via HI) after reading the PR; the wake is not involved. See §9.10 for the resumed-from-changes routing shape that follows.
δ wake-invoked mode operates within constraints supplied by the substrate firing. δ HONORS these constraints; δ does NOT emit substrate-specific encoding for them. The renderer (per wake-provider/SKILL.md §3.3 substrate-leakage rule + the package-vs-renderer authority split) is the surface that maps these logical constraints onto the concrete substrate (cn install-wake per cnos#476 + cnos#485).
| Constraint | Logical statement δ honors | Where the substrate encodes it |
|---|---|---|
| Substrate timeout horizon | The wake firing has a per-firing time horizon; δ assumes the cell completes (or reaches a state-stable boundary at a R[N] artifact-committed boundary) within one substrate firing. δ does NOT plan multi-firing continuations in v0; cells too large for one firing surface as status:blocked with a block-class comment naming the timeout class. | Renderer authority (renders the substrate's timeout field per substrate convention). |
| Per-protocol concurrency group | At most one wake firing per (repository × wake protocol) at a time; concurrent firings of the same dispatch wake are serialized by the substrate's concurrency mechanism (per dispatch-protocol/SKILL.md (cnos#454) §2.3 layer 1). δ assumes serialization; δ does NOT serialize internally. Cross-protocol firings (e.g. cds-dispatch and a future cdr-dispatch) parallelize naturally because each owns its own concurrency group. | Renderer authority (maps to the substrate's concurrency primitive). |
| One-claim-per-firing | One substrate firing claims at most one cell (per dispatch-protocol/SKILL.md (cnos#454) §3.2). δ runs the one claimed cell to a state-stable boundary; δ does NOT pick up a second cell within the same firing. | Wake claim-sequence authority (per dispatch-protocol/SKILL.md §2.2). |
v0 simplifying assumption: the wake fires once and the cell completes (or reaches a state-stable boundary) within one substrate firing. The state-stable boundaries are exactly the R[N] artifact-committed boundaries enumerated in §9.5 (R0 / R[N≥1] / converge). Cells that cannot reach one of these within the substrate's per-firing horizon transition to status:blocked with a block-class comment per §9.6; future enhancements (cron-staggered continuations, long-running cell modes) are deferred to a post-v0 wave.
This skill is substrate-agnostic per the wake-provider/SKILL.md §3.3 substrate-leakage rule applied to cnos.cdd's δ skill. The §9.2–§9.7 contracts name what δ does logically; they do NOT emit substrate-specific syntax (no workflow YAML, no runs-on: fields, no GITHUB_TOKEN / secret bindings, no ${{ }} interpolations, no claude-code-action references). Substrate decisions are renderer authority (cnos#476 + cnos#485 + cnos#487); δ skill MUST NOT pin them.
For v0, the substrate is GitHub Actions and the renderer is cn install-wake; when the dispatch wake's firing instantiates δ, the wake's prompt body (per cds-dispatch/SKILL.md) cites this section as the contract δ honors. A future substrate replacement (different scheduler; different runner; different agent-execution carrier) would change the renderer and the wake-template; this skill section would be unchanged.
The single descriptive carve-out in this §9 is this paragraph: it names "GitHub Actions" + "workflow" + "claude-code-action" descriptively to anchor the reader, not to pin the contract. The contract surfaces (§9.2 input contract; §9.3 routing sequence; §9.4 iteration discipline; §9.5 artifact contract; §9.6 return tokens; §9.7 constraints) are substrate-agnostic; any substrate that supplies (a) a fire-once firing horizon, (b) a serialize-per-protocol concurrency primitive, (c) a one-claim-per-firing claim mechanism, and (d) an issue-comment + label-transition API surface, can carry the contract. The framework owns the contract; the renderer owns the substrate emission.
cnos.core/skills/agent/dispatch-protocol/SKILL.md (cnos#454) — claim sequence (§2.2), concurrency discipline (§2.3), lifecycle transitions (§2.4), drift handling (§2.6). Wake-invoked-δ consumes the claim sequence's output and honors its lifecycle transitions; the contract above maps each return token (§9.6) to a transition this skill defines.cnos.core/skills/agent/wake-provider/SKILL.md (cnos#470) — substrate-agnosticism doctrine (§3.3 substrate-leakage rule); cited as the source for §9.8 above.cnos.cds/orchestrators/cds-dispatch/SKILL.md (cnos#483) — the reference dispatch-shape wake; its frontmatter wake: block is the dispatch-shape manifest. wake.output.artifact_class_taxonomy is the canonical artifact set §9.5 matches; wake.responsibilities enumerates the lifecycle transitions §9.6 consumes.cnos.cds/orchestrators/cds-dispatch/SKILL.md (cnos#483) is the wake's prompt body; it forward-references this section; the reference resolved to a landed citation once cnos#486 merged.cdd/issue/SKILL.md — cell-shaped issue contract; δ reads the claimed cell's issue body against this skill's §"Minimal output pattern" (§9.2 input #1).cdd/gamma/SKILL.md — γ role contract; wake-invoked routing dispatches γ per its §2.5 (scaffold) and §2.7 (closeout). δ does not restate γ-side mechanics here.cdd/alpha/SKILL.md — α role contract; wake-invoked routing dispatches α per its §2.1 (intake), §2.5 (self-coherence), §2.6 (pre-review gate), §2.7 (request review), §2.8 (close-out).cdd/beta/SKILL.md — β role contract; wake-invoked routing dispatches β per its Phase map + Pre-merge gate + Role Rules..cdd/releases/docs/2026-06-21/470/ — cycle/470 (Sub 2 wake-provider). R1 F1: broken relative-link path in α's prompt template — γ-scaffold-side substantive ambiguity. Cited in §9.3 as evidence that γ's SHA-pin + path-verify discipline is necessary for wake-invoked routing..cdd/releases/docs/2026-06-21/476/ — cycle/476 (Sub 3 renderer v0). R1–R3 (3 rounds): missing set -o pipefail + grep -c exit-1-on-zero-matches class-trap (per cnos#478). Cited in §9.4 as evidence that R[N] iteration must be wake-observable on the branch..cdd/unreleased/485/ — cycle/485 (Sub 5A renderer extension). R0-only converge under cnos#478 mechanical-injection discipline. Cited in §9.4 as evidence that the per-CI-step audit format absorbs the bash-e class-trap class.cds-dispatch activation_state to live, renders + commits the substrate artifact for the cds-dispatch wake, and runs a real protocol:cds smoke cell. cnos#487 consumes this section as the contract its smoke cell verifies.This subsection names the resumed-from-changes wake-invoked mode shape: what δ does when a previously-converged cell returns from status:changes and re-enters the cycle.
Trigger. The operator has read the cell's PR at status:review, returned an iterate or reject verdict via cn cell return, and re-armed the cycle via cn cell resume. The issue now carries status:changes. On the next wake firing that claims the cell (under dispatch:cell + protocol:{P} + status:todo, after the operator re-labels from status:changes → status:todo to re-authorize dispatch), δ receives a cell with a prior-round artifact history — this is the resumed-from-changes shape.
How this differs from a first-claim cell. A first-claim cell has only gamma-scaffold.md on its cycle branch. A resumed-from-changes cell has the full prior-round artifact set: gamma-scaffold.md (R0, unchanged) + self-coherence.md (all §R[0..N] sections, with §R[N+1] header appended by cn cell resume) + beta-review.md (all §R[0..N] verdicts) + operator-review.md (the HI-authored typed verdict artifact) + optionally prior closeout artifacts. δ MUST detect this shape and route accordingly.
Detection. δ detects the resumed-from-changes shape by reading the cycle branch state at wake-firing time. Indicators (any one is sufficient):
self-coherence.md contains two or more §R[N] section headers (R0 plus at least one prior implementation round)operator-review.md exists at .cdd/unreleased/{N}/operator-review.mdstatus:changes → status:todo transition occurred (branch history evidence; not always available to δ)Input contract (resumed-from-changes). In addition to the five standard inputs (§9.2), δ receives:
operator-review.md — the HI-authored cn.operator-review.v1 artifact carrying the operator's findingsself-coherence.md §R[0..N] sections — α's prior-round AC verification and review-ready signalbeta-review.md §R[0..N] verdicts — β's prior-round review findingsR[N+1] increment — the next round number, determined from the §R[N+1] header appended by cn cell resume (or computed by δ if cn cell resume was not invoked)Routing sequence (resumed-from-changes). Follows §9.3 with modifications for the resumed shape:
gamma-scaffold.md; operator-review.md; prior self-coherence.md (with §R[N+1] header); prior beta-review.md §R[0..N]. α's job: address operator-review.md's findings[]; append self-coherence.md §R[N+1] (AC verification + review-ready signal); commit, push, append readiness signal; exit. α does NOT spawn β.gamma-scaffold.md; α's self-coherence.md §R[N+1]; operator-review.md; issue body. β's job: walk the AC oracle list independently; append beta-review.md §R[N+1] with verdict + findings; commit, push, exit. β does NOT spawn α.iterate → re-dispatch α at R[N+2]; converge → dispatch γ for closeout amendment.gamma-closeout.md (per gamma/SKILL.md §2.7) naming the R[N+1] round, the operator findings addressed, and the recovery path. γ DOES NOT rewrite prior closeout sections; γ appends an amendment section.γ closeout amendment shape. On converge at R[N+1], γ's closeout amendment appends a §R[N+1] amendment section to gamma-closeout.md carrying:
operator-review.md findings were addressed (by finding id)Preserved invariants. The resumed-from-changes shape MUST preserve:
cycle/{N} branch — not recreated, not rebased onto main during resume (only δ may rebase per §9.3 rules; cn cell resume does not rebase).cdd/unreleased/{N}/ artifact directory — not replaced, not emptiedgamma-scaffold.md — unchanged (R0 γ artifact; reflects the original cell contract)self-coherence.md §R[0..N] sections — preserved; only §R[N+1] is appendedbeta-review.md §R[0..N] verdicts — preserved; only §R[N+1] is appendedoperator-review.md — HI-owned; not modified by α/β/γReconciliation with §9.6 carve-out. status:changes is still the operator's authority; the resumed-from-changes shape does not change that. What changes is the return path: the operator uses cn cell return (the mechanical translator of the operator's verdict) to initiate the transition, then re-authorizes dispatch by applying status:todo. δ's wake then claims the cell in the resumed-from-changes shape. The dispatch wake still never writes status:changes; the four return tokens in §9.6 are still the complete set δ writes during a wake-invoked cycle.
Empirical anchor. cycle/497 R1 is the first empirical witness for the resumed-from-changes shape — executed manually (bootstrap-exception path: HI applied corrections inline as dd819f00 rather than via cn cell return/cn cell resume). The recovery sequence (HI files operator-review.md; α R1 takes ownership; β R1 takes ownership; γ R1 takes ownership) is the manual stand-in for the wake-invoked routing defined here. The degraded_recovery: human_interface_applied_operator_patch declaration in .cdd/unreleased/497/gamma-closeout.md §5 records the bootstrap exception. cnos#500 lands this subsection; future cycles with iterate verdicts use the mechanical path.
Cross-references.
cnos.cdd/skills/cdd/operator-review/SKILL.md — cn.operator-review.v1 schema; degraded_recovery declaration schema; HI authoring rules.cnos.core/orchestrators/agent-admin/hi-contract.md — HI behavioral contract; prohibited surfaces.src/go/internal/cell/ — Go implementation of cn cell return (label transition) and cn cell resume (cycle re-arm)..cdd/unreleased/497/operator-review.md — canonical first-use cn.operator-review.v1 witness..cdd/unreleased/497/gamma-closeout.md §5 — canonical first degraded_recovery declaration.This subsection names a second, structurally distinct resume shape, sibling to §9.10: what δ does when a claimed status:todo cell carries pre-existing cycle/{N} matter (a branch + an open draft PR) checkpointed by the recovery scanner's own mechanical reversion, not by an operator rejection. This is the AC3/AC1 "resume, not defer" behavior cnos#630 requires: the partial-matter in-progress wedge fix (transitions.json's propose_status_todo_with_matter rule; src/packages/cnos.issues/commands/issues-fsm/scan.go) mechanically moves a dead-run-with-checkpointed-matter cell back to status:todo specifically so the NEXT claim resumes from it — but only if δ actually recognizes the shape instead of treating the pre-existing branch/PR as an unexplained anomaly.
Trigger. A prior wake firing claimed this cell, ran to some partial point (at minimum a cycle/{N} branch + a checkpointed draft PR, per the cnos#591 finalizer), and its run died before REVIEW-REQUEST.yml was written. A later scheduled scan (cn issues fsm scan --apply) observed the dead run + checkpointed matter + no REVIEW-REQUEST.yml and mechanically reconciled status:in-progress -> status:todo, preserving the branch/PR and posting an audit-note comment naming this as a MECHANICAL reversion (transitions.json's propose_status_todo_with_matter rule reason text, posted verbatim by scan.go's existing reconciliation-comment path). The cell is now status:todo again, and the next dispatch-wake firing that scans the open-issue queue claims it — this is the resumed-from-mechanical-reversion shape.
How this differs from §9.10's resumed-from-changes shape. Both shapes hand δ a cell whose cycle/{N} branch already carries prior-round matter, but the cause and the correct response differ:
| §9.10 resumed-from-changes | §9.11 resumed-from-mechanical-reversion (this section) | |
|---|---|---|
| Cause | Operator read the PR at status:review and returned iterate/reject via cn cell return | The prior run died mid-cycle (infra failure, timeout) before reaching status:review; the recovery scanner's own reconciliation requeued it |
| Evidence on the branch | operator-review.md present; self-coherence.md carries §R[N] for N≥1; explicit rejection findings | No operator-review.md; the branch may carry only a partial R0 (e.g. gamma-scaffold.md alone, or gamma-scaffold.md + a partial self-coherence.md); the issue carries the scanner's "MECHANICAL reversion" audit-note comment, not an operator verdict |
| What "resume" means | Address operator-review.md's findings; append a NEW §R[N+1] round | Continue the SAME round from wherever it stopped — do not re-scaffold, do not treat the partial state as a rejection to address |
Repair-contract machinery (cds-dispatch/SKILL.md §Repair re-entry preflight Steps B–E) | Does not apply (no status:changes involved) | Does not apply — Step A of that preflight explicitly checks for and excludes this shape (run_class: resumed_from_matter) before ever reaching the repair-re-entry classification, precisely so this shape's absence of a rejection is not mistaken for one |
Detection. δ detects the resumed-from-mechanical-reversion shape from the same five-input contract §9.2 already supplies — no new Go surface or additional wake-to-δ input is required. cn issues fsm evaluate --issue {N} --json (already run at claim time per cds-dispatch/SKILL.md §"Claim mechanism") exposes branch_exists, pr_exists, and cdd_artifacts (FactSnapshot, src/packages/cnos.issues/commands/issues-fsm/snapshot.go) — δ reads the cycle branch state directly (git ls-tree -r origin/cycle/{N} .cdd/unreleased/{N}/) at spawn time, exactly as §9.4's "wake-observable without chat-state" mechanism already does for R[N] tracking. Indicators (any one is sufficient, and cds-dispatch/SKILL.md §Repair re-entry preflight Step A already runs this check before δ is even invoked):
cycle/{N} branch and/or an open PR already exist for this issue at claim time (branch_exists/pr_exists true in the fresh FactSnapshot)propose_status_todo_with_matter rule's reason text)operator-review.md is present and NO prior status:changes label-history exists (the negative check that rules out §9.10 instead)Routing sequence (resumed-from-mechanical-reversion). Follows §9.3 with one structural difference from a first-claim cell: δ does not unconditionally dispatch γ for a fresh R0 scaffold.
.cdd/unreleased/{N}/ on the resumed cycle/{N} branch. If gamma-scaffold.md already exists, δ does NOT overwrite it and does NOT dispatch γ for a new R0 scaffold — the existing scaffold is still the cell's contract.alpha/SKILL.md §4 "Resumption": if only gamma-scaffold.md exists, dispatch α exactly as a first-claim cell would (α's own resumption protocol, §4, handles a partially-written self-coherence.md if one exists); if self-coherence.md already carries a review-readiness signal with no beta-review.md, dispatch β directly. δ never re-dispatches γ for a fresh scaffold when one is already present and no operator rejection occurred.Preserved invariants. Identical in spirit to §9.10's list, restated for this shape's cause:
cycle/{N} branch — not recreated, not discarded, not rebased onto main during resume (the cnos#368 protection this cell's own fix restates for the reconciler's own action)cn cell finalize's own idempotence keeps re-invocation safe if a later step needs to re-checkpoint.cdd/unreleased/{N}/ artifact directory — not emptied; any partial R0 artifacts already present are read, not discardedgamma-scaffold.md, if present — unchanged; δ does not re-author itCross-references.
cnos.cds/orchestrators/cds-dispatch/SKILL.md §"Claim mechanism" (cnos#630 paragraph after step 9) — the wake-side claim behavior this section's routing continues from; §"Repair re-entry preflight" Step A — the run_class: resumed_from_matter classification that keeps this shape from being misrouted into the repair-contract machinery.src/packages/cnos.cds/skills/cds/fsm/transitions.json — the propose_status_todo_with_matter rule (in-progress state) that produces this shape's trigger condition.src/packages/cnos.issues/commands/issues-fsm/scan.go — the recovery scanner that applies the rule and posts the audit-note comment this section's detection reads.This subsection is not a resume shape like §9.10/§9.11 — it names a standing doctrine constraint that holds on every wake-invoked-δ cycle, first-claim or resumed: the cell carries no substrate identity and no hub-state scope. The wake/substrate owns identity, channel logs, and reporting; δ and the roles it dispatches (γ/α/β) do not.
The rule. Cell-execution cognition — δ itself, and every role δ dispatches (γ/α/β) — operates entirely on the five inputs §9.2 already names (claimed-issue-number, protocol identifier, current main SHA, wake run id, package-runtime context). It does NOT perform a full activate/SKILL.md six-step activation (Kernel → CA skills → Persona → Operator → hub state → identity confirmation), does NOT load <hub>/spec/PERSONA.md or <hub>/spec/OPERATOR.md, does NOT survey hub state (dependency manifest, reflections, thread surfaces), and does NOT read or write .cn-{agent}/ — including .cn-{agent}/logs/, the admin wake's channel-log writer-locality per AGENT-ACTIVATION-LOG-v0 §0. The corresponding wake-side statement of this same rule lands in cnos.cds/orchestrators/cds-dispatch/SKILL.md §"Identity and activation" (cnos#626): the dispatch wake's own minimal self-identification (which wake, which protocol) is manifest-declared — supplied by the renderer via the {agent} variable and bot-account binding — not file-discovered by reading Persona/Operator at runtime.
§9.2's silence is intentional, not an oversight. §9.2's five-input contract already omits Persona, Operator, and hub-state from what a dispatch wake hands δ at invocation — it names claimed-issue-number, protocol identifier, current main SHA, wake run id, and package-runtime context, full stop. Before cnos#626, that omission could be read either way: an intentional narrowing, or an incomplete first pass nobody had gotten around to widening. cnos#626 makes the reading explicit: the absence is doctrine, not debt. A cell that needed Persona/Operator/hub-state to do its job would be evidence the cell-execution/substrate-identity boundary itself is wrong, not evidence that §9.2's contract is missing a row. No future amendment should add a sixth "hub state" or seventh "Persona" input to §9.2's table without first overturning this subsection.
Who owns what. The wake/substrate (the dispatch wake's claim sequence, the FSM transitions it requests, the admin wake's channel-log and cycle-complete reporting) owns: substrate identity (which bot account, which {agent} binding), channel logs (.cn-{agent}/logs/, admin-wake writer-locality per AGENT-ACTIVATION-LOG-v0 §0), and operator-facing reporting (claim comments, return-token comments per §9.6, the admin wake's class: cycle-complete entry). Cell-execution cognition (δ/γ/α/β) owns: producing code, tests, docs, and reviews, and landing the .cdd/unreleased/{N}/ artifact set — matter, not identity or reporting. A cell that finds itself needing to know "who is Sigma" or "what did the last channel entry say" has stepped outside its own boundary; that need routes to the wake/substrate layer, not into the cell's own reading list.
Scope note (AC3/AC4 not covered here). This subsection names the doctrine boundary (AC1) and the input-contract omission (part of AC2). It does NOT retire the mechanical enforcement that currently backstops a narrower slice of the same boundary — the dispatch_activation_log_write_violation write-fence (cds-dispatch/SKILL.md §"Disallowed surfaces") stays in place. Removing the checkout-level capability to see .cn-{agent}/logs/ at all (rather than merely being instructed not to read/write it) is a separate, not-yet-bounded mechanism; see cnos#626's issue body and .cdd/unreleased/626/self-coherence.md §"AC3/AC4" for the candidate mechanisms and why they are deferred to the operator rather than implemented in this cell.
Cross-references.
cnos.cds/orchestrators/cds-dispatch/SKILL.md §"Identity and activation" (cnos#626) — the wake-side prompt-body statement of this same rule; this subsection is its cnos.cdd-side doctrine counterpart.cnos.core/skills/agent/activate/SKILL.md §2.1 — the six-step general agent-at-a-hub procedure this subsection narrows the audience of, without changing the procedure itself; the admin wake and any true agent-at-a-hub activation still run all six steps.docs/reference/conventions/AGENT-ACTIVATION-LOG-v0.md §0 — channel-log writer-locality; the admin wake owns .cn-{agent}/logs/, cell-execution cognition does not read or write it.This subsection names a third, structurally distinct resume shape, sibling to §9.10 and §9.11: what δ does when a claimed status:todo cell carries an operator (or CAP-authorized) comment authorizing a new bounded AC scope on an issue whose prior cycle round(s) already converged and merged — not a rejection (§9.10) and not a mechanically-checkpointed dead run (§9.11).