bmad-plus 0.21.0 → 0.23.0

package/src/bmad-plus/packs/pack-shield/review-rules/index.yaml

@@ -0,0 +1,134 @@
+# Shield compliance review rules, applied by path once the Shield pack is installed.
+# They add to the built-in rules (a pack never replaces or disables one); a project replaces
+# or disables them by id in _bmad/review-rules.yaml. Every rule names the controls it
+# examines as FRAMEWORK:ID (bmad-plus review rules lists them), so a checklist can say which
+# controls a change touches. All rules share the `compliance` group: one parallel reviewer
+# can take them together.
+schema: bmad-plus/review-rules/1
+rules:
+  - id: shield-access-control
+    title: Identity, authentication and authorisation
+    group: compliance
+    globs:
+      - '**/{auth,authn,authz,login,session,sessions,permissions,rbac,acl,oauth,oidc,sso,iam,guards,policies}/**'
+      - '**/*{auth,Auth,session,Session,permission,Permission,policy,Policy}*.*'
+    controls:
+      [
+        ISO27001:A.5.15,
+        ISO27001:A.5.18,
+        ISO27001:A.8.2,
+        ISO27001:A.8.5,
+        SOC2:CC6.1,
+        SOC2:CC6.2,
+        SOC2:CC6.3,
+        NIST-800-53:AC-3,
+        NIST-800-53:AC-6,
+        NIST-800-53:IA-2,
+        NIS2:Art.21(2)(i),
+        NIS2:Art.21(2)(j),
+      ]
+    doc: access-control.md
+  - id: shield-personal-data
+    title: Personal data in models, schemas and migrations
+    group: compliance
+    globs:
+      - '**/{models,entities,schemas,schema,dto,dtos,migrations,migrate}/**'
+      - '**/*{user,User,customer,Customer,profile,Profile,account,Account,contact,Contact,consent,Consent,privacy,Privacy}*.*'
+    controls:
+      [
+        GDPR:Art.5(1)(c),
+        GDPR:Art.5(1)(e),
+        GDPR:Art.25,
+        GDPR:Art.30,
+        GDPR:Art.32,
+        ISO27001:A.5.34,
+        ISO27001:A.8.10,
+        ISO27001:A.8.11,
+        SOC2:P4.2,
+        SOC2:P4.3,
+      ]
+    doc: personal-data.md
+  - id: shield-cryptography
+    title: Cryptography, keys and secrets handling
+    group: compliance
+    globs:
+      - '**/{crypto,cryptography,security,secrets,certs,certificates,tls,vault,kms}/**'
+      - '**/*{crypt,Crypt,cipher,Cipher,hash,Hash,signature,Signature,token,Token,secret,Secret}*.*'
+    controls:
+      [
+        ISO27001:A.8.24,
+        ISO27001:A.5.17,
+        SOC2:CC6.1,
+        SOC2:CC6.7,
+        NIST-800-53:SC-8,
+        NIST-800-53:SC-12,
+        NIST-800-53:SC-13,
+        NIST-800-53:SC-28,
+        GDPR:Art.32(1)(a),
+        NIS2:Art.21(2)(h),
+      ]
+    doc: cryptography.md
+  - id: shield-logging
+    title: Logging, audit trail and monitoring
+    group: compliance
+    globs:
+      - '**/{logs,logger,logging,audit,telemetry,observability,monitoring,metrics,tracing}/**'
+      - '**/*{logger,Logger,logging,Logging,audit,Audit,telemetry,Telemetry}*.*'
+    controls:
+      [
+        ISO27001:A.8.15,
+        ISO27001:A.8.16,
+        ISO27001:A.8.17,
+        SOC2:CC7.2,
+        SOC2:CC7.3,
+        NIST-800-53:AU-2,
+        NIST-800-53:AU-3,
+        NIST-800-53:AU-9,
+        NIST-800-53:AU-11,
+        GDPR:Art.5(1)(c),
+        NIS2:Art.23,
+      ]
+    doc: logging.md
+  - id: shield-ai-integrations
+    title: AI models, prompts and agent tooling
+    group: compliance
+    globs:
+      - '**/{ai,llm,llms,prompts,agents,mcp,rag,embeddings}/**'
+      - '**/*{openai,OpenAI,anthropic,Anthropic,gemini,Gemini,llm,LLM,prompt,Prompt}*.*'
+      - '**/{.mcp.json,mcp.json}'
+      - '{CLAUDE,GEMINI,AGENTS,CONVENTIONS}.md'
+      - '{.claude,.cursor,.codex,.opencode,.gemini}/**'
+    controls:
+      [
+        GDPR:Art.28,
+        GDPR:Art.35,
+        GDPR:Art.44,
+        EU-AI-Act:Art.50,
+        ISO27001:A.5.19,
+        ISO27001:A.5.23,
+        ISO27001:A.8.12,
+      ]
+    doc: ai-integrations.md
+  - id: shield-change-and-supply-chain
+    title: Change control and supply chain
+    group: compliance
+    globs:
+      - '.github/workflows/**/*.{yml,yaml}'
+      - '**/{.gitlab-ci.yml,azure-pipelines.yml,bitbucket-pipelines.yml,CODEOWNERS}'
+      - '**/{package.json,pyproject.toml,requirements*.txt,go.mod,Cargo.toml,composer.json,Gemfile}'
+      - '**/{Dockerfile,Containerfile}'
+    controls:
+      [
+        ISO27001:A.8.25,
+        ISO27001:A.8.32,
+        ISO27001:A.5.21,
+        ISO27001:A.8.9,
+        SOC2:CC8.1,
+        SOC2:CC7.1,
+        NIST-800-53:CM-3,
+        NIST-800-53:SA-10,
+        NIST-800-53:SR-3,
+        NIS2:Art.21(2)(d),
+        NIS2:Art.21(2)(e),
+      ]
+    doc: change-and-supply-chain.md

