@ericrisco/rsc 4.0.0 → 4.0.2

package/skills/implement/scripts/task-brief

@@ -1,10 +1,13 @@
 #!/bin/sh
 # task-brief PLAN_FILE N
-# Extracts task number N from a plan/tasks markdown file into a brief file in the
-# sdd-workspace dir, and prints its path.
+# Extracts task N from a plan/tasks markdown file into a brief file in the sdd-workspace dir, and
+# prints its path. N may be written 2, 002 or T002: ids compare as numbers.
 #
-# A task starts at a heading matching: ### T<N> / ### T<N>( / ### T<N> — / ## T<N>
-# and ends just before the next ### T / ## heading.
+# Two task shapes are read, because `tasks` prescribes a table and older plans used headings:
+#   - a table row `| T002 | ... |` → the table's header, its separator and that row;
+#   - a heading `### T2 …` / `## T002 …` → the block up to the next ## / ### heading;
+#   - a bold block `**T002 — Interfaces**` → that line and what follows up to a blank line.
+# Both are printed when both exist (the row is the contract, the heading its detail).
 # If task N is not found, exits nonzero with a clear message.
 
 # Resolve the directory of this script portably.
@@ -13,7 +16,7 @@ _SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
 usage() {
   printf 'Usage: task-brief <PLAN_FILE> <N>\n' >&2
   printf '  PLAN_FILE  path to the tasks markdown file\n' >&2
-  printf '  N          task number to extract (e.g. 2 for T2)\n' >&2
+  printf '  N          task id to extract: 2, 002 or T002\n' >&2
   exit 1
 }
 
@@ -23,41 +26,52 @@ if [ $# -lt 2 ]; then
 fi
 
 PLAN_FILE="$1"
-N="$2"
+N="${2#T}"
+N="${N#t}"
 
 if [ ! -f "$PLAN_FILE" ]; then
   printf 'error: plan file not found: %s\n' "$PLAN_FILE" >&2
   exit 1
 fi
 
-# Validate N is a positive integer.
 case "$N" in
   ''|*[!0-9]*)
-    printf 'error: N must be a positive integer, got: %s\n' "$N" >&2
+    printf 'error: N must be a task number (2, 002 or T002), got: %s\n' "$2" >&2
     exit 1
     ;;
 esac
 
-# Use awk to extract the task block.
-# Match start: a heading line (## or ###) followed by T<N> then space, (, —, or end of line.
-# Match end: the next heading line starting with ## (which includes ###).
-# Exit code: 0 if found, 1 if not found.
 CONTENT="$(awk -v n="$N" '
-  BEGIN { printing=0; found=0 }
+  function idnum(s) { sub(/^[Tt]/, "", s); return s + 0 }
+  BEGIN { n = n + 0; printing = 0; bold = 0; found = 0; head = ""; sep = "" }
+  # Table rows: remember the latest header + separator, print the matching row.
+  /^\|/ {
+    split($0, cell, "|"); id = cell[2]; gsub(/[[:space:]]/, "", id)
+    if (id ~ /^[Tt][0-9]+$/) {
+      if (idnum(id) == n) { if (!printing) { if (head != "") print head; if (sep != "") print sep }; print; found = 1; next }
+    } else if ($0 ~ /^\|[-:| ]+\|[[:space:]]*$/) { sep = $0 }
+    else { head = $0; sep = "" }
+    if (!printing) next
+  }
+  # A bold block `**T004 — Interfaces**` (what `tasks` writes under the table): the line and every
+  # line after it up to the first blank one. It is the task-local contract an isolated worker needs.
+  bold && /^[[:space:]]*$/ { bold = 0 }
+  bold { print; next }
+  /^\*\*[Tt][0-9]+/ {
+    t = $0; sub(/^\*\*/, "", t); sub(/[^Tt0-9].*$/, "", t)
+    if (idnum(t) == n) { bold = 1; found = 1; print ""; print; next }
+  }
   /^#{2,3}[[:space:]]/ {
