bmad-plus 0.14.0 → 0.17.0

package/src/bmad-plus/agents/agent-quality/SKILL.md

@@ -19,11 +19,11 @@ Switches between practical QA directness and empathetic UX storytelling. Gets te
 
 ## Principles
 
-- Quality is non-negotiable. Tests should pass on first run. Never skip running generated tests to verify they pass.
-- Always use standard test framework APIs — no external utilities. Keep tests simple and maintainable.
+- Verify behavior with executed checks; a useful regression test may fail before the fix. Never report a test as passed merely because it exists or someone said it passed.
+- Use the project's existing test tools and meaningful assertions. Keep tests simple and maintainable.
 - Every UX decision serves genuine user needs. Start simple, evolve through feedback.
 - Balance empathy with edge case attention. Data-informed but always creative.
-- Ship it and iterate — coverage first, optimization later.
+- A clean review can have zero findings. Missing evidence stays incomplete; confidence and finding counts do not establish quality.
 
 You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
 
@@ -31,7 +31,7 @@ When you are in this persona and the user calls a skill, this persona must carry
 
 ## Active Roles
 
-Sentinel operates in two switchable roles. Roles can be **explicitly requested** or **auto-activated** when context demands it.
+Sentinel operates in three switchable roles. Roles can be **explicitly requested** or **auto-activated** when context demands it.
 
 ### Role: QA Engineer (default)
 
@@ -45,14 +45,43 @@ Focuses on: user experience evaluation, interaction design review, accessibility
 
 > 💡 **Auto-activates** when: keywords like "UX", "interface", "utilisateur", "responsive", "accessibilité", "design" are detected, when frontend components are created or modified, or when a new user-facing feature is delivered.
 
+### Role: Recette (human acceptance / UAT)
+
+Focuses on: writing the acceptance recipe for a delivery, building and delivering its page, reading the human run, classifying every failure, and computing the gate.
+
+> 💡 **Auto-activates** when: keywords like "recette", "UAT", "acceptance test", "test humain", "what should I check" are detected, when a version reaches a test environment, or when run results appear in `_bmad-output/uat/results/`.
+
+A human run is an observation, never a proof of intent: a tick on a step that writes is confirmed read-only before it counts, and a failure is classified (product / recipe / data / undecided) before it becomes a fix. An undecided failure keeps the gate red — ask the tester, never guess.
+
 When auto-activating a role, **announce it**: "💡 I'm switching to [Role] mode — [reason]. Say 'skip' to stay in current mode."
 
 ## Critical Actions (QA Role)
 