package/src/bmad-plus/packs/pack-shield/review-rules/logging.md

@@ -0,0 +1,10 @@
+A log is evidence for an investigation and a store of personal data at the same time.
+
+- **Security events.** Sign-in success and failure, access denied, privilege and role changes, exports, deletions and configuration changes are logged with who, what, when and from where. A security-relevant path the change adds without an event is a gap.
+- **Content.** No passwords, tokens, keys, full card numbers, session ids or request bodies with personal data in log lines, traces, metrics labels or error reports. Identifiers are pseudonymised where the investigation does not need them in clear.
+- **Integrity.** Audit records cannot be edited or deleted by the application account that writes them; a change that routes audit events through a mutable table or a best-effort queue that drops on failure weakens the trail.
+- **Time.** Timestamps are in UTC from a synchronised clock and carry their zone; ordering never depends on a client-supplied time.
+- **Retention.** The retention of new logs is set, matches the policy for their content, and is shorter for logs holding personal data than for pure security events where the policy says so.
+- **Detection.** An alert or dashboard that the change removes, renames or silences is called out: incident detection and notification deadlines depend on it.
+
+Name the control a finding breaks (for example `ISO27001:A.8.15` for logging) in the finding's description.

package/src/bmad-plus/packs/pack-shield/review-rules/personal-data.md

@@ -0,0 +1,10 @@
+Follow each personal field from where it enters to where it is deleted.
+
+- **Minimisation.** A new field, column or payload property that identifies a person has a purpose the feature needs now. Collecting "in case" is the defect; so is copying a whole user object into another table, a cache, an event or a third-party call.
+- **Special categories.** Health, biometric, political, religious, sexual orientation, criminal or children's data needs its own legal basis and safeguards; flag it even when the rest of the change is clean.
+- **Retention and deletion.** Data added here has a retention period, and account deletion or an erasure request reaches it: backups, search indexes, analytics exports, soft-deleted rows and denormalised copies included.
+- **Masking.** Identifiers and contact details are masked or pseudonymised where the full value is not needed: admin lists, logs, support views, test fixtures and seed data.
+- **Migrations.** A migration that copies, backfills or widens personal data states why; a rollback does not resurrect erased data; a new nullable column that will hold personal data has a default that collects nothing.
+- **Records of processing.** A new purpose, recipient or category of data subject is a change to the record of processing activities; say so in the finding so the register is updated.
+
+Name the control a finding breaks (for example `GDPR:Art.5(1)(c)` for minimisation) in the finding's description.

package/src/bmad-plus/packs/pack-shield/shared/ai-processing-register-template.yaml

