@ikon85/agent-workflow-kit 0.10.0 → 0.12.0

package/.agents/skills/kit-release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: kit-release
-description: "Prepare a verified release PR for agent-workflow-kit with an explicit Semver confirmation, regenerated manifest, full tests, and pack audit, then delegate landing to wrapup."
+description: "Prepare a verified release PR for agent-workflow-kit, delegate landing to wrapup, then monitor the trusted post-merge publishing flow through npm/GitHub parity."
 ---
 
 # Kit Release
@@ -42,10 +42,31 @@ merge, registry publishing, tags, or release creation.
    `scripts/wrapup-land.py` exclusively own commit, push, PR creation, merge,
    and cleanup. Do not reproduce those operations here.
 
-5. After merge, the release is not complete until the repository's configured
-   publishing flow has produced the matching registry package and GitHub
-   tag/release and verified their parity. If that flow is not configured, stop
-   and report the missing post-merge capability; never publish ad hoc.
+5. After merge, monitor the `release.yml` workflow and inspect its externally
+   reconstructable state:
+
+   ```sh
+   gh run list --workflow release.yml --limit 1
+   npm run release:status
+   ```
+
+   `awaiting-npm` means the trusted workflow has not published yet;
+   `awaiting-github` means npm readback passed and a safe rerun will skip npm
+   publish and resume at GitHub; `released` means local, npm, and the GitHub
+   release asset have identical version, manifest hash, and tarball integrity.
+   The release is complete only at `released`.
+
+   The registry identity is **`@ikon85/agent-workflow-kit`**. The unscoped
+   `agent-workflow-kit` package is owned by another publisher and must never be
+   queried, published, or treated as this repository's release.
+
+   Before the first real release, the npm package must name this repository's
+   exact `.github/workflows/release.yml` as its GitHub Trusted Publisher. If it
+   does not exist yet, stop for a separately confirmed one-time bootstrap
+   publish; npm only permits trust configuration for an existing package. That
+   bootstrap creates the scoped package but does not replace the first real
+   OIDC/provenance release. Never request, store, or substitute an npm token,
+   and never publish or create a release ad hoc beyond that explicit bootstrap.
 
 ## Guard contract
 

package/.agents/skills/kit-update/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: kit-update
+description: "Preview and transactionally apply a parity-verified agent-workflow-kit release without overwriting local modifications or auto-resolving conflicts."
+---
+
+# Kit Update
+
+Update an installed consumer only from the public scoped package
+`@ikon85/agent-workflow-kit`. The unscoped `agent-workflow-kit` package belongs
+to another publisher and is never a valid update source. Existing installs from
+`npx github:iKon85/agent-workflow-kit` remain valid, but updates must use the
+scoped npm release so the shared release-parity checker can prove that npm and
+the matching GitHub release contain the same artifact.
+
+## Workflow
+
+1. Preview the delta without writing:
+
+   ```sh
+   npx @ikon85/agent-workflow-kit@latest diff
+   ```
+
+   Review the named added, updated, locally modified, removed, and conflicting
+   paths. Do not reinterpret a local modification as permission to overwrite it.
+
+2. Apply the update:
+
+   ```sh
+   npx @ikon85/agent-workflow-kit@latest update
+   ```
+
+   The command checks npm/GitHub release parity before staging. It prepares a
+   complete candidate outside the consumer, runs the consumer's existing
+   `npm test` command there, and activates only a verified candidate. A staging
+   or verification failure leaves the installed tree byte-identical.
+
+3. Read the terminal report. `aktuell` proves a second run found no upstream
+   delta. A conflict report names and counts every category and leaves every
+   consumer file untouched. Follow its recommendation and resolve each named
+   conflict manually; never auto-merge, delete a local edit, or silently choose
+   the incoming copy.
+
+4. If a candidate is interrupted, discard its reported stage directory or
+   resume the transaction through the update API's `resumeFrom` option. Do not
+   copy staged files into the consumer by hand.
+
+## State contract
+
+The update API reports `checking -> preview/awaiting_decision -> staging ->
+verifying -> applied | conflicted | failed | aborted`. `conflicted`, `failed`,
+and `aborted` never authorize partial activation. The existing manifest,
+three-way diff, and atomic-write seams remain the source of truth.