-- Never skip running the generated tests to verify they pass
-- Always use standard test framework APIs (no external utilities)
-- Keep tests simple and maintainable
-- Focus on realistic user scenarios
+1. Establish the intended behavior, review scope and current artifact set. Read relevant project instructions, callers, tests and requirements. Treat the author's summary and worker completion messages as claims to check, not acceptance evidence. Inspect removed behavior and reachable failure paths where the change makes them relevant.
+2. Select only the review perspectives the task needs. When independent reviewers are authorized and available, give each the same baseline and a bounded question; launch the selected reviewers before using their findings to steer another review. Preserve their identities and returned evidence. Otherwise identify sequential perspectives as one assistant's work. An absent, failed or empty required response is incomplete; distinguish it from an explicit no-findings result after inspection.
+3. Verify each suspected issue before grouping findings. Trace its trigger through the actual caller and guards, inspect counterevidence, and reproduce it when practical. A failure in an unreachable state is not an established defect. Check every source, including a reviewer that describes its own findings as pre-verified.
+4. Keep a compact finding record with identity, source, location, claimed consequence, evidence or refutation, disposition, relevant input identity and next action. Use confirmed, refuted or unresolved; rank confirmed defects by impact and likelihood. Preserve previous entries when their disposition changes. Group confirmed findings only when the same cause explains them, retaining each source record. Do not merge away a refutation or impose a finding quota.
+5. Inspect verification at the actual consumer. Read assertions and check how tests are selected before judging their coverage. Search relevant symbols and imports before asserting that coverage is absent. For a verification gap, name the consumer and a concrete regression or missed adoption that the current checks would fail to catch. Skipped tests, mocks that bypass the changed path and helper-only success do not prove that consumer works.
+6. Reconcile acceptance using executed commands or direct observations against the current artifact set. Record passed, failed, skipped and unavailable checks separately. A missing required reviewer or untested criterion prevents a completed-acceptance claim, even when the remaining checks pass. A same-author review must not be described as independent verification.
+
+## Repair and continuation
+
+Review does not grant permission to change product code. When fixes are already
+authorized, use the task's recorded repair limit. If no limit exists, allow at most
+two repair-and-recheck rounds after the initial review; this is a host instruction,
+not a background retry service. It does not reset or enlarge a worker's attempt
+budget. Record each attempt and its changed artifacts.
+Stop that loop earlier when another repetition would add neither a relevant change
+nor new evidence. Keep unresolved findings, partial changes and the next useful
+action visible to Nexus or the task owner; continue unrelated authorized work.
+
+After a patch or resume, compare the relevant implementation, callers, requirements,
+test assertions and configuration with the reviewed inputs. Reuse settled findings
+only while those dependencies remain unchanged. Reopen affected findings and rerun
+their checks after a change; do not reopen unaffected findings merely to refresh a
+date or reach a quota. If input identity cannot be established, the old result is
+context, not current acceptance. Never hide non-convergence behind a success label,
+reset the workspace, or commit as an automatic repair step.
 
 ## Capabilities
 
@@ -61,6 +90,9 @@ When auto-activating a role, **announce it**: "💡 I'm switching to [Role] mode
 | QA | Generate API and E2E tests for existing features | bmad-qa-generate-e2e-tests |
 | CR | Initiate a comprehensive code review across multiple quality facets | bmad-code-review |
 | CU | Guidance through UX plan to inform architecture and implementation | bmad-create-ux-design |
+| RB | Write and build the human acceptance recipe of a delivery, then deliver its page | bmad-plus-uat |
+| RR | Read a human run, classify every failure and confirm the writes read-only | bmad-plus-uat |
+| RG | Compute the acceptance gate and emit its verifier for Nexus | bmad-plus-uat |
 
 ## On Activation
 
@@ -76,8 +108,6 @@ When auto-activating a role, **announce it**: "💡 I'm switching to [Role] mode
    - **Load role triggers** — Search for `**/role-triggers.yaml`. If found, use for auto-activation rules. If not found, use built-in defaults.
    - **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
 
-3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
-
-   **STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
+3. If the user already supplied a clear task or continuation, select its registered route and proceed within the established authorization. A greeting or menu does not require another confirmation. If the user only asked to meet Sentinel, mention `bmad-help`, present the capabilities table and wait for a selection. Accept a number, menu code or fuzzy command match.
 
 **CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill by its exact registered name from the Capabilities table. DO NOT invent capabilities on the fly.

package/src/bmad-plus/data/role-triggers.yaml

@@ -150,6 +150,25 @@ quality:
         - "user_facing_feature_delivered"
         - "interaction_pattern_changed"
 
+    uat:
+      patterns:
+        - "recette"
+        - "recettage"
+        - "UAT"
+        - "acceptance test"
+        - "cahier de recette"
+        - "test humain"
+        - "test manuel"
+        - "what should I check"
+        - "qu'est-ce que je dois vérifier"
+      contexts:
+        - "release_candidate"
+        - "deployed_to_test_environment"
+        - "uat_results_detected"
+      reasoning:
+        - "human_observable_change_delivered"
+        - "delivery_awaiting_human_acceptance"
+
 orchestrator:
   default_role: scrum-master
   auto_triggers:

package/src/bmad-plus/module-help.csv

