@ericrisco/rsc 3.7.5 → 4.0.0

package/skills/suggest/SKILL.md

@@ -29,9 +29,9 @@ intent is ambiguous, ask one question and stay here — ambiguity slows the lane
 
 **You choose the lane; never hand that choice to the person.** Simple → **FTD**: one feature document
 in `02-DOCS` (intent, scope, checklist, evidence, next step), tasks checked off against observed proof.
-Big, or decisions that affect each other → **SDD**: enter the chain; the person approves the spec and
+Big, or decisions that affect each other → **ASDD**: enter the chain; the person approves the spec and
 clarify, then picks manual or autopilot. Say which and why in one line; switch if asked.
-→ `../ftd/SKILL.md` · `../sdd/SKILL.md`.
+→ `../ftd/SKILL.md` · `../asdd/SKILL.md`.
 
 **Where.** Default branch open (chosen at install, or nothing complex) → work on it, no branch
 question. Closed («ramas y PR», CI, team) → before each code change ask: this branch, a new one, or
@@ -40,9 +40,9 @@ question. Closed («ramas y PR», CI, team) → before each code change ask: thi
 Judge the **meaning**, not the wording: the trigger is semantic in any language. A bug fix restoring
 intended behaviour is `debug`. Autopilot consent covers a whole run — advance without re-asking.
 
-Lane's skill missing? Offer it (§2) first. SDD recorded as deferred in `.rsc.json`? Run
+Lane's skill missing? Offer it (§2) first. ASDD recorded as deferred in `.rsc.json`? Run
 `npx @ericrisco/rsc@latest reassess`; silent on `RSC_REASSESSMENT_NO_CHANGE`, and on new evidence
-show the plan command — SDD still needs a newly accepted plan id, never added silently.
+show the plan command — ASDD needs a newly accepted plan id, never added silently.
 
 ---
 

package/skills/tasks/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: tasks
-description: "Use when an approved plan needs slicing into an ordered task list before any code — the SDD `tasks` phase. Each row carries a literal done-check, dependencies, a parallel-safe marker and a spec trace, appended to the plan artifact. NOT writing the plan (that is `plan`), NOT the consistency gate (that is `analyze`), NOT executing the tasks (that is `implement`)."
-tags: [sdd, tasks, breakdown]
+description: "Use when an approved plan needs slicing into an ordered task list before any code — the `tasks` step of ASDD stage 3 (Plan). Each row carries the spec criterion it covers, a risk forecast (tier 0/1/2), a literal done-check, dependencies and a parallel-safe marker, appended to the plan artifact. NOT writing the plan (that is `plan`), NOT the consistency gate (that is `analyze`), NOT executing the tasks (that is `implement`)."
+tags: [asdd, sdd, tasks, breakdown]
 recommends: [analyze, implement]
 profiles: [core, full]
 origin: risco
@@ -28,7 +28,7 @@ appended to the plan it was built from.
 This phase's default tier is **`balanced`**: decomposing an approved plan is
 structured work, not architecture. Routing is off unless `models.enabled: true`
 in `02-DOCS/wiki/sdd/config.yaml`; when on, resolve the tier and apply it per
-`../sdd/references/model-routing.md`, which owns the resolution order and the
+`../asdd/references/model-routing.md`, which owns the resolution order and the
 announcement rules. Routing off or no profile → honor the session model silently.
 
 ## Read the harness profile first
@@ -45,8 +45,8 @@ You break down a **plan**, not an intent. Before slicing, confirm all three exis
 
 1. **The plan** — `02-DOCS/wiki/sdd/plans/<slug>.md`, written by the `plan`
    phase. It must contain the architecture, interfaces, and testing strategy.
-2. **The spec** — `02-DOCS/wiki/sdd/specs/<slug>.md`, so every task traces to a
-   requirement. A task with no spec line behind it is scope you are inventing.
+2. **The spec** — `02-DOCS/wiki/sdd/specs/<slug>.md`, so every task traces to an
+   acceptance criterion. A task with no criterion behind it is scope you are inventing.
 3. **The constitution** — `02-DOCS/wiki/sdd/constitution.md`, the non-negotiable
    bars (stack canon, quality gates) every task must respect.
 4. **The SDD config** — `02-DOCS/wiki/sdd/config.yaml`, if present. Use its