package/.agents/skills/scale-check/SKILL.md

@@ -97,8 +97,10 @@ Tripped altitude criteria: <e.g. C1 staged delivery, C2 multiple subsystems, C4
    structure-bearing decisions (escalate a single bounded choice to `decision-gate`).
 2. `to-prd` — it auto-detects the program mode from the Wellenplan chapter and writes
    a Program-PRD (native anchor over the waves).
-3. `to-waves` — unfold the wave plan into named wave stubs + slice leaves after the
-   chat preview gate (nothing is written to the board until you approve it).
+3. `to-waves` — after one complete chat preview, materialize the whole Program with
+   **all waves execute-ready by default**: complete slice contracts, buckets,
+   dependencies and handoffs. Decision Gates, Verify Spikes and Design-Grill waves
+   are explicit planned exceptions; generic late-binding cleanup is not.
 ```
 
 ### Feature (0–1 criteria, or any doubt)
@@ -132,7 +134,7 @@ Bug: <what's broken — expected vs. actual>.
 ```
 scale-check: verdict=<Program | Feature | Direct-Slice | Bug>
   criteria tripped=<C1,C2,… | none | n/a (bug/direct)>
-  route=<program grill → to-prd → to-waves | grill-with-docs → to-prd → to-issues | tdd | diagnose>
+  route=<program grill → to-prd → to-waves (all waves execute-ready by default) | grill-with-docs → to-prd → to-issues | tdd | diagnose>
   start-prompt: <the paste-ready block above, filled in>
 ```
 

package/.agents/skills/setup-workflow/workflow-overview.md

@@ -19,6 +19,7 @@ Use this section as the entry-point map for agent-assisted work. The individual
 - **Implementation slice:** use `tdd` for one behavior at a time: RED, GREEN, then refactor.
 - **Finished slice:** use `wrapup` to prepare the branch, PR, and cleanup steps your repo expects.
 - **Kit release:** use `kit-release` to derive the shipped delta, confirm Semver, regenerate the manifest, run all gates, and then hand landing to `wrapup`.
+- **Kit update:** use `kit-update` to preview and transactionally apply a parity-verified scoped release without overwriting local modifications.
 - **A huge, foggy effort, too big for one session:** use `wayfinder` — it charts it as a shared map of investigation tickets, resolving one per session.
 
 ## Routing Rule

package/.agents/skills/to-issues/SKILL.md

@@ -98,6 +98,14 @@ Ask the user:
 
 Iterate until the user approves the breakdown.
 
+**Program batch handoff.** When `to-waves` invokes this skill for a Stufe-1p stub,
+the complete Program preview has already shown and approved every wave's slice
+contract. Reuse that approval when this pass preserves the approved cut: do not
+pause again merely because the internal pipeline crossed a skill boundary. Run
+the normal contract in full — maturity is not a reduced mode — and reconcile the
+stub's existing leaves instead of duplicating them. A new structural choice or a
+newly discovered gate invalidates the inherited approval and returns to §4.
+
 ### 5. Publish — promote-or-atomic (contract)
 
 **Cluster/Wave discriminator (identical wording — `to-prd` §2 / `to-issues` §5):** `type:cluster` (label) always stops. A Wave number also stops, **unless** the target carries the `wave-stub` label — a Wave-stamped `wave-stub` issue is a **Stufe-1p Program-stub** (`to-waves`-published, native parent = a Program-PRD) and remains a **valid target**. A Wave-stamped issue **without** `wave-stub` (an already-assigned leaf, or a drifted item) is still a hard stop.
@@ -193,6 +201,21 @@ python3 scripts/board-sync.py dep-add --issue <blocked#> --blocked-by <blocker#>
 
 The Draft-PRD stays the executable leaf. Edit its body: **remove** `<!-- prd: awaiting-decomposition -->`, keep `type:*`+`priority:*` (**no** `type:cluster`/Wave, **no** `Welle N` title prefix), stamp the leaf `plan_revision`, add the `## Handoff Start Command`. The single PR `closes #<prd#>`.
 