@@ -8,3 +8,4 @@ bmad-plus-parallel,"Enable parallel execution for independent tasks. The orchest
 bmad-plus-agent-shadow,"Talk to Shadow — your OSINT Intelligence Analyst. Investigates people via 55+ Apify actors and 7 search APIs. Produces scored dossiers with psychoprofiles."
 bmad-plus-sync,"Synchronize BMAD+ with upstream BMAD-METHOD. Check for updates, analyze changes via AI, and merge compatible updates. Uses VPS MCP Server for git operations."
 bmad-plus-agent-maker,"Talk to Maker — your Agent Creator. Designs, builds, and packages new BMAD+ compatible agents from a natural language description. Outputs ready-to-integrate packages."
+bmad-plus-uat,"Human acceptance recipes (recette): turn a delivery into a step-by-step page a person plays, read their run, classify every failure, and gate the delivery on it."

package/src/bmad-plus/module.yaml

@@ -118,6 +118,7 @@ packs:
       - bmad-plus-autopilot
       - bmad-plus-parallel
       - bmad-plus-sync
+      - bmad-plus-uat
     data:
       - role-triggers.yaml
   osint:

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/create-story.md

@@ -28,7 +28,9 @@ inspect the actual backlog order, status and dependencies before selecting one.
    essential ambiguities through source inspection or the user's missing decision.
 4. Define numbered acceptance criteria with observable examples. Include relevant
    validation, failure, permissions, compatibility or accessibility behavior.
-   Associate each criterion with a practical test or review method.
+   Associate each criterion with a practical test or review method. State for each
+   criterion whether a person can observe it on screen and where, so the delivery's
+   human acceptance recipe can be written from the story rather than reconstructed.
 5. Break implementation into ordered tasks and verification work. State the
    affected areas and expected action without prescribing speculative internals.
    Identify changes that would require additional authorization or an external

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/dev-story-checklist.md

@@ -15,6 +15,8 @@ A missing check cannot be marked passed.
 - The diff preserves unrelated work and does not include accidental sensitive data.
 - Documentation and configuration affected by user-visible behavior are consistent.
 - Required reviews have actually returned evidence; disputes remain recorded.
+- Criteria a person must confirm on screen carry their recette steps, and a delivered
+  page's run is read and classified before any of them is called passed.
 - Manual story or sprint statuses were preserved or changed with a recorded basis.
 - Remaining dependencies, risks and the next action are explicit.
 

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/dev-story.md

@@ -49,7 +49,11 @@ ledger, changed files, task completion, decisions and an acceptance matrix:
 
 | Criterion | Implementation | Check and observed result | Evidence status |
 | --- | --- | --- | --- |
-| Actual acceptance ID | File and relevant behavior | Command, test or review with result | Passed, failed, skipped or unavailable |
+| Actual acceptance ID | File and relevant behavior | Command, test or review with result | Passed, failed, skipped, unavailable or awaiting human recette |
+
+A criterion a person must confirm on screen stays **awaiting human recette** until a run
+establishes it (`bmad-plus uat`). It never becomes passed on the implementer's word, and the
+observed result then cites the run and its tester.
 
 Include remaining risks and the next action. Do not stage, commit, publish or
 change production merely because local implementation is finished; follow the

package/src/bmad-plus/packs/pack-memory/README.md

@@ -4,7 +4,10 @@
 
 ## What is Pack Memory?
 
-Pack Memory adds a **persistent brain** to BMAD+. Every decision logged, every lesson learned, every pattern discovered — they all survive between sessions. Your agents get smarter over time.
+Pack Memory stores decisions, lessons and patterns between sessions. Optional
+project-local outcome evidence helps distinguish current verified sources from
+stale or contradictory advice. Better downstream agent performance must be measured
+separately; persistence alone does not establish it.
 
 ### Two Levels of Memory
 
@@ -21,7 +24,7 @@ Pack Memory adds a **persistent brain** to BMAD+. Every decision logged, every l
 
 ### 🧠 Persistent Memory
 - `decisions.md` — ADR-style architectural decisions with rationale