-    # Check if this heading is the target task T<n>
-    line=$0
-    pat="^#{2,3}[[:space:]]+T" n "([[:space:](]|[-]|$)"
-    if (match(line, pat)) {
-      printing=1; found=1; print; next
+    if (printing) { printing = 0 }
+    if (match($0, /^#{2,3}[[:space:]]+[Tt][0-9]+([[:space:](]|-|$)/)) {
+      t = $0; sub(/^#{2,3}[[:space:]]+/, "", t); sub(/[^Tt0-9].*$/, "", t)
+      if (idnum(t) == n) { printing = 1; found = 1; print ""; print; next }
     }
-    # Any other ## / ### heading stops printing
-    if (printing) { exit }
   }
   { if (printing) print }
   END { if (!found) exit 1 }
 ' "$PLAN_FILE")" || {
-  printf 'error: task T%s not found in %s\n' "$N" "$PLAN_FILE" >&2
+  printf 'error: task T%s not found in %s (looked for a "| T%s |" table row and a "### T%s" heading)\n' "$N" "$PLAN_FILE" "$N" "$N" >&2
   exit 1
 }
 
@@ -71,7 +85,8 @@ SCRATCH="$(sh "$_SCRIPT_DIR/sdd-workspace")"
 
 # Derive a readable unique name from the plan file basename and task number.
 PLAN_BASENAME="$(basename "$PLAN_FILE" .md)"
-OUT="$SCRATCH/brief-${PLAN_BASENAME}-T${N}.txt"
+NUM="$(printf %s "$N" | sed "s/^0*//")"
+OUT="$SCRATCH/brief-${PLAN_BASENAME}-T${NUM:-0}.txt"
 
 printf '%s\n' "$CONTENT" > "$OUT"
 printf '%s\n' "$OUT"

package/skills/plan/SKILL.md

@@ -85,7 +85,7 @@ Three of them carry the weight and fail quietly:
 
 Write `02-DOCS/wiki/sdd/plans/<slug>.md`, `<slug>` matching the spec's slug exactly — one plan per
 spec, same name, because that is how `tasks`, `analyze` and `implement` find it. Then index it in
-`02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a pointer). If a plan for
+`02-DOCS/wiki/index.md` (the Knowledge map) — never the root `CLAUDE.md`. If a plan for
 this slug already exists, update it in place and note what changed — never fork a `-v2`.
 
 ## Model tier — `heavy` (opt-in routing)

package/skills/plan/evals/cases.yaml

@@ -46,4 +46,4 @@ capability:
       - "Testing strategy maps each acceptance criterion to a test level (unit/contract/integration/e2e), states what each asserts and what it mocks (e.g. the payments provider), and defers the test runner/tooling to the stack skill"
       - "Risks section is ranked with trigger + impact + mitigation per risk (e.g. payments timeout, double-reservation race); does NOT claim zero risk"
       - "Stays stack-neutral above the seam — no framework route decorators, ORM session code, or test-runner flags in the plan"
-      - "Ends by pointing to the tasks phase and notes indexing the plan in the root CLAUDE.md Knowledge map"
+      - "Ends by pointing to the tasks phase and notes indexing the plan in 02-DOCS/wiki/index.md (the Knowledge map), never the root CLAUDE.md"

package/skills/plan/references/plan-template.md

@@ -145,8 +145,8 @@ unit / contract / integration / e2e. Tooling is the stack skill's job — name t
   defend it, not to enumerate every option without choosing.
 - **Empty section = defect.** Every one of the seven must say something real before `tasks` runs.
   If a section genuinely has no content (e.g. no migration), write "none — <why>", not silence.
-- **Index it.** After writing, add the plan to the root `CLAUDE.md` `## Knowledge map` so the
-  harness wiki and later phases can find it.
+- **Index it.** After writing, add the plan to `02-DOCS/wiki/index.md` (the Knowledge map) so the
+  harness wiki and later phases can find it. Never edit the root `CLAUDE.md` — that is `harness`'s, and tier 2.
 - **Global Constraints carry the verbatim values.** §0 is not a summary of §1 — §1 explains *which*
   constraints shape the design and *why*; §0 lists the exact values a blind implementer and the
   reviewer must honor. A value that lives only in prose ("use the project's naming rule") is a value

package/skills/review/SKILL.md

@@ -12,7 +12,7 @@ origin: risco
 Tests prove the code works, not that it does what was asked. Review answers that other question: **is the diff correct, well-scoped and faithful to the spec — or did it pass for the wrong reasons?** In ASDD (`../asdd/SKILL.md`) it runs in two modes:
 
 - **Per task** — called from `implement`'s loop after each task's self-check. Depth comes from `npx @ericrisco/rsc risk [--base <ref>] [paths…]` (same path table as the sello, works with the sello off): **tier 0** → no review; **tier 1** → one fresh-context reviewer (a subagent that never saw the implementation conversation); **tier 2** → the three-refuter panel below, and the branch will wait for human approval at ship.
-- **Closing review** — once, before `ship`: the whole branch against the spec. Forty individually-correct tasks can still fail to be the feature together: a criterion nobody owned, two tasks that each assumed the other handled an edge, scope that crept in a slice at a time. Read the spec's acceptance criteria and "must respect" list against `git diff <base>...HEAD`, not the task reviews.
+- **Closing review** — once, before `ship`: the whole branch against the spec. Forty individually-correct tasks can still fail to be the feature together: a criterion nobody owned, two tasks that each assumed the other handled an edge, scope that crept in a slice at a time. Read the spec's acceptance criteria and "must respect" list against `git diff <base>...HEAD`, not the task reviews. Its record — tier, counts, verdict, each finding with its outcome — goes to `02-DOCS/wiki/sdd/reviews/<slug>.md`.
 
 This skill owns **two roles that share one discipline**:
 
@@ -175,21 +175,28 @@ Two extra finding classes the four inputs unlock, neither reachable from a diff:
 report one defect three ways, and a lens hunting for something can overstate what it found. Two
 steps, in this order:
 
-1. **Group (deterministic).** Each lens ends its report with a ` ```json findings ` block. Save the
-   three reports and run `npx @ericrisco/rsc review consolidate <reports…>`. It merges findings on
-   the same file within 3 lines, or quoting the same evidence; keeps the highest severity and every
-   lens that saw it; and downgrades a blocker or should-fix with no `file:line` or failure scenario to
-   a question. Several lenses on one finding is a reason to look first, never a reason to raise its
-   severity.
-2. **Verify (judgement).** For each finding it marks `verify`, dispatch the **`finding-verifier`**
-   agent with that one finding plus the same four inputs, in parallel. It starts from "this is false"
-   and returns **CONFIRMED** (reproduced or traced, with the proof), **REFUTED** (cites the guard that
-   makes it impossible), or **UNPROVEN** (becomes a question). It never gets the lens's reasoning.
+1. **Group (deterministic).** Each lens ends its report with a ` ```json findings ` block — an
+   array of objects in exactly this shape (give it to every reviewer verbatim):
+
+   ```json
+   {"severity":"blocker|should-fix|nit|question","file":"path","line":N,"claim":"…","failure_scenario":"concrete input → wrong result","evidence":"quoted code","class":"bug class"}
+   ```
+
+   Save the reports and run `npx @ericrisco/rsc review consolidate <reports…>`. It merges findings
+   on the same place that say the same thing, or that quote the same evidence; keeps the highest
+   severity and every lens that saw it; and **downgrades a blocker or should-fix with no
+   `file:line` or no `failure_scenario` to a question**. Several lenses on one finding is a reason
+   to look first, never a reason to raise its severity.
+2. **Verify (judgement).** Consolidate marks `verify` on **every blocker and every should-fix**.
+   For each, dispatch the **`finding-verifier`** agent with that one finding plus the same four
+   inputs, in parallel. It starts from "this is false" and returns **CONFIRMED** (reproduced or
+   traced, with the proof), **REFUTED** (cites the guard that makes it impossible), or **UNPROVEN**
+   (becomes a question). It never gets the lens's reasoning.
 
 Report the consolidated count honestly ("11 reported → 4 unique → 2 confirmed"), and list what was
 refuted and why: a refuted finding hidden from the author is a review nobody can audit. At tier 1
-(one reviewer) there is nothing to group, but a blocker still goes to `finding-verifier` before it
-blocks.
+(one reviewer) there is nothing to group, but run `review consolidate` on its one report anyway:
+it applies the downgrade, and every blocker and should-fix still goes to `finding-verifier`.
 
 **A finding blocks only if it survives all three filters** — no exceptions, and eagerness to
 find something is not evidence:
@@ -213,9 +220,10 @@ A review loop that never converges is worse than none: Anthropic saw a single PR
 Four rules, enforced by `npx @ericrisco/rsc review ledger` (`.rsc/review-ledger.jsonl`) rather
 than by memory:
 
-1. **Max 3 rounds per task.** Start each round with `review ledger round <slug>/<task>`; it exits non-zero
-   on the 4th. That is not "try harder": rethink the approach, or park the task in the decision
-   queue and continue with independent work.
+1. **Max 3 rounds per task.** Call `review ledger round <slug>/<task>` before **every** review of
+   the task, the first included: round 1 is the task's first review, not its first fix. It exits
+   non-zero on the 4th. That is not "try harder": rethink the approach, or park the task in the
+   decision queue (a `blocking` entry) and continue with independent work.
 2. **From round 2, re-review only the new diff** — what changed since the last round, not the task
    again from scratch.
 3. **Flag the bug class, not the line.** "Every handler in this file trusts `req.params.id`" — so
@@ -225,9 +233,13 @@ than by memory:
    normalized title — comes back marked `repeat`; it is never re-raised as new. A repeat means the
    last fix missed the class, so say that instead.
 
-**Every finding closes with an outcome**: `review ledger outcome <id> fixed|false|intentional|irrelevant`.
-`review ledger stats` then shows totals per outcome, the false rate and mean rounds per task — the
-only way to tell whether a change to the reviewer made it better or worse.
+**Every finding closes with an outcome**: `review ledger outcome <id> fixed|false|intentional|irrelevant|parked`
+— `parked` when the finding's task went to the decision queue (neither fixed nor dismissed; a human
+decides). `review ledger stats` then shows totals per outcome, the false rate and mean rounds per
+task — the only way to tell whether a change to the reviewer made it better or worse.
+
+The ledger is **local**: it lives in `.rsc/` and is never committed, so it does not travel between
+machines or clones. What lasts is what you write from it — review-evals cases and rules (below).
 
 ---
 