+**Program-batch atomic exception.** A Stufe-1p stub already represents one named
+wave under a Program-PRD. When its approved cut contains exactly one slice, keep
+the stub itself as the atomic executable wave leaf: preserve its existing Wave and Phase,
+`Welle N — …` title, native Program parent, and source marker; write the complete
+atomic contract and bucket, then remove only `wave-stub`. Do not erase Program
+navigation by applying the ordinary Wave-less atomic normalization.
+
+On a delta re-run, a legacy or interrupted preliminary child may already be linked
+under that atomic stub. Lift any still-relevant content into the stub, unlink the
+child with `board-sync.py unlink`, and close it with the mapping comment
+`superseded by atomic wave leaf #<stub>`. Scan both `children-of` and the Program's
+`program-leaf-source` markers: the **matching source marker remains discoverable after unlink**.
+Resume idempotently — unlink only when still linked; close only when still open;
+an already completed step is a no-op. The final atomic wave has no child set.
+
 Then set the bucket via the helper — the leaf already exists, so the workflow-label write goes through `board-sync.py add --bucket` (§5a forbids a bare `gh issue edit --add-label ready-for-agent`):
 
 ```bash
@@ -215,6 +238,12 @@ Every child **and** the atomic leaf sits in **exactly one** bucket:
 
 Status alone cannot discriminate (both are `Spec`) — the **label** does. The helper's `--hitl` flag rejects a `ready-for-agent` label mechanically. Authority = `scripts/execute-ready-check.py` (`parse_bucket`) — the checker wins on a mismatch.
 
+**A mandatory human or external setup action is never AFK.** Cut it as a HITL gate
+slice (or an explicitly named planning wave), place it before the dependent build
+slice, and set the native blocked-by edge. Never hide a maintainer configuration,
+credentialless console action, approval, or design response inside a leaf carrying
+`ready-for-agent`, even when the remaining code work could run unattended.
+
 **Gate slices (🔬/📐) are AFK.** A `🔬` Verify-Spike or `📐` Trade-off/Research gate slice is **read-only** (a fact question, or a bounded trade-off + read-only research) — an agent can run it solo, so it carries `ready-for-agent` like any other AFK slice; the **native blocked-by edge** on its dependent build slice (set at publish, §5a step 5) is what protects the gate-before-build ordering (§3b/§4), not the HITL bucket. Only a `🧭` Design-Grill gate slice is HITL (it needs the human in the grill). A gate slice's **placement** — which altitude/layer it lands on — follows `decision-gate`'s placement rule (owned there, referenced here).
 
 #### 5d. Issue body template (each child / atomic leaf)

package/.agents/skills/to-waves/SKILL.md

@@ -1,15 +1,16 @@
 ---
 name: to-waves
 disable-model-invocation: true
-description: "Unfold a Program-PRD's wave plan onto the board — parse + graph-validate it, show the complete Wellenplan as a chat preview before ANY board write, then after approval publish named wave stubs (native parent = the PRD) + slice leaves (native parent = their stub) with Wave and Phase stamped in one batch, and report a counted completion. Idempotent + crash-recoverable on re-run; adopts referenced existing issues instead of duplicating them. Use on a Program-PRD, the native anchor over several waves. NOT for a single-wave feature (to-issues) and NOT for clustering a backlog (board-to-waves)."
+description: "Turn a Program-PRD's wave plan into fully planned, execute-ready wave anchors and slice leaves after one complete chat preview. Validates the graph, publishes every wave, runs the to-prd/spec-self-critique/to-issues maturity contract for each wave, models unresolved work as explicit gates, and audits counted readiness. Idempotent and crash-recoverable. Use on a Program-PRD over several waves. NOT for a single-wave feature (to-issues) or backlog clustering (board-to-waves)."
 ---
 
 # to-waves — Unfold a Program-PRD's wave plan onto the board
 
 Takes a **Program-PRD** — the native Sub-Issue anchor over a multi-wave program
 (Programm → Phase → Welle → Slice) — and turns its `## Wellenplan` chapter into
