cross-repo

name	cross-repo
description	Cross-repo CDD coordination. Use when a cnos cycle interacts with another repo's CDD lifecycle — accepting an inbound proposal, emitting an outbound iteration trace, running a bilateral iteration across hats, or staging operator-pending bundles for a counterpart repo.
artifact_class	skill
kata_surface	embedded
governing_question	How does γ resolve a cross-repo event into a single canonical bundle with one path, one STATUS vocabulary, one schema, and one archival rule — without rediscovering the protocol each cycle?
visibility	public
parent	handoff
triggers	["cross-repo","proposal intake","outbound iteration","bilateral iteration","feedback patch"]
scope	task-local
inputs	["cross-repo event (inbound proposal / outbound patches / bilateral iteration / operator-pending draft)","counterpart-repo identity","source or target cycle state"]
outputs	["cross-repo bundle at the canonical path","LINEAGE.md per directional case","STATUS ledger when proposal lifecycle applies","feedback patch when direct write to counterpart is not authorized","bundle archival decision when terminal events fire"]
requires	["a cross-repo event applies (the matter spans two repos)","consumer protocol package's loader has routed here (typically cnos.cdd γ intake/close-out, cnos.cds γ intake, or cnos.cdr γ — see `calls:` below)"]
calls	["cnos.cdd/skills/cdd/gamma/SKILL.md","cnos.cdd/skills/cdd/post-release/SKILL.md","cnos.cdd/skills/cdd/issue/SKILL.md"]

Cross-Repo Coordination

Core Principle

Coherent cross-repo coordination resolves a single directional case at a single canonical path, with a known event vocabulary terminating at landed (or rejected), and a bundle file set + LINEAGE schema selected by the case.

Cross-repo coordination is the protocol for events that span two CDD-activated repos (or one CDD-activated repo and one agent-hub or unscaffolded counterpart). It covers same-org bilateral coordination only. Multi-hop (A → B → C) and cross-org are not in scope.

The failure mode is directional ambiguity — γ invents the bundle shape per cycle because the protocol does not name the directional case. The result is bundles that drift in shape, STATUS ledgers that go stale at accepted, and doctrine that lives inside individual bundles rather than in the protocol.

This skill is the canonical surface for the protocol. Consumer protocol packages (cnos.cdd, cnos.cds, cnos.cdr, future c-d-X) reference it from their own role / coordination surfaces; they do not carry inline cross-repo doctrine.

Authority

• This skill (in cnos.handoff) is the only canonical home for the cross-repo state machine, bundle file set, LINEAGE schema, feedback-patch format, archival rule, and hat-collapse attribution. If another skill or doctrine surface carries the same doctrine, this skill governs.
• The consumer protocol packages govern the cycle lifecycle and selection rules into which cross-repo events feed; this skill governs what happens inside a single cycle's cross-repo interaction. For cnos.cdd consumers see cnos.cdd/skills/cdd/CDD.md; for software-class realizations see cnos.cds/skills/cds/CDS.md §"Coordination surfaces"; for research-class realizations see cnos.cdr/skills/cdr/CDR.md.
• The ## Source Proposal block in cnos.cdd/skills/cdd/issue/SKILL.md minimal output pattern is the target-side issue-body integration; that fragment stays in issue/ as a consumer-side concern.

Scope

In scope:

• Bilateral, same-org cross-repo coordination between cnos and one counterpart repo.
• Four directional cases: inbound proposal (1:1 or master/sub), outbound iteration trace, bilateral iteration, operator-pending bundle.
• STATUS state machine, bundle file set, LINEAGE.md schema, feedback-patch format, bundle archival rule, hat-collapse attribution.

Out of scope:

• Multi-hop coordination (A → B → C). When the next cycle hits multi-hop, this skill extends; until then, the protocol covers bilateral only.
• Cross-org coordination (different GitHub orgs).
• Tooling that auto-applies feedback patches, auto-emits landed events, or auto-archives bundles. Doctrine first; tooling deferred.

---

1. Define

1.1. The parts of a cross-repo coordination

A coherent coordination unit has these parts:

• Direction — who originates the substantive work (source) and who lands it (target).
• Fan-out shape — 1:1, master/sub, or patch-series.
• Bundle — the on-disk artifacts that carry the coordination record.
• STATUS ledger — the event sequence (proposal lifecycle only; cases a, c when proposal-shaped).
• LINEAGE.md — the bilateral trace; the durable record of who did what when.
• Feedback patch — when the cnos session cannot write to the counterpart side, the patch carries STATUS events or substantive content for the counterpart γ to apply on receipt.
• Bundle archival rule — when each side may delete its copy.

1.2. How they fit

Direction selects the case. Case selects the bundle file set. STATUS (when present) tracks proposal lifecycle. LINEAGE records the bilateral trace. Feedback patch is the cross-side write channel when direct write is unavailable. Archival rule names when each side may delete.