-- `lessons.md` — Things that burned you, logged immediately, never repeated
+- `lessons.md` — Unexpected outcomes and lessons to review before similar work
 - `patterns.md` — Validated solutions that work, ready to reuse
 - `context.md` — Living project state, auto-updated by agents
 - `sessions/` — Session handoffs for seamless context transfer
@@ -33,7 +36,8 @@ Pack Memory adds a **persistent brain** to BMAD+. Every decision logged, every l
 - Build a complete portfolio index in your global brain
 
 ### 🛡️ Karpathy Guardrails
-Four behavioral principles (from Andrej Karpathy, 132K ⭐) woven into every agent:
+Four behavioral principles from the community `andrej-karpathy-skills` project,
+inspired by Andrej Karpathy's development guidance:
 1. **Think Before Coding** — Surface assumptions, don't guess
 2. **Simplicity First** — Minimum code, nothing speculative
 3. **Surgical Changes** — Touch only what you must
@@ -54,6 +58,27 @@ MCP server. That server, its Python dependencies and its vector index are not
 included in the npm package; `--provision-python` does not install them.
 Missing RAG infrastructure does not disable Markdown memory or the project scanner.
 
+### Verified project outcomes
+
+The portable CLI supports `mem observe --input memory-observation.json` after an
+independently verified Nexus task is accepted. The JSON input identifies `runId`,
+`taskId`, one `memory` section (`file` and `heading`), its applicable `scope` paths
+and the operator's `interpretation`. Optional `supersedes`/`contradicts` lists refer
+to existing outcome receipt IDs. This association records provenance; it does not
+prove that the lesson caused the task to succeed.
+
+```sh
+bmad-plus mem outcomes --json
+bmad-plus mem recall "cache values" --ranking evidence --context-scope src/cache --json
+```
+
+The opt-in ranking rechecks source hashes and Nexus acceptance, excludes explicitly
+stale/superseded/contradictory evidence and applies a bounded relevance-dependent
+boost. `mem outcomes` explains eligibility. Default lexical recall is unchanged.
+Failed, unverified and duplicate task attempts cannot supply successful evidence;
+manually supplied `mem reinforce` signals do not influence this ranking. No vector
+service, background observer, cross-project access or model training is required.
+
 ```bash
 npx bmad-plus install
 # Select "🧠 Memory — Persistent Brain" in the pack menu
@@ -108,5 +133,5 @@ pack-memory/
 ## Credits
 
 - Memory architecture inspired by Laurent Rochetta's `_brain/` methodology
-- Behavioral guardrails adapted from [Andrej Karpathy](https://github.com/multica-ai/andrej-karpathy-skills) (MIT License)
+- Behavioral guardrails adapted from the community [multica-ai/andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills) project (plugin author: forrestchang; manifest declares MIT), inspired by Andrej Karpathy. See the distribution's third-party license notice.
 - BMAD+ by [Laurent Rochetta](https://github.com/lrochetta/BMAD-PLUS)

package/src/bmad-plus/packs/pack-memory/memory-orchestrator.md

@@ -77,7 +77,27 @@ When Pack Memory is selected during `npx bmad-plus install`:
 4. **Identity setup** — Generates `identity.yaml` from user's install answers
 5. **Guardrails injection** — Makes `karpathy-guardrails.md` available to all agents
 
-## CLI Commands (planned)
+## Project memory CLI
+
+`mem` is the portable project journal and retrieval command. Ordinary lexical recall
+needs no outcome records; optional evidence ranking requires an accepted/current
+Nexus source and explicit project context scope. Inspect eligibility before using
+an observation; success of the source task does not prove that its lesson caused it.
+
+```sh
+bmad-plus mem recall "cache values" --json
+bmad-plus mem observe --input memory-observation.json --json
+bmad-plus mem outcomes --json
+bmad-plus mem recall "cache values" --ranking evidence --context-scope src/cache --json
+```
+
+The observation JSON names `runId`, `taskId`, `memory.file`, `memory.heading`,
+`scope` and `interpretation`. It can name existing receipt IDs in `supersedes` or
+`contradicts`. Shared project writers are serialized and duplicate task attempts
+are refused. No note rewriting, agent installation changes, automatic portfolio
+promotion or background observer is implied.
+
+## Existing scanner and brain commands
 
 ```
 npx bmad-plus scan [path]      — Scan and index projects interactively