@@ -61,7 +61,7 @@ exact thing `analyze` will catch next, and you will have wasted the round trip.
 
 ## What makes a task well-formed
 
-Every task is one row. A row is well-formed only when all six fields hold:
+Every task is one row. A row is well-formed only when all seven fields hold:
 
 | Field | Rule |
 | --- | --- |
@@ -70,7 +70,12 @@ Every task is one row. A row is well-formed only when all six fields hold:
 | **Title** | One imperative verb + object. "Implement", "Add", "Wire", "Migrate" — not "Handle" or "Support". |
 | **Done-check** | The **literal** command or observation that proves done. Runnable, not a feeling. See below. |
 | **Depends-on** | The task IDs that must finish first, or `—` for none. Drives the ordering and the parallel markers. |
-| **Trace** | The spec section / acceptance criterion this task satisfies. Every task traces to one; if it can't, it's out of scope. |
+| **Trace** | The spec acceptance criterion this task covers (`AC3`). Every task traces to one; if it can't, it's out of scope. |
+| **Risk forecast** | Tier `0`/`1`/`2` from the paths the task expects to touch: `npx @ericrisco/rsc risk <expected paths…>`. Never guessed. |
+
+**Coverage runs both ways.** A criterion with no task, or a task with no criterion, is a defect
+`analyze` flags. The forecast budgets review; `implement` recomputes the tier on the task's actual
+diff, and that one wins.
 
 Put `[P]` (parallel-safe) in its own field only when the task shares **no files
 and no state** with another unblocked task. When in doubt, leave it blank — a
@@ -125,12 +130,12 @@ will execute.
    service → API → UI. A task never precedes what it depends on.
 4. MARK [P] only on tasks that share no files/state with another
    unblocked task. Default to sequential.
-5. TRACE each task back to a spec line. No trace → cut it (scope creep)
-   or send the gap to `clarify`/`specify`.
-6. ADD the cross-cutting closers: a final "all done-checks pass" task
-   and a "verify.sh green" task that hands off to `verify`.
-7. ADD a review workload + delivery forecast before implementation.
-8. APPEND the table to the plan artifact (see below). Do not start a
+5. TRACE each task to a spec criterion, and each criterion to ≥1 task.
+   No trace → cut it (scope creep) or send the gap to `clarify`/`specify`.
+6. FORECAST risk per task: `npx @ericrisco/rsc risk <expected paths…>`.
+7. ADD the closer: "all done-checks pass + verify.sh green" (stage 5).
+8. ADD a review workload + delivery forecast before implementation.
+9. APPEND the table to the plan artifact (see below). Do not start a
    new file; the list lives with the plan it came from.
 ```
 
@@ -160,14 +165,14 @@ delete a user's map entry.
 ## Tasks
 <!-- generated by tasks on 2026-06-01; IDs are stable, do not renumber -->
 
-| ID | [P] | Task | Done-check | Depends-on | Trace |
-| --- | --- | --- | --- | --- | --- |
-| T001 |  | Add `users` table migration | `alembic upgrade head` applies clean; `\d users` shows email UNIQUE | — | spec §3 Data |
-| T002 | [P] | Add `sessions` table migration | migration applies; FK to users present | T001 | spec §3 Data |
-| T003 |  | Write failing test for `POST /login` | `pytest tests/auth/test_login.py` fails: no route | T001 | spec §4 Auth |
-| T004 |  | Implement `POST /login` | T003 test green; bad pw → 401 | T003 | spec §4 Auth |
-| ... | ... | ... | ... | ... | ... |
-| T0NN |  | All done-checks pass + `verify.sh` green | every row above checked; `scripts/verify.sh` exits 0 | all | spec §Acceptance |
+| ID | [P] | Task | Done-check | Depends-on | Trace | Risk |
+| --- | --- | --- | --- | --- | --- | --- |
+| T001 |  | Add `users` table migration | `alembic upgrade head` applies clean; `\d users` shows email UNIQUE | — | AC1 | 2 |
+| T002 | [P] | Add `sessions` table migration | migration applies; FK to users present | T001 | AC2 | 2 |
+| T003 |  | Write failing test for `POST /login` | `pytest tests/auth/test_login.py` fails: no route | T001 | AC3 | 1 |
+| T004 |  | Implement `POST /login` | T003 test green; bad pw → 401 | T003 | AC3 | 2 |
+| ... | ... | ... | ... | ... | ... | ... |
+| T0NN |  | All done-checks pass + `verify.sh` green | every row above checked; `scripts/verify.sh` exits 0 | all | all ACs | — |
 ```
 
 ### Per-task Interfaces (for context-isolated implementers)