-**named wave stubs + slice leaves** on the board. Pipeline position:
-`scale-check → grill → to-prd (program mode) → to-waves → …per wave: to-issues`.
+**fully planned wave anchors + slice leaves** on the board. Pipeline position:
+`scale-check → grill → to-prd (program mode) → to-waves`, with the per-wave
+`to-prd → spec-self-critique → to-issues` maturity pass owned inside this run.
 The **grill and to-prd sit upstream**; to-waves runs once the Program-PRD exists.
 It **never invents structure** — it only unfolds what the plan already decided.
 
@@ -70,28 +71,39 @@ Show:
 - The **publish plan**: how many stubs + leaves will be created, which referenced
   existing issues will be **adopted** (§4) rather than created, and which
   Wave/Phase stamps will be applied.
+- The complete per-wave issue contracts that will be materialized: outcome,
+  Blast-Radius, acceptance criteria, AFK/HITL bucket, native dependencies, and
+  self-contained handoff. A placeholder is not preview-complete.
 
-Then ask for approval. Only on an explicit "yes" proceed to §4/§5. On "no", stop —
-no writes happened.
+This complete Program preview is the **single user approval** for the default
+planning run. Only on an explicit "yes" proceed to §4/§5/§7; when a later
+per-wave maturity pass reproduces the approved cut, **do not ask for another per-wave approval**.
+Ask again only when new evidence changes structure or exposes
+a genuinely undecided gate. On "no", stop — no writes happened.
 
 ## 4. Publish — the fixed order
 
 After approval, publish in **exactly this order** (issue CREATES stay sequential so
 the numbering is deterministic; only the field stamps are batched):
 
-1. **Wave stubs — Stufe 1p.** One per Wellenplan row, native parent = the PRD.
+1. **Wave stubs — transient Stufe 1p.** One per Wellenplan row, native parent = the PRD.
    Title `Welle <N> — <Name>`; created with the `wave-stub` label and Status Spec.
    Body = the Stufe-1p stub template (named header, the program idempotency marker,
-   the revision marker — see §6). Not yet Wave/Phase-stamped (that is step 4).
+   the revision marker — see §6). This is a crash-recovery checkpoint inside the
+   run, never its successful terminal state. Not yet Wave/Phase-stamped (step 4).
    ```bash
    python3 scripts/board-sync.py create --title "Welle <N> — <Name>" \
      --body-file <stub.md> --wave-stub --status-role spec
    ```
-2. **Slice leaves.** One per slice under each wave, native parent = its stub. Created
-   with the spec-role status and **no** `ready-for-agent` (a leaf is not buildable until its
+2. **Preliminary slice leaves for multi-slice waves.** Create one per slice under
+   each wave whose approved cut contains ≥2 slices, native parent = its stub. For
+   an exactly-one-slice wave, **do not create a preliminary child**: keep that
+   slice's metadata on the stub so step 6 can turn the stub itself into the atomic
+   executable wave leaf without a duplicate identity. Preliminary children use
+   the spec-role status and **no** `ready-for-agent` (a leaf is not buildable until its
    wave is promoted — the ordering guard stays unambiguous). Body = the slice's
    `## Slices` section carried forward per `SLICE-METADATA-FORMAT.md` (metadata block +
-   the outcome/placeholder skeleton, sharpened only at promotion). **Title carries the
+   the outcome/placeholder skeleton, finalized in step 6). **Title carries the
    navigation prefix** `Welle <N> / Slice <local-id> — <title>` — the local-id
    (`1a`, `1b`, …) encodes the build order, so the sub-issue LIST is navigable by title
    alone (same convention as `to-issues`' promoted children, `Welle N / Slice X — <outcome>`).
@@ -131,10 +143,22 @@ the numbering is deterministic; only the field stamps are batched):
    ```bash
    python3 scripts/board-sync.py program-sync <prd#>
    ```
