@ericrisco/rsc 3.7.5 → 4.0.1

package/skills/clarify/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: clarify
-description: "Use when a spec exists and must be de-risked before planning — hunt its ambiguities, unstated assumptions and edge cases, ask the few build-changing questions, bake the answers back into the spec. The rsc SDD gate between `specify` (writes the spec) and `plan` (designs the build). NOT the cross-artifact consistency check (that is `analyze`)."
+description: "Use when a spec exists and must be de-risked before planning — run the gap checklist over its four ASDD questions and out-of-scope, ask only what changes what gets built (one question at a time, recommendation first), record every other call as an assumption, bake the answers back into the spec. The second half of ASDD stage 2 (Spec), between `specify` (writes the spec) and `plan` (designs the build). NOT the cross-artifact consistency check (that is `analyze`)."
 tags: [sdd, clarify, questions]
 recommends: [plan]
 profiles: [core, full]
@@ -11,19 +11,20 @@ origin: risco
 
 A spec written in one sitting always lies a little. It states what the author *thought of*, and stays silent on everything they didn't — the edge cases, the unstated defaults, the words that mean two things. Those silences don't disappear; they get discovered later, mid-implementation, where they cost ten times as much to fix. **Clarify is the gate that drags those silences into the open while they are still cheap.**
 
-This is the fourth phase of the rsc SDD chain (`constitution` → `specify` → **`clarify`** → `plan` → `tasks` → `analyze` → `implement` → `verify` → `review` → `ship`); the method itself lives in `../sdd/SKILL.md`. `specify` turned a fuzzy intent into a spec; clarify interrogates that spec, asks the user the questions that actually change the build, and writes the answers back so the spec becomes safe to plan from. It produces **no new artifact** — it sharpens the existing one in place. The line is **specify creates, clarify de-risks, plan designs**: if you find yourself proposing how to *build* it, you have left clarify.
+This is the second half of ASDD stage 2, **Spec** (`../asdd/SKILL.md`): `specify` drafts → **`clarify`** hunts the gaps → answers go into the spec → the human approves. It produces **no new artifact** — it sharpens the existing spec in place. The line is **specify creates, clarify de-risks, plan designs**: if you find yourself proposing how to *build* it, you have left clarify.
 
