---
name: operator
description: δ role in CDD. Owns external gates, routing, and override authority during an active triad cycle.
artifact_class: skill
kata_surface: embedded
governing_question: What does the operator do — and not do — during an active CDD cycle?
visibility: internal
parent: cdd
triggers:
  - operator
  - dispatch
  - gate
  - unblock
scope: role-local
inputs:
  - γ dispatch prompts
  - external gate requests from α/β/γ
  - cycle state (issue, branch, .cdd/unreleased/{N}/, CI)
outputs:
  - routed prompts to agent sessions
  - external gate executions and confirmations (push on β's behalf, tag, release, deploy, issue filing)
  - override declarations when needed
requires:
  - active CDD cycle exists
  - γ has produced dispatch prompts
calls:
  - gamma/SKILL.md
  - harness/SKILL.md
---

# Operator (δ)

## Core Principle

**Coherent δ operation routes work, holds gates, and stays out of the triad's reasoning.**

δ is not a fourth triad role — δ is not scored on coherence axes. δ owns what agents cannot: external platform actions, session routing, and override authority. The failure mode is **invisible meddling** — the operator adjusts implementation, review, or coordination reasoning without declaring an override, and the triad's coherence record no longer matches what actually happened.

> **First-time operator?** Before running the algorithm below, ensure the repository has been activated under CDD.
> See [`cdd/activation/SKILL.md`](../activation/SKILL.md) for the one-time bootstrap: `.cdd/` scaffold, version
> pin, identity convention setup, and the §24 verification command that confirms activation is complete.

## Algorithm

1. **Dispatch γ** — δ dispatches γ via the harness; γ reads the issue, creates the cycle branch, and produces α/β prompts. See `harness/SKILL.md` §1 for invocation mechanics.
2. **Dispatch α** — δ dispatches α via the harness with the prompt γ produced; α implements on the cycle branch and exits after signaling review-readiness.
3. **Dispatch β** — δ dispatches β via the harness with the prompt γ produced; β reviews, merges, writes β close-out, and exits.
4. **Re-dispatch α for fix rounds** (when β returns RC) — δ dispatches α via the harness with the fix-round re-dispatch prompt (`cnos.cds/skills/cds/CDS.md` §"Coordination surfaces"; prompt format in §5.2 of this file); α fixes findings, appends fix-round to self-coherence.md, exits.
5. **Re-dispatch α for close-out** (when γ requests after β merge) — δ dispatches α via the harness with the close-out re-dispatch prompt (`cnos.cds/skills/cds/CDS.md` §"Coordination surfaces"; prompt format in §5.2 of this file); α writes alpha-closeout.md, commits to main, exits. **This step is mandatory when γ requests it.** γ cannot complete the closure gate without alpha-closeout.md.
6. **Gate** — execute external actions: push main, tag, release, branch deletes. **Do not tag/release before `gamma-closeout.md` exists on main.** Disconnect-release mechanics live in [`release-effector/SKILL.md`](../release-effector/SKILL.md) (Phase 4c of cnos#366, cycle/399); see §3.4 below for the doctrinal frame. **δ blocks release completion until CI is green** (or operator explicitly accepts a known pre-existing failure per the release-effector recovery runbook).
7. **Override** — reassign roles or redirect scope only with an explicit declaration. The override doctrine (override is a degraded boundary action, never rewrites V's verdict, requires a structured override block when proceeding against a non-PASS verdict) lives in [`delta/SKILL.md`](../delta/SKILL.md) §3; this step is operator-as-coordinator routing the override declaration through the cycle.

δ runs one role at a time. This keeps memory pressure low (single process per role), gives δ direct visibility into each session via the observability stream (`harness/SKILL.md` §2), and isolates failures — if α dies, δ retries α without losing γ or β state.

---

## Git identity for role actors

The canonical identity form (`{role}@{project}.cdd.cnos`, with the `{role}@cdd.cnos` elision for the cnos project) and the worktree-aware identity-write discipline live in `harness/SKILL.md` §3 "Git identity for role actors." δ ensures each role-actor's identity is set per that contract before any commits land on the cycle branch.

---

## 1. Route

### 1.1. Dispatch γ first

δ dispatches γ. γ reads the issue, creates the cycle branch, and returns α/β prompts to δ. γ does not execute dispatch — δ does.

### 1.2. Dispatch α and β sequentially

δ dispatches α, waits for completion, then dispatches β. One role at a time.

The invocation shell, observability flags, and permission-mode requirement are codified in `harness/SKILL.md` §1 (Dispatch invocation) and §2 (Dispatch observability contract). δ honors that contract; this section names the routing discipline.

- ❌ Rewrite the prompt to add constraints or context γ didn't include
- ✅ Deliver the prompt verbatim to the dispatched session (harness contract)
- ❌ Run α and β concurrently or nest them inside γ's session
- ✅ Run one role at a time, inspect artifacts between dispatches
- ✅ Name the agent-to-role mapping before delivering prompts

---

## 2. Wait

### 2.1. Do not poll internal work

Once dispatched, the triad runs. The operator does not need to monitor branch diffs, `.cdd/unreleased/{N}/` files, or CI runs — γ owns that.

The operator's wake-up signals are:

- **γ requests an external gate** (push on β's behalf, tag push, release, deploy, issue filing, auth action)
- **γ requests an unblock decision** (design ambiguity, scope question, env constraint)
- **γ declares cycle closure** and names deferred outputs that need operator action
- **An agent session dies or stalls** (no activity for an unexpected duration)

Between these signals, the operator's correct action is nothing.

- ❌ Check the branch every 30 minutes and suggest changes (role leak into β)
- ❌ Heartbeat reveals cycle state (tag missing, branches exist) → δ acts on it (observation is not a gate request)
- ✅ Wait for γ to surface a gate or decision request
- ✅ Heartbeat reveals cycle state → δ notes it, waits for γ

### 2.2. Subscribe to the issue

Poll the issue and cycle branches for activity using the same transition-only pattern as the triad (`cnos.cds/skills/cds/CDS.md` §"Coordination surfaces" → §"Polling primitives"). δ polls less frequently than γ — the wake-up signals are coarser (gate requests, not per-commit state). 5-minute interval is sufficient for δ; γ owns the tight loop.

The polling loop mechanics (issue-activity poller, multi-branch poller with reachability re-probe) live in `harness/SKILL.md` §5 (Polling and wake-up). δ uses those forms under `Monitor` or equivalent. Canonical cycle branches are `origin/cycle/{N}` (per `cnos.cds/skills/cds/CDS.md` §"Development lifecycle" → §"Branch rule", since #287); the pre-#287 `'origin/claude/*'` glob is warn-only / retrospective per harness §5.3.

---

## 3. Gate

> **δ-as-role boundary policy lives in [`delta/SKILL.md`](../delta/SKILL.md).** This section retains the gate-policy doctrine that `operator/SKILL.md` is authoritative for (the gate-action confirmation protocol, the request-vs-observation discipline, the operator-as-coordinator routing). The role-policy that governs *whether* and *when* gate actions fire — δ as sole tag-author, gate-fires-on-request-not-observation, the BoundaryDecision enumerants, the override-as-degraded-action doctrine, the verdict-vs-decision distinction — lives in `delta/SKILL.md` §1 "Outward membrane" and §3 "Override." **Dispatch-coordinator mechanics** (the `claude -p` / `cn dispatch` invocation, observability flags, worktree management, identity discipline) live in [`harness/SKILL.md`](../harness/SKILL.md) per Phase 4b of cnos#366. **Release-effector mechanics** (the single-command release script invocation, post-push CI polling, the recovery runbook, merged-branch deletes) live in [`release-effector/SKILL.md`](../release-effector/SKILL.md) per Phase 4c of cnos#366 (cycle/399).

### 3.1. External actions the operator executes on δ-the-role's authority

The actions in this table require platform permissions agents may lack. **δ-as-role authorises** these actions per [`delta/SKILL.md`](../delta/SKILL.md) §1.1; operator-as-coordinator dispatches them on request from γ, β, or α-via-γ:

| Action | Trigger | Who requests |
|--------|---------|-------------|
| Pre-merge gate validation | Before authorizing β merge, run `scripts/validate-release-gate.sh --mode pre-merge` to verify cycle artifacts exist and are well-formed. See `cnos.cds/skills/cds/CDS.md` §"Artifact contract" → §"Ownership matrix" and `gamma/SKILL.md` §2.10. | γ |
| Push β-approved merge to main | β runs `git merge` — δ only pushes when β cannot execute the push directly (env/auth constraint). This is execution of β's integration authority, not δ approval. | β or γ |
| Release-boundary preflight | After β merge + close-outs + γ PRA, δ verifies merge commit, release artifacts, tag/deploy preconditions, and platform readiness. Proceed / request changes / override. See `cnos.cds/skills/cds/CDS.md` §"Development lifecycle" → §"Step table" Step 9 (δ gate). | γ |
| Tag push + release | After δ preflight confirms and γ closes the cycle. **δ is sole tag-author** — β does not tag; only δ creates tags per cycle (role-policy: `delta/SKILL.md` §1.1) | γ |
| Branch delete | Cycle closed, merged branches | γ |
| Issue filing on external repos | Cross-project dependency | γ |
| Force push | Rebase required with env constraints | α via γ |
| Auth refresh | Token/permission expiry | any role via γ |

### 3.2. Execute on request, not on observation

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. (Role-policy framing: [`delta/SKILL.md`](../delta/SKILL.md) §1.2.)

- ❌ Heartbeat shows tag not pushed → δ pushes it (role leak: δ decided the gate, not γ)
- ❌ "β asked me to push the merge but I think we should wait for one more review"
- ✅ γ requests tag push → δ pushes it and confirms
- ✅ If you disagree with a gate request, declare an override per [`delta/SKILL.md`](../delta/SKILL.md) §3

### 3.3. Report completion

After executing a gate action, confirm to the requesting role that the action completed. (Role-policy framing: [`delta/SKILL.md`](../delta/SKILL.md) §1.3.)

- ❌ Execute silently and assume the triad will notice
- ✅ "Tag pushed: `git push origin 3.59.0` — confirmed on remote"

### 3.4. Cut the release — disconnect the triad's final state

After all post-cycle work lands on main (γ's PRA + skill patches, δ's own session patches), δ cuts the release. **This is not optional** — the release is how δ disconnects the triad's output into a distributable, tagged whole.

> **Role-policy** (the triad's work is not complete until tagged; untagged post-cycle patches on main are an open boundary; δ is sole tag-author; δ blocks release completion until CI is green and owns recovery on red) **lives in [`delta/SKILL.md`](../delta/SKILL.md) §1.1.** **Mechanics** (the single-command release script invocation, post-push CI polling, the recovery runbook, branch deletes) **live in [`release-effector/SKILL.md`](../release-effector/SKILL.md)** — Phase 4c of cnos#366 (cycle/399) relocated them out of this section.

The triad's work is not complete until it is 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.

That skill owns: the single-command release script invocation, the bare-`X.Y.Z` tag policy (per `cnos.cds/skills/cds/CDS.md` §"Artifact contract" → §"Location matrix"), post-push CI polling, the CI-red recovery runbook, and merged-cycle-branch deletes. The script-as-only-path discipline (no manual `git tag`) is its rule, not this section's.

Two gate-rules δ enforces from this surface (the policy-level claims; mechanics in the effector skill):

- **Do not tag/release before `gamma-closeout.md` exists on main.**
- **δ blocks release completion until CI is green** (or operator explicitly accepts a known pre-existing failure per the release-effector recovery runbook).

### 3.5. The tag is the signal

The disconnect tag (§3.4) 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 (per [`release-effector/SKILL.md`](../release-effector/SKILL.md) — pre-disconnect tag pushes, merged-branch deletes), confirm completion to the requesting role per §3.3. But the disconnect tag itself needs no announcement — it speaks for itself. (Role-policy framing: [`delta/SKILL.md`](../delta/SKILL.md) §1.4.)

---

## 3a. δ as inward membrane: implementation-contract enrichment at dispatch

**Canonical doctrine lives at [`cnos.handoff/skills/handoff/dispatch/SKILL.md`](../../../../cnos.handoff/skills/handoff/dispatch/SKILL.md) §"δ as inward membrane"** (Sub 3 of [cnos#404](https://github.com/usurobor/cnos/issues/404), shipped under [cnos#417](https://github.com/usurobor/cnos/issues/417)). That skill owns the 7 implementation-contract axes, δ's review-before-routing duty, the fill-or-escalate paths, the four-surface mesh (γ template / δ enrichment / α constraint / β verification), and the cnos#389/#391/#392/#393 empirical anchors. The role-local realization continues to live at [`delta/SKILL.md`](../delta/SKILL.md) §2 (the inward-membrane half of δ's two-sided framing; outward half at §1; override at §3). `operator/SKILL.md` retains operator-as-coordinator + harness mechanics only; the doctrine lives at handoff and the role-local pointer lives in `delta/SKILL.md`.

---

## 4. Override

**Relocated to [`delta/SKILL.md`](../delta/SKILL.md) §3 "Override — degraded boundary action" as Phase 4a of cnos#366** (cycle/397). Override is a degraded boundary action (never a form of validity, never rewrites V's `ValidationVerdict`) per the cnos#367 freeze in `RECEIPT-VALIDATION.md` §Q4 — that role-doctrine is unified with the δ role-skill in `delta/SKILL.md`. The dispatch-coordinator side ("when α/β/γ ask for an override decision, where does it land?") fires through the algorithm step 7 above; the doctrine that constrains δ's override decision lives in the role-skill.

For the embedded override kata (Kata B — "α stuck on AC3 due to undocumented API change"), see §9 of this file. The kata exercises operator-as-coordinator's request-handling; the doctrine constraining δ's decision is in `delta/SKILL.md` §3.

---

## 5. Dispatch configurations

CDD defines two valid dispatch configurations. Choose one before dispatching; record it in `gamma-closeout.md`.

### 5.1 Canonical multi-session dispatch

One dispatched process per role (via the harness — see `harness/SKILL.md` §1); each has an independent auth context and no shared memory. This is the model described in §1.2 above.

- γ/δ separation is structurally present: the operator (δ) selects and scaffolds; γ coordinates; α and β are separate processes with no access to each other's reasoning or conversation state.
- Sub-agent returns do not apply — each dispatched session exits cleanly; the operator reads committed artifacts.
- Branch names are stable: `cycle/{N}` persists through all fix rounds because each role session checks it out fresh.

Use this configuration when the cycle is substantial (see §5.3 escalation criteria).

### 5.2 Single-session δ-as-γ via Agent tool (Claude Code activation)

When the operator is a Claude Code agent (one parent session), α and β are dispatched as sub-agents using the Agent tool rather than via separate harness processes. Sub-agents run with fresh context per invocation and are functionally equivalent to a fresh dispatched session for role-isolation purposes (each sub-agent reasons independently, cannot see the parent's conversation state, and cannot see the other sub-agent's conversation state). However, sub-agents inherit MCP scope and filesystem access from the parent session.

**Scope of the collapse.** §5.2 collapses **δ↔γ only**. γ↔α↔β remain structurally separate per the triadic rule (`cnos.cds/skills/cds/CDS.md` §"Field 6: Actor collapse rule"): γ scaffolds and coordinates in the parent session, α implements in its own sub-agent, β reviews and merges in its own sub-agent. The dyad-plus-coordinator structure is preserved; only the operator (δ) and coordinator (γ) functions fuse into one parent session.

A single sub-agent that performs γ-selection plus α-implementation plus β-review is not §5.2 — it is a triadic-rule violation (`cnos.cds/skills/cds/CDS.md` §"Field 6: Actor collapse rule"). §5.2 requires three execution contexts: the parent session (γ, also δ), a separate α sub-agent, and a separate β sub-agent. Lumping γ+α+β into one sub-agent breaks role-isolation (α gains access to β's reasoning and vice versa) and is rejected.

Three structural consequences follow:

1. **δ=γ collapse.** γ/δ separation is structurally absent: one parent session holds both the selection/scaffolding function (γ) and the external gate authority (δ). The cycle proceeds, but the grading floor in §3.8 of `release/SKILL.md` applies — see §3.8 configuration-floor clause.

For the general principle governing when role collapses are safe, see `ROLES.md §4` (hats-vs-actors: independence as the collapse constraint).

2. **sub-agent return messages are summaries, not full transcripts.** The Agent tool returns a summary message from the sub-agent, not a full conversation transcript. δ-as-γ verifies committed artifacts — specifically `beta-review.md` for β's verdict and `self-coherence.md` for α's review-readiness signal — rather than relying on the sub-agent's return message. This is the protocol invariant that makes §5.2 valid despite the summary-not-transcript limitation: the artifact β commits is canonical; the return message is informational only.

3. **Harness push restrictions surface as branch-name churn under fix-rounds.** Some Claude Code harness environments block updates to existing remote branches (403 on push to a previously-written branch). Under this constraint, a fresh-branch chain (`cycle/{N}` → `cycle/{N}-impl` → `cycle/{N}-impl-r2` → `cycle/{N}-impl-r3` → `cycle/{N}-merged` → `cycle/{N}-final`) is an acceptable workaround. Each link in the chain is a valid cycle branch for that fix-round; the final fast-forward into `main` becomes an external operator action.

**Empirical anchors:** The cnos-tsc supercycle (cycles 24–26, close-outs at `usurobor/tsc:.cdd/releases/{0.5.0,0.6.0,0.7.0}/{24,25,26}/gamma-closeout.md`) ran under §5.2 end-to-end; tsc cycle 26 γ-closeout explicitly records "operator (δ = γ in this two-agent configuration)." Tsc cycle #32 (close-out at `usurobor/tsc:.cdd/releases/docs/2026-05-09/32/gamma-closeout.md`) ran §5.2 and produced a five-link branch trail (`cycle/32` → `cycle/32-impl` → `cycle/32-impl-r2` → `cycle/32-merged` → `cycle/32-final`) due to harness push restrictions; that trail is the source observation for consequence (3) above.

**Reference dependencies:** §5.2 dispatch sizing follows `cnos.cds/skills/cds/CDS.md` §"Field 6: Actor collapse rule" (sequential bounded dispatch model; sub-agent dispatch budget heuristic). The harness push restriction that produces branch-name churn is the same constraint that makes the mechanical pre-merge gate (`release/SKILL.md §2.1`) an operator-side action when β cannot push directly (`cnos.cds/skills/cds/CDS.md` §"Development lifecycle" → §"Step table" Step 8 — β review and merge).

**Wave-manifest as γ-artifact-of-record (rule 3.11b discoverability under §5.2 wave-mode).** When §5.2 is run as a *wave* — a sequence of related cycles under one wave manifest per §10 Wave Coordination — the canonical γ-artifact-of-record for every sub of the wave is the wave manifest at `.cdd/waves/{wave-id}/manifest.md`, *not* a per-sub `.cdd/unreleased/{N}/gamma-scaffold.md`. The wave manifest carries every γ-artifact duty: γ=δ collapse declaration (or equivalent wave-mode exemption text), pinned file-paths forward-reference contract, standing permissions, timeout budgets, dispatch order, and per-issue scope. β's binding rule 3.11b gate (`review/SKILL.md` §3.11b "Exemption discoverability") recognizes this configuration provided the sub-issue ↔ wave-manifest **discoverability link** is auditable: either (a) the sub-issue body cites the wave by id (e.g. names `.cdd/waves/{wave-id}/manifest.md` or the wave title in a `## Wave` / `## Source` / `## Related` section), OR (b) the master tracking issue named by the wave manifest links to the sub-issue (e.g. GitHub sub-issue relations, wave-tracking comment thread, or an explicit `Issues:` table in the manifest itself naming the sub). Wave authors (δ-as-wave-planner, γ-as-wave-dispatcher) ensure at least one of (a)/(b) holds *before* dispatching any sub of the wave. The manifest template at §10.2 includes the `## Issues` table; populating that table with sub-issue links discharges path (b) by construction. *Derives from: cph cdr-refactor wave 2026-05-18 (master `usurobor/cph#11`; subs `cph#12, #13, #14, #15`) — four-of-four sub-uniform §5.2 with zero per-sub gamma-scaffold; three distinct β substantive-read justifications across four subs of the same wave-manifest-as-γ-artifact configuration. Without explicit recognition of this convention at the operator layer (this clause) and the review layer (rule 3.11b clause (ii)) and the alpha pre-review-gate layer (§2.6 row 15), β must re-derive the substantive read per sub and α cannot pre-empt the gate. Wave-iteration consolidation: `usurobor/cph:.cdd/iterations/wave-2026-05-18.md` Finding F1.*

### 5.2.1 Parent-session quiescence during sub-agent runs

When a sub-agent dispatch is in flight (via the Agent tool), the parent session MUST enter quiescent mode:

**Prohibited during sub-agent runs:**
- **No file edits** in the working tree
- **No commits** from the parent session
- **No branch switches** (`git checkout`, `git switch`)
- **No `git add` / `git restore --staged`** (index state must remain stable for the sub-agent's view)
- **No `git pull` / `git fetch` that updates the current branch HEAD**

**Permitted during sub-agent runs:**
- Reads: `git status`, `git log`, `git diff`, file reads via Read tool, web fetches, GitHub MCP queries
- Coordination: dispatching additional sub-agents (each gets its own context; isolation is by sub-agent), reading existing branches via `git fetch <branch>` (does not update HEAD)
- **Filesystem operations on paths outside the repo** (e.g., `/tmp`, drafts)

**When the parent must edit:** dispatch a sub-agent to do the edit, or wait for current sub-agents to complete. The parent is the coordinator, not a fourth concurrent writer.

**What goes wrong when this is violated:** Sub-agent A is running α R1, has read the working tree, is about to `git add` and `git commit`. Parent session edits file X concurrently. Sub-agent's `git add .` picks up parent's edits accidentally. Sub-agent's commit message describes only its intended change but the diff includes parent's edits. Result: corrupted commit, branch must be reset, fix-round required.

**Sub-agent parallelism note:** Multiple sub-agents launched in parallel (via `Agent` tool calls in one parent message) have **isolated contexts** from each other but **share the working tree with the parent and with each other**. Concurrent file edits by parallel sub-agents are also a corruption risk and should be avoided — multi-sub-agent parallelism is for independent reads, not concurrent writes.

**Exception:** When the Agent tool runs with filesystem-isolation mode (the sub-agent operates on a copy of the repo, e.g. the Claude Code Agent tool's `isolation` parameter set to the per-agent-copy mode), parent-session quiescence is unnecessary. Default mode requires quiescence.

### 5.3 Escalation criteria

Switch from §5.2 to §5.1 (multi-session) when any of the following is true at γ scaffold time:

- **≥7 ACs** in the cycle (complexity exceeds what a single-session coordinator can reliably hold across sub-agent round-trips)
- **New contract surface or cross-repo deliverables** (γ/δ separation matters for audit when external systems are affected)
- **≥3 β rounds expected** (multiple fix-round re-dispatches compound the branch-name churn problem under §5.2 harness constraints)
- **≥3 γ judgment calls expected mid-cycle** (design ambiguity, scope changes, unblock decisions — each requires full cross-agent context that δ-as-γ holds less reliably than a dedicated γ session)

---

## 6. What the operator does NOT do

These are role boundaries. Crossing them without an override declaration breaks the coherence record.

- **Do not implement.** That's α. If you want to fix something, declare an override and take the α role explicitly.
- **Do not review.** That's β. If you disagree with β's verdict, declare an override.
- **Do not triage findings.** That's γ. If you want a finding handled differently, tell γ.
- **Do not rewrite prompts.** γ owns prompt quality. If the prompt is weak, tell γ to fix the issue.
- **Do not merge without β's approval.** The merge gate fires when β says it's ready, not before.
- **Do not communicate directly with α or β during in-cycle work.** γ is the bridge. δ-to-γ, γ-to-α/β. δ remains external to the triad; γ is the operator's only in-cycle counterparty.

---

## 7. Cycle lifecycle from the operator's view

| Phase | Operator action | Wait for |
|-------|----------------|----------|
| γ dispatch | Dispatch γ via the harness (see `harness/SKILL.md` §1); γ creates branch, returns α/β prompts | γ completion |
| α dispatch | Dispatch α via the harness with γ's prompt | α completion (exits after review-readiness) |
| β dispatch | Dispatch β via the harness with γ's prompt | β completion (merge + β close-out) |
| α fix-round re-dispatch | Dispatch α via the harness with fix-round prompt (`cnos.cds/skills/cds/CDS.md` §"Coordination surfaces"; prompt format in §5.2 of this file) when β returns RC | α completion (exits after fix-round) |
| α close-out re-dispatch | Dispatch α via the harness with close-out prompt (`cnos.cds/skills/cds/CDS.md` §"Coordination surfaces"; prompt format in §5.2 of this file) when γ requests | α completion (alpha-closeout.md on main) |
| Release prep | γ writes RELEASE.md, moves cycle dirs; δ holds until complete | γ request |
| δ preflight | Verify merge commit, release artifacts, tag preconditions | γ preflight request |
| Closure | Gate: do not tag before `gamma-closeout.md` exists on main | γ closure declaration (gamma-closeout.md) |
| Disconnect | Cut the release — see [`release-effector/SKILL.md`](../release-effector/SKILL.md) | γ close-out + δ session patches on main |
| Post-release | Execute deferred operator actions from γ close-out | γ deferred-output list |
| Inter-cycle | Nothing until next γ dispatch | γ next-cycle selection |

---

## 8. Timeout recovery

When a dispatched session SIGTERMs, hits a timeout, or crashes before committing, δ runs the worktree inspection + decision-tree recovery procedure codified in `harness/SKILL.md` §6 (Timeout recovery). The procedure is mechanics; the doctrine surfaces that depend on it stay here:

- **Override declaration.** If δ commits work on behalf of an agent, this is an implicit override; δ declares it per [`delta/SKILL.md`](../delta/SKILL.md) §3 with the standard shape ("Override: operator-identity commit for cycle #N. Reason: …"). The mechanics record entry lives in `self-coherence.md §Debt` per harness §6.4.
- **Grade implication.** A cycle with operator-identity recovery commits is a cycle with operator override; per `release/SKILL.md §3.8`, the γ-axis grade reflects the override.
- **Prevention.** The recovery procedure is the failure path; the prevention path is a correctly-sized dispatch budget per `cnos.cds/skills/cds/CDS.md` §"Field 6: Actor collapse rule" (heuristic constants in this file's §5.2). Record budget/AC count in PRA telemetry (`post-release/SKILL.md` §4) so the heuristic refines.

---

## 9. Embedded Kata

### Kata A — Normal cycle

#### Scenario

γ has dispatched α and β prompts for issue #230. You have two agent sessions available.

#### Task

Execute the operator role through the full cycle.

#### Expected actions

1. Confirm agent-to-role mapping
2. Deliver α prompt to session A, β prompt to session B
3. Wait
4. When β requests merge: execute merge
5. When γ requests tag push: execute tag push
6. When γ declares closure: cut the release per [`release-effector/SKILL.md`](../release-effector/SKILL.md)
7. Execute any deferred operator actions from γ's close-out

#### Common failures

- Checking the branch during review and suggesting changes (role leak into β)
- Merging before β approves (gate fired early)
- Rewriting γ's prompts before delivering (role leak into γ)

### Kata B — Override

#### Scenario

α has been implementing for 4 hours. γ reports α is stuck on AC3 due to an undocumented API change. γ's unblock attempt (clarifying the issue) didn't resolve it.

#### Task

Decide whether to override and, if so, execute the protocol.

#### Expected answer

- Override: descope AC3 from this cycle. Reason: undocumented API change requires investigation beyond cycle scope. New scope: AC1–AC2 + AC4–AC6. γ to update the issue and file AC3 as a follow-on.
- Or: provide the missing API documentation as an artifact fact (not implementation direction), which γ can add to the issue. This is unblocking, not override.

#### Reflection

- Did you route through γ, or did you talk directly to α? (Should route through γ unless γ is unavailable.)
- Did you declare the override explicitly, or did you quietly adjust scope?

---

## 10. Wave Coordination

**Multi-cycle coordination primitive for sequences of related issues.**

When δ runs a wave (sequence of related cycles), the artifacts, coordination protocol, and dispatch templates below ensure wave state is durable, auditable, and git-committed — not ephemeral like `/tmp` files.

### 10.1. δ Wave Dispatch Template

**Wave dispatch prompt template for δ-as-agent.** Parallel to α/β templates in `gamma/SKILL.md` §2.5. Takes wave manifest as input, produces γ prompts per issue.

```markdown
# δ Wave Dispatch — {wave-name}

You are δ (operator) for CDD wave coordination.

## Load Order (mandatory)

1. Read `src/packages/cnos.cdd/skills/cdd/operator/SKILL.md` — canonical δ algorithm
2. Read wave manifest at `.cdd/waves/{wave-id}/manifest.md` — issue order, dependencies, permissions
3. Read wave status at `.cdd/waves/{wave-id}/status.md` — current per-issue state

## Context

- **Wave:** {wave-name}
- **Wave ID:** {wave-id} 
- **Repo:** {repo-path}
- **Issues in scope:** {issue-list}

## Algorithm

1. **Initialize wave directory** — create `.cdd/waves/{wave-id}/` if it doesn't exist
2. **Update wave status** — write current state to `status.md` (queued → in-progress for next issue)  
3. **Select next issue** — per manifest order and dependency constraints
4. **Dispatch γ** — create issue-specific γ prompt using manifest permissions and timeouts
5. **Monitor cycle** — poll `origin/cycle/{N}` and `.cdd/unreleased/{N}/` for completion
6. **Update wave status** — mark cycle completed/failed, update rounds, notes
7. **Repeat or close** — continue with next issue or close wave when complete

## Wave permissions from manifest

- Push to cycle branches: {push-cycles}
- Push merges to main: {push-main}  
- Auto-dispatch α fix rounds: {auto-fix} (max {fix-max})
- Tag/release: {tag-release}
- Branch delete after merge: {branch-delete}

## Standing instructions

- Update `.cdd/waves/{wave-id}/status.md` after each cycle completion
- Emit wave status table on operator request  
- Close wave when all issues completed/deferred per manifest
- Write `.cdd/waves/{wave-id}/wave-closeout.md` at wave end

Signal completion when wave is closed or blocked.
```

### 10.2. Wave Manifest Format

**Canonical wave manifest** — `.cdd/waves/{wave-id}/manifest.md`.

Contains issue list, execution order, dependency constraints, standing permissions, timeout budgets.

```markdown
# Wave: {wave-title}

**Date:** {YYYY-MM-DD}
**Dispatcher:** {δ-identity}  
**Repo:** {repo-path}

## Issues (run in order)

| Order | # | Title | ACs | Type | Dependencies |
|-------|---|-------|-----|------|--------------|
| 1 | {N1} | {title1} | {ac-count1} | {type1} | — |
| 2 | {N2} | {title2} | {ac-count2} | {type2} | #{N1} |
| 3 | {N3} | {title3} | {ac-count3} | {type3} | #{N1}, #{N2} |

## Standing permissions

- Push to cycle branches: {yes|no}
- Push merges to main: {yes|no}
- Auto-dispatch α fix rounds on REQUEST CHANGES: {yes|no} (max {N})
- Tag/release: {yes|no} — write to status.md only
- Branch delete after merge: {yes|no}

## Timeout budgets

- γ: {N}s ({configuration-note})
- α: {N}s  
- β: {N}s

## Dependencies

{per-issue dependency description}
```

### 10.3. Wave Status Format

**Wave status tracking** — `.cdd/waves/{wave-id}/status.md`.

Per-issue status table updated by δ after each cycle closes.

```markdown
# Wave Status: {wave-title}

**Last updated:** {timestamp} by δ

| # | Issue | Status | Rounds | Branch | Tag | Notes |
|---|-------|--------|--------|--------|-----|-------|
| {N1} | {title1} | {status1} | {rounds1} | {branch-state1} | {tag-state1} | {notes1} |
| {N2} | {title2} | {status2} | {rounds2} | {branch-state2} | {tag-state2} | {notes2} |

## Status values

- `⬜ queued` — not started
- `🔄 in-progress` — γ/α/β active
- `✅ completed` — merged to main
- `❌ failed` — cycle abandoned
- `⏸️ blocked` — waiting on dependency
- `⭕ deferred` — explicitly moved out of wave
```

### 10.4. Wave Closure Protocol

**Wave completion conditions and closure procedure.**

Wave is closed when:
1. **All issues completed** or explicitly deferred
2. **Status.md final** — all entries show terminal state (completed/failed/deferred)  
3. **Wave-closeout.md written** with aggregate stats and findings

**Closure algorithm:**
1. **Verify completion** — every manifest issue has terminal status  
2. **Write wave-closeout.md** — wave summary, aggregate metrics, cross-wave findings
3. **Finalize status.md** — add wave closure timestamp, mark final
4. **Signal closure** — wave coordination complete, artifacts durable

### 10.5. δ Wave Reporting Format  

**Wave status table emitted by δ.** Parallel to γ's TLDR (§2.11) but wave-scoped.

| # | Issue | Status | Rounds | Notes |
|---|-------|--------|--------|-------|
| {N} | {title} | {status} | {round-count} | {notes} |

**Status icons:**
- `⬜ queued` — not started  
- `🔄 in-progress` — cycle active
- `✅ completed` — merged, tagged
- `❌ failed` — cycle abandoned
- `⏸️ blocked` — dependency wait
- `⭕ deferred` — moved out of wave

**Emit frequency:**
- After each cycle completion  
- On operator request
- At wave closure

### 10.6. Iteration Artifact Lifecycle

**Three-stage lifecycle for wave iteration findings.**

Wave iteration files (like `.cdd/iterations/wave-2026-05-12.md`) track cross-cycle findings and their dispositions through wave execution and into release.

**Stage 1: Per-issue close**
- Wave iteration file's disposition column updated with issue numbers or commit SHAs
- Each finding gets: `filed #{N}`, `patched {SHA}`, `deferred`, or `no-action`
- Updated as each wave issue closes

**Stage 2: Wave close**  
- Wave iteration file moves to `.cdd/waves/{wave-id}/iteration.md`
- Dispositions finalized, no further updates
- Wave-closeout.md cross-references iteration.md
- Iteration.md becomes part of durable wave record

**Stage 3: Release boundary**
- Findings that produced MCAs (Major Change Approvals) get cross-referenced in release PRA
- PRA links back to specific iteration.md findings that drove release changes
- Creates audit trail from wave findings → MCAs → release notes

**File movement example:**
```
.cdd/iterations/wave-2026-05-12.md  
  ↓ (wave closes)
.cdd/waves/hardening-2026-05-12/iteration.md
  ↓ (release time) 
.cdd/releases/3.60.0/post-release-assessment.md (references iteration findings)
```