-6. **Counted completion report + program view link.** Report `X von Y` for each part
-   (stubs created, leaves created, issues adopted, field stamps set) and link the
-   program board view. Completeness is **counted, never claimed** — the numbers come
-   from the create outputs + the `stamp-batch` response, not from memory.
+6. **Mature every wave.** For each stub in dependency order, run the approved
+   Program batch handoff: `to-prd` Mode B writes the per-wave Draft-PRD,
+   `spec-self-critique` hardens it, and `to-issues` promotes/atomizes it while
+   reusing the preliminary leaves. The pass writes complete issue bodies, final
+   AFK/HITL buckets, handoffs, native dependencies, `plan_revision`, and removes
+   `wave-stub`. It inherits the §3 approval when the cut is unchanged.
+7. **Audit every wave.** Run `execute-ready-check.py --mode audit` on every promoted
+   anchor or atomic wave leaf. Any incomplete placeholder, incoherent revision,
+   missing bucket, or child-set mismatch blocks successful completion. **Program completion gate:**
+   Although `to-issues` uses audit mode as an informational handoff check, **do not count that wave as matured** or report
+   Program success until its audit findings are clean.
+8. **Counted completion report + program view link.** Report `X von Y` for each part
+   (stubs created, leaves adopted/created, field stamps set, waves matured, waves
+   execute-ready) and link the program board view. Completeness is **counted, never
+   claimed** — the numbers come from the commands, including the exact line
+   `X von Y Wellen ausführungsreif`.
 
 ## 5. Adopt path — referenced existing issues
 
@@ -176,6 +200,10 @@ A re-run of to-waves on the same program is **delta-apply** and doubles as
   report as **orphaned** (do not auto-close — closing is the abort convention, §8).
   Cross-check the native children (`children-of <prd#>` and each stub) against the
   plan so both origins are covered.
+- **Atomic supersession exception.** A marked preliminary leaf whose local-id maps
+  to the one slice now carried by its atomic stub is not a generic orphan. Route it
+  to `to-issues` §5b cleanup whether it is still linked or was already unlinked by
+  an interrupted run. Search-by-marker is the durable recovery identity.
 - **Crash recovery.** Because create is search-before-create, `link` is idempotent,
   and `stamp-batch` field-sets are idempotent, re-running the whole publish after an
   abort resumes cleanly — already-created issues match, missing ones are created,
@@ -191,7 +219,7 @@ A re-run of to-waves on the same program is **delta-apply** and doubles as
   (the same sanctioned body-write `to-prd` Mode B uses). The mechanism that renews
   coherence is the same one the revision broke — it self-repairs.
 
-## 7. Program-grill agenda + the per-wave-start content pass
+## 7. Program completion contract
 
 to-waves also carries the **program-grill agenda** as a reference chapter — the
 checklist a program grill (upstream) should cover so the wave plan does not rest on
@@ -211,12 +239,22 @@ open switches:
   single bounded choice to `decision-gate` — not deferred into the plan as an open
   task.
 
-**The per-wave-start content pass** is where slice content is sharpened — deliberately
-**just-in-time (Late Binding)**, never ex ante on spec. When a wave is promoted:
-`to-prd` (Mode B, into the wave stub) + `spec-self-critique` are **mandatory**, and
-the depth ladder is **raised for a high-stakes wave** (a design-grill or a
-`decision-gate` before slicing). This is what folds in any drift propagated since the
-plan was first written.
+**Default postcondition:** every published wave is fully planned and passes the
+shared execute-ready audit before this run reports success. Stufe 1p is an
+internal recovery state, not the result presented to the user. **Late Binding is not the default**
+for unfinished issue prose or missing buckets.
+
+Uncertainty is planned, not hidden. A bounded trade-off becomes an explicit
+**Decision Gate**, a factual unknown becomes a **Verify Spike**, and an unresolved
+structure seam becomes a HITL **Design-Grill** slice (or an explicitly named
+planning wave). Place that gate before its dependent build slice and write the
+native blocking edge. The gate issue itself still receives a complete contract and
+handoff; the dependent work is blocked, not vaguely under-planned.
+
+A mandatory human or external setup action follows the same rule: model it as a
+HITL predecessor, never bury it inside a `ready-for-agent` build leaf. If later
+drift invalidates an already planned wave, use the revision/escalation path in §8;
+do not pre-emptively leave every future wave incomplete.
 
 ## 8. Close protection, abort convention, escalation path
 
