@aperant/framework 0.17.0 → 0.20.0

package/dist/plugin/skills/apt-quick/SKILL.md

@@ -29,7 +29,7 @@ Execute a small task quickly without full pipeline overhead. For small fixes, do
 - **Working directory:** The project root (where you were invoked) UNLESS an active task has a task-level worktree (see below).
 - **Constitution:** Read `AGENTS.md` in the project root if it exists
 - **State directory:** `.aperant/quick/{task-id}/`
-- **Task-level worktree isolation:** Use the `worktree_path` the router passed in skill context (router path) OR that §1a parsed from `task create`'s envelope (direct path) — this is the worktree `task create` literally just provisioned for this task. When present, run all editing Bash commands with `cd {worktree_path} &&` prefix so the fix lands on the task branch. `apt-tools` calls still take the project root as `<project-dir>` so they coordinate through the main repo's shared `.aperant/`. The quick task's `.aperant/quick/{task-id}/` directory lives in the main repo, not the worktree. (Last-resort fallback only: if neither source supplied a `worktree_path` but `.aperant/state.json` has an active task with one, you may use that.)
+- **Task-level worktree isolation:** Use the `worktree_path` the router passed in skill context (router path) OR that §1a parsed from `task ensure`'s envelope (direct path) — this is the worktree `task ensure` literally just provisioned for this task. When present, run all editing Bash commands with `cd {worktree_path} &&` prefix so the fix lands on the task branch. `apt-tools` calls still take the project root as `<project-dir>` so they coordinate through the main repo's shared `.aperant/`. The quick task's `.aperant/quick/{task-id}/` directory lives in the main repo, not the worktree. (Last-resort fallback only: if neither source supplied a `worktree_path` but `.aperant/state.json` has an active task with one, you may use that.)
 </your_environment>
 
 <state_files>
@@ -54,35 +54,27 @@ Extract the task description from `$ARGUMENTS`.
 
 ### 1a. Resolve canonical task id (idempotent)
 
-QUICK now produces a canonical state.active_tasks record so `/apt:ship` can find the task via the lite ship profile. The body owns idempotency because `apt-tools task create` does NOT guard against existing ids (see spec §3 R8).
+QUICK now produces a canonical state.active_tasks record so `/apt:ship` can find the task via the lite ship profile. Idempotency is owned by the deterministic allocator `apt-tools task ensure --intent create-new` (NOT raw `task create`) — re-running returns the SAME task + worktree (`reused: true`), so the old `task get` guard dance is gone.
 
 Two invocation paths converge here:
 
-- **Router path** (`/apt` → `/apt:quick`): the router has already called `task create` and injected `task_id` into your skill context.
-- **Direct path** (`/apt:quick foo`): no `task_id` in context — you create one now.
-
-Sequence:
+- **Router path** (`/apt` → `/apt:quick`): the router has already run `task ensure --intent create-new` and injected `task_id` (+ `worktree_path`) into your skill context. Re-affirm idempotently with the same id:
+  ```bash
+  apt-tools task ensure . --description "$ARGUMENTS" --intent create-new --track QUICK --id {task_id}
+  ```
+  The `--id {task_id}` makes ensure resolve to the EXACT record the router just provisioned (`reused: true`) — no second task, no second worktree.
 
-1. **If `task_id` is present in skill context** (router path):
-   ```bash
-   apt-tools task get . --id {task_id}
-   ```
-   - If exit 0 AND the returned record has `track === "QUICK"` → reuse, skip the create call.
-   - Else (record missing OR wrong track) → call:
-     ```bash
-     apt-tools task create . --description "$ARGUMENTS" --track QUICK --id {task_id}
-     ```
-     Parse `task_id` from the returned envelope (it will match the id you passed).
+- **Direct path** (`/apt:quick foo`): no `task_id` in context — allocate now:
+  ```bash
+  apt-tools task ensure . --description "$ARGUMENTS" --intent create-new --track QUICK
+  ```
+  ensure is keyed on the normalized description + scope, so a retry returns the SAME canonical `{slug}_YY-MM-DD` `task_id`.
 
-2. **If no `task_id` in skill context** (direct path):
-   ```bash
-   apt-tools task create . --description "$ARGUMENTS" --track QUICK
-   ```
-   Parse the generated `task_id` from the envelope — it will be the canonical `{slug}_YY-MM-DD` shape.
+Parse `task_id` from the returned envelope.
 
 The task id is now canonical (no more `quick-YYYYMMDD-*` invention). `QuickTaskSchema` accepts both the canonical `{slug}_YY-MM-DD` form and the legacy `quick-YYYYMMDD-{slug}` form for back-compat with already-shipped task records on disk.
 
-**Worktree isolation (both paths).** `task create` provisions a worktree when `task_isolation.worktree_per_task` is enabled (track-agnostic — QUICK gets one too). Parse `worktree.worktree_path`, `worktree.branch`, and `worktree.base_branch` from the `task create` envelope (direct path); on the router path the orchestrator already passed `worktree_path` into your skill context — use that. When a `worktree` block is present, print the banner and run all subsequent editing Bash commands with `cd {worktree_path} &&`:
+**Worktree isolation (both paths).** `task ensure --intent create-new` provisions a worktree when `task_isolation.worktree_per_task` is enabled (track-agnostic — QUICK gets one too). Parse `worktree.worktree_path`, `worktree.branch`, and `worktree.base_branch` from the `task ensure` envelope (direct path); on the router path the orchestrator already passed `worktree_path` into your skill context — use that. When a `worktree` block is present, print the banner and run all subsequent editing Bash commands with `cd {worktree_path} &&`:
 
 ```
 [APT] Working in isolated worktree: {worktree_path}
@@ -173,7 +165,7 @@ Show the affected files briefly before proceeding (5-second delay; user can inte
 Make the changes directly:
 - Follow existing code patterns and conventions
 - Keep changes minimal — solve the stated problem, nothing more
-- If touching code with tests, run the tests to make sure nothing breaks
+- If touching tested code, run those tests
 
 ## 5. Verify (Lightweight)
 
@@ -183,7 +175,7 @@ Run a quick sanity check appropriate to the change:
   pnpm typecheck 2>&1 | tail -20
   ```
 - **Config change:** Validate the config is syntactically correct
-- **Doc change:** No verification needed unless `--verify` flag is set
+- **Doc change:** none unless `--verify` is set
 - **Style change:** Run lint on changed files
 
 If visual verification is performed via MCP screenshots:
@@ -193,24 +185,26 @@ If visual verification is performed via MCP screenshots:
 If verification fails:
 - Fix the issue
 - Re-run verification
-- If stuck after 2 attempts, report the failure and let the user decide
+- If stuck after 2 attempts, report and let the user decide
 
 ## 6. Commit
 
-Create an atomic commit with a descriptive message:
+Create an atomic commit:
 
 ```bash
 git add {changed-files}
 git commit -m "{type}: {description}"
 ```
 
-Use appropriate conventional commit type:
-- `fix:` for bug fixes
-- `docs:` for documentation
-- `style:` for formatting/style
-- `chore:` for config, dependencies, maintenance
-- `refactor:` for code restructuring
-- `feat:` for small features (rare for quick tasks)
+Use a conventional commit type: `fix:` / `docs:` / `style:` / `chore:` / `refactor:` / `feat:` (rare for quick tasks).
+
+After the commit, emit the registry delta (one non-blocking command):
+
+```bash
+node packages/framework/bin/apt-tools.mjs features-reconcile . --draft --task-id {task-id} || true
+```
+
+Stage `.aperant/features/deltas/` with the commit; fill any `needs-disposition` field (usually `no-semantic-change` + a one-line reason).
 
 ## 7. Record Task
 