-**Model tier: `balanced`** — this phase ranks and asks the few high-leverage questions, it does not design architecture. Resolve and apply it per `../sdd/references/model-routing.md`; routing is off unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`.
+**Model tier: `balanced`** — this phase finds and asks the few questions that matter, it does not design architecture. Resolve and apply it per `../asdd/references/model-routing.md`; routing is off unless `models.enabled: true` in `02-DOCS/wiki/sdd/config.yaml`.
 
-**Register.** Read `technical_level` from `02-DOCS/wiki/harness/user-profile.md` (the `02-DOCS/wiki/` convention is owned by `../harness/SKILL.md`). Clarify is question-heavy, so the voice matters here more than almost anywhere. Ask only the questions whose answer changes the build; propose safe defaults for everything else and list them as "assumed unless you object". Each question carries one line of *why* and the trade-off behind each option, in the `orient` voice. For a `non-technical` reader, frame each option with an everyday analogy. With no profile: use analogies and ask once "technical or with analogies?".
+**Register.** Read `technical_level` from `02-DOCS/wiki/harness/user-profile.md` (the `02-DOCS/wiki/` convention is owned by `../harness/SKILL.md`). Clarify is question-heavy, so the voice matters here more than almost anywhere. Each question carries one line of *why* and the trade-off behind each option, in the `orient` voice. For a `non-technical` reader, frame each option with an everyday analogy. With no profile: use analogies and ask once "technical or with analogies?".
 
 ## Read first — the inputs
 
-Clarify never works blind. Before asking a single question, load three things:
+Clarify never works blind. Before asking a single question, load:
 
 1. **The spec.** Read the target spec under `02-DOCS/wiki/sdd/specs/<slug>.md` end to end. If the path wasn't given, find the most recently touched spec or ask which one. Its *Points to clarify* is a **typed** handoff, not a question list — read the types before you plan a single question (below).
 2. **The constitution.** Read `02-DOCS/wiki/sdd/constitution.md` if it exists. Its principles (stack canon, quality bars, conventions) resolve a surprising number of "ambiguities" without bothering the user — if the constitution already fixes the auth method or the data region, that's answered, not open.
-3. **The harness profile.** `02-DOCS/wiki/harness/user-profile.md`, for the register above.
+3. **What was already decided.** The project's brain if it has one; otherwise `02-DOCS/wiki/sdd/decisions.md` and the sibling specs. *What it must respect* is checked against these, not against memory.
+4. **The harness profile.** `02-DOCS/wiki/harness/user-profile.md`, for the register above.
 
 Citing what you read ("checked the constitution — auth is already fixed to OAuth, so that's not an open question") shows your work and prevents re-litigating settled decisions.
 
@@ -36,7 +37,7 @@ deliberately deferred:
 | Type in the spec | What it means | Your action |
 | --- | --- | --- |
 | **pregunta abierta** | Formulable, unanswered | Ask it — this is your queue |
-| **suposición tomada** | `specify` decided it; the basis is written | **Validate**, don't re-ask: state the assumption and its basis back, and ask only whether it still holds |
+| **suposición tomada** | `specify` (or you) decided it; the basis is written | **Validate**, don't re-ask: state the assumption and its basis back, and ask only whether it still holds |
 | **decisión diferida** | Sharp, out of this cycle on purpose | Leave it. Do not reopen scope the author closed |
 | **área no formulable** | Known to be coming, not yet phrasable | Note it. If your pass sharpens it into a real question, it graduates — say that it did |
 
@@ -51,94 +52,97 @@ the way through.
 Sharpness, not difficulty, is what separates a question from an unformulable area: *can you state it
 precisely now?* Not *can you answer it?*
 
-## The ambiguity taxonomy — where specs hide their gaps
+## The gap checklist — where specs hide their gaps
 
-Scan the spec against these categories. Most real gaps fall into one of them; walking the list is how you find the ones the author didn't think to write down.
+Walk the spec's four ASDD questions and its out-of-scope against this **gap checklist**, one row at a time. Most real gaps sit in one of these cells; walking every row is how you find the ones the author didn't think to write down.
 
-| Category | What to hunt | Tell-tale phrasing in the spec |
-| --- | --- | --- |
-| **Underspecified behavior** | A described feature with a missing branch — what happens in the *other* case | "the user logs in" (and if it fails? locked out? wrong password vs no account?) |
-| **Unstated assumptions** | Defaults the author assumed everyone shares | no mention of auth, tenancy, currency, timezone, locale |
-| **Edge & boundary cases** | Empty, zero, max, duplicate, concurrent, first-run, offline | lists with no empty-state, counts with no upper bound |
-| **Ambiguous terms** | A word doing two jobs | "user" (end-user or admin?), "delete" (soft or hard?), "fast" (how fast?) |
-| **Missing acceptance criteria** | A goal with no observable done-condition | "should be performant", "easy to use", "handle errors gracefully" |
-| **Scope edges** | What's explicitly OUT vs left dangling | features hinted at but never bounded — "for now", "eventually" |
-| **Data & state** | Lifecycle, ownership, retention, migration of existing data | new entity with no story for what happens to old records |
-| **Failure & recovery** | What happens when a dependency is down, a write half-completes, input is hostile | happy-path-only flows |
-| **Non-functional** | Performance, scale, security, accessibility, i18n targets | vague "non-functional requirements" or none at all |
-| **Actors & permissions** | Who can do each thing | a verb with no subject — "can be edited" (by whom?) |
-
-You are not filling every cell for every spec. You are scanning all ten so the gaps that *do* exist surface instead of hiding.
+| Spec section | Hunt for |
+| --- | --- |
+| **What the user can do** | Who can and who can't (a verb with no subject — "can be edited", by whom?); what happens if the starting conditions fail; ambiguous terms ("user": end-user or admin?) |
+| **What result they get** | Is there an approved reference (screenshot, sketch, expected response) — or only the agent's own judgement? Empty, error and loading states; boundaries (zero, max, duplicate, concurrent, first run) |
+| **What it must respect** | Does it contradict a recorded decision or spec? What current behaviour must not break? Data already there (lifecycle, ownership, migration); security, accessibility, performance floors |
+| **How it proves it** | Any criterion that cannot be checked ("fast", "easy", "handles errors gracefully"); what evidence remains after the check runs |
+| **Out of scope** | Anything the agent might add "just in case" — a feature nobody asked for; hints left dangling ("for now", "eventually") |
+
+On an older spec without the four sections, walk the same rows against *Behaviour* and *Acceptance criteria*.
 
 ## The pass — five steps
 
 Run in order. The discipline is: find many candidate gaps, keep only the ones that change the build, ask those well, write the answers back.
 
-1. **Inventory.** Walk the spec against the taxonomy above. Produce a raw list of every candidate ambiguity, edge case, and unstated assumption. Over-collect here; you'll prune next. Note for each which category it is and where in the spec it lives.
+1. **Inventory.** Walk the spec against the gap checklist. Produce a raw list of every candidate gap. Over-collect here; you'll prune next. Note for each its row and where in the spec it lives.
 
-2. **Resolve what you already can.** For each candidate, check the constitution and the spec's own later sections before asking the user. Many "gaps" are answered elsewhere. Mark each candidate **resolved-internally** (cite the source), **inferable** (a safe default you'll propose, not silently assume), or **must-ask** (only the user can decide).
+2. **Resolve what you already can.** Check each candidate against the constitution, the decisions and the spec's own later sections before asking. Many "gaps" are answered elsewhere — cite the source.
 
-3. **Rank by leverage.** Sort the must-ask list by impact: how much does the build change depending on the answer? A question whose two answers lead to two different architectures ranks above a cosmetic one. Cut low-leverage questions — clarify is not an interrogation, it's the *few* questions that matter.
+3. **Filter.** Ask only if the answer **changes what gets built**: two answers that lead to the same build are not a question. Everything that fails the filter, pick the most reasonable option yourself and record it in the spec's *Points to clarify* as a **suposición tomada**, with its basis — so the human sees every assumption in one block at approval instead of discovering them in the code. A silent default is an unrecorded decision; a recorded one is a cheap thing to veto.
 
-4. **Ask — one focused batch.** How you ask determines whether you get a usable answer:
-   - **Make it a decision, not an essay prompt.** "Should deletes be soft (recoverable, hidden) or hard (gone immediately)? I'd recommend soft because the spec mentions an audit trail — confirm?" beats "How should deletion work?".
-   - **Carry your own recommendation** when there's a defensible default, matched to the constitution. The user confirms or overrides — far less effort than authoring from scratch.
-   - **Quote the spec.** Anchor each question to the exact line or section it came from, so the user sees *why* it's open.
-   - **One batch, ranked, then stop.** Don't drip questions one at a time over many turns; don't dump thirty at once. Then wait: never ask and answer in the same breath, and never assume the user's intent on a must-ask item.
+4. **Ask — one question at a time, recommendation first.** Most important first. Each question is a decision, not an essay prompt, and leads with the answer you recommend so a "yes" suffices: "I'd make deletes soft (recoverable, hidden), because the spec mentions an audit trail — OK?" beats "How should deletion work?". Quote the spec line it came from. Wait for the answer, fold it in, then decide whether the next question still passes the filter — an answer often settles the next one. Never ask and answer in the same breath.
 
 5. **Bake the answers back into the spec.** This is the deliverable — an un-baked answer is a lost answer. For each resolved item, edit the spec in place:
-   - Tighten the relevant section with the decided behavior.
+   - Tighten the relevant section with the decided behaviour.
    - Add or sharpen acceptance criteria so the decision is now observable.
    - Append a `## Clarifications` log to the spec: dated entries of `Q → decision → why`, so the *reasoning* survives, not just the result.