A bundle without LINEAGE is uninterpretable. A proposal-lifecycle case without STATUS is unanchored. A case without a named directional reading produces shape drift.

1.3. Failure mode

Cross-repo coordination fails through directional ambiguity:

• γ scans the wrong path and misses an active proposal.
• γ invents a LINEAGE schema by adapting a precedent shaped for a different case.
• γ leaves a STATUS at accepted indefinitely because the landed emitter is unclear.
• γ places protocol doctrine inside the bundle README, where it archives with the bundle.

This skill closes each failure mode by naming the directional case explicitly and binding bundle shape, STATUS rules, and archival to it.

---

2. Unfold

2.1. Directional cases

A cross-repo coordination unit fits exactly one of four directional cases. γ identifies the case before authoring the bundle.

Case (a) — Inbound proposal

Counterpart repo emits a proposal; cnos accepts, modifies, or rejects; substantive target work happens in cnos. Sub-shapes:

• (a.1) 1:1 — one source proposal → one cnos issue → one cnos cycle. Example: cn-sigma/agent-activate-skill → cnos#379.
• (a.2) master+sub — one source proposal → one cnos master issue → N cnos sub-issues landing independently. Example: cph/bootstrap-cdr → cnos#376 + subs.

cnos side is the target. The cnos-side bundle is the mirror; the source-side bundle is the originating artifact.

Case (b) — Outbound iteration trace

A cnos cycle produces patches that land in another repo. The substantive target work happens elsewhere. Sub-shape:

• (b.1) patch-series — cnos authors N patches against one target repo, all landed before the cycle closes. Example: tsc/cdd-supercycle (6 patches → cnos#331/#332).

cnos side is the source. The cnos-side bundle is the source-side staging surface; the target-side bundle (when authored) is the mirror.

Case (c) — Bilateral iteration

A single session produces patches for both repos via hat-collapse (an actor playing γ in one repo and ε — or another role — in the other during the same session). The substantive target work spans both repos. Example: cph/coherence-drift-sweep-followup-2026-05-18 (ε work for cph; patches landing in cnos and cph).

Case (c) bundles are dual-purpose: they carry both the iteration content (for the counterpart repo's γ to apply) and the cnos-side patch trace (for cnos's record of patches that landed in cnos as part of the same iteration).

Case (d) — Operator-pending bundle

Substantive content drafted for a target the current cnos session cannot reach. Three sub-shapes observed:

• (d.1) target-repo-doesn't-exist — full file drafts staged in cnos for a repo the operator will scaffold. Example: cn-rho/bootstrap-2026-05-19 (drafts for usurobor/cn-rho before the repo exists).
• (d.2) target-repo-exists-but-unreachable — feedback patch for an existing repo that the current session's MCP / credential scope cannot write to. Example: cn-sigma/discipline-section-2026-05-19.
• (d.3) proposal-as-issue-comment — proposal shaped as a GitHub issue comment rather than a file patch (e.g. retargeting an existing issue). Example: cph/issue-32-tightening-2026-05-19.

Case (d) is structurally degenerate relative to (a)–(c): it carries no STATUS state machine (there is no source-side γ on the other end emitting submitted). Its lifecycle is operator-applied → archive. The protocol covers it as a named case with a simpler shape, not by forcing it into the proposal-lifecycle frame.

Rule 2.1.a — Identify the case before authoring the bundle

• ❌ Begin authoring a bundle "following the precedent" without naming which case the cycle is in.
• ✅ Name the case (a.1 / a.2 / b / c / d.1 / d.2 / d.3) in the first paragraph of LINEAGE.md so the schema selection is auditable.

2.2. Canonical path

One canonical path: .cdd/iterations/cross-repo/{counterpart-repo}/{slug}/ on whichever side carries the bundle.

{counterpart-repo} is "the repo that is not me". On cnos:

• For case (a) inbound: cnos:.cdd/iterations/cross-repo/{source-repo}/{slug}/ (source name appears).
• For case (b) outbound: cnos:.cdd/iterations/cross-repo/{target-repo}/{slug}/ (target name appears).
• For case (c) bilateral: cnos:.cdd/iterations/cross-repo/{counterpart-repo}/{slug}/ (the not-cnos repo).
• For case (d) operator-pending: cnos:.cdd/iterations/cross-repo/{prospective-or-unreachable-target}/{slug}/.

The corresponding source-side path on the counterpart repo (when the counterpart is CDD-activated) is {counterpart}:.cdd/iterations/cross-repo/cnos/{slug}/.

This path resolves the historical collision between "intake scan" and "outbound trace" — both directions share the path shape; they are distinguished by event semantics (presence of source-vs-target events in STATUS) and LINEAGE schema (Source vs Target section content).

Rule 2.2.a — Use exactly one canonical path

• ❌ Stage an inbound proposal mirror at .cdd/proposals/{target}/{slug}/ or .cdd/iterations/proposals/{slug}/.
• ✅ Stage all cross-repo bundles at .cdd/iterations/cross-repo/{counterpart-repo}/{slug}/, direction-agnostic.

2.3. STATUS state machine

A STATUS ledger applies to cases (a) and (c) when the case carries proposal-shaped lifecycle. Cases (b) and (d) do not carry STATUS (case b's trace is patch-confirmation in LINEAGE; case d's disposition is recorded in LINEAGE).

The STATUS vocabulary is canonical in this skill (§2.3); CDS / CDR / CDD bind or consume it, but do not own it. This section codifies the transition graph, emitter rules, master/sub landed rule, and bundle-state phase mapping. Consumer-side surfaces (notably cnos.cds/skills/cds/CDS.md §"Coordination surfaces" → "Cross-repo proposals") cite this section as the authoritative source rather than re-declaring the vocabulary.

2.3.1. Event vocabulary

Eight events:

Event	Meaning
drafted	Source has written the proposal but has not requested target action. Pre-intake.
submitted	Source requests target intake. This is the only event required for target intake.
accepted	Target γ will act substantially as proposed and has filed a target reference.
modified	Target γ accepts the governing gap but changes scope, split, wording, implementation, proof, or patch application materially. The target issue's ## Source Proposal block carries a Delta field. May also fire post-accepted to record a refinement (e.g. issue body edit folding in upstream changes).
landed	Target work merged or otherwise became target truth. For 1:1 — one event. For master/sub — one per sub merge + one terminal master-close (see §2.3.4).
rejected	Target γ declines the proposal. Terminal.
withdrawn	Source retracts the request. Terminal.
revised / corrected	Optional audit events for post-submission revisions or corrections. Do not rewrite old events after sharing — append a corrected event instead.

2.3.2. Transition graph

                ┌──────────────┐
                │   (start)    │
                └──────┬───────┘
                       │ source role
                       │ authors bundle
                       ▼
                ┌──────────────┐  source retracts
                │   drafted    │──────────────────┐
                └──────┬───────┘                  │
                       │                          │
                       │ source γ                 │
                       │ requests intake          │
                       ▼                          │
                ┌──────────────┐                  │
                │  submitted   │──────────────────┤
                └──────┬───────┘                  │
                       │                          │
                       │ target γ                 │
                       │ disposition              │
       ┌───────────────┼──────────────────┐       │
       ▼               ▼                  ▼       │
  ┌─────────┐    ┌──────────┐       ┌──────────┐  │
  │accepted │◀──▶│ modified │       │ rejected │  │
  └────┬────┘    └────┬─────┘       └──────────┘  │
       │              │              (terminal)   │
       │              │                           │
       │ target       │                           ▼
       │ work         │                     ┌──────────┐
       │ merges       │                     │withdrawn │
       └──────┬───────┘                     └──────────┘
              │                              (terminal)
              ▼
         ┌────────┐
         │ landed │
         └────────┘
          (terminal — per §2.3.4 master/sub)

  *  → revised | corrected   (optional audit events; do not change state;
                              may fire from any non-terminal state)

Legal transitions:

• (start) → drafted | submitted (source authors directly into either state)
• drafted → submitted (source γ requests intake)
• drafted → accepted | modified | rejected (permitted when source explicitly delegates filing-authority to target without intermediate submitted — see §2.3.3 below)
• drafted → withdrawn
• submitted → accepted | modified | rejected | withdrawn
• accepted → modified (post-filing refinement; Delta updated)
• modified → modified (further refinement)
• accepted → landed
• modified → landed
• * → revised | corrected (any non-terminal state may emit an audit event without changing lifecycle state)

Illegal transitions:

• rejected → * (terminal)
• landed → * (terminal — for 1:1; master/sub permits multiple landed rows per §2.3.4)
• withdrawn → * (terminal)
• submitted → landed (must pass through accepted or modified)
• modified → accepted (cannot un-modify once delta is recorded)

2.3.3. drafted → accepted (direct acceptance from drafted state)

The cn-sigma/agent-activate-skill anchor shows drafted sigma → accepted gamma@cnos without an intermediate submitted event. Per §2.3.1 above, submitted is "the only event required for target intake" — implying intake without submitted is unusual but not impossible. The protocol permits drafted → accepted (or modified / rejected) when:

1. The source explicitly delegates filing-authority to the target (e.g. an agent hub authoring a proposal whose first reader is expected to act, not approve-then-act).
2. The target γ records the delegation in the cnos-side LINEAGE's ## Source or ## Target section.

The mirror STATUS may carry the original drafted event; the cnos-side mirror does not retroactively insert a submitted event the source did not emit.

2.3.4. Emitters per event

Event	Emitter	Write target
drafted	source role (γ or other) authoring the bundle	source-side STATUS at authoring time
submitted	source γ	source-side STATUS when source γ requests target intake
accepted / modified / rejected	target γ	source-side STATUS via direct push if cross-repo write is authorized; otherwise via FEEDBACK.patch for source γ to apply
landed (1:1)	target γ	source-side STATUS (and cnos-side mirror STATUS) when the cycle implementing the target issue merges to target main
landed (master/sub)	target γ per §2.3.5	source-side STATUS (one row per sub merge + one terminal master-close row)
withdrawn	source γ	source-side STATUS when source retracts the request
revised / corrected	event-originator (source or target as relevant)	source-side STATUS; optional audit-only — does not change lifecycle state

Constraint: after the target γ's filing decision, source STATUS must not remain at submitted (or at drafted once target γ has taken action on a delegated drafted → accepted path). The decision must be recorded — directly or via feedback patch — within the same target session that made the decision.

2.3.5. Master/sub rule for landed

For master/sub-shaped proposals (case a.2):

1. Per-sub landed event fires each time a sub merges to target main, with the form:

   <ISO-date> landed gamma@<target> <target-sub-issue#> <merge-sha> <release-version>
   

2. Terminal master-close landed event fires when the master issue is closed (all subs landed, or deferred subs explicitly named as tracked debt in the master's closure condition):

   <ISO-date> landed gamma@<target> <target-master-issue#> master-close
   

A wave with 4 subs landing across 3 releases produces 5 landed rows: 4 per-sub + 1 master-close.

For 1:1 proposals (case a.1): one landed event total. No separate master-close because the issue is the only target unit.

• ❌ Leave a master/sub proposal at accepted indefinitely after subs land, because "the master hasn't closed yet."
• ✅ Emit per-sub landed rows as each sub merges; emit the master-close row when the master closes.

2.4. Bundle-state phases

.cdd/iterations/cross-repo/README.md defines three bundle-state phases: open | converging | closed. Mapping to STATUS:

Bundle phase	STATUS event(s)	Meaning
open	drafted or submitted (or initial state)	Filed; no target disposition yet. Both pre-intake (drafted) and intake-requested (submitted) sit here.
converging	accepted or modified (no terminal landed yet; may carry partial per-sub landed rows)	Target accepted; work in flight.
closed	terminal landed (1:1) or master-close landed (master/sub) or rejected or withdrawn	No further work expected.

Audit events (revised, corrected) do not change the bundle's phase — they record post-hoc corrections to earlier events without re-opening or re-closing the bundle.

For cases (b), (c), (d) — which carry no STATUS — the bundle-state phase is derived from LINEAGE state:

Case	Phase derivation
(b) outbound	open while patches are in flight; closed when all patches confirmed landed in the target's per-patch table.
(c) bilateral	open while ε deliverables (cnos-side and counterpart-side) are pending; closed when both sides land their respective patches and the iteration record is committed in each repo's cdd-iteration.md.
(d) operator-pending	drafted (operator-pending) (LINEAGE.md Disposition field) until the operator effects the application; then closed. This is a phase-name synonym for open for inventory purposes — case (d) bundles report as open in bundle-state inventories until their application gate fires.

2.5. Bundle file set per case

Case (a) — Inbound proposal (1:1 or master/sub)

Required files on the cnos side:

File	Required?	Purpose
LINEAGE.md	yes	Bilateral trace; per §2.6 schema
STATUS	yes	Event ledger (mirror of source STATUS + cnos-side authoritative landed rows)
FEEDBACK.patch	conditional	Required when the cnos session cannot write to source-side STATUS directly
ISSUE.md	optional	Verbatim copy of source ISSUE.md for audit (useful when source bundle is dormant)
README.md	discouraged	Do not place protocol doctrine here; bundle-specific narrative belongs in LINEAGE.md

Case (b) — Outbound iteration trace

Required files on the cnos side (mirror, after source-side bundle is archived):

File	Required?	Purpose
LINEAGE.md	yes	Bilateral trace; per-patch confirmation; mirror status

The source-side bundle (under counterpart-repo's .cdd/iterations/cross-repo/cnos/{slug}/) carries the working files (patches, lineage, STATUS if a proposal lifecycle is attached). After target patches merge and target-side mirror confirms receipt, the source-side may be archived (see §2.8).

Case (c) — Bilateral iteration

Required files on the cnos side:

File	Required?	Purpose
LINEAGE.md	yes	Bilateral trace + hat-collapse acknowledgment + per-patch trace per destination repo
cdd-iteration.md	yes	The ε work product when the bilateral iteration carries ε output (per cnos.handoff/skills/handoff/receipt-stream/SKILL.md for the canonical per-finding shape + aggregator rules; cnos.cdd/skills/cdd/epsilon/SKILL.md §1 for ε's CDD-side role-local authority on gap-class instantiation)
<patch>.patch	one per outbound patch	Feedback patches for the counterpart repo to apply, named descriptively

Case (d) — Operator-pending

Required files on the cnos side:

File	Required?	Purpose
LINEAGE.md	yes	Carries Status: drafted (operator-pending) and the application gate
Substantive content	varies	Drafted artifact(s): file content for (d.1), <file>.patch for (d.2), issue-comment.md for (d.3)

No STATUS ledger — there is no proposal lifecycle to track.

Rule 2.5.a — Use the bundle file set the case requires, no more, no less

• ❌ Author a case (a) bundle without a STATUS file because "the precedent didn't have one" (the precedent was a different case).
• ❌ Add a README.md carrying protocol doctrine because "future readers will want context" (doctrine archives with the bundle if the bundle is archived).
• ✅ Match the file set to the case in §2.5; place narrative inside LINEAGE.md; place protocol doctrine here in this skill.

2.6. LINEAGE.md schema per case

Case (a) inbound proposal — required sections

• ## Source (counterpart repo, branch, commit, path)
• ## Target (cnos repo, issue #, mode, disposition, first filing commit/branch, canonical-path on cnos main)
• ## Delta — required only when disposition = modified; names what changed and why
• ## Bilateral trace — which side carries what; archival predicate
• ## Per-sub confirmation — master/sub only; table of subs (proposed shape, cnos issue #, cnos commit, status). Omit for 1:1.
• ## Per-patch confirmation — 1:1 with multi-patch only; table of patches and target commits
• ## Related cross-repo wave context — optional; links to wave artifacts, repository rename events, sibling bundles

Case (b) outbound — required sections

• ## Source (cnos cycle, branch, commit, source-side path)
• ## Target (counterpart repo, target issue, target PR/commit, patches landed)
• ## Bilateral trace (mirror status)
• ## Per-patch confirmation — table of patch numbers, target commits, status

Case (c) bilateral — required sections

• ## Source (counterpart repo, branch, wave, master issue, sub issues, wave verdict)
• ## ε actor (or relevant role name) — hat-collapse acknowledgment: played-by, authority basis, output date (per §2.9)
• ## Target patches — per-patch table, one row per destination repo
• ## Bundle contents — file-by-file purpose
• ## Bilateral trace direction — why this is on this side; what the counterpart side carries
• ## Protocol observations forwarded — optional; when the iteration surfaces protocol gaps for codification in this skill

Case (d) operator-pending — required sections

• ## Purpose — one-paragraph what-this-stages
• ## Source — trigger, reference doctrine, sibling exemplar, empirical anchor
• ## Bundle contents — file-by-file purpose
• ## Operator-side scaffolding steps (case d.1) OR ## Application (case d.2/d.3)
• ## Verification after application — case d.2 specifically; how the operator confirms the patch landed
• ## What is NOT in scope here / ## What this bundle does NOT do — optional but recommended; prevents scope creep
• ## Disposition — always drafted (operator-pending) for case d

Rule 2.6.a — Select the LINEAGE schema by case, not by precedent

• ❌ Copy the LINEAGE shape from the most recent bundle, even if the case differs.
• ✅ Identify the case (§2.1), then use the schema in §2.6 for that case.

2.7. Feedback-patch format

A feedback patch is a unified diff against a counterpart-side file, wrapped in a header.

Header form:

From: <actor identity> (<originating branch>)
Date: <ISO date>
Subject: <one-line summary>

<free-prose context: apply command, rationale, links to related artifacts>

---

<unified diff>

Apply command convention: git apply <patch-filename> from the counterpart repo root.

Patch filename convention:

• FEEDBACK.patch — when the patch's purpose is STATUS-event emission only. Canonical name.
• <descriptor>.patch — when the patch carries substantive content. Lowercase-with-hyphens descriptor (e.g. cdr-changelog-rule.patch, PERSONA-discipline.patch).

Content rules:

• Diff is against the counterpart-side file path (e.g. a/.cdd/iterations/cross-repo/cnos/{slug}/STATUS, a/CDR.md, a/spec/PERSONA.md).
• Header includes the cnos-side cross-reference to where the bilateral trace lives (cnos:.cdd/iterations/cross-repo/{counterpart}/{slug}/LINEAGE.md).
• When the patch documents a protocol observation worth forwarding (e.g. cn-sigma's drafted-event observation forwarded to cnos#377), include the observation in the header context.

Rule 2.7.a — Use the canonical feedback-patch format

• ❌ Emit a feedback "patch" as a YAML script, a replacement-file blob, or a free-prose change request.
• ✅ Emit a unified diff with the header form above; the counterpart γ applies with git apply.

2.8. Bundle archival rule

A bundle's archival rule depends on direction and side.

2.8.1. Source-side may be deleted when

Case	Source side may archive when
(a) inbound	The cnos-side mirror exists on cnos main and the cycle implementing the target work has closed (terminal landed event recorded).
(b) outbound	The cnos-side (source) bundle may be archived once the counterpart-side mirror confirms receipt of all patches landed.
(c) bilateral	The counterpart-side bundle (the side that cannot write directly) may be archived once the counterpart applies the patches and emits its own iteration trace.
(d) operator-pending	The bundle may be archived once the operator effects the application (target repo created with files / patch applied / comment posted).

2.8.2. Target-side (mirror) is preserved indefinitely

Mirror bundles on cnos:.cdd/iterations/cross-repo/{counterpart}/{slug}/ when cnos is the target (case a) are preserved indefinitely as audit artifacts and retroactive validators. They are not subject to archival.

Source-side bundles where cnos is the source (case b / c) may be deleted post-archival per §2.8.1.

Rule 2.8.a — Asymmetric archival

• ❌ Delete the cnos-side mirror of an inbound proposal once the work lands ("cycle is done; mirror not needed").
• ✅ Preserve target-side mirrors as audit artifacts; archive source-side bundles once the counterpart records receipt.

2.9. Hat-collapse attribution

When a single actor plays γ in repo A and ε (or another role) in repo B during the same session, attribution is recorded in two places:

1. In the bundle LINEAGE.md, a ## ε actor (or equivalent role-name) section names:

   • Played by: — actor identity + originating session branch
   • Authority basis: — citing cnos.cdd/skills/cdd/epsilon/SKILL.md §2 ("ε and δ are often the same actor") + ROLES.md §4 role-collapse rules + any operator-specific delegation
   • Output date: — ISO date

2. In the cdd-iteration.md (when case (c) produces ε output), a top-level ## Hat-collapse acknowledgment section names:

   • which two roles are collapsed in this session
   • the authority basis citation
   • an explicit statement that the substantive role-A and role-B work are independent
   • the reason hat-collapse does not collapse with α/β/γ responsibilities for any in-flight cycle

Boundary preservation: the attribution form names role-collapse as factual record, not as authority override. Per ROLES.md §4a persona/protocol/project boundary, the personas stay distinct (e.g. cnos γ identity ≠ cph ε identity); the actor wearing both hats acknowledges the collapse and carries the substantive work for each role independently. This skill's hat-collapse section documents an actor-level fact (one human/agent ran two sessions of work) without merging the role-level identities or authorities — the persona/protocol/project boundary is preserved.

Rule 2.9.a — Record hat-collapse where it happens

• ❌ Hide hat-collapse by attributing both pieces of work to "the session" without naming the actor or the two roles.
• ✅ Name the collapse in LINEAGE.md §"<role> actor" and (for case c) in cdd-iteration.md §"Hat-collapse acknowledgment".

2.10. Known protocol edge cases

These are observed shapes that the protocol covers explicitly. New edge cases discovered in future cycles are added here.

• drafted → accepted direct acceptance — agent-hub source repos may author a bundle in drafted state and delegate filing-authority to the target, who acts on the bundle without an intermediate submitted event. The transition is legal (per §2.3.3) when the cnos-side LINEAGE records the delegation in ## Source or ## Target. Empirical anchor: cn-sigma/agent-activate-skill (source drafted sigma cn-tau@8f153c15e → target accepted gamma@cnos cnos#379).

• Repository rename mid-coordination — when a source repo is renamed (e.g. gait-support-paths → cph on 2026-05-18), the cnos-side mirror's path is updated to the new name; the pre-rename mirror is preserved as an archived audit artifact. The LINEAGE.md ## Repository rename event section names the rename and its consequences. Empirical anchor: cph/bootstrap-cdr (with archived pre-rename mirror at gait-support-paths/bootstrap-cdr).

• Post-filing refinement — a target γ may transition accepted → modified when post-filing upstream changes warrant folding into the target issue body. The Delta field of the target issue's ## Source Proposal block is updated; the source STATUS receives a modified event. Empirical anchor: cn-sigma/agent-activate-skill (AC4 capability-matrix refinement folded in 7 minutes after filing).

• Asymmetric source posture — when the source repo is an agent hub (not a CDD-activated tenant repo), the source-side bundle may live on source main rather than on a dormant branch. The cnos-side mirror remains canonical. Empirical anchor: cn-sigma (full bundle on cn-sigma main, asymmetric to cph/bootstrap-cdr whose bundle is on a dormant branch).

• Dual-purpose case-c bundle — case (c) bundles carry both iteration content (for the counterpart's γ to apply) and the cnos-side patch trace. The dual purpose is named explicitly in LINEAGE.md §"Bilateral trace direction". Empirical anchor: cph/coherence-drift-sweep-followup-2026-05-18.

• Proposal-as-issue-comment (case d.3) — a proposal that retargets or comments on an existing target issue, rather than emitting a new ISSUE.md or patch. The bundle carries issue-comment.md as the deliverable. The operator pastes the comment on the target issue. Empirical anchor: cph/issue-32-tightening-2026-05-19.

• Target-repo-doesn't-exist (case d.1) — drafts staged for an operator-scaffolded repo. The bundle carries the prospective files (e.g. PERSONA.md, OPERATOR.md). Empirical anchor: cn-rho/bootstrap-2026-05-19.

• Issue-edit cache-bust on post-filing refinement — when a modified event fires post-accepted because the target γ folds an upstream change into the target issue body's ## Source Proposal block (or any other Delta-bearing edit), the same write may need to propagate to an in-flight role on the target's cycle branch. The canonical mechanism is the gamma-clarification.md rescue at cnos.handoff/skills/handoff/mid-flight/SKILL.md — γ commits a clarification entry to .cdd/unreleased/{N}/ on cycle/{N} before running the gh issue edit that records the Delta. The cycle-branch SHA transition is the polling role's cache-bust signal; relying on the GitHub issue mtime alone is unreliable for MCP-cached intake. Empirical anchor: cn-sigma/agent-activate-skill (post-filing refinement folded in 7 minutes after filing); the cnos-side practice of the cache-bust channel is anchored at cnos#391.

---

3. Rules

3.1. Identify the directional case first

• ❌ Author a bundle "following the precedent" without naming which case the cycle is in.
• ✅ Name the case (a.1 / a.2 / b / c / d.1 / d.2 / d.3) in the first paragraph of LINEAGE.md; the schema selection becomes auditable.

3.2. Use the canonical path

• ❌ .cdd/proposals/{target}/{slug}/ or .cdd/iterations/proposals/{slug}/.
• ✅ .cdd/iterations/cross-repo/{counterpart-repo}/{slug}/.

3.3. After filing decision, source STATUS must not remain at submitted or drafted

• ❌ File the target issue, then forget to emit the accepted event to source STATUS (directly or via FEEDBACK.patch).
• ✅ Emit the disposition event in the same session that made the decision. (For drafted → accepted direct acceptance per §2.3.3, the same constraint applies — source STATUS must not remain at drafted after target γ acts.)

3.4. Emit landed per master/sub rule

• ❌ Treat landed as a single event for a master/sub proposal ("the work is done").
• ✅ Per-sub landed rows as each sub merges; terminal master-close landed row when the master closes (§2.3.5).

3.5. Keep protocol doctrine in this skill, not in bundle READMEs

• ❌ Place archival rules, schema definitions, or STATUS doctrine inside a bundle's README.md.
• ✅ Doctrine lives here; bundle LINEAGE.md describes only the bundle's specific context.

3.6. Mirror target-side bundles are preserved indefinitely

• ❌ Delete a cnos-side mirror of an inbound proposal once the work lands.
• ✅ Preserve target-side mirrors as audit artifacts and retroactive validators.

3.7. Use the canonical feedback-patch format

• ❌ Emit a feedback "patch" as YAML, a replacement file, or prose.
• ✅ Unified diff with the header form in §2.7; git apply from counterpart repo root.

3.8. Record hat-collapse where it happens

• ❌ Attribute the work to "the session" without naming the actor or the two roles.
• ✅ LINEAGE.md §"<role> actor" + (for case c) cdd-iteration.md §"Hat-collapse acknowledgment".

3.9. Identify case (d) explicitly when no STATUS lifecycle applies

• ❌ Force a case-d bundle into the proposal-lifecycle frame with a hollow STATUS.
• ✅ Name (d.1) / (d.2) / (d.3) in LINEAGE; carry Disposition: drafted (operator-pending) and the application gate.

3.10. Cross-reference, do not duplicate

Consumer protocol skills cite this skill for cross-repo doctrine. If you find cross-repo doctrine in cnos.cdd/skills/cdd/gamma/, cnos.cdd/skills/cdd/post-release/, cnos.cds/skills/cds/CDS.md, or elsewhere that contradicts this skill, this skill governs and the other surface is patched to reference this one.

---

4. Verify

4.1. Case-identification check

• Did LINEAGE.md name the case (a.1 / a.2 / b / c / d.1 / d.2 / d.3) in its first paragraph?
• Does the bundle file set match §2.5 for that case?
• Does the LINEAGE schema match §2.6 for that case?

4.2. STATUS check (cases a, c when proposal-shaped)

• Is the source STATUS at a non-submitted event after target γ's filing decision?
• For master/sub: are per-sub landed rows present for each merged sub?
• Are illegal transitions absent (e.g. no submitted → landed skip)?

4.3. Archival check

• For source-side bundles: is the archival predicate (per §2.8.1) named in LINEAGE.md §"Bilateral trace"?
• For target-side mirrors: are they preserved (not subject to archival)?

4.4. Doctrine-locality check

• Is the bundle's README.md (if present) free of protocol doctrine?
• Does protocol doctrine live only in this skill?

---

5. Cross-references

• cnos.cdd/skills/cdd/gamma/SKILL.md §2.1 — cross-repo proposal intake (consumer): references this skill for case (a) directional rules.
• cnos.cdd/skills/cdd/gamma/SKILL.md §2.7 — cross-repo proposal close-out (consumer): references this skill for landed emitter and master/sub rule.
• cnos.handoff/skills/handoff/receipt-stream/SKILL.md §6 — canonical wire-format home for the cross-repo trace trigger (the patch-landed + Cross-repo disposition that fires the bundle). References this skill for case (b) outbound bundle file set and §2.8 archival.
• cnos.cdd/skills/cdd/post-release/SKILL.md §5.6b — cdd-side runbook (pointer); applies the receipt-stream rule at cycle close-out.
• cnos.cdd/skills/cdd/issue/SKILL.md minimal output pattern ## Source Proposal block (consumer) — target-side issue-body integration; stays in issue/.
• .cdd/iterations/cross-repo/README.md — bundle convention; references this skill for the canonical state machine.
• cnos.cdd/skills/cdd/epsilon/SKILL.md §1 — ε's cdd-iteration.md work product; relates to case (c) bilateral bundle file set §2.5.
• cnos.cds/skills/cds/CDS.md §"Coordination surfaces" → "Cross-repo proposals" — software-class binding (consumer): cites this skill's §2.3 as the canonical STATUS state machine.
• ROLES.md §4 — role-collapse rules; cited from §2.9 hat-collapse attribution.
• ROLES.md §4a — persona / operator / protocol / project / receipt boundary; cited from §2.9 to confirm the attribution form preserves the boundary.

---

6. Kata

Scenario

cnos γ is dispatched on a new cycle. While running the intake scan in cnos.cdd/skills/cdd/gamma/SKILL.md §2.1, γ finds a STATUS ledger in a source repo usurobor/cn-tau at .cdd/iterations/cross-repo/cnos/agent-trace-hook/STATUS whose last non-comment event reads drafted sigma cn-tau@abc1234.

Task

1. Identify the directional case.
2. Decide the disposition (accepted / modified / rejected).
3. Stage the cnos-side bundle correctly.
4. Emit the STATUS update.

Expected reasoning

1. Case identification. Source is cn-tau; substantive target work would happen in cnos. This is case (a) inbound. Single proposal; sub-shape is (a.1) unless the proposal body declares master/sub.

2. drafted reading. Per §2.3.1, drafted is a distinct first-class event meaning "source has written the proposal but has not requested target action". The cn-tau STATUS at drafted means filing-authority has not yet been requested by source γ — γ checks whether the source posture (agent hub) is delegating filing-authority. If yes, γ proceeds via §2.3.3 drafted → accepted direct-acceptance and records the delegation in LINEAGE. If no, γ asks the source γ to emit submitted first.

3. Disposition. γ reads ISSUE.md and decides; let's say accepted. The cnos-side target issue is filed with a ## Source Proposal block citing cn-tau path + commit + disposition.

4. Bundle staging. Cnos-side bundle at cnos:.cdd/iterations/cross-repo/cn-tau/agent-trace-hook/:

   • LINEAGE.md — case (a.1) schema: ## Source, ## Target, ## Bilateral trace. Names the case in the first paragraph.
   • STATUS — mirror of source STATUS, preserving the drafted event (do not retroactively insert submitted) and appending the new accepted gamma@cnos cnos#<new-issue#> row per §2.3.3 direct-acceptance.
   • FEEDBACK.patch — required if cnos session cannot write to cn-tau. Header + apply command + unified diff against source STATUS appending the accepted event.

5. STATUS update. Source STATUS must not remain at submitted/drafted post-decision. Either direct push to cn-tau (if authorized) or FEEDBACK.patch for cn-tau γ to apply.

Common failures

• Filing the cnos issue but forgetting to emit the accepted event to source STATUS.
• Authoring LINEAGE.md without naming the case in the first paragraph.
• Placing the FEEDBACK.patch under .cdd/proposals/... instead of the canonical path.
• Treating drafted as unknown and refusing intake.

Verification

• LINEAGE.md first paragraph names case (a.1).
• Source STATUS last event = accepted gamma@cnos cnos#<N>.
• Bundle file set matches §2.5 case (a).
• No bundle README.md carrying protocol doctrine.

Reflection

A second γ reading this kata's output should be able to reconstruct the disposition, locate every artifact, and verify all events fired in the right order — without consulting the original cycle session.