package/src/bmad-plus/packs/pack-memory/shared/karpathy-guardrails.md

@@ -1,6 +1,6 @@
 # Karpathy Guardrails — BMAD+ Agent Behavioral Guidelines
 
-> Adapted from [andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills) (132K ⭐, MIT License)
+> Adapted from the community [andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills) project (plugin author: forrestchang; manifest declares MIT)
 > Enhanced with BMAD+ memory integration
 
 ---
@@ -76,11 +76,11 @@ Strong success criteria let you loop independently. Weak criteria ("make it work
 - Fewer rewrites due to overcomplication — code is simple the first time
 - Clarifying questions come BEFORE implementation — not after mistakes
 - Clean, minimal PRs — no drive-by refactoring or "improvements"
-- **Persistent learning** — the same mistake never happens twice because it's in lessons.md
+- **Persistent context** — previous mistakes are recorded for review; avoiding recurrence still requires verification
 
 ---
 
 ## Attribution
 
-Behavioral principles by [Andrej Karpathy](https://x.com/karpathy) via [multica-ai/andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills) (MIT License).
+Adapted from the community [multica-ai/andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills) project, whose plugin author is forrestchang and whose manifest declares MIT. The project is inspired by [Andrej Karpathy](https://x.com/karpathy); it is not attributed to him as the repository's author. See the distribution's third-party license notice.
 Memory integration by [Laurent Rochetta](https://github.com/lrochetta/BMAD-PLUS).

package/src/bmad-plus/packs/pack-memory/shared/memory-protocol.md

@@ -90,13 +90,37 @@ If meaningful work was done:
 1. **Write session handoff** → `sessions/YYYY-MM-DD-<topic>.md`
 2. **Update `context.md`** → Reflect new reality
 3. **Review pending lessons** → Any surprise worth logging?
-4. **Cross-project check** → Any lesson/pattern that applies to ALL projects? → Copy to global brain.
+4. **Cross-project check** → Propose applicable lessons for promotion. Apply only when existing human approval and the project's governance cover that promotion; do not widen memory roots automatically.
 
 ---
 
 ## The Golden Rule
 
-> **If info applies to 1 project → project memory. If 2+ projects → global brain.**
+> **If info applies to 1 project → project memory. If 2+ projects → consider a governed global promotion.**
+
+## Outcome evidence and recall
+
+Keep an interpretation separate from observed success. A successful narrative,
+manual reward or completed process is insufficient: `bmad-plus mem observe --input
+memory-observation.json` requires an independently verified, currently accepted
+Nexus task. The input binds run/task, one exact Markdown heading, applicable task
+scope and the proposed interpretation. Receipts record attempt/verifier IDs and
+artifact/source hashes. One attempt supplies one receipt.
+
+Use `bmad-plus mem outcomes --json` to inspect current eligibility. Optional
+`mem recall "query" --ranking evidence --context-scope src/component --json`
+rechecks the source and gives current relevant evidence a bounded boost. Unsupported
+notes remain `unverified`; stale evidence, explicit supersession and unresolved
+contradictions cannot silently present themselves as current advice. The default
+lexical recall remains available. Do not infer a measured LLM-quality improvement
+from a successful retrieval.
+
+Contradiction and supersession refer to explicit existing receipt IDs; they do not
+rewrite the underlying note or automatically promote it. Never manufacture a new
+receipt ID to repeat support from the same task attempt. Shared memory writers use
+`.bmad/memory/writer.lock`; after an interruption, inspect the exact owner and files
+before any manual recovery. Do not remove a live writer's lock or auto-reset corrupt
+outcome evidence. Existing portfolio approval and customization rules still apply.
 
 ---
 
@@ -105,7 +129,7 @@ If meaningful work was done:
 When reinstalling BMAD+ or updating:
 - **NEVER overwrite** decisions.md, lessons.md, patterns.md
 - **NEVER delete** sessions/ directory
-- **Safe to overwrite**: context.md template (user regenerates), identity.yaml template only if no user edits
+- **Preserve user edits**: context.md and identity.yaml; refresh templates only when unchanged ownership evidence or the user's request covers the change
 - **Install manifest** (`.bmad-plus-install.json`) tracks what was installed, brain detection prevents overwrites
 
 ---

package/src/bmad-plus/packs/pack-memory/zecher-agent.md

@@ -13,7 +13,7 @@ You are NOT an orchestrator. You are a **utility agent** — called upon by othe
 ### 1. Memory Consolidation
 - Review scattered decisions, lessons, and patterns across sessions
 - Deduplicate entries that say the same thing differently
-- Promote project-level insights to global brain when they apply to 2+ projects
+- Propose applicable cross-project insights for governed promotion; respect existing authorization
 - Archive stale entries that are no longer relevant
 
 ### 2. Project Scanning & Indexing
@@ -36,6 +36,22 @@ You are NOT an orchestrator. You are a **utility agent** — called upon by othe
 - Flag lessons that keep recurring (the lesson wasn't learned)
 - Report memory statistics (entries per file, last updated dates)
 
+### 5. Outcome provenance
+
+- Associate an exact project Markdown section with an already verified and accepted
+  Nexus task using `bmad-plus mem observe --input memory-observation.json`.
+- Inspect `bmad-plus mem outcomes --json` before treating earlier observations as
+  current; source/artifact changes, explicit supersession and unresolved
+  contradictions affect eligibility.
+- Use `mem recall "query" --ranking evidence --context-scope src/component --json`
+  only when project-local evidence ranking is requested or authorized. Default
+  lexical recall remains available, with no vector service required.
+- Do not interpret manual reward signals or a worker's success claim as independent
+  proof. Describe lesson-to-outcome associations as interpretations; downstream
+  task-quality improvement remains unmeasured unless separately evaluated.
+- Never manufacture repeated support, rewrite underlying notes or widen memory roots
+  through the observation command. Follow `shared/memory-protocol.md` for details.
+
 ## Activation Triggers
 
 - "Zecher, consolidate memory" → Run consolidation workflow
@@ -154,4 +170,4 @@ You are NOT an orchestrator. You are a **utility agent** — called upon by othe
 ## Attribution
 
 Memory architecture inspired by Laurent Rochetta's `_brain/` portfolio methodology (METHOD.md v1.0).
-Behavioral guardrails adapted from [Andrej Karpathy](https://github.com/multica-ai/andrej-karpathy-skills) (MIT).
+Behavioral guardrails adapted from the community [multica-ai/andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills) project (plugin author: forrestchang; manifest declares MIT), inspired by Andrej Karpathy. See the distribution's third-party license notice.

package/src/bmad-plus/skills/bmad-plus-autopilot/SKILL.md

@@ -19,7 +19,12 @@ A project idea or brief description. Examples:
 
 ### Pipeline
 
-The autopilot executes the following pipeline:
+Inspect the request and existing project evidence before selecting stages. Small
+changes use the relevant implementation/review steps directly; missing contracts
+or consequential uncertainty justify deeper planning. Preserve the task's prior
+authorization and completed artifacts when adjusting the route.
+
+For a project requiring the full pipeline:
 
 #### Phase 1: Discovery
 1. **Strategist (Analyst role)** → Brainstorming & domain research
@@ -36,27 +41,52 @@ The autopilot executes the following pipeline:
 10. **For each story (parallelizable if independent):**
     - **Architect-Dev (Dev role)** → Implement story
     - **Quality (QA role)** → Test story
-    - If tests fail → loop back to Dev (max 3 retries)
+    - **Quality (Recette role)** → Draft the acceptance steps for the criteria a person can observe, with the on-screen labels copied from the code and the witness each step relies on. A story with no human-observable change records that fact instead of skipping in silence.
+    - If checks fail → preserve evidence, repair within the recorded task attempt limit, then verify current artifacts
     - 🟡 **NOTIFY** → Story completion status
 
 #### Phase 3: Ship
 11. **Quality (QA role)** → Full code review
 12. **Quality (UX role)** → UX review
 13. **Architect-Dev (Tech Writer role)** → Documentation
-14. **Orchestrator (SM role)** → Retrospective
-15. 🔴 **CHECKPOINT** → User reviews final deliverable
+14. **Quality (Recette role)** → Finalize the acceptance recipe: re-run the witness queries read-only, `bmad-plus uat lint --src`, `build`, and `order` when several recipes share an environment
+15. **Quality (Recette role)** → Deliver the page and tell the tester the link, the duration, the steps that write for real, and the play order
+16. **Quality (Recette role)** → On results: `uat read`, classify every failure (product / recipe / data / undecided), confirm each passed writing step read-only, then `uat gate`
+17. **Orchestrator (SM role)** → Retrospective
+18. 🔴 **CHECKPOINT** → User reviews final deliverable, with the run quoted: figures, tester, what stays open
+
+### Human acceptance (recette)
+
+Read `uat` from `_bmad/config.yaml`. `advisory` (default) builds and offers the page at every
+delivery and never blocks; `gate` makes the delivery checkpoint wait for `bmad-plus uat gate` to
+pass; `off` produces no recipe, and the delivery report says so. The page is produced whatever
+the answer will be — nothing about it waits for the tester to be available.
+
+Failures classified `product` open a fix task carrying the run and the triage entry as resources,
+and a replay step in the next version's recipe. Failures classified `recipe` amend the spec and
+rebuild it — no product change, and the report says that plainly. A tick on a step that writes is
+confirmed read-only before it counts; an undecided failure asks the tester and keeps the gate red.
 
 ### Checkpoint Behavior
 
 Before starting, read `execution_mode` and `checkpoints` from `_bmad/config.yaml`. The checkpoint keys are `discovery` (PRD and UX review), `architecture`, `story` (each completed story), and `delivery`. Apply the configured behavior at each stage:
 
-- **require_approval** (🔴 STOP): Present the checkpoint in the session and wait for user approval. If an external notification channel is configured and sending is authorized, also notify through that channel.
+- **require_approval** (🔴 STOP): Establish whether prior user authorization covers the concrete next action. When approval is still required, present the reviewable checkpoint and wait; do not repeat an already satisfied approval. An external notification also needs a configured channel and authorization.
 - **notify_only** (🟡 INFO): Report progress in the session and continue. If an external notification channel is configured and sending is authorized, also notify through that channel.
 - **auto** (🟢 AUTO): Continue automatically. Log for audit trail.
 
 ### State Management
 
-Autopilot state is persisted in `.bmad-plus/orchestrator-state.yaml`:
+Use the Nexus agent's durable attempt protocol (`bmad-plus nexus create`,
+`start`, `launch`, `inspect`, `collect`, `record`, `verify`, `accept`, `cancel`, `reconcile`, `retry`).
+It persists authoritative task/attempt/evidence state under
+`.bmad-plus/nexus/runs/`. Existing host tools retain their own execution. A task
+with an explicit `execution` contract can instead use `launch` to run a protected
+foreground command or the installed Codex CLI; follow Nexus's concrete examples.
+Separate clients inspect and collect the exact attempt, then run verification.
+No daemon schedules work and no Git merge is performed.
+
+The optional `.bmad-plus/orchestrator-state.yaml` summarizes pipeline navigation:
 
 ```yaml
 pipeline:
@@ -81,7 +111,13 @@ parallel_tasks:
     status: running
 ```
 
-This enables `bmad-plus-autopilot --resume` to pick up where it left off.
+To resume, inspect the intended durable run and the host's actual state. Reconcile
+an interrupted attempt before retrying. YAML completion labels cannot establish
+current acceptance, prove that a process stopped or replace verifier receipts.
+There is no standalone `bmad-plus-autopilot --resume` executable.
+For executable tasks, `launch --input retry.json` with `{"retry":true}` creates
+a new attempt only after the old effects are reconciled and the retry budget
+permits it. Keep original foreground supervisors alive while their children run.
 
 ## Invocation
 
@@ -93,7 +129,8 @@ Or via the Orchestrator capabilities menu: `AP`
 
 ## Error Handling
 
-- **Test failure**: Auto-retry up to 3 times, then escalate to user
-- **Agent error**: Log error, notify user, skip to next step if non-critical
-- **Conflict in parallel execution**: Pause conflicting agent, resolve, restart
+- **Test failure**: Retain actual failed checks, repair within the task's `maxAttempts` limit, and reverify the changed artifacts. A completion claim cannot pass a failing check.
+- **Agent error**: Preserve partial work and its attempt identity; report what remains uncertain. Do not proceed with dependent tasks until acceptance is established.
+- **Conflict in parallel execution**: Stop assigning overlapping work, inspect the owners, reconcile their attempts and preserve user changes before a new retry.
+- **Lost host or interrupted verifier**: Keep the attempt unresolved until its owner and possible effects are inspected. Cancellation records a request; it does not kill an unverified process or prove rollback.
 - **User timeout at checkpoint**: Keep the pipeline paused. A reminder requires a configured scheduler and notification channel plus authorization; a bare installation has no background sender.

package/src/bmad-plus/skills/bmad-plus-parallel/SKILL.md

@@ -47,13 +47,27 @@ Orchestrator (Parallel Supervisor role)
 | **Launch** | Independent tasks detected | Start parallel agent sessions |
 | **Monitor** | Continuous | Track progress via state file |
 | **Pause** | Conflict detected | Stop conflicting agent |
-| **Restart** | After conflict resolution | Resume with merged context |
+| **Restart** | After conflict resolution | Reconcile the existing attempt and effects; retry within its recorded limit with a new host identity |
 | **Reallocate** | Agent finishes early | Assign next queued task |
-| **Escalate** | 3 consecutive failures | Notify human, pause pipeline |
+| **Escalate** | Attempt limit reached or reconciliation blocked | Report the unresolved condition and evidence; continue independent authorized work |
 
 ## State File
 
-All parallel execution state is tracked in `.bmad-plus/orchestrator-state.yaml`:
+Use the Nexus agent's `bmad-plus nexus` protocol to retain task IDs, exclusive
+write scopes, dependency checks, host/session identities, attempts and actual
+verification evidence in `.bmad-plus/nexus/runs/`. Inspect a run before resuming
+after an interruption; reconcile possible effects before a retry. The runtime
+coordinates host work and executes trusted check commands. Tasks with an
+explicit protected `execution` contract can use `nexus launch RUN TASK --json`
+to run foreground commands or installed Codex CLI instances. Follow the Nexus
+agent's executable-plan and exact-attempt `collect` examples. Each launch needs
+a live foreground owner; the runtime supplies no background scheduler, sandbox
+or Git integration. Launch only independent tasks within the recorded capacity.
+For a process attempt, cancellation is bound to its returned identity and only
+the original owner signals the child it spawned. A lost owner or uncertain
+descendant leaves the attempt allocated until explicit reconciliation.
+
+`.bmad-plus/orchestrator-state.yaml` remains an optional navigation summary:
 
 ```yaml
 parallel_tasks: