[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CF84VCBME6RK8V6HAVDM8Z":3,"skill-same:01M6CF84VCBME6RK8V6HAVDM8Z":184},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":72,"commitSha":73,"skillDirectory":74,"forksCount":75,"repositoryHtmlUrl":76,"repositoryHomepageUrl":6,"ownerHtmlUrl":77,"ownerBlogUrl":6,"ownerDescription":78,"updatedAt":79,"install":80,"resources":93},"01M6CF84VCBME6RK8V6HAVDM8Z","mid-flight",null,"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.","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.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"mid flight","read","artifact channel","gamma","Legacy","github issue","up","dispatch","only","use","github","repo","branch","coordination","pin","how","cache","file","sessions","change","2026-11-10 10:12:30",false,"---\nname: mid-flight\ndescription: 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.\nartifact_class: skill\nkata_surface: embedded\ngoverning_question: How does γ change a load-bearing fact mid-cycle without abandoning the branch — naming the change in the cycle's artifact channel so in-flight α\u002Fβ cache-bust and re-converge, rather than chat-relaying or silently mutating the contract?\nvisibility: public\nparent: handoff\ntriggers:\n  - mid-flight\n  - gamma-clarification\n  - issue-edit\n  - cache-bust\n  - rescue\n  - re-pin\n  - spec-staleness\nscope: task-local\ninputs:\n  - active CDD-class cycle with α and\u002For β in-flight on origin\u002Fcycle\u002F{N}\n  - the load-bearing change γ needs to signal (axis re-pin, scope clarification, AC clarification, blocker resolution, issue-body edit, spec change on origin\u002Fmain)\noutputs:\n  - .cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md entry on origin\u002Fcycle\u002F{N} (substantive content of the change)\n  - cycle-branch SHA transition (the wake-up signal)\n  - .cdd\u002Funreleased\u002F{N}\u002Fgamma-coordination.md entry (legacy long-lived polling sessions only; spec-staleness propagation)\nrequires:\n  - cycle\u002F{N} exists on origin with at least one in-flight role\n  - the load-bearing change has been (or is about to be) committed in some other surface (issue body, origin\u002Fmain spec file) that the in-flight role's cached read would miss\ncalls:\n  - HANDOFF.md\n  - artifact-channel\u002FSKILL.md\n  - dispatch\u002FSKILL.md\n  - cross-repo\u002FSKILL.md\n---\n\n# Mid-Flight Rescue — γ → in-flight α\u002Fβ re-pinning channel\n\n## Core principle\n\n**A mid-flight change to a load-bearing fact transits the cycle's artifact channel, not chat. γ writes the substance to `.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` on `cycle\u002F{N}` *before* the change becomes visible elsewhere; the cycle-branch SHA transition is the wake-up signal that bursts in-flight α\u002Fβ caches. The mechanism is bounded recovery — a structural escape valve when γ under-specified at dispatch time — not a substitute for clean dispatch.**\n\nThe mid-flight rescue is the wire format γ uses when something the cycle relied on changes after dispatch. The thing that changed may be (1) a pinned implementation-contract axis γ realizes was wrong, (2) an AC γ realizes was ambiguous, (3) a non-goal γ realizes was load-bearing, (4) the issue body itself (γ edited it because α surfaced an ambiguity or δ refined an axis), or (5) a spec file on `origin\u002Fmain` whose change ripples into the cycle's loaded skill snapshot. In all cases, an in-flight α or β session may be operating on a cached read of the prior state — chat will not reach them; only artifact-channel writes will.\n\nThe failure mode is **silent re-pin** — γ edits the issue body, or pushes a spec change to main, or mutates a contract row, without writing `gamma-clarification.md`. In-flight α\u002Fβ keep working from cached state, finish on the old contract, and ship the wrong shape. β's Rule 7 verification cannot adjudicate \"which contract is canonical\" when γ's mutation left no trail. The result is a cycle that satisfies the *new* contract by accident (or doesn't), with no audit trail for which decision happened when.\n\nThis skill is the **canonical surface** for the rescue mechanism: file path, authoring role, reader role, trigger conditions, cache-bust semantics, and the empirical anchors. Consumer protocol packages (cnos.cdd, cnos.cds, future c-d-X) cite this skill; the **operational realization** (the `gh issue edit` + `git commit` + `git push` shell sequence γ runs at clarification time) stays in `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` as the v0.1 overlay. The wire-format invariant lives here; the v0.1 software-cycle realization stays at cds.\n\n## Authority\n\n- This skill (in `cnos.handoff`) is the only canonical home for the mid-flight rescue mechanism's wire format: the file path, the authoring\u002Freader roles, the trigger conditions, the cache-bust function, the spec-staleness propagation invariant. If another skill or doctrine surface carries the same wire-format claims, this skill governs.\n- The consumer protocol packages govern the operational realization: `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` carries the post-#411 software-cycle realization (the shell sequence and the polling mapping); `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002FSKILL.md §2.5 → \"Spec-staleness propagation\"` carries the consumer-specific file list (which cdd skill files trigger propagation). Both cite this skill for the wire-format invariant.\n- The `gamma-clarification.md` artifact lives on the channel substrate; channel rules (per-role write ownership, frozen-snapshot rule on merge, sequential α→β→γ flow) are at `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md`. This skill cites the channel; the channel does not redefine the rescue protocol.\n\n## Scope\n\nIn scope:\n\n- The `gamma-clarification.md` file format and authoring contract (file path, authoring role, content sections, commit + push sequence).\n- The wake-up \u002F cache-bust semantics (cycle-branch SHA transition is the signal; not the GitHub issue mtime, which is invisible to MCP-cached reads).\n- Reader role obligations (in-flight α\u002Fβ polling sessions detect the write; re-read the issue body live via `gh issue view`; re-load any other source γ named in the clarification).\n- The resumption protocol (in-flight α\u002Fβ acknowledge in their own artifact, re-scope, escalate, or stop).\n- The spec-staleness propagation invariant (γ writes a coordination note when spec changes land on origin\u002Fmain mid-cycle).\n- Empirical anchors (cnos#391 rescue; cnos#392 recovery).\n\nOut of scope:\n\n- The cycle-lifecycle role-skill obligations of α (intake; pre-implementation surface; review-readiness signal) and β (review CLP; verdict cadence). Those live in `cnos.cdd\u002Fskills\u002Fcdd\u002F{alpha,beta}\u002FSKILL.md` and are consumers of this wire format.\n- The per-artifact channel rules (write ownership, sequential flow, frozen-snapshot). Those live in `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md`. This skill cites the channel as the substrate `gamma-clarification.md` lives on.\n- The dispatch-time implementation-contract enrichment (δ-as-inward-membrane review before routing). That lives in `cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md §3`. This skill picks up where dispatch leaves off — once α is routed, dispatch's enforcement window closes; mid-flight is the post-dispatch channel.\n- The operational shell sequence γ runs (`gh issue edit` + `git commit` + `git push`). That stays at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` as the v0.1 software-cycle realization overlay.\n- The harness substrate (polling primitives, Monitor wrapping, reachability re-probe). That lives in `cnos.cdd\u002Fskills\u002Fcdd\u002Fharness\u002FSKILL.md` per Phase 4b of cnos#366.\n- The cross-repo proposal lifecycle. Cited from this skill (issue-body edits propagating to in-flight intake sessions are the same mechanism); the lifecycle itself is at `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md`.\n\n---\n\n## 1. Define\n\n### 1.1. What a mid-flight rescue is\n\nA mid-flight rescue is **one γ-authored file** (`gamma-clarification.md`) written to the cycle's artifact-channel directory (`.cdd\u002Funreleased\u002F{N}\u002F`) on the cycle branch (`origin\u002Fcycle\u002F{N}`), committed and pushed *before* the change becomes visible in any other surface the in-flight role might read. It carries:\n\n- the change (axis re-pin \u002F scope clarification \u002F AC clarification \u002F blocker resolution \u002F issue-body edit summary \u002F spec-change pointer),\n- the date,\n- the impact (which ACs \u002F non-goals \u002F constraints \u002F artifacts the change affects),\n- the rationale (typically: a repo-convention emerged; a downstream consumer surfaced; an operator override; α surfaced an ambiguity; β found a wrong-shape implementation; a spec change landed on main).\n\nThe cycle-branch SHA transition is the **only** signal in-flight roles need. They are already polling the branch per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Polling primitives\"`. The SHA advance wakes them; their next iteration re-reads the issue body (and any other named source) live, not from cache.\n\n### 1.2. What a mid-flight rescue is not\n\nA mid-flight rescue is **not**:\n\n- a substitute for clean dispatch (the dispatch-time implementation-contract enrichment at `dispatch\u002FSKILL.md §3` is the *first* line of defense; the rescue is the escape valve when the first line failed),\n- a chat-relayed instruction (chat does not reach polling roles; the artifact channel does),\n- a silent contract mutation (γ MUST NOT edit the issue body or push a spec change without first writing `gamma-clarification.md` — silent re-pin is the canonical failure mode),\n- an authority override of α's intake constraints (α still surfaces unpinned rows to γ\u002Fδ; the rescue is γ's tool, not α's permission to improvise),\n- a routine cadence (a cycle with > 1–2 `gamma-clarification.md` entries is a signal that dispatch under-specified; ε reads the pattern and codifies).\n\n### 1.3. Failure mode\n\nThe mid-flight channel fails through **silent re-pin**:\n\n- γ edits the issue body to clarify an ambiguity (or pin a missing axis, or fold in an operator override).\n- γ does not write `gamma-clarification.md` to the cycle branch.\n- The in-flight α or β session continues on its cached `gh issue view` read (the MCP cache; the local snapshot; whatever the polling primitive serves).\n- α finishes on the old contract; β APPROVE-s on the old contract; the cycle merges in the wrong shape.\n- No audit trail explains which decision happened when; the post-release assessment cannot reconstruct the contract history.\n\nThe canonical anchor is cnos#391: γ recovered the cycle by editing the issue body to pin missing axes (`Package scoping`, `CLI integration target`) and committing `gamma-clarification.md` to the cycle branch. α detected the SHA transition via cycle-branch polling, re-read the issue body live, and re-shaped the implementation. The rescue worked specifically because the clarification was on-channel; the issue-edit alone would have been invisible.\n\n---\n\n## 2. Unfold\n\n### 2.1. File format\n\nThe clarification file lives at the canonical channel path:\n\n```text\n.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md\n```\n\non the cycle branch (`origin\u002Fcycle\u002F{N}`). When multiple clarifications fire in one cycle, γ **appends** to the existing file (one `## Clarification — {ISO-date}` section per event); γ does not author parallel files.\n\n**Required sections per event:**\n\n```markdown\n## Clarification — {ISO-date}\n\n**Change:** {one-line summary of the load-bearing change}\n\n**Trigger:** {axis re-pin | scope clarification | AC clarification | blocker resolution | issue-body edit | spec change on main | operator override | α-surfaced ambiguity | β-surfaced wrong-shape}\n\n**Impact:**\n- ACs affected: {list or \"none\"}\n- Non-goals affected: {list or \"none\"}\n- Constraints affected: {list or \"none\"}\n- Artifacts affected: {list or \"none — γ-authored clarification only\"}\n\n**Rationale:** {1–3 sentences naming why the change is needed; cite the surface that surfaced the gap when applicable}\n\n**Resumption guidance:** {what in-flight α\u002Fβ should do next — re-scope \u002F acknowledge \u002F continue \u002F stop and escalate}\n```\n\nThe format is small by design: the rescue is bounded recovery, not a re-write of the cycle's substance. If a clarification needs more than ~30 lines, γ is probably mid-redesigning the cycle's intent and should consider stopping and re-scaffolding instead.\n\n### 2.2. Authoring role\n\n`gamma-clarification.md` is **γ-authored only**. The cycle's γ is the writer; the operator-as-γ may write when γ is collapsed onto the operator (per `ROLES.md §4` role-collapse). α and β MUST NOT write to this file — α surfaces gaps via `self-coherence.md` and β surfaces gaps via `beta-review.md` per the per-role write ownership rules at `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md §\"Per-role write ownership\"`.\n\nThe write sequence is:\n\n1. γ identifies the load-bearing change (axis re-pin, scope clarification, AC clarification, blocker resolution, issue-body edit, spec change on origin\u002Fmain).\n2. γ writes (or appends to) `.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` on `cycle\u002F{N}` per the §2.1 format.\n3. γ commits and pushes to `origin\u002Fcycle\u002F{N}` — this is the wake-up signal.\n4. *Only then* γ effects the other-surface change (`gh issue edit`, `git push` to main for spec change, etc.). Order matters: the clarification on the cycle branch is the signal that the other surface is about to change.\n\n### 2.3. Reader role\n\nIn-flight α and β are the **readers**. Both roles poll `origin\u002Fcycle\u002F{N}` per the polling primitives at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Polling primitives\"`. When their polling sees a `gamma-clarification.md` add or update (the SHA advance carries a touch to this file), the reader role's next intake iteration:\n\n1. Reads the clarification file (`git show origin\u002Fcycle\u002F{N}:.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` or `git pull` + local read).\n2. Re-reads the issue body **live** via `gh issue view {N} --json title,body,state,comments` (the MCP-cached read is stale; the live fetch is the cache-bust).\n3. Re-reads any other source γ named in the clarification (e.g. a spec file on `origin\u002Fmain` per the spec-staleness rule §2.5 below).\n4. Decides per §2.4 resumption protocol.\n\nThe reader does not need γ to chat-relay; the file write *is* the signal.\n\n### 2.4. Resumption protocol\n\nAfter reading a clarification, the in-flight role has four paths:\n\n1. **Acknowledge and continue.** The change does not affect work in flight (e.g. γ clarified an AC the role had already interpreted correctly). The role notes the clarification in its own artifact (α in `self-coherence.md`; β in `beta-review.md`) — a one-line entry naming the clarification date and the impact assessment — and continues.\n2. **Re-scope and continue.** The change requires a localized adjustment (e.g. a pinned axis re-pinned to a new value; a non-goal added). The role re-shapes work in flight, notes the re-scope in its own artifact, and continues from the next uncompleted step.\n3. **Stop and escalate.** The change requires a rewrite (e.g. the language axis re-pinned from Python to Go after substantial implementation in Python). The role writes a stop note in its own artifact, signals via the artifact channel that the cycle needs operator attention, and waits. γ (or operator-as-γ) decides whether to (a) abandon work in flight and resume on the new contract, (b) close the cycle and re-scaffold a new one, or (c) accept the partial work and file a follow-on.\n4. **Continue under protest.** Reserved for cases where the role believes the clarification itself is incoherent. The role logs the protest in its own artifact (α or β), continues on the *prior* contract, and surfaces the conflict to γ. γ adjudicates by either revising the clarification or routing through δ for boundary review (`cnos.cdd\u002Fskills\u002Fcdd\u002Fdelta\u002FSKILL.md §1 — outward membrane`). The protest path is rare; the resumption guidance field in the clarification (§2.1) should pre-empt it.\n\nThe role MUST NOT silently merge the clarification into work in flight without acknowledging it in its own artifact. Acknowledgment is the audit trail that lets β's Rule 7 verification distinguish \"α applied the clarification\" from \"α happened to ship the new shape\".\n\n### 2.5. Issue-edit cache-bust\n\nThe most frequent rescue trigger is an **issue-body edit**. γ edits the cycle's GitHub issue body to:\n\n- pin a missing implementation-contract axis (post-#391; the dispatch-time gate at `dispatch\u002FSKILL.md §3` did not catch the omission),\n- clarify an ambiguous AC,\n- add or remove a non-goal,\n- fold in a post-filing refinement (per `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md §2.3.1` `modified` event — the same mechanism propagates a Delta to in-flight readers),\n- record an operator override.\n\n**The GitHub issue mtime is not a reliable signal.** MCP `gh issue view` calls may return cached state for an unspecified window; even authenticated `gh` CLI calls may hit caching layers. The reader cannot trust \"did the issue update?\" as a wake-up condition.\n\n**The cycle-branch SHA transition is the canonical signal.** γ commits `gamma-clarification.md` to `cycle\u002F{N}` *before* `gh issue edit` runs. The polling role sees the SHA advance, knows from the touched file that an issue edit is incoming, and re-fetches the issue body live in the next intake iteration. The clarification on the cycle branch is the explicit cache-bust signal that an issue-edit-only signal would lack.\n\nThis is also the cross-repo cache-bust mechanism — when γ records a STATUS event change or refines a `## Source Proposal` block on the cycle's target issue (per `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md §2.3.4 — Emitters per event`), the same `gamma-clarification.md` write is the signal that propagates the refinement to any in-flight role.\n\n### 2.6. Spec-staleness propagation\n\nWhen γ (or δ) pushes spec changes to `origin\u002Fmain` while α\u002Fβ sessions are in-flight, loaded skills become stale. The wire-format invariant:\n\n- **Identity-rotation mode (`cn dispatch` \u002F `claude -p`):** Not applicable — each role invocation loads skills fresh from the filesystem; the next dispatch picks them up. No `gamma-clarification.md` needed; the next-iteration's fresh load is the cache-bust.\n- **Long-lived polling sessions (legacy):** γ writes a coordination note to `.cdd\u002Funreleased\u002F{N}\u002Fgamma-coordination.md` on `cycle\u002F{N}` (the gamma-coordination cousin of gamma-clarification — same channel, same authoring role, distinguished filename so the polling role can route by file name). The note names the spec change and the affected skill path; the in-flight role re-loads the affected skill from the new origin\u002Fmain snapshot.\n\nThe list of *which* skill files trigger propagation in a given consumer protocol is **consumer-side** doctrine. For CDD-class cycles, the file list (CDD.md; role skill files; release\u002FSKILL.md; review\u002FSKILL.md when they land on `main` while a cycle is in-flight) lives in `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002FSKILL.md §2.5 → \"Spec-staleness propagation\"`. For CDS-class cycles, the canonical realization is at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\"`. The wire-format invariant (\"γ writes a coordination note when spec changes mid-flight, on the cycle branch, before the spec change becomes visible\") is what this skill owns; the per-consumer trigger list is what cdd\u002Fcds own.\n\nDerives from cnos#301 §9.1: γ proposed an out-of-spec merge because σ's `4a0f678` (\"merge is β authority\") landed mid-cycle outside γ's loaded snapshot. The reactive fix is the staleness check in γ's Load Order; this is the proactive side — γ writes the coordination note *before* the spec change makes the loaded snapshot stale.\n\n---\n\n## 3. Rules\n\n### 3.1. Write the clarification before the other-surface edit\n\n- ❌ Edit the issue body, then write `gamma-clarification.md`. The in-flight role may sample the issue body in between and apply the new contract with no audit trail.\n- ✅ Commit and push `gamma-clarification.md` to `cycle\u002F{N}` first; *then* run `gh issue edit` (or `git push` to main for spec change). The branch SHA leads the signal.\n\n### 3.2. The cycle-branch SHA transition is the canonical signal\n\n- ❌ Rely on the GitHub issue mtime to wake polling readers — MCP caches may make it invisible.\n- ✅ Commit to `origin\u002Fcycle\u002F{N}`; the SHA advance is the wake-up event the polling primitive emits.\n\n### 3.3. γ is the sole author; α and β are the readers\n\n- ❌ α writes to `gamma-clarification.md` to flag a gap it found; β writes to `gamma-clarification.md` to record a finding.\n- ✅ α surfaces gaps via `self-coherence.md`; β surfaces gaps via `beta-review.md`; γ adjudicates and (if a clarification is the right tool) writes `gamma-clarification.md` itself.\n\n### 3.4. Acknowledge the clarification in the reader's own artifact\n\n- ❌ Silently merge a clarification into work in flight; β's Rule 7 verification cannot tell whether α applied the new contract or shipped the new shape by accident.\n- ✅ α appends a one-line entry to `self-coherence.md` naming the clarification date and impact assessment; β appends a one-line entry to `beta-review.md`. The acknowledgment is the audit trail.\n\n### 3.5. Do not redesign mid-cycle through clarifications\n\n- ❌ Use `gamma-clarification.md` to add ACs, change the cycle's gap, or rewrite the contract substantively (> ~30 lines of clarification per event).\n- ✅ Use `gamma-clarification.md` for bounded recovery (pin a missing axis; clarify an ambiguous AC; record an operator override). For substantive scope changes, close the cycle and re-scaffold a new one; the cycle boundary is the right unit of change for redesigns.\n\n### 3.6. The rescue is a structural escape valve, not a routine cadence\n\n- ❌ Treat repeated mid-flight clarifications as normal cadence; ship cycles with 3–4 clarification events as \"the contract was iterative\".\n- ✅ A cycle with > 1–2 clarifications is a dispatch-time signal. ε reads the pattern (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Cycle iteration triggers\"`) and files a finding against the dispatch protocol (`dispatch\u002FSKILL.md`) — under-specification at scaffold time is the root cause; codification, not more rescues, is the fix.\n\n### 3.7. Cross-reference, do not duplicate\n\nConsumer protocol skills cite this skill for the mid-flight rescue mechanism. If you find rescue-mechanism doctrine in `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002F`, `cnos.cdd\u002Fskills\u002Fcdd\u002F{alpha,beta}\u002F`, `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md`, or elsewhere that contradicts this skill, this skill governs and the other surface is patched to reference this one. The operational realization (the shell sequence) stays at cds as the v0.1 overlay; the wire-format invariant lives here.\n\n---\n\n## 4. Empirical anchors\n\nThe mid-flight rescue mechanism has empirical anchors across the cnos#388–#412 wave:\n\n- **[cnos#391](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F391)** — the canonical anchor. Wrong-shape implementation (wrong package scoping + a separate-binary axis γ did not pin at dispatch). γ recovered by editing the issue body to pin the missing axes (`Package scoping`, `CLI integration target`, `Existing-binary disposition`) and committing `gamma-clarification.md` to the cycle branch. α picked up the cache-bust via cycle-branch polling and re-shaped the implementation. The cycle was rescued mid-flight without abandoning the branch. The empirical-anchor doctrine cited at `dispatch\u002FSKILL.md §3` (δ-as-architect \u002F cnos#393) names this rescue path as the structural escape valve when γ under-specifies and α improvises.\n- **[cnos#392](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F392)** — recovery cycle. First cycle where δ pinned the 7-axis implementation contract at dispatch (the *upstream* fix); cnos#391's rescue path (the *downstream* fix) is what enabled cnos#392 to absorb the prior cycle's scope without abandonment. The two cycles compose: the dispatch-time enrichment at `dispatch\u002FSKILL.md §3` prevents most mid-flight rescues; the mechanism here remains the escape valve when prevention fails.\n- **[cnos#393](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F393)** — codification cycle. Made the dispatch-time implementation-contract first-class; named the mid-flight rescue as the structural escape valve in `dispatch\u002FSKILL.md §3.3`. The mechanism's *first* doctrinal mention lives in dispatch; the mechanism's *canonical home* is this skill.\n- **#406–#412 wave** — the post-codification cycles that exercised both the dispatch-time gate and the rescue channel in practice. Most cycles in the wave shipped with zero `gamma-clarification.md` events — the dispatch-time gate was sufficient. The rescue channel remains available; its rate of fire is the inverse signal of dispatch-time pinning quality.\n\n---\n\n## 5. Verify\n\n### 5.1. Clarification authoring check (per rescue event)\n\n- Does `.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` exist on `origin\u002Fcycle\u002F{N}`?\n- Was it committed *before* the other-surface change (`gh issue edit`, spec push to main)?\n- Does the entry name change \u002F trigger \u002F impact \u002F rationale \u002F resumption guidance per §2.1?\n- Is γ the author (commit attribution)?\n\n### 5.2. Reader-side acknowledgment check (at review time)\n\n- Did the in-flight α append a one-line acknowledgment to `self-coherence.md` per §3.4?\n- Did the in-flight β append a one-line acknowledgment to `beta-review.md` per §3.4?\n- If the role chose Stop and escalate (§2.4 path 3), is the escalation visible in the cycle's record?\n\n### 5.3. Cycle-cadence check (at close-out)\n\n- How many `gamma-clarification.md` events fired in this cycle? If > 1–2, does the close-out (or `cdd-iteration.md`) name the dispatch-protocol gap that motivated them?\n\n### 5.4. Spec-staleness check (when spec changes land mid-cycle)\n\n- For spec changes pushed to `origin\u002Fmain` during the cycle, did γ write `gamma-coordination.md` on `cycle\u002F{N}` before the push?\n- (Identity-rotation mode exempt — next-iteration's fresh load is the cache-bust.)\n\n---\n\n## 6. Related documents\n\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002FHANDOFF.md` — package contract; this skill is one sub-surface.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md` — the dispatch wire format; precondition for this skill (this skill picks up after α is routed and dispatch's enforcement window closes). The dispatch skill cites this one for mid-cycle re-pinning at §3.3.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md` — the substrate `gamma-clarification.md` lives on (per-role write ownership; sequential α→β→γ flow; frozen-snapshot rule on merge). Companion sub-skill landed alongside this one under Sub 4 of cnos#404.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md` — STATUS state machine; `modified` event post-filing refinement uses the same `gamma-clarification.md` mechanism to propagate a Delta to in-flight readers.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Freceipt-stream\u002FSKILL.md` — Sub 5 of cnos#404 (forthcoming). The cross-cycle aggregator; mid-flight rescue events feed into the cycle's `cdd-iteration.md` when the rescue indicates a dispatch-protocol gap.\n- `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002FSKILL.md §2.5` — γ role-skill; γ's coordination loop names the issue-edit cache-bust procedure and the spec-staleness propagation (CDD-specific file list) as role-local procedure, citing this skill for the wire-format invariant.\n- `cnos.cdd\u002Fskills\u002Fcdd\u002Falpha\u002FSKILL.md` — α intake \u002F polling; cites this skill for the issue-edit cache-bust trigger.\n- `cnos.cdd\u002Fskills\u002Fcdd\u002Fbeta\u002FSKILL.md` — β intake \u002F polling; cites this skill for the issue-edit cache-bust trigger.\n- `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` — v0.1 software-cycle operational realization (the `gh issue edit` + `git commit` + `git push` shell sequence γ runs at clarification time). Cites this skill for the wire-format invariant; this skill cites it for the v0.1 realization overlay.\n- [cnos#391](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F391) — canonical empirical anchor (the rescue cycle).\n- [cnos#392](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F392) — recovery cycle (the downstream cycle that absorbed #391's scope).\n- [cnos#404](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F404) — parent tracker (handoff\u002Fcoordination extraction wave).\n- [cnos#418](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F418) — the codification cycle for this surface (Sub 4 of cnos#404).\n\n---\n\n## 7. Non-goals\n\n- This skill does NOT own the dispatch-time implementation-contract enrichment. The 7-axis schema, the δ-as-inward-membrane review, the four-surface mesh (γ template \u002F δ enrichment \u002F α constraint \u002F β verification) live in `cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md`. This skill picks up where dispatch leaves off — once α is routed, dispatch's enforcement window closes; mid-flight is the post-dispatch channel.\n- This skill does NOT own the artifact-channel rules. The per-role write ownership (α writes self-coherence + alpha-closeout; β writes beta-review + beta-closeout; γ writes gamma-scaffold + gamma-closeout + cdd-iteration + gamma-clarification + gamma-coordination), the sequential α→β→γ flow, and the frozen-snapshot rule on merge belong to `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md`. This skill cites the channel as the substrate.\n- This skill does NOT own the operational realization. The `gh issue edit` + `git commit` + `git push` shell sequence γ runs at clarification time, the polling primitive that detects the SHA transition, the v0.1 software-cycle overlay all stay at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\"` and `cnos.cdd\u002Fskills\u002Fcdd\u002Fharness\u002FSKILL.md §5.4`. This skill names the wire-format invariant; cds\u002Fcdd carry the v0.1 realization.\n- This skill does NOT redefine the cycle-state observation surfaces or polling primitives. Those live in `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Polling primitives\"`. This skill assumes a polling primitive exists that emits on cycle-branch SHA transitions.\n- This skill does NOT change the rescue mechanism's behavior. Sub 4 of cnos#404 is a wholesale extraction of an empirically-anchored mechanism (cnos#391); the file path, authoring role, reader role, trigger conditions, and cache-bust function are preserved verbatim from the empirical practice.\n- This skill does NOT lift the clarification format into a typed schema. Whether to type `gamma-clarification.md` into `schemas\u002Fhandoff\u002Fclarification.cue` is deferred; if a future cycle pressures the type-lift, the Markdown format references the schema by `$ref` then.\n\n---\n\n## 8. Kata\n\n### Scenario\n\nα is mid-implementation on `cycle\u002FN`, polling `origin\u002Fcycle\u002FN`. γ realizes (from an operator note) that implementation-contract row 7 (Backward-compat invariant) is wrong: the operator wants existing rules preserved + new content additive; γ had pinned \"breaking change documented in §Migration\". γ needs to re-pin without abandoning α's work.\n\n### Expected reasoning\n\n1. **Tool identification.** Single axis re-pin; α has not committed dependent implementation yet. Bounded recovery applies. Mid-flight rescue is the right tool (§2.4 path 2 — re-scope and continue). If the re-pin required a full language switch, γ would stop (§2.4 path 3) and re-scaffold instead.\n\n2. **Clarification authoring.** γ writes (or appends to) `.cdd\u002Funreleased\u002FN\u002Fgamma-clarification.md` per the §2.1 format: change = row 7 re-pin; trigger = operator override; impact = AC4 (now requires additive-only diff); rationale = operator clarified the cycle is part of a migration wave; resumption guidance = α re-scope, revert in-flight breaking-change content, acknowledge in self-coherence.md before review-readiness.\n\n3. **Operation sequence.** γ commits and pushes `gamma-clarification.md` to `cycle\u002FN` *first*. Only then does γ effect any other surface change (e.g. `gh issue edit` if the issue body needs updating; in this case the implementation contract lives in the dispatch prompt on the cycle branch, so no issue edit is needed).\n\n4. **α cache-bust.** α's polling primitive detects the SHA advance within the polling cadence. α's next intake iteration reads the clarification, re-reads the issue body live via `gh issue view N --json title,body,state,comments`, re-scopes per the resumption guidance, appends a one-line acknowledgment to `self-coherence.md`, and continues.\n\n### Common failures\n\n- γ runs `gh issue edit` first, then writes `gamma-clarification.md` — α may sample the issue body between the two operations and apply the new contract with no audit trail.\n- γ chat-relays the change instead of writing the clarification — chat does not reach polling sessions.\n- α reads the clarification but does not acknowledge in `self-coherence.md` — β's Rule 7 verification cannot distinguish \"α applied the new contract\" from \"α happened to ship the new shape\".\n- γ writes a 100-line clarification rewriting the cycle's scope — at that volume the cycle should be closed and re-scaffolded.\n- γ silently mutates the dispatch prompt on the cycle branch — same failure mode as silent issue-body edit.\n\n### Verification\n\n- `.cdd\u002Funreleased\u002FN\u002Fgamma-clarification.md` exists on `origin\u002Fcycle\u002FN`; commit precedes any other-surface change.\n- α's `self-coherence.md` carries a one-line acknowledgment naming the clarification date.\n- β at review time confirms the diff matches the *post-clarification* contract; Rule 7 cites the clarification date in the verification record.\n\n### Reflection\n\nA second γ reading this kata's output should be able to reconstruct what changed, when, how it propagated to α, and whether α acknowledged before continuing — without consulting chat history. The artifact channel carries the complete record.\n\n---\n\n**End of skill.**\n","# Mid-Flight Rescue — γ → in-flight α\u002Fβ re-pinning channel\n\n## Core principle\n\n**A mid-flight change to a load-bearing fact transits the cycle's artifact channel, not chat. γ writes the substance to `.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` on `cycle\u002F{N}` *before* the change becomes visible elsewhere; the cycle-branch SHA transition is the wake-up signal that bursts in-flight α\u002Fβ caches. The mechanism is bounded recovery — a structural escape valve when γ under-specified at dispatch time — not a substitute for clean dispatch.**\n\nThe mid-flight rescue is the wire format γ uses when something the cycle relied on changes after dispatch. The thing that changed may be (1) a pinned implementation-contract axis γ realizes was wrong, (2) an AC γ realizes was ambiguous, (3) a non-goal γ realizes was load-bearing, (4) the issue body itself (γ edited it because α surfaced an ambiguity or δ refined an axis), or (5) a spec file on `origin\u002Fmain` whose change ripples into the cycle's loaded skill snapshot. In all cases, an in-flight α or β session may be operating on a cached read of the prior state — chat will not reach them; only artifact-channel writes will.\n\nThe failure mode is **silent re-pin** — γ edits the issue body, or pushes a spec change to main, or mutates a contract row, without writing `gamma-clarification.md`. In-flight α\u002Fβ keep working from cached state, finish on the old contract, and ship the wrong shape. β's Rule 7 verification cannot adjudicate \"which contract is canonical\" when γ's mutation left no trail. The result is a cycle that satisfies the *new* contract by accident (or doesn't), with no audit trail for which decision happened when.\n\nThis skill is the **canonical surface** for the rescue mechanism: file path, authoring role, reader role, trigger conditions, cache-bust semantics, and the empirical anchors. Consumer protocol packages (cnos.cdd, cnos.cds, future c-d-X) cite this skill; the **operational realization** (the `gh issue edit` + `git commit` + `git push` shell sequence γ runs at clarification time) stays in `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` as the v0.1 overlay. The wire-format invariant lives here; the v0.1 software-cycle realization stays at cds.\n\n## Authority\n\n- This skill (in `cnos.handoff`) is the only canonical home for the mid-flight rescue mechanism's wire format: the file path, the authoring\u002Freader roles, the trigger conditions, the cache-bust function, the spec-staleness propagation invariant. If another skill or doctrine surface carries the same wire-format claims, this skill governs.\n- The consumer protocol packages govern the operational realization: `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` carries the post-#411 software-cycle realization (the shell sequence and the polling mapping); `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002FSKILL.md §2.5 → \"Spec-staleness propagation\"` carries the consumer-specific file list (which cdd skill files trigger propagation). Both cite this skill for the wire-format invariant.\n- The `gamma-clarification.md` artifact lives on the channel substrate; channel rules (per-role write ownership, frozen-snapshot rule on merge, sequential α→β→γ flow) are at `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md`. This skill cites the channel; the channel does not redefine the rescue protocol.\n\n## Scope\n\nIn scope:\n\n- The `gamma-clarification.md` file format and authoring contract (file path, authoring role, content sections, commit + push sequence).\n- The wake-up \u002F cache-bust semantics (cycle-branch SHA transition is the signal; not the GitHub issue mtime, which is invisible to MCP-cached reads).\n- Reader role obligations (in-flight α\u002Fβ polling sessions detect the write; re-read the issue body live via `gh issue view`; re-load any other source γ named in the clarification).\n- The resumption protocol (in-flight α\u002Fβ acknowledge in their own artifact, re-scope, escalate, or stop).\n- The spec-staleness propagation invariant (γ writes a coordination note when spec changes land on origin\u002Fmain mid-cycle).\n- Empirical anchors (cnos#391 rescue; cnos#392 recovery).\n\nOut of scope:\n\n- The cycle-lifecycle role-skill obligations of α (intake; pre-implementation surface; review-readiness signal) and β (review CLP; verdict cadence). Those live in `cnos.cdd\u002Fskills\u002Fcdd\u002F{alpha,beta}\u002FSKILL.md` and are consumers of this wire format.\n- The per-artifact channel rules (write ownership, sequential flow, frozen-snapshot). Those live in `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md`. This skill cites the channel as the substrate `gamma-clarification.md` lives on.\n- The dispatch-time implementation-contract enrichment (δ-as-inward-membrane review before routing). That lives in `cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md §3`. This skill picks up where dispatch leaves off — once α is routed, dispatch's enforcement window closes; mid-flight is the post-dispatch channel.\n- The operational shell sequence γ runs (`gh issue edit` + `git commit` + `git push`). That stays at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` as the v0.1 software-cycle realization overlay.\n- The harness substrate (polling primitives, Monitor wrapping, reachability re-probe). That lives in `cnos.cdd\u002Fskills\u002Fcdd\u002Fharness\u002FSKILL.md` per Phase 4b of cnos#366.\n- The cross-repo proposal lifecycle. Cited from this skill (issue-body edits propagating to in-flight intake sessions are the same mechanism); the lifecycle itself is at `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md`.\n\n---\n\n## 1. Define\n\n### 1.1. What a mid-flight rescue is\n\nA mid-flight rescue is **one γ-authored file** (`gamma-clarification.md`) written to the cycle's artifact-channel directory (`.cdd\u002Funreleased\u002F{N}\u002F`) on the cycle branch (`origin\u002Fcycle\u002F{N}`), committed and pushed *before* the change becomes visible in any other surface the in-flight role might read. It carries:\n\n- the change (axis re-pin \u002F scope clarification \u002F AC clarification \u002F blocker resolution \u002F issue-body edit summary \u002F spec-change pointer),\n- the date,\n- the impact (which ACs \u002F non-goals \u002F constraints \u002F artifacts the change affects),\n- the rationale (typically: a repo-convention emerged; a downstream consumer surfaced; an operator override; α surfaced an ambiguity; β found a wrong-shape implementation; a spec change landed on main).\n\nThe cycle-branch SHA transition is the **only** signal in-flight roles need. They are already polling the branch per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Polling primitives\"`. The SHA advance wakes them; their next iteration re-reads the issue body (and any other named source) live, not from cache.\n\n### 1.2. What a mid-flight rescue is not\n\nA mid-flight rescue is **not**:\n\n- a substitute for clean dispatch (the dispatch-time implementation-contract enrichment at `dispatch\u002FSKILL.md §3` is the *first* line of defense; the rescue is the escape valve when the first line failed),\n- a chat-relayed instruction (chat does not reach polling roles; the artifact channel does),\n- a silent contract mutation (γ MUST NOT edit the issue body or push a spec change without first writing `gamma-clarification.md` — silent re-pin is the canonical failure mode),\n- an authority override of α's intake constraints (α still surfaces unpinned rows to γ\u002Fδ; the rescue is γ's tool, not α's permission to improvise),\n- a routine cadence (a cycle with > 1–2 `gamma-clarification.md` entries is a signal that dispatch under-specified; ε reads the pattern and codifies).\n\n### 1.3. Failure mode\n\nThe mid-flight channel fails through **silent re-pin**:\n\n- γ edits the issue body to clarify an ambiguity (or pin a missing axis, or fold in an operator override).\n- γ does not write `gamma-clarification.md` to the cycle branch.\n- The in-flight α or β session continues on its cached `gh issue view` read (the MCP cache; the local snapshot; whatever the polling primitive serves).\n- α finishes on the old contract; β APPROVE-s on the old contract; the cycle merges in the wrong shape.\n- No audit trail explains which decision happened when; the post-release assessment cannot reconstruct the contract history.\n\nThe canonical anchor is cnos#391: γ recovered the cycle by editing the issue body to pin missing axes (`Package scoping`, `CLI integration target`) and committing `gamma-clarification.md` to the cycle branch. α detected the SHA transition via cycle-branch polling, re-read the issue body live, and re-shaped the implementation. The rescue worked specifically because the clarification was on-channel; the issue-edit alone would have been invisible.\n\n---\n\n## 2. Unfold\n\n### 2.1. File format\n\nThe clarification file lives at the canonical channel path:\n\n```text\n.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md\n```\n\non the cycle branch (`origin\u002Fcycle\u002F{N}`). When multiple clarifications fire in one cycle, γ **appends** to the existing file (one `## Clarification — {ISO-date}` section per event); γ does not author parallel files.\n\n**Required sections per event:**\n\n```markdown\n## Clarification — {ISO-date}\n\n**Change:** {one-line summary of the load-bearing change}\n\n**Trigger:** {axis re-pin | scope clarification | AC clarification | blocker resolution | issue-body edit | spec change on main | operator override | α-surfaced ambiguity | β-surfaced wrong-shape}\n\n**Impact:**\n- ACs affected: {list or \"none\"}\n- Non-goals affected: {list or \"none\"}\n- Constraints affected: {list or \"none\"}\n- Artifacts affected: {list or \"none — γ-authored clarification only\"}\n\n**Rationale:** {1–3 sentences naming why the change is needed; cite the surface that surfaced the gap when applicable}\n\n**Resumption guidance:** {what in-flight α\u002Fβ should do next — re-scope \u002F acknowledge \u002F continue \u002F stop and escalate}\n```\n\nThe format is small by design: the rescue is bounded recovery, not a re-write of the cycle's substance. If a clarification needs more than ~30 lines, γ is probably mid-redesigning the cycle's intent and should consider stopping and re-scaffolding instead.\n\n### 2.2. Authoring role\n\n`gamma-clarification.md` is **γ-authored only**. The cycle's γ is the writer; the operator-as-γ may write when γ is collapsed onto the operator (per `ROLES.md §4` role-collapse). α and β MUST NOT write to this file — α surfaces gaps via `self-coherence.md` and β surfaces gaps via `beta-review.md` per the per-role write ownership rules at `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md §\"Per-role write ownership\"`.\n\nThe write sequence is:\n\n1. γ identifies the load-bearing change (axis re-pin, scope clarification, AC clarification, blocker resolution, issue-body edit, spec change on origin\u002Fmain).\n2. γ writes (or appends to) `.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` on `cycle\u002F{N}` per the §2.1 format.\n3. γ commits and pushes to `origin\u002Fcycle\u002F{N}` — this is the wake-up signal.\n4. *Only then* γ effects the other-surface change (`gh issue edit`, `git push` to main for spec change, etc.). Order matters: the clarification on the cycle branch is the signal that the other surface is about to change.\n\n### 2.3. Reader role\n\nIn-flight α and β are the **readers**. Both roles poll `origin\u002Fcycle\u002F{N}` per the polling primitives at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Polling primitives\"`. When their polling sees a `gamma-clarification.md` add or update (the SHA advance carries a touch to this file), the reader role's next intake iteration:\n\n1. Reads the clarification file (`git show origin\u002Fcycle\u002F{N}:.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` or `git pull` + local read).\n2. Re-reads the issue body **live** via `gh issue view {N} --json title,body,state,comments` (the MCP-cached read is stale; the live fetch is the cache-bust).\n3. Re-reads any other source γ named in the clarification (e.g. a spec file on `origin\u002Fmain` per the spec-staleness rule §2.5 below).\n4. Decides per §2.4 resumption protocol.\n\nThe reader does not need γ to chat-relay; the file write *is* the signal.\n\n### 2.4. Resumption protocol\n\nAfter reading a clarification, the in-flight role has four paths:\n\n1. **Acknowledge and continue.** The change does not affect work in flight (e.g. γ clarified an AC the role had already interpreted correctly). The role notes the clarification in its own artifact (α in `self-coherence.md`; β in `beta-review.md`) — a one-line entry naming the clarification date and the impact assessment — and continues.\n2. **Re-scope and continue.** The change requires a localized adjustment (e.g. a pinned axis re-pinned to a new value; a non-goal added). The role re-shapes work in flight, notes the re-scope in its own artifact, and continues from the next uncompleted step.\n3. **Stop and escalate.** The change requires a rewrite (e.g. the language axis re-pinned from Python to Go after substantial implementation in Python). The role writes a stop note in its own artifact, signals via the artifact channel that the cycle needs operator attention, and waits. γ (or operator-as-γ) decides whether to (a) abandon work in flight and resume on the new contract, (b) close the cycle and re-scaffold a new one, or (c) accept the partial work and file a follow-on.\n4. **Continue under protest.** Reserved for cases where the role believes the clarification itself is incoherent. The role logs the protest in its own artifact (α or β), continues on the *prior* contract, and surfaces the conflict to γ. γ adjudicates by either revising the clarification or routing through δ for boundary review (`cnos.cdd\u002Fskills\u002Fcdd\u002Fdelta\u002FSKILL.md §1 — outward membrane`). The protest path is rare; the resumption guidance field in the clarification (§2.1) should pre-empt it.\n\nThe role MUST NOT silently merge the clarification into work in flight without acknowledging it in its own artifact. Acknowledgment is the audit trail that lets β's Rule 7 verification distinguish \"α applied the clarification\" from \"α happened to ship the new shape\".\n\n### 2.5. Issue-edit cache-bust\n\nThe most frequent rescue trigger is an **issue-body edit**. γ edits the cycle's GitHub issue body to:\n\n- pin a missing implementation-contract axis (post-#391; the dispatch-time gate at `dispatch\u002FSKILL.md §3` did not catch the omission),\n- clarify an ambiguous AC,\n- add or remove a non-goal,\n- fold in a post-filing refinement (per `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md §2.3.1` `modified` event — the same mechanism propagates a Delta to in-flight readers),\n- record an operator override.\n\n**The GitHub issue mtime is not a reliable signal.** MCP `gh issue view` calls may return cached state for an unspecified window; even authenticated `gh` CLI calls may hit caching layers. The reader cannot trust \"did the issue update?\" as a wake-up condition.\n\n**The cycle-branch SHA transition is the canonical signal.** γ commits `gamma-clarification.md` to `cycle\u002F{N}` *before* `gh issue edit` runs. The polling role sees the SHA advance, knows from the touched file that an issue edit is incoming, and re-fetches the issue body live in the next intake iteration. The clarification on the cycle branch is the explicit cache-bust signal that an issue-edit-only signal would lack.\n\nThis is also the cross-repo cache-bust mechanism — when γ records a STATUS event change or refines a `## Source Proposal` block on the cycle's target issue (per `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md §2.3.4 — Emitters per event`), the same `gamma-clarification.md` write is the signal that propagates the refinement to any in-flight role.\n\n### 2.6. Spec-staleness propagation\n\nWhen γ (or δ) pushes spec changes to `origin\u002Fmain` while α\u002Fβ sessions are in-flight, loaded skills become stale. The wire-format invariant:\n\n- **Identity-rotation mode (`cn dispatch` \u002F `claude -p`):** Not applicable — each role invocation loads skills fresh from the filesystem; the next dispatch picks them up. No `gamma-clarification.md` needed; the next-iteration's fresh load is the cache-bust.\n- **Long-lived polling sessions (legacy):** γ writes a coordination note to `.cdd\u002Funreleased\u002F{N}\u002Fgamma-coordination.md` on `cycle\u002F{N}` (the gamma-coordination cousin of gamma-clarification — same channel, same authoring role, distinguished filename so the polling role can route by file name). The note names the spec change and the affected skill path; the in-flight role re-loads the affected skill from the new origin\u002Fmain snapshot.\n\nThe list of *which* skill files trigger propagation in a given consumer protocol is **consumer-side** doctrine. For CDD-class cycles, the file list (CDD.md; role skill files; release\u002FSKILL.md; review\u002FSKILL.md when they land on `main` while a cycle is in-flight) lives in `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002FSKILL.md §2.5 → \"Spec-staleness propagation\"`. For CDS-class cycles, the canonical realization is at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\"`. The wire-format invariant (\"γ writes a coordination note when spec changes mid-flight, on the cycle branch, before the spec change becomes visible\") is what this skill owns; the per-consumer trigger list is what cdd\u002Fcds own.\n\nDerives from cnos#301 §9.1: γ proposed an out-of-spec merge because σ's `4a0f678` (\"merge is β authority\") landed mid-cycle outside γ's loaded snapshot. The reactive fix is the staleness check in γ's Load Order; this is the proactive side — γ writes the coordination note *before* the spec change makes the loaded snapshot stale.\n\n---\n\n## 3. Rules\n\n### 3.1. Write the clarification before the other-surface edit\n\n- ❌ Edit the issue body, then write `gamma-clarification.md`. The in-flight role may sample the issue body in between and apply the new contract with no audit trail.\n- ✅ Commit and push `gamma-clarification.md` to `cycle\u002F{N}` first; *then* run `gh issue edit` (or `git push` to main for spec change). The branch SHA leads the signal.\n\n### 3.2. The cycle-branch SHA transition is the canonical signal\n\n- ❌ Rely on the GitHub issue mtime to wake polling readers — MCP caches may make it invisible.\n- ✅ Commit to `origin\u002Fcycle\u002F{N}`; the SHA advance is the wake-up event the polling primitive emits.\n\n### 3.3. γ is the sole author; α and β are the readers\n\n- ❌ α writes to `gamma-clarification.md` to flag a gap it found; β writes to `gamma-clarification.md` to record a finding.\n- ✅ α surfaces gaps via `self-coherence.md`; β surfaces gaps via `beta-review.md`; γ adjudicates and (if a clarification is the right tool) writes `gamma-clarification.md` itself.\n\n### 3.4. Acknowledge the clarification in the reader's own artifact\n\n- ❌ Silently merge a clarification into work in flight; β's Rule 7 verification cannot tell whether α applied the new contract or shipped the new shape by accident.\n- ✅ α appends a one-line entry to `self-coherence.md` naming the clarification date and impact assessment; β appends a one-line entry to `beta-review.md`. The acknowledgment is the audit trail.\n\n### 3.5. Do not redesign mid-cycle through clarifications\n\n- ❌ Use `gamma-clarification.md` to add ACs, change the cycle's gap, or rewrite the contract substantively (> ~30 lines of clarification per event).\n- ✅ Use `gamma-clarification.md` for bounded recovery (pin a missing axis; clarify an ambiguous AC; record an operator override). For substantive scope changes, close the cycle and re-scaffold a new one; the cycle boundary is the right unit of change for redesigns.\n\n### 3.6. The rescue is a structural escape valve, not a routine cadence\n\n- ❌ Treat repeated mid-flight clarifications as normal cadence; ship cycles with 3–4 clarification events as \"the contract was iterative\".\n- ✅ A cycle with > 1–2 clarifications is a dispatch-time signal. ε reads the pattern (per `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Cycle iteration triggers\"`) and files a finding against the dispatch protocol (`dispatch\u002FSKILL.md`) — under-specification at scaffold time is the root cause; codification, not more rescues, is the fix.\n\n### 3.7. Cross-reference, do not duplicate\n\nConsumer protocol skills cite this skill for the mid-flight rescue mechanism. If you find rescue-mechanism doctrine in `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002F`, `cnos.cdd\u002Fskills\u002Fcdd\u002F{alpha,beta}\u002F`, `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md`, or elsewhere that contradicts this skill, this skill governs and the other surface is patched to reference this one. The operational realization (the shell sequence) stays at cds as the v0.1 overlay; the wire-format invariant lives here.\n\n---\n\n## 4. Empirical anchors\n\nThe mid-flight rescue mechanism has empirical anchors across the cnos#388–#412 wave:\n\n- **[cnos#391](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F391)** — the canonical anchor. Wrong-shape implementation (wrong package scoping + a separate-binary axis γ did not pin at dispatch). γ recovered by editing the issue body to pin the missing axes (`Package scoping`, `CLI integration target`, `Existing-binary disposition`) and committing `gamma-clarification.md` to the cycle branch. α picked up the cache-bust via cycle-branch polling and re-shaped the implementation. The cycle was rescued mid-flight without abandoning the branch. The empirical-anchor doctrine cited at `dispatch\u002FSKILL.md §3` (δ-as-architect \u002F cnos#393) names this rescue path as the structural escape valve when γ under-specifies and α improvises.\n- **[cnos#392](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F392)** — recovery cycle. First cycle where δ pinned the 7-axis implementation contract at dispatch (the *upstream* fix); cnos#391's rescue path (the *downstream* fix) is what enabled cnos#392 to absorb the prior cycle's scope without abandonment. The two cycles compose: the dispatch-time enrichment at `dispatch\u002FSKILL.md §3` prevents most mid-flight rescues; the mechanism here remains the escape valve when prevention fails.\n- **[cnos#393](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F393)** — codification cycle. Made the dispatch-time implementation-contract first-class; named the mid-flight rescue as the structural escape valve in `dispatch\u002FSKILL.md §3.3`. The mechanism's *first* doctrinal mention lives in dispatch; the mechanism's *canonical home* is this skill.\n- **#406–#412 wave** — the post-codification cycles that exercised both the dispatch-time gate and the rescue channel in practice. Most cycles in the wave shipped with zero `gamma-clarification.md` events — the dispatch-time gate was sufficient. The rescue channel remains available; its rate of fire is the inverse signal of dispatch-time pinning quality.\n\n---\n\n## 5. Verify\n\n### 5.1. Clarification authoring check (per rescue event)\n\n- Does `.cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md` exist on `origin\u002Fcycle\u002F{N}`?\n- Was it committed *before* the other-surface change (`gh issue edit`, spec push to main)?\n- Does the entry name change \u002F trigger \u002F impact \u002F rationale \u002F resumption guidance per §2.1?\n- Is γ the author (commit attribution)?\n\n### 5.2. Reader-side acknowledgment check (at review time)\n\n- Did the in-flight α append a one-line acknowledgment to `self-coherence.md` per §3.4?\n- Did the in-flight β append a one-line acknowledgment to `beta-review.md` per §3.4?\n- If the role chose Stop and escalate (§2.4 path 3), is the escalation visible in the cycle's record?\n\n### 5.3. Cycle-cadence check (at close-out)\n\n- How many `gamma-clarification.md` events fired in this cycle? If > 1–2, does the close-out (or `cdd-iteration.md`) name the dispatch-protocol gap that motivated them?\n\n### 5.4. Spec-staleness check (when spec changes land mid-cycle)\n\n- For spec changes pushed to `origin\u002Fmain` during the cycle, did γ write `gamma-coordination.md` on `cycle\u002F{N}` before the push?\n- (Identity-rotation mode exempt — next-iteration's fresh load is the cache-bust.)\n\n---\n\n## 6. Related documents\n\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002FHANDOFF.md` — package contract; this skill is one sub-surface.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md` — the dispatch wire format; precondition for this skill (this skill picks up after α is routed and dispatch's enforcement window closes). The dispatch skill cites this one for mid-cycle re-pinning at §3.3.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md` — the substrate `gamma-clarification.md` lives on (per-role write ownership; sequential α→β→γ flow; frozen-snapshot rule on merge). Companion sub-skill landed alongside this one under Sub 4 of cnos#404.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Fcross-repo\u002FSKILL.md` — STATUS state machine; `modified` event post-filing refinement uses the same `gamma-clarification.md` mechanism to propagate a Delta to in-flight readers.\n- `cnos.handoff\u002Fskills\u002Fhandoff\u002Freceipt-stream\u002FSKILL.md` — Sub 5 of cnos#404 (forthcoming). The cross-cycle aggregator; mid-flight rescue events feed into the cycle's `cdd-iteration.md` when the rescue indicates a dispatch-protocol gap.\n- `cnos.cdd\u002Fskills\u002Fcdd\u002Fgamma\u002FSKILL.md §2.5` — γ role-skill; γ's coordination loop names the issue-edit cache-bust procedure and the spec-staleness propagation (CDD-specific file list) as role-local procedure, citing this skill for the wire-format invariant.\n- `cnos.cdd\u002Fskills\u002Fcdd\u002Falpha\u002FSKILL.md` — α intake \u002F polling; cites this skill for the issue-edit cache-bust trigger.\n- `cnos.cdd\u002Fskills\u002Fcdd\u002Fbeta\u002FSKILL.md` — β intake \u002F polling; cites this skill for the issue-edit cache-bust trigger.\n- `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Mid-flight clarification\"` — v0.1 software-cycle operational realization (the `gh issue edit` + `git commit` + `git push` shell sequence γ runs at clarification time). Cites this skill for the wire-format invariant; this skill cites it for the v0.1 realization overlay.\n- [cnos#391](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F391) — canonical empirical anchor (the rescue cycle).\n- [cnos#392](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F392) — recovery cycle (the downstream cycle that absorbed #391's scope).\n- [cnos#404](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F404) — parent tracker (handoff\u002Fcoordination extraction wave).\n- [cnos#418](https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fissues\u002F418) — the codification cycle for this surface (Sub 4 of cnos#404).\n\n---\n\n## 7. Non-goals\n\n- This skill does NOT own the dispatch-time implementation-contract enrichment. The 7-axis schema, the δ-as-inward-membrane review, the four-surface mesh (γ template \u002F δ enrichment \u002F α constraint \u002F β verification) live in `cnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md`. This skill picks up where dispatch leaves off — once α is routed, dispatch's enforcement window closes; mid-flight is the post-dispatch channel.\n- This skill does NOT own the artifact-channel rules. The per-role write ownership (α writes self-coherence + alpha-closeout; β writes beta-review + beta-closeout; γ writes gamma-scaffold + gamma-closeout + cdd-iteration + gamma-clarification + gamma-coordination), the sequential α→β→γ flow, and the frozen-snapshot rule on merge belong to `cnos.handoff\u002Fskills\u002Fhandoff\u002Fartifact-channel\u002FSKILL.md`. This skill cites the channel as the substrate.\n- This skill does NOT own the operational realization. The `gh issue edit` + `git commit` + `git push` shell sequence γ runs at clarification time, the polling primitive that detects the SHA transition, the v0.1 software-cycle overlay all stay at `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\"` and `cnos.cdd\u002Fskills\u002Fcdd\u002Fharness\u002FSKILL.md §5.4`. This skill names the wire-format invariant; cds\u002Fcdd carry the v0.1 realization.\n- This skill does NOT redefine the cycle-state observation surfaces or polling primitives. Those live in `cnos.cds\u002Fskills\u002Fcds\u002FCDS.md §\"Coordination surfaces\" → \"Polling primitives\"`. This skill assumes a polling primitive exists that emits on cycle-branch SHA transitions.\n- This skill does NOT change the rescue mechanism's behavior. Sub 4 of cnos#404 is a wholesale extraction of an empirically-anchored mechanism (cnos#391); the file path, authoring role, reader role, trigger conditions, and cache-bust function are preserved verbatim from the empirical practice.\n- This skill does NOT lift the clarification format into a typed schema. Whether to type `gamma-clarification.md` into `schemas\u002Fhandoff\u002Fclarification.cue` is deferred; if a future cycle pressures the type-lift, the Markdown format references the schema by `$ref` then.\n\n---\n\n## 8. Kata\n\n### Scenario\n\nα is mid-implementation on `cycle\u002FN`, polling `origin\u002Fcycle\u002FN`. γ realizes (from an operator note) that implementation-contract row 7 (Backward-compat invariant) is wrong: the operator wants existing rules preserved + new content additive; γ had pinned \"breaking change documented in §Migration\". γ needs to re-pin without abandoning α's work.\n\n### Expected reasoning\n\n1. **Tool identification.** Single axis re-pin; α has not committed dependent implementation yet. Bounded recovery applies. Mid-flight rescue is the right tool (§2.4 path 2 — re-scope and continue). If the re-pin required a full language switch, γ would stop (§2.4 path 3) and re-scaffold instead.\n\n2. **Clarification authoring.** γ writes (or appends to) `.cdd\u002Funreleased\u002FN\u002Fgamma-clarification.md` per the §2.1 format: change = row 7 re-pin; trigger = operator override; impact = AC4 (now requires additive-only diff); rationale = operator clarified the cycle is part of a migration wave; resumption guidance = α re-scope, revert in-flight breaking-change content, acknowledge in self-coherence.md before review-readiness.\n\n3. **Operation sequence.** γ commits and pushes `gamma-clarification.md` to `cycle\u002FN` *first*. Only then does γ effect any other surface change (e.g. `gh issue edit` if the issue body needs updating; in this case the implementation contract lives in the dispatch prompt on the cycle branch, so no issue edit is needed).\n\n4. **α cache-bust.** α's polling primitive detects the SHA advance within the polling cadence. α's next intake iteration reads the clarification, re-reads the issue body live via `gh issue view N --json title,body,state,comments`, re-scopes per the resumption guidance, appends a one-line acknowledgment to `self-coherence.md`, and continues.\n\n### Common failures\n\n- γ runs `gh issue edit` first, then writes `gamma-clarification.md` — α may sample the issue body between the two operations and apply the new contract with no audit trail.\n- γ chat-relays the change instead of writing the clarification — chat does not reach polling sessions.\n- α reads the clarification but does not acknowledge in `self-coherence.md` — β's Rule 7 verification cannot distinguish \"α applied the new contract\" from \"α happened to ship the new shape\".\n- γ writes a 100-line clarification rewriting the cycle's scope — at that volume the cycle should be closed and re-scaffolded.\n- γ silently mutates the dispatch prompt on the cycle branch — same failure mode as silent issue-body edit.\n\n### Verification\n\n- `.cdd\u002Funreleased\u002FN\u002Fgamma-clarification.md` exists on `origin\u002Fcycle\u002FN`; commit precedes any other-surface change.\n- α's `self-coherence.md` carries a one-line acknowledgment naming the clarification date.\n- β at review time confirms the diff matches the *post-clarification* contract; Rule 7 cites the clarification date in the verification record.\n\n### Reflection\n\nA second γ reading this kata's output should be able to reconstruct what changed, when, how it propagated to α, and whether α acknowledged before continuing — without consulting chat history. The artifact channel carries the complete record.\n\n---\n\n**End of skill.**\n",{"name":5,"calls":44,"scope":49,"inputs":50,"parent":53,"outputs":54,"requires":58,"triggers":61,"visibility":68,"description":7,"kata_surface":69,"artifact_class":70,"governing_question":71},[45,46,47,48],"HANDOFF.md","artifact-channel\u002FSKILL.md","dispatch\u002FSKILL.md","cross-repo\u002FSKILL.md","task-local",[51,52],"active CDD-class cycle with α and\u002For β in-flight on origin\u002Fcycle\u002F{N}","the load-bearing change γ needs to signal (axis re-pin, scope clarification, AC clarification, blocker resolution, issue-body edit, spec change on origin\u002Fmain)","handoff",[55,56,57],".cdd\u002Funreleased\u002F{N}\u002Fgamma-clarification.md entry on origin\u002Fcycle\u002F{N} (substantive content of the change)","cycle-branch SHA transition (the wake-up signal)",".cdd\u002Funreleased\u002F{N}\u002Fgamma-coordination.md entry (legacy long-lived polling sessions only; spec-staleness propagation)",[59,60],"cycle\u002F{N} exists on origin with at least one in-flight role","the load-bearing change has been (or is about to be) committed in some other surface (issue body, origin\u002Fmain spec file) that the in-flight role's cached read would miss",[5,62,63,64,65,66,67],"gamma-clarification","issue-edit","cache-bust","rescue","re-pin","spec-staleness","public","embedded","skill","How does γ change a load-bearing fact mid-cycle without abandoning the branch — naming the change in the cycle's artifact channel so in-flight α\u002Fβ cache-bust and re-converge, rather than chat-relaying or silently mutating the contract?","main","fb527e6c4bfb75c71fa75d6471b3aa3da32106d4","src\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight",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":81,"prompt":91,"zipAvailable":92},[82,85,88],{"tool":83,"command":84},"npx","npx skills add usurobor\u002Fcnos --skill mid-flight",{"tool":86,"command":87},"bunx","bunx skills add usurobor\u002Fcnos --skill mid-flight",{"tool":89,"command":90},"pnpm","pnpm dlx skills add usurobor\u002Fcnos --skill mid-flight","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fmid-flight\u002FSKILL.md",true,[94,100,104,108,112,116,120,124,128,132,136,140,144,148,152,156,160,164,168,172,176,180],{"path":95,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":98,"sourceHtmlUrl":99},"agents\u002Fopenai.yaml","REFERENCE","参考文档",394,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Fagents\u002Fopenai.yaml",{"path":101,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fai-workflows.md",6734,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fai-workflows.md",{"path":105,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fasset-source-lock.md",1363,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fasset-source-lock.md",{"path":109,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fcleanup-and-git.md",1701,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fcleanup-and-git.md",{"path":113,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fcontent-and-systems.md",4448,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fcontent-and-systems.md",{"path":117,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":118,"sourceHtmlUrl":119},"references\u002Fcoordinate-space-conversion.md",18505,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fcoordinate-space-conversion.md",{"path":121,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":122,"sourceHtmlUrl":123},"references\u002Fmodular-architecture.md",5106,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fmodular-architecture.md",{"path":125,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":126,"sourceHtmlUrl":127},"references\u002Fmulti-surface-visible.md",1043,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fmulti-surface-visible.md",{"path":129,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":130,"sourceHtmlUrl":131},"references\u002Fproject-structure-discovery.md",5874,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fproject-structure-discovery.md",{"path":133,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":134,"sourceHtmlUrl":135},"references\u002Fruntime-numeric-proof.md",17161,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fruntime-numeric-proof.md",{"path":137,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":138,"sourceHtmlUrl":139},"references\u002Fruntime-owner-proof.md",4794,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fruntime-owner-proof.md",{"path":141,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":142,"sourceHtmlUrl":143},"references\u002Fruntime-visible-output.md",1864,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fruntime-visible-output.md",{"path":145,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":146,"sourceHtmlUrl":147},"references\u002Fruntime-visible-targets.md",8332,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fruntime-visible-targets.md",{"path":149,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":150,"sourceHtmlUrl":151},"references\u002Fscreenshot-text-owner.md",1144,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fscreenshot-text-owner.md",{"path":153,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":154,"sourceHtmlUrl":155},"references\u002Fserialized-persistence.md",1767,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fserialized-persistence.md",{"path":157,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":158,"sourceHtmlUrl":159},"references\u002Fsession-mining.md",2146,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fsession-mining.md",{"path":161,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":162,"sourceHtmlUrl":163},"references\u002Fshared-caller-blast-radius.md",2003,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fshared-caller-blast-radius.md",{"path":165,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":166,"sourceHtmlUrl":167},"references\u002Ftarget-bounds-catalog.md",3407,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Ftarget-bounds-catalog.md",{"path":169,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":170,"sourceHtmlUrl":171},"references\u002Fui-and-visual-assets.md",9834,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fui-and-visual-assets.md",{"path":173,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":174,"sourceHtmlUrl":175},"references\u002Funity-validation.md",6827,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Funity-validation.md",{"path":177,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":178,"sourceHtmlUrl":179},"references\u002Fvisible-object-identity.md",1842,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fvisible-object-identity.md",{"path":181,"resourceType":96,"resourceTypeDesc":97,"sizeBytes":182,"sourceHtmlUrl":183},"references\u002Fworkflow-recipes.md",7184,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FAUN-PN\u002Funity-agent-workflows\u002Fskills\u002Funity-agent-workflows\u002Freferences\u002Fworkflow-recipes.md",[185,200,214,242,257,274],{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":39},"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",[],[192,193,194,195,196,34,197,68,28,26,198,199],"triage","issues","issues triage","issue triage","SET","decision","issue","doctrine",{"skillNo":201,"name":202,"nameZh":6,"description":203,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":204,"categories":205,"keywords":206,"publishedAt":39},"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",[],[193,207,208,29,209,210,196,211,68,212,28,26,24,198,213],"taxonomy","issues taxonomy","status","protocol","open","board","issue labels",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":218,"categories":219,"keywords":230,"publishedAt":39},"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",[220,225],{"categoryNo":221,"categoryName":222,"taxonomyType":223,"taxonomyTypeDesc":224},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":226,"categoryName":227,"taxonomyType":228,"taxonomyTypeDesc":229},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[193,231,29,232,233,234,196,235,207,211,34,236,237,212,238,239,240,241,28,198],"issues map","reasoning","data","pipeline","api","json","README","edit","interactive","fetch","generated",{"skillNo":243,"name":193,"nameZh":6,"description":244,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":245,"categories":246,"keywords":247,"publishedAt":39},"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",[],[193,29,248,249,250,251,252,253,254,207,211,34,197,31,237,255,28,27,26,256],"pr","current state","run","artifacts","state","package","boundary","command","cds",{"skillNo":258,"name":259,"nameZh":6,"description":260,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":261,"categories":262,"keywords":263,"publishedAt":39},"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",[],[264,53,251,210,265,34,266,267,268,68,30,269,20,270,28,69,271,272,273,199],"receipt stream","index","learning","format","trace","closeout","channel","patch","shape","cdd",{"skillNo":275,"name":26,"nameZh":6,"description":276,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":277,"categories":278,"keywords":283,"publishedAt":39},"01M6CF819GAMEVZN193MSK22DW","Dispatch-time wire-format contract between γ (orchestrator) and α\u002Fβ (workers). Use when γ authors a dispatch prompt for α or β, when δ enriches an under-specified prompt at routing time, or when α reads the implementation-contract block at intake.","https:\u002F\u002Fgithub.com\u002Fusurobor\u002Fcnos\u002Fblob\u002Fmain\u002Fsrc\u002Fpackages\u002Fcnos.handoff\u002Fskills\u002Fhandoff\u002Fdispatch\u002FSKILL.md",[279,282],{"categoryNo":280,"categoryName":281,"taxonomyType":223,"taxonomyTypeDesc":224},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":226,"categoryName":227,"taxonomyType":228,"taxonomyTypeDesc":229},[26,53,284,253,285,286,287,288,34,289,31,30,290,28,291,198,292,273,293,22],"intake","alpha","beta","operator","escalation","template","orchestrator","ready","contracts","delta"]