---
name: delta
description: δ role-skill. Owns the two-sided coherence-cell membrane (outward boundary decision on receipt + V verdict; inward implementation-contract enrichment at dispatch) and the override authority that compose with V's verdict per RECEIPT-VALIDATION.md.
artifact_class: skill
kata_surface: embedded
governing_question: What does δ-as-role decide at the cell's boundary — both the receipt-facing outward gate and the dispatch-facing inward enrichment — and what authority does δ hold over override?
visibility: internal
parent: cdd
triggers:
  - boundary
  - membrane
  - override
  - receipt
  - verdict
  - gate
  - dispatch-enrichment
  - implementation-contract
scope: role-local
inputs:
  - typed receipt emitted by γ at close-out (RECEIPT-VALIDATION.md §Validation Interface)
  - ValidationVerdict emitted by V (RECEIPT-VALIDATION.md §Output contract)
  - γ-authored dispatch prompts containing the `## Implementation contract` section (wire-format at cnos.handoff/skills/handoff/dispatch/SKILL.md; γ-side authoring at gamma/SKILL.md §2.5)
  - repo conventions (language, package scoping, integration-target, etc. — for inward enrichment)
outputs:
  - BoundaryDecision recorded against (receipt, verdict) — one of {accept, release, override, reject, repair_dispatch}
  - dispatch-prompt enrichment when γ leaves implementation-contract rows unpopulated (or escalation to operator-as-human when undecidable)
  - override declarations with structured override block when proceeding against non-PASS verdict
requires:
  - active CDD cycle exists with a closed cell at scope n (receipt + verdict materialised)
  - "or: active γ dispatch prompt awaiting δ's pre-routing enrichment"
calls:
  - RECEIPT-VALIDATION.md
  - COHERENCE-CELL-NORMAL-FORM.md
  - operator/SKILL.md
---

# δ (delta) — the cell's boundary actor

## Core Principle

**δ is the coherence cell's boundary — the actor that decides what crosses from scope `n` to scope `n+1`, and the actor that enriches what crosses from γ's protocol-level contract into α's executable dispatch.**

δ is a **two-sided membrane**:

```text
δ as two-sided membrane:

  outward:  receipt + V verdict → parent-scope boundary decision   (§1)
            (V dereferences evidence from the receipt; δ records
             a BoundaryDecision against the verdict)

  inward:   γ contract → α-ready dispatch                           (§2)
            (implementation-contract enrichment happens here:
             γ writes protocol-level; δ pins implementation-level)
```

`COHERENCE-CELL-NORMAL-FORM.md` (CCNF) names δ at step 5 of the kernel — δ reads the receipt and V's verdict and records a `BoundaryDecision`. `RECEIPT-VALIDATION.md` freezes the typed interface: V emits a `ValidationVerdict`; δ emits a `BoundaryDecision`; the two surfaces are independent and compose by an explicit rule (§4 below). The δ-inward function is the complementary face — the dispatch-time enrichment that pins the implementation-contract axes γ's protocol-level contract leaves unpinned.