package/skills/sdd-init/SKILL.md

@@ -2,7 +2,7 @@
 name: sdd-init
 description: "Use when calibrating an existing repo for the rsc SDD chain: detect stack, package manager, test runners and apply/verify commands, refresh the skill registry, and write the runtime config at 02-DOCS/wiki/sdd/config.yaml. NOT the dispatcher that routes SDD phases (that is `asdd`), NOT first-contact user/workspace bootstrap (that is `init`)."
 tags: [sdd, init, config, testing, registry]
-recommends: [sdd, specify, implement, verify]
+recommends: [asdd, constitution, specify, verify]
 profiles: [core, full]
 origin: risco
 ---
@@ -28,13 +28,15 @@ Read-only first:
 
 If `02-DOCS/` does not exist, create only the `02-DOCS/wiki/sdd/` path needed for the config. Do not run full harness scaffolding unless the user asked for `harness`.
 
+**Empty repo — nothing to detect?** Then there is nothing to calibrate yet: `constitution` runs first and decides the stack, and this skill calibrates against that decision (or re-runs once the first manifest exists). Never invent runners for an empty tree.
+
 ## Preflight Choices
 
 Ask only when the answer changes behavior; explain each trade-off in one line, in the register `technical_level` sets.
 
 | Setting | Default | Options |
 | --- | --- | --- |
-| `execution_mode` | `interactive` | `interactive` pauses at review-risk gates; `automatic` chains phases until a blocker/risk appears. |
+| `execution_mode` | `interactive` | `interactive` pauses at review-risk gates; `automatic` chains phases until a blocker/risk appears. `sdd.execution_mode: automatic` is the switch `asdd`'s autopilot reads. |
 | `artifact_store` | `02-DOCS/wiki/sdd` | Keep RSC artifacts in `02-DOCS`; do not create an `openspec/` parallel tree. |
 | `review_budget.line_budget` | `400` | Lower for solo tight review; higher only with explicit approval. |
 | `delivery_strategy.default` | `ask-on-risk` | `ask-on-risk`, `single-pr`, `autochain`, `exception`. |
@@ -158,7 +160,7 @@ End with the standard SDD result envelope:
   "status": "complete",
   "executive_summary": "SDD config calibrated and registry refreshed.",
   "artifact": "02-DOCS/wiki/sdd/config.yaml",