@@ -255,6 +293,7 @@ python3 scripts/board-sync.py program-sync <prd#>
 to-waves: prd=#<n> preview=<approved|rejected>
   created=<stubs X von Y, leaves X von Y>  adopted=<#a #b … | none>
   stamped=<N von M Wave/Phase>  phase=<stamped | skipped (profile lacks fields.phase)>
+  matured=<X von Y>  execute-ready=<X von Y Wellen ausführungsreif>
   revision=r<N>  renewed-markers=<count | none>  orphaned=<#… | none>
   graph=<ok | blocking: …>  program-view=<url>
 ```

package/.claude/skills/kit-release/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: kit-release
-description: "Prepare a verified release PR for agent-workflow-kit with an explicit Semver confirmation, regenerated manifest, full tests, and pack audit, then delegate landing to wrapup."
+description: "Prepare a verified release PR for agent-workflow-kit, delegate landing to wrapup, then monitor the trusted post-merge publishing flow through npm/GitHub parity."
 ---
 
 # Kit Release
@@ -42,10 +42,31 @@ merge, registry publishing, tags, or release creation.
    `scripts/wrapup-land.py` exclusively own commit, push, PR creation, merge,
    and cleanup. Do not reproduce those operations here.
 
-5. After merge, the release is not complete until the repository's configured
-   publishing flow has produced the matching registry package and GitHub
-   tag/release and verified their parity. If that flow is not configured, stop
-   and report the missing post-merge capability; never publish ad hoc.
+5. After merge, monitor the `release.yml` workflow and inspect its externally
+   reconstructable state:
+
+   ```sh
+   gh run list --workflow release.yml --limit 1
+   npm run release:status
+   ```
+
+   `awaiting-npm` means the trusted workflow has not published yet;
+   `awaiting-github` means npm readback passed and a safe rerun will skip npm
+   publish and resume at GitHub; `released` means local, npm, and the GitHub
+   release asset have identical version, manifest hash, and tarball integrity.
+   The release is complete only at `released`.
+
+   The registry identity is **`@ikon85/agent-workflow-kit`**. The unscoped
+   `agent-workflow-kit` package is owned by another publisher and must never be
+   queried, published, or treated as this repository's release.
+
+   Before the first real release, the npm package must name this repository's
+   exact `.github/workflows/release.yml` as its GitHub Trusted Publisher. If it
+   does not exist yet, stop for a separately confirmed one-time bootstrap
+   publish; npm only permits trust configuration for an existing package. That
+   bootstrap creates the scoped package but does not replace the first real
+   OIDC/provenance release. Never request, store, or substitute an npm token,
+   and never publish or create a release ad hoc beyond that explicit bootstrap.
 
 ## Guard contract
 

package/.claude/skills/kit-update/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: kit-update
+description: "Preview and transactionally apply a parity-verified agent-workflow-kit release without overwriting local modifications or auto-resolving conflicts."
+---
+
+# Kit Update
+
+Update an installed consumer only from the public scoped package
+`@ikon85/agent-workflow-kit`. The unscoped `agent-workflow-kit` package belongs
+to another publisher and is never a valid update source. Existing installs from
+`npx github:iKon85/agent-workflow-kit` remain valid, but updates must use the
+scoped npm release so the shared release-parity checker can prove that npm and
+the matching GitHub release contain the same artifact.
+
+## Workflow
+
+1. Preview the delta without writing:
+
+   ```sh
+   npx @ikon85/agent-workflow-kit@latest diff
+   ```
+
+   Review the named added, updated, locally modified, removed, and conflicting
+   paths. Do not reinterpret a local modification as permission to overwrite it.
+
+2. Apply the update:
+
+   ```sh
+   npx @ikon85/agent-workflow-kit@latest update
+   ```
+
+   The command checks npm/GitHub release parity before staging. It prepares a
+   complete candidate outside the consumer, runs the consumer's existing
+   `npm test` command there, and activates only a verified candidate. A staging
+   or verification failure leaves the installed tree byte-identical.
+
+3. Read the terminal report. `aktuell` proves a second run found no upstream
+   delta. A conflict report names and counts every category and leaves every
+   consumer file untouched. Follow its recommendation and resolve each named
+   conflict manually; never auto-merge, delete a local edit, or silently choose
+   the incoming copy.
+
+4. If a candidate is interrupted, discard its reported stage directory or
+   resume the transaction through the update API's `resumeFrom` option. Do not
+   copy staged files into the consumer by hand.
+
+## State contract
+
+The update API reports `checking -> preview/awaiting_decision -> staging ->
+verifying -> applied | conflicted | failed | aborted`. `conflicted`, `failed`,
+and `aborted` never authorize partial activation. The existing manifest,
+three-way diff, and atomic-write seams remain the source of truth.

package/.claude/skills/scale-check/SKILL.md

@@ -97,8 +97,10 @@ Tripped altitude criteria: <e.g. C1 staged delivery, C2 multiple subsystems, C4
    structure-bearing decisions (escalate a single bounded choice to `decision-gate`).
 2. `to-prd` — it auto-detects the program mode from the Wellenplan chapter and writes
    a Program-PRD (native anchor over the waves).
-3. `to-waves` — unfold the wave plan into named wave stubs + slice leaves after the
-   chat preview gate (nothing is written to the board until you approve it).
+3. `to-waves` — after one complete chat preview, materialize the whole Program with
+   **all waves execute-ready by default**: complete slice contracts, buckets,
+   dependencies and handoffs. Decision Gates, Verify Spikes and Design-Grill waves
+   are explicit planned exceptions; generic late-binding cleanup is not.
 ```
 
 ### Feature (0–1 criteria, or any doubt)
