[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF0TZJX2XNW81EESRT7D0Y":3,"skill-same:01M6CF0TZJX2XNW81EESRT7D0Y":87},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":65,"commitSha":66,"skillDirectory":67,"forksCount":68,"repositoryHtmlUrl":69,"repositoryHomepageUrl":6,"ownerHtmlUrl":70,"ownerBlogUrl":6,"ownerDescription":71,"updatedAt":72,"install":73,"resources":86},"01M6CF0TZJX2XNW81EESRT7D0Y","operator",null,"δ role in CDD. Owns external gates, routing, and override authority during an active triad cycle.","usurobor\u002Fcnos","usurobor","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F182342826?v=4","01M6CEXJCRMYD8HB2315FGB1Q8","Peter Lisovin","01M6CEXJH2RW04GQ2SNXY40F5S",9,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Foperator\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"ci","gamma","cdd","gate","issue","prompts","embedded","dispatch","branch","sessions","push","harness","state","release","routing","deploy","2026-11-10 10:12:30",false,"---\nname: operator\ndescription: δ role in CDD. Owns external gates, routing, and override authority during an active triad cycle.\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: What does the operator do — and not do — during an active CDD cycle?\nvisibility: internal\nparent: cdd\ntriggers:\n  - operator\n  - dispatch\n  - gate\n  - unblock\nscope: role-local\ninputs:\n  - γ dispatch prompts\n  - external gate requests from α\u002Fβ\u002Fγ\n  - cycle state (issue, branch, .cdd\u002Funreleased\u002F{N}\u002F, CI)\noutputs:\n  - routed prompts to agent sessions\n  - external gate executions and confirmations (push on β's behalf, tag, release, deploy, issue filing)\n  - override declarations when needed\nrequires:\n  - active CDD cycle exists\n  - γ has produced dispatch prompts\ncalls:\n  - gamma\u002FSKILL.md\n  - harness\u002FSKILL.md\n---\n\n# Operator (δ)\n\n## Core Principle\n\n**Coherent δ operation routes work, holds gates, and stays out of the triad's reasoning.**\n\nδ 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.\n\n> **First-time operator?** Before running the algorithm below, ensure the repository has been activated under CDD.\n> See [`cdd\u002Factivation\u002FSKILL.md`](..\u002Factivation\u002FSKILL.md) for the one-time bootstrap: `.cdd\u002F` scaffold, version\n> pin, identity convention setup, and the §24 verification command that confirms activation is complete.\n\n## Algorithm\n\n1. **Dispatch γ** — δ dispatches γ via the harness; γ reads the issue, creates the cycle branch, and produces α\u002Fβ prompts. See `harness\u002FSKILL.md` §1 for invocation mechanics.\n2. **Dispatch α** — δ dispatches α via the harness with the prompt γ produced; α implements on the cycle branch and exits after signaling review-readiness.\n3. **Dispatch β** — δ dispatches β via the harness with the prompt γ produced; β reviews, merges, writes β close-out, and exits.\n4. **Re-dispatch α for fix rounds** (when β returns RC) — δ dispatches α via the harness with the fix-round re-dispatch prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\"; prompt format in §5.2 of this file); α fixes findings, appends fix-round to self-coherence.md, exits.\n5. **Re-dispatch α for close-out** (when γ requests after β merge) — δ dispatches α via the harness with the close-out re-dispatch prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n6. **Gate** — execute external actions: push main, tag, release, branch deletes. **Do not tag\u002Frelease before `gamma-closeout.md` exists on main.** Disconnect-release mechanics live in [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md) (Phase 4c of cnos#366, cycle\u002F399); 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).\n7. **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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §3; this step is operator-as-coordinator routing the override declaration through the cycle.\n\nδ 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\u002FSKILL.md` §2), and isolates failures — if α dies, δ retries α without losing γ or β state.\n\n---\n\n## Git identity for role actors\n\nThe 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\u002FSKILL.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.\n\n---\n\n## 1. Route\n\n### 1.1. Dispatch γ first\n\nδ dispatches γ. γ reads the issue, creates the cycle branch, and returns α\u002Fβ prompts to δ. γ does not execute dispatch — δ does.\n\n### 1.2. Dispatch α and β sequentially\n\nδ dispatches α, waits for completion, then dispatches β. One role at a time.\n\nThe invocation shell, observability flags, and permission-mode requirement are codified in `harness\u002FSKILL.md` §1 (Dispatch invocation) and §2 (Dispatch observability contract). δ honors that contract; this section names the routing discipline.\n\n- ❌ Rewrite the prompt to add constraints or context γ didn't include\n- ✅ Deliver the prompt verbatim to the dispatched session (harness contract)\n- ❌ Run α and β concurrently or nest them inside γ's session\n- ✅ Run one role at a time, inspect artifacts between dispatches\n- ✅ Name the agent-to-role mapping before delivering prompts\n\n---\n\n## 2. Wait\n\n### 2.1. Do not poll internal work\n\nOnce dispatched, the triad runs. The operator does not need to monitor branch diffs, `.cdd\u002Funreleased\u002F{N}\u002F` files, or CI runs — γ owns that.\n\nThe operator's wake-up signals are:\n\n- **γ requests an external gate** (push on β's behalf, tag push, release, deploy, issue filing, auth action)\n- **γ requests an unblock decision** (design ambiguity, scope question, env constraint)\n- **γ declares cycle closure** and names deferred outputs that need operator action\n- **An agent session dies or stalls** (no activity for an unexpected duration)\n\nBetween these signals, the operator's correct action is nothing.\n\n- ❌ Check the branch every 30 minutes and suggest changes (role leak into β)\n- ❌ Heartbeat reveals cycle state (tag missing, branches exist) → δ acts on it (observation is not a gate request)\n- ✅ Wait for γ to surface a gate or decision request\n- ✅ Heartbeat reveals cycle state → δ notes it, waits for γ\n\n### 2.2. Subscribe to the issue\n\nPoll the issue and cycle branches for activity using the same transition-only pattern as the triad (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nThe polling loop mechanics (issue-activity poller, multi-branch poller with reachability re-probe) live in `harness\u002FSKILL.md` §5 (Polling and wake-up). δ uses those forms under `Monitor` or equivalent. Canonical cycle branches are `origin\u002Fcycle\u002F{N}` (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Branch rule\", since #287); the pre-#287 `'origin\u002Fclaude\u002F*'` glob is warn-only \u002F retrospective per harness §5.3.\n\n---\n\n## 3. Gate\n\n> **δ-as-role boundary policy lives in [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md).** This section retains the gate-policy doctrine that `operator\u002FSKILL.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\u002FSKILL.md` §1 \"Outward membrane\" and §3 \"Override.\" **Dispatch-coordinator mechanics** (the `claude -p` \u002F `cn dispatch` invocation, observability flags, worktree management, identity discipline) live in [`harness\u002FSKILL.md`](..\u002Fharness\u002FSKILL.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\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md) per Phase 4c of cnos#366 (cycle\u002F399).\n\n### 3.1. External actions the operator executes on δ-the-role's authority\n\nThe actions in this table require platform permissions agents may lack. **δ-as-role authorises** these actions per [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.1; operator-as-coordinator dispatches them on request from γ, β, or α-via-γ:\n\n| Action | Trigger | Who requests |\n|--------|---------|-------------|\n| Pre-merge gate validation | Before authorizing β merge, run `scripts\u002Fvalidate-release-gate.sh --mode pre-merge` to verify cycle artifacts exist and are well-formed. See `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Ownership matrix\" and `gamma\u002FSKILL.md` §2.10. | γ |\n| Push β-approved merge to main | β runs `git merge` — δ only pushes when β cannot execute the push directly (env\u002Fauth constraint). This is execution of β's integration authority, not δ approval. | β or γ |\n| Release-boundary preflight | After β merge + close-outs + γ PRA, δ verifies merge commit, release artifacts, tag\u002Fdeploy preconditions, and platform readiness. Proceed \u002F request changes \u002F override. See `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" Step 9 (δ gate). | γ |\n| 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\u002FSKILL.md` §1.1) | γ |\n| Branch delete | Cycle closed, merged branches | γ |\n| Issue filing on external repos | Cross-project dependency | γ |\n| Force push | Rebase required with env constraints | α via γ |\n| Auth refresh | Token\u002Fpermission expiry | any role via γ |\n\n### 3.2. Execute on request, not on observation\n\nGate 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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.2.)\n\n- ❌ Heartbeat shows tag not pushed → δ pushes it (role leak: δ decided the gate, not γ)\n- ❌ \"β asked me to push the merge but I think we should wait for one more review\"\n- ✅ γ requests tag push → δ pushes it and confirms\n- ✅ If you disagree with a gate request, declare an override per [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §3\n\n### 3.3. Report completion\n\nAfter executing a gate action, confirm to the requesting role that the action completed. (Role-policy framing: [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.3.)\n\n- ❌ Execute silently and assume the triad will notice\n- ✅ \"Tag pushed: `git push origin 3.59.0` — confirmed on remote\"\n\n### 3.4. Cut the release — disconnect the triad's final state\n\nAfter 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.\n\n> **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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.1.** **Mechanics** (the single-command release script invocation, post-push CI polling, the recovery runbook, branch deletes) **live in [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md)** — Phase 4c of cnos#366 (cycle\u002F399) relocated them out of this section.\n\nThe 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.\n\nThat skill owns: the single-command release script invocation, the bare-`X.Y.Z` tag policy (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nTwo gate-rules δ enforces from this surface (the policy-level claims; mechanics in the effector skill):\n\n- **Do not tag\u002Frelease before `gamma-closeout.md` exists on main.**\n- **δ blocks release completion until CI is green** (or operator explicitly accepts a known pre-existing failure per the release-effector recovery runbook).\n\n### 3.5. The tag is the signal\n\nThe 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.\n\nFor mid-cycle gate actions (per [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.4.)\n\n---\n\n## 3a. δ as inward membrane: implementation-contract enrichment at dispatch\n\n**Canonical doctrine lives at [`cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md`](..\u002F..\u002F..\u002F..\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md) §\"δ as inward membrane\"** (Sub 3 of [cnos#404](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F404), shipped under [cnos#417](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F417)). That skill owns the 7 implementation-contract axes, δ's review-before-routing duty, the fill-or-escalate paths, the four-surface mesh (γ template \u002F δ enrichment \u002F α constraint \u002F β verification), and the cnos#389\u002F#391\u002F#392\u002F#393 empirical anchors. The role-local realization continues to live at [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §2 (the inward-membrane half of δ's two-sided framing; outward half at §1; override at §3). `operator\u002FSKILL.md` retains operator-as-coordinator + harness mechanics only; the doctrine lives at handoff and the role-local pointer lives in `delta\u002FSKILL.md`.\n\n---\n\n## 4. Override\n\n**Relocated to [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §3 \"Override — degraded boundary action\" as Phase 4a of cnos#366** (cycle\u002F397). 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\u002FSKILL.md`. The dispatch-coordinator side (\"when α\u002Fβ\u002Fγ 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.\n\nFor 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\u002FSKILL.md` §3.\n\n---\n\n## 5. Dispatch configurations\n\nCDD defines two valid dispatch configurations. Choose one before dispatching; record it in `gamma-closeout.md`.\n\n### 5.1 Canonical multi-session dispatch\n\nOne dispatched process per role (via the harness — see `harness\u002FSKILL.md` §1); each has an independent auth context and no shared memory. This is the model described in §1.2 above.\n\n- γ\u002Fδ 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.\n- Sub-agent returns do not apply — each dispatched session exits cleanly; the operator reads committed artifacts.\n- Branch names are stable: `cycle\u002F{N}` persists through all fix rounds because each role session checks it out fresh.\n\nUse this configuration when the cycle is substantial (see §5.3 escalation criteria).\n\n### 5.2 Single-session δ-as-γ via Agent tool (Claude Code activation)\n\nWhen 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.\n\n**Scope of the collapse.** §5.2 collapses **δ↔γ only**. γ↔α↔β remain structurally separate per the triadic rule (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nA single sub-agent that performs γ-selection plus α-implementation plus β-review is not §5.2 — it is a triadic-rule violation (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nThree structural consequences follow:\n\n1. **δ=γ collapse.** γ\u002Fδ separation is structurally absent: one parent session holds both the selection\u002Fscaffolding function (γ) and the external gate authority (δ). The cycle proceeds, but the grading floor in §3.8 of `release\u002FSKILL.md` applies — see §3.8 configuration-floor clause.\n\nFor the general principle governing when role collapses are safe, see `ROLES.md §4` (hats-vs-actors: independence as the collapse constraint).\n\n2. **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.\n\n3. **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\u002F{N}` → `cycle\u002F{N}-impl` → `cycle\u002F{N}-impl-r2` → `cycle\u002F{N}-impl-r3` → `cycle\u002F{N}-merged` → `cycle\u002F{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.\n\n**Empirical anchors:** The cnos-tsc supercycle (cycles 24–26, close-outs at `usurobor\u002Ftsc:.cdd\u002Freleases\u002F{0.5.0,0.6.0,0.7.0}\u002F{24,25,26}\u002Fgamma-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\u002Ftsc:.cdd\u002Freleases\u002Fdocs\u002F2026-05-09\u002F32\u002Fgamma-closeout.md`) ran §5.2 and produced a five-link branch trail (`cycle\u002F32` → `cycle\u002F32-impl` → `cycle\u002F32-impl-r2` → `cycle\u002F32-merged` → `cycle\u002F32-final`) due to harness push restrictions; that trail is the source observation for consequence (3) above.\n\n**Reference dependencies:** §5.2 dispatch sizing follows `cnos.cds\u002Fskills\u002Fcds\u002FCDS.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\u002FSKILL.md §2.1`) an operator-side action when β cannot push directly (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" Step 8 — β review and merge).\n\n**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\u002Fwaves\u002F{wave-id}\u002Fmanifest.md`, *not* a per-sub `.cdd\u002Funreleased\u002F{N}\u002Fgamma-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\u002FSKILL.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\u002Fwaves\u002F{wave-id}\u002Fmanifest.md` or the wave title in a `## Wave` \u002F `## Source` \u002F `## 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)\u002F(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\u002Fcph#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\u002Fcph:.cdd\u002Fiterations\u002Fwave-2026-05-18.md` Finding F1.*\n\n### 5.2.1 Parent-session quiescence during sub-agent runs\n\nWhen a sub-agent dispatch is in flight (via the Agent tool), the parent session MUST enter quiescent mode:\n\n**Prohibited during sub-agent runs:**\n- **No file edits** in the working tree\n- **No commits** from the parent session\n- **No branch switches** (`git checkout`, `git switch`)\n- **No `git add` \u002F `git restore --staged`** (index state must remain stable for the sub-agent's view)\n- **No `git pull` \u002F `git fetch` that updates the current branch HEAD**\n\n**Permitted during sub-agent runs:**\n- Reads: `git status`, `git log`, `git diff`, file reads via Read tool, web fetches, GitHub MCP queries\n- Coordination: dispatching additional sub-agents (each gets its own context; isolation is by sub-agent), reading existing branches via `git fetch \u003Cbranch>` (does not update HEAD)\n- **Filesystem operations on paths outside the repo** (e.g., `\u002Ftmp`, drafts)\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n### 5.3 Escalation criteria\n\nSwitch from §5.2 to §5.1 (multi-session) when any of the following is true at γ scaffold time:\n\n- **≥7 ACs** in the cycle (complexity exceeds what a single-session coordinator can reliably hold across sub-agent round-trips)\n- **New contract surface or cross-repo deliverables** (γ\u002Fδ separation matters for audit when external systems are affected)\n- **≥3 β rounds expected** (multiple fix-round re-dispatches compound the branch-name churn problem under §5.2 harness constraints)\n- **≥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)\n\n---\n\n## 6. What the operator does NOT do\n\nThese are role boundaries. Crossing them without an override declaration breaks the coherence record.\n\n- **Do not implement.** That's α. If you want to fix something, declare an override and take the α role explicitly.\n- **Do not review.** That's β. If you disagree with β's verdict, declare an override.\n- **Do not triage findings.** That's γ. If you want a finding handled differently, tell γ.\n- **Do not rewrite prompts.** γ owns prompt quality. If the prompt is weak, tell γ to fix the issue.\n- **Do not merge without β's approval.** The merge gate fires when β says it's ready, not before.\n- **Do not communicate directly with α or β during in-cycle work.** γ is the bridge. δ-to-γ, γ-to-α\u002Fβ. δ remains external to the triad; γ is the operator's only in-cycle counterparty.\n\n---\n\n## 7. Cycle lifecycle from the operator's view\n\n| Phase | Operator action | Wait for |\n|-------|----------------|----------|\n| γ dispatch | Dispatch γ via the harness (see `harness\u002FSKILL.md` §1); γ creates branch, returns α\u002Fβ prompts | γ completion |\n| α dispatch | Dispatch α via the harness with γ's prompt | α completion (exits after review-readiness) |\n| β dispatch | Dispatch β via the harness with γ's prompt | β completion (merge + β close-out) |\n| α fix-round re-dispatch | Dispatch α via the harness with fix-round prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\"; prompt format in §5.2 of this file) when β returns RC | α completion (exits after fix-round) |\n| α close-out re-dispatch | Dispatch α via the harness with close-out prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\"; prompt format in §5.2 of this file) when γ requests | α completion (alpha-closeout.md on main) |\n| Release prep | γ writes RELEASE.md, moves cycle dirs; δ holds until complete | γ request |\n| δ preflight | Verify merge commit, release artifacts, tag preconditions | γ preflight request |\n| Closure | Gate: do not tag before `gamma-closeout.md` exists on main | γ closure declaration (gamma-closeout.md) |\n| Disconnect | Cut the release — see [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md) | γ close-out + δ session patches on main |\n| Post-release | Execute deferred operator actions from γ close-out | γ deferred-output list |\n| Inter-cycle | Nothing until next γ dispatch | γ next-cycle selection |\n\n---\n\n## 8. Timeout recovery\n\nWhen a dispatched session SIGTERMs, hits a timeout, or crashes before committing, δ runs the worktree inspection + decision-tree recovery procedure codified in `harness\u002FSKILL.md` §6 (Timeout recovery). The procedure is mechanics; the doctrine surfaces that depend on it stay here:\n\n- **Override declaration.** If δ commits work on behalf of an agent, this is an implicit override; δ declares it per [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.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.\n- **Grade implication.** A cycle with operator-identity recovery commits is a cycle with operator override; per `release\u002FSKILL.md §3.8`, the γ-axis grade reflects the override.\n- **Prevention.** The recovery procedure is the failure path; the prevention path is a correctly-sized dispatch budget per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Field 6: Actor collapse rule\" (heuristic constants in this file's §5.2). Record budget\u002FAC count in PRA telemetry (`post-release\u002FSKILL.md` §4) so the heuristic refines.\n- **Close-state assertion parity.** If recovery carries a SIGTERM-terminated cycle through to a merge, δ MUST run the same close-state hard gate a normal γ close-out runs (`gamma\u002FSKILL.md §2.10` row 15: `gh issue view {N} --json state --jq .state` MUST return `CLOSED`) before declaring the recovered cycle closed — mechanics at `harness\u002FSKILL.md` §6.6. Recovery changes who runs the closure gate, not whether it runs.\n\n---\n\n## 9. Embedded Kata\n\n### Kata A — Normal cycle\n\n#### Scenario\n\nγ has dispatched α and β prompts for issue #230. You have two agent sessions available.\n\n#### Task\n\nExecute the operator role through the full cycle.\n\n#### Expected actions\n\n1. Confirm agent-to-role mapping\n2. Deliver α prompt to session A, β prompt to session B\n3. Wait\n4. When β requests merge: execute merge\n5. When γ requests tag push: execute tag push\n6. When γ declares closure: cut the release per [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md)\n7. Execute any deferred operator actions from γ's close-out\n\n#### Common failures\n\n- Checking the branch during review and suggesting changes (role leak into β)\n- Merging before β approves (gate fired early)\n- Rewriting γ's prompts before delivering (role leak into γ)\n\n### Kata B — Override\n\n#### Scenario\n\nα 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.\n\n#### Task\n\nDecide whether to override and, if so, execute the protocol.\n\n#### Expected answer\n\n- 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.\n- Or: provide the missing API documentation as an artifact fact (not implementation direction), which γ can add to the issue. This is unblocking, not override.\n\n#### Reflection\n\n- Did you route through γ, or did you talk directly to α? (Should route through γ unless γ is unavailable.)\n- Did you declare the override explicitly, or did you quietly adjust scope?\n\n---\n\n## 10. Wave Coordination\n\n**Multi-cycle coordination primitive for sequences of related issues.**\n\nWhen δ 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 `\u002Ftmp` files.\n\n### 10.1. δ Wave Dispatch Template\n\n**Wave dispatch prompt template for δ-as-agent.** Parallel to α\u002Fβ templates in `gamma\u002FSKILL.md` §2.5. Takes wave manifest as input, produces γ prompts per issue.\n\n```markdown\n# δ Wave Dispatch — {wave-name}\n\nYou are δ (operator) for CDD wave coordination.\n\n## Load Order (mandatory)\n\n1. Read `src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Foperator\u002FSKILL.md` — canonical δ algorithm\n2. Read wave manifest at `.cdd\u002Fwaves\u002F{wave-id}\u002Fmanifest.md` — issue order, dependencies, permissions\n3. Read wave status at `.cdd\u002Fwaves\u002F{wave-id}\u002Fstatus.md` — current per-issue state\n\n## Context\n\n- **Wave:** {wave-name}\n- **Wave ID:** {wave-id} \n- **Repo:** {repo-path}\n- **Issues in scope:** {issue-list}\n\n## Algorithm\n\n1. **Initialize wave directory** — create `.cdd\u002Fwaves\u002F{wave-id}\u002F` if it doesn't exist\n2. **Update wave status** — write current state to `status.md` (queued → in-progress for next issue)  \n3. **Select next issue** — per manifest order and dependency constraints\n4. **Dispatch γ** — create issue-specific γ prompt using manifest permissions and timeouts\n5. **Monitor cycle** — poll `origin\u002Fcycle\u002F{N}` and `.cdd\u002Funreleased\u002F{N}\u002F` for completion\n6. **Update wave status** — mark cycle completed\u002Ffailed, update rounds, notes\n7. **Repeat or close** — continue with next issue or close wave when complete\n\n## Wave permissions from manifest\n\n- Push to cycle branches: {push-cycles}\n- Push merges to main: {push-main}  \n- Auto-dispatch α fix rounds: {auto-fix} (max {fix-max})\n- Tag\u002Frelease: {tag-release}\n- Branch delete after merge: {branch-delete}\n\n## Standing instructions\n\n- Update `.cdd\u002Fwaves\u002F{wave-id}\u002Fstatus.md` after each cycle completion\n- Emit wave status table on operator request  \n- Close wave when all issues completed\u002Fdeferred per manifest\n- Write `.cdd\u002Fwaves\u002F{wave-id}\u002Fwave-closeout.md` at wave end\n\nSignal completion when wave is closed or blocked.\n```\n\n### 10.2. Wave Manifest Format\n\n**Canonical wave manifest** — `.cdd\u002Fwaves\u002F{wave-id}\u002Fmanifest.md`.\n\nContains issue list, execution order, dependency constraints, standing permissions, timeout budgets.\n\n```markdown\n# Wave: {wave-title}\n\n**Date:** {YYYY-MM-DD}\n**Dispatcher:** {δ-identity}  \n**Repo:** {repo-path}\n\n## Issues (run in order)\n\n| Order | # | Title | ACs | Type | Dependencies |\n|-------|---|-------|-----|------|--------------|\n| 1 | {N1} | {title1} | {ac-count1} | {type1} | — |\n| 2 | {N2} | {title2} | {ac-count2} | {type2} | #{N1} |\n| 3 | {N3} | {title3} | {ac-count3} | {type3} | #{N1}, #{N2} |\n\n## Standing permissions\n\n- Push to cycle branches: {yes|no}\n- Push merges to main: {yes|no}\n- Auto-dispatch α fix rounds on REQUEST CHANGES: {yes|no} (max {N})\n- Tag\u002Frelease: {yes|no} — write to status.md only\n- Branch delete after merge: {yes|no}\n\n## Timeout budgets\n\n- γ: {N}s ({configuration-note})\n- α: {N}s  \n- β: {N}s\n\n## Dependencies\n\n{per-issue dependency description}\n```\n\n### 10.3. Wave Status Format\n\n**Wave status tracking** — `.cdd\u002Fwaves\u002F{wave-id}\u002Fstatus.md`.\n\nPer-issue status table updated by δ after each cycle closes.\n\n```markdown\n# Wave Status: {wave-title}\n\n**Last updated:** {timestamp} by δ\n\n| # | Issue | Status | Rounds | Branch | Tag | Notes |\n|---|-------|--------|--------|--------|-----|-------|\n| {N1} | {title1} | {status1} | {rounds1} | {branch-state1} | {tag-state1} | {notes1} |\n| {N2} | {title2} | {status2} | {rounds2} | {branch-state2} | {tag-state2} | {notes2} |\n\n## Status values\n\n- `⬜ queued` — not started\n- `? in-progress` — γ\u002Fα\u002Fβ active\n- `✅ completed` — merged to main\n- `❌ failed` — cycle abandoned\n- `⏸️ blocked` — waiting on dependency\n- `⭕ deferred` — explicitly moved out of wave\n```\n\n### 10.4. Wave Closure Protocol\n\n**Wave completion conditions and closure procedure.**\n\nWave is closed when:\n1. **All issues completed** or explicitly deferred\n2. **Status.md final** — all entries show terminal state (completed\u002Ffailed\u002Fdeferred)  \n3. **Wave-closeout.md written** with aggregate stats and findings\n\n**Closure algorithm:**\n1. **Verify completion** — every manifest issue has terminal status  \n2. **Write wave-closeout.md** — wave summary, aggregate metrics, cross-wave findings\n3. **Finalize status.md** — add wave closure timestamp, mark final\n4. **Signal closure** — wave coordination complete, artifacts durable\n\n### 10.5. δ Wave Reporting Format  \n\n**Wave status table emitted by δ.** Parallel to γ's TLDR (§2.11) but wave-scoped.\n\n| # | Issue | Status | Rounds | Notes |\n|---|-------|--------|--------|-------|\n| {N} | {title} | {status} | {round-count} | {notes} |\n\n**Status icons:**\n- `⬜ queued` — not started  \n- `? in-progress` — cycle active\n- `✅ completed` — merged, tagged\n- `❌ failed` — cycle abandoned\n- `⏸️ blocked` — dependency wait\n- `⭕ deferred` — moved out of wave\n\n**Emit frequency:**\n- After each cycle completion  \n- On operator request\n- At wave closure\n\n### 10.6. Iteration Artifact Lifecycle\n\n**Three-stage lifecycle for wave iteration findings.**\n\nWave iteration files (like `.cdd\u002Fiterations\u002Fwave-2026-05-12.md`) track cross-cycle findings and their dispositions through wave execution and into release.\n\n**Stage 1: Per-issue close**\n- Wave iteration file's disposition column updated with issue numbers or commit SHAs\n- Each finding gets: `filed #{N}`, `patched {SHA}`, `deferred`, or `no-action`\n- Updated as each wave issue closes\n\n**Stage 2: Wave close**  \n- Wave iteration file moves to `.cdd\u002Fwaves\u002F{wave-id}\u002Fiteration.md`\n- Dispositions finalized, no further updates\n- Wave-closeout.md cross-references iteration.md\n- Iteration.md becomes part of durable wave record\n\n**Stage 3: Release boundary**\n- Findings that produced MCAs (Major Change Approvals) get cross-referenced in release PRA\n- PRA links back to specific iteration.md findings that drove release changes\n- Creates audit trail from wave findings → MCAs → release notes\n\n**File movement example:**\n```\n.cdd\u002Fiterations\u002Fwave-2026-05-12.md  \n  ↓ (wave closes)\n.cdd\u002Fwaves\u002Fhardening-2026-05-12\u002Fiteration.md\n  ↓ (release time) \n.cdd\u002Freleases\u002F3.60.0\u002Fpost-release-assessment.md (references iteration findings)\n```","# Operator (δ)\n\n## Core Principle\n\n**Coherent δ operation routes work, holds gates, and stays out of the triad's reasoning.**\n\nδ 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.\n\n> **First-time operator?** Before running the algorithm below, ensure the repository has been activated under CDD.\n> See [`cdd\u002Factivation\u002FSKILL.md`](..\u002Factivation\u002FSKILL.md) for the one-time bootstrap: `.cdd\u002F` scaffold, version\n> pin, identity convention setup, and the §24 verification command that confirms activation is complete.\n\n## Algorithm\n\n1. **Dispatch γ** — δ dispatches γ via the harness; γ reads the issue, creates the cycle branch, and produces α\u002Fβ prompts. See `harness\u002FSKILL.md` §1 for invocation mechanics.\n2. **Dispatch α** — δ dispatches α via the harness with the prompt γ produced; α implements on the cycle branch and exits after signaling review-readiness.\n3. **Dispatch β** — δ dispatches β via the harness with the prompt γ produced; β reviews, merges, writes β close-out, and exits.\n4. **Re-dispatch α for fix rounds** (when β returns RC) — δ dispatches α via the harness with the fix-round re-dispatch prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\"; prompt format in §5.2 of this file); α fixes findings, appends fix-round to self-coherence.md, exits.\n5. **Re-dispatch α for close-out** (when γ requests after β merge) — δ dispatches α via the harness with the close-out re-dispatch prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n6. **Gate** — execute external actions: push main, tag, release, branch deletes. **Do not tag\u002Frelease before `gamma-closeout.md` exists on main.** Disconnect-release mechanics live in [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md) (Phase 4c of cnos#366, cycle\u002F399); 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).\n7. **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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §3; this step is operator-as-coordinator routing the override declaration through the cycle.\n\nδ 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\u002FSKILL.md` §2), and isolates failures — if α dies, δ retries α without losing γ or β state.\n\n---\n\n## Git identity for role actors\n\nThe 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\u002FSKILL.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.\n\n---\n\n## 1. Route\n\n### 1.1. Dispatch γ first\n\nδ dispatches γ. γ reads the issue, creates the cycle branch, and returns α\u002Fβ prompts to δ. γ does not execute dispatch — δ does.\n\n### 1.2. Dispatch α and β sequentially\n\nδ dispatches α, waits for completion, then dispatches β. One role at a time.\n\nThe invocation shell, observability flags, and permission-mode requirement are codified in `harness\u002FSKILL.md` §1 (Dispatch invocation) and §2 (Dispatch observability contract). δ honors that contract; this section names the routing discipline.\n\n- ❌ Rewrite the prompt to add constraints or context γ didn't include\n- ✅ Deliver the prompt verbatim to the dispatched session (harness contract)\n- ❌ Run α and β concurrently or nest them inside γ's session\n- ✅ Run one role at a time, inspect artifacts between dispatches\n- ✅ Name the agent-to-role mapping before delivering prompts\n\n---\n\n## 2. Wait\n\n### 2.1. Do not poll internal work\n\nOnce dispatched, the triad runs. The operator does not need to monitor branch diffs, `.cdd\u002Funreleased\u002F{N}\u002F` files, or CI runs — γ owns that.\n\nThe operator's wake-up signals are:\n\n- **γ requests an external gate** (push on β's behalf, tag push, release, deploy, issue filing, auth action)\n- **γ requests an unblock decision** (design ambiguity, scope question, env constraint)\n- **γ declares cycle closure** and names deferred outputs that need operator action\n- **An agent session dies or stalls** (no activity for an unexpected duration)\n\nBetween these signals, the operator's correct action is nothing.\n\n- ❌ Check the branch every 30 minutes and suggest changes (role leak into β)\n- ❌ Heartbeat reveals cycle state (tag missing, branches exist) → δ acts on it (observation is not a gate request)\n- ✅ Wait for γ to surface a gate or decision request\n- ✅ Heartbeat reveals cycle state → δ notes it, waits for γ\n\n### 2.2. Subscribe to the issue\n\nPoll the issue and cycle branches for activity using the same transition-only pattern as the triad (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nThe polling loop mechanics (issue-activity poller, multi-branch poller with reachability re-probe) live in `harness\u002FSKILL.md` §5 (Polling and wake-up). δ uses those forms under `Monitor` or equivalent. Canonical cycle branches are `origin\u002Fcycle\u002F{N}` (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Branch rule\", since #287); the pre-#287 `'origin\u002Fclaude\u002F*'` glob is warn-only \u002F retrospective per harness §5.3.\n\n---\n\n## 3. Gate\n\n> **δ-as-role boundary policy lives in [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md).** This section retains the gate-policy doctrine that `operator\u002FSKILL.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\u002FSKILL.md` §1 \"Outward membrane\" and §3 \"Override.\" **Dispatch-coordinator mechanics** (the `claude -p` \u002F `cn dispatch` invocation, observability flags, worktree management, identity discipline) live in [`harness\u002FSKILL.md`](..\u002Fharness\u002FSKILL.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\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md) per Phase 4c of cnos#366 (cycle\u002F399).\n\n### 3.1. External actions the operator executes on δ-the-role's authority\n\nThe actions in this table require platform permissions agents may lack. **δ-as-role authorises** these actions per [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.1; operator-as-coordinator dispatches them on request from γ, β, or α-via-γ:\n\n| Action | Trigger | Who requests |\n|--------|---------|-------------|\n| Pre-merge gate validation | Before authorizing β merge, run `scripts\u002Fvalidate-release-gate.sh --mode pre-merge` to verify cycle artifacts exist and are well-formed. See `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Artifact contract\" → §\"Ownership matrix\" and `gamma\u002FSKILL.md` §2.10. | γ |\n| Push β-approved merge to main | β runs `git merge` — δ only pushes when β cannot execute the push directly (env\u002Fauth constraint). This is execution of β's integration authority, not δ approval. | β or γ |\n| Release-boundary preflight | After β merge + close-outs + γ PRA, δ verifies merge commit, release artifacts, tag\u002Fdeploy preconditions, and platform readiness. Proceed \u002F request changes \u002F override. See `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" Step 9 (δ gate). | γ |\n| 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\u002FSKILL.md` §1.1) | γ |\n| Branch delete | Cycle closed, merged branches | γ |\n| Issue filing on external repos | Cross-project dependency | γ |\n| Force push | Rebase required with env constraints | α via γ |\n| Auth refresh | Token\u002Fpermission expiry | any role via γ |\n\n### 3.2. Execute on request, not on observation\n\nGate 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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.2.)\n\n- ❌ Heartbeat shows tag not pushed → δ pushes it (role leak: δ decided the gate, not γ)\n- ❌ \"β asked me to push the merge but I think we should wait for one more review\"\n- ✅ γ requests tag push → δ pushes it and confirms\n- ✅ If you disagree with a gate request, declare an override per [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §3\n\n### 3.3. Report completion\n\nAfter executing a gate action, confirm to the requesting role that the action completed. (Role-policy framing: [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.3.)\n\n- ❌ Execute silently and assume the triad will notice\n- ✅ \"Tag pushed: `git push origin 3.59.0` — confirmed on remote\"\n\n### 3.4. Cut the release — disconnect the triad's final state\n\nAfter 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.\n\n> **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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.1.** **Mechanics** (the single-command release script invocation, post-push CI polling, the recovery runbook, branch deletes) **live in [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md)** — Phase 4c of cnos#366 (cycle\u002F399) relocated them out of this section.\n\nThe 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.\n\nThat skill owns: the single-command release script invocation, the bare-`X.Y.Z` tag policy (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nTwo gate-rules δ enforces from this surface (the policy-level claims; mechanics in the effector skill):\n\n- **Do not tag\u002Frelease before `gamma-closeout.md` exists on main.**\n- **δ blocks release completion until CI is green** (or operator explicitly accepts a known pre-existing failure per the release-effector recovery runbook).\n\n### 3.5. The tag is the signal\n\nThe 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.\n\nFor mid-cycle gate actions (per [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.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\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §1.4.)\n\n---\n\n## 3a. δ as inward membrane: implementation-contract enrichment at dispatch\n\n**Canonical doctrine lives at [`cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md`](..\u002F..\u002F..\u002F..\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md) §\"δ as inward membrane\"** (Sub 3 of [cnos#404](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F404), shipped under [cnos#417](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F417)). That skill owns the 7 implementation-contract axes, δ's review-before-routing duty, the fill-or-escalate paths, the four-surface mesh (γ template \u002F δ enrichment \u002F α constraint \u002F β verification), and the cnos#389\u002F#391\u002F#392\u002F#393 empirical anchors. The role-local realization continues to live at [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §2 (the inward-membrane half of δ's two-sided framing; outward half at §1; override at §3). `operator\u002FSKILL.md` retains operator-as-coordinator + harness mechanics only; the doctrine lives at handoff and the role-local pointer lives in `delta\u002FSKILL.md`.\n\n---\n\n## 4. Override\n\n**Relocated to [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.md) §3 \"Override — degraded boundary action\" as Phase 4a of cnos#366** (cycle\u002F397). 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\u002FSKILL.md`. The dispatch-coordinator side (\"when α\u002Fβ\u002Fγ 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.\n\nFor 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\u002FSKILL.md` §3.\n\n---\n\n## 5. Dispatch configurations\n\nCDD defines two valid dispatch configurations. Choose one before dispatching; record it in `gamma-closeout.md`.\n\n### 5.1 Canonical multi-session dispatch\n\nOne dispatched process per role (via the harness — see `harness\u002FSKILL.md` §1); each has an independent auth context and no shared memory. This is the model described in §1.2 above.\n\n- γ\u002Fδ 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.\n- Sub-agent returns do not apply — each dispatched session exits cleanly; the operator reads committed artifacts.\n- Branch names are stable: `cycle\u002F{N}` persists through all fix rounds because each role session checks it out fresh.\n\nUse this configuration when the cycle is substantial (see §5.3 escalation criteria).\n\n### 5.2 Single-session δ-as-γ via Agent tool (Claude Code activation)\n\nWhen 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.\n\n**Scope of the collapse.** §5.2 collapses **δ↔γ only**. γ↔α↔β remain structurally separate per the triadic rule (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nA single sub-agent that performs γ-selection plus α-implementation plus β-review is not §5.2 — it is a triadic-rule violation (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.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.\n\nThree structural consequences follow:\n\n1. **δ=γ collapse.** γ\u002Fδ separation is structurally absent: one parent session holds both the selection\u002Fscaffolding function (γ) and the external gate authority (δ). The cycle proceeds, but the grading floor in §3.8 of `release\u002FSKILL.md` applies — see §3.8 configuration-floor clause.\n\nFor the general principle governing when role collapses are safe, see `ROLES.md §4` (hats-vs-actors: independence as the collapse constraint).\n\n2. **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.\n\n3. **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\u002F{N}` → `cycle\u002F{N}-impl` → `cycle\u002F{N}-impl-r2` → `cycle\u002F{N}-impl-r3` → `cycle\u002F{N}-merged` → `cycle\u002F{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.\n\n**Empirical anchors:** The cnos-tsc supercycle (cycles 24–26, close-outs at `usurobor\u002Ftsc:.cdd\u002Freleases\u002F{0.5.0,0.6.0,0.7.0}\u002F{24,25,26}\u002Fgamma-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\u002Ftsc:.cdd\u002Freleases\u002Fdocs\u002F2026-05-09\u002F32\u002Fgamma-closeout.md`) ran §5.2 and produced a five-link branch trail (`cycle\u002F32` → `cycle\u002F32-impl` → `cycle\u002F32-impl-r2` → `cycle\u002F32-merged` → `cycle\u002F32-final`) due to harness push restrictions; that trail is the source observation for consequence (3) above.\n\n**Reference dependencies:** §5.2 dispatch sizing follows `cnos.cds\u002Fskills\u002Fcds\u002FCDS.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\u002FSKILL.md §2.1`) an operator-side action when β cannot push directly (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Development lifecycle\" → §\"Step table\" Step 8 — β review and merge).\n\n**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\u002Fwaves\u002F{wave-id}\u002Fmanifest.md`, *not* a per-sub `.cdd\u002Funreleased\u002F{N}\u002Fgamma-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\u002FSKILL.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\u002Fwaves\u002F{wave-id}\u002Fmanifest.md` or the wave title in a `## Wave` \u002F `## Source` \u002F `## 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)\u002F(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\u002Fcph#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\u002Fcph:.cdd\u002Fiterations\u002Fwave-2026-05-18.md` Finding F1.*\n\n### 5.2.1 Parent-session quiescence during sub-agent runs\n\nWhen a sub-agent dispatch is in flight (via the Agent tool), the parent session MUST enter quiescent mode:\n\n**Prohibited during sub-agent runs:**\n- **No file edits** in the working tree\n- **No commits** from the parent session\n- **No branch switches** (`git checkout`, `git switch`)\n- **No `git add` \u002F `git restore --staged`** (index state must remain stable for the sub-agent's view)\n- **No `git pull` \u002F `git fetch` that updates the current branch HEAD**\n\n**Permitted during sub-agent runs:**\n- Reads: `git status`, `git log`, `git diff`, file reads via Read tool, web fetches, GitHub MCP queries\n- Coordination: dispatching additional sub-agents (each gets its own context; isolation is by sub-agent), reading existing branches via `git fetch \u003Cbranch>` (does not update HEAD)\n- **Filesystem operations on paths outside the repo** (e.g., `\u002Ftmp`, drafts)\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n### 5.3 Escalation criteria\n\nSwitch from §5.2 to §5.1 (multi-session) when any of the following is true at γ scaffold time:\n\n- **≥7 ACs** in the cycle (complexity exceeds what a single-session coordinator can reliably hold across sub-agent round-trips)\n- **New contract surface or cross-repo deliverables** (γ\u002Fδ separation matters for audit when external systems are affected)\n- **≥3 β rounds expected** (multiple fix-round re-dispatches compound the branch-name churn problem under §5.2 harness constraints)\n- **≥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)\n\n---\n\n## 6. What the operator does NOT do\n\nThese are role boundaries. Crossing them without an override declaration breaks the coherence record.\n\n- **Do not implement.** That's α. If you want to fix something, declare an override and take the α role explicitly.\n- **Do not review.** That's β. If you disagree with β's verdict, declare an override.\n- **Do not triage findings.** That's γ. If you want a finding handled differently, tell γ.\n- **Do not rewrite prompts.** γ owns prompt quality. If the prompt is weak, tell γ to fix the issue.\n- **Do not merge without β's approval.** The merge gate fires when β says it's ready, not before.\n- **Do not communicate directly with α or β during in-cycle work.** γ is the bridge. δ-to-γ, γ-to-α\u002Fβ. δ remains external to the triad; γ is the operator's only in-cycle counterparty.\n\n---\n\n## 7. Cycle lifecycle from the operator's view\n\n| Phase | Operator action | Wait for |\n|-------|----------------|----------|\n| γ dispatch | Dispatch γ via the harness (see `harness\u002FSKILL.md` §1); γ creates branch, returns α\u002Fβ prompts | γ completion |\n| α dispatch | Dispatch α via the harness with γ's prompt | α completion (exits after review-readiness) |\n| β dispatch | Dispatch β via the harness with γ's prompt | β completion (merge + β close-out) |\n| α fix-round re-dispatch | Dispatch α via the harness with fix-round prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\"; prompt format in §5.2 of this file) when β returns RC | α completion (exits after fix-round) |\n| α close-out re-dispatch | Dispatch α via the harness with close-out prompt (`cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Coordination surfaces\"; prompt format in §5.2 of this file) when γ requests | α completion (alpha-closeout.md on main) |\n| Release prep | γ writes RELEASE.md, moves cycle dirs; δ holds until complete | γ request |\n| δ preflight | Verify merge commit, release artifacts, tag preconditions | γ preflight request |\n| Closure | Gate: do not tag before `gamma-closeout.md` exists on main | γ closure declaration (gamma-closeout.md) |\n| Disconnect | Cut the release — see [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md) | γ close-out + δ session patches on main |\n| Post-release | Execute deferred operator actions from γ close-out | γ deferred-output list |\n| Inter-cycle | Nothing until next γ dispatch | γ next-cycle selection |\n\n---\n\n## 8. Timeout recovery\n\nWhen a dispatched session SIGTERMs, hits a timeout, or crashes before committing, δ runs the worktree inspection + decision-tree recovery procedure codified in `harness\u002FSKILL.md` §6 (Timeout recovery). The procedure is mechanics; the doctrine surfaces that depend on it stay here:\n\n- **Override declaration.** If δ commits work on behalf of an agent, this is an implicit override; δ declares it per [`delta\u002FSKILL.md`](..\u002Fdelta\u002FSKILL.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.\n- **Grade implication.** A cycle with operator-identity recovery commits is a cycle with operator override; per `release\u002FSKILL.md §3.8`, the γ-axis grade reflects the override.\n- **Prevention.** The recovery procedure is the failure path; the prevention path is a correctly-sized dispatch budget per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md` §\"Field 6: Actor collapse rule\" (heuristic constants in this file's §5.2). Record budget\u002FAC count in PRA telemetry (`post-release\u002FSKILL.md` §4) so the heuristic refines.\n- **Close-state assertion parity.** If recovery carries a SIGTERM-terminated cycle through to a merge, δ MUST run the same close-state hard gate a normal γ close-out runs (`gamma\u002FSKILL.md §2.10` row 15: `gh issue view {N} --json state --jq .state` MUST return `CLOSED`) before declaring the recovered cycle closed — mechanics at `harness\u002FSKILL.md` §6.6. Recovery changes who runs the closure gate, not whether it runs.\n\n---\n\n## 9. Embedded Kata\n\n### Kata A — Normal cycle\n\n#### Scenario\n\nγ has dispatched α and β prompts for issue #230. You have two agent sessions available.\n\n#### Task\n\nExecute the operator role through the full cycle.\n\n#### Expected actions\n\n1. Confirm agent-to-role mapping\n2. Deliver α prompt to session A, β prompt to session B\n3. Wait\n4. When β requests merge: execute merge\n5. When γ requests tag push: execute tag push\n6. When γ declares closure: cut the release per [`release-effector\u002FSKILL.md`](..\u002Frelease-effector\u002FSKILL.md)\n7. Execute any deferred operator actions from γ's close-out\n\n#### Common failures\n\n- Checking the branch during review and suggesting changes (role leak into β)\n- Merging before β approves (gate fired early)\n- Rewriting γ's prompts before delivering (role leak into γ)\n\n### Kata B — Override\n\n#### Scenario\n\nα 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.\n\n#### Task\n\nDecide whether to override and, if so, execute the protocol.\n\n#### Expected answer\n\n- 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.\n- Or: provide the missing API documentation as an artifact fact (not implementation direction), which γ can add to the issue. This is unblocking, not override.\n\n#### Reflection\n\n- Did you route through γ, or did you talk directly to α? (Should route through γ unless γ is unavailable.)\n- Did you declare the override explicitly, or did you quietly adjust scope?\n\n---\n\n## 10. Wave Coordination\n\n**Multi-cycle coordination primitive for sequences of related issues.**\n\nWhen δ 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 `\u002Ftmp` files.\n\n### 10.1. δ Wave Dispatch Template\n\n**Wave dispatch prompt template for δ-as-agent.** Parallel to α\u002Fβ templates in `gamma\u002FSKILL.md` §2.5. Takes wave manifest as input, produces γ prompts per issue.\n\n```markdown\n# δ Wave Dispatch — {wave-name}\n\nYou are δ (operator) for CDD wave coordination.\n\n## Load Order (mandatory)\n\n1. Read `src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Foperator\u002FSKILL.md` — canonical δ algorithm\n2. Read wave manifest at `.cdd\u002Fwaves\u002F{wave-id}\u002Fmanifest.md` — issue order, dependencies, permissions\n3. Read wave status at `.cdd\u002Fwaves\u002F{wave-id}\u002Fstatus.md` — current per-issue state\n\n## Context\n\n- **Wave:** {wave-name}\n- **Wave ID:** {wave-id} \n- **Repo:** {repo-path}\n- **Issues in scope:** {issue-list}\n\n## Algorithm\n\n1. **Initialize wave directory** — create `.cdd\u002Fwaves\u002F{wave-id}\u002F` if it doesn't exist\n2. **Update wave status** — write current state to `status.md` (queued → in-progress for next issue)  \n3. **Select next issue** — per manifest order and dependency constraints\n4. **Dispatch γ** — create issue-specific γ prompt using manifest permissions and timeouts\n5. **Monitor cycle** — poll `origin\u002Fcycle\u002F{N}` and `.cdd\u002Funreleased\u002F{N}\u002F` for completion\n6. **Update wave status** — mark cycle completed\u002Ffailed, update rounds, notes\n7. **Repeat or close** — continue with next issue or close wave when complete\n\n## Wave permissions from manifest\n\n- Push to cycle branches: {push-cycles}\n- Push merges to main: {push-main}  \n- Auto-dispatch α fix rounds: {auto-fix} (max {fix-max})\n- Tag\u002Frelease: {tag-release}\n- Branch delete after merge: {branch-delete}\n\n## Standing instructions\n\n- Update `.cdd\u002Fwaves\u002F{wave-id}\u002Fstatus.md` after each cycle completion\n- Emit wave status table on operator request  \n- Close wave when all issues completed\u002Fdeferred per manifest\n- Write `.cdd\u002Fwaves\u002F{wave-id}\u002Fwave-closeout.md` at wave end\n\nSignal completion when wave is closed or blocked.\n```\n\n### 10.2. Wave Manifest Format\n\n**Canonical wave manifest** — `.cdd\u002Fwaves\u002F{wave-id}\u002Fmanifest.md`.\n\nContains issue list, execution order, dependency constraints, standing permissions, timeout budgets.\n\n```markdown\n# Wave: {wave-title}\n\n**Date:** {YYYY-MM-DD}\n**Dispatcher:** {δ-identity}  \n**Repo:** {repo-path}\n\n## Issues (run in order)\n\n| Order | # | Title | ACs | Type | Dependencies |\n|-------|---|-------|-----|------|--------------|\n| 1 | {N1} | {title1} | {ac-count1} | {type1} | — |\n| 2 | {N2} | {title2} | {ac-count2} | {type2} | #{N1} |\n| 3 | {N3} | {title3} | {ac-count3} | {type3} | #{N1}, #{N2} |\n\n## Standing permissions\n\n- Push to cycle branches: {yes|no}\n- Push merges to main: {yes|no}\n- Auto-dispatch α fix rounds on REQUEST CHANGES: {yes|no} (max {N})\n- Tag\u002Frelease: {yes|no} — write to status.md only\n- Branch delete after merge: {yes|no}\n\n## Timeout budgets\n\n- γ: {N}s ({configuration-note})\n- α: {N}s  \n- β: {N}s\n\n## Dependencies\n\n{per-issue dependency description}\n```\n\n### 10.3. Wave Status Format\n\n**Wave status tracking** — `.cdd\u002Fwaves\u002F{wave-id}\u002Fstatus.md`.\n\nPer-issue status table updated by δ after each cycle closes.\n\n```markdown\n# Wave Status: {wave-title}\n\n**Last updated:** {timestamp} by δ\n\n| # | Issue | Status | Rounds | Branch | Tag | Notes |\n|---|-------|--------|--------|--------|-----|-------|\n| {N1} | {title1} | {status1} | {rounds1} | {branch-state1} | {tag-state1} | {notes1} |\n| {N2} | {title2} | {status2} | {rounds2} | {branch-state2} | {tag-state2} | {notes2} |\n\n## Status values\n\n- `⬜ queued` — not started\n- `? in-progress` — γ\u002Fα\u002Fβ active\n- `✅ completed` — merged to main\n- `❌ failed` — cycle abandoned\n- `⏸️ blocked` — waiting on dependency\n- `⭕ deferred` — explicitly moved out of wave\n```\n\n### 10.4. Wave Closure Protocol\n\n**Wave completion conditions and closure procedure.**\n\nWave is closed when:\n1. **All issues completed** or explicitly deferred\n2. **Status.md final** — all entries show terminal state (completed\u002Ffailed\u002Fdeferred)  \n3. **Wave-closeout.md written** with aggregate stats and findings\n\n**Closure algorithm:**\n1. **Verify completion** — every manifest issue has terminal status  \n2. **Write wave-closeout.md** — wave summary, aggregate metrics, cross-wave findings\n3. **Finalize status.md** — add wave closure timestamp, mark final\n4. **Signal closure** — wave coordination complete, artifacts durable\n\n### 10.5. δ Wave Reporting Format  \n\n**Wave status table emitted by δ.** Parallel to γ's TLDR (§2.11) but wave-scoped.\n\n| # | Issue | Status | Rounds | Notes |\n|---|-------|--------|--------|-------|\n| {N} | {title} | {status} | {round-count} | {notes} |\n\n**Status icons:**\n- `⬜ queued` — not started  \n- `? in-progress` — cycle active\n- `✅ completed` — merged, tagged\n- `❌ failed` — cycle abandoned\n- `⏸️ blocked` — dependency wait\n- `⭕ deferred` — moved out of wave\n\n**Emit frequency:**\n- After each cycle completion  \n- On operator request\n- At wave closure\n\n### 10.6. Iteration Artifact Lifecycle\n\n**Three-stage lifecycle for wave iteration findings.**\n\nWave iteration files (like `.cdd\u002Fiterations\u002Fwave-2026-05-12.md`) track cross-cycle findings and their dispositions through wave execution and into release.\n\n**Stage 1: Per-issue close**\n- Wave iteration file's disposition column updated with issue numbers or commit SHAs\n- Each finding gets: `filed #{N}`, `patched {SHA}`, `deferred`, or `no-action`\n- Updated as each wave issue closes\n\n**Stage 2: Wave close**  \n- Wave iteration file moves to `.cdd\u002Fwaves\u002F{wave-id}\u002Fiteration.md`\n- Dispositions finalized, no further updates\n- Wave-closeout.md cross-references iteration.md\n- Iteration.md becomes part of durable wave record\n\n**Stage 3: Release boundary**\n- Findings that produced MCAs (Major Change Approvals) get cross-referenced in release PRA\n- PRA links back to specific iteration.md findings that drove release changes\n- Creates audit trail from wave findings → MCAs → release notes\n\n**File movement example:**\n```\n.cdd\u002Fiterations\u002Fwave-2026-05-12.md  \n  ↓ (wave closes)\n.cdd\u002Fwaves\u002Fhardening-2026-05-12\u002Fiteration.md\n  ↓ (release time) \n.cdd\u002Freleases\u002F3.60.0\u002Fpost-release-assessment.md (references iteration findings)\n```",{"name":5,"calls":45,"scope":48,"inputs":49,"parent":26,"outputs":53,"requires":57,"triggers":60,"visibility":62,"description":7,"kata_surface":30,"artifact_class":63,"governing_question":64},[46,47],"gamma\u002FSKILL.md","harness\u002FSKILL.md","role-local",[50,51,52],"γ dispatch prompts","external gate requests from α\u002Fβ\u002Fγ","cycle state (issue, branch, .cdd\u002Funreleased\u002F{N}\u002F, CI)",[54,55,56],"routed prompts to agent sessions","external gate executions and confirmations (push on β's behalf, tag, release, deploy, issue filing)","override declarations when needed",[58,59],"active CDD cycle exists","γ has produced dispatch prompts",[5,31,27,61],"unblock","internal","skill","What does the operator do — and not do — during an active CDD cycle?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Foperator",0,"https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos","https:\u002F\u002Fgithub.com\u002Fusurobor","Coherence engineer. Building git-CN.","2026-11-07 14:25:44",{"source":8,"skillName":5,"commands":74,"prompt":84,"zipAvailable":85},[75,78,81],{"tool":76,"command":77},"npx","npx skills add usurobor\u002Fcnos --skill operator",{"tool":79,"command":80},"bunx","bunx skills add usurobor\u002Fcnos --skill operator",{"tool":82,"command":83},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill operator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.cdd\u002Fskills\u002Fcdd\u002Foperator\u002FSKILL.md",true,[],[88,105,121,147,162,181],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":40},"01M6CF8RWQPM0VXZG06XMR0FFX","issues\u002Ftriage","Issue triage doctrine pointer. Use when classifying a new issue, deciding dispatch eligibility, or deciding whether to close\u002Fsupersede\u002Fdefer.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftriage\u002FSKILL.md",[],[95,96,97,98,99,100,101,102,103,31,28,104],"triage","issues","issues triage","issue triage","SET","how","decision","public","use","doctrine",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":111,"publishedAt":40},"01M6CF8PJ812DD4APZ3WE8X67B","issues\u002Ftaxonomy","Issue label taxonomy pointer. Use when classifying an issue's kind\u002Farea\u002Fpriority\u002Feffort\u002Fstatus\u002Fprotocol\u002Fdispatch labels, or when the board needs to interpret them.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Ftaxonomy\u002FSKILL.md",[],[96,112,113,114,115,116,99,117,102,118,103,31,119,28,120],"taxonomy","issues taxonomy","github","status","protocol","open","board","github issue","issue labels",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":135,"publishedAt":40},"01M6CF8KBMZ4D0CDJQ3PF1YVTP","issues\u002Fmap","Issue-board (Issue Pivot) generation domain. Use when reasoning about `cn issues map`'s fetch, taxonomy-parse, effort-computation, and render pipeline, or about the board's JSON\u002FHTML output contract.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002Fskills\u002Fmap\u002FSKILL.md",[127,130],{"categoryNo":128,"categoryName":129,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":131,"categoryName":132,"taxonomyType":133,"taxonomyTypeDesc":134},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[96,136,114,137,138,139,99,140,112,117,100,141,142,118,143,144,145,146,103,28],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":148,"name":96,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":40},"01M6CF8CZQH7G7B7RZPANQWR4G","cnos.issues package entrypoint. Use when reasoning about issue taxonomy, the Issue Pivot \u002F issue-board (`cn issues map`), the read-only CDS issue-state evaluator (`cn issues fsm evaluate`), or the current command-dispatch disposition of issue tooling.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.issues\u002FSKILL.md",[],[96,114,153,154,155,156,36,157,158,112,117,100,101,32,142,159,103,160,31,161],"pr","current state","run","artifacts","package","boundary","command","only","cds",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":40},"01M6CF896XKSRQVB1CSHY8GSXB","receipt-stream","Cross-cycle receipt-stream doctrine for protocol-iteration. Use when γ closes a cycle and writes the per-cycle iteration artifact (`cdd-iteration.md`), when γ updates the cross-cycle aggregator at `.cdd\u002Fiterations\u002FINDEX.md`, when ε reads the receipt stream across cycles to surface protocol-gap patterns, when a finding's disposition lands a cross-repo patch and the cross-repo trace bundle attaches, or when a courtesy empty-findings stub is written for a `protocol_gap_count == 0` cycle.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Freceipt-stream\u002FSKILL.md",[],[169,170,156,116,171,100,172,173,174,102,175,176,177,178,103,30,179,180,26,104],"receipt stream","handoff","index","learning","format","trace","repo","closeout","read","channel","patch","shape",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":40},"01M6CF84VCBME6RK8V6HAVDM8Z","mid-flight","Mid-flight γ→in-flight-α rescue channel. Use when γ needs to change a load-bearing fact (pinned axis, scope, AC, blocker) after α has begun coding, when γ edits the cycle's GitHub issue body mid-cycle, or when a spec change lands on origin\u002Fmain while α\u002Fβ polling sessions are in-flight.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight\u002FSKILL.md",[],[188,114,189,33,190,191,100,192,193,32,175,177,103,160,31,194,119,195,25,196],"mid flight","change","file","cache","pin","coordination","up","Legacy","artifact channel"]