-  "next_recommended": "sdd",
+  "next_recommended": "constitution|specify",
   "risk": "low",
   "skill_resolution": {
     "used": ["sdd-init"],
@@ -186,4 +188,4 @@ End with the standard SDD result envelope:
 
 ## Next
 
-After `sdd-init`, return to `asdd`. If no spec exists, route to `specify`. If the work is ambiguous or architectural, write a proposal first under `02-DOCS/wiki/sdd/proposals/`.
+After `sdd-init`, return to `asdd` with `next_recommended` set to the next phase: `constitution` if there is none (or it is `status: draft`), else `specify` when no spec exists. If the work is ambiguous or architectural, write a proposal first under `02-DOCS/wiki/sdd/proposals/`.

package/skills/ship/SKILL.md

@@ -13,16 +13,16 @@ Ship is the **last step** of ASDD's closing stage (`../asdd/SKILL.md`), after th
 
 This skill owns one decision and its safe execution: **how does this work integrate?** It does not write code, run test gates, or read the diff for defects — those phases already happened. It is the **close, not the open**: creating the isolated branch or worktree is `../worktrees/SKILL.md`, taking the gates green is `../verify/SKILL.md`, reading the diff adversarially is `../review/SKILL.md`, and putting merged code onto a server is `../deployment/SKILL.md`.
 
-## The hard rule: git authorship is Eric, never Claude
+## The hard rule: git authorship is the responsible person, never an AI
 
-> **Every commit and every PR ships under Eric's name. No `Co-Authored-By: Claude`. No `Co-Authored-By` for any AI. No "🤖 Generated with Claude Code" footer. No "made by an agent" line in the PR body. Nothing that attributes the work to a tool.**
+> **Every commit and every PR ships under the name of the responsible person — the configured git user. No `Co-Authored-By: Claude`. No `Co-Authored-By` for any AI. No "🤖 Generated with Claude Code" footer. No "made by an agent" line in the PR body. Nothing that attributes the work to a tool.**
 
-This is absolute — not a preference to weigh against convenience — because a commit is a permanent, published claim about who wrote something. The work is Eric's; the agent is a tool he used, like an editor or a compiler, and you do not credit the compiler in the commit message. Once a forged trailer is pushed it is in everyone's history and only a rewrite removes it.
+This is absolute — not a preference to weigh against convenience — because a commit is a permanent, published claim about who wrote something. The work is the responsible person's; the agent is a tool they used, like an editor or a compiler, and you do not credit the compiler in the commit message. Once a forged trailer is pushed it is in everyone's history and only a rewrite removes it.
 
 Concretely, before any commit or PR:
 
-- **Never** pass `--author` to set a non-Eric author. The repo's configured `user.name` / `user.email` (Eric's) is the author and committer.
-- If `git config user.email` is unset or clearly not Eric's, **stop and ask** which identity to commit under — do not guess, and do not substitute an agent identity.
+- **Never** pass `--author` to set another author. The repo's configured `user.name` / `user.email` — the responsible person — is the author and committer.
+- If `git config user.email` is unset or is an agent/bot identity, **stop and ask** which identity to commit under — do not guess, and do not substitute an agent identity.
 - If you find a Claude/AI trailer in a commit you are about to push (e.g. left over from an upstream tool), **strip it** before the branch lands.
 
 Verify it after writing the commit. A non-empty match is a blocker: amend and re-check before the branch goes anywhere.
@@ -48,9 +48,9 @@ Run this before presenting the landing options. Any unchecked item is a stop —
 - [ ] **On a feature branch, not the trunk** — `git rev-parse --abbrev-ref HEAD` is not `main`/`master`. If work landed directly on the trunk, that is its own problem; flag it, don't paper over it.
 - [ ] **Rebased / up to date with the base, and tested there** — branch is on top of latest `main`; conflicts resolved locally, not punted to the merge; the checks re-ran on the rebased branch.
 - [ ] **Risk tier known** — `npx @ericrisco/rsc risk --base main` run; its tier, classes and `human approval` line go into the PR's Risk section.
-- [ ] **Decision queue empty** — no task parked for a human decision in this branch, or the PR says which ones remain.
+- [ ] **No `blocking` entry in the decision queue** (`## Decision queue` in `progress/<slug>.md`) — or the PR says which remain and it does not self-merge. `review-after` entries never block; they are listed in the PR body (or the parked summary) for the human.
 - [ ] **No secrets in the diff** — scan the staged/branch diff for keys, tokens, `.env` values (`git diff main... | grep -iE 'api[_-]?key|secret|password|token|BEGIN .*PRIVATE KEY'`). A hit is a blocker; remove it, and rotate it if it was ever pushed.
-- [ ] **Authorship is Eric** — `git config user.email` is Eric's; no AI trailer in any commit on the branch (run the grep above across `main..HEAD`).
+- [ ] **Authorship is the responsible person** — `git config user.email` is the configured human; no AI trailer in any commit on the branch (run the grep above across `main..HEAD`).
 - [ ] **Commit history is intelligible** — squashed or organized so the history reads as deliberate, not "wip wip fix fix".
 
 ```bash
@@ -58,7 +58,7 @@ Run this before presenting the landing options. Any unchecked item is a stop —
 echo "branch:   $(git rev-parse --abbrev-ref HEAD)"
 echo "clean?:   $([ -z "$(git status --short)" ] && echo yes || echo NO-dirty)"
 echo "behind:   $(git rev-list --count HEAD..origin/main 2>/dev/null || echo '?') commits behind origin/main"
-git log main..HEAD --format='%an <%ae>' | sort -u   # authors on this branch — expect only Eric
+git log main..HEAD --format='%an <%ae>' | sort -u   # authors on this branch — expect only the configured user
 git diff main...HEAD | grep -icE 'api[_-]?key|secret|password|token|BEGIN .*PRIVATE KEY' \
   | sed 's/^/secret-hits: /'
 npx @ericrisco/rsc risk --base main                 # tier, classes, reviewers, human approval
@@ -125,7 +125,13 @@ Stacked PR / feature-track support still fits inside the three landing options:
 
 ## Executing each option
 
-**Nothing below runs before the user picks an option.** Merging, pushing, opening a PR and deleting a branch are outward or irreversible — they change shared history or publish to a forge, and no later phase undoes them. A recommendation is not a yes; wait for one.
+**Nothing below runs before an option is picked.** Merging, pushing, opening a PR and deleting a branch are outward or irreversible — they change shared history or publish to a forge, and no later phase undoes them. Interactively, the user picks: a recommendation is not a yes; wait for one.
+
+**In autopilot** (the up-front yes, or `execution_mode: automatic` in `config.yaml`) the agent picks by these rules, and there is always a legal path:
+
+- **A remote exists** → option 2, the PR. Self-merge only when `rsc risk` says tier 0-1, CI is green and **no `blocking` entry** is open; otherwise leave the PR open for the human. List every `review-after` entry in the PR body.
+- **No remote** → option 3, **park**: leave the branch committed, write the explainer, the open queue entries and the exact merge command for the human (`git switch main && git merge --no-ff feature/<slug>`) into `progress/<slug>.md`, and stop.
+- **Never merge locally around the branch guard.** When `rsc main status` says `closed: true`, the guard denies a local merge — that is the signal to park, not to find another command. Autopilot never discards.
 
 ### Option 1 — direct merge
 
@@ -177,14 +183,15 @@ Implements `02-DOCS/wiki/sdd/specs/<slug>.md`. <the user-facing reason>
 ## Risk
 
 Tier <0|1|2> (`rsc risk`): <classes touched>. Human approval: <required|not required>.
+Decision queue: <open `blocking` entries, or none> · Review after: <each `review-after` entry, or none>.
 
 ## How to revert
 
 <`git revert <merge-sha>` / the squash commit; plus anything a revert alone does not undo — a migration, a flag, data written>
 ```
 