@@ -132,7 +134,7 @@ Bug: <what's broken — expected vs. actual>.
 ```
 scale-check: verdict=<Program | Feature | Direct-Slice | Bug>
   criteria tripped=<C1,C2,… | none | n/a (bug/direct)>
-  route=<program grill → to-prd → to-waves | grill-with-docs → to-prd → to-issues | tdd | diagnose>
+  route=<program grill → to-prd → to-waves (all waves execute-ready by default) | grill-with-docs → to-prd → to-issues | tdd | diagnose>
   start-prompt: <the paste-ready block above, filled in>
 ```
 

package/.claude/skills/setup-workflow/workflow-overview.md

@@ -19,6 +19,7 @@ Use this section as the entry-point map for agent-assisted work. The individual
 - **Implementation slice:** use `tdd` for one behavior at a time: RED, GREEN, then refactor.
 - **Finished slice:** use `wrapup` to prepare the branch, PR, and cleanup steps your repo expects.
 - **Kit release:** use `kit-release` to derive the shipped delta, confirm Semver, regenerate the manifest, run all gates, and then hand landing to `wrapup`.
+- **Kit update:** use `kit-update` to preview and transactionally apply a parity-verified scoped release without overwriting local modifications.
 - **A huge, foggy effort, too big for one session:** use `wayfinder` — it charts it as a shared map of investigation tickets, resolving one per session.
 
 ## Routing Rule

package/.claude/skills/skill-manifest.json

@@ -384,6 +384,16 @@
         "codex"
       ],
       "provenance": "own"
+    },
+    "kit-update": {
+      "class": "generic",
+      "publish": true,
+      "entryPoint": true,
+      "surfaces": [
+        "claude",
+        "codex"
+      ],
+      "provenance": "own"
     }
   }
 }

package/.claude/skills/to-issues/SKILL.md

@@ -98,6 +98,14 @@ Ask the user:
 
 Iterate until the user approves the breakdown.
 
+**Program batch handoff.** When `to-waves` invokes this skill for a Stufe-1p stub,
+the complete Program preview has already shown and approved every wave's slice
+contract. Reuse that approval when this pass preserves the approved cut: do not
+pause again merely because the internal pipeline crossed a skill boundary. Run
+the normal contract in full — maturity is not a reduced mode — and reconcile the
+stub's existing leaves instead of duplicating them. A new structural choice or a
+newly discovered gate invalidates the inherited approval and returns to §4.
+
 ### 5. Publish — promote-or-atomic (contract)
 
 **Cluster/Wave discriminator (identical wording — `to-prd` §2 / `to-issues` §5):** `type:cluster` (label) always stops. A Wave number also stops, **unless** the target carries the `wave-stub` label — a Wave-stamped `wave-stub` issue is a **Stufe-1p Program-stub** (`to-waves`-published, native parent = a Program-PRD) and remains a **valid target**. A Wave-stamped issue **without** `wave-stub` (an already-assigned leaf, or a drifted item) is still a hard stop.
@@ -193,6 +201,21 @@ python3 scripts/board-sync.py dep-add --issue <blocked#> --blocked-by <blocker#>
 
 The Draft-PRD stays the executable leaf. Edit its body: **remove** `<!-- prd: awaiting-decomposition -->`, keep `type:*`+`priority:*` (**no** `type:cluster`/Wave, **no** `Welle N` title prefix), stamp the leaf `plan_revision`, add the `## Handoff Start Command`. The single PR `closes #<prd#>`.
 
+**Program-batch atomic exception.** A Stufe-1p stub already represents one named
+wave under a Program-PRD. When its approved cut contains exactly one slice, keep
+the stub itself as the atomic executable wave leaf: preserve its existing Wave and Phase,
+`Welle N — …` title, native Program parent, and source marker; write the complete
+atomic contract and bucket, then remove only `wave-stub`. Do not erase Program
+navigation by applying the ordinary Wave-less atomic normalization.
+
+On a delta re-run, a legacy or interrupted preliminary child may already be linked
+under that atomic stub. Lift any still-relevant content into the stub, unlink the
+child with `board-sync.py unlink`, and close it with the mapping comment
+`superseded by atomic wave leaf #<stub>`. Scan both `children-of` and the Program's
+`program-leaf-source` markers: the **matching source marker remains discoverable after unlink**.
+Resume idempotently — unlink only when still linked; close only when still open;
+an already completed step is a no-op. The final atomic wave has no child set.
+
 Then set the bucket via the helper — the leaf already exists, so the workflow-label write goes through `board-sync.py add --bucket` (§5a forbids a bare `gh issue edit --add-label ready-for-agent`):
 
 ```bash
@@ -215,6 +238,12 @@ Every child **and** the atomic leaf sits in **exactly one** bucket:
 
 Status alone cannot discriminate (both are `Spec`) — the **label** does. The helper's `--hitl` flag rejects a `ready-for-agent` label mechanically. Authority = `scripts/execute-ready-check.py` (`parse_bucket`) — the checker wins on a mismatch.
 
+**A mandatory human or external setup action is never AFK.** Cut it as a HITL gate
+slice (or an explicitly named planning wave), place it before the dependent build
+slice, and set the native blocked-by edge. Never hide a maintainer configuration,
+credentialless console action, approval, or design response inside a leaf carrying
+`ready-for-agent`, even when the remaining code work could run unattended.
+
 **Gate slices (🔬/📐) are AFK.** A `🔬` Verify-Spike or `📐` Trade-off/Research gate slice is **read-only** (a fact question, or a bounded trade-off + read-only research) — an agent can run it solo, so it carries `ready-for-agent` like any other AFK slice; the **native blocked-by edge** on its dependent build slice (set at publish, §5a step 5) is what protects the gate-before-build ordering (§3b/§4), not the HITL bucket. Only a `🧭` Design-Grill gate slice is HITL (it needs the human in the grill). A gate slice's **placement** — which altitude/layer it lands on — follows `decision-gate`'s placement rule (owned there, referenced here).
 
 #### 5d. Issue body template (each child / atomic leaf)