package/dist/plugin/skills/apt-review/SKILL.md

@@ -146,8 +146,8 @@ AGENTS.md, READMEs, docs/**). It is **inline** in the reviewer brief — a
 grep workload that does not justify a separate agent spawn.
 
 This pass drives two CLI verbs: `apt-tools docs-audit` (external +
-internal drift detection) and `apt-tools features-audit` (registry
-coverage). Both emit JSON; the reviewer buckets by policy.
+internal drift detection) and `apt-tools features-reconcile --check`
+(registry coverage). Both emit JSON; the reviewer buckets by policy.
 
 1. Run the docs-drift audit against the task's diff:
 
@@ -159,23 +159,26 @@ coverage). Both emit JSON; the reviewer buckets by policy.
    Capture the `findings[]` (for `flag-drift` surfaces) and `patch_plan[]`
    (for `auto-update` surfaces).
 
-2. Run the features-registry audit in report-only mode:
+2. Run the features-registry reconcile check in report-only mode:
 
    ```bash
-   node packages/framework/bin/apt-tools.mjs features-audit . \
-     --since <task-base-ref> --format json
+   node packages/framework/bin/apt-tools.mjs features-reconcile . \
+     --check --warn-only --base <task-base-ref>
    ```
 
-   The executor post-step in `/apt:execute` already applies stubs for
-   `auto-update` surfaces; this run catches anything the executor missed
-   (e.g. stubs were generated but the user's policy opted out, or the
-   executor skipped the post-step on a blocked subtask).
+   The executor's `/apt:execute` §3e-features delta-emit already recorded
+   this task's registry deltas; this run catches anything the executor
+   missed (an uncovered qualifying file, a stale fingerprint after a
+   re-edit, a delta still carrying `needs-disposition`). The repair the
+   reviewer surfaces is `features-reconcile . --draft --task-id <id>`
+   (then fill dispositions) — never a hand-authored area edit.
 
 3. **Policy split — critical:**
    - **auto-update findings** are FIXED inline via the fix-review loop. The
      reviewer applies the patch via the matching `apt-tools` subcommand
-     (`features-audit --apply-stubs`, `roadmap rollup`, registry rewriter).
-     These land in iterations 1–2 of the fix loop.
+     (`features-reconcile --draft` + fill dispositions + `--write`,
+     `roadmap rollup`, registry rewriter). These land in iterations 1–2 of
+     the fix loop.
    - **flag-drift findings** are SURFACED only. They appear in
      `review_findings.md` with category `docs-drift`, severity `warning`,
      and the full shape

package/dist/plugin/skills/apt-run/SKILL.md

@@ -17,7 +17,7 @@ execution_modes:
   - plan-mode
   - plan-only
 allowed-tools: "Bash, Read, Write, Edit, Grep, Glob, Task"
-argument-hint: "apt:run [task description] [--skip-review] [--phase-mode auto|agent-team|sub-agents|sequential] [--spar-gates plan[,execute]]"
+argument-hint: "apt:run [task description] [--skip-review] [--phase-mode auto|agent-team|sub-agents|sequential] [--spar-gates plan[,execute]] [--full]"
 gates: 
   - constitution-read
   - constitution-coverage
@@ -29,6 +29,8 @@ config_keys:
 Run the full Aperant pipeline: plan a task, execute all subtasks, verify the implementation, and optionally review the code. This is the one-command experience — from task description to verified, reviewed code.
 
 As of C32 the STANDARD and DEEP auto pipelines **terminate on review** (`plan → execute → verify → review`). Pass `--skip-review` to stop after verify; for trivial work the QUICK track still skips planning entirely.
+
+Pass `--full` to carry a SINGLE task all the way to **merged + green**: it extends the pipeline past review through **ship** (a PR that auto-merges to main on green — never a direct push) and **watch-CI** (arm the watcher with auto-merge so the change lands once CI passes — the merge is performed by `/apt:watch-ci` alone, never a direct `gh pr merge`). `--full` is a thin chain over the existing `/apt:ship` + `/apt:watch-ci` skills — it forces review ON and is hard-guarded by `autonomy.allow_yolo` plus a one-time confirm (§1a). A `/apt:run` invocation WITHOUT `--full` behaves exactly as today (terminates on review).
 </objective>
 
 <your_environment>
@@ -58,7 +60,7 @@ As of C32 the STANDARD and DEEP auto pipelines **terminate on review** (`plan
 
 1. Read `AGENTS.md` if it exists
 2. Parse task description from `$ARGUMENTS` (everything before flags)
-3. Parse flags: `--skip-review`, `--dry-run`, `--phase-mode <mode>`, `--spar-gates <comma-list>`.
+3. Parse flags: `--skip-review`, `--dry-run`, `--phase-mode <mode>`, `--spar-gates <comma-list>`, `--full`.
    - `--spar-gates <plan|execute|plan,execute>` (FRAMEWORK-RFC-001) — comma-separated stage list to auto-fire `/apt:spar` after. Per-invocation override of `.aperant/config.local.json` `spar.enabled`. On QUICK track, print the verbatim hard-reject line and discard the flag (Fast Path Guarantee — CLAUDE.md):
 
    ```
@@ -71,6 +73,52 @@ As of C32 the STANDARD and DEEP auto pipelines **terminate on review** (`plan
 node packages/framework/bin/apt-tools.mjs state .
 ```
 
+## 1a. `--full` flag — surface + gates
+
+This section runs ONLY when `--full` was parsed in §1. When `--full` is absent, skip this entire section and run the pipeline exactly as today (manual mode is byte-behavior-unchanged).
+
+**Contradiction handling (resolve in THIS precedence order — the "discard" cases win first, so a `--full` that is discarded never triggers the conflict or autonomy gates):**
+
+0. **QUICK track wins first (Fast Path Guarantee).** If the task is QUICK track, discard `--full` with the Fast-Path line (item 4 below) and run the QUICK one-shot path unchanged — do NOT evaluate the `--skip-review` conflict (item 1) or the autonomy gate. On QUICK, `--full` is treated as never passed.
+
+1. **`--full` + `--skip-review` → hard reject.** `--full` requires review before auto-ship, so the two flags are contradictory. Do NOT silently let one win — print the verbatim line and exit:
+
+   ```
+   [apt:run] --full and --skip-review conflict (--full requires review before auto-ship). Pick one.
+   ```
+
+2. **`--full` IMPLIES review ON.** Treat `--skip-review` as never set for the rest of the run; §6 Review always executes.
+
+3. **`--full` + `--dry-run` → dry-run wins.** Run the plan stage only and report (the existing §3 dry-run exit), then stop. No execute, no ship — `--full` is discarded for this run.
+
+4. **QUICK track → discard `--full` with the Fast-Path line.** On QUICK track `--full` is hard-exempt (CLAUDE.md Fast Path Guarantee). Print the verbatim line and run the QUICK one-shot path unchanged:
+
+   ```
+   [apt:run] --full ignored for QUICK track (Fast Path Guarantee)
+   ```
+
+`--full` composes normally with `--phase-mode` and `--spar-gates`.
+
+**Autonomy gate (load-bearing safety valve, ID-03):**
+
+Auto-ship + auto-merge is YOLO-class. Read `.aperant/config.json` for `autonomy.allow_yolo` (boolean) and the autonomy `level` (0–3).
+
+1. **`allow_yolo` hard guard.** If `autonomy.allow_yolo !== true`, STOP before ship with the verbatim line and leave the task at `reviewing` (fully shippable by hand):
+
+   ```
+   [apt:run] --full needs autonomy.allow_yolo=true (auto-ship + auto-merge to main). Enable via /apt:setup or drop --full.
+   ```
+
+2. **One-time confirm at autonomy < 3.** Before opening the auto-merging PR (just before §6.1 Ship below), emit ONE confirmation when autonomy `level < 3` AND `--yolo` was not also passed:
+
+   ```
+   [apt:run --full] About to open a PR that auto-merges to main once CI is green. Proceed? [y/N]
+   ```
+
+   At autonomy 3 OR when `--yolo` is passed, degrade to silent (mirrors `/apt:ship`'s autonomy-3 degrade). On `N` / empty, STOP after review with the standard `/apt:ship` hand-off hint — the task is left at `reviewing`, fully shippable by hand.
+
+Note: the `allow_yolo` guard + the one-time confirm are evaluated up front here (parse-time gating) and the confirm is RE-SURFACED at the ship boundary (§6.1) so the user confirms immediately before the irreversible auto-merge arm. Review always runs first, and auto-merge always waits for green.
+
 ## 1b. Resolve Orchestration Mode
 
 Run reconcile to determine the effective orchestration strategy for this pipeline run. Pass the task's track via `--track <quick|standard|deep>` so per-track defaults from `.aperant/config.json:orchestration.per_track` apply (roundtable 2026-05-14 R7):
@@ -338,6 +386,64 @@ Skip on `spar.enabled === true` (no pre-ship gate exists in v2 — see spec §8
 
 **This is the task review, not the PR review.** It runs inline without sub-agents. For heavy multi-agent PR review, use `/apt:pr-review` separately.
 
+## 6.1. Stage 5 — Ship (apt:ship) — `--full` only
+
+**Run this section ONLY when `--full` was parsed (§1a) AND review passed** — "review passed" means the §6 review `assessment` is `approve`; a `request-changes` assessment STOPS here (task left at `reviewing`, no ship — see the stop-condition table in §6.2). When `--full` is absent, skip §6.1 + §6.2 entirely and go straight to §7 (manual mode — terminates on review).
+
+Pipeline order note: the user's phrasing was *"review, verify"* but `/apt:run` runs **verify (§5) → review (§6) → ship (§6.1)**. KEEP this order — verify gates review, and review consumes `qa_signoff.json`. Do NOT silently reorder. `--full` runs `plan → execute → verify → review → ship → watch-ci`.
+
+**Pre-ship gate (re-surface the §1a confirm at the boundary):**
+
+1. Re-check `autonomy.allow_yolo === true` (already validated in §1a; re-read here so a mid-run config edit cannot slip an auto-merge past the guard). If false, STOP with the §1a `allow_yolo` line; leave the task at `reviewing`.
+2. Emit the §1a one-time confirm (`[apt:run --full] About to open a PR that auto-merges to main once CI is green. Proceed? [y/N]`) when autonomy `level < 3` and `--yolo` was not passed. At autonomy 3 / `--yolo`, degrade to silent. On `N` / empty, STOP after review with the standard `/apt:ship` hand-off hint; the task stays at `reviewing`.
+
+**Ship (Option A — PR that auto-merges to main on green; NEVER a direct push/merge):**
+
+Invoke `/apt:ship` inline. It runs its own hard-gate (verify-approved / review-clean / consistency / gitignore), opens the PR against the task's recorded `base_branch` (main for a task forked from main), and atomically flips `reviewing → shipped-pending-merge` via `task update --pr-url` — which also arms the post-ship watcher per `ci_watch.after_ship`. `--full` MUST NEVER `git push`/`git merge` directly to main (ID-02 Option B is rejected unconditionally): "ship to main" means **a PR that auto-merges to main on green**, not a force-push. The merge itself is performed EXCLUSIVELY by `/apt:watch-ci` (§6.2, ID-10) — `--full` MUST NEVER run `gh pr merge` (with or without `--auto`) nor enable GitHub native auto-merge.
+
+Capture the opened PR number `{N}` from the `/apt:ship` result for §6.2.
+
+If `/apt:ship`'s hard-gate fails, or the branch is behind and the rebase conflicts with no `resolve_merge_conflicts`, STOP — no PR is opened and the task stays at `reviewing` (see the stop-condition table below).
+
+## 6.2. Stage 6 — Watch-CI arm (auto-merge-on-green) — `--full` only
+
+After the PR opens, force auto-merge for THIS run regardless of the config default (`ci_watch.auto_merge_on_green` is `false` by default per the D-08 kill-criteria). `/apt:ship` already armed the watcher via `ci_watch.after_ship`; this call PATCHES that already-armed watch's auto-merge flag to `true` (it does NOT reimplement arming and is idempotent):
+
+```bash
+node packages/framework/bin/apt-tools.mjs ci-watch start . --pr {N} --task-id {task-id} --host {cli} --auto-merge-on-green
+```
+
+> **ID-10 — `/apt:watch-ci` is the SOLE merge authority (hard guardrail).**
+> The auto-merge is performed EXCLUSIVELY by `/apt:watch-ci`: its §4 green branch runs a plain `gh pr merge {N} --squash` — NEVER `--auto` — only after its `allGreen` classifier confirms every check is terminal-green.
+> `--full` (and `/apt:ship`) MUST NEVER itself run `gh pr merge` — with or without `--auto`/`--squash` — nor enable GitHub native auto-merge.
+> Rationale: this repo has no required status checks, so `gh pr merge --auto` degrades to an immediate merge — it would land the PR before CI can turn it red (the exact bug this guardrail prevents).
+> After ship, the ONLY merge-capable dispatch is invoking `/apt:watch-ci --tick --pr {N}` (below) and letting the watcher decide; you do NOT merge here.
+
+**Branch on host cron capability.** Run host-detect and read `host_capabilities.cron`:
+
+```bash
+node packages/framework/bin/apt-tools.mjs host-detect .
+```
+
+- **cron-capable host** (e.g. Claude Code, `cron: true`): the watcher is armed with auto-merge ON; hand the merge to `/apt:watch-ci` — register a recurring `CronCreate` whose payload is `/apt:watch-ci --tick --pr {N}` (per `/apt:watch-ci` §3), then invoke `/apt:watch-ci --tick --pr {N}` once now to run the first (still-waiting) tick. Then **EXIT — do NOT loop** (respect `/apt:watch-ci`'s single-execution-per-invocation contract). The cron beat drives `/apt:watch-ci` to merged + green unattended, and its §4 green branch performs the green-gated squash-merge — you never merge from here. Report: watcher armed, auto-merge ON, and the deadline.
+- **non-cron host** (Codex / Gemini / OpenCode): truly-unattended watching is impossible. Arm the watch state + auto-merge (the `ci-watch start --auto-merge-on-green` above) but do NOT impersonate a scheduler — NEVER fake a `while` / `sleep` loop. Print the honest manual-tick instruction:
+
+  ```
+  [apt:run --full] PR opened + CI watcher state created (host has no cron). Advance manually: /apt:watch-ci --tick --pr {N}. Auto-merge-on-green is set; the merge fires on the first green tick you run.
+  ```
+
+**Stop conditions (every gate is reused; each STOP leaves the task in its current lifecycle state and NEVER merges). `--full` adds NO new gate — it only chains the existing ones and surfaces the stop reason in §7:**
+
+| Stop point | Resulting state |
+|---|---|
+| QA `rejected` after max iters (§5) | `verifying`; no ship |
+| Review `request-changes` (§6) | `reviewing`; no ship |
+| Ship hard-gate fail (verify-approved / review-clean / consistency / gitignore) | `reviewing`; no PR |
+| Branch behind + rebase conflict (no `resolve_merge_conflicts`) | `reviewing`; no PR |
+| `allow_yolo=false` or confirm `N` (§1a / §6.1) | `reviewing`; no PR |
+| CI red after 5-attempt / 4h-wall (watcher) | `shipped-pending-merge`; PR comment, NOT merged |
+| Merge conflict mid-watch (`diverged-bailed`) | `shipped-pending-merge`; PR comment, NOT merged |
+
 ## 7. Pipeline Summary
 
 Render the phase rail panel verbatim — branch glyphs `┌─ │ └─`, status glyphs `✓` (done) / `●` (active) / `○` (pending/skipped), inline metrics per row drawn from the artifacts written across §3–§6:
@@ -359,7 +465,18 @@ Substitute live values from the on-disk artifacts: `build-progress.json.complete
 **Always end with a "What's Next" recommendation:**
 
 ```
-{If review assessment is "approve" and QA approved:}
+{If --full ran and the PR opened (cron host):}
+-> Shipped. PR #{N} opened; CI watcher armed with auto-merge-on-green (deadline {deadline}).
+   The cron beat drives it to merged + green. /apt:close-task runs post-merge.
+
+{If --full ran and the PR opened (non-cron host):}
+-> Shipped. PR #{N} opened; watcher state created with auto-merge-on-green.
+   Advance manually: /apt:watch-ci --tick --pr {N} (merge fires on the first green tick).
+
+{If --full was requested but a gate STOPPED before ship:}
+-> {stop reason}. Task left at {lifecycle state}, not merged. {remediation per the stop-condition table}
+
+{If review assessment is "approve" and QA approved (no --full):}
 -> Recommended: /apt:ship — create PR for this task
    Also: /apt:pr-review (deep multi-agent review) | manual review
 
@@ -388,5 +505,17 @@ atomic `reviewing → shipped-pending-merge` flip. `/apt:ship` then flips
 does not need to record or drain anything beyond ensuring each child-skill
 stage runs to its success-end.
 
+**`--full` full lifecycle map:** `planning → executing → verifying → reviewing
+→ shipped-pending-merge → (CI green + merged) → completed`. The `reviewing →
+shipped-pending-merge` flip is done atomically by ship's `task update --pr-url`
+(§6.1). `shipped-pending-merge → completed` is done by `/apt:close-task`
+post-merge — **`--full` does NOT auto-invoke `/apt:close-task`.** On cron hosts
+the merge happens asynchronously AFTER `--full` has exited, so `--full` cannot
+observe it; closeout is left to the existing path (the watcher's green branch
+suggests `/apt:close-task`, and the user / passive sweeper runs it). Folding
+close-task into `--full` would require it to become a recurring watcher —
+explicitly rejected (it would duplicate the watcher and violate the
+single-execution contract).
+
 </process>
 </output>

package/dist/plugin/skills/apt-ship/SKILL.md

@@ -24,6 +24,7 @@ gates:
   - consistency-check
   - r-persona-alignment
   - gitignore-in-sync
+  - features-reconciled
 config_keys:
   - pipeline.auto_branch
   - pipeline.branch_prefix
@@ -54,6 +55,27 @@ Create a pull request (or publish a package) with full traceability from decisio
 
 <process>
 
+## 0.0 Materialize feature-registry deltas
+
+BEFORE the hard-gate check runs (write-then-verify: the `features-reconciled` gate in Section 0 verifies what this step wrote), materialize any pending feature-registry deltas into the area JSONs + a durable receipt:
+
+```bash
+ship_cwd=$(node packages/framework/bin/apt-tools.mjs task get . --id {task-id} | jq -r '.task.worktree_path // empty')
+ship_cwd=${ship_cwd:-.}
+node packages/framework/bin/apt-tools.mjs features-reconcile "$ship_cwd" --write --task-id {task-id}
+```
+
+Handle the envelope:
+
+- **`status: "ok"` with writes** (`materialized > 0` or a non-empty `changed_paths`): the write already self-staged its committable outputs (areas + receipt + REGISTRY.md + deleted delta paths). Commit them in `ship_cwd`:
+  ```bash
+  git -C "$ship_cwd" commit -m "chore(aperant): materialize feature-registry deltas"
+  ```
+  (Skip the commit when nothing was staged — a zero-delta write only regenerates REGISTRY.md when it drifted.)
+- **`status: "skip"` (`reason: "policy-opt-out"`)**: proceed — the `features-reconciled` gate reports `skip` for the same reason.
+- **`status: "error"` with `kind: "hard-conflict"`**: STOP. Print the conflict report verbatim (it names BOTH writer delta files). The repair is `features-reconcile "$ship_cwd" --draft --task-id {task-id}` plus hand-fixing the conflicting operations — NEVER `--force` around this stop.
+- **`status: "error"` with `kind: "invalid-deltas"`**: STOP and report — a pending delta still carries `needs-disposition` (or another validation failure); fill the dispositions and re-run.
+
 ## 0. Hard Gate Check
 
 Before gathering context or building any PR artifacts, run the hard-gate check for the `ship` skill:
@@ -72,7 +94,7 @@ Parse the JSON envelope:
   ```
   Exit the skill. Do NOT auto-apply `--force` — force is an explicit human decision.
 
-The ship gate covers constitution-read, verify-approved (qa_signoff.json verdict), review-clean (no unresolved critical/warning findings), gitignore-in-sync (.aperant/.gitignore conformance), and consistency-check (G8 — cross-artifact consistency between spec.md, implementation_plan.json, review.json, qa_signoff.json, and build-progress.json). Because these gates run here, Sections 1–3 below no longer need to re-check the verify verdict or block on review findings — the gate already did it.
+The ship gate covers constitution-read, verify-approved (qa_signoff.json verdict), review-clean (no unresolved critical/warning findings), gitignore-in-sync (.aperant/.gitignore conformance), features-reconciled (feature-registry deltas materialized in Section 0.0 + coverage/schema/integrity verified — blocking on ALL profiles, QUICK/DEBUG included), and consistency-check (G8 — cross-artifact consistency between spec.md, implementation_plan.json, review.json, qa_signoff.json, and build-progress.json). Because these gates run here, Sections 1–3 below no longer need to re-check the verify verdict or block on review findings — the gate already did it.
 
 ### 0.1 Parse `profile` from the envelope
 
@@ -249,14 +271,14 @@ If `rn_enabled !== "true"`, jump to Section 3.
 
 ### 2.6.1 Compute the feature-registry diff
 
-The auto-draft needs to know which features the PR's commits touched. Use the same `features-audit` surface that `apt:execute` uses post-step:
+The auto-draft needs to know which features the PR's commits touched. Source the diff from a read-only reconcile draft (no file is written):
 
 ```bash
-base=$(node packages/framework/bin/apt-tools.mjs task get . --id {task-id} | jq -r '.base_branch // "main"')
-feature_diff=$(node packages/framework/bin/apt-tools.mjs features-audit . --diff-since "$base" --json)
+base=$(node packages/framework/bin/apt-tools.mjs task get . --id {task-id} | jq -r '.task.base_branch // "main"')
+feature_diff=$(node packages/framework/bin/apt-tools.mjs features-reconcile . --draft --dry-run --base "$base" --task-id {task-id})
 ```
 
-The envelope shape (see `packages/framework/src/cli/commands/features-audit.mjs`) returns the list of touched features with their declared `personas: []` field (when the registry's feature row carries one).
+The envelope's `delta.files[]` entries (see `packages/framework/src/cli/commands/features-reconcile.mjs`) carry each touched surface with its `area` — feed those areas to the helper below alongside the registry's declared `personas: []` fields (when the feature rows carry one).
 
 ### 2.6.2 Decide draft vs block via the helper
 
@@ -578,6 +600,8 @@ suggest_mode=$(jq -r '.pr_review.suggest_after_ship // "always"' .aperant/config
 
 ### 7.2 Post-ship /apt:watch-ci hook
 
+> Cross-reference: `/apt:run --full` drives this skill's §6 PR creation + §7.2 watcher arming end-to-end (review → ship → auto-merge-on-green watch). When invoked from that chain, the watcher's auto-merge is force-enabled for the run via `apt-tools ci-watch start --auto-merge-on-green` (see `apt-run/SKILL.md` §6.1–§6.2); `/apt:ship` itself behaves identically whether invoked standalone or by `--full`.
+
 After Section 7.1's hint resolves (whether it ran the deep review or skipped), report or interactively arm the post-ship CI watcher. The hook is controlled by `ci_watch.after_ship` in `.aperant/config.json` (tri-state: `auto` | `ask` | `never`). The default depends on host capability — `auto` on cron-capable hosts (Claude Code, Pi), `never` elsewhere.
 
 **Skip entirely** when no PR URL was captured in Section 6 (library `npm publish`-only path — same skip rule as 7.1).

package/dist/plugin/skills/apt-spar/SKILL.md

@@ -186,8 +186,8 @@ The table below shows the canonical command shape per (partner × rung); the act
 | Partner | Rung | Command | Notes |
 |---|---|---|---|
 | codex | mcp | tool call: `mcp__codex-mcp__codex({prompt, model})` where `model` is the `model` field returned by `apt-tools spar-resolve-partner --partner codex` (see §5a below). | **Demoted to LAST for codex** (see the codex walk-order note in §3) — attempt this rung only when the resolver returns `available: true`. 900000ms (15 min) timeout (configurable `apt-spar.mcp_timeout_ms`); on timeout fall through to plugin then CLI. When the resolver returns `available: false`, treat the MCP rung as UNAVAILABLE and fall through to plugin/CLI — never invent a default model (the MCP server silently substitutes a stale hardcoded default model id, which is exactly the bug we are fixing). |
-| codex | plugin | `node "${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs" task "$(cat <<'APT_SPAR_PROMPT_EOF' ... APT_SPAR_PROMPT_EOF\n)"` | No `--model` flag — `codex-companion.mjs` invokes `codex exec` which inherits `~/.codex/config.toml` automatically. **NO `--write`. NO `--effort` override.** Per SPAR-04 — spar is conversation, not patching. |
-| codex | cli | `codex exec "$(cat <<'APT_SPAR_PROMPT_EOF' ... APT_SPAR_PROMPT_EOF\n)"` | Precedent: `apt-pr-review/SKILL.md:1084`. No `--model` flag — `codex exec` inherits `~/.codex/config.toml` automatically. Verify with `codex --help`. |
+| codex | plugin | `node "${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs" task "$(cat <<'APT_SPAR_PROMPT_EOF' ... APT_SPAR_PROMPT_EOF\n)" < /dev/null` | No `--model` flag — `codex-companion.mjs` invokes `codex exec` which inherits `~/.codex/config.toml` automatically. **NO `--write`. NO `--effort` override.** Per SPAR-04 — spar is conversation, not patching. The `< /dev/null` is load-bearing — the shim forwards to `codex exec`, which wedges on stdin EOF under a no-TTY subprocess (see the wedge note below). |
+| codex | cli | `codex exec --sandbox read-only "$(cat <<'APT_SPAR_PROMPT_EOF' ... APT_SPAR_PROMPT_EOF\n)" < /dev/null` | Precedent: `apt-pr-review/SKILL.md:1084`. No `--model` flag — `codex exec` inherits `~/.codex/config.toml` automatically. The `< /dev/null` un-wedges the no-TTY stdin block and `--sandbox read-only` keeps the spar read-only (see the wedge note below). Verify with `codex --help`. |
 | claude | mcp | tool call: `mcp__claude-code-mcp__claude_code({prompt})` | Preferred. Same 900000ms (15 min) timeout + fallthrough rule. |
 | claude | plugin | n/a | No plugin shim exists for Claude. Skip this rung. |
 | claude | cli | `claude -p "$(cat <<'APT_SPAR_PROMPT_EOF' ... APT_SPAR_PROMPT_EOF\n)" --output-format text` | Symmetric. Claude has no `--write` equivalent — asymmetric flags are a smell. |
@@ -195,6 +195,8 @@ The table below shows the canonical command shape per (partner × rung); the act
 | gemini | plugin | n/a | No plugin shim exists for Gemini. Skip this rung. |
 | gemini | cli | `gemini "$(cat <<'APT_SPAR_PROMPT_EOF' ... APT_SPAR_PROMPT_EOF\n)"` | No `-m` flag — gemini-cli resolves model via `--model` > `GEMINI_MODEL` env > `~/.gemini/settings.json` > built-in default per `docs/cli/model-routing.md:47-58`. Drop the flag, let the cascade work; users override per-shell via `GEMINI_MODEL=...` or per-project via `settings.json`. |
 
+**Codex stdin-wedge note (load-bearing).** `codex exec` reads the positional prompt and THEN blocks on stdin EOF under a no-TTY subprocess (the Bash tool), printing `Reading additional input from stdin…` and never returning. Redirecting `< /dev/null` un-wedges it (verified: returns in ~6s instead of hanging, exit 0, and prints the resolved `model:` it used). Both codex Bash rungs (plugin shim + raw CLI) carry `< /dev/null` because the shim forwards to `codex exec`. The `--sandbox read-only` flag on the raw-CLI rung keeps the spar read-only — aligning with the SPAR-04 "NO `--write`" rule; read-only still permits the partner's investigative Read/Grep.
+
 Set the Bash tool's `timeout` parameter to `--timeout-ms` (default 300000).
 
 **Timeout calibration.** The 5-min Bash-rung default and 15-min MCP-rung default are sized for heavy-research partner runs — modern partner CLIs commonly spend multiple minutes doing real Read/Grep/Bash investigation before producing a round response. The two defaults are intentionally asymmetric: the Bash rungs (plugin shim, raw CLI) are capped at the Claude Code Bash tool's 600000ms (10 min) host ceiling, while the MCP rung — a structured tool call rather than a Bash invocation — has no host ceiling and can carry the worst-case 15-min Claude Code partner. For tighter budgets (e.g. CI), pass `--timeout-ms` explicitly. The MCP-rung override is downward-only: if you observe consistent partner-CLI wedges (auth handshakes, hosted-API stalls, CI lanes wanting fast failure), set `apt-spar.mcp_timeout_ms` BELOW the 15-min default in `.aperant/config.json` (e.g. `120000` for a 2-min fast-fail budget) — raising it above 15 min is unnecessary because the default already covers the documented worst case. Future versions may introduce per-partner defaults.
@@ -224,7 +226,7 @@ Follow the envelope's `recommended_walk` / `prefer_self_resolving` for the rung
 node "${CLAUDE_PLUGIN_ROOT}/scripts/codex-companion.mjs" task "$(cat <<'APT_SPAR_PROMPT_EOF'
 <prompt body — opaque, no shell expansion>
 APT_SPAR_PROMPT_EOF
-)"
+)" < /dev/null
 
 # Claude direction
 claude -p "$(cat <<'APT_SPAR_PROMPT_EOF'

package/dist/plugin/skills/apt-watch-ci/SKILL.md

@@ -37,7 +37,7 @@ The locked decisions backing every section are in `.aperant/context/notes/framew
 - **Working directory:** the task's worktree (or the project root if this is a non-worktree task).
 - **State files:** `.aperant/ci-watches/{pr}.json` (per-PR state, D-04); `.aperant/ci-watches/{pr}.lock` (per-PR atomic lock, D-05). Both ephemeral — they are NOT committed.
 - **Events:** every tick appends a `ci-watch.tick` event to `.aperant/events/{today}.jsonl`; `start` appends `ci-watch.armed`; the fix-and-push path appends `ci-watch.fix-pushed`; terminal actions append `ci-watch.stopped` with a `reason`.
-- **CLI surface:** `apt-tools ci-watch start|stop|status|tick --pr N`. The skill body shells out to those subcommands — DO NOT re-implement the classifier in your prompt; the cmd already does it.
+- **CLI surface:** `apt-tools ci-watch start|stop|status|tick --pr N`. `start` also accepts `--auto-merge-on-green` (per-run override — forces `auto_merge_on_green: true` on the snapshot without persisting `ci_watch.auto_merge_on_green` into config; on an already-armed watch it PATCHES the snapshot rather than no-opping). `/apt:run --full` uses this flag to guarantee auto-merge for a single PR after ship's config-driven arm runs first. The skill body shells out to those subcommands — DO NOT re-implement the classifier in your prompt; the cmd already does it.
 
 ---
 
@@ -87,7 +87,7 @@ For the `--tick` mode, execute exactly the following sequence — once — insid
 
 When `action ∈ {green, merged, closed, attempts-cap, wall-cap, identical-log}`:
 
-- **green** — print "CI green for PR {N}." If `ci_watch.auto_merge_on_green` is `true` in `.aperant/config.json`, run `gh pr merge {N} --auto --squash` then suggest `/apt:close-task`.
+- **green** — print "CI green for PR {N}." If `ci_watch.auto_merge_on_green` is `true` in `.aperant/config.json`, run `gh pr merge {N} --squash` then suggest `/apt:close-task`. Use a PLAIN merge here, NOT `--auto`: the classifier has already confirmed every check is `SUCCESS`/`SKIPPED` (`stop-matrix.mjs` `allGreen`) before this branch fires, so green is gated by the watcher, not by GitHub branch protection. `--auto` bought nothing on this path — in a repo WITHOUT required status checks `gh pr merge --auto` degrades to an immediate merge anyway — and dropping it removes the classify→merge ambiguity in unprotected repos.
   - **DO NOT pass `--delete-branch`** to `gh pr merge` from this auto-merge path — ever, unconditionally. The watcher's cwd is the task worktree, where `gh`'s `--delete-branch` post-merge cleanup tries to `git switch <base>` and fails because `<base>` is checked out in the primary worktree. The remote merge has already succeeded by then; local branch + worktree cleanup is `/apt:close-task`'s job via `apt-tools task close-merged` → `computeWorktreeCleanup` (see FRAMEWORK-BUG-019).
 
   Else print the exact D-08 text:
@@ -125,9 +125,11 @@ When `action === 'fix'` (or `diverged-rebased`/`diverged-bailed`):
 5. **Emit event.** `apt-tools event append . --type ci-watch.fix-pushed --data '{pr, attempts, commit_sha}'`.
 6. **Reschedule** per §3 step 4.
 
+When the failed check is `features-reconcile`, the fixer MAY run the deterministic repair directly instead of a free-form fix: `apt-tools features-reconcile . --draft --task-id {task-id}` in the worktree, fill the scaffold's dispositions, `apt-tools features-reconcile . --write --task-id {task-id}`, commit + push. Correctness never depends on this path — raw PRs (no active task / pr_url) repair via the red check's printed `--draft` command.
+
 For `diverged-rebased`: the cmd already returned the verb; the orchestrator runs `git -C {worktree} fetch && git rebase origin/{base}` BEFORE the fix step. On conflict the action becomes `diverged-bailed`.
 
-For `diverged-bailed`: default behavior is to exit with a PR comment summarizing the conflict. Self-heal is **opt-in** via `ci_watch.resolve_merge_conflicts` (default false) in `.aperant/config.json`. When enabled, instead of bailing, hand off to **`/apt:merge-conflict-resolution`** (`--base origin/{base}`) for the worktree; it resolves the rebase conflict inline and re-probes mergeability. On success, continue to the §5 fix-and-push step (`git push origin {branch}`) and reschedule per §3 — the watcher keeps running. On its non-convergence STOP (it aborts the rebase to a clean tree first), fall back to the bail-with-PR-comment path. The resolved branch still goes through CI; the watcher never auto-merges except via the existing config-gated `gh pr merge --auto`.
+For `diverged-bailed`: default behavior is to exit with a PR comment summarizing the conflict. Self-heal is **opt-in** via `ci_watch.resolve_merge_conflicts` (default false) in `.aperant/config.json`. When enabled, instead of bailing, hand off to **`/apt:merge-conflict-resolution`** (`--base origin/{base}`) for the worktree; it resolves the rebase conflict inline and re-probes mergeability. On success, continue to the §5 fix-and-push step (`git push origin {branch}`) and reschedule per §3 — the watcher keeps running. On its non-convergence STOP (it aborts the rebase to a clean tree first), fall back to the bail-with-PR-comment path. The resolved branch still goes through CI; the watcher never auto-merges except via the existing config-gated green-branch `gh pr merge --squash` (§4).
 
 ---
 
@@ -164,5 +166,5 @@ If you find yourself wanting to add "and then wait 5 minutes and run again," STO
 ## Notes for the orchestrator
 
 - All gh CLI calls run with the host's existing auth. The watcher introduces no new secret material (per task `dimensions_covered.token-encryption.crossed: false`).
-- `auto_merge_on_green` is snapshotted from `.aperant/config.json` at `start` time (state file's `auto_merge_on_green` field). Changing the config mid-watch does NOT retroactively affect armed watches — re-run `start` to pick up the new value.
+- `auto_merge_on_green` is snapshotted from `.aperant/config.json` at `start` time (state file's `auto_merge_on_green` field). Changing the config mid-watch does NOT retroactively affect armed watches — re-run `start` to pick up the new value. The `--auto-merge-on-green` start flag forces it `true` for one run regardless of the config default (it patches an already-armed snapshot too); this is how `/apt:run --full` drives auto-merge without flipping the global config.
 - The fix-CLI shell-out is the cleanest abstraction we have for portability. It's NOT a sub-agent. On Claude Code that means another `claude` invocation; on Codex/Gemini/OpenCode/Pi, the equivalent binary. Detection lives in `apt-tools host-detect`'s `cli` field.

package/dist/schemas/feature-registry.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"feature-registry.d.ts","sourceRoot":"","sources":["../../src/schemas/feature-registry.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAA;AA0BvB,eAAO,MAAM,gBAAgB;;;;;;;;;;;;;;;;;iBAa3B,CAAA;AAEF,eAAO,MAAM,kBAAkB;;;;;;;;;;;;;;;;;;;;;;iBAK7B,CAAA;AAEF,eAAO,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBAQhC,CAAA;AAGF,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAA;AACzD,MAAM,MAAM,YAAY,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,kBAAkB,CAAC,CAAA;AAC7D,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAA;AAGnE,wBAAgB,uBAAuB,CAAC,IAAI,EAAE,OAAO;;;;;;;;;;;;;;;;;;;;;;;;GAEpD;AAGD,eAAO,MAAM,yBAAyB;;;;;;;;;;;;;;;;;;;;;;;;;;;;kBAAwC,CAAA"}
+{"version":3,"file":"feature-registry.d.ts","sourceRoot":"","sources":["../../src/schemas/feature-registry.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAA;AA0BvB,eAAO,MAAM,gBAAgB;;;;;;;;;;;;;;;;;iBAa3B,CAAA;AAEF,eAAO,MAAM,kBAAkB;;;;;;;;;;;;;;;;;;;;;;iBAK7B,CAAA;AAiBF,eAAO,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBAuBhC,CAAA;AAGF,MAAM,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,gBAAgB,CAAC,CAAA;AACzD,MAAM,MAAM,YAAY,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,kBAAkB,CAAC,CAAA;AAC7D,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAA;AAGnE,wBAAgB,uBAAuB,CAAC,IAAI,EAAE,OAAO;;;;;;;;;;;;;;;;;;;;;;;;GAEpD;AAKD,eAAO,MAAM,yBAAyB;;;;;;;;;;;;;;;;;;;;;;;;;;;;kBAA4C,CAAA"}

package/dist/schemas/feature-registry.js

@@ -38,7 +38,7 @@ export const FeatureGroupSchema = z.object({
     component: ComponentRef.optional(),
     sub_features: z.array(SubFeatureSchema).default([]),
 });
-export const FeatureRegistrySchema = z.object({
+const FeatureRegistryBaseSchema = z.object({
     area: z.string().min(1),
     route: z.string().min(1),
     components: z.array(ComponentRef).default([]),
@@ -47,10 +47,41 @@ export const FeatureRegistrySchema = z.object({
     }),
     features: z.array(FeatureGroupSchema),
 });
+// Uniqueness refinement (features-reconcile AC17): feature ids must be unique
+// per area, and sub_feature ids unique per feature group. Mirrored by the
+// dependency-free twin validator `src/cli/features/area-shape.mjs` (the
+// bare-node CI check cannot import zod) — parity is locked by
+// `feature-registry-schema-parity.test.ts`.
+export const FeatureRegistrySchema = FeatureRegistryBaseSchema.superRefine((data, ctx) => {
+    const featureIds = new Set();
+    for (const [i, group] of data.features.entries()) {
+        if (featureIds.has(group.id)) {
+            ctx.addIssue({
+                code: 'custom',
+                path: ['features', i, 'id'],
+                message: `duplicate feature id "${group.id}" in area`,
+            });
+        }
+        featureIds.add(group.id);
+        const subIds = new Set();
+        for (const [j, sub] of group.sub_features.entries()) {
+            if (subIds.has(sub.id)) {
+                ctx.addIssue({
+                    code: 'custom',
+                    path: ['features', i, 'sub_features', j, 'id'],
+                    message: `duplicate sub_feature id "${sub.id}" in group`,
+                });
+            }
+            subIds.add(sub.id);
+        }
+    }
+});
 // Validator — thin wrapper returning zod's discriminated union { success: true, data } | { success: false, error }
 export function validateFeatureRegistry(data) {
     return FeatureRegistrySchema.safeParse(data);
 }
-// Pre-computed JSON Schema for use in LLM prompt injection
-export const featureRegistryJsonSchema = z.toJSONSchema(FeatureRegistrySchema);
+// Pre-computed JSON Schema for use in LLM prompt injection. Derived from the
+// BASE object schema — the uniqueness superRefine is not JSON-Schema
+// representable and would be dropped/rejected by z.toJSONSchema.
+export const featureRegistryJsonSchema = z.toJSONSchema(FeatureRegistryBaseSchema);
 //# sourceMappingURL=feature-registry.js.map

package/dist/schemas/feature-registry.js.map

@@ -1 +1 @@
-{"version":3,"file":"feature-registry.js","sourceRoot":"","sources":["../../src/schemas/feature-registry.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAA;AAEvB,yGAAyG;AACzG,kGAAkG;AAClG,yEAAyE;AAEzE,MAAM,YAAY,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,UAAU,EAAE,YAAY,EAAE,SAAS,CAAC,CAAC,CAAA;AAElE,6GAA6G;AAC7G,4GAA4G;AAC5G,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC;IAC1B,CAAC,CAAC,OAAO,CAAC,IAAI,CAAC;IACf,CAAC,CAAC,OAAO,CAAC,KAAK,CAAC;IAChB,CAAC,CAAC,OAAO,CAAC,SAAS,CAAC;IACpB,CAAC,CAAC,OAAO,CAAC,SAAS,CAAC;CACpB,CAAC,CAAA;AAEF,MAAM,QAAQ,GAAG,CAAC,CAAC,MAAM,EAAE,CAAC,KAAK,CAAC,cAAc,EAAE;IACjD,OAAO,EAAE,6DAA6D;CACtE,CAAC,CAAA;AAEF,wFAAwF;AACxF,0FAA0F;AAC1F,kGAAkG;AAClG,MAAM,YAAY,GAAG,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAA;AAEtC,MAAM,CAAC,MAAM,gBAAgB,GAAG,CAAC,CAAC,MAAM,CAAC;IACxC,EAAE,EAAE,QAAQ;IACZ,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,SAAS,EAAE,YAAY,CAAC,QAAQ,EAAE;IAClC,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,KAAK,EAAE,UAAU;IACjB,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC9B,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC/B,KAAK,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC7B,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC/B,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC/B,QAAQ,EAAE,YAAY,CAAC,QAAQ,EAAE;IACjC,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAChC,CAAC,CAAA;AAEF,MAAM,CAAC,MAAM,kBAAkB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC1C,EAAE,EAAE,QAAQ;IACZ,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,SAAS,EAAE,YAAY,CAAC,QAAQ,EAAE;IAClC,YAAY,EAAE,CAAC,CAAC,KAAK,CAAC,gBAAgB,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC;CACnD,CAAC,CAAA;AAEF,MAAM,CAAC,MAAM,qBAAqB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC7C,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACxB,UAAU,EAAE,CAAC,CAAC,KAAK,CAAC,YAAY,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC;IAC7C,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,KAAK,CAAC,mCAAmC,EAAE;QACnE,OAAO,EAAE,0EAA0E;KACnF,CAAC;IACF,QAAQ,EAAE,CAAC,CAAC,KAAK,CAAC,kBAAkB,CAAC;CACrC,CAAC,CAAA;AAOF,mHAAmH;AACnH,MAAM,UAAU,uBAAuB,CAAC,IAAa;IACpD,OAAO,qBAAqB,CAAC,SAAS,CAAC,IAAI,CAAC,CAAA;AAC7C,CAAC;AAED,2DAA2D;AAC3D,MAAM,CAAC,MAAM,yBAAyB,GAAG,CAAC,CAAC,YAAY,CAAC,qBAAqB,CAAC,CAAA"}
+{"version":3,"file":"feature-registry.js","sourceRoot":"","sources":["../../src/schemas/feature-registry.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAA;AAEvB,yGAAyG;AACzG,kGAAkG;AAClG,yEAAyE;AAEzE,MAAM,YAAY,GAAG,CAAC,CAAC,IAAI,CAAC,CAAC,UAAU,EAAE,YAAY,EAAE,SAAS,CAAC,CAAC,CAAA;AAElE,6GAA6G;AAC7G,4GAA4G;AAC5G,MAAM,UAAU,GAAG,CAAC,CAAC,KAAK,CAAC;IAC1B,CAAC,CAAC,OAAO,CAAC,IAAI,CAAC;IACf,CAAC,CAAC,OAAO,CAAC,KAAK,CAAC;IAChB,CAAC,CAAC,OAAO,CAAC,SAAS,CAAC;IACpB,CAAC,CAAC,OAAO,CAAC,SAAS,CAAC;CACpB,CAAC,CAAA;AAEF,MAAM,QAAQ,GAAG,CAAC,CAAC,MAAM,EAAE,CAAC,KAAK,CAAC,cAAc,EAAE;IACjD,OAAO,EAAE,6DAA6D;CACtE,CAAC,CAAA;AAEF,wFAAwF;AACxF,0FAA0F;AAC1F,kGAAkG;AAClG,MAAM,YAAY,GAAG,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAA;AAEtC,MAAM,CAAC,MAAM,gBAAgB,GAAG,CAAC,CAAC,MAAM,CAAC;IACxC,EAAE,EAAE,QAAQ;IACZ,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,SAAS,EAAE,YAAY,CAAC,QAAQ,EAAE;IAClC,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,KAAK,EAAE,UAAU;IACjB,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC9B,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC/B,KAAK,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC7B,OAAO,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;IAC/B,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC/B,QAAQ,EAAE,YAAY,CAAC,QAAQ,EAAE;IACjC,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAChC,CAAC,CAAA;AAEF,MAAM,CAAC,MAAM,kBAAkB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC1C,EAAE,EAAE,QAAQ;IACZ,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,SAAS,EAAE,YAAY,CAAC,QAAQ,EAAE;IAClC,YAAY,EAAE,CAAC,CAAC,KAAK,CAAC,gBAAgB,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC;CACnD,CAAC,CAAA;AAEF,MAAM,yBAAyB,GAAG,CAAC,CAAC,MAAM,CAAC;IAC1C,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACvB,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC;IACxB,UAAU,EAAE,CAAC,CAAC,KAAK,CAAC,YAAY,CAAC,CAAC,OAAO,CAAC,EAAE,CAAC;IAC7C,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,KAAK,CAAC,mCAAmC,EAAE;QACnE,OAAO,EAAE,0EAA0E;KACnF,CAAC;IACF,QAAQ,EAAE,CAAC,CAAC,KAAK,CAAC,kBAAkB,CAAC;CACrC,CAAC,CAAA;AAEF,8EAA8E;AAC9E,0EAA0E;AAC1E,wEAAwE;AACxE,8DAA8D;AAC9D,4CAA4C;AAC5C,MAAM,CAAC,MAAM,qBAAqB,GAAG,yBAAyB,CAAC,WAAW,CAAC,CAAC,IAAI,EAAE,GAAG,EAAE,EAAE;IACxF,MAAM,UAAU,GAAG,IAAI,GAAG,EAAU,CAAA;IACpC,KAAK,MAAM,CAAC,CAAC,EAAE,KAAK,CAAC,IAAI,IAAI,CAAC,QAAQ,CAAC,OAAO,EAAE,EAAE,CAAC;QAClD,IAAI,UAAU,CAAC,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,EAAE,CAAC;YAC9B,GAAG,CAAC,QAAQ,CAAC;gBACZ,IAAI,EAAE,QAAQ;gBACd,IAAI,EAAE,CAAC,UAAU,EAAE,CAAC,EAAE,IAAI,CAAC;gBAC3B,OAAO,EAAE,yBAAyB,KAAK,CAAC,EAAE,WAAW;aACrD,CAAC,CAAA;QACH,CAAC;QACD,UAAU,CAAC,GAAG,CAAC,KAAK,CAAC,EAAE,CAAC,CAAA;QACxB,MAAM,MAAM,GAAG,IAAI,GAAG,EAAU,CAAA;QAChC,KAAK,MAAM,CAAC,CAAC,EAAE,GAAG,CAAC,IAAI,KAAK,CAAC,YAAY,CAAC,OAAO,EAAE,EAAE,CAAC;YACrD,IAAI,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC;gBACxB,GAAG,CAAC,QAAQ,CAAC;oBACZ,IAAI,EAAE,QAAQ;oBACd,IAAI,EAAE,CAAC,UAAU,EAAE,CAAC,EAAE,cAAc,EAAE,CAAC,EAAE,IAAI,CAAC;oBAC9C,OAAO,EAAE,6BAA6B,GAAG,CAAC,EAAE,YAAY;iBACxD,CAAC,CAAA;YACH,CAAC;YACD,MAAM,CAAC,GAAG,CAAC,GAAG,CAAC,EAAE,CAAC,CAAA;QACnB,CAAC;IACF,CAAC;AACF,CAAC,CAAC,CAAA;AAOF,mHAAmH;AACnH,MAAM,UAAU,uBAAuB,CAAC,IAAa;IACpD,OAAO,qBAAqB,CAAC,SAAS,CAAC,IAAI,CAAC,CAAA;AAC7C,CAAC;AAED,6EAA6E;AAC7E,qEAAqE;AACrE,iEAAiE;AACjE,MAAM,CAAC,MAAM,yBAAyB,GAAG,CAAC,CAAC,YAAY,CAAC,yBAAyB,CAAC,CAAA"}

package/dist/types/config.d.ts

@@ -403,11 +403,14 @@ export interface CiWatchConfig {
      */
     after_ship?: 'auto' | 'ask' | 'never';
     /**
-     * On all-green CI, auto-merge the PR via `gh pr merge --auto --squash`.
-     * Default `false` — the watcher prints a merge hint and leaves the merge
-     * decision to the user (matches the user's stated rhythm). Flip to `true`
-     * once a calendar week of clean post-launch usage shows zero false-green
-     * merges (D-08 kill criteria).
+     * On all-green CI, `/apt:watch-ci` merges the PR with a plain
+     * `gh pr merge --squash` — NEVER `gh pr merge --auto` (in a repo without
+     * required status checks `--auto` degrades to an immediate merge; the
+     * watcher's `allGreen` classifier is the gate, not GitHub branch
+     * protection). Default `false` — the watcher prints a merge hint and leaves
+     * the merge decision to the user (matches the user's stated rhythm). Flip to
+     * `true` once a calendar week of clean post-launch usage shows zero
+     * false-green merges (D-08 kill criteria).
      */
     auto_merge_on_green?: boolean;
 }