-**Merge policy — by risk tier.** Tier 0-1, CI green and the decision queue empty → you may
-self-merge (autopilot): `gh pr merge --squash --delete-branch` (or `--merge` to preserve the
+**Merge policy — by risk tier.** Tier 0-1, CI green and no `blocking` entry in the decision queue
+→ you may self-merge (autopilot): `gh pr merge --squash --delete-branch` (or `--merge` to preserve the
 history; squash when the branch history is noisy, preserve when each commit is meaningful). **Tier
 2 waits for human approval** — a human's approving review on the PR, or their explicit yes in the
 conversation. An agent's approval never counts as a human's: no refuter, reviewer subagent or bot
@@ -203,7 +210,7 @@ Never stack to hide review risk. Stack because each slice is independently revie
 
 ### Option 3 — park or discard
 
-- **Park:** leave the branch, push it so it's not lost (`git push -u origin feature/<slug>`), and log *why it's parked* to `02-DOCS/wiki/sdd/decisions.md`. Do not merge.
+- **Park:** leave the branch committed, push it if a remote exists (`git push -u origin feature/<slug>`), and log *why it's parked* to `02-DOCS/wiki/sdd/decisions.md`. Do not merge. A branch parked *ready to land* (autopilot, no remote) also gets its explainer, open queue entries and the exact merge command in `progress/<slug>.md`, so the human lands it with one command.
 - **Discard:** deletion is **destructive and unrecoverable** once the branch is gone from both sides, so it takes an explicit confirmation that quotes the branch name (the literal `yes, delete feature/<slug>`) before `git branch -D`. Anything ambiguous means keep it. Log the discard and the reason so the dead-end is remembered, not re-attempted.
 
 **Park and discard do NOT reap.** The cleanup default acts only on work that is already in the trunk;
@@ -216,7 +223,7 @@ reaper — it owns its own lifecycle and its tracking has to stay consistent.
 
 ## Commit message discipline
 
-The commit is the durable record. Make it describe the change and tie it to the spec — and keep it Eric's.
+The commit is the durable record. Make it describe the change and tie it to the spec — and keep it the responsible person's.
 
 - **Subject:** `<gitmoji> type: imperative summary (<spec-slug>)` — `✨ feat:`, `🐛 fix:`, `♻️ refactor:`, etc. Under ~72 chars. The gitmoji is **not optional**: on Claude Code a PreToolUse guard denies a `git commit -m` without one, and the refusal hands back the corrected message. Emoji → intention table: `../git-workflow/references/gitmoji.md`.
 - **Body:** *why*, not a restatement of the diff. Reference the spec slug and any decision logged in `decisions.md`.
@@ -224,23 +231,24 @@ The commit is the durable record. Make it describe the change and tie it to the
 
 ## Model tier — `light` (opt-in routing)
 
-Closing the branch (PR / merge / cleanup) is mechanical, so this phase's default tier is **`light`**. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`; when it is on, follow `../asdd/references/model-routing.md` for resolving and announcing the switch rather than from memory. Routing off or no profile → honor the session model silently, and skip routing on a one-line change. The Eric-only authorship rule is independent of the model and never relaxes.
+Closing the branch (PR / merge / cleanup) is mechanical, so this phase's default tier is **`light`**. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`; when it is on, follow `../asdd/references/model-routing.md` for resolving and announcing the switch rather than from memory. Routing off or no profile → honor the session model silently, and skip routing on a one-line change. The human-authorship rule is independent of the model and never relaxes.
 
 ## What ship shows
 
 Read `technical_level` from `02-DOCS/wiki/harness/user-profile.md`. It changes the words, **never** the safety checklist or the authorship rule. No profile → use analogies and proceed; don't stall the ship to ask.
 
-In the `orient` voice: the explainer, the checklist result in one line, the three options as one-liners, the recommendation and its *why*, then execute on a yes — e.g. `Clean, rebased, authorship Eric. Recommend PR (main is protected). Open it?`. For a `non-technical` owner, explain the recommended option with an analogy: a protected `main` wants a PR ("asking permission before changing the shared copy"). Explain fast-forward vs `--no-ff` or what squashing trades away only when asked.
+In the `orient` voice: the explainer, the checklist result in one line, the three options as one-liners, the recommendation and its *why*, then execute on a yes — e.g. `Clean, rebased, authorship <git user>. Recommend PR (main is protected). Open it?`. For a `non-technical` owner, explain the recommended option with an analogy: a protected `main` wants a PR ("asking permission before changing the shared copy"). Explain fast-forward vs `--no-ff` or what squashing trades away only when asked.
 
 ## Anti-patterns → STOP
 
 | Rationalization | Reality |
 | --- | --- |
-| "I'll add `Co-Authored-By: Claude` / a 'Generated with Claude Code' footer to be transparent" | It forges the record. The work is Eric's — no AI trailer, ever. Strip it. |
+| "I'll add `Co-Authored-By: Claude` / a 'Generated with Claude Code' footer to be transparent" | It forges the record. The work is the responsible person's — no AI trailer, ever. Strip it. |
 | "Review didn't formally approve but it's obviously fine" | No verdict = not ready. Ship runs on APPROVE only. Route back to review. |
 | "Tier 2, but the three refuters approved — I'll self-merge" | An agent's approval never counts as a human's. Tier 2 waits for human approval. |
 | "The tree has a couple of stray edits, they're harmless" | A dirty tree means the merge is not the reviewed diff. Clean it or stash it first. |
 | "`main` is protected but I'll just force-merge, I'm sure" | Protected means PR. Don't bypass the gate the repo deliberately set. |
+| "No remote and the guard denies the merge — I'll merge another way" | The denial is the answer. Park the branch with the merge command for the human. |
 | "I'll rebase and resolve conflicts during the merge" | Resolve before. A conflicted merge commit hides what actually shipped. |
 | "The gitmoji is decoration, the conventional type is what matters" | Both ship or neither does. The type is for tooling, the emoji for the human scanning `git log` — and the guard denies the commit either way. |
 | "This branch is dead, I'll just delete it" | Discard is destructive — confirm with the quoted branch name and log why first. |
@@ -252,7 +260,7 @@ In the `orient` voice: the explainer, the checklist result in one line, the thre
 Ship is mostly git actions, but the outcome is recorded so the knowledge model stays whole:
 
 - **The landing decision** (which of the three options, and why) → append to `02-DOCS/wiki/sdd/decisions.md`, the same append-only log `implement`, `verify`, and `review` write to. Parks and discards are logged with their reason so dead-ends aren't re-walked.
-- A **shipped feature** flips its spec under `02-DOCS/wiki/sdd/specs/<slug>.md` to a shipped state (note the merge commit / PR). The harness owns the wiki; ship just keeps the `sdd/` rows in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer) honest.
+- A **shipped feature** flips its spec under `02-DOCS/wiki/sdd/specs/<slug>.md` to a shipped state (note the merge commit / PR). The harness owns the wiki; ship just keeps the `sdd/` rows in `02-DOCS/wiki/index.md` (the Knowledge map) honest — never the root `CLAUDE.md`.
 - An **archive bundle** closes the loop under `02-DOCS/wiki/sdd/archive/<slug>/`:
   - `final-report.md` — what shipped, why, landing decision, links.
   - `apply-progress.md` — copy or link to `progress/<slug>.md`.