@@ -0,0 +1,53 @@
+# AI processing register (bmad-plus/ai-processing-register/1).
+#
+# Start with `bmad-plus ai-register init` (it writes _bmad/ai-processing-register.yaml)
+# and describe every AI tool the project uses:
+# coding assistants, agent CLIs, model APIs called by the product, MCP servers. Then:
+#   bmad-plus ai-register check
+# warns about any AI integration found in the project (adapter files such as CLAUDE.md,
+# tool folders such as .cursor/, servers declared in .mcp.json) that no entry covers.
+# `bmad-plus doctor` reports the same when the Shield pack is installed. A missing entry
+# never fails a build: the register is a record of processing, kept honest by review.
+#
+# integrations: the ids this entry covers. Tool ids are those of the BMAD+ adapters
+#   (claude-code, gemini-cli, antigravity, cursor, codex-cli, opencode, aider) or of other
+#   tools (github-copilot, windsurf, continue); an MCP server is mcp:<name as declared>.
+# legalBasis (GDPR Art. 6(1)), only when personalData is true: consent, contract,
+#   legal-obligation, vital-interests, public-task, legitimate-interests.
+# transfers: every destination outside the EEA with its mechanism: adequacy-decision,
+#   standard-contractual-clauses, binding-corporate-rules, derogation. [] when none.
+# Every value below is an example: replace it with what the provider's terms actually say.
+schema: bmad-plus/ai-processing-register/1
+controller: Example Ltd, 1 Example Street, Example City
+reviewed: 2026-09-29
+
+tools:
+  - id: coding-assistant
+    name: Claude Code
+    provider: Anthropic PBC
+    integrations: [claude-code]
+    purpose: Assist developers in reading, writing and reviewing the code of this repository.
+    data:
+      - Source code and commit history of this repository
+      - File contents and command output the developer shares in a session
+    personalData: true
+    legalBasis: legitimate-interests
+    retention: The period set by the provider's terms for the plan in use, written here in days.
+    transfers:
+      - to: United States
+        mechanism: standard-contractual-clauses
+    agreement: Data processing addendum attached to the commercial terms.
+
+  - id: issue-tracker-connector
+    name: GitHub MCP server
+    provider: GitHub, Inc.
+    integrations: ['mcp:github']
+    purpose: Let the coding assistant read and comment on issues and pull requests.
+    data:
+      - Issue and pull-request text, including contributor names and handles
+    personalData: true
+    legalBasis: legitimate-interests
+    retention: Not stored by the connector; the assistant's retention applies to what it reads.
+    transfers:
+      - to: United States
+        mechanism: standard-contractual-clauses

package/src/bmad-plus/packs/pack-shield/shared/ai-processing-register.md

@@ -0,0 +1,32 @@
+# AI Processing Register
+
+> Procedure used by Shield when a user asks which AI tools touch the project's data, prepares a record of processing (GDPR Art. 30), a DPIA involving AI tooling, or an ISO 27001 / ISO 42001 supplier review. Template: `shared/ai-processing-register-template.yaml`. Tooling: `bmad-plus ai-register init|check`, and `bmad-plus doctor` when Shield is installed.
+
+## What it produces
+
+`_bmad/ai-processing-register.yaml`: one entry per AI tool the project uses — coding assistants, agent CLIs, model APIs called by the product, MCP servers — with its provider, purpose, the categories of data it sees, whether that includes personal data and on which legal basis, retention, transfers outside the EEA with their mechanism, and the processing agreement in place.
+
+## Steps
+
+1. **Inventory.** Run `bmad-plus ai-register check`. It lists the AI integrations present in the project: the adapter files BMAD+ installs (`CLAUDE.md`, `GEMINI.md`, `.cursor/rules/`, `.codex/AGENTS.md`...), the tools' own folders (`.claude/`, `.cursor/`, `.gemini/`...), and the MCP servers declared in `.mcp.json`, `.cursor/mcp.json`, `.gemini/settings.json` or `.vscode/mcp.json` (comments and trailing commas allowed). Ask the user for tools used without a trace in the repository (a model API called by the product, a browser assistant).
+2. **One entry per tool.** `bmad-plus ai-register init` starts the file from the template; replace its example entries. An MCP server is registered as `mcp:` followed by its name exactly as declared. Fill each field from facts: the provider's terms and data processing addendum, the tool's settings (training opt-out, retention, region), what the tool can actually read. When a fact is unknown, say so to the user; do not guess a retention period or a transfer mechanism.
+3. **Personal data.** Code rarely is, but commit authors, issue text, customer data in fixtures, logs and support tickets are. When `personalData` is true, choose the legal basis with the user (the `gdpr-agent` and `legitimate-interest` workflow help) and flag the entry for a DPIA (`dpia-sentinel`) when the processing is large-scale or novel.
+4. **Transfers.** Every destination outside the EEA needs a mechanism; an adequacy decision covers a US provider only while it is certified under the Data Privacy Framework.
+5. **Check again.** `bmad-plus ai-register check` must report every integration registered. Set `reviewed` to the date of the review; the check warns after twelve months.
+
+## How the gate behaves
+
+| Situation                                                                                                                   | Result                                                     |
+| --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
+| An AI integration found in the project that no entry covers                                                                 | Warning (exit code 0)                                      |
+| No register while AI integrations are present                                                                               | Warning                                                    |
+| Register last reviewed more than 365 days ago                                                                               | Warning                                                    |
+| An entry that matches nothing found here                                                                                    | Listed as not found; it may be used outside the repository |
+| A register that does not follow the schema (unknown key, legal basis missing for personal data, unknown transfer mechanism) | Error (exit code 1)                                        |
+
+The gate is deliberately soft: it keeps the register in step with the tooling, and a missing entry never blocks a build; only a register that cannot be read exits non-zero. `bmad-plus doctor` shows every case, that one included, as a warning.
+
+## Boundaries
+
+- The register records processing; it does not make it lawful. The legal basis, transfer mechanism and agreements are decisions for the controller and its DPO.
+- Detection sees configuration in the repository only. A tool installed on a developer's machine without project configuration is found by asking, not by the check.