@@ -205,15 +210,13 @@ before a giant diff exists.
 | --- | --- | --- |
 | Estimated changed lines | <number or range> | based on task count + touched areas |
 | Files / areas | <count and names> | modules, migrations, UI, tests, docs |
-| Review risk | low / medium / high | complexity, cross-stack scope, security/data changes |
+| Risk | max tier; count of tier-2 tasks | tier 2 tasks need three refuters and park in the decision queue for the human |
 | Suggested delivery | single-pr / ask-on-risk / autochain / exception | matched to config.review_budget |
 ```
 
-Pick the delivery strategy from the forecast: tiny change → `single-pr`; estimated
-lines over `config.sdd.review_budget.line_budget` (default 400) → recommend
-splitting or `ask-on-risk`; many areas or cross-stack contracts touched →
-`autochain` or a feature-track branch. A deadline or emergency that justifies a
-large review is marked `exception` and requires explicit user approval later.
+Delivery: tiny → `single-pr`; over `config.sdd.review_budget.line_budget` (default
+400) → split or `ask-on-risk`; many areas or cross-stack contracts → `autochain`;
+`exception` (deadline, emergency) needs explicit user approval.
 
 ## Anti-patterns → STOP
 
@@ -223,9 +226,10 @@ large review is marked `exception` and requires explicit user approval later.
 | "Done-check: 'feature works'" | Not runnable, not evidence. Quote the literal test/command, or it's not a done-check. |
 | "One giant task: 'build the backend'" | Unverifiable, un-handoffable. Split until each slice has its own runnable check. |
 | "Mark everything `[P]` so it goes faster" | Shared files = merge collisions. `[P]` only when scope is truly disjoint. |
-| "This task has no spec line but we obviously need it" | That's scope creep wearing a hat. Trace it or cut it; if it's real, send it to `clarify`. |
+| "This task has no criterion but we obviously need it" | That's scope creep wearing a hat. Trace it or cut it; if it's real, send it to `clarify`. |
 | "The plan is thin here, I'll guess the slice" | `analyze` will reject the guess next phase. Tighten the plan first. |
 | "I'll start coding the easy task while I list the rest" | This phase writes zero runtime code. Implementation is `implement`. |
+| "Risk is obviously low, I'll write 0" | The tier comes from `rsc risk` on the paths, never from the agent's judgement. |
 | "Renumber the IDs so they're contiguous" | Downstream phases cite IDs. They're stable once written. Append, don't renumber. |
 
 ## Result envelope
@@ -243,19 +247,19 @@ End with:
     "used": ["tasks"],
     "missing": [],
     "fallback": [],
-    "compact_rules": ["Every task needs a runnable done-check.", "Forecast review load before implementation."]
+    "compact_rules": ["Every task needs a runnable done-check, a criterion trace and a risk forecast.", "Forecast review load before implementation."]
   },
   "evidence": ["task table appended", "review workload forecast appended"]
 }
 ```
 
-## Next in the SDD chain
+## Next in ASDD
 
 The task list is now the contract for the rest of the build. Hand off to
 **`analyze`** — the consistency gate that cross-checks constitution ↔ spec ↔ plan
-↔ **tasks** and surfaces orphan tasks and untraceable scope — and then to
-**`implement`**, which executes the list TDD-style, using `parallel` for the `[P]`
-tasks and `worktrees` for isolation.
+↔ **tasks** and flags uncovered criteria and untraced tasks — and then to
+**`implement`** (stage 4), which runs each task through its build–review–fix loop,
+using `parallel` for the `[P]` tasks and `worktrees` for isolation.
 
 Do not jump straight to `implement`. The whole point of writing a checkable list
 was to let `analyze` audit it cheaply *before* code exists.

package/skills/tasks/evals/README.md

@@ -20,7 +20,7 @@ human spot-check.
 Goal: the skill fires when it should and never on a near-miss.
 
 1. Configure an agent with the **full catalog of skill descriptions** available