package/skills/specify/SKILL.md

@@ -125,7 +125,7 @@ Then they see an empty-cart message and the "pay" button is disabled
 
 A criterion that needs a human to "decide if it's good enough" is not done yet — sharpen it or move the soft part to *Points to clarify*.
 
-**Six of those sections are enforced, not suggested, each from its own date.** For a spec dated 2026-09-06 or later, `spec:gate` refuses the file if *Cost of not building it* or *The cheapest alternative* is missing or still holding the template's guidance; from 2026-11-03 it also refuses one missing any of the four ASDD questions — *What the user can do*, *What result they get*, *What it must respect*, *How it proves it* (Spanish headings accepted: *Qué podrá hacer el usuario*, *Qué resultado obtiene*, *Qué debe respetar*, *Cómo lo demuestra*). Specs written before each date are exempt — they cannot answer honestly after the fact. The first two ask whether the thing should exist at all, because every other gate compares artifacts to each other and a wrong-but-coherent spec passes all of them. The four make the spec something a long autonomous run can be checked against: tests prove the code works, not that it does what was asked.
+**Six of those sections are enforced, not suggested, each from its own date.** For a spec dated 2026-09-06 or later, `rsc spec gate` refuses the file if *Cost of not building it* or *The cheapest alternative* is missing or still holding the template's guidance; from 2026-11-03 it also refuses one missing any of the four ASDD questions — *What the user can do*, *What result they get*, *What it must respect*, *How it proves it* (Spanish headings accepted: *Qué podrá hacer el usuario*, *Qué resultado obtiene*, *Qué debe respetar*, *Cómo lo demuestra*). Specs written before each date are exempt — they cannot answer honestly after the fact. The first two ask whether the thing should exist at all, because every other gate compares artifacts to each other and a wrong-but-coherent spec passes all of them. The four make the spec something a long autonomous run can be checked against: tests prove the code works, not that it does what was asked.
 
 ### Points to clarify carry a type
 
@@ -193,13 +193,11 @@ property of the **file**, not of your confidence:
 > Every template section carries content or an explicit typed open point, and no section holds an
 > unmarked assumption.
 