package/src/bmad-plus/packs/pack-shield/shared/assurance-case-template.yaml

@@ -0,0 +1,87 @@
+# Security assurance case (bmad-plus/assurance-case/1).
+#
+# Start with `bmad-plus assurance init _bmad/assurance/<id>.yaml`, then replace every
+# example with the project's own claims and checks. At the commit the case is about:
+#   bmad-plus assurance run _bmad/assurance/<id>.yaml
+#   bmad-plus assurance verify _bmad/assurance/<id>.yaml --ledger-head <head reported by run>
+#     --emit-check _bmad-output/assurance/<id>/check.json
+# Keep the head outside the ledger, and set BMAD_PLUS_ASSURANCE_KEY from a secret in CI:
+# without them the ledger shows accidental edits, not deliberate ones.
+#
+# Evidence is only ever a check below that ran: its command, exit code, output digest and
+# artifact digests are recorded in a hash-chained ledger (_bmad-output/assurance/<id>/runs.jsonl).
+# A statement, a document or a link is not evidence, and verify refuses a case that relies
+# on one. Evidence goes stale when the commit, the command or an artifact changes, or when
+# it is older than freshness.maxAgeDays.
+#
+# Commands run without a shell: write each argument separately. On Windows, programs such
+# as npm are .cmd files and need [cmd, /c, npm, ...]. A check inherits only PATH, HOME and
+# the temporary folders; name any other variable it needs under env.
+schema: bmad-plus/assurance-case/1
+id: release-security
+title: Release security case
+scope: >-
+  The service at the commit being released, built by the pipeline from this repository.
+freshness:
+  maxAgeDays: 30
+  sameCommit: true
+
+checks:
+  - id: unit-tests
+    run: [npm, test]
+    timeoutSeconds: 900
+  - id: dependency-audit
+    run: [npm, audit, --audit-level=high, --omit=dev]
+  - id: secret-scan
+    run: [gitleaks, detect, --no-banner, --redact, --report-path, reports/gitleaks.json]
+    artifacts: [reports/gitleaks.json]
+  - id: review-gate
+    run: [npx, bmad-plus, review, gate, release, --emit-check, reports/review-check.json]
+    artifacts: [reports/review-check.json]
+
+claims:
+  - id: C1
+    claim: The release ships no known exploitable weakness, no committed credential, and no unreviewed change.
+    argument: >-
+      The top claim holds when each of the four sub-claims below holds; together they cover
+      third-party code, secrets, the change process and the behaviour the controls rely on.
+  - id: C1.1
+    parent: C1
+    claim: Production dependencies carry no known vulnerability rated high or critical.
+    argument: >-
+      npm audit compares the resolved dependency tree with the advisory database and exits
+      non-zero at the chosen level; a zero exit at this commit shows none is known today.
+    controls: [ISO27001:A.8.8, NIST-800-53:RA-5]
+    evidence:
+      - check: dependency-audit
+        shows: npm audit reports no advisory at high or above for production dependencies.
+  - id: C1.2
+    parent: C1
+    claim: No credential is committed in the repository history.
+    argument: >-
+      The scanner reads every commit reachable from this one and exits non-zero on a finding;
+      its report is kept as an artifact so the result can be inspected.
+    controls: [ISO27001:A.5.17, SOC2:CC6.1]
+    evidence:
+      - check: secret-scan
+        shows: gitleaks finds no secret in the history and writes its report.
+  - id: C1.3
+    parent: C1
+    claim: Every changed file of the release was reviewed and no finding is left open.
+    argument: >-
+      The review gate derives its verdict from coverage of the sealed scope: it exits zero
+      only when every selected file is completed or waived and no finding is open.
+    controls: [ISO27001:A.8.32, SOC2:CC8.1]
+    evidence:
+      - check: review-gate
+        shows: bmad-plus review gate reports the release review clean.
+  - id: C1.4
+    parent: C1
+    claim: The behaviour the security controls rely on is covered by passing tests.
+    argument: >-
+      Access checks, input validation and redaction have tests in the suite; the suite
+      passing at this commit shows that behaviour is intact.
+    controls: [ISO27001:A.8.29]
+    evidence:
+      - check: unit-tests
+        shows: The test suite passes at this commit.