-   - Move anything explicitly dropped into an `## Out of scope` section so it's bounded, not dangling.
+   - Move anything explicitly dropped into *Non-goals / out of scope* so it's bounded, not dangling.
+
+   Then re-read the spec once more: did resolving one gap open a new one? If so, one more short loop. Otherwise, hand it to the human for approval.
+
+## In autopilot — nobody to ask
+
+Under an up-front autopilot yes there is no one to answer, so step 4 changes: **every question that
+would have been asked is recorded instead** as a **suposición tomada** in the spec (your recommended
+answer, its basis, the spec line it came from) and mirrored as a `review-after` entry in the
+**decision queue** (`## Decision queue` in `02-DOCS/wiki/sdd/progress/<slug>.md`; create it if
+absent). The run continues; the human reviews these afterwards and nothing waits on them. Only a gap
+that would make the build **unsafe**, or whose answer would **contradict a recorded decision**, is a
+`blocking` entry — and only `blocking` stops the branch from merging itself. Never ask and wait in
+autopilot; never stay silent about what you assumed.
+
+## Late gaps — found during implementation
 
-   Then re-read the spec once more: did resolving one gap open a new one? If so, one more short loop. Otherwise, the gate is passed.
+A gap nobody saw until `implement` is running does not stop the run. It goes to the **decision queue** of `implement`'s per-task loop (`../implement/SKILL.md`): the task that needs the answer is parked, independent tasks continue, and when the human answers, the answer is written back into this spec (and its `## Clarifications` log) so the spec stays the contract.
 
 ## Worked micro-example
 
 Spec line: *"Users can upload a profile photo."*
 
-Clarify's inventory against the taxonomy:
+Inventory against the gap checklist:
 
 ```text
-- Ambiguous term  : "photo" — which formats? (PNG/JPG/HEIC/SVG?)
-- Boundary        : max file size? max dimensions? what if it's 50 MB?
-- Edge case       : no photo uploaded — is there a default/placeholder?
-- Failure         : upload fails mid-transfer — retry, or lose it?
-- Data lifecycle  : replacing a photo — is the old file deleted or orphaned?
-- Actors          : can an admin change another user's photo?
-- Non-functional  : is the image resized/compressed server-side? stored where?
-- Security        : is the file type validated, or can someone upload an .svg with script?
+- Can do      : can an admin change another user's photo? what if the user is signed out?
+- Result      : which formats? max size? no photo yet — placeholder? upload fails midway — retry?
+- Respect     : replacing a photo — old file deleted or orphaned? decisions log fixes storage
+- Proves it   : "accepts photos" cannot be checked — which file proves rejection of a 50 MB one?
+- Out of scope: cropping and filters — an agent could add them "just in case"
 ```
 
-Resolved-internally (cite): constitution fixes storage to the project's object store → "stored where" is answered. Must-ask, ranked: formats + max size (changes validation and UX), security validation (changes the upload path), old-file deletion (changes data model). Cosmetic placeholder choice → propose a default, don't burn a question on it.
+Resolved (cited): the decisions log fixes storage. Changes what gets built, asked one at a time: formats + max size, then old-file deletion. Fails the filter: placeholder image → **suposición tomada** (generic avatar). Cropping → *Out of scope*.
 
-After baking back, the spec line becomes a bounded, testable behavior with acceptance criteria ("rejects files >5 MB with a clear message", "accepts PNG/JPG/HEIC only", "replacing a photo deletes the prior file") and a `## Clarifications` entry recording why.
+After baking back, the spec line becomes a bounded, testable behaviour ("rejects files >5 MB with a clear message", "accepts PNG/JPG/HEIC only", "replacing a photo deletes the prior file") with a `## Clarifications` entry recording why.
 
 ## Anti-patterns
 
 | Anti-pattern | Why it breaks the gate / do instead |
 | --- | --- |
-| Skipping clarify because the spec "reads clear enough" | Clear to the author ≠ unambiguous. Run the taxonomy; the gaps you can't see are exactly the expensive ones. |
-| Assuming the sensible default and moving on | An assumption is an unrecorded decision. Either it's resolvable from the constitution (cite it) or it's a must-ask. Silent defaults resurface as bugs — and "the user is busy" is not an exception; a wrong guess costs more than a one-tap question. |
+| Skipping clarify because the spec "reads clear enough" | Clear to the author ≠ unambiguous. Walk the checklist; the gaps you can't see are exactly the expensive ones. |
+| Assuming a default and not writing it down | An unrecorded default resurfaces as a bug. Record it as **suposición tomada** with its basis, so the human vetoes it at approval. |
 | Sketching how you'd build it while you're in there | That's `plan`. Clarify decides *what*, not *how*. Proposing architecture means you left the gate. |
-| Asking everything you can think of, to be safe | Thirty questions is noise that buries the three that matter. Rank by leverage, ask the few, default the rest — and batch them once instead of dripping one per turn. |
+| Asking everything you can think of, to be safe | Thirty questions bury the three that matter. Only what changes what gets built is asked; the rest is assumed and listed. |
 | Answering the questions in your head and leaving the spec as-is | The deliverable is the *edited spec* plus the Clarifications log, not a clean conscience. |
 | Leaving edge cases "to the implementer" | Edge cases are *spec* problems. Resolving them now is the whole point of the gate. |
 
 ## Exit gate
 
-The gate is passed when the spec, constitution and profile were all read (settled questions cited, not re-asked); **every typed point in the handoff has its declared outcome** (asked / validated / left deferred / graduated), with nothing silently dropped; all ten taxonomy categories were considered; only the build-changing gaps were put to the user, as one ranked batch of decisions with recommendations; every answer is baked into the spec body with observable acceptance criteria, logged under `## Clarifications` and bounded under `## Out of scope`; and the final re-read opened no new gap.
+The gate is passed when the spec, constitution, prior decisions and profile were all read (settled questions cited, not re-asked); **every typed point in the handoff has its declared outcome** (asked / validated / left deferred / graduated), with nothing silently dropped; every gap checklist row was walked; only questions that change what gets built were asked, one at a time with a recommendation (in autopilot: recorded as assumptions with their `review-after` / `blocking` queue entries); every other call is a **suposición tomada** in the spec; every answer is baked into the spec body with observable acceptance criteria, logged under `## Clarifications` and bounded under out of scope; and the final re-read opened no new gap.
 
 ## Result envelope
 
 End with the parseable block every SDD phase shares, so the dispatcher can chain without