-Run `npm run spec:gate <path>` on the spec you just wrote (no path: the whole corpus). It reports the
-missing and the empty sections by name, and it prints what it does **not** check — the unmarked
-assumption is yours to catch, because no parser can. A red gate means the spec is not closed: name
-the section that failed and fix it before step 9.
-
-A gate that has never been seen fail is not known to work, so this one ships with the test that
-watches it fail and pass (`tests/spec-gate.test.js`).
+Run `npx @ericrisco/rsc spec gate <path>` on the spec you just wrote (no path: every spec in the
+project's `02-DOCS/wiki/sdd/specs/`). It prints `PASS`/`FAIL` per file, reports the missing and the
+empty sections by name, exits non-zero on any `FAIL`, and prints what it does **not** check — the
+unmarked assumption is yours to catch, because no parser can. A red gate means the spec is not
+closed: name the section that failed and fix it before step 9.
 
 ### Fresh-eyes spec review (step 8, scaled to the stakes)
 
@@ -244,7 +242,11 @@ ask → user answers → fold it in → say what changed → show the revised sp
   **approved in autopilot, not item by item**, in the spec's `status:`. The spec then becomes the
   artifact the user reviews *after the fact*, and the work claims correspondingly less certainty
   about having captured their intent. Writing "aprobada" flat, when what happened was a blanket
-  go-ahead, is the record telling a small lie about the strongest gate in the chain.
+  go-ahead, is the record telling a small lie about the strongest gate in the chain. The same goes
+  for *What result they get*: with no human to approve a reference, write one that can be checked
+  mechanically (the expected transcript, response or output), and record it as a `review-after`
+  entry in the decision queue (`## Decision queue`, `02-DOCS/wiki/sdd/progress/<slug>.md`) — the
+  run continues, the human confirms the reference afterwards.
 - **Rejection is information — keep it.** If the user turns the spec down, revise it in place and
   append the reason to `## Revisions`. Never delete and start clean: what they rejected, and why,
   is the most useful thing in the file.

package/skills/specify/evals/cases.yaml

@@ -67,7 +67,7 @@ capability:
       - "Stays strictly WHAT/WHY: no framework, token format, database table, endpoint shape, email provider, library, or file path appears in the spec — implementation-laden answers are flagged as points to clarify instead of guessed."
       - "Produces the spec sections: Problem & why, Cost of not building it, The cheapest alternative, Goals, Non-goals / out of scope (including what an agent might add 'just in case'), Users & context, What the user can do, What result they get (against a human-approved reference), What it must respect (checked against the decisions log or the project's brain), How it proves it (what evidence remains), Behaviour (main + edge + error paths), Acceptance criteria, Points to clarify — and neither of the two doubt sections is left as a formality: 'Cost of not building it' names a concrete consequence, and 'The cheapest alternative' names something that would solve most of it without building this, plus why that is not enough."
       - "Writes testable acceptance criteria in Given/When/Then form that verify could later check (e.g. expired-link refusal, unknown-email revealing nothing)."
-      - "Writes the file to 02-DOCS/wiki/sdd/specs/<slug>.md (kebab-case slug), indexes it in the root CLAUDE.md Knowledge map under sdd/specs, and logs the spec creation to the canonical SDD decisions log at 02-DOCS/wiki/sdd/decisions.md."
+      - "Writes the file to 02-DOCS/wiki/sdd/specs/<slug>.md (kebab-case slug), indexes it in 02-DOCS/wiki/index.md under sdd/specs (never the root CLAUDE.md), and logs the spec creation to the canonical SDD decisions log at 02-DOCS/wiki/sdd/decisions.md."
       - "Lists honest Points to clarify as the handoff rather than inventing values, and TYPES each one (pregunta abierta / suposición tomada / decisión diferida / área no formulable) so clarify knows whether to ask it, validate it, or leave it alone; a suposición carries its basis."
       - "Ends by pointing to the clarify phase as the next step in the SDD chain."
 

package/skills/specify/references/eliciting-requirements.md

@@ -109,7 +109,7 @@ something `clarify` can validate instead of re-ask.
 ## When to stop
 
 Stop when the frontier is empty: every branch visited, nothing left silently
-assumed. Then run the exit gate (`npm run spec:gate <path>`) on the written
+assumed. Then run the exit gate (`npx @ericrisco/rsc spec gate <path>`) on the written
 file — the bound is a property of the artifact, not of your confidence.
 Lingering unknowns are fine, and belong in *Points to clarify*, typed. Over-asking to feel thorough is itself an anti-pattern: it burns the
 user's patience and pushes them to rubber-stamp answers they haven't thought

package/skills/specify/references/spec-template.md

@@ -98,7 +98,7 @@ costliest of the four.>
 - **Status** moves `draft` → `clarified` (after the `clarify` phase) → `planned`
   (once `plan` exists). Don't invent other states. An approval obtained as a
   blanket "just run it" is recorded as **approved in autopilot**, not flat.
-- **Before you call it written**, run `npm run spec:gate <path>`. It checks that
+- **Before you call it written**, run `npx @ericrisco/rsc spec gate <path>`. It checks that
   every section here carries content or an explicit open point, and prints the
   clauses it cannot check (the unmarked assumption is yours).
 - **The enforced sections are dated, not retroactive.** `Cost of not building

package/skills/tasks/evals/cases.yaml

@@ -71,5 +71,5 @@ capability:
       - "Orders by dependency (migration/schema → data → service → API), so no task precedes what it depends on; marks `[P]` only on file/state-disjoint tasks and defaults to sequential when unsure."
       - "Uses TDD-shaped slicing: a failing-test task before its implementation task, whose done-check is 'the test that was red is now green'."
       - "Checks coverage both ways: every task traces to a criterion and every criterion has a task; a task with no criterion is cut/flagged as scope creep (route to clarify/specify), and either gap is a defect analyze will flag."
-      - "Appends the table under a `## Tasks` heading INSIDE 02-DOCS/wiki/sdd/plans/auth.md (not a new file) and confirms the plan is indexed in the root CLAUDE.md Knowledge map under sdd/."
+      - "Appends the table under a `## Tasks` heading INSIDE 02-DOCS/wiki/sdd/plans/auth.md (not a new file) and confirms the plan is indexed in 02-DOCS/wiki/index.md under sdd/ (never the root CLAUDE.md)."
       - "Adds a final closer task gating on all done-checks passing plus `scripts/verify.sh` green, and hands off to `analyze` next (then implement) — not straight to implementation."

package/skills/verify/SKILL.md

@@ -41,7 +41,8 @@ omitted. A task with a control **not run** is not done; a closing record with on
 
 ```text
 LOCATE  → find the spec, the task done-checks, and which stack(s) changed
-RUN     → execute the relevant stack scripts/verify.sh (lint, type, test+coverage, audit)
+RUN     → execute the relevant stack scripts/verify.sh (lint, type, test+coverage, audit),
+          or the generic gate from config.yaml when no stack ships one
 WALK    → check every task done-check and every spec acceptance criterion against real output
 ROLLBACK→ write how to undo the change (revert sha, migration down, flag off) into the record
 RECORD  → write the verification record under 02-DOCS/wiki/sdd/, index it
@@ -91,7 +92,7 @@ Rules for RUN:
 - A `GAP` is the third thing, and it is the one that looks most like a pass: **the layer ran and had nothing to fail with.** The fastapi gate reports it when coverage runs with no `--cov-fail-under` configured; the Go gate reports it always, because `go test -cover` takes no threshold. The script deliberately does not fail on a GAP — that judgement is yours. **Treat a GAP as an unverified criterion, which fails the verdict**, and record it (see the mapping below). A gate that reports and a gate that checks are indistinguishable on screen, and only the broken one is guaranteed to stay green.
 - A non-zero exit from a tool that actually ran is a hard FAIL. Record the failing tool and its output.
 - Run from the directory the stack skill documents (Go runs from the module root; others from the subproject root). Don't guess paths.
-- If no `scripts/verify.sh` exists for a touched stack, that's a gap — say the gate is incomplete and recommend the user add the stack skill, rather than hand-rolling a one-off check that drifts from the real gate.
+- **No stack skill ships a `scripts/verify.sh` for this stack?** Run the **generic gate**: the test, lint, type, build and audit commands `sdd-init` recorded in `02-DOCS/wiki/sdd/config.yaml`, each recorded as pass, fail or **not run**. It is a full gate, not a lesser one. Procedure: `references/generic-gate.md`.
 
 #### A home-grown gate must prove it can fail — and that it can pass
 
@@ -106,7 +107,7 @@ The dangerous way a checker breaks is not a crash — it is **fail-open**: nothi
 
 **Over-blocking is not the safe side.** It feels like caution and it is not: a gate that fires on correct work gets muted, worked around, or wedges the pipeline that depends on it, which is the same damage as a gate that checks nothing with the sign reversed. And it is *harder* to notice, because the failure arrives dressed as diligence.
 
-Where this bites hardest is a check that matches text rather than structure — **"the path appears in the string" is not "the write targets that location"**. Our own integrity gate shipped that defect: twelve mutants proved it could fail, none asked whether it could pass. → `02-DOCS/wiki/harness/puertas-y-mecanismos.md`
+Where this bites hardest is a check that matches text rather than structure — **"the path appears in the string" is not "the write targets that location"**. Our own integrity gate shipped that defect: twelve mutants proved it could fail, none asked whether it could pass — and the first real run blocked every reading of a protected file as if it were a write to it.
 
 So when you write the negative control, write the positive one beside it, and prefer matching **structure** (a parsed tool call, a resolved path, an exit code) over matching text that happens to contain the thing you care about.
 
@@ -188,7 +189,7 @@ source_state: 3f9a1c2 (clean)
 
 **A dismissed finding carries evidence, one line each.** A fix is self-evidencing — the test now passes. A dismissal is not: "not a real problem" is indistinguishable from "did not check". Name the command, the `file:line`, or the test that disproves it, or write "ninguno".
 
-Append-only spirit: don't overwrite a prior run's record; a new run is a new dated file. The record is the receipt the `review` and `ship` phases trust.
+Append-only spirit: don't overwrite a prior run's record; a new run is a new dated file — a re-run on the same day writes `<slug>-YYYY-MM-DD-r2.md` (then `-r3`, …). The record is the receipt the `review` and `ship` phases trust.
 
 ### 5 — VERDICT
 

package/skills/verify/evals/cases.yaml

@@ -94,7 +94,7 @@ capability:
       - "Treats the mypy SKIP as UNVERIFIED rather than a pass, and does not let 'everything else was green' stand in for the skipped layer."
       - "WALKS all three done-checks and all three acceptance criteria, and catches that AC2/T2 (duplicate POST is a no-op) has NO test at all — the two named tests cover AC1 and AC3 only — marking it UNVERIFIED rather than passing it."
       - "Does NOT fix a failing test inline; if a check fails it records it and hands off to debug, and refuses to fix-then-claim."
-      - "RECORDS a dated verification file under 02-DOCS/wiki/sdd/verifications/ and indexes it in the root CLAUDE.md Knowledge map."
+      - "RECORDS a dated verification file under 02-DOCS/wiki/sdd/verifications/ and indexes it in 02-DOCS/wiki/index.md (never the root CLAUDE.md)."
       - "Returns a VERDICT that is PASS only if EVERY item has passing evidence; a single unverified acceptance criterion makes the whole verdict FAIL — and refuses to call it 'done' otherwise."
       - "On PASS, points to the review phase; on FAIL, routes failing checks to debug and missing coverage back to implement."
       - "Treats a coverage GAP (the layer ran with no threshold configured, so it could not have failed) as an unverified criterion that fails the verdict — not as a pass — and records it as SUSTITUIDA: a report in place of a gate, unable to detect coverage regressing."

package/skills/verify/references/generic-gate.md

@@ -0,0 +1,43 @@
+# Generic gate — when no stack skill ships `scripts/verify.sh`
+
+A project in a stack the catalog has no gate for (a plain Node CLI, a Rust crate, a shell tool) is
+still verified. The gate is the commands the project itself declares, as `sdd-init` recorded them.
+This is a first-class path, not a fallback to apologise for.
+
+## Where the commands come from
+
+`02-DOCS/wiki/sdd/config.yaml` → `testing.commands.verify` (and `testing.commands.apply` for the
+suite), filled by `sdd-init` from the manifests (`package.json` scripts, `Makefile`, `Cargo.toml`,
+`pyproject.toml`…). No config → run `sdd-init` first; do not pick commands from memory.
+
+## The five layers
+
+| Layer | What counts | Typical source |
+| --- | --- | --- |
+| test | the full suite | `npm test`, `cargo test`, `pytest` |
+| lint | the project's linter | `npm run lint`, `cargo clippy` |
+| type | the type checker | `tsc --noEmit`, `mypy` |
+| build | the build or compile | `npm run build`, `cargo build` |
+| audit | dependency vulnerabilities | `npm audit`, `cargo audit`, `pip-audit` |
+
+## Procedure
+
+1. List the five layers. For each, take the command from `config.yaml`; if it declares none, look
+   for one in the manifest and say where you found it.
+2. Run each command once, after the last edit, from the project root. Capture the exit code and the
+   relevant output verbatim.
+3. Record every layer as exactly one of:
+   - **pass** — the command ran and exited 0;
+   - **fail** — the command ran and exited non-zero (a hard FAIL of the verdict);
+   - **not run** — no command is declared or the tool is missing. Label it as `verify` does:
+     `NO-APLICA` (no such surface, e.g. no types in plain JS), `HERRAMIENTA-AUSENTE` (the surface
+     exists, nothing checked it).
+4. Write the layers under `## Stack gate` in the record, as `generic gate (config.yaml) → …`, one
+   line per layer, with the command that ran.
+
+## Rules that still apply
+
+- A `not run` layer whose surface exists fails the verdict, exactly like a SKIP in a stack script.
+- A command the project wrote (a custom check script) is a home-grown gate: watch it fail and pass
+  before trusting it.
+- Suggest a stack skill if one fits — but the generic gate is the verdict for this run.