package/src/bmad-plus/packs/pack-shield/shared/assurance-case.md

@@ -0,0 +1,50 @@
+# Security Assurance Case
+
+> Procedure used by Shield when a user asks for an assurance case, evidence for an audit, or proof that security controls hold at a given commit. Template: `shared/assurance-case-template.yaml`. Tooling: `bmad-plus assurance init|run|verify`.
+
+## What it produces
+
+A case in `_bmad/assurance/<id>.yaml` that states **claims**, gives for each an **argument**, and supports it with **evidence**. Evidence is only ever a check that ran: `bmad-plus assurance run` executes each declared command without a shell and appends to a hash-chained ledger what happened (exit code, output digest, digests of the artifacts the run wrote, commit, whether the tree was clean of changes and untracked files). `bmad-plus assurance verify` then refuses any claim whose evidence is missing, failed or stale, and the case file itself cannot name evidence that is only asserted.
+
+## Steps
+
+0. **Start.** `bmad-plus assurance init _bmad/assurance/<id>.yaml` copies this template under that id; it never overwrites a case.
+1. **Scope.** Agree with the user on what the case covers (system, commit or release, deployment) and which frameworks matter. Write it in `scope`.
+2. **Claims from controls.** Start from the controls in scope (the relevant framework agent and `shared/cross-framework-mapper.md` help). Write one top claim, then sub-claims narrow enough that a single command can show each one. Tag a claim with the controls it supports (`ISO27001:A.8.8`, `SOC2:CC8.1`, `GDPR:Art.32`); unknown or mistyped controls are refused.
+3. **Checks.** For every leaf claim, choose a command that exits zero only when the claim holds: a test suite, a dependency audit, a secret scanner, a configuration linter, `bmad-plus review gate`, a policy-as-code evaluation. Declare artifacts the command writes (reports, SBOMs) so they are hashed with the run.
+4. **Argument.** Say why a passing check shows the claim, and what it does not show. A check that cannot fail for the reason the claim is about is not evidence of it.
+5. **Run and verify** at the commit the case is about, with a clean working tree (untracked files count unless git ignores them; the case's own ledger folder and artifacts do not):
+   ```
+   bmad-plus assurance run _bmad/assurance/<id>.yaml
+   bmad-plus assurance verify _bmad/assurance/<id>.yaml --ledger-head <head> --emit-check _bmad-output/assurance/<id>/check.json
+   ```
+   `run` reports the ledger head; keep it where the ledger's writers cannot change it (the CI job log, the audit file) and pass it to `verify`. In CI, run both in the same job with `BMAD_PLUS_ASSURANCE_KEY` set from a secret.
+6. **Report.** Present the verdict: supported and unsupported claims with their reasons, and the controls that now have executed evidence (`controls.supported`). Never describe an unsupported claim as met.
+
+## What is refused
+
+| Situation                                                                                                                                               | Result                                                            |
+| ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- |
+| Evidence that is a statement, a document or a link                                                                                                      | The case does not load: evidence must name a check                |
+| A claim with neither evidence nor sub-claims                                                                                                            | The case does not load: the claim is only asserted                |
+| A check that never ran                                                                                                                                  | `missing` — the claim is unsupported                              |
+| A non-zero or unexpected exit code, a timeout, an artifact the run did not write (absent, or left unchanged from before)                                | `failed`                                                          |
+| A run at another commit or on uncommitted changes or untracked files, a command changed since, an artifact changed since, a run older than `maxAgeDays` | `stale`                                                           |
+| A ledger record edited or reordered, or removed before the last one                                                                                     | The whole case is unsupported until the ledger is rebuilt         |
+| The last records removed                                                                                                                                | Unsupported with `--ledger-head` given; unseen without it         |
+| A record written by hand, with its digest recomputed                                                                                                    | Unsupported with `BMAD_PLUS_ASSURANCE_KEY` set; unseen without it |
+
+## How far the ledger can be trusted
+
+Without a key, the chain of SHA-256 digests shows accidental and careless edits only: anyone who can write the ledger can append a record that verifies, or cut off the records after a run they want forgotten. Two things close that, both kept outside the ledger:
+
+- **A key.** With `BMAD_PLUS_ASSURANCE_KEY` (at least 32 characters) set, `run` signs every record with an HMAC and `verify` refuses any record the key does not authenticate. The key is never passed to a check, and a case cannot ask for it.
+- **The head.** `verify --ledger-head <sha256>` refuses a ledger that no longer holds the record `run` reported last, so removed runs are seen.
+
+Report which of the two applied (`ledger.authenticated`, `ledger.anchor` in the verdict); without either, say the evidence is recorded, not tamper-proof.
+
+## Boundaries
+
+- The case shows that named checks passed at a commit. It does not certify the system, and it is not an audit opinion: a qualified auditor decides what the evidence is worth.
+- `assurance run` executes the commands written in the case, with the same trust as a project's own scripts. Read a case from someone else before running it.
+- Evidence is bound to the commit by default (`freshness.sameCommit: true`). Set it to false only for a project outside git, and say so in the report.

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

@@ -128,6 +128,25 @@ Detect the relevant framework(s) from user input using these trigger patterns:
 - FRIA, fundamental rights, Art. 27, impact assessment AI → route to `ai-act-fria`
 - AI incident, serious incident, Art. 73, incident reporting → route to `ai-act-incidents`
 
+**Evidence & tooling triggers:**
+- assurance case, security case, audit evidence, prove the controls hold, claims and evidence → follow `shared/assurance-case.md`
+- AI tools register, which AI tools see our data, record of processing for AI tooling, MCP servers inventory → follow `shared/ai-processing-register.md`
+- compliance review of a change, which controls does this change touch → use the Shield review rules (see Evidence & Tooling below)
+
+---
+
+## Evidence & Tooling
+
+Three Shield capabilities rest on BMAD+ CLI commands, so their results are checked by code, not asserted:
+
+| Need | Procedure | Command |
+|------|-----------|---------|
+| A security assurance case whose every piece of evidence is a check that ran, at the commit concerned | `shared/assurance-case.md`, template `shared/assurance-case-template.yaml` | `bmad-plus assurance init <case>`, `bmad-plus assurance run <case>`, `bmad-plus assurance verify <case> --ledger-head <head>`; `BMAD_PLUS_ASSURANCE_KEY` authenticates the ledger |
+| A register of the AI tools the project uses, what data they see and on which legal basis | `shared/ai-processing-register.md`, template `shared/ai-processing-register-template.yaml` | `bmad-plus ai-register init`, `bmad-plus ai-register check` (a warning, never a failure, for an unregistered tool) |
+| A code review that says which compliance controls a change touches | `review-rules/`: access control, personal data, cryptography, logging, AI integrations, change and supply chain, all in the `compliance` group | `bmad-plus review scope` writes the checklist; `bmad-plus review rules <path>` lists the rules and controls for one file |
+
+Controls are written `FRAMEWORK:ID` (`ISO27001:A.8.28`, `SOC2:CC8.1`, `GDPR:Art.32(1)(b)`, `NIS2:Art.21(2)(d)`, `NIST-800-53:AC-6(1)`, `EU-AI-Act:Art.50`); an unknown or mistyped control is refused. Report a supported claim or a touched control as what it is: evidence that a named check passed, or a prompt to review, never a certification. An assurance ledger without a key and a kept head shows accidental edits, not deliberate ones: say which protections applied.
+
 ---
 
 ## Multi-Framework Analysis
@@ -200,7 +219,11 @@ What type of compliance question do you have?
 8. 🔄 Cross-Framework Analysis
    "I need to comply with multiple frameworks — help me map controls."
 
-Which area? (1-8, or describe your situation)
+9. 🧾 Evidence & AI Tooling
+   → Assurance case, AI processing register, compliance review rules
+   "Prove our controls hold at this release" / "Which AI tools see our data?"
+
+Which area? (1-9, or describe your situation)
 ```
 
 ---

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

@@ -24,9 +24,16 @@ 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.
 
+A pack that declares a pipeline in the registry replaces the generic phases below
+for the work that belongs to it: its steps run in their declared order, each with
+its own gate (`require_approval`, `notify_only`, `auto`) applied like a checkpoint,
+after that pack's intake when one is declared. The generic phases still cover the
+work no pack pipeline claims.
+
 For a project requiring the full pipeline:
 
 #### Phase 1: Discovery
+0. **Intake of every pack the request involves** → For each such pack that declares an `intake` (the file sits in its installed pack directory), run the `bmad-plus-intake` protocol: `plan`, ask at most `max_per_message` questions in the user's language, `record` each answer, default or `UNKNOWN`, until `plan` says ready, then `render` the brief. The brief is an input of every later step; a pack with a must-have still open is not started.
 1. **Strategist (Analyst role)** → Brainstorming & domain research
 2. **Strategist (PM role)** → Product brief
 3. **Strategist (PM role)** → PRD creation

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

@@ -0,0 +1,87 @@
+---
+name: bmad-plus-intake
+description: Ask a user the questions a pack needs before it acts, a few at a time and in the user's language, record every answer, proposed default or unknown with its risk, and render the brief the pack works from. Use when a pack declares an intake, when a pipeline or a swarm is about to start, when a request lacks what the pack must know, or when someone says "what do you need from me".
+---
+
+# Pack intake
+
+## Overview
+
+A pack acts on what it knows. An intake is the list of what it must know before it starts:
+each question marked must-have or not, with a default where one is honest and the risk the
+pack runs when the answer stays unknown. The host asks, the user answers, the CLI keeps the
+book, and the rendered brief becomes the contract for everything the pack does next.
+
+Three files: the pack's **intake** (`intake.yaml`, shipped with the pack), the **answers**
+(`.json`, written only through the CLI) and the **brief** (`.md`, rendered from both).
+Formats and one example each: `ref/intake-format.md`.
+
+```
+intake.yaml ─► plan ─► ask (≤ max_per_message) ─► record ─► plan says ready ─► render ─► brief.md
+                 ▲                                      │
+                 └──────────── not ready yet ◄──────────┘
+```
+
+## When to activate
+
+- A pack with an `intake` field in the registry is about to run its pipeline or start a swarm.
+- The spine's Project Context names a pack that drives skills, and the request is thin.
+- The user asks what is needed, or an agent is about to guess at something the user knows.
+
+Never start a swarm or a pipeline for a pack while one of its must-haves is neither answered
+nor marked unknown with its risk. Never invent an answer.
+
+## Protocol
+
+1. **Locate the files.** The intake is `.agents/skills/<pack_dir>/<intake>` as the registry
+   declares it. Keep the answers next to the pack's output, for example
+   `_bmad-output/<pack>/intake.json`; the brief goes where the pack's first step reads it.
+2. **Plan.** `bmad-plus intake plan --intake FILE --answers FILE --json`. Exit 0 means ready;
+   exit 2 means a must-have is open. `next` lists what to ask now, must-haves first, in the
+   file's order, never more than `max_per_message`.
+3. **Ask in the user's language** (`language: user`) or in the tag the intake names. One
+   message, the questions of `next`, each with its choices or bounds when it has them, and
+   the default where one exists ("5 unless you say otherwise"). Do not pad, do not rephrase
+   the question's intent, do not ask what is already recorded.
+4. **Record what you heard.** `bmad-plus intake record --intake FILE --answers FILE --set
+   id=VALUE ... --json`. A value is checked against the question's kind and bounds and
+   refused when it does not fit; ask again rather than coerce. When the user does not know,
+   `--set id=UNKNOWN` records the question's risk with it. When the user accepts the proposed
+   default without choosing, `--default id` records it as `defaulted`; a value the user
+   actually chose, even equal to the default, is recorded with `--set` as `answered`.
+5. **Loop** to step 2 until `plan` says ready. Stop asking then, even if optional questions
+   remain: say which ones stay open and move on unless the user wants to continue.
+6. **Render.** `bmad-plus intake render --intake FILE --answers FILE --out brief.md --json`.
+   The brief lists every section, every answer with its status and must-have mark, and an
+   "Open questions" list with the risks. Hand the brief to the pack's pipeline or swarm as
+   their input; quote the open risks in the first deliverable.
+
+## Rules
+
+- A `defaulted` value is a proposal the user let stand, not a fact the user gave. The brief
+  says so, and a deliverable built on it says so too.
+- An `unknown` answer carries its risk everywhere the answer would have been used.
+- Answers are written only through `record`; never edit the JSON by hand, never write the
+  brief by hand. A changed intake file invalidates an answers file that no longer fits it;
+  `plan` reports the problem, `record --reset` starts the file again, empty, for the same
+  intake id (a file that belongs to another intake is never reset over), and the questions
+  are asked again.
+- `render` only overwrites a brief it wrote before for the same intake (the second line of
+  the file is the ownership marker); `record` only overwrites an answers file of the same
+  intake. Neither writes under `.git/`, `_bmad/`, `.bmad-plus/` or `node_modules/`, nor
+  through a symlink. A user's value is printed as an indented block under `Answer:`, so what
+  the user typed never becomes a heading or a list of the brief.
+- `bmad-plus intake check FILE --json` validates an intake file; the BMAD+ build runs the
+  same validator on every intake a pack declares.
+
+## Commands
+
+```bash
+bmad-plus intake check FILE --json
+bmad-plus intake plan --intake FILE --answers FILE --json
+bmad-plus intake record --intake FILE --answers FILE --set id=VALUE [--set id=UNKNOWN] [--default id] --json
+bmad-plus intake render --intake FILE --answers FILE --out brief.md --json
+```
+
+Paths are relative to the project (`--directory`, default the current directory) and must
+stay inside it. Exit codes: 0 done, 1 invalid file or value, 2 not ready (`plan`).

package/src/bmad-plus/skills/bmad-plus-intake/ref/intake-format.md

@@ -0,0 +1,112 @@
+# Intake file formats
+
+Validator: `tools/build/intake-contract.js` (shipped with BMAD+; run by `bmad-plus intake
+check` and by the BMAD+ build on every declared intake). Unknown fields are refused.
+
+## 1. Intake (`intake.yaml`, shipped by the pack)
+
+```yaml
+schema_version: 1
+id: shop-brief              # lowercase slug, unique per pack
+pack: shop                  # the pack id that declares `intake:` in the registry
+title: Shop brief
+language: user              # ask in the user's language, or a tag such as fr or en-GB
+max_per_message: 4          # 1..20, default 6
+sections:
+  - id: offer
+    title: What is sold
+    questions:
+      - id: product_kind
+        ask: What does the shop sell, one line?
+        kind: text
+        must_have: true
+        feeds: [brief.md#offer]
+        risk_if_unknown: Every page is written for a product nobody described.
+      - id: price_band
+        ask: Where do prices sit?
+        kind: choice
+        choices: [budget, mid, premium]
+        default: mid
+        feeds: [brief.md#offer]
+      - id: launch_in_days
+        ask: In how many days must it go live?
+        kind: number
+        min: 1
+        max: 365
+      - id: has_stock
+        ask: Is there stock to ship today?
+        kind: boolean
+        default: true
+      - id: markets
+        ask: Which countries are served?
+        kind: list
+        must_have: true
+        risk_if_unknown: Taxes, currencies and legal pages cannot be chosen.
+```
+
+- `kind`: `text`, `choice` (needs at least two distinct `choices`), `number` (optional `min`,
+  `max`), `boolean`, `list` (of texts).
+- `must_have: true` requires `risk_if_unknown` and forbids `default`: the user answers it or
+  marks it unknown. A question that is not must-have may carry a `default`, valid for its kind.
+- `feeds` names the artifact anchors the answer fills (`file#anchor`); informative.
+- Question ids are `snake_case` and unique across the whole file; section ids are slugs.
+
+## 2. Answers (`.json`, written by `bmad-plus intake record`)
+
+```json
+{
+  "schemaVersion": 1,
+  "intake": "shop-brief",
+  "answers": {
+    "product_kind": { "value": "Hand-poured soy candles", "status": "answered" },
+    "price_band": { "value": "mid", "status": "defaulted" },
+    "markets": { "status": "unknown", "risk": "Taxes, currencies and legal pages cannot be chosen." }
+  }
+}
+```
+
+- Statuses: `answered` (the user said it), `defaulted` (the proposed default stood), `unknown`
+  (the user does not know; `risk` copies the question's `risk_if_unknown`). Nothing else.
+- A key must be a question id of the intake; a value must fit the question's kind and bounds;
+  a `defaulted` value equals the question's default. A question not yet asked has no entry.
+
+## 3. Brief (`.md`, written by `bmad-plus intake render`)
+
+```markdown
+# Shop brief
+<!-- owned by bmad-plus intake shop-brief; written by bmad-plus intake render, do not edit -->
+
+Intake `shop-brief` of pack `shop` — 1 answered, 1 defaulted, 1 unknown, 2 not asked yet. Not ready: a must-have is open.
+
+## What is sold
+
+### product_kind (must-have)
+
+What does the shop sell, one line?
+
+Answer:
+    Hand-poured soy candles
+Feeds: brief.md#offer
+
+### price_band
+
+Where do prices sit?
+
+Answer (proposed default, not confirmed by the user):
+    mid
+Feeds: brief.md#offer
+
+...
+
+## Open questions
+
+- markets (must-have): unknown — risk: Taxes, currencies and legal pages cannot be chosen.
+- launch_in_days: not asked yet
+```
+
+The first paragraph states readiness; a pack reads "Ready." before it starts. The second
+line is the ownership marker: `render` overwrites an existing file only when it starts with
+the marker of the same intake. Values are printed as a block indented by four spaces, one
+line per list item and per line of a multi-line text, so a value never opens a heading or a
+list of its own. Text and list values may hold line breaks and tabs; any other control
+character is refused.