-   for routing — the other rsc-sdd phases (`sdd`, `constitution`, `specify`,
+   for routing — the other rsc-sdd phases (`asdd`, `constitution`, `specify`,
    `clarify`, `plan`, `analyze`, `implement`, `verify`, `review`, `ship`,
    `debug`, `worktrees`, `parallel`) plus the stack/process skills (`fastapi`,
    `nextjs`, `go`, `postgresdb`, `flutter`, `harness`, …) — so routing competes

package/skills/tasks/evals/cases.yaml

@@ -66,10 +66,10 @@ capability:
     must_include:
       - "Confirms the inputs first: plan, spec, AND constitution must exist; if the plan were missing it would STOP and route to `plan` rather than slice from intent."
       - "Reads technical_level from 02-DOCS/wiki/harness/user-profile.md and picks the register; the table is complete either way, and the chat adds only one line of why-this-slicing plus the risky tasks."
-      - "Emits sequential zero-padded stable IDs (T001, T002… — no hyphen, GitHub Spec Kit canon) with the six well-formed fields: ID, a separate [P] marker field after the ID, imperative title, done-check, depends-on, and a trace to a spec section."
+      - "Emits sequential zero-padded stable IDs (T001, T002… — no hyphen, GitHub Spec Kit canon) with the seven well-formed fields: ID, a separate [P] marker field after the ID, imperative title, done-check, depends-on, a trace to the spec acceptance criterion it covers, and a risk forecast (tier 0/1/2 from `npx @ericrisco/rsc risk <expected paths>`, never guessed)."
       - "Every done-check is a LITERAL runnable command or checkable observation (e.g. `pytest tests/auth/test_login.py` green; `alembic upgrade head` applies; bad password → 401) — never 'login works'."
       - "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'."
-      - "Ensures every task traces to a spec line and cuts/flags any task with no trace as scope creep (route to clarify/specify), rather than inventing scope."
+      - "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/."
       - "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

@@ -1,7 +1,7 @@
 ---
 name: verify
-description: "Use when implementation is finished and about to be called done or merged — the rsc-sdd evidence gate: runs the stack's scripts/verify.sh (lint, type, test, audit), walks every task done-check and acceptance criterion, records a dated verdict. NOT judging the diff by eye (that is `review`, spec-less `code-review`), NOT diagnosis (that is `debug`)."
-tags: [sdd, verify, test]
+description: "Use when work is about to be called done — the ASDD evidence gate, in two modes: per task inside `implement`'s loop (tests, build, security, traceability) and at closing over the whole branch against main (stack scripts/verify.sh, every done-check and acceptance criterion, rollback plan, dated verdict). A check that did not execute is reported not run, never passed. NOT judging the diff by eye (that is `review`, spec-less `code-review`), NOT diagnosis (that is `debug`)."
+tags: [asdd, sdd, verify, test]
 recommends: [review]
 profiles: [core, full]
 origin: risco
@@ -9,7 +9,7 @@ origin: risco
 
 # verify — the evidence gate before "done"
 
-`verify` is the post-implementation **gate** in the rsc-sdd chain. Implementation just finished; nobody is allowed to call it *done*, *fixed*, *working*, or *ready to merge* until the evidence exists and has been read. This skill produces that evidence: it runs the project's real quality gate, walks every task's done-check and every acceptance criterion from the spec, and records the result. Pass or fail, the verdict is grounded in command output you actually saw — never in a hunch.
+`verify` is the evidence **gate** of ASDD. Nobody is allowed to call work *done*, *fixed*, *working*, or *ready to merge* until the evidence exists and has been read. This skill produces that evidence: it runs the project's real quality gate, walks every task's done-check and every acceptance criterion from the spec, and records the result. Pass or fail, the verdict is grounded in command output you actually saw — never in a hunch.
 
 The one rule everything else serves: **a claim of done is a claim about evidence. No evidence, no claim.** A green feeling is not green output.
 
@@ -19,7 +19,7 @@ Not this phase: still writing tests or production code → `../implement/SKILL.m
 
 ## Model tier — `balanced` (opt-in routing)
 
-This phase's default model tier is **`balanced`** — it runs the checks and interprets failures with judgment. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch in one line when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
+This phase's default model tier is **`balanced`** — it runs the checks and interprets failures with judgment. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../asdd/references/model-routing.md` — announce the switch in one line when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
 
 ## Read the room first (register)
 
@@ -27,12 +27,23 @@ Before running anything, read `technical_level` in `02-DOCS/wiki/harness/user-pr
 
 Report in the `orient` voice: pass/fail per gate, then one line of *why* per failing check, then what the user should decide next. For a `non-technical` reader, say what each failing check protects with an everyday analogy.
 
-## The gate (run in this order)
+## Two modes
+
+| Mode | When | Scope | Output |
+| --- | --- | --- | --- |
+| **Per task** | step e of `implement`'s loop, every tier | the task's diff: **tests** (affected suite), **build** (compile + types), **security** (stack audit; `../secure-coding/SKILL.md` on input/authz/secrets), **traceability** (every new behaviour traces to a spec criterion — untraced behaviour is a finding) | one line per control in the task's progress entry |
+| **Closing** | ASDD stage 5, once, before `review` and `ship` | the whole branch against main: merge main in (or rebase) and run the full gate below on the result | the dated record, with a rollback plan |
+
+**Both modes, one rule: a check that was not executed is listed as not run** — never as passed, never
+omitted. A task with a control **not run** is not done; a closing record with one is a FAIL.
+
+## The closing gate (run in this order)
 
 ```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)
 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
 VERDICT → PASS only if every item has passing evidence; otherwise FAIL with the gaps + handoff
 ```
@@ -46,10 +57,10 @@ Never collapse a step. Never write the verdict before RUN and WALK have produced
   non-trivial, mark that as a verification risk and recommend `sdd-init`.
 - Read the spec at `02-DOCS/wiki/sdd/specs/<slug>.md` for its **acceptance criteria**.
 - Read the plan/task list at `02-DOCS/wiki/sdd/plans/<slug>.md` for each task's **done-check**.
-- Read `02-DOCS/wiki/sdd/progress/<slug>.md` if present for apply evidence and
-  completed tasks. Missing progress does not automatically fail, but it is a
-  traceability gap to record.
-- Determine which subprojects/stacks the change touched (from `git status`/`git diff --name-only` and the manifests). That tells you *which* stack `verify.sh` to run — possibly more than one in a monorepo.
+- Read `02-DOCS/wiki/sdd/progress/<slug>.md` for apply evidence, per-task controls and the
+  `## Decision queue`. Missing progress is a traceability gap to record; parked tasks are listed
+  in the record, never counted as done.
+- Determine which subprojects/stacks the branch touched (from `git diff --name-only main...HEAD` and the manifests). That tells you *which* stack `verify.sh` to run — possibly more than one in a monorepo.
 - If the constitution exists (`02-DOCS/wiki/sdd/constitution.md`), note its quality bars (coverage floor, lint level) — they are part of the gate.
 
 If the spec or task list is missing, stop: there is nothing to verify against. Say so and point back up the chain.