-interpreting prose (contract: `../sdd/SKILL.md`):
+interpreting prose (contract: `../asdd/SKILL.md`):
 
 ```json result-envelope
 {
   "status": "complete|blocked|failed",
-  "executive_summary": "Open points resolved; the spec is de-risked and ready to plan against.",
+  "executive_summary": "Open points resolved; the spec is de-risked and ready for approval and plan.",
   "artifact": "02-DOCS/wiki/sdd/specs/<slug>.md",
   "next_recommended": "plan",
   "risk": "low|medium|high",
@@ -146,16 +150,16 @@ interpreting prose (contract: `../sdd/SKILL.md`):
     "used": ["clarify"],
     "missing": [],
     "fallback": [],
-    "compact_rules": ["Ask only what changes the spec.", "An unanswered question is recorded, never invented."]
+    "compact_rules": ["Ask only what changes what gets built.", "Every other call is a recorded suposición tomada."]
   },
-  "evidence": ["answers folded back into the spec", "remaining open points listed with their owner"]
+  "evidence": ["answers folded back into the spec", "assumptions listed as suposición tomada", "remaining open points listed with their owner"]
 }
 ```
 
 ## Next in the chain
 
-Hand off to **`plan`** — turn the now-sharp spec into a technical implementation plan (architecture, interfaces, data flow, testing strategy, risks), deferring stack specifics to the relevant stack skill. The chain continues: clarify → **plan** → tasks → analyze → implement → verify → review → ship. `debug` is callable any time if what you are "clarifying" turns out to be a runtime fault, not a spec gap.
+Stage 2 closes when the human approves the spec (or the up-front autopilot yes covers it). Then hand off to **`plan`**, ASDD stage 3 (`plan` + `tasks` + `analyze`) — turn the now-sharp spec into a technical plan, deferring stack specifics to the relevant stack skill. `debug` is callable any time if what you are "clarifying" turns out to be a runtime fault, not a spec gap.
 
 ## Orientación (siempre)
 
-Habla con la voz de `orient`: frases cortas, una idea por frase, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)
+Habla con la voz de `orient`: frases cortas, una idea por frase, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)

package/skills/clarify/evals/cases.yaml

@@ -54,18 +54,17 @@ should_not_trigger:
     why: "Establishing project-wide principles is the constitution phase; clarify reads the constitution but does not author it."
 
 # Capability scenario with a rubric to grade WITH vs WITHOUT the skill loaded.
-# A skill-guided pass walks the taxonomy, resolves what the constitution already
-# fixes, ranks by leverage, asks as decisions, and bakes answers back with a
+# A skill-guided pass walks the gap checklist, resolves what the constitution already
+# fixes, asks only what changes the build, records the rest as assumptions, and bakes answers back with a
 # Clarifications log. An ungrounded pass typically free-associates a few
 # questions and never edits the spec or records the reasoning.
 capability:
   - scenario: "We have a spec at 02-DOCS/wiki/sdd/specs/profile.md whose only line about photos is 'Users can upload a profile photo.' De-risk it before we plan."
     must_include:
       - "Reads the spec, the constitution (02-DOCS/wiki/sdd/constitution.md), and the harness profile first — citing anything the constitution already fixes (e.g. storage) as resolved rather than re-asking it."
-      - "Scans against the ambiguity taxonomy and surfaces concrete gaps: accepted formats, max file size / dimensions, empty/no-photo state, upload-failure recovery, old-file deletion on replace, who-can-edit (actor/permission), and security validation of the file type."
-      - "Ranks the gaps by leverage — asks only the build-changing ones (formats+size, security validation, old-file deletion) and proposes safe defaults for the cosmetic ones instead of burning a question on each."
-      - "Frames questions as decisions with a recommendation (e.g. 'soft vs hard delete — recommend X because…'), one ranked batch, anchored to the spec line, rather than open-ended essay prompts or one-at-a-time drips."
-      - "Asks only the build-changing questions and lists the rest as assumed-defaults (assumed unless you object), with no verbosity level; phrases them in the register from technical_level in user-profile.md."
-      - "Bakes the resolved answers BACK into the spec: tightens the photo section into bounded behavior, adds observable acceptance criteria, and bounds dropped items under '## Out of scope'."
+      - "Walks the gap checklist (what the user can do, what result they get, what it must respect, how it proves it, out of scope) and surfaces concrete gaps: accepted formats, max file size / dimensions, empty/no-photo state, upload-failure recovery, old-file deletion on replace, who-can-edit (actor/permission), security validation of the file type, and anything an agent might add 'just in case'."
+      - "Asks only if the answer changes what gets built (formats+size, security validation, old-file deletion); for the rest it picks the most reasonable option and records it in the spec as a 'suposición tomada' with its basis, so the human sees every assumption in one block at approval."
+      - "Asks one question at a time, as a decision with the recommended answer first so a 'yes' suffices (e.g. 'I'd make deletes soft because… — OK?'), anchored to the spec line, rather than open-ended essay prompts or a batch of questions; phrases them in the register from technical_level in user-profile.md."
+      - "Bakes the resolved answers BACK into the spec: tightens the photo section into bounded behavior, adds observable acceptance criteria, and bounds dropped items under out of scope."
       - "Appends a dated '## Clarifications' log of Q → decision → why so the reasoning survives, and does a final re-read to confirm no new gap was opened."
       - "Stays in its lane: decides WHAT, never proposes the technical HOW (no architecture/library choices) and ends by pointing to plan as the next phase."

package/skills/constitution/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: constitution
-description: "Use when setting or amending a project's non-negotiables — stack canon, quality bars, conventions, security/a11y floors — as numbered, testable rules later phases obey. First rsc-sdd phase; writes 02-DOCS/wiki/sdd/constitution.md. NOT a feature spec (that is `specify`), NOT the technical plan (that is `plan`), NOT the wiki itself (that is `harness`)."
-tags: [sdd, constitution, principles]
+description: "Use when setting or amending a project's non-negotiables — stack canon, quality bars, conventions, security/a11y floors — as numbered, testable rules later phases obey, and drafting the REVIEW.md the reviewer reads. ASDD's base stage; writes 02-DOCS/wiki/sdd/constitution.md and REVIEW.md at the project root. NOT a feature spec (that is `specify`), NOT the technical plan (that is `plan`), NOT the wiki itself (that is `harness`)."
+tags: [asdd, constitution, principles, review]
 recommends: [specify]
 profiles: [core, full]
 origin: risco
@@ -9,7 +9,7 @@ origin: risco
 
 # constitution — the project's non-negotiable principles
 
-*The first rsc-sdd phase. Run once per project, then amend. It writes down the rules every later phase obeys: stack canon, quality bars, conventions. Everything downstream — specify, plan, analyze, implement, verify, review — reads this file as guardrails.*
+*ASDD's base stage (`../asdd/SKILL.md`). Run once per project, then amend. It writes down the rules every later phase obeys — stack canon, quality bars, conventions — and the `REVIEW.md` the reviewer reads first. Everything downstream — specify, plan, analyze, implement, verify, review — reads these as guardrails.*
 
 A constitution is small, durable, and enforceable. It is **not** a wiki of everything you know about the project (that is what `02-DOCS/wiki/` already is, run by the `harness`). It is the short list of principles that, if violated, mean the work is wrong regardless of whether it runs. If a rule here cannot be checked or pointed at later, it does not belong here — move it to the stack wiki and link it.
 
@@ -17,7 +17,7 @@ Not this phase: *what to build* → `../specify/SKILL.md`; the technical approac
 
 ## Model tier — `heavy` (opt-in routing)
 
-This phase's default model tier is **`heavy`** — it sets the project's non-negotiables, the highest-leverage decisions in the repo. 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 **`heavy`** — it sets the project's non-negotiables, the highest-leverage decisions in the repo. 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.
 
 ## Honor the register first
 
@@ -31,7 +31,7 @@ Before asking anything, read `02-DOCS/wiki/harness/user-profile.md` and use its
 
 The harness may already hold real conventions under `02-DOCS/wiki/stack/*` (e.g. `nextjs.md`, `fastapi.md`, `postgresdb.md`). The constitution does not copy them — it **ratifies the principle and links the detail**. Run this reconciliation pass first:
 
-1. **Read the Knowledge map** — the full index lives in `02-DOCS/wiki/index.md` (root `CLAUDE.md` keeps only a short pointer to it). List every `02-DOCS/wiki/stack/*` article that exists.
+1. **Read the Knowledge map** — `02-DOCS/wiki/index.md`. List every `02-DOCS/wiki/stack/*` article that exists.
 2. **Read each stack article.** Pull out anything already phrased as a rule (a version pin, a lint config, a test threshold, a naming convention).
 3. **For each existing rule, decide:** is it a *project-wide non-negotiable* (→ ratify it as a principle, linking the stack article for detail) or a *local mechanic* (→ leave it in the stack wiki, do not lift it into the constitution)?
 4. **Contradictions are findings, not fixes.** If two stack articles disagree, or a stack article contradicts what the user states now, surface it and let the user resolve — never silently pick a winner.
@@ -72,7 +72,7 @@ For any significant either/or (e.g. "strict types or gradual?", "squash or merge
 
 Two principles are inherited from the rsc ecosystem and appear in every constitution unless the user explicitly overrides them:
 
-- **Git authorship is the human's.** Commits and PRs are authored by the human (Eric, or whoever owns the repo). No `Co-Authored-By` an AI, no "generated with" footer. Enforced at the `ship` phase.
+- **Git authorship is the human's.** Commits and PRs are authored by the responsible person — the configured git user. No `Co-Authored-By` an AI, no "generated with" footer. Enforced at the `ship` phase.
 - **Decisions are logged.** Every significant decision is appended to `02-DOCS/wiki/sdd/decisions.md` (or the harness `decisions.md`) with date, options considered, and the why. The constitution itself is the highest-order decision record.
 
 ## Drafting the constitution
@@ -88,6 +88,18 @@ Create `02-DOCS/wiki/sdd/` if it does not exist. Do not overwrite an existing co
 
 **A draft is "complete me", not "amend me".** `rsc onboard` writes a skeleton with `status: draft` in the frontmatter: the template's headings, the facts onboarding knew (goal, kind, scope, workflow, detected stack) and no principle. Keep those facts, run the interview, fill the sections, then on ratification drop `status: draft`, set `version: v1.0.0` and log v1.0.0 in the amendment log.
 
+## REVIEW.md — what the reviewer reads first
+
+With the constitution, draft `REVIEW.md` at the project root (the code repo — the reviewer runs there). It is short, specific to this repo, and ratified with the constitution:
+
+- **What failure looks like here** — the defect classes that actually hurt this project (e.g. "a query without the tenant filter", "a migration that is not reversible").
+- **Paths to skip** — generated code, vendored files, fixtures.
+- **Nit cap** — the most nits one review may report (e.g. 3); the rest are dropped.
+- **Always-human paths** — what must never merge without a person (billing, auth, infra). Listing them here only informs; to be *enforced* they go into `.rsc/sello-config.json` `risk.raise`, which `rsc risk` reads — say so to the user.
+- **Summary starts with a count** — "3 findings: 1 blocker, 2 nits", before anything else.
+
+`review` adds to it when a finding keeps repeating; amend it like the constitution, never silently.
+
 ## Versioning & amendment protocol
 
 The constitution is versioned so `analyze` and `review` can cite "constitution v1.2.0, principle 4".
@@ -95,6 +107,7 @@ The constitution is versioned so `analyze` and `review` can cite "constitution v
 - **Semantic-ish versioning.** MAJOR when a principle is removed or reversed (breaks existing work); MINOR when a principle is added or materially tightened; PATCH for wording/clarity with no behavior change.
 - **Amendments are append-only in the log.** Never silently edit a ratified principle — strike it (mark superseded) and add the new one, bump the version, and record date + why in the amendment log.
 - **Ratification.** A new or amended constitution is shown to the user and ratified explicitly before it takes effect. "Ratify" is an explicit yes on the shown draft; walk each change only if the user asks.
+- **In autopilot** (`execution_mode: automatic`, or an up-front "take it all the way"), there is no one to ask: ratify **provisionally** (`status: provisional` in the frontmatter), log it in `decisions.md`, and add a `review-after` entry to the decision queue (`../asdd/SKILL.md`) so the human confirms it later. It does not block the run or a self-merge.
 - **Downstream notice.** When a principle changes mid-project, flag that existing specs/plans may now be inconsistent — `analyze` will catch the drift on the next run.
 
 ## Anti-patterns
@@ -108,7 +121,7 @@ The constitution is versioned so `analyze` and `review` can cite "constitution v
 | "I'll rewrite the existing constitution to match what they said today." | Amend, don't overwrite. Strike + add + bump version + log the why. |
 | "No profile yet, I'll assume they're technical." | Use analogies; ask once "technical or with analogies?" or send them to `init`. |
 | "I'll add a Co-Authored-By so the commit credits the assist." | No. Git authorship is the human's — it's a fixed principle, enforced at `ship`. |
-| "I'll ratify it myself since it's obvious." | The user ratifies. Show the draft, get the explicit yes, then it takes effect. |
+| "I'll ratify it myself since it's obvious." | The user ratifies. Show the draft, get the explicit yes, then it takes effect. Only autopilot ratifies provisionally, as a `review-after` queue entry. |
 
 ## Checklist before handing off
 
@@ -118,23 +131,24 @@ The constitution is versioned so `analyze` and `review` can cite "constitution v
 - [ ] The Definition-of-Done checklist is present (what `verify` runs against).
 - [ ] Fixed principles included: human git authorship + decisions logged.
 - [ ] `02-DOCS/wiki/sdd/constitution.md` written with version + ratified date + amendment log.
-- [ ] Root `CLAUDE.md` `## Knowledge map` pointer has the read-first row for the constitution.
-- [ ] The constitution was shown to the user and explicitly ratified.
+- [ ] `REVIEW.md` drafted at the project root; always-human paths mirrored into `.rsc/sello-config.json` `risk.raise` (or the user told why they are not).
+- [ ] The constitution is indexed in `02-DOCS/wiki/index.md` (the Knowledge map) under the `sdd/` topic.
+- [ ] The constitution was shown to the user and explicitly ratified — or, in autopilot, ratified provisionally with a `review-after` queue entry.
 
-## Project grounding (02-DOCS + CLAUDE.md)
+## Project grounding (02-DOCS)
 
-This skill's `02-DOCS` record is the constitution at `02-DOCS/wiki/sdd/constitution.md`. It is a **read-first** pointer entry, so its row stays in the short `## Knowledge map` pointer in the root `CLAUDE.md` (create `CLAUDE.md` if absent, additive only — never delete existing sections) — unlike other sdd artifacts, which are indexed in `02-DOCS/wiki/index.md` (the full Knowledge map that root `CLAUDE.md` points to). Add this row to the root pointer if it is not already present:
+This skill's `02-DOCS` record is the constitution at `02-DOCS/wiki/sdd/constitution.md`, indexed in `02-DOCS/wiki/index.md` (the Knowledge map) like every other sdd artifact:
 
 ```markdown
 | Project constitution (SDD non-negotiables) | `02-DOCS/wiki/sdd/constitution.md` |
 ```
 
-Every later rsc-sdd phase reads this file before it works. The harness maintains and improves the article over the life of the project; this skill is the place that ratifies and amends it.
+Never edit the root `CLAUDE.md` from here: it is owned by `harness` and is tier 2 in `rsc risk`. Every later ASDD phase reads the constitution before it works. The harness maintains and improves the article over the life of the project; this skill is the place that ratifies and amends it.
 
 ## Result envelope
 
-End with the parseable block every SDD phase shares, so the dispatcher can chain without
-interpreting prose (contract: `../sdd/SKILL.md`):
+End with the parseable block every phase shares, so the dispatcher can chain without
+interpreting prose (contract: `../asdd/SKILL.md`):
 
 ```json result-envelope
 {
@@ -149,10 +163,10 @@ interpreting prose (contract: `../sdd/SKILL.md`):
     "fallback": [],
     "compact_rules": ["Principles are inherited constraints, not choices to re-make.", "Every rule is testable or it is a preference."]
   },
-  "evidence": ["constitution path exists", "rules numbered and testable", "decisions log appended"]
+  "evidence": ["constitution path exists", "rules numbered and testable", "REVIEW.md drafted", "decisions log appended"]
 }
 ```
 
 ## Next in the chain
 
-The constitution is the guardrail; now describe what to build. Hand off to **`../specify/SKILL.md`** — turn a fuzzy intent into a spec (what & why, no implementation), grounded in these principles. The full chain: **constitution → specify → clarify → plan → tasks → analyze → implement → verify → review → ship** (with `debug`, `worktrees`, `parallel` callable on demand). The dispatcher is `../sdd/SKILL.md`.
+The constitution is the guardrail; now describe what to build. Hand off to **`../specify/SKILL.md`** — turn a fuzzy intent into a spec (what & why, no implementation), grounded in these principles. The ASDD stages: **base → spec → plan → per-task loop → closing → learn** (with `debug`, `worktrees`, `parallel` callable on demand). The dispatcher is `../asdd/SKILL.md`.

package/skills/constitution/evals/README.md

@@ -64,5 +64,5 @@ even if it reads tidy.
 - Re-run after any edit to `SKILL.md` or `references/constitution-template.md` —
   wording changes shift both triggering and rubric coverage.
 - Several `route_to` targets are rsc-sdd phase siblings (`specify`, `plan`,
-  `analyze`, `sdd`) that ship alongside this skill; the near-misses here route
+  `analyze`, `asdd`) that ship alongside this skill; the near-misses here route
   only to skills already present in the repo so the eval is runnable today.

