@ericrisco/rsc 3.7.4 → 4.0.0

package/skills/specify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: specify
-description: "Use when a feature, change, or product idea is still fuzzy and must become an approved WHAT/WHY spec before any planning or code — the brainstorming front door of SDD. Turns a one-line intent into problem, goals, users, scope, behaviour and acceptance criteria, via frontier-round dialogue and 2-3 approaches with a recommendation, carrying zero implementation detail. Fires whenever someone jumps to HOW before WHAT is agreed, in any language. NOT the technical plan (that is `plan`), NOT the de-risking ambiguity sweep (that is `clarify`), NOT project-wide principles (that is `constitution`)."
+description: "Use when a feature, change, or product idea is still fuzzy and must become an approved WHAT/WHY spec before any planning or code — the brainstorming front door of ASDD stage 2 (Spec). Turns a one-line intent into problem, goals, users, out-of-scope, the four ASDD questions (what the user can do, what result they get, what it must respect, how it proves it) and acceptance criteria, via frontier-round dialogue and 2-3 approaches with a recommendation, carrying zero implementation detail. Fires whenever someone jumps to HOW before WHAT is agreed, in any language. NOT the technical plan (that is `plan`), NOT the de-risking ambiguity sweep (that is `clarify`), NOT project-wide principles (that is `constitution`)."
 tags: [sdd, spec, requirements]
 recommends: [clarify, plan]
 profiles: [core, full]
@@ -9,7 +9,7 @@ origin: risco
 
 # Specify — intent becomes a spec
 
-This is the **specify** phase of the rsc-sdd chain: `constitution` → **`specify`** → `clarify` → `plan` → `tasks` → `analyze` → `implement` → `verify` → `review` → `ship`. Its single job is to turn a fuzzy intent into a written specification that states **WHAT** the change is and **WHY** it matters — and nothing about **HOW** it gets built.
+This is the drafting half of ASDD stage 2, **Spec** (`../asdd/SKILL.md`): **`specify`** writes the draft → `clarify` hunts its gaps → the human approves. Its single job is to turn a fuzzy intent into a written specification that states **WHAT** the change is and **WHY** it matters — and nothing about **HOW** it gets built.
 
 A spec is a contract about behaviour and outcomes, readable by a non-technical stakeholder and precise enough that a `plan` can be derived from it. The output is one file: `02-DOCS/wiki/sdd/specs/<slug>.md`, indexed in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer).
 
@@ -40,7 +40,7 @@ If, having looked, there is no real objection, **say so in one line and move on
 **Offer autopilot once, right here.** At this boundary, propose how to run the rest of the chain:
 > *"¿Quieres que lo lleve hasta el final yo solo — spec → plan → código → verify, parando solo si algo es ambiguo — o prefieres que pare a que apruebes en cada fase?"*
 
-A **yes engages autopilot** (`../sdd/SKILL.md`): you still write the spec and every artifact, but you auto-advance through the phases without re-asking — that up-front yes is the approval that satisfies the hard gate above, for the whole run. A **no** (or silence) keeps the default gated flow: write the spec, hand to `clarify`/`plan`, stop for approval before code. Either way the spec gets written; autopilot only changes whether you pause *between* phases — and it still stops for genuine ambiguity, hard failures, or destructive/outward actions (ship still confirms). If `sdd.autopilot: true` in config, autopilot is the default — still surface it once.
+A **yes engages autopilot** (`../asdd/SKILL.md`): you still write the spec and every artifact, but you auto-advance through the phases without re-asking — that up-front yes is the approval that satisfies the hard gate above, for the whole run. A **no** (or silence) keeps the default gated flow: write the spec, hand to `clarify`/`plan`, stop for approval before code. Either way the spec gets written; autopilot only changes whether you pause *between* phases — and it still stops for genuine ambiguity, hard failures, or destructive/outward actions (ship still confirms). If `sdd.autopilot: true` in config, autopilot is the default — still surface it once.
 
 ## The one rule that defines this skill
 
@@ -52,7 +52,7 @@ If you cannot state a requirement without naming the technology, that is a real
 
 ## Model tier — `balanced` (opt-in routing)
 
-This phase's default model tier is **`balanced`** — it drafts the what/why spec through dialogue, not architecture. 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 drafts the what/why spec through dialogue, not architecture. 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)
 
@@ -103,8 +103,12 @@ Write these sections into `02-DOCS/wiki/sdd/specs/<slug>.md` using `references/s
 | Cost of not building it | What concretely happens if nobody does this, and what it costs | Softening a genuinely small cost — "not much" IS the finding |
 | The cheapest alternative | What would solve most of it without building this, and why that is not enough | "Nothing" — there is always a manual workaround or a smaller version |
 | Goals | What success delivers, in outcome terms | A "goal" that's actually a HOW |
-| Non-goals / out of scope | What is explicitly NOT done now — adjacent work, deferred features | Silence — unsaid scope becomes assumed scope |
+| Non-goals / out of scope | What is explicitly NOT done now — adjacent work, deferred features, and what an agent could add "just in case" (the dropped token, the QR nobody asked for) | Silence — unsaid scope becomes assumed scope, and a long run fills it |
 | Users & context | Who acts, their context, what they're trying to achieve | An imagined user no one asked for |
+| What the user can do | The action, its starting conditions, who is allowed to do it | A capability with no actor or no precondition |
+| What result they get | The observable result against a reference the **human approved**: a screenshot or sketch for UI, the expected response for an API | An agent judging that two screenshots "look alike" — that is not a reference |
+| What it must respect | Constraints and prior behaviour that must keep working. Consult the project's brain if it has one, otherwise `02-DOCS/wiki/sdd/decisions.md` and existing specs, so the spec never steps on a prior decision | A constraint you remember but did not look up |
+| How it proves it | How the check runs and what evidence remains afterwards | "Yes, I tested it" — that is a claim, not evidence |
 | Behaviour | What the system does, in observable terms, incl. main + edge + error paths | A verb that's actually a HOW ("queries", "caches") |
 | Acceptance criteria | Testable, binary checks that say "done" | Vague critera ("works well", "is fast") |
 | Points to clarify | The typed handoff to `clarify` — see the four types below | An untyped list, or pretending there are none |
@@ -121,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*.
 
-**Two of those sections are enforced, not suggested.** 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. Specs written before that date are exempt — they cannot answer honestly after the fact. The two exist because every other gate in the chain compares artifacts to each other, so a spec that is wrong-but-coherent passes all of them; these are the only two lines that ask whether the thing should exist at all.
+**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.
 
 ### Points to clarify carry a type
 
@@ -155,7 +159,8 @@ saves you work.
 Run these in order. It is a collaborative dialogue, not a form you fill in silence — and **you do not skip to a design dump.** Track the steps with a todo list so none is dropped.
 
 ```text
-1. EXPLORE context        → profile + sdd config + constitution + existing specs + wiki + recent git
+1. EXPLORE context        → profile + sdd config + constitution + existing specs + decisions log (or the
+                            project's brain) + wiki + recent git
 2. SCOPE check            → if the request is several independent subsystems, DECOMPOSE into sub-specs first,
                             then brainstorm the FIRST one; each gets its own spec → plan → build cycle
 3. RESTATE + OBJECT     → one sentence of what you understood, plus the strongest objection you can
@@ -268,10 +273,25 @@ drop-off, because the friction is the password itself, not the reset.
 ## Non-goals / out of scope
 - Social login (Google/Apple) — deferred.
 - Replacing existing sessions for already-signed-in users.
+- A QR code to sign in from another device — nobody asked for it.
 
 ## Users & context
 A returning user on a new device who does not remember a password.
 
+## What the user can do
+Any registered user, signed out, can request a link to their own email.
+
+## What result they get
+The sign-in screen matches the approved sketch (linked); following the link
+lands them signed in on the page they started from.
+
+## What it must respect
+Existing sessions keep working; the decisions log says unknown emails reveal nothing.
+
+## How it proves it
+An end-to-end check per acceptance criterion; its run log and a screenshot of
+the signed-in page stay in the verification file.
+
 ## Behaviour
 - Main: user enters email → receives a link → following it signs them in.
 - Edge: an expired link shows a "request a new link" path.
@@ -296,28 +316,7 @@ Note what is *absent*: no token format, no table, no email provider, no framewor
 
 ## Optional proposal / pre-execution briefing
 
-For a tiny feature, skip this. For ambiguous, architectural, high-risk, high-review-cost or research-heavy work, write a proposal before the spec:
-
-```text
-02-DOCS/wiki/sdd/proposals/<slug>.md
-```
-
-Proposal grammar:
-
-```markdown
-# Proposal — <slug>
-
-## Problem
-## Intent
-## Scope / Non-scope
-## Research input
-## Alternatives considered
-## Tradeoffs
-## Risks
-## Rollback
-## Success criteria
-## Recommendation
-```
+For a tiny feature, skip this. For ambiguous, architectural, high-risk, high-review-cost or research-heavy work, write `02-DOCS/wiki/sdd/proposals/<slug>.md` before the spec, with these sections: Problem · Intent · Scope / Non-scope · Research input · Alternatives considered · Tradeoffs · Risks · Rollback · Success criteria · Recommendation.
 
 The proposal is allowed to mention options and tradeoffs; the spec that follows still stays WHAT/WHY. If research came from a transcript, doc, spike, or external briefing, cite it in `Research input` so the decision trail survives the chat.
 
@@ -333,7 +332,7 @@ repeated here as prohibitions: naming a behaviour makes it more available, not l
 | Name a framework, table, endpoint, or library | That's HOW. Strip it; describe the behaviour instead, or log the open question. |
 | Write "it should work well / be fast / be intuitive" | Not testable. Make it a binary Given/When/Then or move it to Points to clarify. |
 | Hand to `plan`/`implement` before the user approved the written spec | The approval at step 9 is the gate. No design approved → nothing gets built. |
-| Skip non-goals because "it's obvious" | Unsaid scope becomes assumed scope. State what you are *not* doing. |
+| Skip non-goals because "it's obvious" | Unsaid scope becomes assumed scope. State what you are *not* doing, including what an agent would add "just in case". |
 | Resolve every ambiguity yourself to look finished | Inventing answers is worse than naming gaps. List them in Points to clarify. |
 | Start designing the solution because it's clearer | Stay on WHAT/WHY. The plan is a later, separate phase. |
 | Write the spec somewhere other than 02-DOCS/wiki/sdd/specs/ | That's the canonical location the rest of the chain reads. Use it. |
@@ -370,11 +369,11 @@ End with:
 
 ## Next in the chain
 
-A spec is the input to **`clarify`**, not the finish line. End by pointing there:
+A spec is the input to **`clarify`**, not the finish line — both are ASDD stage 2 (**Spec**), which closes only when the human approves. End by pointing there:
 
-> "Spec written to `02-DOCS/wiki/sdd/specs/<slug>.md` with N open points. Next: run **`clarify`** to resolve them and de-risk the spec before planning."
+> "Spec written to `02-DOCS/wiki/sdd/specs/<slug>.md` with N open points. ASDD stage 2 (Spec) continues: run **`clarify`** to hunt its gaps before the human approves and `plan` starts."
 
-If `clarify` surfaces answers, they get baked back into this same spec file. Only once the spec is de-risked does `plan` derive the technical approach.
+If `clarify` surfaces answers, they get baked back into this same spec file. Only once the spec is de-risked and approved does stage 3 (`plan`) derive the technical approach.
 
 ## See Also
 

package/skills/specify/evals/cases.yaml

@@ -65,7 +65,7 @@ capability:
     must_include:
       - "Reads technical_level from 02-DOCS/wiki/harness/user-profile.md and the constitution first, inferring everything it can before asking, then asks only contract-changing gaps — the whole FRONTIER in one numbered round, each with its recommendation, and nothing whose answer depends on another question open in that same round."
       - "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, Users & context, 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."
+      - "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."
       - "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."

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

@@ -41,13 +41,33 @@ version, or doing nothing. Required for specs dated 2026-09-06 or later.>
 
 ## Non-goals / out of scope
 - <What is explicitly NOT done in THIS change — adjacent features, deferred
-  work, things a reader might assume are included. Be explicit, not silent:
-  unsaid scope becomes assumed scope.>
+  work, things a reader might assume are included, and what an agent could be
+  tempted to add "just in case" (a feature nobody asked for). Be explicit, not
+  silent: unsaid scope becomes assumed scope.>
 
 ## Users & context
 <Who acts, the situation they're in, and what they're trying to achieve.
 Real users from the constitution/wiki, not invented personas.>
 
+## What the user can do
+<The action, the starting conditions it needs, and who is (and is not)
+allowed to do it. Required for specs dated 2026-11-03 or later.>
+
+## What result they get
+<The observable result, against a reference the human approved: a screenshot
+or sketch for UI, the expected response for an API. An agent's own judgement
+that two screenshots "look alike" is not a reference. Required from 2026-11-03.>
+
+## What it must respect
+<Constraints and prior behaviour that must keep working. Look them up in the
+project's brain if it has one, otherwise in 02-DOCS/wiki/sdd/decisions.md and
+the existing specs, so this spec never steps on a prior decision. Required from
+2026-11-03.>
+
+## How it proves it
+<How the check runs and what evidence remains afterwards. "Yes, I tested it" is
+not evidence. Required from 2026-11-03.>
+
 ## Behaviour
 - Main path: <what the system does, observably, in the common case>
 - Edge cases: <empty, maximum, boundary, concurrent, repeated…>
@@ -81,10 +101,12 @@ costliest of the four.>
 - **Before you call it written**, run `npm run 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 two doubt sections are dated, not retroactive.** `Cost of not building
+- **The enforced sections are dated, not retroactive.** `Cost of not building
   it` and `The cheapest alternative` are required only for specs whose
-  frontmatter `timestamp` is `2026-09-06` or later. Specs written before that
-  are exempt — they cannot answer honestly after the fact, and a gate that turns
+  frontmatter `timestamp` is `2026-09-06` or later; the four ASDD questions
+  (`What the user can do`, `What result they get`, `What it must respect`, `How
+  it proves it`, or their Spanish headings) from `2026-11-03`. Specs written
+  before are exempt — they cannot answer honestly after the fact, and a gate that turns
   the whole corpus red is a gate that gets switched off. A spec with no readable
   `timestamp` falls on the exempt side too.
 - **Sharpness, not difficulty**, sorts the last two types from the first: *can

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.