@@ -95,7 +106,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 learned this twice in one day: it flagged a transcript that merely *named* a protected path (the skill body it had been handed named it), then flagged a sandbox directory whose path *contained* the protected one as a substring. Twelve mutants had proven it could fail; not one had asked whether it could pass, so the defect shipped and surfaced on first real use with the filesystem provably untouched. → `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. → `02-DOCS/wiki/harness/puertas-y-mecanismos.md`
 
 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.
 
@@ -138,6 +149,9 @@ source_state: 3f9a1c2 (clean)
 - [x] AC1 user can place an order — evidence: e2e test green
 - [ ] AC3 duplicate submit is a no-op — UNVERIFIED: no observable proof
 
+## Rollback plan
+- `git revert <merge sha>`; migration `0042` has a tested down step; no flag involved.
+
 ## Capas no ejecutadas
 - **NO-APLICA** — mutation: no logic module changed, only templates.
 - **HERRAMIENTA-AUSENTE** — mypy: not installed in this environment; verify.sh printed SKIP and **nothing ran in its place**.
@@ -153,7 +167,7 @@ source_state: 3f9a1c2 (clean)
 
 **All numbers come from one fresh run made after the last edit.** A figure from mid-task is stale and does not go in the record, however true it was when you saw it.
 
-**Split "didn't run" three ways**, because one `SKIP` list collapses three different confidence claims and they read identically:
+**Every not-run check is listed, labelled.** Split "didn't run" three ways, because one `SKIP` list collapses three different confidence claims and they read identically:
 
 | Label | Means | Reader should conclude |
 |---|---|---|
@@ -178,7 +192,7 @@ Append-only spirit: don't overwrite a prior run's record; a new run is a new dat
 
 ### 5 — VERDICT
 
-- **PASS** only when *every* stack gate that ran is green (no FAILs), *every* task done-check is met with evidence, and *every* acceptance criterion has observable proof. Then, and only then, say it's verified — and point to `review`.
+- **PASS** only when *every* stack gate ran green (none **not run** but `NO-APLICA`), *every* task done-check is met with evidence, *every* acceptance criterion has observable proof, and the rollback plan is written. Then, and only then, say it's verified — and point to `review`. Parked tasks don't block the verdict; they travel to the human with it.
 - **FAIL** the moment any item lacks passing evidence. List the open items precisely (which check, which criterion, what's missing). Do not soften it. A single unverified acceptance criterion fails the whole gate.
 - Hand each failing kind to the right place: a failing test/type error → `debug`; a missing test for a criterion → back to `implement`; a spec ambiguity that surfaced → `clarify`.
 
@@ -187,7 +201,8 @@ Append-only spirit: don't overwrite a prior run's record; a new run is a new dat
 | Anti-pattern | Why it fails / fix |
 | --- | --- |
 | "The tests passed last run, I'll trust that." | Re-run now. Code changed since; stale green is not green. Evidence is current, or it isn't evidence. |
-| "verify.sh printed SKIP for the tests — close enough." | A SKIP is *unverified*, not passing. The criterion it covers is still open until a real run passes. |
+| "verify.sh printed SKIP for the tests — close enough." | A SKIP is **not run**, not passing. The criterion it covers is still open until a real run passes. |
+| "The security audit didn't run, but the task is clearly fine." | List it **not run**. The task is not done until it runs or the human accepts the gap. |
 | "I read the code and the criterion is obviously satisfied." | Reading is `review`. Verifying needs an observable result — a test, a response, a rendered page. |
 | "Lint and types are green, so it's done." | The stack gate proves clean code, not correct behavior. Walk the acceptance criteria too. |
 | "Coverage dipped below the floor but the feature works." | The constitution's coverage bar is part of the gate. Below floor = FAIL, not a footnote. |
@@ -220,9 +235,9 @@ End with:
 }
 ```
 