package/skills/constitution/evals/cases.yaml

@@ -68,5 +68,5 @@ capability:
       - "Every principle is numbered, imperative, and testable (a number, command, or named artifact), not an aspiration like 'write clean code'."
       - "Includes the two fixed principles: git authorship is the human's (no Co-Authored-By AI / generated-with footer, enforced at ship) and significant decisions are logged."
       - "Produces a Definition of Done checklist (the merge bar verify runs against) covering format/lint, types, tests/coverage, conventions, branch+PR+authorship, security, and decisions logged."
-      - "Writes 02-DOCS/wiki/sdd/constitution.md with a version (v1.0.0), ratified date, and an append-only amendment log; adds the Knowledge-map row to root CLAUDE.md additively (never deleting sections)."
+      - "Writes 02-DOCS/wiki/sdd/constitution.md with a version (v1.0.0), ratified date, and an append-only amendment log; indexes it in 02-DOCS/wiki/index.md and never edits the root CLAUDE.md."
       - "Shows the draft and gets explicit ratification from the user before it takes effect, and ends by pointing to the specify phase as next in the chain."

package/skills/debug/SKILL.md

@@ -26,7 +26,7 @@ delegation table below.
 
 ## Model tier — `heavy` (opt-in routing)
 
-This phase's default model tier is **`heavy`** — root-cause diagnosis is deep reasoning. 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 **`heavy`** — root-cause diagnosis is deep reasoning. 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)
 
@@ -124,8 +124,8 @@ first — isolate which side actually fails before you open either stack's debug
 
 When the cause is non-obvious — a race, an order dependency, an environment-only failure, a
 regression a reviewer would otherwise have to rediscover — append a short entry to
-`02-DOCS/wiki/sdd/decisions.md` (append-only; create it if absent and add a row to the root
-`CLAUDE.md` `## Knowledge map` under the `sdd/` topic). One entry:
+`02-DOCS/wiki/sdd/decisions.md` (append-only; create it if absent and index it in
+`02-DOCS/wiki/index.md` under the `sdd/` topic — never the root `CLAUDE.md`). One entry:
 
 ```text
 ## YYYY-MM-DD — bug: <symptom in five words>  (feature: <slug>)

package/skills/fastapi/SKILL.md

@@ -20,7 +20,7 @@ pytest 8 + pytest-asyncio 1.0+ (`asyncio_mode=auto`), ruff 0.7+, mypy 1.13+ stri
 uv 0.5+, uvicorn 0.32+ / gunicorn 23+ + uvicorn-worker 0.3+, PyJWT 2.10+, argon2-cffi 23+,
 pip-audit 2.7+, PostgreSQL 16. (All lower bounds; install the latest in each line.)
 
-> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../asdd/SKILL.md`.
 
 Out of scope, and where it goes instead: [`django`](../django/SKILL.md) for Django; Flask / sync WSGI,
 notebooks and CLI-only scripts (no skill); language-level Python, typing and packaging →

package/skills/flutter/SKILL.md

@@ -18,7 +18,7 @@ this skill targets: **Flutter 3.44 / Dart 3.12**, **Riverpod 3.0**, **go_router
 
 ## Boundaries
 
-> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../sdd/SKILL.md`.
+> **⚠️ SDD new-feature gate — read this first.** If this skill fired on a **new, non-trivial feature or behaviour change** and there is **no approved spec + plan** under `02-DOCS/wiki/sdd/`, STOP — do **not** write feature code yet. Hand off to `../specify/SKILL.md` first: it runs brainstorm → spec → plan → tasks before any code, then routes back here once the plan is approved. Build here directly only for a genuinely one-line / low-risk change. Method: `../asdd/SKILL.md`.
 
 This skill owns the `pubspec.yaml` subproject and nothing else in the repo. Hand off when the UI is
 Compose Multiplatform (`compose-multiplatform`), SwiftUI/native iOS (`swift-ios`) or React Native

package/skills/ftd/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ftd
-description: "Use for ordinary authorised change — the default lane once the decisor has ruled out a question and not selected the chain. Keeps one feature document per feature in 02-DOCS holding intent, scope, checklist, evidence and next step, checks tasks off only against observed proof, and asks whether to branch before the work writes code. NOT the ten-phase chain (that is `sdd`), NOT the classification itself (that is the decisor in `suggest`), NOT a request for information, which writes nothing."
+description: "Use for ordinary authorised change — the default lane once the decisor has ruled out a question and not selected the chain. Keeps one feature document per feature in 02-DOCS holding intent, scope, checklist, evidence and next step, checks tasks off only against observed proof, asks whether to branch before the work writes code, and runs a minimal risk loop (self-check, `rsc risk`, one reviewer from tier 1). NOT the full method (that is `asdd`), NOT the classification itself (that is the decisor in `suggest`), NOT a request for information, which writes nothing."
 tags: [ftd, lane, default, feature-document, evidence]
 recommends: [worktrees, debug, verify]
 profiles: [minimal, core, full]
@@ -10,11 +10,11 @@ origin: risco
 # FTD — Fast-Track Development
 
 The lane ordinary work takes. Not a lighter methodology: the **same** discipline about evidence with
-none of the coordination the ten-phase chain exists to buy. One document instead of five, written
+none of the coordination `asdd` exists to buy. One document instead of five, written
 because the work might be interrupted, not because somebody has to approve it first.
 
 You are here because the decisor in `../suggest/SKILL.md` ruled that this turn authorises a change
-and did not select `../sdd/SKILL.md`. If it is still a question, you are in the wrong place: go back
+and did not select `../asdd/SKILL.md`. If it is still a question, you are in the wrong place: go back
 and answer it.
 
 ## Why this lane exists
@@ -24,7 +24,7 @@ riesgo. Silencio para lo trivial, ceremonia solo donde el fallo es caro. Un sist
 80% inofensivo acaba apagado, y apagado no protege el 20% que importa.»*
 
 The harness spent a long time contradicting it — every request that sounded like building went
-through ten phases. This lane is that principle finally implemented, not a new idea.
+through the whole chain. This lane is that principle finally implemented, not a new idea.
 
 ## The feature document
 
@@ -60,6 +60,20 @@ the test output, the command's result, the page rendering. A task whose check wa
 could not run is recorded as such, honestly. The tenth principle applies here exactly as it does in
 the chain: a result asserted without evidence is treated as not done.
 
+## The minimal loop — per change that writes code
+
+The lane inherits ASDD's per-task loop, cut to its floor:
+
+1. **Self-check** — run the change's own check and record the output under Evidence.
+2. **`npx @ericrisco/rsc risk`** — the tier of what changed (same path table as the sello; works
+   with it off).
+3. **Tier ≥ 1 → one fresh-context reviewer** (`../review/SKILL.md`, per-task mode). Tier 0 → none.
+4. **Mandatory controls** — tests, build, the security scan the project has. What did not run is
+   written «not executed», never left blank.
+
+**Escalate to `asdd`** when `rsc risk` says **tier 2**, or when the change contradicts a decision
+already recorded in `decisions.md`: the feature document becomes its spec input, as below.
+
 ## Isolation
 
 Where the work runs follows the project's decision (asked at install: «main» or «ramas y PR»; rsc
@@ -83,10 +97,10 @@ cleanup is automatic and you do not run anything.
 
 ## Growing out of the lane
 
-A feature that turns out to need the chain is **promoted, not restarted**: the feature document
-becomes the input to `../specify/SKILL.md`, and no completed work is discarded. Promotion happens for
-the same reason the chain is ever entered — durable artifacts would remove a substantial ambiguity —
-and never because the work turned out to be big.
+A feature that turns out to need `asdd` is **promoted, not restarted**: the feature document
+becomes the input to `../specify/SKILL.md`, and no completed work is discarded. Promotion happens
+when durable artifacts would remove a substantial ambiguity, or by the escalation above (tier 2, a
+contradicted decision) — never because the work turned out to be big.
 
 ## Anti-patterns → STOP
 
@@ -96,13 +110,15 @@ and never because the work turned out to be big.
 | Check a task off because you believe it works | Observed proof or it is not done (P10). Record the check you could not run. |
 | Write the document into the code repository | It belongs in `02-DOCS`. A clone should get code, not notes. |
 | Open a worktree "to be safe" | That is the chain's ceremony arriving through the back door (P7). |
-| Escalate to the chain because the change is large | Size never selects it. Only unresolved ambiguity that artifacts would settle. |
+| Escalate to `asdd` because the change is large | Size never selects it. Only unresolved ambiguity, tier 2, or a contradicted decision. |
+| Skip the reviewer because the change looks safe | `rsc risk` decides, not the feeling. Tier ≥ 1 gets one. |
 | Produce a spec, plan or task artifact here | Those are the chain's. This lane has one document. |
 
 ## See Also
 
 - `../suggest/SKILL.md` — the decisor that routed here, and the other two lanes.
-- `../sdd/SKILL.md` — the ten-phase chain, for when artifacts genuinely earn their cost.
+- `../asdd/SKILL.md` — the full method, for when artifacts genuinely earn their cost.
+- `../review/SKILL.md` — the reviewer the minimal loop calls at tier ≥ 1.
 - `../verify/SKILL.md` — the evidence gate, when this lane's checks need the full battery.
 - `../debug/SKILL.md` — a failure to reproduce before fixing; comes back here afterwards.
 

package/skills/ftd/evals/cases.yaml

@@ -3,7 +3,7 @@ skill: ftd
 # Cases for FTD — Fast-Track Development, the lane ordinary authorised change takes.
 # FTD keeps ONE feature document per feature in 02-DOCS (intent, scope, checklist,
 # evidence, next step), checks tasks off only against observed proof, and branches when
-# the work writes code. It is NOT the ten-phase chain (sdd), NOT the classification
+# the work writes code. It is NOT the full method (asdd), NOT the classification
 # itself (the decisor lives in the always-on suggest body), and NOT a request for
 # information — those write nothing at all.
 

package/skills/ftd/evals/routing.json

@@ -3,7 +3,7 @@
   "lanes": {
     "answer": "information only; writes nothing, creates no artifact",
     "ftd": "authorised change, ordinary; one feature document",
-    "sdd": "the ten-phase chain, entered by the agent for big or complex work"
+    "asdd": "the ASDD chain (review inside every task), entered by the agent for big or complex work"
   },
   "cases": [
     { "request": "¿Por qué el login tarda tanto en producción?", "expect": "answer", "why": "investigation; nothing authorises a change" },
@@ -17,8 +17,8 @@
     { "request": "Renombra la tabla de usuarios en las 40 llamadas que la usan", "expect": "ftd", "why": "large and mechanical: size alone must never select the chain" },
     { "request": "Sube la versión de la dependencia y arregla lo que rompa", "expect": "ftd", "why": "authorised change with no unresolved design question" },
     { "request": "Migra los tres endpoints al nuevo formato de respuesta", "expect": "ftd", "why": "many files, but nothing a spec would settle that the code does not" },
-    { "request": "Quiero especificar bien el sistema de permisos antes de tocar nada", "expect": "sdd", "why": "explicit request for the chain" },
-    { "request": "Vamos a hacer una spec de esto", "expect": "sdd", "why": "explicit request, stated in the user's own words" },
-    { "request": "No tengo claro si los permisos van por rol o por recurso, y afecta al esquema, a la API y a la UI", "expect": "sdd", "why": "enter the chain: several interlocking decisions that durable artifacts would settle; the agent enters it and says why" }
+    { "request": "Quiero especificar bien el sistema de permisos antes de tocar nada", "expect": "asdd", "why": "explicit request for the chain" },
+    { "request": "Vamos a hacer una spec de esto", "expect": "asdd", "why": "explicit request, stated in the user's own words" },
+    { "request": "No tengo claro si los permisos van por rol o por recurso, y afecta al esquema, a la API y a la UI", "expect": "asdd", "why": "enter the chain: several interlocking decisions that durable artifacts would settle; the agent enters it and says why" }
   ]
 }