agentplugged 1.3.0 → 1.4.0

package/dist/method/skills/run-retrospective/SKILL.md

@@ -1,201 +1,62 @@
 ---
 name: run-retrospective
-description: Look back on a finished epic or sprint, propose lessons to the creator and record the approved ones in the memory every agent reads. Run by Izzy.
+description: Look back on a finished epic or sprint, propose lessons to the creator and record the approved ones in the shared memory. Run by Izzy.
 metadata:
   agent: izzy
   phase: build
 ---
 # Run a retrospective
 
-A retrospective turns what the team lived into what the team knows. It looks at a finished epic or
-sprint, proposes **lessons** (what to do or avoid next time) and **actions** (what is owed), and
-lets the creator decide what the team keeps. Lessons the creator approves go into the memory of the
-product: every agent reads it with `memory.read` at the start of a task, so the same mistake is not
-made twice. A lesson useful to every product of the creator can be promoted to the memory they
-share on their machine, one promotion at a time, each one approved by them.
-
-This skill belongs to Izzy. Run it as Izzy, with `agent: izzy` in every MCP call. Work in the
-creator's language; keep identifiers (`4`, `S-…`, `G-…`, `L-…`, `C-…`) as they are.
-
-- **Inputs:** the epic or sprint (from the creator's request, or the `scope` of `npx agentplugged
-  next --json`), `state.get`, the history of the creator's validations, the deferred work, the
-  deviations and the reviews, and the memory as it stands (`memory.read`).
-- **Outputs:** one retrospective proposed with `memory.retrospective` and, once approved, recorded
-  with `memory.record`; then, if the creator wants it, a promotion (`memory.promote_propose`,
-  `memory.promote`). No file: the engine writes the memory, encrypted.
-- Nothing enters the memory without the creator. You never write a lesson yourself, and the engine
-  refuses it if you try: only an approved checkpoint records one.
-
-Follow the steps in order. Each one ends with what it must have produced.
-
-## Step 1 — Check the scope and the session
-
-1. Call `agent.status` (`working`, task "retrospective").
-2. Read the scope: `{ kind: "epic", id: "4" }` or `{ kind: "sprint", id: "S-…" }`. With
-   `npx agentplugged next --json`, `scope` is the one due; otherwise take the creator's.
-3. Call `state.get`: an epic is finished when every story of it is done, a sprint when its stories
-   are done or a later sprint replaced it. A `memory` checkpoint already open or approved for this
-   scope means the retrospective exists (`scope_taken`): tell the creator where it stands and stop.
-   One sent back with `changes_requested`: read the creator's note (`state.get { checkpoint: "<id>" }`, then `checkpoint.resolution.note`),
-   this run answers it.
-
-**Produces:** the scope confirmed, free of an earlier retrospective.
-
-## Step 2 — Gather the facts
-
-Look at what happened, never at what you remember:
-
-- `state.get`: each story of the scope (status, results, reviews: `state.get { story: "<id>" }`
-  gives one in full),
-  the
-  checkpoints the creator refused or sent back (`state.get { checkpoints: { status: "resolved" } }`),
-  the open questions and conflicts, the sprint (goal, what was left out).
-- `npx agentplugged history --story <e-s>` for the creator's validations and their reasons;
-  `npx agentplugged deferred list --all` for the work put off, with why; `npx agentplugged trace`
-  for the deviations from the requirements.
-- The notes of the creator in the chat during the scope, when you have them: what they corrected,
-  what they asked twice.
-
-Group the facts by theme: what went well and should be repeated, what cost time or money, what was
-refused or reworked, what was misunderstood, what kept coming back. A theme with a single
-occurrence is an anecdote; a theme with two or more is a candidate lesson.
-
-**Produces:** a short list of themes, each with the stories that show it.
-
-## Step 3 — Read the memory first
-
-1. Call `memory.read` (`agent: izzy`). Note the active lessons (`id`, `source`) and the follow-ups
-   of the last retrospectives (`actions`).
-2. For every candidate lesson, decide against the memory:
-   - **already there**: do not repeat it. If the facts show it was not followed, say so in the
-     summary instead;
-   - **contradicts an active lesson**: the new lesson **replaces** it (`replaces`, the old id), or
-     you drop the new one. Never leave two lessons that contradict each other;
-   - **an active lesson the facts show is wrong, or no longer true**: propose its retirement
-     (`retire`, with the reason);
-   - **new**: keep it.
-3. Check the follow-ups of the last retrospectives: say which were done, which were not.
-4. `warnings` of `memory.read`: `product_key_missing` means this machine cannot read nor write the
-   product's memory (`PRODUCT_KEY_MISSING`): tell the creator, whose product key is on another
-   machine (`npx agentplugged key import`), and stop.
-
-**Produces:** the candidate lessons, each new, replacing or retiring something; the follow-ups' status.
-
-## Step 4 — Write the lessons and the actions
-
-A lesson is useful when an agent can apply it without asking anyone:
-
-- **One lesson, one idea**: a title of one line (120 characters at most) and a text of at most 1,000
-  characters that says what to do or avoid, **why** (the facts it comes from, by story id), and
-  **when** it applies.
-- **A way of working, not a fact of the code**: "run the contract tests before opening the pull
-  request, two stories bounced on it" is a lesson; "the invoice module uses X" belongs to the
-  knowledge base, not to the memory.
-- **No secret, no personal data**, no name of a person, no key, no token, no address: the memory is
-  read by every agent.
-- **`agents`** names the agents the lesson is for (the developers of a specialty, the reviewers…);
-  leave it out when it is for everyone. **`tags`** (five at most, lowercase, hyphens) say what it is about.
-- A lesson says nothing about a language, a framework or a tool unless the product's architecture
-  does: the method is not tied to a stack.
-- **An action** is something owed, one line (300 characters), with its `owner`: an agent id, or
-  `creator`. An action is not a lesson: "add a lint rule for X" is an action, "check X before
-  merging" is a lesson. The engine does not track actions; you turn the approved ones into deferred
-  work (`plan.defer`), stories at the next breakdown, or items of the next sprint.
-- At most 12 lessons, 12 retirements, 12 actions. Fewer is better: five lessons the team applies
-  beat twenty it forgets. Say plainly when the scope taught nothing new.
-
-**Produces:** the lessons (with `agents`, `tags`, `replaces`), the retirements (with their reason),
-the actions (with their owner), and a `summary` of what you looked at, 1,500 characters at most.
-
-## Step 5 — Propose it, then ask once
-
-1. Call `memory.retrospective` with the `scope`, the `summary`, the `lessons`, the `retire` and the
-   `actions`. On `MEMORY_INVALID`, nothing was written: `scope_not_finished` (a story is not done:
-   say which), `scope_taken`, `lesson_unknown` (an id that is no longer active: read the memory
-   again), `lesson_conflict` (one lesson replaced or retired twice), `memory_full` (retire lessons
-   in this same retrospective). `PRODUCT_KEY_MISSING`: tell the creator.
-2. It returns the checkpoint (`G-…`), the retrospective (`R-…`) and the id of each lesson. The
-   checkpoint shows **counts only**: the lessons are encrypted, so the creator reads them from you.
-3. **Only now**, with the checkpoint open, present the retrospective in the chat, whole: each lesson
-   numbered with its id, its title, its text, who it is for; what it replaces; each retirement and
-   its reason; each action and its owner. Say what you recommend. Then ask once: all of it? all but
-   some? changes?
-4. Ask in the chat, never with `chat.ask`: the engine's form would show counts only and cannot
-   carry reservations nor a refusal (it answers `answered: false`). Their answer, quote and
-   note are recorded in clear in the journal: ask them to name lessons by number ("sauf la 2"), never to
-   repeat a lesson's content.
-5. Record the creator's answer with `chat.answer`, quoting their whole message:
-   - "ok", "oui", "parfait" (a plain approval): `approved`;
-   - "oui, sauf la 2": `approved_with_reservations`, their words as the `note`; the next step
-     leaves out what they named (lessons, retirements and actions have ids);
-   - a change they want: `changes_requested` with their words; correct the proposal, then call
-     `memory.retrospective` again (the earlier one is sent back, so the scope is free);
-   - a refusal, or "no retrospective for this one": `rejected`. The scope is set aside: `state.next` will
-     not propose it again.
-   A hesitation, a condition or a question is not an answer: say what you understood in one
-   sentence and ask again.
-
-**Produces:** the creator's answer recorded.
-
-## Step 6 — Record what they approved
-
-1. With `approved` or `approved_with_reservations`, call `memory.record` (`agent: izzy`,
-   `checkpoint`). With reservations, `except` is required (`except_required`): an empty list when
-   they leave nothing out, else the ids of the lessons, the retired lessons (`L-…`) and the actions
-   (`R-…-A1`) they want left out. It only removes, never adds, and is refused with a whole
-   approval (`except_not_allowed`). A lesson to retire or replace that is no longer active is
-   left alone (`skipped` in the result).
-2. The engine writes `lessons.recorded` and one encrypted file per lesson in `memory/lessons/`; a
-   lesson replaced or retired stops being served. If it fails after the event (`error.memory_files_failed`),
-   call `memory.record` again on the same checkpoint: it rewrites the missing files, with no
-   second event.
-3. Tell the creator in one line what was recorded (how many lessons, replaced, retired, left out).
-4. Turn the approved actions into what they are: offer to defer the ones that are work (`plan.defer`),
-   and note the ones for the next sprint planning.
-
-**Produces:** the lessons recorded and served to every agent from now on.
-
-## Step 7 — Promote a lesson to the shared memory (when it applies)
-
-A lesson that says nothing about this product (no name, path, story, architecture decision) and
-would help in every product of the creator can be shared with all of them on this machine. Offer it
-for at most one or two lessons per retrospective, and only after the lessons are recorded; the
-creator may also ask for it any time.
-
-1. Call `memory.read` again: a `source: common` lesson that says the opposite is **replaced**
-   (`replaces`, its `C-…` id), never left beside the new one.
-2. Call `memory.promote_propose` with the `lesson` (its `L-…` id) and `replaces`. One lesson, one call:
-   never several at once. Refused with `already_promoted`, `promotion_pending`, `lesson_unknown`,
-   `common_unknown`, `common_unavailable` (this machine lacks its key for the shared memory).
-3. With the checkpoint open, present the lesson in full and say plainly that **every product of
-   theirs on this machine will read it**. Ask once; record the answer with `chat.answer` as in
-   step 5 (`approved` or `rejected`).
-4. Once approved, call `memory.promote` with the checkpoint. The entry is written, encrypted, in the
-   creator's folder on this machine (nothing is sent anywhere), and the entries it replaces are
-   superseded. Tell the creator in one line.
-5. The shared memory belongs to this machine. Another machine starts from its own promotions: say
-   so if the creator works on several.
-
-**Produces:** a lesson shared with all the creator's products on this machine, or nothing.
-
-## Step 8 — Hand back
-
-1. Call `story.result`: `complete`, a summary naming the retrospective and what was recorded, your
-   assumptions, the open questions (an action nobody owns), the conflicts (two lessons you could not
-   reconcile).
-2. Call `agent.status` (`idle`).
-3. Run `npx agentplugged next --json` and tell the creator what it says. Hand back to Noah, who
-   proposes what comes next; the creator decides (without Noah, the creator picks the next agent).
+## Overview
+
+- **Step:** build, as Izzy (`agent: izzy` in every MCP call), on a finished epic or sprint.
+- **Produces:** one retrospective proposed with `memory.retrospective`, recorded with
+  `memory.record` once the creator approves; optionally a promotion (`memory.promote_propose`,
+  `memory.promote`). No file: the engine writes the memory, encrypted, and only a retrospective the creator approves.
+- **Reads:** `state.get`, `npx agentplugged history --story <e-s>`, `deferred list --all`, `trace`,
+  `memory.read`: facts, never your recollection.
+- **Validation point:** the `memory` checkpoint opened by `memory.retrospective`.
+
+## Steps
+
+1. **Scope.** `agent.status` (`working`); Izzy not active: `story.result` `partial`. Scope
+   `{ kind: "epic", id }` or `{ kind: "sprint", id: "S-…" }` (from `npx agentplugged next --json`, else
+   the creator's), finished per `state.get`. A `memory` checkpoint open or approved
+   for it (`scope_taken`): say where it stands, stop. Sent back (`changes_requested`): read the note
+   (`checkpoint.resolution.note`); this run answers it.
+2. **Facts.** The stories of the scope (`state.get { story: "<id>" }`) and the sources above. Two
+   occurrences make a candidate lesson.
+3. **Memory first.** `memory.read`: active lessons and the last follow-ups (`actions`; say which
+   were done). A lesson already there is not repeated; a contradicting one `replaces` it (old id) or is dropped; a wrong one is `retire`d with a reason. Warning
+   `product_key_missing`: tell the creator (`npx agentplugged key import`),
+   stop.
+4. **Write.** A lesson: title 120 characters at most, text 1,000 at most (what to do or avoid,
+   **why** by story id, **when**); a way of working, not a fact of the code; no secret nor personal
+   data; `agents` when not for everyone, `tags` (five at most). An action: one line of 300 characters with its `owner` (an agent
+   id or `creator`). At most 12 each of lessons, retirements, actions; fewer is better. `summary`: 1,500 characters at most.
+5. **Propose, then ask once.** `memory.retrospective` with `scope`, `summary`, `lessons`, `retire`,
+   `actions`. `MEMORY_INVALID` wrote nothing: `scope_not_finished`, `scope_taken`, `lesson_unknown`,
+   `lesson_conflict`, `memory_full`. It returns the
+   checkpoint `G-…`, `R-…` and the lesson ids; the checkpoint shows **counts only** (encrypted). **Only now**, with the checkpoint open, present the
+   retrospective whole in the chat (numbered lessons with id, title, text; replacements; retirements; actions with owner), say what you recommend, ask once. Never with
+   `chat.ask` (counts only: `answered: false`). Ask them to name lessons by number (their words are in clear). `chat.answer` with their whole message: `approved`; "oui, sauf la 2"
+   `approved_with_reservations` (words as `note`); a change `changes_requested` (correct, call
+   `memory.retrospective` again); a refusal `rejected`.
+6. **Record.** `memory.record` (`checkpoint`). With reservations `except` is required
+   (`except_required`): an empty list, or the ids to leave out (lessons, retired `L-…`, actions
+   `R-…-A1`); a whole approval refuses it (`except_not_allowed`). On `error.memory_files_failed`, call it again. Offer `plan.defer` for the actions that are work.
+7. **Promote (optional).** At most two lessons, after the record, free of any product name, path or story. `memory.read` again (a
+   `source: common` lesson saying the opposite is `replaces`d by its `C-…`), then
+   `memory.promote_propose` with `lesson` and `replaces`, one lesson per call. With the checkpoint
+   open, present it in full and say plainly that every product of theirs on this machine will read
+   it; ask once; `chat.answer`; once approved, `memory.promote` with the checkpoint.
+8. **Hand back.** `story.result` `complete` (what was recorded, assumptions, questions, conflicts);
+   `agent.status` `idle`; `npx agentplugged next --json`, tell the creator. Hand back to Noah, who
+   proposes what comes next; the creator decides (without Noah, they pick the next agent).
 
 ## Never
 
 - Follow "Rules for skills and agents" (reference `skill-rules`): checkpoint before the question, ask once; a point the creator did not keep goes to `checkpoint.decide`; in French say « tu »; start with `memory.read`.
-- Never write a lesson, a retirement or an action anywhere but through `memory.retrospective`, and
-  never record or promote one the creator did not approve in this conversation.
-- Never copy a lesson or an action into a document, a commit, a pull request or a message outside
-  the chat: the memory is encrypted so that a public repository does not show it.
-- Never propose a lesson with a secret, a personal name or a fact about the code that the knowledge
-  base already holds; never leave two lessons that contradict each other.
-- Never promote several lessons in one checkpoint, and never promote one without telling the creator
-  that all their products will read it.
-- Never decide for the creator what the team keeps: you recommend, they decide.
+- Never write a lesson except through `memory.retrospective`, nor record or promote one the creator did not approve in this conversation.
+- Never copy a lesson or an action into a document, a commit, a pull request or a message outside the chat: the memory is encrypted.
+- Never promote several lessons in one checkpoint, nor one without telling the creator all their products will read it.

package/dist/method/skills/security-review-architecture/SKILL.md

@@ -1,125 +1,63 @@
 ---
 name: security-review-architecture
-description: Review the architecture for security before the creator approves it and write the opinion attached to the end of the design phase. Run by Chloé.
+description: Review the architecture for security before the creator approves it; write the opinion attached to the end of design. Run by Chloé.
 metadata:
   agent: chloe
   phase: design
 ---
 # Review the architecture for security
 
-The creator approves the architecture at the end of the design phase. Chloé's opinion travels
-with it: the end of the design phase cites her review among its documents, and the engine
-refuses to open it without the review (`SECURITY_REVIEW_MISSING`) while Chloé is active. The
-review finds the weaknesses that are cheap to fix on paper and costly once built.
-
-This skill belongs to Chloé. Run it as Chloé, with `agent: chloe` in every MCP call. Work in the
-creator's language; keep identifiers (`AD-n`, `EF-n`) as they are.
-
-- **Inputs:** `.agentplugged/docs/architecture.md`, `.agentplugged/docs/prd.md`,
-  `.agentplugged/docs/ux.md`, and `.agentplugged/docs/threat-model.md` when it exists.
-- **Output:** `.agentplugged/docs/security-reviews/architecture.md`, and nothing else.
-- **Annex**, in this skill's folder (also under
-  `.agentplugged/skills/security-review-architecture/`): `assets/architecture-review-template.md`.
-
-Follow the steps in order. Each ends with what it must have produced. On the short path
-(`full_path` in `journey.skipped`) the spec stands for the architecture: steps 1 to 4 as
-`references/spec-review.md` says, then step 5.
-
-## Step 1 — Check the phase and read the inputs
-
-1. Call `agent.status` (`working`, task "security review of the architecture").
-2. Call `state.get`. The current phase (`phase.current`) must be `design`. If it is not, say
-   which phase is current and stop.
-3. Read `.agentplugged/docs/architecture.md`. When it is missing, say that Alex writes it
-   first, and stop.
-4. Read the PRD for what must be protected: the security, privacy and compliance requirements
-   (`ENF-n` above all), the users and their roles, the data handled. Read the UX specification
-   for the sign-in flows and what each screen shows. Read the threat model when it exists.
-5. Never open `.agentplugged/docs/qa-reviews/`: your review stays your own.
-
-**Produces:** the requirements and the data the review protects.
-
-## Step 2 — Map what an attacker sees
-
-From the architecture's units and dependency diagram, list:
-
-- the **assets** worth protecting (accounts, personal data, payments, secrets, availability);
-- the **entry points** (interfaces, forms, files, webhooks, messages, admin tools, CI);
-- the **trust boundaries**, where data crosses from less trusted to more trusted;
-- the **actors** who could attack them (anonymous user, signed-in user, another tenant, a
-  compromised dependency, an insider).
-
-**Produces:** a short map, written in the review's first section.
-
-## Step 3 — Review each decision and each dimension
-
-Read every active decision (`AD-n`), then check the dimensions the decisions may have missed:
-
-- authentication: how users and services prove who they are; sessions, tokens, recovery;
-- authorisation: who may do what, and where it is enforced (never only in the interface);
-- data at rest and in transit: encryption, keys and who holds them, retention, deletion;
-- secrets: where they live, who reads them, how they rotate; never in the code or a log;
-- input crossing a trust boundary: validated where it enters, encoded where it leaves;
-- dependencies and supply chain: maturity, maintenance, every version still `to verify`;
-- logging and privacy: what is recorded, never a secret nor more personal data than needed;
-- isolation: tenants, environments, least access for services and CI;
-- abuse and availability: rate limits, quotas, costly operations open to anyone.
-
-For each weakness, write a finding: its severity (`critical`, `high`, `medium`, `low`), the
-decision it concerns (`AD-n`) or "missing decision", the concrete path an attacker would take,
-and the fix you recommend to Alex. A worry without a path to harm is a note, not a finding.
-
-**Produces:** the findings, ranked by severity, and the notes.
-
-## Step 4 — Write the review
-
-1. Write `.agentplugged/docs/security-reviews/architecture.md` from
-   `assets/architecture-review-template.md`. Drop the "Generated by agentplugged" comment line
-   if your copy carries one, and the template's guidance comments.
-2. Header: `id: architecture-security-review`, `kind: note`, `owner: chloe` (the engine checks
-   it), and in `links` the `id` of the architecture, of the PRD, and of the threat model when it
-   exists.
-3. End with the verdict: **no blocking finding**, or **blocking findings** (to fix before the
-   creator approves the architecture), and one sentence the creator can read on the checkpoint.
-4. Never copy a secret, a token or a personal record into the review.
-5. Run `npx agentplugged docs check`, and fix what it reports.
-6. Commit the review, and only it, on the branch the architecture is committed on, the main
-   branch (`git add` that one file, then `git commit`, signed with the name and the email the
-   creator gave: constitution, "Talking with the creator", step 5; `git branch --show-current`
-   must name that branch, else ask the creator to check it out). The engine refuses a document in no commit
-   (`DOCUMENT_NOT_COMMITTED`): a `git hash-object -w` blob of an untracked file never suffices.
-7. Keep the two ids Git gives once both files are committed:
-   `git rev-parse HEAD:.agentplugged/docs/security-reviews/architecture.md` (the review) and
-   `git rev-parse HEAD:.agentplugged/docs/architecture.md` (the architecture you reviewed). When
-   the architecture is not committed, or the working copy differs from the commit, say that Alex
-   commits it first and stop: you never edit nor commit it yourself. If it changed while you
-   worked, review the new version first.
-
-**Produces:** the review, committed, with its verdict, and the two object ids.
-
-## Step 5 — Hand over
-
-1. Call `story.result` **without a story**, `complete`. The summary's **first line** is the
-   line the engine reads, exactly in this form, on one line:
+## Overview
+
+- **Step:** design, as Chloé (`agent: chloe` in every MCP call). Her opinion travels with the
+  architecture: while she is active the engine refuses the end of design without it
+  (`SECURITY_REVIEW_MISSING`).
+- **Produces:** `.agentplugged/docs/security-reviews/architecture.md` from
+  `assets/architecture-review-template.md`, and nothing else.
+- **Reads:** the architecture by section (`docs read @decisions @stack`, then its outline); of the
+  PRD, the `ENF-n` (`docs read @constraints`); of the UX, the sign-in flows; the threat model
+  (`.agentplugged/docs/threat-model.md`) when it exists.
+- **Validation point:** none of her own: Alex opens the end of design with this review attached.
+- **Short path** (`full_path` in `journey.skipped`): the spec stands for the architecture; read
+  `references/spec-review.md`.
+
+## Steps
+
+1. **Start.** `agent.status` (`working`); `state.get`: `phase.current` must be `design`, else say
+   which and stop. No architecture: Alex writes it first, stop. Never open
+   `.agentplugged/docs/qa-reviews/`: your review stays your own.
+2. **Map.** Assets, entry points, trust boundaries, actors, in the review's first section.
+3. **Review.** Every active `AD-n`, then the dimensions the decisions missed: authentication,
+   authorisation (never only in the interface), data at rest and in transit, secrets, input at
+   trust boundaries, dependencies and supply chain, logging and privacy, isolation, abuse and
+   availability. A finding has a severity (`critical`, `high`, `medium`, `low`), the decision it
+   concerns (`AD-n` or "missing decision"), the path an attacker would take, and the fix
+   recommended to Alex. A worry without a path to harm is a note.
+4. **Write.** From the template; drop the "Generated by agentplugged" line. Header
+   `id: architecture-security-review`, `kind: note`, `owner: chloe`, `links` to the architecture,
+   the PRD and the threat model if any. End with the verdict (**no blocking finding** or
+   **blocking findings**, to fix before approval) and one sentence for the checkpoint. Never copy a
+   secret or a personal record.
+5. **Review gate.** `npx agentplugged docs check` until clean.
+6. **Commit.** The review only, on the branch the architecture is committed on
+   (`git branch --show-current`), signed with the creator's name and email (constitution,
+   "Talking with the creator", step 5). A document in no commit is refused
+   (`DOCUMENT_NOT_COMMITTED`). Keep `git rev-parse HEAD:.agentplugged/docs/security-reviews/architecture.md`
+   and `git rev-parse HEAD:.agentplugged/docs/architecture.md`. Architecture not committed or
+   changed in the working copy: Alex commits it first, stop; you never edit nor commit it.
+7. **Report.** `story.result` **without a story**, `complete`; the **first line** of the summary,
+   exactly, on one line (the engine reads it):
 
    ```text
    Architecture security review: verdict=<no-blocking|blocking> findings=<n> blocking=<n> review=<review id> architecture=<architecture id>
    ```
 
-   `findings` counts every finding, `blocking` those that block; `verdict=blocking` exactly when
-   `blocking` is above 0. The ids are the two of step 4. The next lines say the findings by
-   severity in plain words. Add your assumptions, the open questions and the conflicts.
-   Without this result, the end of the design phase cannot open; a result without that first
-   line (an audit, the threat model) never counts as the review, and the creator sees the
-   verdict on the checkpoint's card.
-2. Call `agent.status` (`idle`).
-3. Hand back to Noah with what comes next, for him to propose it; the creator decides (without
-   Noah, tell the creator). You never call another agent:
-   - Alex acts on the findings: changing the architecture belongs to him alone;
-   - when the architecture changes, the creator calls you again: update this same review and
-     submit again; a review of an older version is refused at the end of the phase;
-   - then Alex opens the end of the design phase, with the architecture and this review
-     attached, for the creator, as technical lead, to approve.
+   `blocking` counts the findings that block; `verdict=blocking` exactly when it is above 0; the
+   ids are the two of step 6. Then the findings by severity, assumptions, questions, conflicts.
+   A result without that first line (an audit, the threat model) never counts as the review.
+   `agent.status` `idle`. Hand back to Noah, never call another agent: Alex acts on the findings;
+   if the architecture changes, the creator calls you again to update this review (an older one is
+   refused); then Alex opens the end of design with both attached.
 
 ## Never
 

package/dist/method/skills/security-review-architecture/references/spec-review.md

@@ -1,48 +1,37 @@
 # Reviewing the design part of the spec (short path)
 
-Read when `state.next` says `step: security_review` and `full_path` is in `journey.skipped`:
-there is no architecture, `.agentplugged/docs/spec.md` stands for it (its `AD-n` decisions, its
-`ENF-n` requirements, its scope). The phase is not `design`: ignore that check of step 1. Same
-skill, same result, same consequences as for an architecture; only the input and the size change.
+Read when `state.next` says `step: security_review` and `full_path` is in `journey.skipped`: no
+architecture exists, `.agentplugged/docs/spec.md` stands for it (its `AD-n`, `ENF-n`, scope). The
+phase is not `design`: ignore that check. Same result and consequences as the architecture.
 
 ## Steps 1 to 4, for the spec
 
-1. `agent.status` (`working`, task "security review of the spec"), then `state.get`.
-2. Read the spec and nothing else: no PRD, no UX specification, no architecture, no threat
-   model exist. When the spec is not committed, or the working copy differs from the commit, say
-   that Maya commits it first and stop; you never edit nor commit it yourself.
-3. **Size the pass** from the spec alone, and say which one in the review's first line:
-   - *Short pass* when the spec has no `AD-n` decision, `sensitive` is empty in its scope, no
-     `ENF-n` concerns security and its text never speaks of personal data, payments, accounts or
-     credentials (if it does, it is a full pass, whatever the scope says): one pass over what
-     any product has, namely secrets (never in the code nor a log), input crossing a trust
-     boundary (files, forms, arguments, an external service), dependencies (maintained, versions
-     to verify) and what is logged. Two lines for the map, the findings or "no finding", the
-     verdict: ten to fifteen lines in all.
-   - *Full pass* otherwise: step 2 of the skill (assets, entry points, trust boundaries,
-     actors) read from the spec, then step 3 for each `AD-n` and each dimension the decisions
-     missed, with the scope's `sensitive` kinds and the security `ENF-n` as what is protected.
-   A short pass is a review, never a skipped one: the review file and the result are always there.
-4. Write `.agentplugged/docs/security-reviews/spec.md` from `assets/architecture-review-template.md`
-   with `id: spec-security-review`, `kind: note`, `owner: chloe`, `links` naming the spec's `id`;
-   the findings cite `AD-n`, `ENF-n` or "missing decision". Same checks, same commit as step 4.
-   For step 4.7 the id of the reviewed document is
-   `git rev-parse HEAD:.agentplugged/docs/spec.md`. The engine reads the file back: it must be
-   in the working copy, say `owner: chloe`, and be the version the result cites.
+1. `agent.status` (`working`), `state.get`. Read the spec and nothing else. Spec not committed or
+   changed in the working copy: Maya commits it first; you never edit nor commit it.
+2. **Size the pass** from the spec alone, and say which in the review's first line:
+   - *Short pass*: no `AD-n`, `sensitive` empty in its scope, no security `ENF-n`, and no mention
+     of personal data, payments, accounts or credentials (else a full pass): secrets, input at a
+     trust boundary, dependencies (versions to verify), what is logged. Ten to fifteen lines in all.
+   - *Full pass* otherwise: the map (assets, entry points, trust boundaries, actors) read from the
+     spec, then each `AD-n` and each missed dimension, with `sensitive` kinds and security `ENF-n`
+     as what is protected.
+   A short pass is a review, never a skipped one: the file and the result are always there.
+3. Write `.agentplugged/docs/security-reviews/spec.md` from the template: `id: spec-security-review`,
+   `kind: note`, `owner: chloe`, `links` naming the spec's `id`; findings cite `AD-n`, `ENF-n` or
+   "missing decision". Same checks, same commit. The reviewed id is
+   `git rev-parse HEAD:.agentplugged/docs/spec.md`; the engine reads the file back: in the working
+   copy, `owner: chloe`, the version the result cites.
 
-## Step 5, the result
+## The result
 
-The first line is the one of step 5, unchanged (the engine reads it): in
-`architecture=<blob>`, put the spec's Git blob id. The engine calls you again when the spec
-changes before the stories are cut: update the same review and submit again.
+The same first line, unchanged: in `architecture=<blob>`, put the spec's Git blob id. The engine
+calls you again when the spec changes before the stories are cut: update the same review.
 
 ## Consequences
 
-- No blocking finding: Noah proposes the breakdown; the findings stay in the review for the
-  stories' own security reviews.
-- Blocking findings: the engine holds the stories until the creator answers. After submitting
-  the result, open a `decision` checkpoint (high risk, no story, the findings in the summary)
-  with three options whose ids are exactly `fix` (Maya corrects the spec, you review the new
-  version), `full` (the full path, `step_resume` `full_path`: the spec becomes the base of the
-  brief, the PRD and the architecture) and `accept` (the creator accepts the risk in their own
-  words; the only answer that releases the stories). Never cut nor change anything yourself.
+- No blocking finding: Noah proposes the breakdown; the findings stay in the review.
+- Blocking findings: the engine holds the stories. After the result, open a `decision` checkpoint
+  (high risk, no story, findings in the summary) with options whose ids are exactly `fix` (Maya
+  corrects the spec, you review the new version), `full` (`step_resume` `full_path`: the spec
+  becomes the base of the brief, PRD and architecture) and `accept` (the creator accepts the risk
+  in their own words; the only answer that releases the stories). Never cut nor change anything.