-## Next in the chain
+## Next in ASDD
 
-A **PASS** record is the entry ticket to the next phase: **`../review/SKILL.md`** (adversarial read of the diff for what the gate can't catch), then **`../ship/SKILL.md`** (PR/merge). A **FAIL** routes back per the VERDICT step. Either way the verification record under `02-DOCS/wiki/sdd/verifications/` travels with the work as its proof.
+Per-task mode returns to `implement`'s loop (step f). A closing **PASS** record is the entry ticket to **`../review/SKILL.md`** (whole-branch adversarial read against the spec), then **`../ship/SKILL.md`** (PR with Testing / Risk / How to revert). A **FAIL** routes back per the VERDICT step. Either way the verification record under `02-DOCS/wiki/sdd/verifications/` travels with the work as its proof.
 
 ## Orientación (siempre)
 

package/skills/verify/evals/README.md

@@ -1,6 +1,6 @@
 # Eval harness — `verify` skill
 
-`verify` is the rsc-sdd post-implementation **gate**. These evals check two
+`verify` is the ASDD evidence **gate** (per task and at closing). These evals check two
 things: that it **triggers** at the right moment (someone is about to claim
 "done"/"green"/"ready to merge") and stays quiet on near-misses, and that it
 **measurably changes the behavior** — running the real stack gate, walking the
@@ -28,7 +28,7 @@ pure shell runner.
 Goal: the skill fires when a "done" claim is imminent and never on a near-miss.
 
 1. Configure an agent with the **full catalog of skill descriptions** available
-   for routing (verify + the rsc-sdd phase skills it chains to — implement,
+   for routing (verify + the ASDD phase skills it chains to — implement,
    debug, review, clarify, ship — plus the stack/process skills: fastapi, go,
    nextjs, flutter, postgresdb, secure-coding, deployment, harness, init) so
    routing competes realistically.

package/skills/verify/evals/cases.yaml

@@ -101,4 +101,5 @@ capability:
       - "Before trusting any home-grown gate that reports green, asks for it to be watched failing on a known-bad input, and states the limit: one negative control proves one bad case reaches the failure path, not that the gate covers the rule it claims to enforce."
       - "Splits layers that did not run into NO-APLICA / HERRAMIENTA-AUSENTE / SUSTITUIDA rather than one undifferentiated SKIP list, and never writes SUSTITUIDA as a pass."
       - "Binds the record to a source state (short commit SHA plus clean/dirty) and takes every number from one fresh run made after the last edit, refusing to reuse mid-task figures."
+      - "Lists every check that did not execute (the mypy SKIP) as 'not run', never as passed, and writes a rollback plan into the closing record."
       - "Gives any dismissed finding its own evidence line (command, file:line, or the test that disproves it) rather than asserting it was not a real problem."

package/skills/worktrees/SKILL.md

@@ -184,7 +184,7 @@ a linked worktree (`git rev-parse --git-dir` ≠ `--git-common-dir`), rule out a
 
 ## Model tier — `light` (opt-in routing)
 
-This phase's default model tier is **`light`** — isolating the workspace is mechanical git work. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../sdd/references/model-routing.md` — announce the switch in one line when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
+This phase's default model tier is **`light`** — isolating the workspace is mechanical git work. Routing is **off** unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`. When on: resolve this phase's tier (`models.overrides` wins over `models.phases`), map it to a model via `models.tiers`, and apply per `../asdd/references/model-routing.md` — announce the switch in one line when it differs from the session model, and dispatch any `Task`/`parallel` subagents on that model. Routing off or no profile → honor the session model silently. Never fake a switch a tool can't make; skip routing on a one-line change.
 
 ## Talking about it
 

package/targets/clone-bootstrap.mjs

@@ -95,7 +95,7 @@ export function readManifest(root) {
   const ids = (v) => (Array.isArray(v) ? v.filter((x) => typeof x === 'string' && ID.test(x)) : []);
   // Retired skills read as their successors. Canonical map: scripts/lib/retired-skills.js — inlined
   // because this file cannot import anything, and tests/retired-skills.test.js holds the two equal.
-  const RETIRED = { eli5: 'orient', 'show-me': 'orient', bro: 'unslop', 'design-loop': 'design', 'design-dna': 'design', 'motion-craft': 'design', 'ui-engineering': 'ux' };
+  const RETIRED = { eli5: 'orient', 'show-me': 'orient', bro: 'unslop', 'design-loop': 'design', 'design-dna': 'design', 'motion-craft': 'design', 'ui-engineering': 'ux', sdd: 'asdd' };
   const skills = [...new Set(ids(parsed.skills).map((id) => (Object.hasOwn(RETIRED, id) ? RETIRED[id] : id)))];
   const own = ids(parsed.ownSkills);
   // A manifest with nothing declared is not a clone waiting to be equipped; there is nothing to offer.

package/targets/hook-once.mjs

@@ -97,10 +97,10 @@ Reply in the person's language, not this text's.
   question and stay read-only; ambiguity slows the lane, it never raises it.
 - Authorises a change? YOU pick the lane, say it and why: simple -> FTD (one
   feature document, tasks checked off against observed proof); big or
-  interlocking decisions -> SDD (spec + clarify approved, then autopilot or not).
+  interlocking decisions -> ASDD (spec + clarify approved, review in every task).
 - Code change: the line below says where it goes in this project. Never open
   a branch on your own. Another session here: .worktrees/<branch>.
-Method: \`ftd\` · chain: \`sdd\` · full decisor in the always-on \`suggest\` body.
+Method: \`ftd\` · chain: \`asdd\` · full decisor in the always-on \`suggest\` body.
 =================================================
 `;
 

package/targets/sello.mjs

@@ -42,7 +42,7 @@ import { spawnSync } from 'node:child_process';
 // with no switch to stop it, so leaving it out made the lockout permanent.
 export const SELLO_STATE_PATHS = [
   '.rsc/sello.json', '.rsc/sello-config.json', '.rsc/sello-findings.md', '.rsc/sello-log.jsonl',
-  '.rsc/automation-gaps.md',
+  '.rsc/automation-gaps.md', '.rsc/review-ledger.jsonl',
 ];
 
 export function selloPaths(root) {