**δ-the-role lives here.** δ-as-actor in a running CDD cycle (γ=δ collapse cases, dispatch coordination, gate routing) lives in [`operator/SKILL.md`](../operator/SKILL.md); the harness substrate (dispatch invocation, observability, identity, polling, timeout recovery) lives in [`harness/SKILL.md`](../harness/SKILL.md) (Phase 4b of cnos#366, landed at cnos#398); release-effector mechanics live in [`release-effector/SKILL.md`](../release-effector/SKILL.md) (Phase 4c of cnos#366, landed at cnos#399). The four surfaces are deliberately separate: the role-skill is portable (any role-scope ladder instantiation per `ROLES.md` can carry it); the substrate skills are the substrate-specific realizations on the current substrate (per CCNF §Two-Layer Separation: kernel is the *what*, realization is the *how-on-this-substrate*).

> **First-time operator?** The dispatch-coordination layer (γ=δ collapse, single-session vs multi-session, harness quiescence, timeout recovery) is in [`operator/SKILL.md`](../operator/SKILL.md) (coordination) + [`harness/SKILL.md`](../harness/SKILL.md) (mechanics). δ-the-role's authority and policy live here.

---

## 1. Outward membrane — receipt + verdict → boundary decision

The outward face of δ runs after γ closes the cell and emits the receipt. V validates the receipt against the contract (per CCNF step 4 + `RECEIPT-VALIDATION.md` §Q1) and emits a `ValidationVerdict`. δ then records a `BoundaryDecision` — the outward act that determines whether and how the closed cell crosses to scope `n+1`.

```text
γ closes cell                    →   closed_cell exists; receipt drafted
γ emits receipt                  →   receipt exists; cell is "closed", not "accepted"
δ invokes V on receipt           →   V emits ValidationVerdict
δ records BoundaryDecision       →   {accept | release | override | reject | repair_dispatch}
ACCEPTED                         →   receipt transmissible to parent scope
```

(Per `RECEIPT-VALIDATION.md` §Q1 ordering rule. `V` is a typed predicate exposed as a capability per §Q2; δ invokes the capability, not the operator-facing `cn-cdd-verify` command.)

### 1.1. External actions δ-the-role authorises

δ-as-role holds **authority** for the platform actions that cross the boundary. The mechanics of executing these actions live in three companion surfaces: [`operator/SKILL.md`](../operator/SKILL.md) §3 (gate-action confirmation protocol, request-vs-observation discipline); [`harness/SKILL.md`](../harness/SKILL.md) (dispatch invocation, observability, identity, polling, timeout recovery — landed via Phase 4b of cnos#366, cycle/398); [`release-effector/SKILL.md`](../release-effector/SKILL.md) (`scripts/release.sh` invocation, post-push CI polling, recovery runbook, branch deletes — landed via Phase 4c of cnos#366, cycle/399). The authority-naming surface lives here:

| Action | Authority | Mechanics location |
|--------|-----------|--------|
| Pre-merge gate validation | δ authorises; γ requests via `scripts/validate-release-gate.sh --mode pre-merge` (`cnos.cds/skills/cds/CDS.md` §"Artifact contract" → §"Ownership matrix" + `gamma/SKILL.md` §2.10) | `operator/SKILL.md` §3.1 |
| Push β-approved merge to main | δ executes on β's behalf when env/auth blocks β; this is execution of β's integration authority, not δ approval | `operator/SKILL.md` §3.1 |
| Release-boundary preflight | δ verifies merge commit, release artifacts, tag/deploy preconditions, platform readiness; decision is proceed / request changes / override (`cnos.cds/skills/cds/CDS.md` §"Development lifecycle" → §"Step table" Step 9 — δ gate) | `operator/SKILL.md` §3.1 |
| Tag push + release | **δ is sole tag-author** — β does not tag; only δ creates tags per cycle | `release-effector/SKILL.md` |
| Branch delete | After cycle closure and merge | `release-effector/SKILL.md` §5 |
| Issue filing on external repos | Cross-project dependency | `operator/SKILL.md` §3.1 |
| Force push | Rebase required with env constraints | `operator/SKILL.md` §3.1 |
| Auth refresh | Token/permission expiry | `operator/SKILL.md` §3.1 |

The role-policy that governs the release boundary: **the triad's work is not complete until tagged.** Untagged post-cycle patches on main are an open boundary — the triad's output is still entangled with whatever comes next. The tag is the disconnection point. δ-as-role commits to this property; the `scripts/release.sh` runbook lives in [`release-effector/SKILL.md`](../release-effector/SKILL.md) (Phase 4c of cnos#366 — landed via cycle/399; the doctrinal frame stays at `operator/SKILL.md` §3.4).

**δ blocks release completion until CI is green and owns recovery on red.** This is δ-role policy:

- **CI Green** → δ declares release complete.
- **CI Red** → δ owns the failure. Investigate release logs; classify as release-specific vs pre-existing infrastructure; fix or escalate; re-verify; operator override (§3 below) is the explicit escape hatch for known pre-existing failures (cf. v3.66.0/v3.67.0 smoke failures).

The gate does not close until CI is green or δ explicitly records an override (§3).

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

Gate actions fire when a role **requests** them, not when δ notices they're needed. Observing that a tag isn't pushed or a branch exists is not a gate trigger — γ's explicit request is.

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

### 1.3. Report completion

After executing a gate action, confirm to the requesting role that the action completed.

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

### 1.4. The tag is the signal

The disconnect tag (cf. `operator/SKILL.md` §3.4 for the runbook) is git-observable. γ and all future agents can see it. No separate completion signal is needed — the tag appearing on main IS the proof that all gate actions completed and the cycle is disconnected.

For mid-cycle gate actions (tag push before the disconnect, branch cleanup), confirm completion to the requesting role per §1.3. But the disconnect tag itself needs no announcement — it speaks for itself.

### 1.5. BoundaryDecision: the five outcomes δ records

Per CCNF §Cell Outcomes, the closed cell at scope `n` terminates in one of four outcomes, determined by `(verdictₙ, decisionₙ)`. δ records `decisionₙ` as one of five enumerants; the outcome is the `(verdict, decision)` pair:

| `decisionₙ` (δ records) | When | CCNF outcome |
|---|---|---|
| `accept` | `verdictₙ = PASS` and the cell is transmissible to scope `n+1` without release-boundary semantics | `accepted` |
| `release` | `verdictₙ = PASS` and the cell ships as a release boundary (tag + downstream-distributable disconnection) | `accepted` |
| `override` | `verdictₙ ≠ PASS` and δ proceeds anyway by recording a structured override block (§3 below) | `degraded` |
| `reject` | δ refuses transmission for boundary-policy reasons; the cell terminates at scope `n` with no projection | `blocked` |
| `repair_dispatch` | The cell stays open at scope `n`; a child cell at scope `n` runs under a repair contract; on child accept γₙ re-emits a fresh `receiptₙ` and steps 4–5 re-fire (CCNF §Recursion Modes) | `blocked` (within-scope) |

The `(PASS, override)` and `(non-PASS, accept/release)` pairs are **invalid** per CCNF §Cell Outcomes — these are non-terminal states; δ re-decides until the outcome is one of `{accepted, degraded, blocked}`.

---

## 2. Inward membrane — γ contract → α-ready dispatch (implementation-contract enrichment)

The inward face of δ runs at dispatch time, before α is routed. γ writes the protocol-level contract (gap, ACs, oracle, evidence). γ also writes the 7-axis `## Implementation contract` section into the α prompt. **δ reviews that section before routing**, fills any unpopulated row per repo conventions (logging the enrichment in `.cdd/unreleased/{N}/gamma-clarification.md`), or blocks dispatch and escalates to operator-as-human when a row is genuinely undecidable. **Implementation-contract decisions belong to δ; α MUST NOT improvise.**

**Canonical doctrine lives at [`cnos.handoff/skills/handoff/dispatch/SKILL.md`](../../../../cnos.handoff/skills/handoff/dispatch/SKILL.md)** (Sub 3 of [cnos#404](https://github.com/usurobor/cnos/issues/404), shipped under [cnos#417](https://github.com/usurobor/cnos/issues/417)). That skill owns:

- the 7 architectural axes (Language; CLI integration target; Package scoping; Existing-binary disposition; Runtime dependencies; JSON/wire contract preservation; Backward-compat invariant);
- the dispatch-prompt template γ injects the contract block into;
- the δ review-before-routing duty and the fill-or-escalate paths;
- the four-surface mesh (γ template / δ enrichment / α constraint / β verification);
- the cnos#389/#391/#392/#393 empirical anchors.

δ's role-local realization here: δ is the actor that performs the inward review at routing time. The doctrine — what δ is responsible for, why δ holds this authority rather than γ alone, how the contract distributes across γ/α/β — lives at the canonical handoff path. The two-sided framing of δ (outward §1 + inward §2) remains the membrane's core; this section is the inward half, with doctrine sourced from cnos.handoff and execution executed here.

### 2.1. Phase 4a / Sub 3 landing note

The inward-membrane substance landed as Phase 4a of cnos#366 (cycle/397) in this file; **Sub 3 of cnos#404 (cycle/417) extracts the doctrine into [`cnos.handoff/skills/handoff/dispatch/SKILL.md`](../../../../cnos.handoff/skills/handoff/dispatch/SKILL.md)** alongside the dispatch-prompt template and the four-surface mesh declaration. This section is now a pointer; the role-local realization (δ-as-actor at routing time) stays here. **Phase 4b — harness substrate** landed in [`harness/SKILL.md`](../harness/SKILL.md) via cnos#398 (cycle/398). **Phase 4c — release-effector mechanics** landed in [`release-effector/SKILL.md`](../release-effector/SKILL.md) via cnos#399 (cycle/399). **Phase 5 — γ shrink** landed at cnos#400 (cycle/400). The complete two-sided framing (outward §1 + inward §2 of this file) is preserved; the doctrine for §2 is sourced from handoff.

---

## 3. Override — degraded boundary action

**Override is a degraded boundary action; it is never a form of validity, and it never rewrites V's verdict.** This is the load-bearing freeze from [`RECEIPT-VALIDATION.md`](../RECEIPT-VALIDATION.md) §Q4 (cnos#367) — restated here as δ-role doctrine because δ is the actor that records overrides.

### 3.1. Override does not rewrite the ValidationVerdict

An override is a structured `override:` block inside the receipt's `boundary` block, populated by δ when δ records a `BoundaryDecision` of `override` against a non-PASS `ValidationVerdict`. The `validation` block of the receipt continues to carry V's original verdict **unchanged** — override does not rewrite, mask, or replace the `ValidationVerdict`. The presence of a non-null `boundary.override` is the structural signal to every downstream consumer that the receipt closed in degraded state.

Three explicit failure modes if the design or implementation drifts:

1. **Override never rewrites the `ValidationVerdict`.** The `validation` block carries V's emitted verdict. `validation.result` stays at FAIL; `validation.failures` stays populated. δ does not edit, redact, or replace V's verdict. The verdict is what V saw; the override is what δ did with it. The two are separate fields with separate authors.
2. **Override never substitutes for PASS in downstream consumers.** A receipt where `validation.result == FAIL` and `boundary.override` is populated is **not equivalent** to a receipt where `validation.result == PASS` and `boundary.override == null`. Downstream V at scope n+1 — reading the n-receipt as evidence — must distinguish these two cases. Treating a degraded n-receipt as PASS-equivalent would let degradation propagate silently into the parent scope.
3. **Override never emits `OVERRIDE-PASS` as a `ValidationVerdict`.** V emits PASS, FAIL, and possibly WARN. There is no `OVERRIDE-PASS` value. Override lives in the `BoundaryDecision` shape (an enumerant of what δ decided), not in the `ValidationVerdict` shape (an enumerant of what V observed). Fusing them would let δ-side decisions reach back and rewrite V-side observations.

### 3.2. Downstream-consumer detection rule (binding biconditional, per cnos#367)

```text
A receipt is degraded ⇔ boundary.override != null.
A receipt is PASS-equivalent ⇔ validation.result == PASS AND boundary.override == null.

Every downstream consumer of a receipt — including:
  - the parent scope's V (V at scope n+1)
  - the parent scope's δ
  - operators auditing the cycle
  - cn-cdd-verify when reading a closed cycle
— MUST check both validation.result and boundary.override before
treating the receipt as a clean closure. Reading only one of the
two fields is incorrect.
```

The biconditional form is load-bearing. A consumer that checks only `validation.result == PASS` and assumes clean closure is incorrect (it misses degraded cells V did not approve). A consumer that checks only `boundary.override == null` and assumes clean closure is also incorrect (it misses cells where V emitted FAIL but no override exists — which is itself an incomplete-closure state per `COHERENCE-CELL.md` §Receipt Validity: "A missing override block plus a non-PASS V is not a receipt — it is an incomplete closure"). Both fields must be checked together.

### 3.3. When δ overrides

The δ-as-role may override a triad decision (or proceed past a non-PASS verdict) when:

- The triad's direction conflicts with project priorities the triad cannot see
- A role is stuck in a loop and γ's unblocking hasn't resolved it
- External constraints force a scope change (e.g. deadline, dependency shift)
- Safety or security requires immediate action
- A known pre-existing infrastructure failure (release CI red on infra unrelated to the cycle) — the explicit escape hatch named in §1.1

Override is **for information asymmetry or hard constraints, not preference**.

- ❌ "I think the implementation should use a different approach" → that's α's job
- ❌ "The review was too harsh" → that's β's judgment
- ✅ "The API we're building against is being deprecated next week" → information the triad needs

### 3.4. Override protocol

Per `cnos.cds/skills/cds/CDS.md` §"Field 6: Actor collapse rule" and `operator/SKILL.md` §3.4 (override protocol): the reassignment must name the target agent and the reason. No implicit drift.

State:

1. What you are overriding (role assignment, scope, priority, decision, or the non-PASS verdict)
2. Why (the information or constraint the triad didn't have)
3. What the new state is

When the override is against a non-PASS `ValidationVerdict`, populate the structured `override:` block in the receipt's `boundary` block with at minimum:

- `actor` — δ identity (e.g. `delta@cdd.cnos`)
- `justification` — narrative reason for the override
- `original_validation_verdict` — V's emitted verdict or a typed reference to it
- `failed_predicates_overridden` — list of the specific failed predicate refs the override covers (blanket "override all failures" is forbidden)
- `degraded_state` — `true`

Examples:

- ❌ Edit the issue quietly and let α discover the change
- ❌ Override = "PASS" silently propagated downstream
- ✅ "Override: descoping AC4–AC5 from this cycle. Reason: timeline constraint for release by Friday. New scope: AC1–AC3 only. γ to update the issue."
- ✅ "Override: release CI red on smoke test unrelated to cycle scope (known infra issue, cnos#NNN). Boundary block populated with `failed_predicates_overridden: [release_ci_smoke]`; `validation.result` remains as V emitted; downstream V at scope n+1 reads degraded matter."

### 3.5. ValidationVerdict vs BoundaryDecision — the structural distinction

The two surfaces are independent and must not be fused. Per `RECEIPT-VALIDATION.md` §"ValidationVerdict vs BoundaryDecision":

| Surface | Emitted by | Describes | Lives in receipt block |
|---|---|---|---|
| `ValidationVerdict` | V (the predicate) | Whether the receipt satisfies the contract+evidence predicates | `validation` |
| `BoundaryDecision` | δ (this role) | What δ decided to do with the receipt at the boundary | `boundary` |

The composition rule binds them but does not collapse them. Three explicit constraints follow:

1. **V does not record boundary decisions.** V emits a verdict — PASS or FAIL — and a structured failure list. V does not record "accepted" or "rejected" or "released." Those are δ's. The `validation` block of the receipt is V-owned; the `boundary` block is δ-owned.
2. **δ does not rewrite ValidationVerdict.** δ may decide to override a FAIL verdict, but δ does not rewrite the verdict to PASS. The verdict stays FAIL; the override block carries the degraded boundary action.
3. **PASS-equivalence is the conjunction.** A receipt is PASS-equivalent for downstream consumers iff `validation.verdict == PASS` AND `boundary.override == null` (§3.2). Either condition failing makes the receipt non-PASS-equivalent.

For the embedded kata exercising override (Kata B — "α stuck on AC3 due to undocumented API change"), see [`operator/SKILL.md`](../operator/SKILL.md) §9.

---

## 4. Composition with V (RECEIPT-VALIDATION.md)

Per `RECEIPT-VALIDATION.md` §Validation Interface, the composition rule:

```text
ValidationVerdict.verdict == PASS
    → δ may record BoundaryDecision in {accept, release}
    → δ may also record BoundaryDecision in {reject, repair_dispatch} if boundary-policy
      reasons orthogonal to V demand it (release freeze, downstream readiness check)

ValidationVerdict.verdict == FAIL
    → δ may record BoundaryDecision in {reject, repair_dispatch}
    → δ may record BoundaryDecision == override only as a degraded boundary action,
      with the override block populated per §3. boundary.override != null is the
      structural signal that downstream consumers MUST detect.
```

V makes acceptance **available** to δ on PASS; V does not make acceptance **automatic**. δ holds final gate authority over what crosses the boundary, and the `BoundaryDecision` is what δ records after consulting the verdict.

For the four closed-cell outcomes (`accepted`, `degraded`, `blocked`, `invalid`) and the within-scope vs cross-scope recursion modes, see [`COHERENCE-CELL-NORMAL-FORM.md`](../COHERENCE-CELL-NORMAL-FORM.md) §Cell Outcomes and §Recursion Modes.

---

## 5. What δ-as-role does NOT do

These are role boundaries at the role-skill level (CCNF kernel surface). For the dispatch-coordinator role boundaries (δ-as-actor's coordinator hat in γ=δ collapse cases), see [`operator/SKILL.md`](../operator/SKILL.md) §6.

- **δ does not produce matter.** That's α's signature (CCNF step 1). If δ wants to fix something, δ declares an override and takes the α role explicitly under the override discipline (§3).
- **δ does not discriminate matter.** That's β's signature (CCNF step 2). If δ disagrees with β's review, δ may override the boundary decision; δ does not rewrite β's review.
- **δ does not close cells.** That's γ's signature (CCNF step 3). δ does not author or edit the receipt; γ binds evidence and emits. δ reads the receipt and acts at the boundary.
- **δ does not re-read the evidence graph.** δ's signature in CCNF (step 5) explicitly excludes evidence as input. δ trusts V's verdict. If δ doubts the verdict, δ has two paths: invoke V again (reproducible from the same inputs), or `repair_dispatch` the cell to recompute its matter.
- **δ does not pronounce non-PASS receipts valid.** Override is degraded; override is not validity (§3.1).

---

## 6. Cross-references and relationships

- [`operator/SKILL.md`](../operator/SKILL.md) — δ-as-actor coordinator surface. Dispatch loop, γ=δ collapse rules, wait discipline, dispatch configurations doctrine, embedded kata, wave coordination. Cross-references `harness/SKILL.md` for dispatch / observability / polling / identity / timeout-recovery mechanics; cross-references `release-effector/SKILL.md` for release mechanics.
- [`harness/SKILL.md`](../harness/SKILL.md) — Phase 4b substrate: dispatch invocation (`claude -p` / `cn dispatch`), JSONL observability contract, worktree management, per-actor git identity (worktree-local under `extensions.worktreeConfig`), polling and wake-up forms (Monitor-wrapped transition loops, reachability re-probes), branch-retry mechanics, timeout recovery. Landed via cnos#398.
- [`release-effector/SKILL.md`](../release-effector/SKILL.md) — δ-side release mechanics: `scripts/release.sh` invocation, bare-X.Y.Z tag policy, post-push CI polling, CI-red recovery runbook, branch deletes. Landed via Phase 4c of cnos#366 (cycle/399). δ-as-role authority for the release boundary is named in §1.1 above; mechanics live in release-effector.
- [`RECEIPT-VALIDATION.md`](../RECEIPT-VALIDATION.md) — frozen typed-interface design for V, the verdict-vs-decision distinction, and the override field shape (§Q4). Binding once Phase 3 of cnos#366 lands V as a working predicate.
- [`COHERENCE-CELL-NORMAL-FORM.md`](../COHERENCE-CELL-NORMAL-FORM.md) — kernel doctrine. δ's signature at step 5 (no evidence); the four cell outcomes; the two recursion modes; the three scope-lift projections.
- [`COHERENCE-CELL.md`](../COHERENCE-CELL.md) — predecessor doctrine. δ Boundary Complex; trust grammar; the prediction of the δ split this cycle implements.
- [`cnos.handoff/skills/handoff/dispatch/SKILL.md`](../../../../cnos.handoff/skills/handoff/dispatch/SKILL.md) — canonical wire-format + 7-axis implementation-contract schema + δ-as-inward-membrane doctrine + four-surface mesh declaration. Sub 3 of [cnos#404](https://github.com/usurobor/cnos/issues/404), shipped under [cnos#417](https://github.com/usurobor/cnos/issues/417); the role-side surfaces below are its consumer-side realizations.
- [`gamma/SKILL.md`](../gamma/SKILL.md) §2.5 — γ-template side of the implementation-contract mesh (consumer realization).
- [`alpha/SKILL.md`](../alpha/SKILL.md) §3.6 — α-constraint side of the implementation-contract mesh (consumer realization).
- [`beta/SKILL.md`](../beta/SKILL.md) §Role Rules Rule 7 — β-verification side of the implementation-contract mesh (consumer realization).
- [`release/SKILL.md`](../release/SKILL.md) and [`post-release/SKILL.md`](../post-release/SKILL.md) — β-side release authoring (RELEASE.md, CHANGELOG, version decision) and γ-side post-release assessment; release-effector cross-references both as upstream context for the δ-side mechanics it executes.

---

## 7. Phase 4 of cnos#366 — what this cycle ships and what remains

This file (`delta/SKILL.md`) is Phase 4a of cnos#366. It carries:

- The two-sided membrane doctrine (outward §1, inward §2)
- Override semantics (§3) with the verdict-vs-decision freeze from cnos#367
- Composition with V (§4)
- δ-as-role boundary constraints (§5)

**Phase 4b — harness substrate (landed).** Dispatch invocation shells and observability contract, per-actor git identity with worktree-aware writes, parallel-α worktree pre-creation, polling and wake-up forms, branch-retry under push restrictions, and timeout recovery — previously authored as inline shell prose in the δ-coordinator surface — have landed in [`harness/SKILL.md`](../harness/SKILL.md) as Phase 4b of cnos#366 (cycle/398).

**Phase 4c — release-effector mechanics (landed).** The release-effector mechanics formerly living in `operator/SKILL.md` §3.4 (the single-command release script invocation, post-push CI polling, the recovery runbook, branch deletes, manual-tag prohibition) have landed in [`release-effector/SKILL.md`](../release-effector/SKILL.md) as Phase 4c of cnos#366 (cycle/399). The β-side authoring stays in `release/SKILL.md` (§2.4 CHANGELOG, §2.5 RELEASE.md, §2.5a cycle-dir move, pre-release validators); release-effector handles the δ-side mechanics only.

**Phase 5 — γ shrink (landed).** `gamma/SKILL.md` reduced to coordination + closure + triage doctrine; runtime supervision mechanics (polling shell, dispatch invocation shells, branch pre-flight bash) now cross-reference `harness/SKILL.md` and `release-effector/SKILL.md` rather than restating. Landed via cnos#400 (cycle/400).

All three substrate surfaces are now landed. δ-as-role's authority over the platform actions is named in §1.1 above; the harness substrate lives in `harness/SKILL.md`; release-effector mechanics live in `release-effector/SKILL.md`; operator-as-coordinator routing discipline (gate-action confirmation, request-vs-observation) lives in `operator/SKILL.md` §3.

---

## 8. Remote-runner delegation — δ-class effect surface

Canonical doctrine: [`docs/gamma/essays/BOX-AND-THE-RUNNER.md`](../../../../../../docs/gamma/essays/BOX-AND-THE-RUNNER.md) (cnos#425, this section's authoring cycle). Landed alongside this section under the doctrine-before-first-use rule: the essay, this skill section, the first workflow artifact, and the first instantiated receipt all land in the same commit-set; the workflow's push trigger only fires post-merge, by which point the doctrine governs.

**δ-class rule:** Any artifact an agent commits that, when present on its branch, causes another body to execute is a δ-class effect surface. δ holds authority over its authoring, not just over the receipt that closes the cell containing it.

The pattern covers, at minimum: `.github/workflows/*.yml` files; deploy hooks; extension manifests with execution permissions; scheduled-job definitions; webhook handlers; MCP server registrations; release-effector invocation scripts the agent authors rather than invokes. The class is **artifacts that cause another body to execute** — the local-shell case is one body; remote runners, deploy hooks, third-party services, and host-process extensions are other bodies. δ's authority extends to every body the agent's writes can reach, not just the body the harness can see.

The reason the rule sits in δ-as-role rather than in α-as-producer is that the effect crosses a boundary the producer cannot validate by itself. α writes the YAML; α cannot inspect the runner that will execute it. β reviews the YAML; β cannot replay the future run. Only δ-as-role, whose signature is the boundary decision, can name what authority the runner has, where it runs, and who may accept the result. The 6-field receipt is δ's surface for recording that naming.

### 8.1. Required output: the 6-field remote-runner receipt

When δ-as-role approves the authoring of any remote-runner-triggering artifact, δ requires a receipt with six fields (per `BOX-AND-THE-RUNNER.md §"The 6-field receipt convention"`):

| Field | Content |
|---|---|
| 1. Who asked | Operator session + directive, or upstream-cell receipt ref. Agent-initiated remote-runner moves without an upstream request are forbidden. |
| 2. What runs | The actual commands the remote body will execute, at command granularity (not "publishes release" — list `git tag -f X Y`, `git push --force origin X`, etc.). |
| 3. Where it runs | The execution environment (`ubuntu-latest` on GitHub Actions; a self-hosted runner; a third-party service). |
| 4. What authority | The token, scopes, secrets, and credentials the runner has access to (`GITHUB_TOKEN` with `contents: write`; deploy keys; cloud OIDC roles). |
| 5. Evidence | The artifact that proves the run happened (workflow run URL; release URL; deployment ID). May be a post-run-fillable placeholder authored before the run, with the *shape* of the evidence named in advance. |
| 6. Who may accept | The actor (operator or named cell) authorized to declare the remote run a success, with the acceptance criterion. |

Receipt path: `.cdd/unreleased/{N}/remote-runner-receipt-{handle}.md` for the issue cycle that authors the artifact. The receipt moves with the cycle into the release directory at cycle close.

### 8.2. Authoring-order rule

The receipt and the doctrine citation must land **with or before** the artifact that will trigger execution. There must be no window in which a remote-runner-triggering artifact exists on a branch that can reach an executing runner without the accompanying receipt also existing on that branch. For push-triggered workflows, the artifact and the receipt commit together; for branch-protected workflows whose dispatch is gated, the receipt may pre-land but the artifact must not pre-land alone.

Concretely, when γ dispatches a cycle that will author a remote-runner artifact, δ at the inward membrane (§2) pins this discipline into the implementation contract: the dispatch-prompt names the receipt as a required artifact, and α-side closure is incomplete without it. β verifies presence + 6-field completeness at R1 review.

### 8.3. One-shot workflows self-delete

When the remote-runner artifact is one-shot (a release-fix workflow; a single migration job; an infrastructure repair), the artifact MUST contain a final step that deletes itself from the repository after the work completes (`git rm` + `git commit` + `git push`). This is boundary discipline applied to the effect surface itself: the artifact does not persist beyond its declared single use, so the latent-execution authority closes after the run rather than remaining open. Persistent workflows (regularly-scheduled jobs, ongoing CI) do not self-delete; they are declared persistent at authoring time and the receipt's "Who may accept" field names the actor that owns the ongoing schedule.

### 8.4. Composition with the existing outward membrane (§1)

The remote-runner receipt is one piece of evidence inside the cell's full receipt at close-out. V (per §4) validates the cycle receipt; the remote-runner sub-receipt is a typed evidence ref V dereferences when the cycle's matter includes a remote-runner-triggering artifact. δ records the BoundaryDecision against V's verdict per §1.5 as normal; the override block (§3) is populated if δ accepts the cycle despite a non-PASS verdict on the remote-runner receipt (e.g. the post-run evidence is missing and the acceptor has not yet declared acceptance).

The remote-runner receipt does **not** replace V or the BoundaryDecision — it is the surface that makes the *authoring* of the effect artifact legible. The cycle-level V/δ wall still gates whether the cycle as a whole closes accepted, degraded, blocked, or invalid.

### 8.5. What this is not

- **Not a security policy.** The receipt is a legibility discipline; it does not prevent a malicious agent from forging fields. Security boundaries (token scoping, branch protection, required reviews) are orthogonal mechanisms enforced by the substrate, not by this skill.
- **Not retroactive.** A receipt authored after the remote run happened is a degraded closure; the gap is recorded as a finding and the override block (§3) is populated. Authoring the artifact first and the receipt second is a process gap ε should aggregate.
- **Not a substitute for the release-effector runbook.** The release-effector (`release-effector/SKILL.md`) governs locally-invoked release moves with release-boundary authority; the remote-runner rule governs runner-invoked moves on any boundary. The two surfaces overlap for any release-fix that uses a remote runner (cnos#425 is the first such case); the receipt cites both skills as governing.

### 8.6. First use

cnos#425 is the first cycle to author a remote-runner artifact under this doctrine. The artifact is `.github/workflows/repoint-3.82.0.yml` (one-shot; self-deleting); the receipt is `.cdd/unreleased/425/remote-runner-receipt-3.82.0.md` (6 fields filled, evidence as post-run-fillable placeholder); the effect is force-moving the `3.82.0` tag to `fd1d654e` so `release.yml` publishes the GH release with the correct root `RELEASE.md` body. The doctrine + skill section + workflow + receipt land in the same commit-set per §8.2; the post-merge push triggers the workflow under doctrine.
