diff --git a/tools/spec-loop/.last-sync b/tools/spec-loop/.last-sync
index be96efb3b..f97ccffa7 100644
--- a/tools/spec-loop/.last-sync
+++ b/tools/spec-loop/.last-sync
@@ -1 +1 @@
-bcd8b7f28e5d926ca8eff6e603c64b327ae038fe
+da660f14e69670145e6096aa27626845ae910327
diff --git a/tools/spec-loop/specs/adapters.md b/tools/spec-loop/specs/adapters.md
index 58570b8b8..e58f48d96 100644
--- a/tools/spec-loop/specs/adapters.md
+++ b/tools/spec-loop/specs/adapters.md
@@ -2,7 +2,7 @@
      https://www.apache.org/licenses/LICENSE-2.0 -->
 
 ---
-title: Adapters (Gmail / PonyMail / Jira / GitHub / Bitbucket / mail-source / SourceHut / maildir / VCS / change-request)
+title: Adapters (Gmail / PonyMail / Jira / GitHub / GitLab / Bitbucket / mail-source / SourceHut / maildir / VCS / change-request / chat)
 status: experimental
 kind: feature
 mode: infra
@@ -14,7 +14,7 @@ source: >
   tools/sourcehut/, tools/maildir/, tools/vcs/, tools/change-request/,
   tools/asf-svn/, tools/mail-archive/, tools/mail-patch/,
   tools/jira-patch/, tools/forwarder-relay/, tools/github-body-field/,
-  tools/github-rollup/.
+  tools/github-rollup/, tools/gitlab/, tools/chat/, tools/chat-slack/.
 acceptance:
   - Project-specific integrations live behind adapter modules, not
     hardcoded into skills.
@@ -24,7 +24,7 @@ acceptance:
     redactor before any LLM read.
 ---
 
-# Adapters (Gmail / PonyMail / Jira / GitHub / Bitbucket / SourceHut / maildir / VCS / change-request)
+# Adapters (Gmail / PonyMail / Jira / GitHub / GitLab / Bitbucket / SourceHut / maildir / VCS / change-request / chat)
 
 ## What it does
 
@@ -45,8 +45,29 @@ by swapping the adapter, not the skill.
 - `tools/jira/` — issue-tracker adapter for projects on Jira.
 - `tools/github/` — issues/PRs/labels read + write-back helpers.
   Sub-adapters: `tools/github-body-field/` (reads GitHub issue/PR body
-  structured field sets) and `tools/github-rollup/` (aggregates
-  multi-repo PR state into a single view).
+  structured field sets) and `tools/github-rollup/` (`contract:tracker`,
+  stdlib-only), which maintains the single status-rollup comment on a
+  tracker issue in a subprocess so the growing rollup body never enters
+  agent context.
+  `append` and `amend-latest` print the rollup comment's URL on stdout
+  (#1451), so a caller links to the entry without a second lookup.
+  Its subcommands are `append` (creates the rollup if none exists),
+  `amend-latest` (replaces the newest entry's body, keeping its date and
+  user, and refuses with exit 4 when that entry's action differs, so another
+  writer's entry is never overwritten), `fold` (moves one legacy bot comment
+  into the rollup with its own date and author, then deletes it; refuses to
+  fold the rollup itself), `list`, and `latest`.
+  An existing rollup is found by any `<!-- <name> status rollup v<N>`
+  marker, and a comment's id is read from its `#issuecomment-<id>` URL.
+  `tools/github/status-rollup.md` calls the tool instead of carrying its own
+  script.
+  Under the secure agent setup both tools' `gh` runs sandboxed and fails,
+  so their READMEs route skills to the same procedures through vetted-ops:
+  `vetted-op-tracker` (`rollup-append`, `rollup-amend-latest`,
+  `rollup-fold`, `body-field-set`) for writes and `vetted-op-read …
+  body-field-get` for the read, with the parsing modules vendored into
+  vetted-ops; the uv CLIs remain for use outside the sandbox (#1448; see
+  [`vetted-command-surface.md`](vetted-command-surface.md)).
 - `tools/bitbucket/` — partial Bitbucket Cloud and Bitbucket
   Data Center bridge foundation. Supports repository metadata reads,
   read-only branch restriction context, Cloud-only issue listing/fetching, issue comment fetching, issue attachment metadata fetching, and confirmed issue comment creation,
@@ -59,6 +80,22 @@ by swapping the adapter, not the skill.
   deeper Jira handoff, broader issue writes, review/merge writes, broader
   repository permissions, and fuller Pipelines run/log/retry coverage remain
   tracked in #606.
+- `tools/gitlab/` (`magpie-gitlab`) — partial, read-only GitLab REST API v4
+  bridge, declared `contract:tracker + contract:source-control +
+  contract:change-request` with `**Coverage:** partial`.
+  Operations: `repo get`, `issue list` / `issue get`, `mr list` / `mr get` /
+  `mr diff` / `mr commits` / `mr pipelines`, and `pipeline status`, all
+  printing JSON.
+  Auth from `GITLAB_TOKEN` or `CI_JOB_TOKEN` (optional for public reads),
+  with `GITLAB_AUTH_SCHEME` to force `PrivateToken`, `Bearer`, or
+  `JobToken`; `GITLAB_INSTANCE_URL` defaults to `https://gitlab.com`.
+  Redirects that change origin or downgrade HTTPS to HTTP are refused so
+  the token cannot leak.
+  Paginated reads follow `X-Next-Page` until `--limit` items are collected
+  (short pages keep paging), or, without `--limit`, stop at 10 pages and
+  note the cap on stderr; `--limit` rejects values below 1.
+  No write or mutation operations exist.
+  Offline tests mock every HTTP response.
 - `tools/sourcehut/` — SourceHut (sr.ht) forge bridge: ticket tracking
   (`todo.sr.ht`), mailing-list patchset review (`lists.sr.ht`), CI build
   status (`builds.sr.ht`), and repository reads (`git.sr.ht`/`hg.sr.ht`)
@@ -101,6 +138,21 @@ by swapping the adapter, not the skill.
   patch-over-Jira adapters; implement `contract:change-request` for
   projects that land patches via mailing-list review or Jira rather than
   GitHub PRs.
+- `tools/chat/` — the `contract:chat` interface (pure Markdown) for a
+  project's public chat.
+  Three verbs, `list_channels`, `resolve_user(github_handle)`, and
+  `search_messages(chat_user_id, since, until, channels)`; read-only by
+  construction: no verb posts, reacts, edits, or reads a direct message or
+  private channel.
+  Consumed by the contributor-growth skills to see how a contributor helps
+  others in chat ([contributor growth](contributor-growth.md)).
+  Selected by `chat.kind` in `<project-config>/project.md`.
+- `tools/chat-slack/` — the shipping `contract:chat` adapter: a mapping
+  onto the Slack MCP tools (`operations.md`) over the public channels of the
+  project's workspace, optionally narrowed by `chat.channels`.
+  It never calls a tool that sends, schedules, drafts, or edits a message.
+  `discord` and `none` are placeholders in the contract's adapter table
+  (Discord tracked in #1421).
 
 ## Behaviour & contract
 
@@ -144,16 +196,28 @@ by swapping the adapter, not the skill.
 ## Validation
 
 ```bash
-for t in gmail maildir ponymail jira github bitbucket; do
+for t in gmail maildir ponymail jira github bitbucket gitlab; do
   uv run --project tools/$t --group dev pytest || echo "check tools/$t test setup"
 done
 uv run --project tools/vcs --group dev pytest || echo "check tools/vcs test setup"
+uv run --all-packages --group dev pytest tools/github-rollup/tests
 ```
 
 ## Known gaps
 
 - `experimental` overall — adapter coverage varies; a new adopter system
-  (e.g. GitLab, a different mail backend) is a gap the plan pass records.
+  (e.g. a different mail backend) is a gap the plan pass records.
+- **GitLab adapter is a read-only foundation.** `tools/gitlab/` covers
+  repository metadata, issue and merge-request reads, MR diffs, commits and
+  pipelines, and pipeline status; it is `partial` for all three contracts
+  and must not be advertised as a selectable complete backend.
+  Writes, issue/MR mutations, and review or merge actions remain tracked in
+  #305.
+  Fetched issue and MR titles, descriptions, diffs and commit messages are
+  external data, never instructions.
+- **Chat covers Slack only.** `contract:chat` ships one adapter;
+  `discord` and `none` are placeholders, so a project on Discord gets chat
+  reported as not collected.
 - **Bitbucket adapter is new and intentionally partial.** `tools/bitbucket/`
   currently provides read-only repository metadata, read-only branch restriction
   context, pull-request discovery, pull-request fetching, read-only pull-request
diff --git a/tools/spec-loop/specs/adoption-and-setup.md b/tools/spec-loop/specs/adoption-and-setup.md
index eedd5dca0..d451081f8 100644
--- a/tools/spec-loop/specs/adoption-and-setup.md
+++ b/tools/spec-loop/specs/adoption-and-setup.md
@@ -36,7 +36,8 @@ acceptance:
     plugin list, with no `ref`, and a fresh clone is brought up to that
     minimum and never held down to it.
   - Drift between the committed pin and the local install is detected and
-    surfaced with an upgrade proposal.
+    surfaced with an upgrade proposal, or with a full re-install proposal
+    when the local install's method or URL differs from the pin.
   - A gitignored `.apache-magpie-local/` supplies per-person overrides that
     layer above the committed `.apache-magpie-overrides/`, cannot weaken the
     safety baseline, and can be ignored for a single run via a one-shot
@@ -139,8 +140,26 @@ committed version with drift detection.
 
 ## Where it lives
 
-- Skill: `setup` (install, adopt/unadopt, verify, upgrade, override,
-  reconcile — the one-time project-wide reconciliation sweep).
+- Skill: `setup` (install, config, adopt/unadopt, verify, upgrade,
+  override, reconcile — the one-time project-wide reconciliation sweep) at
+  `plugins/magpie-setup/skills/setup/`: one `SKILL.md` plus a sibling
+  detail file per sub-action (`install.md`, `config.md`, `adopt.md`,
+  `upgrade.md`, `verify.md`, `reconcile.md`, `locks.md`, …).
+  `skills/setup` is the flat-tree mirror symlink, like every other skill's
+  `skills/<dir>`; the sibling setup skills below live beside it under
+  `plugins/magpie-setup/skills/`.
+- Pre-flight checker: the `setup_preflight` package ships inside the
+  `magpie-setup` plugin at `plugins/magpie-setup/skills/setup/setup_preflight/`
+  (#1409), so a marketplace-only adopter has a copy to install.
+  `tools/setup-preflight/` stays the uv workspace member that carries its
+  tests and CI job; its `src/setup_preflight` is a symlink inward to the
+  plugin's package, and `check-family-plugins.py` fails when the package
+  leaves the plugin or the mirror link drifts.
+- Project templates: `plugins/magpie-setup/templates/` (#1410), the
+  scaffold `setup config` copies adopter configuration from.
+  `projects/_template` is a symlink to it, so older paths keep resolving;
+  `check-family-plugins.py` fails when the templates leave the plugin or
+  that link drifts.
 - Skills: `setup-isolated-setup-install` / `-update` / `-verify` / `-doctor`
   (the sandbox harness; `-doctor` probes live restrictions — SSH agent /
   Yubikey reachability, localhost port binding, filesystem restrictions),
@@ -150,7 +169,11 @@ committed version with drift detection.
   method and pin, drift between local and committed locks, which skills
   are wired in the current repo.
 - Docs: `docs/setup/` (install recipes, agentic-overrides contract,
-  prerequisites).
+  prerequisites, `commit-attribution.md`).
+- Commit attribution: `commit-attribution.toml`, committed in
+  `.apache-magpie-overrides/` (project policy) and gitignored in
+  `.apache-magpie-local/` (a contributor's preference), scaffolded from
+  `plugins/magpie-setup/templates/commit-attribution.toml` (#1385).
 - Lock files: `.apache-magpie.lock` (committed — a pin on the snapshot
   methods, a floor on `method: marketplace`) and
   `.apache-magpie.local.lock` (gitignored, what this machine fetched).
@@ -224,6 +247,56 @@ committed version with drift detection.
 - **`upgrade` splits on adoption:** nothing repo-side when the project
   has not adopted; `min_version` raised — never lowered — and staged
   when it has.
+- **An unrecognised sub-action is never guessed** (#1391). A first
+  argument that names no sub-action and is not a flag prints an
+  "Unknown setup sub-action" message with close-match suggestions (edit
+  distance one or two, or a prefix; every candidate when several qualify)
+  and the full sub-action list, then waits.
+  It runs a suggested sub-action only after the user confirms it, and
+  never falls back to `install`, because `upgrade`, `reconcile` and
+  `adopt` stage committed files.
+- **Stacked PRs only with write access** (#1430). The agent conventions
+  block `install` writes into an adopter's `AGENTS.md`, like this repo's own
+  `AGENTS.md`, tells agents how to open a series of dependent PRs.
+  With push access to `<upstream>` (`gh api repos/<upstream> --jq
+  .permissions.push`), every branch is pushed to `<upstream>` itself, each PR
+  is opened in the browser from its approved body against the previous
+  branch, and the stack is joined with `gh stack link`; the agent only
+  suggests installing the `github/gh-stack` extension, never installs it.
+  Without push access, the PRs go from the fork against the default branch
+  with a *"Depends on #N"* line.
+  `gh stack submit --auto` and letting `gh stack` generate titles or bodies
+  are never used.
+- **Commit attribution is a project choice** (#1385). `adopt` always asks
+  the maintainer for the convention (`generated-by`, the default and the
+  ASF convention; `assisted-by`; `co-authored-by`; `none`;
+  `contributor-choice`; or custom wording) and writes it to
+  `.apache-magpie-overrides/commit-attribution.toml`.
+  `config` asks a contributor only when the project's file is absent or
+  says `contributor-choice`, and writes
+  `.apache-magpie-local/commit-attribution.toml`.
+  This is the one configuration file where the project wins over the
+  contributor's local copy; an unreadable file or unknown value fails
+  closed to `generated-by`.
+  Every skill that commits adds the trailer as a `--trailer` argument,
+  never inside the message, so it stays visible to command-line guards.
+  The framework repository pins `generated-by` for itself.
+- **Adversarial reviewers are configured on request** (#1371).
+  `config adversarial-review` (Step 3c, run only when named and only with
+  the `magpie-adversarial-review` plugin installed) runs
+  `adversarial-review detect`, pre-selects every available backend except
+  the running harness's own model, writes
+  `.apache-magpie-local/adversarial-review.md` from its template, and
+  offers the Codex / Gemini command files under the user's home directory,
+  never inside a repository.
+  `verify` check 8i reports configured reviewers whose CLI is gone and
+  stale command files; `adopt` always flags `adversarial-review.md` as
+  personal.
+- **`method: local` has nothing to drift** (#1414). The framework
+  checkout's self-adoption writes `method: local` with a `source:` key; the
+  checker's lock parser accepts that key and returns no project findings
+  for the method, and `upgrade` on it only refreshes the pre-flight
+  checker from the in-repo package and stops.
 - **Every skill's pre-flight also compares its own generated
   `surface_hash` against the reconciliation stamp**, silently when they
   match, at no extra cost inside a sandboxed session: both values are
@@ -249,7 +322,14 @@ committed version with drift detection.
 3. The committed lock re-installs the same version on a fresh clone on the
    snapshot methods, and on `method: marketplace` brings a fresh clone up to
    the recorded floor without capping it there.
-4. Drift between local and committed locks is surfaced with an upgrade.
+4. Drift between local and committed locks is surfaced with a remedy that
+   fits it: a missing local lock proposes `/magpie-setup`; a differing
+   `ref` or `commit` proposes `/magpie-setup upgrade`; a differing `method`
+   or `url` (the machine fetched the framework another way, or from
+   another source) proposes a full re-install with `/magpie-setup`,
+   because an upgrade cannot fix it. `setup_preflight` compares all four
+   keys (`method` and `url` since #1435), and its `step-2` rules section
+   carries the three remedies.
 5. Override files can be discovered and surfaced to skills without
    editing upstream skill bodies, and override text cannot weaken the
    safety/confidentiality baseline.
@@ -376,7 +456,10 @@ committed version with drift detection.
     `.apache-magpie-local/`** by `/magpie-setup config` and refreshed
     there by `/magpie-setup upgrade`, because Bash can neither read nor
     execute the plugin cache under the framework's own recommended
-    sandbox. `config` states that it installed an executable, since it may
+    sandbox. The copy's source is the package inside the installed
+    `magpie-setup` plugin on a marketplace install, and
+    `<snapshot-dir>/tools/setup-preflight/src/setup_preflight/` (the same
+    files, through the mirror link) on a snapshot install. `config` states that it installed an executable, since it may
     run unattended from a skill's pre-flight. `upgrade` skips the refresh
     when the directory does not exist rather than creating it, because its
     absence is what marks a project as never configured.
@@ -399,6 +482,25 @@ committed version with drift detection.
     The stamp is written only by `python3 -m setup_preflight.isolated
     record-update | record-reminder`, never by hand; the proposal never
     runs the update and never blocks the skill.
+28. The memoised project verdict is keyed on the lock files, the plugin
+    listing, and the checker's own `core.py` and `lockfile.py`, so a
+    checker refreshed by `upgrade` never serves the previous code's
+    answer (#1414). A `method: local` lock, `source:` key included,
+    parses and yields no project findings.
+29. An unrecognised `setup` sub-action is answered with close-match
+    suggestions and the sub-action list, and nothing runs until the user
+    confirms (#1391; eval suite
+    `tools/skill-evals/evals/setup/step-unknown-subaction`).
+30. `adopt` writes the project's commit-attribution convention to
+    `.apache-magpie-overrides/commit-attribution.toml`; `config` writes a
+    contributor's preference to
+    `.apache-magpie-local/commit-attribution.toml` only when the project
+    leaves the choice open. Resolution is project first, then contributor,
+    then `generated-by`, failing closed to `generated-by` (#1385).
+31. `setup config` scaffolds every template from
+    `plugins/magpie-setup/templates/<file>` on a marketplace install and
+    from `<snapshot-dir>/projects/_template/<file>` on a snapshot install;
+    both are the same file (#1410).
 
 ## Validation
 
@@ -416,11 +518,11 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   only the namespace of their invocation differs.
 
 - `stable`; gaps appear as new agent targets to add to the registry
-  ([`agents.md`](../../../skills/setup/agents.md)) or new override
+  ([`agents.md`](../../../plugins/magpie-setup/skills/setup/agents.md)) or new override
   surfaces — recorded by the plan pass.
-- **Not yet built:** the `.apache-magpie-local/` personal override surface
-  (acceptance 5) and the one-shot default-run switch (acceptance 6). Both are
-  intended behaviour recorded here and tracked as work items
-  `magpie-local-convention` and `override-bypass-one-shot` in the plan. The
-  three hybrid-setup how-tos that build on the local surface are tracked
-  alongside them.
+- **Built since first recorded as gaps:** the `.apache-magpie-local/`
+  personal override surface (acceptance 6) and the one-shot default-run
+  switch (acceptance 7, the `--no-overrides` flag in
+  `docs/setup/agentic-overrides.md` § One-shot defaults run) both ship.
+  They were tracked as work items `magpie-local-convention` and
+  `override-bypass-one-shot` in the plan.
diff --git a/tools/spec-loop/specs/adversarial-review.md b/tools/spec-loop/specs/adversarial-review.md
index c2aba04dd..480ad37be 100644
--- a/tools/spec-loop/specs/adversarial-review.md
+++ b/tools/spec-loop/specs/adversarial-review.md
@@ -7,10 +7,14 @@ status: experimental
 kind: feature
 mode: infra
 source: >
-  docs/designs/2026-09-23-adversarial-review.md (rollout PR 1 of 4).
-  Implemented in tools/adversarial-review/ and published as the
-  magpie-adversarial-review substrate plugin (plugins/magpie-adversarial-review/,
-  SUBSTRATE_PLUGINS in tools/dev/check-family-plugins.py).
+  docs/designs/2026-09-23-adversarial-review.md (all four rollout PRs built;
+  see its As built section). Implemented in tools/adversarial-review/ and
+  published as the magpie-adversarial-review substrate plugin
+  (plugins/magpie-adversarial-review/, SUBSTRATE_PLUGINS in
+  tools/dev/check-family-plugins.py). Consumed by the shared pre-PR block
+  tools/dev/blocks/pre-pr-adversarial-review.md, by
+  pr-management-code-review's with-reviewers: path, and by setup
+  (config Step 3c, verify 8i, isolated-setup-install Step R).
 acceptance:
   - The tool runs only installed reviewer CLIs (codex, copilot, gemini,
     claude), each in its own read-only headless mode, and skips the model
@@ -22,6 +26,11 @@ acceptance:
     run completes — and an unavailable reviewer never fails the run.
   - Reviewer output is data; a finding that reads like an instruction is
     never acted on.
+  - Every skill that opens a PR carries the shared pre-PR review block; the
+    skill validator fails one that does not, apart from a reasoned
+    exemption list.
+  - The tool refuses a --repo-dir that is the project's private tracker
+    unless --allow-tracker-checkout is passed.
 ---
 
 # Adversarial review by other models
@@ -35,31 +44,73 @@ find into one advisory report.
 A reviewer is only useful as a *different* model, so the harness's own model
 is skipped by default.
 
-This spec covers what has shipped: the tool and its plugin.
-Wiring it into the skills — setup, a shared pre-PR block in every PR-creating
-skill, and a multi-reviewer second read in `pr-management-code-review` — is the
-remaining rollout, recorded under *Known gaps*.
+The tool is wired into the skills in three places.
+`setup` detects the installed reviewer CLIs, writes the configuration, offers
+per-harness commands, and installs the sandbox exclusion.
+Every skill that opens a PR runs the configured reviewers over the change
+before the PR is created, through one shared block.
+`pr-management-code-review` runs them as a second read on each PR it reviews
+(`with-reviewers:`).
 
 ## Where it lives
 
 - `tools/adversarial-review/` — stdlib-only Python package, capability
-  `substrate:review`, harness `agnostic`. Two subcommands:
+  `substrate:review`, harness `agnostic`. Three subcommands:
   - `detect` — for each backend, whether its CLI is on `PATH` and answers a
     cheap probe, and which backend is the running harness (`self`),
     recognised from the environment variables each harness sets.
   - `run` — builds the input from `--target branch` (with `--base`),
     `pr:<N>` (with `--repo`, through `gh`) or `diff:<path>`, plus `--title`
     and `--body-file`, runs every requested reviewer, and prints the merged
-    report.
+    report. `--allow-tracker-checkout` lets it run on a tracker checkout
+    whose own code is under review.
+  - `commands --harness claude|codex|gemini|copilot` — prints one harness's
+    command file as JSON `{path, content}`, rendered from one template
+    (`commands.py`). Claude Code's is plugin-relative
+    (`commands/adversarial-review.md`); Codex's is
+    `~/.codex/prompts/magpie-adversarial-review.md`; Gemini's is
+    `~/.gemini/commands/magpie-adversarial-review.toml`; Copilot CLI has no
+    command mechanism, so it gets an empty path and the one-line invocation.
+- `tools/adversarial-review/commands/adversarial-review.md` — the generated
+  Claude Code command, pinned by a test against the generator.
 - `plugins/magpie-adversarial-review/` — the substrate plugin in the Claude
   Code catalogue, linking `tools/adversarial-review` so the tool runs from the
   installed plugin tree
-  ([marketplace distribution](marketplace-distribution.md)).
+  ([marketplace distribution](marketplace-distribution.md)), and
+  `commands/adversarial-review.md` (a link to the generated command), which
+  Claude Code publishes as `/magpie-adversarial-review:adversarial-review`.
 - `adversarial-review.md` — optional configuration, resolved
   `.apache-magpie-local/` first, then `.apache-magpie-overrides/`, under
-  `--project-root`: `mode`, `reviewers`, `timeout_minutes`, per-backend
-  `models`. `--reviewers` on the command line overrides the list.
-- `docs/designs/2026-09-23-adversarial-review.md` and its implementation plan.
+  `--project-root`: `mode` (`on-pr-create`, `on-demand`, `off`), `reviewers`,
+  `timeout_minutes`, per-backend `models`.
+  `--reviewers` on the command line overrides the list.
+  Template: `plugins/magpie-setup/templates/adversarial-review.md`
+  (`projects/_template/` is a link to that directory), pinned parseable by a
+  test.
+- `tools/dev/blocks/pre-pr-adversarial-review.md` — the shared pre-PR block,
+  filled into each host skill by `tools/dev/check-shared-blocks.py`.
+  Hosts today: `issue-fix-workflow` (in its sibling
+  `pre-pr-adversarial-review.md`), `release-announce-draft`,
+  `release-audit-report`, `release-prepare` (also at 2f and 14b),
+  `audit-finding-fix`, `security-issue-fix`, `security-issue-import-from-pr`,
+  `security-issue-import-from-scan`, `security-model-prepare`,
+  `security-model-verify`, `setup-override-upstream`, and
+  `setup-upstream-fix`.
+- `validate_pre_pr_review_block` in
+  `tools/skill-and-tool-validator/src/skill_and_tool_validator/__init__.py` —
+  HARD check, category `pre-pr-review-block`.
+- `pr-management-code-review` — `adversarial.md`, `prerequisites.md` §2 and
+  `selectors.md` under `plugins/magpie-pr-management/skills/code-review/`
+  ([PR management family](pr-management-family.md)).
+- Setup wiring under `plugins/magpie-setup/skills/`: `setup/config.md`
+  Step 3c, `setup/verify.md` 8i, `setup/adopt.md` 4a,
+  `isolated-setup-install/SKILL.md` Step R, and
+  `isolated-setup-verify/conditional-checks.md` check 14.
+- The sandbox exclusion in `.claude/settings.json`, mirrored in
+  `tools/sandbox-lint/expected.json`.
+- `docs/designs/2026-09-23-adversarial-review.md`, whose *As built* section
+  records where the shipped system departs from the design.
+  The implementation plan was folded into it and deleted.
 
 ## Behaviour & contract
 
@@ -89,6 +140,55 @@ remaining rollout, recorded under *Known gaps*.
 - **Nothing written to the repository.** The brief and the schema live in a
   temporary directory removed afterwards; the tool itself makes no network
   calls.
+- **Inputs are confined.** The tool runs outside the sandbox, so it refuses a
+  `--body-file` or `diff:` path outside the repository or a temporary
+  directory.
+  It refuses a `--repo-dir` that is the project's private tracker (exit 2),
+  because the reviewers can read every file there, unless
+  `--allow-tracker-checkout` says the tracker's own code is under review; the
+  report then still carries the warning.
+- **One invocation spelling.** Every generated command, the shared block and
+  code review's copy invoke
+  `uvx --from ~/.claude/plugins/cache/apache-magpie/magpie-adversarial-review/<version>/tools/adversarial-review adversarial-review …`,
+  unquoted with a literal `~`, the only form the sandbox exclusion matches.
+  Tests pin each copy to the exclusion pattern.
+  No command bakes in a version: Claude Code's reads it from
+  `${CLAUDE_PLUGIN_ROOT}`, the others take the newest installed, so `upgrade`
+  has nothing to rewrite.
+- **Sandbox exclusion without an allow rule.** `isolated-setup-install`
+  Step R adds one `excludedCommands` entry for that invocation and an `Edit`
+  deny on the plugin cache, since the tool runs unsandboxed.
+  There is deliberately no allow rule, so every run keeps its prompt.
+  `isolated-setup-verify` check 14 checks all three.
+- **Setup offers reviewers only when named.** `config adversarial-review`
+  (Step 3c) runs `detect`, pre-ticks every available backend except `self`,
+  asks for the `mode`, and writes `.apache-magpie-local/adversarial-review.md`,
+  showing the difference first when the file exists.
+  It then offers the Codex and Gemini command files under the user's home,
+  never in a repository.
+  It is never part of a pre-flight entry.
+  `verify` 8i reports configured reviewers whose CLI is gone and stale command
+  files; `adopt` always flags the file as personal.
+- **The pre-PR block runs before every PR a skill opens.** Once the PR's
+  title and body are final, and after the skill's own public-surface checks,
+  it reviews the diff with the title and body exactly as they will be posted.
+  No configuration or an empty `reviewers` list skips silently; a missing
+  plugin skips with one line.
+  A `security`-family skill runs whenever at least one reviewer is listed,
+  whatever `mode` says; any other skill runs only on `mode: on-pr-create`.
+  `--repo-dir` is never the tracker (an empty temporary directory for
+  `pr:<N>` with no checkout), and a change that is not a committed local
+  branch is reviewed as a diff file.
+  The findings are shown as untrusted, advisory data, never block the flow,
+  and add nothing to a step's structured output; a finding the human wants
+  fixed sends the flow back to the fix, the skill's own checks, and a fresh
+  review.
+- **The validator enforces the block.** A skill counts as PR-opening when
+  any of its Markdown files or scripts names `gh pr create` (a Python argv
+  list included), or when `PRE_PR_REVIEW_DELEGATED` lists it because it opens
+  PRs through another skill's helper (`security-model-prepare`).
+  `PRE_PR_REVIEW_EXEMPT` lists, each with its reason, files that mention the
+  command without opening a PR.
 - **Standalone resolution.** Like `tools/vetted-ops`, the project declares no
   workspace `dev` group, because it runs as
   `uvx --from <plugin>/tools/adversarial-review adversarial-review …`, where
@@ -115,33 +215,43 @@ remaining rollout, recorded under *Known gaps*.
    reviewers returned.
 6. `check-family-plugins.py` passes with `magpie-adversarial-review` in
    `SUBSTRATE_PLUGINS` and its entry point resolving through the plugin link.
+7. `commands --harness <name>` prints the command file for each of the four
+   harnesses, and the shipped Claude Code command matches the generator.
+8. `run` exits 2 on a tracker `--repo-dir` without
+   `--allow-tracker-checkout`, and on a body or diff file outside the
+   repository and the temporary directory.
+9. `skill-and-tool-validate` reports a `pre-pr-review-block` violation for
+   any PR-opening skill without the shared block.
 
 ## Validation
 
 ```bash
 uv run --all-packages --group dev pytest tools/adversarial-review/tests
 python3 tools/dev/check-family-plugins.py
+python3 tools/dev/check-shared-blocks.py
+uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-validate
 ```
 
+Behavioural eval suites under `tools/skill-evals/evals/`:
+`setup/step-config-adversarial`,
+`security-issue-fix/step-7-adversarial-review`,
+`setup-upstream-fix/step-5-adversarial-review`, and
+`pr-management-code-review/step-2-reviewer-resolution`.
+
 ## Known gaps
 
-- **No consumer is wired yet.** The design's rollout PRs 2–4 are unbuilt:
-  `setup` running `detect` in `config` and `verify`, writing the
-  configuration and the per-harness commands, and installing the sandbox
-  exclusion; the shared pre-PR block in every PR-creating skill; and
-  `with-reviewers:` in `pr-management-code-review`, which today still takes a
-  single user-fired `with-reviewer:` slash command. The tool README's
-  statements that skills run it and that setup installs its exclusion
-  describe that target state.
-- **No `commands` subcommand.** The design's `commands --harness <name>`,
-  which would print the per-harness command files for `setup`, does not
-  exist; only `detect` and `run` ship.
-- **The `mode` key is parsed but unused** until the pre-PR block consumes it.
+- **Rollout complete; the earlier gaps are closed.** The consumers once
+  listed here (setup wiring, the pre-PR block, `with-reviewers:`), the
+  `commands` subcommand, a consumer of `mode`, and the sandbox exclusion all
+  shipped (#1371, #1372, #1373).
+- **`detect` does not see login state.** It makes no model call, so a
+  logged-out CLI looks available until the first real run reports it
+  `unavailable`; `setup config` says so.
 - **Reviewers can read beyond the prompt.** `codex -s read-only` restricts
   writes and network, not reads, so an instruction injected into the diff
   could have it read a file elsewhere on the machine; `copilot` and `gemini`
-  keep any MCP servers they are configured with. The README tells operators
-  to keep private checkouts away from review machines or leave `codex` out.
-- **The sandbox blocks it.** Reviewer CLIs need network access and their own
-  credentials, which the reference sandbox denies, and no `excludedCommands`
-  entry ships for the tool yet.
+  keep any MCP servers they are configured with.
+  The README tells operators to keep private checkouts away from review
+  machines or leave `codex` out.
+- **Copilot CLI has no command file.** `setup` can only show the one-line
+  invocation for it.
diff --git a/tools/spec-loop/specs/agent-isolation-sandbox.md b/tools/spec-loop/specs/agent-isolation-sandbox.md
index 671cbd8c7..70d373f67 100644
--- a/tools/spec-loop/specs/agent-isolation-sandbox.md
+++ b/tools/spec-loop/specs/agent-isolation-sandbox.md
@@ -17,9 +17,13 @@ acceptance:
     filesystem reads and network egress; runtime-specific exceptions
     are documented in the adapter and this spec.
   - Credential-shaped env vars are stripped before the agent execs.
-  - State-mutating shell calls (git push and every gh write subcommand,
-    each listed explicitly) require a confirmation prompt; read-only gh
-    subcommands do not; secrets/cred files are deny-read.
+  - State-mutating shell calls (git push, every gh write subcommand,
+    each listed explicitly, and every write-shaped `gh api` call) require
+    a confirmation prompt; read-only gh subcommands and plain `gh api`
+    GETs do not; secrets/cred files are deny-read.
+  - The reference `permissions.allow` set of read-only entries ships to
+    adopters with `deny` and `ask`, and drift in it is reported like any
+    other settings drift.
 ---
 
 # Agent isolation / layered sandbox
@@ -109,7 +113,12 @@ existing sandbox grants can widen the baseline. See `docs/adapters/gemini.md`.
   (`<Deactivate>`, bound after a short grace because activation itself
   churns focus) rather than re-grabbing the keyboard: the overlay
   never traps the screen, since the key still has to be touched for
-  the command to go through (#1325). The
+  the command to go through (#1325). The macOS window takes
+  `SIGTERM` / `SIGINT` / `SIGHUP` back from Aqua Tk right after the root
+  window exists, so the watcher's close signal only sets the flag
+  `watch_for_stop` polls; Tk's own handler called `Tcl_Exit` inside the
+  signal and could deadlock the window mid-redraw until force-quit, and a
+  regression test pins the ordering (#1376). The
   git the agent runs reads the same global config, so the wrapper's
   two files are a `sandbox.filesystem.allowRead` grant of their own
   (nothing wider under `~/.claude/`), or every sandboxed signed commit
@@ -144,6 +153,17 @@ existing sandbox grants can widen the baseline. See `docs/adapters/gemini.md`.
   `git --no-pager commit`), never by a fixed argv slice, and
   `GuardContext.git_subcommand()` gives contributed guards the same
   resolution `gh_subcommand()` gives for `gh` (#1330).
+  The `commit-trailer` guard follows the project's commit-attribution
+  convention (#1385): it denies a `Co-Authored-By:` trailer unless the
+  convention resolved for the repository being committed to (following
+  `git -C`) is `co-authored-by`, failing closed to `generated-by` on an
+  unreadable file or unknown value, with `MAGPIE_ALLOW_COAUTHOR=1` as the
+  per-command override. It scans the message file a `-F` / `--file`
+  names, resolved against the `-C`-adjusted directory as git does,
+  alongside the command line and any `--trailer` (#1386); stdin and a file
+  that does not exist when the command starts are skipped, so a file
+  written earlier in the same command line is a known limit.
+  Resolution rules: `docs/setup/commit-attribution.md`.
   Capability: `substrate:action-guard`.
 - `tools/permission-audit/` — audits and atomically edits Claude Code's
   `permissions.allow[]` entries in `.claude/settings.json` and
@@ -160,6 +180,17 @@ existing sandbox grants can widen the baseline. See `docs/adapters/gemini.md`.
   local file is where they take effect. It never adds the credential
   paths the committed list also names; `--no-tool-paths` limits it to
   the project root. Checked by `setup-isolated-setup-verify` check 8.
+  It also adds the two directories the skills read on every run,
+  `$HOME/.claude/magpie` (the fixed vetted-ops path) and the scratch root
+  `/tmp/claude-<uid>`, to `permissions.additionalDirectories` of the same
+  file, resolved to literal absolute paths, because with
+  `permissions.blockReadsOutsideWorkingDirectories` on every read outside
+  a working directory asks and a glob such as `/tmp/claude-*` is listed
+  but never matched (#1418). They name one host's home directory and uid,
+  so they stay per host in the gitignored local file rather than in a
+  synced user-scope settings file; `--no-working-dirs` skips them.
+  Install proposes them (Step W), verify check 15 and doctor probe 9
+  report them, and update treats their absence as drift.
   Capability: `substrate:sandbox`.
 - Whole-user git hooks — the install skill's Step P.3 alternative to
   per-project scope: global `core.hooksPath` pointing at
@@ -219,6 +250,14 @@ The reference model is four layers, layered:
    `AGENT_ISO_ALLOW` explicitly names additional variables required by runtime authentication or tooling.
    It replaces `CLAUDE_ISO_ALLOW` when set, including an empty value; the legacy name remains supported otherwise.
    Unlisted variables stay stripped and values are never printed by the wrapper.
+   The sourced-mode flag that makes `claude-iso` and friends launch a
+   child rather than `exec` is a `local` inside each sourced entry point,
+   not a global: Claude Code's Bash tool replays a snapshot of functions
+   and aliases that drops plain variables, so under the documented
+   `alias claude=claude-iso` an agent's `claude --version` used to take
+   the `exec` path and replace its own shell (#1383). The verify and
+   install skills read the runtime version with `command claude --version`
+   for the same reason (#1384).
 2. **Filesystem + network sandbox** — Linux `bubblewrap` + `socat` SNI
    proxy; macOS `sandbox-exec`. Default-deny reads outside the tree and
    egress to non-allowed hosts. `sandbox.excludedCommands` carves out
@@ -229,16 +268,46 @@ The reference model is four layers, layered:
      `ask`).
    - the vetted-ops **read** dispatcher, which spawns `gh` and so
      inherits the same need; only the read dispatcher, never
-     `vetted-op` itself, because `--caller` is argv.
+     `vetted-op` itself, because `--caller` is argv. Both invocation
+     forms are excluded and allowed — `uv run --project … vetted-op-read`
+     and the `uvx --from … vetted-op-read` form the read-only gatherer
+     agents use (#1393) — and both name the fixed path
+     `~/.claude/magpie/vetted-ops` rather than a versioned plugin-cache
+     glob (#1406; see [`vetted-command-surface.md`](vetted-command-surface.md)).
+   - the vetted-ops **tracker** dispatcher, `vetted-op-tracker`, in both
+     forms (#1448).
+     The status-rollup and body-field writes need a `gh` that can verify
+     TLS, and `tools/github-rollup` / `tools/github-body-field` call `gh`
+     from a `uv run` subprocess, so every skill using them failed in the
+     sandbox.
+     Excluding this entry point is acceptable where excluding `vetted-op`
+     is not: it refuses every operation except the tracker procedures
+     before reading the policy, and their runner refuses any `gh` call
+     outside `repos/<tracker>/`.
+     It is on `ask` and never `allow`, so each write keeps its
+     confirmation.
+     `vetted-op` itself is never excluded, because that would run the
+     whole write catalogue unsandboxed.
+     sandbox-lint's `expected.json` carries both forms in
+     `excludedCommands` and `ask`, and its tests assert the tracker
+     dispatcher is excluded and asked but not allowed, and that
+     `vetted-op` is never excluded.
+   - the adversarial-review tool, in its single-line installed-plugin
+     form (`uvx --from ~/.claude/plugins/cache/apache-magpie/magpie-adversarial-review/*/tools/adversarial-review adversarial-review *`),
+     because the reviewer CLIs need network and their own credentials
+     (#1371). The plugin cache is `Edit`-denied, and there is
+     deliberately no `allow` rule, so every run keeps its prompt.
+     Install Step R wires it; verify check 14 checks the exclusion, the
+     deny and the absence of an allow.
    - `~/.claude/scripts/magpie-run-evals.sh` (optional), so a suite
      can be graded by `claude -p` from inside the sandbox.
 
    An exclusion runs whatever the command executes **outside** the
    sandbox, so the executed code must not be writable by the thing
-   being sandboxed. Both non-`gh` entries above therefore address code
-   outside the repository — the plugin cache and `~/.claude/scripts/`,
-   neither inside any `allowWrite` root — with `permissions.deny`
-   `Edit(…)` rules over the same paths. An in-repo path cannot carry
+   being sandboxed. The non-`gh` entries above therefore address code
+   outside the repository — the plugin cache, `~/.claude/magpie/` and
+   `~/.claude/scripts/`, none inside any `allowWrite` root — with
+   `permissions.deny` `Edit(…)` rules over the same paths. An in-repo path cannot carry
    that guarantee: without a deny the agent rewrites what runs
    unsandboxed, and a deny only stops the agent's editing tools while
    the file stays in a tree the agent can otherwise reach. The
@@ -267,6 +336,13 @@ The reference model is four layers, layered:
    `gh …` parts; the same whole-command shape rule governs the other
    entries. The rule and its failure signature are in
    [`sandbox-diagnostics.md`](sandbox-diagnostics.md).
+
+   `sandbox.filesystem.allowRead` grants Docker Desktop's CLI
+   directories `~/.docker/bin/` and `~/.docker/cli-plugins/` as exact
+   paths by default, so `docker`, `docker compose` and `docker buildx`
+   start inside the sandbox; the rest of `~/.docker` stays denied, and
+   `Read(~/.docker/**)` still denies it to the file tools (#1404; see
+   [`container-gateway.md`](container-gateway.md)).
 3. **Tool permissions** — the host's `permissions.deny` blocks denied
    paths/binaries (`Read(~/.ssh/**)`, `Bash(curl *)`, …).
 4. **Forced confirmation** — `permissions.ask` on `git push` and,
@@ -279,6 +355,34 @@ The reference model is four layers, layered:
    read. A subcommand in neither list falls through to the mode's
    default (prompt in default mode, classifier in auto).
 
+   `gh api` asks only in its write shapes (#1432). It sends something
+   other than a GET only when it names a method (`-X` / `--method`),
+   sends request fields (`-f` / `-F` / `--field` / `--raw-field`, which
+   switch the default to POST) or sends a body (`--input`), so the ask
+   list matches each of those flags both right after `gh api` and later
+   in the command, value attached or separate. A plain GET (with `--jq`,
+   `-H` or `--paginate`) does not prompt, and the specific `gh api` GET
+   allow rules, which a blanket `Bash(gh api *)` ask had silently
+   overridden, take effect. GraphQL still asks, since every call sends
+   `-f query=…` and a pattern cannot tell a query from a mutation.
+   sandbox-lint's `expected.json` mirrors the rules.
+
+   The **allow** half ships too (#1393). `setup-isolated-setup-install`
+   carries the reference `permissions.allow` set into an adopter's
+   settings merge alongside `deny` and `ask` — `gh` reads, both
+   vetted-ops read forms, the read-only archive / mailbox / roster MCP
+   tools, and the registry `WebFetch` hosts (`cveawg.mitre.org`,
+   `pypi.org`, `lists.apache.org`) — and `setup-isolated-setup-update`
+   diffs it, because a missing read-only entry is a prompt on every skill
+   run. Only read-only entries belong there; `vetted-op` (writes) stays
+   on `ask`.
+   Install Step V now describes three entry points over one catalogue and
+   adds `vetted-op-tracker` to both `ask` and `sandbox.excludedCommands`.
+   The update skill reports `vetted-op-tracker` in `allow`, or `vetted-op`
+   in `excludedCommands`, as a must-fix, and a missing tracker exclusion
+   or `ask` entry as drift; the verify skill fails the check when
+   `vetted-op` is in `excludedCommands` (#1448).
+
 Pinned system tools (`bubblewrap`, `socat`, agent CLI) are aged through a
 cooldown window; bumps are PRs, not silent updates. The window is the
 framework's 7-day default unless a tool's `[tools.<name>]` table in
@@ -301,6 +405,11 @@ carrying a sandbox-setup security fix can move a day after release
 3. `git push` and every `gh` write subcommand are in `permissions.ask`,
    the read-only `gh` subcommands are in `allow`, and no catch-all
    `Bash(gh *)` sits in `ask`; secret/cred files are in `permissions.deny`.
+4. `gh api` asks in each write shape (`-X`, `--method`, `-f`, `-F`,
+   `--field`, `--raw-field`, `--input`, directly after `gh api` or later)
+   and not on a plain GET; no blanket `Bash(gh api *)` sits in `ask`.
+5. The adopter install merges `permissions.allow` with `deny` and `ask`,
+   and the update skill diffs it.
 
 ## Validation
 
@@ -312,7 +421,9 @@ uv run --project tools/egress-gateway --group dev pytest
 python3 -c "import json,sys; s=json.load(open('.claude/settings.json')); \
   ask=s['permissions']['ask']; \
   sys.exit(0 if any(a.startswith('Bash(git push') for a in ask) \
-    and 'Bash(gh pr merge *)' in ask and 'Bash(gh *)' not in ask else 1)"
+    and 'Bash(gh pr merge *)' in ask and 'Bash(gh *)' not in ask \
+    and 'Bash(gh api -X*)' in ask and 'Bash(gh api *)' not in ask else 1)"
+uv run --project tools/sandbox-lint --group dev pytest
 ```
 
 ## Known gaps
diff --git a/tools/spec-loop/specs/codex-runtime.md b/tools/spec-loop/specs/codex-runtime.md
index cd922a382..ad7b722df 100644
--- a/tools/spec-loop/specs/codex-runtime.md
+++ b/tools/spec-loop/specs/codex-runtime.md
@@ -40,8 +40,13 @@ tool adapters, and uses its own sandbox, rules, and approvals.
 - tools/sandbox-lint/ - static Codex profile validator (--codex).
 - tools/agent-isolation/ - clean-env agent-iso codex launcher.
 - docs/adapters/codex.md - operator contract and lifecycle.
-- skills/setup/ and skills/setup-isolated-setup-*/ - installation, drift,
-  verification, and removal paths.
+- plugins/magpie-setup/skills/setup/ and
+  plugins/magpie-setup/skills/isolated-setup-*/ (linked from skills/setup and
+  skills/setup-isolated-setup-*) - installation, drift, verification, and
+  removal paths.
+- tools/adversarial-review/ - Codex as an adversarial reviewer backend, and
+  the Codex command file for asking other models to review a change
+  (see [adversarial review](adversarial-review.md)).
 
 ## Behaviour & contract
 
@@ -55,6 +60,17 @@ tool adapters, and uses its own sandbox, rules, and approvals.
 6. Project trust is a human decision. Setup never edits Codex trust state.
 7. The .codex policy files are committed and reviewed; existing unrelated
    .codex configuration is preserved during adoption and upgrade.
+8. Codex as a reviewer runs read-only: the adversarial-review tool invokes
+   `codex exec -s read-only --ephemeral -c mcp_servers={}` with an output
+   schema, pinned by `tools/adversarial-review/tests/test_backends.py`, and
+   skips it when Codex is the harness running the review.
+9. From a Codex session, `setup config adversarial-review` can write
+   `~/.codex/prompts/magpie-adversarial-review.md`, rendered by
+   `adversarial-review commands --harness codex`, under the user's home and
+   never in a repository.
+   The prompt resolves the newest installed plugin version at run time and
+   tells the agent to ask for an unsandboxed run, because the reviewer CLIs
+   need network and their own credentials.
 
 ## Out of scope
 
@@ -103,3 +119,8 @@ codex execpolicy check --pretty \
 - The POSIX clean-environment wrapper needs WSL on Windows.
 - User-scoped MCP registration and tool authentication remain outside
   repository policy.
+- As a reviewer, `codex -s read-only` restricts writes and network but not
+  reads, so an instruction injected into a reviewed diff could have it read
+  files elsewhere on the machine; the adversarial-review README tells
+  operators to leave `codex` out of the reviewer list on machines that hold
+  private checkouts.
diff --git a/tools/spec-loop/specs/container-gateway.md b/tools/spec-loop/specs/container-gateway.md
index 5e6d40976..72aa54343 100644
--- a/tools/spec-loop/specs/container-gateway.md
+++ b/tools/spec-loop/specs/container-gateway.md
@@ -389,9 +389,12 @@ and bubblewrap; the gateway does nothing for a CLI the sandbox cannot
 run. `podman` from Homebrew or a distro package lives outside every
 denied path. Docker Desktop installs `docker` under `~/.docker/bin/`
 and its plugins under `~/.docker/cli-plugins/`, both inside the
-`~/.docker` read denial; the catalog entry keeps the exact-path
-`allowRead` for those two locations and recommends the Homebrew `docker`
-CLI, which needs no widening. On Linux both CLIs are under `/usr/bin`.
+`~/.docker` read denial.
+The reference `sandbox.filesystem.allowRead` grants exactly those two paths by default (#1404), so `docker`, `docker compose` and `docker buildx` start inside the sandbox out of the box.
+The rest of `~/.docker` (auth tokens, saved contexts) stays denied to the sandbox, and `Read(~/.docker/**)` still denies it to the agent's file tools; sandbox-lint asserts both the grant and that no broader `~/.docker` entry appears.
+A settings file that predates the default adds the two exact paths itself, as the catalog entry says.
+A Homebrew `docker` CLI needs neither, and the two entries are harmless no-ops for it.
+On Linux both CLIs are under `/usr/bin`.
 
 ## Out of scope
 
diff --git a/tools/spec-loop/specs/contributor-growth.md b/tools/spec-loop/specs/contributor-growth.md
index dad2cc5cc..5e6cb6750 100644
--- a/tools/spec-loop/specs/contributor-growth.md
+++ b/tools/spec-loop/specs/contributor-growth.md
@@ -11,9 +11,14 @@ source: >
   base"). triage-mode.md § Known gaps (contributor-growth skills span
   Agentic Triage and Agentic Mentoring but are not yet a named family).
   mentoring-mode.md § Known gaps. Implemented by contributor-nomination,
-  contributor-activity-sweep, committer-onboarding, contributor-identity-map,
-  good-first-issue-author,
-  mentoring-welcome, contributor-to-committer, and good-first-issue-sweep.
+  contributor-activity-sweep, contributor-calibrate,
+  contributor-candidate-screen, committer-onboarding,
+  contributor-identity-map, contributor-sentiment, onboarding-concierge,
+  contributor-to-committer (plugins/magpie-contributor-growth/), and
+  good-first-issue-author, mentoring-welcome, good-first-issue-sweep
+  (plugins/magpie-mentoring/). Deterministic counting in
+  tools/contributor-metrics; chat evidence through tools/chat
+  (contract:chat) and tools/chat-slack.
 acceptance:
   - Every family skill is read-only or propose-before-post; none
     transitions, promotes, or announces without explicit maintainer
@@ -40,7 +45,14 @@ stage a maintainer or nominator cares about:
    to open a committer or PMC vote thread.
 4. **Good first issue authoring** — keeping the on-ramp stocked with
    newcomer-ready issues so contributors can find self-contained tasks.
-5. **Post-vote onboarding** — walking the nominator through the
+5. **Calibration and screening** — deriving the committer and PMC
+   threshold floors from the project's own past nomination decisions,
+   then screening every recent contributor against them so candidates
+   are noticed rather than waiting to be named.
+6. **Identity mapping** — linking a contributor's GitHub handle to
+   their chat, mailing-list, and social-media identities, recording
+   only what a maintainer confirms.
+7. **Post-vote onboarding** — walking the nominator through the
    ICLA check, account provisioning, permissions, and welcome
    announcement once a vote passes.
 
@@ -50,6 +62,23 @@ state change for human sign-off.
 
 ## Where it lives
 
+Skills ship in two plugins, each reachable through a `skills/<dir>`
+symlink:
+`plugins/magpie-contributor-growth/skills/<alias>/SKILL.md`
+(`activity-sweep`, `calibrate`, `candidate-screen`,
+`committer-onboarding`, `contributor-to-committer`, `identity-map`,
+`nomination`, `onboarding-concierge`, `sentiment`) and
+`plugins/magpie-mentoring/skills/<alias>/SKILL.md` (`welcome`,
+`good-first-issue-author`, `good-first-issue-sweep`).
+Family overview: `docs/contributor-growth/README.md`.
+Design record:
+`docs/designs/2026-09-27-contributor-growth-calibration-and-screening.md`.
+Adopter config scaffolds live in `plugins/magpie-setup/templates/`
+(`projects/_template` is a symlink to it): `committer-readiness.md`,
+`contributor-nomination-config.md`, `committer-onboarding-config.md`,
+`contributor-identities.md`, `contributor-sentiment-config.md`,
+`onboarding-concierge-config.md`.
+
 - Skill: `mentoring-welcome` — drafts a first-contact orientation
   comment for a first-time contributor on a newly opened issue or PR.
   Detects first-time authorship via the GitHub `author_association`
@@ -92,10 +121,12 @@ state change for human sign-off.
   provisioning, permissions, and welcome-announcement checklist for
   committer and PMC promotions at ASF TLPs and podlings.
   Propose-before-post at every state-changing step. Ships
-  `mode: Triage` + `experimental`, eval suite under
+  `mode: Meta` + `experimental` (catalogued in the Meta table of
+  `docs/modes.md`), eval suite under
   `tools/skill-evals/evals/committer-onboarding/`. Step 2 maps the
   new committer's channel identities through
-  `contributor-identity-map`.
+  `contributor-identity-map`; the former Steps 2 and 3 are now
+  Steps 3 and 4.
 - Skill: `contributor-identity-map` — maps any contributor's GitHub
   handle to their Slack, Discord, Matrix, mailing-list, and
   social-media handles. Infers from the sources the session can
@@ -114,12 +145,47 @@ state change for human sign-off.
   committer or PMC thresholds; surfaces a traffic-light brief (Not yet /
   Approaching / Ready to nominate) plus the specific evidence gaps that
   remain. Ships `mode: Mentoring` + `experimental`.
+- Skill: `contributor-sentiment` — measures contributor-sentiment
+  signals over a window (thread tone, time-to-first-reply, first-PR
+  retention, reviewer-load Gini), compares them with a pre-adoption
+  baseline, and produces the structured gate report used to decide
+  whether a family advances from `experimental` to `stable`. Read-only.
+  Ships `mode: Triage` + `experimental`, eval suite under
+  `tools/skill-evals/evals/contributor-sentiment/`.
+- Skill: `onboarding-concierge` — answers a newcomer's "how do I
+  contribute here" question grounded in `CONTRIBUTING.md` and the
+  project's docs; classifies the question (setup / workflow /
+  first-issue / out-of-scope) and hands design, security, and
+  deprecation questions to a human. Draft only. Ships
+  `mode: Mentoring` + `experimental`, eval suite under
+  `tools/skill-evals/evals/onboarding-concierge/`.
 - Skill: `good-first-issue-sweep` — sweeps the open issue backlog for
   existing issues that could be labelled as good first issues; classifies
   each candidate as READY, NEAR-MISS, or SKIP against the G1–G7 rubric;
   applies labels only after explicit maintainer confirmation. Ships
   `mode: Mentoring` + `experimental`, eval suite under
   `tools/skill-evals/evals/good-first-issue-sweep/`.
+- Shared nomination references under
+  `plugins/magpie-contributor-growth/skills/nomination/`:
+  `automated-contributions.md` (discount and pushback-penalty rules),
+  `community-signals.md` (Step 3 community evidence), and
+  `real-names.md` (how people are named in briefs and reports),
+  alongside the step files `fetch.md`, `assess.md`, and `render.md`.
+- Tool: `tools/contributor-metrics` (`substrate:analytics`,
+  stdlib-only, shells out to `gh`) with three subcommands.
+  `fetch` collects five GitHub streams, applies the substantive-review
+  rule, flags pushback candidates, and caches by repository, handle,
+  window, phrases and roster (`--refresh` bypasses the cache).
+  `score` applies weights and the penalty and returns per-area shares
+  (with an `(unlabelled)` row), merge rate, a monthly timeline, and
+  which streams hit their search cap; `--since` scores a sub-window.
+  `floors` computes recency-weighted nearest-rank percentiles for
+  calibration.
+  Unit tests under `tools/contributor-metrics/tests/`.
+- Tools: `tools/chat` (`contract:chat`, read-only `list_channels`,
+  `resolve_user`, `search_messages`) and `tools/chat-slack` (Slack MCP
+  adapter, public channels only, never posts).
+  Discord is an extension point with no adapter yet.
 
 ## Behaviour & contract
 
@@ -160,9 +226,47 @@ state change for human sign-off.
   presence and release testing, chat answers through `contract:chat`
   (Slack adapter; public channels only), GitHub Discussions answers,
   and project-related posts on accounts the contributor linked
-  themselves. Identities count only when confirmed; reasoned criticism
-  is constructive; the community indicator never changes counts,
-  thresholds or the band.
+  themselves. Identities count only when confirmed: a chat or social
+  profile that merely names the GitHub handle is a possible match, not
+  an identity, and a self-linked account counts only when it links back
+  to the GitHub profile. Reasoned criticism is constructive. The
+  community indicator never changes counts, thresholds or the band,
+  though any confirmed collected row means an off-GitHub signal is
+  present; in `contributor-to-committer` that signal is always
+  mandatory and never treated as met by default.
+- **Thresholds come from the project's own history.**
+  `contributor-calibrate` reads past `[DISCUSS]` / `[VOTE]` / `[RESULT]`
+  nomination threads on the private list behind the privacy-LLM gate.
+  It keeps one structured row per nomination (target, vote date,
+  outcome, coarse deferral category), never votes, opinions or quotes.
+  It bounds the archive query at the holdout date and never opens an
+  excluded thread.
+  `contributor-metrics floors` computes the floors; a metric that does
+  not separate elected from deferred nominees is evidence-only, and
+  capped counts are left out of a metric's distribution.
+  The config diff carries numbers, `calibrated_on` and
+  `calibrated_window_months` only.
+  `contributor-to-committer` warns on a mismatched window and suggests
+  recalibrating after a year; `contributor-nomination` flags stale or
+  mismatched calibration; `/magpie-setup config` offers calibration
+  when thresholds are blank.
+- **Screening reports go only to a verified-private repository.**
+  `contributor-candidate-screen` builds its pool from merged PRs,
+  sliced by month and then week so GitHub's 1000-result search limit
+  never truncates it (it stops if a single day exceeds the limit).
+  It maps roster ids to GitHub handles through the directory or the
+  maintainer, never by guessing, and stops without a roster.
+  It logs every pre-filter drop, ignores evidence-only floors, does not
+  pre-filter the PMC pool, and treats a capped count below its floor as
+  unknown (written `>= N`), never missing.
+  The report is committed to `report_repo` only after the maintainer
+  confirms, and only when `gh api` reports the repository private,
+  checked before showing and again before writing; a gist is never
+  offered. The report uses plain profile links, never `@`-mentions.
+- **Real names are verified, never inferred.** Briefs and reports name
+  people per `nomination/real-names.md`: the people directory first,
+  then the GitHub profile name, then a consistent commit author name.
+  A name is never inferred from an email address or a handle.
 - **Teaching register for first-contact.** `mentoring-welcome` and
   `good-first-issue-author` follow the Agentic Mentoring mode's tone
   contract (polite, never gatekeeping) and hand off to a human
@@ -216,15 +320,27 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   before a skill can safely propose anything. These are candidate work
   items once the active-path skills stabilise and an adopter pilot
   surfaces the concrete policy knobs needed.
-- **Mode boundary with Agentic Mentoring is intentionally fuzzy.** Four family
-  skills (`mentoring-welcome`, `good-first-issue-author`,
-  `contributor-to-committer`, `good-first-issue-sweep`) carry
-  `mode: Mentoring` and are documented in [mentoring-mode.md](mentoring-mode.md);
-  three carry `mode: Triage` (`contributor-activity-sweep`,
-  `contributor-nomination`, `committer-onboarding`). A later family-maturity
-  review may formalise the boundary or merge the families; for now, both
-  specs cross-reference each other.
-- **`experimental` — no adopter pilot has run.** All seven skills exist
+- **Mode boundary with Agentic Mentoring is intentionally fuzzy.** Five
+  family skills (`mentoring-welcome`, `good-first-issue-author`,
+  `contributor-to-committer`, `good-first-issue-sweep`,
+  `onboarding-concierge`) carry `mode: Mentoring` and are documented in
+  [mentoring-mode.md](mentoring-mode.md).
+  Six carry `mode: Triage` (`contributor-activity-sweep`,
+  `contributor-nomination`, `contributor-calibrate`,
+  `contributor-candidate-screen`, `contributor-identity-map`,
+  `contributor-sentiment`), and `committer-onboarding` carries
+  `mode: Meta`.
+  The plugin split does not follow the mode split either:
+  `onboarding-concierge` and `contributor-to-committer` ship in
+  `magpie-contributor-growth`, the other three Mentoring skills in
+  `magpie-mentoring`.
+  A later family-maturity review may formalise the boundary or merge the
+  families; for now, both specs cross-reference each other.
+- **Chat evidence is Slack-only.** `contract:chat` has one adapter
+  (`tools/chat-slack`); Discord and Matrix answers are not collected
+  until an adapter lands.
+- **`experimental` — no adopter pilot has run.** All twelve skills exist
   but no maintainer has run the full contributor-to-committer path
-  end-to-end through the family. Shape may change as adopter pilots
-  surface real-world usage patterns.
+  end-to-end through the family, and calibration has not yet run against
+  a real project's nomination history. Shape may change as adopter
+  pilots surface real-world usage patterns.
diff --git a/tools/spec-loop/specs/copilot-runtime.md b/tools/spec-loop/specs/copilot-runtime.md
index f0c9a1b94..80282c01c 100644
--- a/tools/spec-loop/specs/copilot-runtime.md
+++ b/tools/spec-loop/specs/copilot-runtime.md
@@ -53,6 +53,8 @@ machine and the other on shared cloud infrastructure.
 - `~/.copilot/mcp-config.json` - MCP servers for the CLI; the Coding
   Agent configures its own in repository Copilot settings.
 - `tools/agent-isolation/agent-iso.sh` - the clean-environment launcher.
+- `tools/adversarial-review/` - Copilot CLI as an adversarial reviewer
+  backend (see [adversarial review](adversarial-review.md)).
 
 ## Behaviour & contract
 
@@ -92,6 +94,15 @@ machine and the other on shared cloud infrastructure.
   `git push`. Branch protection and keeping the permissive flags off are
   what actually hold. Stripping local environment variables also does
   nothing to the cloud inference boundary above.
+- **Copilot CLI as a reviewer.** The adversarial-review tool runs
+  `copilot -p` with the brief directory added and the `shell` and `write`
+  tools denied, pinned by `tools/adversarial-review/tests/test_backends.py`,
+  and skips it when Copilot is the harness running the review.
+  Only the diff and the public PR title and body are in its prompt.
+  Copilot CLI has no command-file mechanism, so
+  `adversarial-review commands --harness copilot` returns an empty path and
+  `setup config adversarial-review` shows the one-line invocation instead of
+  writing a file.
 
 ## Out of scope
 
@@ -148,3 +159,11 @@ uv run prek run doctoc --all-files
 - **The Coding Agent's MCP configuration is not in the repository.** It
   lives in repository Copilot settings, so it cannot be reviewed in a
   PR the way `.mcp.json` or the CLI's `~/.copilot/mcp-config.json` can.
+- **No `.github/copilot-instructions.md` in the framework repository.**
+  `docs/adapters/copilot.md` shows the file as something an adopter
+  configures, but this repository ships none, so acceptance criterion 2 is
+  met only in adopters that add it.
+- **A Copilot reviewer keeps its MCP servers.** Copilot CLI has no switch to
+  drop configured MCP servers, so as an adversarial reviewer any it is
+  configured with stay reachable; the tool README says to configure it with
+  read-only servers or none.
diff --git a/tools/spec-loop/specs/cve-tooling.md b/tools/spec-loop/specs/cve-tooling.md
index 8d03ef138..e1bec29c0 100644
--- a/tools/spec-loop/specs/cve-tooling.md
+++ b/tools/spec-loop/specs/cve-tooling.md
@@ -34,14 +34,20 @@ reviewable.
   issue's template fields (multiple credits, multiple reference URLs,
   `>= X, < Y` version ranges) and emits `containers.cna` JSON matching
   Vulnogram's export shape, plus the Vulnogram `#json` paste URL.
-- `tools/cve-tool-vulnogram/oauth-api/` — a `uv` project exposing three
-  console scripts (`vulnogram-api-setup`, `vulnogram-api-record-update`,
-  `vulnogram-api-check`) that POST CVE 5.x JSON to the Vulnogram HTTP
-  API with a Bearer token the operator copies from
-  `https://cveprocess.apache.org/users/token` after logging in (MFA
-  included) in their own browser, replacing the copy-paste-into-`#source`
-  flow. The tool never sees the operator's password, MFA factor, or
-  session cookie. The skill detects token expiry via `vulnogram-api-check`
+- `tools/cve-tool-vulnogram/oauth-api/` — a `uv` project exposing five
+  console scripts that talk to the Vulnogram HTTP API with a Bearer token
+  the operator copies from `https://cveprocess.apache.org/users/token`
+  after logging in (MFA included) in their own browser, replacing the
+  copy-paste-into-`#source` flow:
+  `vulnogram-api-setup` (token capture via `getpass`, written mode 600
+  under `~/.config/apache-magpie/vulnogram-session.json`),
+  `vulnogram-api-record-update` (POST to the `/cve5/<CVE-ID>` upsert
+  endpoint), `vulnogram-api-record-publish` (move a record
+  `REVIEW` → `PUBLIC`), `vulnogram-api-record-fetch` (read-only: full
+  record, `--state-only`, or `--comments-only` for reviewer comments), and
+  `vulnogram-api-check` (probe: `valid` / `expired` / `not-configured`).
+  The tool never sees the operator's password, MFA factor, or session
+  cookie. The skill detects token expiry via `vulnogram-api-check`
   and falls back to the manual paste path when no token is configured
   or it has expired.
 - `tools/cve-org/` — CVE.org / CVE-services helpers; the `check-published`
@@ -55,9 +61,12 @@ reviewable.
   operation (`osv-get-vuln`, `osv-query-package`, `osv-query-commit`,
   `osv-query-batch`); `api.osv.dev` is on the egress gateway's allowlist
   (#1297, #1326).
-- Skill: `security-cve-allocate` — walks the (PMC-gated) allocation form,
-  then updates the tracker and regenerates the attached JSON via
-  `generate-cve-json --attach`.
+- Skill: `security-cve-allocate`
+  (`plugins/magpie-security/skills/cve-allocate/`, with the Step 4
+  tracker-update proposals in `tracker-updates.md` and title
+  normalisation in `title-normalize.md`) — walks the (PMC-gated)
+  allocation form, then updates the tracker and regenerates the attached
+  JSON via `generate-cve-json --attach`.
 
 ## Behaviour & contract
 
@@ -70,6 +79,30 @@ reviewable.
   user is not on the PMC; it reshapes the recipe into a relay message.
 - **Lock-step.** The attached JSON is regenerated whenever the tracker
   body changes, so the two never drift.
+  Replacing an existing embedded block inserts the new JSON verbatim, so
+  backslash escapes inside string values (`\n` in a multi-paragraph
+  summary, `\\`, `\1`) survive and the embedded JSON still parses (#1377).
+- **Allocation applies exactly what it proposed.** Step 5 of
+  `security-cve-allocate` applies the one-field `github-body-field set`
+  on *CVE tool link* that Step 4 proposed, rather than rewriting the
+  whole issue body (#1444).
+- **Token-scoped API access.** The recommended token is the PMC-scoped
+  `write` token, which the server accepts only on `/cve5/CVE-*` and
+  `/cve5/json/CVE-*`; `allocate` tokens are refused on those endpoints.
+  Bearer-authenticated requests are exempt from Vulnogram's CSRF check,
+  so an update is a single POST with no CSRF-token scrape, and the
+  liveness probe targets `/cve5/json/CVE-0000-00000` because `/cve5/new`
+  is not on the token allowlist.
+  A credentials file written by the earlier `connect.sid` cookie flow is
+  refused with a pointer to `/users/token` (#1387).
+- **Record updates do not regress a published record.**
+  `vulnogram-api-record-update` fetches the current record and, by
+  default, refuses a `CNA_private.state` downgrade from `PUBLIC`, refuses
+  an `affected[].product` / package change, and merges `references[]` by
+  URL so a hand-added reference is kept.
+  Each guard has an explicit override (`--allow-state-downgrade`,
+  `--allow-product-change`, `--replace-references`, or the umbrella
+  `--full-replace`).
 
 ## Out of scope
 
diff --git a/tools/spec-loop/specs/drafting-mode.md b/tools/spec-loop/specs/drafting-mode.md
index 8776401de..a9fd95da3 100644
--- a/tools/spec-loop/specs/drafting-mode.md
+++ b/tools/spec-loop/specs/drafting-mode.md
@@ -9,7 +9,12 @@ mode: Drafting
 source: >
   MISSION.md § Technical scope (Drafting). docs/modes.md § Drafting.
   Implemented by security-issue-fix (stable, security-only),
-  issue-fix-workflow (experimental), and audit-finding-fix (experimental).
+  issue-fix-workflow (experimental), and audit-finding-fix (experimental),
+  in plugins/magpie-security/skills/issue-fix/,
+  plugins/magpie-issue/skills/fix-workflow/ and
+  plugins/magpie-repo-health/skills/audit-finding-fix/. Every PR they open
+  passes through the shared pre-PR adversarial-review block
+  (tools/dev/blocks/pre-pr-adversarial-review.md).
 acceptance:
   - A drafting skill produces the failing test, the smallest production
     change, targeted test runs, and a commit — but never merges.
@@ -17,6 +22,9 @@ acceptance:
     or handed back for the human to push; no autopilot push/merge.
   - Security-class drafts scrub CVE / tracker-slug / "security fix" /
     "vulnerability" from every public surface until the embargo lifts.
+  - Before a drafting skill opens a PR, the configured adversarial reviewers
+    read the diff and the PR title and body as they will be posted; their
+    findings are advisory and never block.
 ---
 
 # Agentic Drafting mode
@@ -31,17 +39,32 @@ merges its own work.
 
 ## Where it lives
 
-- `security-issue-fix` (stable, security-only) — drafts the fix in the
+- `security-issue-fix` (stable, security-only;
+  `plugins/magpie-security/skills/issue-fix/`) — drafts the fix in the
   user's local `<upstream>` clone, runs local checks, opens the public
   PR via `gh pr create --web`, scrubs confidential framing.
-- `issue-fix-workflow` (experimental) — drafts a fix for a triaged
+- `issue-fix-workflow` (experimental;
+  `plugins/magpie-issue/skills/fix-workflow/`) — drafts a fix for a triaged
   general-issue; **does not** open the PR on autopilot, hands back a
-  branch + commits + test results for the human to push.
-- `audit-finding-fix` (experimental) — drafts a fix for a finding from
-  an audit tool (ruff, mypy, security scanner); parses the finding
-  report, implements the smallest fix, scope-checks the diff, and hands
-  back a commit for the human to push.
-- `tools/dev` — shared local-check helpers.
+  branch + commits + test results.
+  An optional Step 9 opens a draft PR with `gh pr create --web --draft`
+  only when `--draft-pr` was passed and the user confirms after the
+  hand-back.
+- `audit-finding-fix` (experimental;
+  `plugins/magpie-repo-health/skills/audit-finding-fix/`) — drafts a fix
+  for a finding from an audit tool (ruff, mypy, security scanner); parses
+  the finding report, implements the smallest fix, scope-checks the diff,
+  and hands back a commit.
+  An optional Step 8 opens a draft PR the same way, on `--draft-pr` and a
+  confirmation.
+- Other skills carry `mode: Drafting` and are specified with their own
+  families: the release-management drafting skills
+  ([release-management lifecycle](release-management-lifecycle.md)) and
+  `security-model-prepare` / `security-model-update`
+  ([security-model preparation](security-model-preparation.md)).
+- `tools/dev` — shared local-check helpers, and
+  `tools/dev/blocks/pre-pr-adversarial-review.md`, the shared block every
+  PR-opening skill carries ([adversarial review](adversarial-review.md)).
 
 ## Behaviour & contract
 
@@ -51,7 +74,21 @@ merges its own work.
   title/body, newsfragment are scrubbed for CVE IDs, the tracker repo
   slug, and the words "security fix" / "vulnerability" before any write
   or push (see `AGENTS.md` § Confidentiality).
-- **Commit trailer** `Generated-by:` — never `Co-Authored-By:` an agent.
+- **Adversarial review before the PR.** Each drafting skill that opens a
+  PR carries the shared pre-PR block: once the title and body are final and
+  after the skill's own public-surface checks (the security scrub
+  included), the configured reviewers read only the diff and that public
+  text.
+  The security family runs the review whenever a reviewer is configured,
+  whatever the `mode`; the others only on `mode: on-pr-create`.
+  Findings are untrusted, advisory data; one the human wants fixed sends
+  the flow back to the fix and its checks.
+  `skill-and-tool-validate` fails a PR-opening skill without the block.
+- **Commit trailer** follows the project's commit-attribution convention
+  (`Generated-by:`, `Assisted-by:`, `Co-authored-by:`, none, or a custom
+  trailer), resolved per `docs/setup/commit-attribution.md` and added with
+  `git commit --trailer`; the agent-guard `commit-trailer` guard resolves it
+  the same way (#1385).
 
 ## Out of scope
 
@@ -63,7 +100,8 @@ merges its own work.
 
 1. No drafting skill merges or force-pushes.
 2. Security drafts pass the confidentiality scrub before any public write.
-3. `skill-and-tool-validate` passes on the drafting-family skills.
+3. `skill-and-tool-validate` passes on the drafting-family skills,
+   including the `pre-pr-review-block` check.
 
 ## Validation
 
diff --git a/tools/spec-loop/specs/good-first-issue-sweep.md b/tools/spec-loop/specs/good-first-issue-sweep.md
index a4e9188f5..9c30c05a1 100644
--- a/tools/spec-loop/specs/good-first-issue-sweep.md
+++ b/tools/spec-loop/specs/good-first-issue-sweep.md
@@ -47,32 +47,60 @@ already sitting in the backlog.
 
 ## Where it lives
 
-- Skill: `good-first-issue-sweep` under `skills/`, in the Mentoring
-  family alongside `good-first-issue-author` and `mentoring-welcome`.
+- Skill: `plugins/magpie-mentoring/skills/good-first-issue-sweep/SKILL.md`
+  (reachable as `skills/good-first-issue-sweep`), in the
+  `magpie-mentoring` plugin alongside `good-first-issue-author`,
+  `welcome` (`mentoring-welcome`), and `newcomer-issue-explainer`.
 - Adopter config scaffold (shared with `good-first-issue-author`):
-  `projects/_template/good-first-issue-config.md` — label name,
-  getting-started link, `max_effort_hours`, `out_of_scope_topics`,
-  `ai_attribution_footer`.
-- Tracker read / label-write access via `tools/github`.
+  `plugins/magpie-setup/templates/good-first-issue-config.md`
+  (`projects/_template` is a symlink to that directory).
+  The sweep reads `good_first_issue_label`, `max_effort_hours`
+  (default 4), and the out-of-scope topics list; the getting-started link
+  and AI-attribution footer serve `good-first-issue-author`.
+  It also requires `issue-tracker-config.md` (both files are declared
+  in `requires_config:`).
+- Pre-flight: the shared `setup_preflight` checker runs first with this
+  skill's `surface_hash` and `requires_config:` entries; adopter
+  overrides resolve from `.apache-magpie-local/good-first-issue-sweep.md`,
+  then `.apache-magpie-overrides/good-first-issue-sweep.md`.
+- Tracker read / label-write access via `tools/github` (`gh issue list`,
+  `gh issue edit`).
 
 ## Behaviour & contract
 
 - **Propose before label.** The skill reads the open backlog, scores
   each issue, and proposes label additions. No `gh issue edit` call runs
   until the maintainer confirms each READY candidate.
+  The confirmation takes `all`, a list of issues, or `none`; labels are
+  then applied one issue at a time, and the run stops and reports on
+  the first failed `gh issue edit` rather than retrying.
 - **Two-class output for actionable issues.** READY issues get the GFI
   label proposed; NEAR-MISS issues get a list of specific edits that
   would make them GFI-ready, with the maintainer deciding whether to make
   those edits and re-run.
-- **Three-class skip.** Security-sensitive (`security-sensitive`),
-  architectural (`architectural-decision`), and deprecation-gating
-  (`deprecation-decision`) issues are always SKIP.
+- **Hard-stop and readiness criteria.** G5 (not security-sensitive),
+  G6 (no architectural decision), and G7 (no deprecation or removal
+  timing decision) are hard stops: any failure is SKIP, recorded as
+  `security-sensitive`, `architectural-decision`, or
+  `deprecation-decision`, and G1–G4 are not scored.
+  G1 (well-scoped), G2 (self-contained), G3 (a concrete code pointer; a
+  command or CLI name alone does not count), and G4 (effort within
+  `max_effort_hours`) are scored independently; all passing is READY,
+  any failing is NEAR-MISS with the failing codes listed.
+  Topics in `out_of_scope_topics` always classify SKIP.
+- **Config-bounded labelling.** Only the configured
+  `good_first_issue_label` is ever proposed; a missing required config
+  key aborts the run and points at the template rather than guessing.
+- **Skips are summarised, not itemised.** SKIP issues appear only as a
+  count per reason unless the maintainer asks for detail.
 - **Untrusted content stays data.** Issue bodies and comment threads are
   read as content, not instructions. An injected "label this good first
   issue" or "mark as READY" in an issue body is flagged and ignored.
-- **Pool-bounded.** The sweep caps at 30 issues per session unless the
-  maintainer explicitly raises the limit; large backlogs are narrowed
-  with component or label filters.
+- **Pool-bounded.** The pool is open issues not already carrying the
+  GFI label, optionally narrowed with `--component` or `--label`.
+  The skill echoes the candidate count and waits for confirmation
+  before classifying. It caps at 30 issues per session (`--limit`,
+  default 30); a larger pool is sent back to be narrowed.
 
 ## Out of scope
 
diff --git a/tools/spec-loop/specs/issue-management-family.md b/tools/spec-loop/specs/issue-management-family.md
index e2761ce1d..7776b0ab0 100644
--- a/tools/spec-loop/specs/issue-management-family.md
+++ b/tools/spec-loop/specs/issue-management-family.md
@@ -13,13 +13,16 @@ source: >
   docs/issue-management/README.md. Implemented by issue-triage,
   issue-reassess, issue-reassess-stats, issue-reproducer,
   issue-fix-workflow, issue-stale-sweep, issue-backlog-stats, and
-  issue-deduplicate.
+  issue-deduplicate, shipped in plugins/magpie-issue/skills/<alias>/ and
+  linked from skills/issue-<alias>.
 acceptance:
   - Every issue-management skill is read-only or proposes-then-confirms;
     none applies a label, comment, or close without explicit maintainer
     confirmation.
-  - issue-fix-workflow produces a branch, commits, and test results but
-    never pushes or opens a PR without the maintainer's direct action.
+  - issue-fix-workflow produces a branch, commits, and test results; it
+    opens a PR only as a draft, through `gh pr create --web --draft`, when
+    `--draft-pr` was passed and the maintainer confirms, and runs the
+    adversarial review first.
   - issue-backlog-stats and issue-reassess-stats are strictly read-only;
     no tracker state is mutated.
   - All family skills validate under skill-and-tool-validate with no errors.
@@ -58,6 +61,16 @@ and a consistent propose-before-act discipline.
 
 ## Where it lives
 
+Every skill ships in the `magpie-issue` plugin under
+`plugins/magpie-issue/skills/<alias>/` (`triage`, `reassess`,
+`reassess-stats`, `reproducer`, `fix-workflow`, `stale-sweep`,
+`backlog-stats`, `deduplicate`), and `skills/issue-<alias>` links to it.
+Since #1400 each `SKILL.md` keeps its gates, hard rules and safety rules
+inline and moves golden-rule elaboration, backend tables and reference
+material into siblings such as `golden-rule-details.md`, `link-form.md`,
+`clickable-references.md`, and `security-screening.md`; the behaviour is
+unchanged.
+
 - Skill: `issue-triage` — sweeps the configured candidate pool, classifies
   each issue against the project's disposition criteria (BUG /
   FEATURE-REQUEST / NEEDS-INFO / DUPLICATE / INVALID / ALREADY-FIXED),
@@ -86,8 +99,11 @@ and a consistent propose-before-act discipline.
 - Skill: `issue-fix-workflow` — drafts a fix for a triaged confirmed issue:
   failing regression test, smallest production change, targeted test run,
   commit message, and PR-description template. Hands back a branch and
-  commit summary; does not push or open a PR without the maintainer's
-  explicit direction. Ships `mode: Drafting` + `experimental`.
+  commit summary. An optional Step 9 opens a draft PR only when
+  `--draft-pr` was passed and the maintainer confirms after the hand-back
+  (`draft-pr-procedure.md`), after the shared pre-PR adversarial review in
+  its sibling `pre-pr-adversarial-review.md`. Ships `mode: Drafting` +
+  `experimental`.
 
 - Skill: `issue-stale-sweep` — sweeps open issues for inactivity past
   configurable thresholds, classifies each as `REQUEST-UPDATE` (activity
@@ -112,7 +128,8 @@ and a consistent propose-before-act discipline.
   mode boundary with `pr-management-*` and `security-issue-*`, and the
   adopter-config scaffold.
 
-- Adopter config (in `projects/_template/`): `project.md`,
+- Adopter config (templates in `plugins/magpie-setup/templates/`, which
+  `projects/_template/` links to): `project.md`,
   `issue-tracker-config.md`, `scope-labels.md`, `release-trains.md`,
   `canned-responses.md`, `runtime-invocation.md`,
   `reassess-pool-defaults.md`, `reproducer-conventions.md`,
@@ -131,10 +148,17 @@ and a consistent propose-before-act discipline.
   cross-link comment, and a second explicit confirmation before any issue
   is closed. Closing is never implied by the first confirmation.
 
-- **Draft, never push.** `issue-fix-workflow` produces a local branch with
-  commits and test results. The human maintainer reviews, then pushes and
-  opens the PR via `gh pr create --web`. The skill never executes a push
-  or a `gh pr create` autonomously.
+- **Draft, never on autopilot.** `issue-fix-workflow` produces a local
+  branch with commits and test results, and the hand-back artefact is its
+  terminal output by default.
+  With `--draft-pr` and an explicit confirmation after the hand-back, Step 9
+  shows the proposed title, body and diff, runs the configured
+  [adversarial reviewers](adversarial-review.md) over the change, and opens
+  a **draft** PR from the user's fork with `gh pr create --web --draft`, so
+  the maintainer submits it in the browser.
+  It never opens a non-draft PR, never pushes to a contributor's fork, never
+  posts to `<issue-tracker>`, self-assigns, or transitions workflow state,
+  and never merges.
 
 - **Evidence-only for reproducer.** `issue-reproducer` extracts and runs
   code; it never posts its verdict to the tracker. The reproduction
@@ -178,8 +202,10 @@ and a consistent propose-before-act discipline.
 2. `issue-stale-sweep` and `issue-deduplicate` require a second explicit
    confirmation before any issue is closed; a single confirmation posts
    the notice or cross-link only.
-3. `issue-fix-workflow` hands back a branch + commit summary; the PR is
-   opened by the maintainer (`gh pr create --web`), never by the skill.
+3. `issue-fix-workflow` hands back a branch + commit summary; a PR is
+   opened only with `--draft-pr` and a confirmation, only as a draft through
+   `gh pr create --web --draft`, and only after the pre-PR adversarial
+   review block.
 4. `issue-backlog-stats` and `issue-reassess-stats` produce a rendered
    report without mutating any tracker state.
 5. All family skills pass `skill-and-tool-validate` with no errors.
@@ -197,6 +223,10 @@ Every skill in the family ships a behavioural eval suite under
 `tools/skill-evals/evals/<skill>/`. Run `--cli` mode outside any sandbox that
 denies the model CLI its credentials; an unauthenticated CLI now errors rather
 than reporting a vacuous pass (see `meta-and-quality-tooling.md`).
+#1434 fixed eleven issue-family cases that failed correct answers (ambiguous
+output specs, fixtures that did not show what the expected answer claimed,
+and keyword graders now replaced by judge checks); no safety check was
+weakened.
 
 ## Known gaps
 
diff --git a/tools/spec-loop/specs/maintainer-education.md b/tools/spec-loop/specs/maintainer-education.md
index 03f6ce19d..794768fe0 100644
--- a/tools/spec-loop/specs/maintainer-education.md
+++ b/tools/spec-loop/specs/maintainer-education.md
@@ -3,7 +3,7 @@
 
 ---
 title: Maintainer-education stream
-status: proposed
+status: experimental
 kind: docs
 mode: infra
 source: >
@@ -11,17 +11,19 @@ source: >
   different craft; MISSION.md § Initial Goals ("Ship the
   maintainer-education stream alongside v1"); PRINCIPLES.md §19
   (maintainer education ships with the platform, release-blocking).
-  Referenced but not yet delivered by docs/rfcs/RFC-AI-0004.md
-  (§ "the maintainer-education stream").
+  Referenced by docs/rfcs/RFC-AI-0004.md (§ "the maintainer-education
+  stream"), which still points at MISSION.md. Implemented by
+  docs/education/, docs/education/training/, and ai-tutors/.
 acceptance:
   - A docs/education/ landing page exists and is linked from docs/index.md.
   - The landing page presents the material as an ordered learning
     progression: what agents are -> working with agents (conversational)
-    -> choosing models -> writing skills -> eval-driven development ->
-    agentic / autonomous work -> English as a programming language ->
-    contributing to the framework. Writing and testing a skill precede
-    agentic work, so autonomy is taught only after the reader has built
-    and evaluated a skill.
+    -> choosing models -> your first skill -> writing safe skills ->
+    debugging a skill -> writing portable skills -> eval-driven
+    development -> agentic / autonomous work -> English as a programming
+    language -> contributing to the framework. Writing and testing a skill
+    precede agentic work, so autonomy is taught only after the reader has
+    built and evaluated a skill.
   - Each progression stage exists as a page. The skill-writing steps keep
     the pattern catalogue as a supporting reference and the hands-on lab
     as practice; eval-driven development is a numbered stage on the main
@@ -51,9 +53,9 @@ that shift with worked, copy-pasteable material.
 
 ## Where it lives
 
-The stream lives at `docs/education/` and resolves the back-reference in
-`docs/rfcs/RFC-AI-0004.md`, which points readers at MISSION "for the
-maintainer-education stream". The material is organised as an **ordered
+The stream lives at `docs/education/`. It is the intended target of the
+back-reference in `docs/rfcs/RFC-AI-0004.md`, which still points readers
+at MISSION "for the maintainer-education stream". The material is organised as an **ordered
 learning progression**, so a maintainer with no agentic background can read
 it front to back, each page assuming only the ones before it:
 
@@ -83,31 +85,44 @@ it front to back, each page assuming only the ones before it:
   - `docs/education/tutorials.md` — the hands-on lab (renamed from
     `workshops.md`): build a small skill, give it an eval suite, and run
     it, self-paced or run for a group.
-- `docs/education/eval-driven-development.md` — **step 5.** How to think
+- `docs/education/writing-safe-skills.md` — **step 5.** Authoring patterns
+  that hold the data-not-instructions and sandbox principles in every skill.
+- `docs/education/debugging-skills.md` — **step 6.** Reading the audit log,
+  reproducing a failure with the eval harness, and isolating prompt, tool,
+  and model problems.
+- `docs/education/portable-skills.md` — **step 7.** Writing skills that work
+  for any project and any model, using placeholders and capability floors.
+- `docs/education/eval-driven-development.md` — **step 8.** How to think
   about correctness when "correct" is a distribution, with worked examples
   drawn from real Magpie skills and wired to a shared eval methodology
   (MISSION § Initial Goals) rather than reinvented per page. A numbered
   stage on the main path: a skill is not finished without its eval suite,
   and agentic work depends on that evidence.
-- `docs/education/agentic-work.md` — **step 6.** Agentic and autonomous
+- `docs/education/agentic-work.md` — **step 9.** Agentic and autonomous
   work: the supervision spectrum and the guardrails (sandbox,
   propose-confirm-act, data-not-instructions) that make unattended runs
   safe. Placed after skill-writing and evals, because autonomy is what a
   written-and-tested skill unlocks.
-- `docs/education/english-as-code.md` — **step 7.** English as a
+- `docs/education/english-as-code.md` — **step 10.** English as a
   programming language: the mental shift that the words in a prompt or
   skill *are* the program — precision, ambiguity as a bug class, and
   reviewing / versioning / testing prose the way you would code.
-- `docs/education/contributing.md` — **step 8.** How to contribute to the
+- `docs/education/contributing.md` — **step 11.** How to contribute to the
   framework: turning what the reader has learned into a merged change,
   through the framework's contribution process.
-- `docs/education/apache-training/` — the stream repackaged as a
-  reusable, LMS-neutral Apache Training module: per-lesson **learning
-  objectives**, hands-on **exercises**, and **self-check** questions,
-  plus a module index mapping each lesson back to the source page above.
-  So any project — ASF or not — can *teach* the material, not just read
-  it. Phase 2: lands after the pages above, and is shaped to Apache
-  Training conventions so it can be contributed upstream there.
+- `docs/education/training/` — the stream repackaged as a reusable,
+  LMS-neutral Apache Training module (the spec earlier named this
+  directory `apache-training/`): `README.md` (module map back to the
+  source pages), one `lesson-NN-*.md` per progression step (01 to 11, each
+  with learning objectives, exercises, and self-check questions),
+  `lesson-lab-tutorials.md` for the hands-on lab, `instructor-guide.md`,
+  and `upstream-contribution.md`, the process document for handing the
+  module to Apache Training.
+- `ai-tutors/` (repository root) — one tutor prompt per lesson
+  (`lesson-01-…` to `lesson-11-…`) that turns a chat model into an
+  interactive tutor for that lesson, plus `inject-knowledge-base.py` and its
+  test. The landing page and the training README link it; every lesson
+  stands on its own without a model.
 
 ## Behaviour & contract
 
@@ -148,12 +163,13 @@ it front to back, each page assuming only the ones before it:
 ## Acceptance criteria
 
 1. `docs/education/README.md` exists, is linked from `docs/index.md`, and
-   presents the material as the ordered progression (steps 1–8).
+   presents the material as the ordered progression (steps 1–11).
 2. Each progression stage exists as a page, in order: `what-agents-are.md`,
    `working-with-agents.md`, `choosing-models.md`, `your-first-skill.md`,
+   `writing-safe-skills.md`, `debugging-skills.md`, `portable-skills.md`,
    `eval-driven-development.md`, `agentic-work.md`, `english-as-code.md`,
-   and `contributing.md`. Skill-writing (step 4) and eval-driven
-   development (step 5) precede agentic work (step 6).
+   and `contributing.md`. Skill-writing (steps 4 to 7) and eval-driven
+   development (step 8) precede agentic work (step 9).
 3. The skill-writing steps keep their supporting references
    (`pattern-catalogue.md` and the hands-on lab `tutorials.md`, renamed
    from `workshops.md`; no `workshops.md` remains).
@@ -162,7 +178,7 @@ it front to back, each page assuming only the ones before it:
 5. Pages carry the SPDX header, use placeholders (no concrete adopter
    name in teaching text), and pass markdownlint / link checks.
 6. The RFC-AI-0004 back-reference resolves to the landing page.
-7. The Apache Training module (`docs/education/apache-training/`) exists
+7. The Apache Training module (`docs/education/training/`) exists
    with per-lesson learning objectives, exercises, and self-checks, and
    is shaped for upstream contribution to Apache Training.
 
@@ -179,6 +195,12 @@ test -f docs/education/working-with-agents.md
 test -f docs/education/choosing-models.md
 test -f docs/education/agentic-work.md
 test -f docs/education/your-first-skill.md
+test -f docs/education/writing-safe-skills.md
+test -f docs/education/debugging-skills.md
+test -f docs/education/portable-skills.md
+test -f docs/education/training/README.md
+test -f docs/education/training/instructor-guide.md
+test -f ai-tutors/README.md
 test -f docs/education/pattern-catalogue.md
 test -f docs/education/eval-driven-development.md
 test -f docs/education/english-as-code.md
@@ -192,13 +214,15 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
 
 ## Known gaps
 
-- **Progression restructure is the current gap.** The MISSION-named pages
-  (pattern catalogue, "your first skill", eval-driven development, the
-  hands-on lab) have shipped; the open work is re-sequencing them into the
-  ordered progression and adding the four new conceptual stages
-  (`what-agents-are`, `working-with-agents`, `choosing-models`,
-  `agentic-work`) plus `english-as-code` and `contributing`. Tracked in
-  IMPLEMENTATION_PLAN.md.
+- **Progression restructure has shipped.** The landing page's table runs
+  the eleven stages above in order, with the pattern catalogue and
+  `tutorials.md` as supporting references, and no `workshops.md` remains.
+  The earlier eight-step plan grew three skill-writing stages
+  (safe, debugging, portable) on the way.
+- **The RFC-AI-0004 back-reference still points at MISSION.md.** Its
+  maintainer-education sentence links `MISSION.md`, not
+  `docs/education/README.md`, so acceptance criterion 6 is open. The fix
+  is an RFC edit, which this loop does not make.
 - **Tutorial cadence undefined.** MISSION commits to "first scheduled
   workshops" but the schedule and hosting belong to the PMC once the
   material lands; `tutorials.md` ships the format, not the calendar.
@@ -206,11 +230,8 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   can land its worked examples immediately, but the link to the
   framework's shared contributor-sentiment methodology firms up only
   once that methodology is defined.
-- **Apache Training module is a phase-2 epic.** The
-  `docs/education/apache-training/` packaging depends on the source pages
-  existing first, and its final shape depends on coordination with the
-  Apache Training project for upstream contribution. It is not a single
-  deliverable: it decomposes into many work items (one per lesson module,
-  per-lesson exercises, an instructor guide, and the upstream hand-off),
-  tracked as an umbrella entry in IMPLEMENTATION_PLAN.md until it reaches
-  the top of the queue and is split.
+- **The Apache Training module exists; the upstream hand-off has not
+  happened.** `docs/education/training/` carries all eleven lessons, the
+  lab lesson, the instructor guide, and `upstream-contribution.md`. Its
+  final shape still depends on coordination with the Apache Training
+  project, which is outside the repository.
diff --git a/tools/spec-loop/specs/marketplace-distribution.md b/tools/spec-loop/specs/marketplace-distribution.md
index 5864dfc68..1d411eb7d 100644
--- a/tools/spec-loop/specs/marketplace-distribution.md
+++ b/tools/spec-loop/specs/marketplace-distribution.md
@@ -69,10 +69,21 @@ that is a symlink yields no manifest at all, with no fallback. See
 `docs/setup/marketplace.md` (*Which manifest Codex reads*).
 
 Plus `plugins/magpie-<family>/` — ten per-family plugins, one per skill family,
-each a manifest and a `skills/` directory of single-hop symlinks into the
-shared `skills/<skill>` tree. Their manifest is Claude Code's
-`.claude-plugin/plugin.json`, but they are not Claude-Code-only: Codex installs
-them by falling through to that same file.
+each a manifest and a `skills/` directory holding that family's skills as real
+directories (`plugins/magpie-<family>/skills/<alias>/SKILL.md`); the flat
+`skills/<dir>` tree mirrors each one back with a single-hop symlink. Their
+manifest is Claude Code's `.claude-plugin/plugin.json`, but they are not
+Claude-Code-only: Codex installs them by falling through to that same file.
+
+`magpie-setup` also carries two non-skill payloads as real files inside its
+plugin root, because `setup config` installs them from the plugin on a
+marketplace install: the `setup_preflight` package at
+`plugins/magpie-setup/skills/setup/setup_preflight/` (#1409) and the project
+templates at `plugins/magpie-setup/templates/` (#1410). Both mirrors point
+inward — `tools/setup-preflight/src/setup_preflight` and `projects/_template`
+are symlinks into the plugin — since `magpie-setup` is listed by the Codex and
+Copilot catalogs, and Agent Plugins 1.0 §4.1 forbids a link out of such a
+plugin root.
 
 `tools/dev/check-family-plugins.py` is both the generator (`--fix`) and the
 CI gate — the prek hook runs it in `--fix` mode, so the gate corrects drift
@@ -89,8 +100,9 @@ adopter-facing page.
   `repository`, and `license`.
 
 - **Between releases the version carries a moving dev suffix, and it is
-  load-bearing.** The manifests read `0.2.0.dev<YYYYMMDDHHMM>`, never a bare
-  `0.2.0` — a bare version would advertise a release that does not exist. The
+  load-bearing.** The manifests read `0.9.0.dev<YYYYMMDDHHMM>` (the base moved
+  from `0.2.0` to `0.9.0` in #1389), never a bare `0.9.0` — a bare version
+  would advertise a release that does not exist. The
   marketplace is served straight from the `main` branch, so adopters *do*
   install dev versions; that is the normal case. `claude plugin update`
   compares **version strings, not commit SHAs**, so while the suffix stays
@@ -101,6 +113,16 @@ adopter-facing page.
   **UTC** so bumps from contributors in different timezones sort in the order
   they were made.
 
+- **A plugin update replaces plugin files and nothing else.** Neither
+  `claude plugin update` nor auto-update runs anything in the adopter's
+  repo; each skill's pre-flight self-checks against the last reconciliation
+  on its first run after an upgrade, and `/magpie-setup:setup reconcile`
+  forces the full pass (`docs/setup/marketplace.md`, #1392). On machines
+  using the isolated setup, the same pre-flight also proposes
+  `setup-isolated-setup-update` when the upgrade moved the secure-setup
+  fingerprint (see [`adoption-and-setup.md`](adoption-and-setup.md),
+  criterion 27).
+
 - **Bump when the work needs to reach installed copies**, not per PR — a
   per-PR bump puts every contributor in conflict with every other over one
   line. Before pointing anyone at `claude plugin update`, before announcing a
@@ -124,8 +146,15 @@ adopter-facing page.
   (#1368) — declared in `SUBSTRATE_PLUGINS` in `check-family-plugins.py`.
   Each inherits the shared manifest metadata, declares no `skills`, exposes
   its `tools/<name>` through a symlink whose entry point must resolve, and
-  declares hook wiring only where it has a hook (agent-guard's
-  `PreToolUse`). They exist to run the tool from the installed plugin tree:
+  declares hook wiring only where it has a hook: agent-guard's `PreToolUse`,
+  and vetted-ops' `SessionStart` hook (`tools/vetted-ops/hooks/link-stable-path.sh`,
+  #1406), which points the fixed path `~/.claude/magpie/vetted-ops` at the
+  installed version each session so permission rules never name a versioned
+  plugin-cache glob. `magpie-adversarial-review` additionally publishes a
+  `commands/adversarial-review.md` link to the command file generated into
+  `tools/adversarial-review/commands/`, which Claude Code exposes as
+  `/magpie-adversarial-review:adversarial-review` (#1371); that file too must
+  resolve. They exist to run the tool from the installed plugin tree:
   the code a sandbox exclusion or a hook executes must sit where the agent
   calling it cannot rewrite it. A tool shipped this way must resolve
   outside the workspace, so it declares no workspace-only `dev` dependency
@@ -160,7 +189,10 @@ adopter-facing page.
 1. `check-family-plugins.py` passes: version parity across every ecosystem
    manifest, AP1 conformance for the root `plugin.json` (pinned `$schema`,
    name pattern, closed ten-field set), one well-formed plugin per declared
-   family, and symlink sets matching `family:` frontmatter exactly.
+   family, skill sets matching `family:` frontmatter exactly, every
+   substrate plugin's links and hook entry points resolving, and
+   `magpie-setup` carrying `setup_preflight` and the templates as real files
+   with their inward mirror links intact.
 2. `--fix` regenerates every manifest from `pyproject.toml` and is idempotent —
    a second run is a no-op.
 3. A version bump is a one-line edit to `pyproject.toml` plus a regeneration.
diff --git a/tools/spec-loop/specs/mentoring-mode.md b/tools/spec-loop/specs/mentoring-mode.md
index 8f900e6df..808885c1e 100644
--- a/tools/spec-loop/specs/mentoring-mode.md
+++ b/tools/spec-loop/specs/mentoring-mode.md
@@ -9,7 +9,7 @@ mode: Mentoring
 source: >
   MISSION.md § Technical scope (Mentoring) — "the highest-value
   project-side mode and the one off-the-shelf agent tooling skips".
-  docs/modes.md § Mentoring (experimental, 5 skills). Spec exists at
+  docs/modes.md § Mentoring (experimental, 7 skills). Spec exists at
   docs/mentoring/spec.md ahead of any skill code. MISSION.md names
   onboarding latency as one of the two loudest ecosystem complaints;
   authoring newcomer-ready good first issues targets it directly.
@@ -50,7 +50,20 @@ a project can offer a first-time contributor.
 ## Where it lives
 
 - Spec: `docs/mentoring/README.md`, `docs/mentoring/spec.md`.
-- Adopter config scaffold: `projects/_template/mentoring-config.md`.
+- Skills ship across three plugins, each reachable through a
+  `skills/<dir>` symlink: `plugins/magpie-mentoring/skills/`
+  (`welcome` as `mentoring-welcome`, `good-first-issue-author`,
+  `good-first-issue-sweep`, `newcomer-issue-explainer`),
+  `plugins/magpie-contributor-growth/skills/`
+  (`contributor-to-committer`, `onboarding-concierge`), and
+  `plugins/magpie-pr-management/skills/mentor/`
+  (`pr-management-mentor`).
+- Adopter config scaffolds in `plugins/magpie-setup/templates/`
+  (`projects/_template` is a symlink to it): `mentoring-config.md`
+  (`pr-management-mentor`; its `out_of_scope_topics` also gates
+  `mentoring-welcome`), `mentoring-welcome-config.md`,
+  `good-first-issue-config.md`, `onboarding-concierge-config.md`,
+  `newcomer-issue-explainer-config.md`, and `committer-readiness.md`.
 - Skill: `pr-management-mentor` — drafts a teaching-register comment on
   a single GitHub issue or PR thread; waits for explicit maintainer
   confirmation before posting. Ships `mode: Mentoring` + `experimental`.
@@ -75,7 +88,10 @@ a project can offer a first-time contributor.
   maps a contributor's GitHub activity against the adopter's PMC-declared
   committer or PMC thresholds; surfaces a traffic-light brief (Not yet /
   Approaching / Ready to nominate) plus the specific evidence gaps that
-  remain. Ships `mode: Mentoring` + `experimental`, with an eval suite
+  remain. Counts come from `tools/contributor-metrics`, discounted for
+  automated and low-signal work, and community signals are collected in
+  Step 3 (see [contributor-growth.md](contributor-growth.md)).
+  Ships `mode: Mentoring` + `experimental`, with an eval suite
   under `tools/skill-evals/evals/contributor-to-committer/`.
 - Skill: `good-first-issue-sweep` — sweeps the open issue backlog for
   existing issues that could be labelled as good first issues. Scores each
@@ -85,6 +101,22 @@ a project can offer a first-time contributor.
   confirmation; never edits issue bodies. Ships `mode: Mentoring` +
   `experimental`, with an eval suite under
   `tools/skill-evals/evals/good-first-issue-sweep/`.
+- Skill: `onboarding-concierge` — answers a newcomer's "how do I
+  contribute here" question by grounding the reply in
+  `CONTRIBUTING.md` and the project's own docs. Classifies the question
+  (setup / workflow / first-issue / out-of-scope), retrieves the
+  relevant excerpt, and drafts a concise answer in the teaching
+  register; design, security, deprecation, and architectural-taste
+  questions are handed to a human maintainer. Produces draft text only.
+  Ships `mode: Mentoring` + `experimental`, with an eval suite under
+  `tools/skill-evals/evals/onboarding-concierge/`.
+- Skill: `newcomer-issue-explainer` — given an open good first issue,
+  explains it in beginner terms and sketches an approach (files to read
+  first, what "done" looks like, where to ask) without writing any code.
+  An issue-assessment gate declines closed, security-sensitive, or
+  scope-unclear issues. Nothing is posted without maintainer
+  confirmation. Ships `mode: Mentoring` + `experimental`, with an eval
+  suite under `tools/skill-evals/evals/newcomer-issue-explainer/`.
 
 ## Behaviour & contract
 
@@ -126,22 +158,32 @@ test -f .agents/skills/magpie-good-first-issue-author/SKILL.md
 test -f .agents/skills/magpie-mentoring-welcome/SKILL.md
 test -f .agents/skills/magpie-contributor-to-committer/SKILL.md
 test -f .agents/skills/magpie-good-first-issue-sweep/SKILL.md
+test -f .agents/skills/magpie-onboarding-concierge/SKILL.md
+test -f .agents/skills/magpie-newcomer-issue-explainer/SKILL.md
 uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-validate
 uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/good-first-issue-author/
 uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/mentoring-welcome/
 uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/good-first-issue-sweep/
+uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/onboarding-concierge/
+uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/newcomer-issue-explainer/
 ```
 
 ## Known gaps
 
 - **The family now covers the newcomer journey end to end.**
-  All five skills ship: `pr-management-mentor`, `good-first-issue-author`,
+  All seven skills ship: `pr-management-mentor`, `good-first-issue-author`,
   `mentoring-welcome` (first-contribution welcome / orientation),
+  `onboarding-concierge` (how-to-contribute answers),
+  `newcomer-issue-explainer` (beginner explanation of a filed issue),
   `contributor-to-committer` (readiness path tracker), and
   `good-first-issue-sweep` (backlog curation / labelling). The on-ramp
   supply chain is complete from both the authoring side
   (`good-first-issue-author`) and the curation side (`good-first-issue-sweep`).
-- **`experimental` — no adopter pilot has run.** All five shipped skills
+- **Mode and plugin do not line up.** The seven `mode: Mentoring` skills
+  ship in three plugins (`magpie-mentoring`, `magpie-contributor-growth`,
+  `magpie-pr-management`); see
+  [contributor-growth.md](contributor-growth.md) § Known gaps.
+- **`experimental` — no adopter pilot has run.** All seven shipped skills
   may change shape as adopter pilots and contributor-sentiment evaluations
   land.
 - **`good-first-issue-author` and `good-first-issue-sweep` shipped
diff --git a/tools/spec-loop/specs/meta-and-quality-tooling.md b/tools/spec-loop/specs/meta-and-quality-tooling.md
index eaa83f9fb..e48099a8f 100644
--- a/tools/spec-loop/specs/meta-and-quality-tooling.md
+++ b/tools/spec-loop/specs/meta-and-quality-tooling.md
@@ -54,6 +54,12 @@ trustworthy as it grows.
   batched rubric is re-asked once, and only silence that survives the retry
   is reported; a verdict the grader actually gave is never re-asked, so a NO
   cannot become a YES by asking twice (#1341).
+  The grader rubric (single-field and batched) counts a candidate that
+  reaches the expected conclusion as a match even when it adds correct
+  detail, omits secondary detail, names the deciding rule differently, or
+  explains the decision without restating it, because the decision itself
+  is compared exactly in its own structured fields; it answers no only on
+  a different or contradictory conclusion (#1398).
 - `tools/sandbox-lint/` — lints the sandbox/permissions configuration.
 - `tools/symlink-lint/` — lints the framework's self-adoption skill
   symlinks: rejects cyclic symlinks, misdirected relays (canonical/
@@ -87,7 +93,11 @@ trustworthy as it grows.
   in live mode (via `gh api graphql`) or replay mode (offline, from a
   cached snapshot) against a real tracker. Measures skip-rate before and
   after any rule change, closing the tune-then-verify loop so rule edits
-  are backed by evidence. Capability: `substrate:analytics`.
+  are backed by evidence. A last comment that starts with the framework
+  skill marker or with the status-rollup marker line
+  (`<!-- <name> status rollup v<N>`) counts as skill activity, not human
+  activity, so a fresh rollup append no longer dispatches the tracker
+  (#1444). Capability: `substrate:analytics`.
 - `tools/spec-validator/` — validates spec-loop spec frontmatter
   (required keys, valid `status`/`kind`/`mode` values, body-section
   presence, `Known gaps` section required in functional specs,
@@ -102,10 +112,21 @@ trustworthy as it grows.
   separate rewrite pass, `rewrite.md` — rewrite prose paragraph by
   paragraph with the maintainer writing every word), `list-skills` (live,
   generated index of every skill, grouped by family).
-
+  The utility skills live at `plugins/magpie-utilities/skills/<alias>/`,
+  reached through `skills/<name>` symlinks.
 - `tools/skill-token-count/` measures full local skill files with pinned
-  `tiktoken` / `cl100k_base`, generates the mode-economics table, and checks
-  drift through prek and a dedicated path-filtered CI workflow.
+  `tiktoken` / `cl100k_base` and stamps each count into that skill's own
+  frontmatter as a generated `measured_tokens:` line (#1394).
+  `--write` restamps the skills whose count changed, `--check` (the default,
+  run by prek and a dedicated path-filtered CI workflow) fails on a missing
+  or stale stamp, and `--table` prints the per-skill table to stdout.
+  The table in `docs/mode-economics.md` is no longer committed: the website
+  build renders it from the stamps.
+  `skill-and-tool-validator` rejects a `measured_tokens:` value that is not
+  a positive integer; whether the value is current is this tool's check.
+- `tools/dev/generate-labeler-config.py` generates `.github/labeler.yml`
+  from the `**Capability:**` line of every `tools/<name>/README.md`, kept in
+  sync by a prek hook; `.github/workflows/labeler.yml` applies it (#1382).
 
 ## Behaviour & contract
 
@@ -171,17 +192,36 @@ trustworthy as it grows.
   only decides whether it fires. A green PR check is therefore not a
   whole-repo result, which is why `prek run --all-files` before pushing
   is a required pre-flight (#1317).
+- **Every required check runs on stacked PRs.** The `zizmor` workflow's
+  `pull_request` trigger carries no `branches:` filter, because that filter
+  matches the PR's base branch and a stacked PR based on another PR's branch
+  would wait forever on the required `zizmor` check; its `push` trigger stays
+  limited to `main` (#1440).
+- **Tool-capability labels are pre-applied, once.** The labeler workflow runs
+  hourly (and on `workflow_dispatch`) in the repository's own context rather
+  than on `pull_request_target`, checks out nothing from a PR, and labels only
+  the non-bot PRs opened since the previous successful run started (24 hours
+  back on the first run). Each PR is labelled once, so a label a maintainer
+  removes stays removed. Eval fixtures and spec-loop specs do not count as
+  touching their tool, and a PR that would gain more than eight labels gets
+  none. The labels are a starting point to correct, not the answer (#1382).
 - **Eval trust roles stay separate.** Mock tool output in `report.md` enters the user turn as untrusted data.
   Repository policy read from a trusted revision may enter through a case-level `trusted-context.md`, which the runner appends only to the system prompt.
 
-- **Token measurement provenance.** Counts include UTF-8 file content with
-  LF-normalized line endings. A content manifest hash identifies inputs without
-  depending on Git history or commit time. A descriptive UTC date changes only
-  on regeneration after drift; checks preserve it. Vocabulary preparation is
-  explicit and checksum-verified; missing or corrupt caches block measurement
-  before a network request. Skill edits,
-  additions, removals, and renames invalidate the table. These file counts
-  are distinct from estimated session costs and runtime percentiles.
+- **Token measurement provenance.** Counts cover the full UTF-8 file with
+  LF-normalized line endings, frontmatter and comments included, excluding the
+  `measured_tokens:` line itself so writing the stamp never changes the count.
+  The stamp sits immediately after `license:` and `surface_hash:` immediately
+  before it, so neither stamper reorders the other's line.
+  A per-skill stamp conflicts only when two PRs edit the same skill; the
+  earlier committed table, with its manifest hash and measurement date, made
+  almost any two skill PRs conflict and was retired (#1394).
+  Vocabulary preparation is explicit and checksum-verified; missing or
+  corrupt caches block measurement before a network request.
+  A `tiktoken` bump that changes tokenization fails `--check` on every skill
+  until the skills are restamped in the same PR.
+  These file counts are distinct from estimated session costs and runtime
+  percentiles.
 - **Runtime evidence is scoped.** An opt-in replay benchmark captures actual
   CLI-reported input, cache, and output usage for synthetic full-entrypoint
   decision-to-draft/report tasks. It records prompts' source hashes, model/CLI
@@ -230,6 +270,8 @@ trustworthy as it grows.
     without ever re-asking a verdict the grader gave.
 11. The validator fails a skill whose `name:` does not match the
     directory holding its `SKILL.md`.
+12. Every `SKILL.md` carries a current `measured_tokens:` stamp;
+    `skill-token-count --check` fails on a missing or stale one.
 
 ## Validation
 
@@ -242,7 +284,7 @@ uv run --project tools/spec-inventory --group dev pytest tools/spec-inventory/te
 
 ## Known gaps
 
-- **Eval coverage is complete.** All 63 shipped skills have a matching
+- **Eval coverage is complete.** All 78 shipped skills have a matching
   suite in `tools/skill-evals/evals/`; the soft eval-coverage check in
   `skill-and-tool-validator` (check #8) warns when a newly added skill has
   no suite, keeping coverage complete going forward.
@@ -275,3 +317,9 @@ uv run --project tools/spec-inventory --group dev pytest tools/spec-inventory/te
 - **Vendor-neutrality measurement is available but unscheduled.** `tools/vendor-neutrality-score/`
   ships and can be run ad hoc, but is not yet wired into CI or the
   build loop. Score drift is not automatically surfaced.
+- **The 500-line cap is advisory and widely exceeded.** `skill-line-limit`
+  is a SOFT check. After the family trims (#1390 pr-management, #1400
+  issue, #1435 to #1438 security), 23 `SKILL.md` files are still over 500
+  lines, led by `release-prepare` (1,208), `release-verify-rc` (968) and
+  `release-rc-cut` (932); 8 of the 10 release-management skills and 10
+  security skills are among them.
diff --git a/tools/spec-loop/specs/organization-adapters.md b/tools/spec-loop/specs/organization-adapters.md
index ad64a422a..9e42c4ef1 100644
--- a/tools/spec-loop/specs/organization-adapters.md
+++ b/tools/spec-loop/specs/organization-adapters.md
@@ -54,6 +54,13 @@ identical "ASF default" values in its own `project.md`.
   `projects/non-asf-example/`.
 - `organizations/_template/` — authoring skeleton.
 - Resolution contract: `AGENTS.md` §"Configuration resolution order".
+- The project-manifest template that names the organization,
+  `plugins/magpie-setup/templates/project.md` (`projects/_template/` links to
+  that directory since #1410), marks the org-level rows (CVE authority,
+  project metadata, …) as inherited from `organizations/<org>/organization.md`.
+- The framework's own published configuration,
+  `.apache-magpie-overrides/project.md`, declares `organization: ASF` and so
+  exercises the ASF profile on this repository (#1412).
 - Path exempted from placeholder / asf-coupling lint via
   `ALLOWLIST_PATHS += "organizations/"` in `skill-and-tool-validator`.
 
@@ -80,8 +87,9 @@ identical "ASF default" values in its own `project.md`.
 
 ## Out of scope
 
-- Removing the ASF default *values* from `projects/_template/project.md`
-  (the reflow to actually inherit) — a follow-up change.
+- Removing the ASF default *values* from the project-manifest template
+  (now `plugins/magpie-setup/templates/project.md`; the reflow to actually
+  inherit) — a follow-up change.
 - Making the `asf:false` skill families fully agnostic (moving residual
   PMC/ICLA/incubator vocabulary behind placeholders) — a follow-up.
 - Replacing the per-family `asf: true/false` metadata with an optional
diff --git a/tools/spec-loop/specs/pairing-mode.md b/tools/spec-loop/specs/pairing-mode.md
index 35706aaf8..83d925c4e 100644
--- a/tools/spec-loop/specs/pairing-mode.md
+++ b/tools/spec-loop/specs/pairing-mode.md
@@ -9,7 +9,9 @@ mode: Pairing
 source: >
   MISSION.md § Technical scope (Pairing) and § Initial Goals ("Ship at
   least one Pairing skill family in v1"). docs/modes.md § Pairing
-  (experimental, 2 skills).
+  (experimental, 3 skills). Implemented in plugins/magpie-pairing/skills/
+  (self-review, multi-agent-review) and
+  plugins/magpie-pr-management/skills/pre-first-pr-check/.
 acceptance:
   - At least one Agentic Pairing skill exists and validates (v1 goal).
   - Agentic Pairing skills run in the developer's OWN dev loop and make no state
@@ -32,15 +34,32 @@ protecting the ASF contribution path (contributor → committer → PMC).
 
 ## Where it lives
 
-- Skill: `pairing-self-review` — structured pre-flight self-review of
+- Skill: `pairing-self-review` (`plugins/magpie-pairing/skills/self-review/`)
+  — structured pre-flight self-review of
   local changes before opening a PR. Read-only; returns a structured
   report with no external writes. Ships `mode: Pairing` + `experimental`.
-- Skill: `pairing-multi-agent-review` — fans the diff through three
+- Skill: `pairing-multi-agent-review`
+  (`plugins/magpie-pairing/skills/multi-agent-review/`) — fans the diff through three
   independent, axis-focused sub-agents (correctness, security,
   conventions); merges findings with deduplication and severity ranking
   into a report in the same format as `pairing-self-review`. Each pass
   is isolated so findings from one axis cannot suppress or bias the
   others. Read-only; no state change. Ships `mode: Pairing` + `experimental`.
+- Skill: `pre-first-pr-check`
+  (`plugins/magpie-pr-management/skills/pre-first-pr-check/`, linked from
+  `skills/pre-first-pr-check`) — newcomer-focused checklist on a local
+  branch before the first PR: CONTRIBUTING conventions, SPDX headers on new
+  files, commit-message shape including the `Generated-by:` trailer, and the
+  placeholder convention.
+  Read-only; no PR and no external writes.
+  Ships `mode: Pairing` + `experimental`, but is packaged in the
+  `magpie-pr-management` plugin (`family: pr-management`), not in
+  `magpie-pairing`.
+- Related, not a Pairing skill: the `magpie-adversarial-review` plugin's
+  per-harness command (`/magpie-adversarial-review:adversarial-review` in
+  Claude Code) lets a developer ask other models for a read-only second
+  read of a branch, diff or PR in their own loop
+  ([adversarial review](adversarial-review.md)).
 
 ## Behaviour & contract
 
@@ -80,6 +99,10 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
 
 ## Known gaps
 
-- **`experimental` — no adopter pilot has run.** Both `pairing-self-review`
-  and `pairing-multi-agent-review` shipped; no contributor-sentiment
-  evaluation has run yet; shape may change.
+- **`experimental` — no adopter pilot has run.** `pairing-self-review`,
+  `pairing-multi-agent-review` and `pre-first-pr-check` shipped; no
+  contributor-sentiment evaluation has run yet; shape may change.
+- **The Pairing skills are split across two plugins.** An adopter who
+  installs only `magpie-pairing` does not get `pre-first-pr-check`, and the
+  validation command above, which greps for the `magpie-pairing-` prefix,
+  does not see it either.
diff --git a/tools/spec-loop/specs/pr-management-family.md b/tools/spec-loop/specs/pr-management-family.md
index c24ee64c3..e66b33f78 100644
--- a/tools/spec-loop/specs/pr-management-family.md
+++ b/tools/spec-loop/specs/pr-management-family.md
@@ -9,7 +9,9 @@ mode: Triage
 source: >
   MISSION.md § Technical scope (Triage: "proposes initial routing") and
   § Rationale ("review-cycle latency is one of the two named priorities").
-  Implemented in docs/pr-management/ and skills/pr-management-*/. Skills
+  Implemented in docs/pr-management/ and plugins/magpie-pr-management/skills/
+  (each linked from skills/<name>, e.g. skills/pr-management-triage ->
+  plugins/magpie-pr-management/skills/pr-triage). Skills
   originated as `breeze pr auto-triage` / `breeze pr stats` inside one ASF
   project's toolchain and were lifted into the framework to be reusable
   across any project with a contributor PR queue. mentor lives in the
@@ -55,19 +57,33 @@ is listed here for navigability since its domain is PR threads.
 
 ## Where it lives
 
-- Skill: `pr-management-triage` — first-pass sweep of the PR queue.
+Every skill ships in the `magpie-pr-management` plugin under
+`plugins/magpie-pr-management/skills/<alias>/`, and the repository name
+`skills/<name>` is a link to it.
+Since #1390 each `SKILL.md` keeps its gates, golden-rule headlines and
+step skeleton inline and moves sub-action detail into sibling files in the
+same directory; the behaviour is unchanged.
+
+- Skill: `pr-management-triage` (`pr-triage/`) — first-pass sweep of the PR
+  queue.
   Classifies each candidate against a project decision table and proposes
   a disposition; the maintainer confirms per PR or per group. State changes
   execute on confirmation only. Ships `mode: Triage` + `experimental`.
-  Detail files: `skills/pr-management-triage/`.
+  Detail files: `prerequisites.md`, `fetch-and-batch.md`,
+  `classify-and-act.md`, `actions.md`, `interaction-loop.md`,
+  `stale-sweeps.md`, `comment-templates.md`, `session-history.md`,
+  `contract-binding.md`, and `rationale.md`.
 - Skill: `pr-management-stats` — read-only summary tables of the open PR
   backlog, grouped by area label, age bucket, and triage state. No tracker
   state is mutated. Ships `mode: Triage` + `capability: capability:stats`
   + `experimental`. Backed by `tools/pr-management-stats/`.
-- Skill: `pr-management-code-review` — deep, line-aware code review one
-  PR at a time; applies project criteria and drafts an `APPROVE` /
-  `REQUEST_CHANGES` / `COMMENT` review with inline comments; posts on
-  maintainer confirmation. Ships `mode: Triage` + `experimental`.
+- Skill: `pr-management-code-review` (`code-review/`) — deep, line-aware
+  code review one PR at a time; applies project criteria and drafts an
+  `APPROVE` / `REQUEST_CHANGES` / `COMMENT` review with inline comments;
+  posts on maintainer confirmation. Ships `mode: Triage` + `experimental`.
+  Detail files include `prerequisites.md`, `selectors.md`, `review-flow.md`,
+  `review-loop.md`, `criteria.md`, `slop-detection.md`, `adversarial.md`,
+  and `posting.md`.
 - Skill: `pr-management-quick-merge` — read-only express-lane screener
   for trivial, low-risk PRs (docs, changelog, translations, tests) that
   pass every quality gate; surfaces ranked candidates with diff summaries
@@ -78,14 +94,22 @@ is listed here for navigability since its domain is PR threads.
   confirmation before posting. Ships `mode: Mentoring` + `experimental`.
   Listed here because its domain is PR/issue threads; documented in detail
   in [`docs/mentoring/README.md`](../../../docs/mentoring/README.md).
+- Companion skills in the same plugin, covered in other specs:
+  `pr-stale-sweep` (`mode: Triage`, draft-or-close inactivity sweep on
+  confirmation; [triage mode](triage-mode.md)),
+  `reviewer-routing` (`mode: Triage`; [reviewer routing](reviewer-routing.md)),
+  and `pre-first-pr-check` (`mode: Pairing`, read-only newcomer checklist on a
+  local branch; [pairing mode](pairing-mode.md)).
 - Family README: `docs/pr-management/README.md` — family overview, skill
   table, adopter-config scaffold.
 - Tool: `tools/pr-management-stats/` — deterministic Python backing for
   `pr-management-stats`; ships its own tests.
-- Adopter config (in `projects/_template/`): `project.md`,
+- Adopter config (templates in `plugins/magpie-setup/templates/`, which
+  `projects/_template/` links to): `project.md`,
   `pr-management-config.md`, `pr-management-triage-comment-templates.md`,
   `pr-management-triage-ci-check-map.md`, `pr-management-code-review-criteria.md`,
-  `pr-management-quick-merge-config.md`.
+  `pr-management-quick-merge-config.md`, and the optional
+  `adversarial-review.md` read by code review.
 
 ## Behaviour & contract
 
@@ -99,6 +123,27 @@ is listed here for navigability since its domain is PR threads.
   `[E]` and `[P]NN` preserve that position and denominator across skipped,
   pending, and pulled-out rows; a changed head advances the transition to
   `re-classify → propose <action>` after live state is refreshed.
+- **Triage markers from any triager count.** `pr-management-triage`
+  treats a PR as already triaged when a triage marker exists after the last
+  commit in either channel: a comment by any `OWNER`, `MEMBER`, or
+  `COLLABORATOR` carrying the `Pull Request quality criteria` link, or the
+  `pr-triage-fold` block in the PR body with a matching `head`, whoever wrote
+  it.
+  The fold block carries an optional `by=<login>` field naming the triager,
+  which the rows 3–4 reasons show; folds written before the field existed
+  are read without it.
+  Association alone does not start Sweep 1a's close clock: a comment-channel
+  marker by anyone other than the viewer counts toward a close only after
+  its author passes the live maintainer check, and a marker comment never
+  double-counts as maintainer activity.
+  Regression cases: `tools/skill-evals/evals/pr-management-triage/`
+  decision-table fixtures, including `case-22-fold-by-another-triager`.
+- **The fold timestamp is untrusted input to stats.** The
+  `pr-triage-fold` block lives in the PR body, which the author controls.
+  `tools/pr-management-stats/reference.py` (`fold_triaged_at`) treats an
+  unparsable or timezone-naive `triaged=` value as no fold event rather
+  than crashing the run, and tries every marker, so a malformed one above
+  the real block cannot hide it (`tests/test_fold_parsing.py`).
 - **Active-maintainer cooldown spans every feedback surface.**
   `pr-management-triage` steps back from a PR whose most recent feedback —
   a general comment, a review-thread comment, or a submitted top-level review
@@ -152,11 +197,32 @@ is listed here for navigability since its domain is PR threads.
   submitted, leaving the body edited down to a pointer as the only
   repair. The same rule covers `gh pr comment` and the
   `addPullRequestReview` mutation.
+- **Adversarial second read in code review.** `pr-management-code-review`
+  offers two paths at Step 5 of `review-flow.md`.
+  The tool path — `with-reviewers:codex,copilot`, or a resolved
+  `adversarial-review.md` whose `mode` is not `off` — has the agent run the
+  [adversarial-review](adversarial-review.md) tool over `--target pr:<N>`
+  from an empty temporary directory created once per session, because the
+  skill has no checkout of the PR's head and the maintainer's own checkout
+  must not be readable by other models.
+  Its findings fold into the Step 4 list, attributed per reviewer, as
+  untrusted data.
+  The slash path — `with-reviewer:<command>` or a *Review preferences*
+  entry — still proposes a command for the maintainer to type.
+  `no-adversarial` turns both off for the session.
+  On a private `<upstream>` the skill asks before the first tool run; exit
+  code 2 skips the tool path for the rest of the session; prefetched PRs get
+  Step 5 from the parent, since subagents have no shell.
+  The resolution order is in `prerequisites.md` §2 and pinned by the
+  `step-2-reviewer-resolution` eval suite.
 - **Config-driven, not skill-edited.** Project-specific values
   (committers team handle, area-label prefix, comment-template wording,
   CI-check → doc-URL map, review criteria, quick-merge path globs) all
   live in `<project-config>/` files; no skill body carries a project
   hardcode.
+  Review footers and the triage comment templates link the contributing
+  guide through `<upstream_contributing_docs_url>` from `project.md`, not a
+  fixed project's docs path (#1407).
 
 ## Out of scope
 
@@ -206,6 +272,7 @@ test -f .agents/skills/magpie-pr-management-code-review/SKILL.md
 test -f .agents/skills/magpie-pr-management-quick-merge/SKILL.md
 test -f .agents/skills/magpie-pr-management-mentor/SKILL.md
 test -f docs/pr-management/README.md
+uv run --all-packages --group dev pytest tools/pr-management-stats/tests
 uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-validate
 ```
 
@@ -226,11 +293,13 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   across transitive paths, empty intersections, partial metadata, environment
   markers, and adopter-specific remediation. The SOFT eval-coverage validator
   warning is cleared. Acceptance criteria 6 and 7 are met.
-- **Stale-PR handling is built into `pr-management-triage`.** Dedicated
-  stale sweeps (`stale-draft`, `inactive-open`, `stale-review-ping`) run
-  as Step 5 of the triage flow and can be invoked standalone via
-  `triage stale`. A separate `pr-management-stale-sweep` skill is
-  intentionally not planned; the triage skill already covers this surface.
+- **Stale-PR handling lives in two places.** Stale sweeps
+  (`stale-draft`, `inactive-open`, `stale-review-ping`) run as Step 5 of
+  the triage flow and can be invoked standalone via `triage stale`.
+  A standalone `pr-stale-sweep` skill has since shipped in the same plugin
+  (draft-or-close proposals on confirmation), so the earlier note that no
+  separate stale-sweep skill was planned is superseded; how the two divide
+  the surface is not written down in one place.
 - **`pr-management-mentor` is documented under Mentoring mode** and is
   listed in `docs/mentoring/README.md`. The PR management README
   cross-references it as a companion skill; adopters wanting PR-thread
diff --git a/tools/spec-loop/specs/privacy-llm-gate.md b/tools/spec-loop/specs/privacy-llm-gate.md
index b67663557..f43671aad 100644
--- a/tools/spec-loop/specs/privacy-llm-gate.md
+++ b/tools/spec-loop/specs/privacy-llm-gate.md
@@ -34,13 +34,31 @@ artefact for leakage before emission.
 
 ## Where it lives
 
-- `tools/privacy-llm/checker/` — the approved-LLM gate.
+- `tools/privacy-llm/checker/` — the approved-LLM gate
+  (`privacy-llm-check`; `--config` to name the config file,
+  `--reads-private-list` so the banner says a PMC-private list is in
+  play, `--quiet` to print nothing on approval).
+- `tools/privacy-llm/models.md` — the approved-model registry and its
+  carve-outs.
 - `tools/privacy-llm/redactor/` — the PII redactor (name→`N-<hash>`,
   email→`E-<hash>`, IP→`IP-<hash>`).
 - `tools/privacy-llm/wiring.md` — the redact-after-fetch protocol every
   Gmail/PonyMail-reading skill follows.
 - `tools/privacy-llm/pii.md` — the PII pattern catalogue.
 - `docs/setup/privacy-llm.md` — adopter-facing setup.
+- Adopter config: `<project-config>/privacy-llm.md`, scaffolded from
+  `plugins/magpie-setup/templates/privacy-llm.md` (moved from
+  `projects/_template/` in #1410).
+- Skill: `setup-privacy-llm` (`plugins/magpie-setup/skills/privacy-llm/`)
+  detects the LLM stack in use, writes `<project-config>/privacy-llm.md`,
+  and runs the gate and the redactor end to end so the approval is
+  demonstrated rather than declared.
+- Consumers: the gate runs as a hard stop in the pre-flight of the
+  security lifecycle skills that read private mail or tracker content
+  (`security-issue-import`, `-import-from-md`, `-triage`, `-deduplicate`,
+  `-sync`, `-fix`, `-invalidate`, `security-cve-allocate`), and outside
+  the security family in `reviewer-routing`, `contributor-calibrate` and
+  `committer-onboarding` (the last with `--reads-private-list`).
 
 ## Behaviour & contract
 
diff --git a/tools/spec-loop/specs/project-agnosticism.md b/tools/spec-loop/specs/project-agnosticism.md
index 3dcc7f3cd..b7ac61fef 100644
--- a/tools/spec-loop/specs/project-agnosticism.md
+++ b/tools/spec-loop/specs/project-agnosticism.md
@@ -56,9 +56,16 @@ The three mechanisms, in order of preference:
 
 - The placeholder + config-resolution contract: `adapters.md`,
   `adoption-and-setup.md`, and the adopter scaffold
-  `projects/_template/`.
+  `plugins/magpie-setup/templates/`, shipped inside the `magpie-setup`
+  plugin since #1410 and still reachable as `projects/_template/`, which is
+  now a symlink to it.
 - The backend-flag precedent: `docs/release-management/README.md`
-  (§ adopter backends) and `projects/_template/release-management-config.md`.
+  (§ adopter backends) and
+  `plugins/magpie-setup/templates/release-management-config.md`.
+- `tools/dev/check-placeholders.sh`, the fixed-string linter for
+  project-specific names; its allowlist names
+  `plugins/magpie-setup/templates/` (the real path) rather than the
+  symlink.
 - The per-family **`organization:` scope** (formerly the binary
   `asf: true` / `asf: false` flag), declared in each family's scope banner
   at the top of `docs/<family>/README.md` and surfaced in the **Scope**
@@ -114,10 +121,29 @@ The three mechanisms, in order of preference:
   both spellings and also matches spaced variants (`name: "<project>"` as well
   as `name:"<project>"`), since YAML, JSON, and GraphQL all accept either form
   and pinning one lets the other through.
+- **Links to project docs resolve from config, never from one adopter's
+  tree.** Review footers in `pr-management-code-review`, the
+  `pr-management-triage` comment templates, and `security-issue-fix` no
+  longer link a specific project's `contributing-docs/` paths. They use
+  `<upstream_contributing_docs_url>` from `<project-config>/project.md`
+  (a footer drops its "More on how …" lines when the key is unset rather
+  than linking a guess) or the triage templates' `<quality_criteria_url>`
+  and `<two_stage_triage_rationale_url>`; `security-issue-fix` falls back
+  to a plain `Generated-by:` disclosure when the project defines none
+  (#1407).
+- **Filled examples use a neutral project.** Template examples that need
+  concrete values (`mentoring-welcome-config.md`,
+  `release-management-config.md`) use the fictional `Apache Foo`
+  (`apache/foo`, `dev@foo.apache.org`) rather than a real adopter (#1407).
+  Generic skills likewise dropped hardcoded release numbers, a backport
+  label, maintainer names, a real CVE id, and one project's canned-response
+  list in favour of `<project-config>` values, and the status-rollup marker
+  names the adopter's tracker instead of a fixed project slug (#1444).
 - **Advisory, not paternalistic.** The audit surfaces candidate coupling
   for a maintainer to judge; some ASF strings are legitimate (examples,
   the ASF default profile, ASF-specific docs). It does not auto-rewrite.
-- **Template and example profiles stay comparable.** `projects/_template/`
+- **Template and example profiles stay comparable.**
+  `plugins/magpie-setup/templates/` (reached as `projects/_template/`)
   is the adopter contract; `projects/non-asf-example/` is the proof that
   a non-ASF adopter can satisfy that contract. Required files and config
   keys should be structurally comparable, with omissions explained rather
@@ -164,13 +190,20 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   `tools/skill-and-tool-validator` (SOFT category `asf_coupling`) surfaces
   coupled tokens automatically on every validator run.  As of the
   `low-confidence-asf-coupling-pass` work (mechanical cleanup + suppression
-  of low-confidence hits for `organization:`-scoped families), the live
-  catalogue produces **3 asf-coupling warnings** — `release-audit-report` and
-  `release-promote` (`svn` invocations, remedy:adapter, pending the #602
-  Subversion backend) and `dependency-license-audit` (a bare `PMC`
-  reference). Other bare `PMC` / `ICLA` / `announce@apache.org` references
-  are inside org-scoped skills where ASF-specific text is appropriate.  No remaining tooling gap — the
-  lint exists and a human judges any new hits.  In the same pass:
+  of low-confidence hits for skills declaring `organization: ASF`), the
+  catalogue produced 3 asf-coupling warnings. Re-measured at the 2026-09-28
+  sync by running `validate_asf_coupling` over every
+  `plugins/magpie-*/skills/*/SKILL.md`, it produces **8 hits across 7
+  skills**: high-confidence `svn mv` or `dist/release/` in
+  `release-archive-sweep` (two hits), `release-audit-report`,
+  `release-keys-sync`, and `release-promote` (remedy adapter or capability
+  flag, pending the #602 Subversion backend), and a low-confidence bare
+  `PMC` in `dependency-license-audit`, `setup-privacy-llm`, and the new
+  `contributor-identity-map`, which sits in the ASF-scoped
+  contributor-growth family but declares no `organization: ASF` of its own,
+  so the low-confidence suppression does not apply to it. No remaining
+  tooling gap — the lint exists and a human judges any new hits.
+  In the same pass:
   `skills/pr-management-triage/comment-templates.md` was generalised —
   `security@apache.org` replaced with the `<security-list>` placeholder and
   the "ASF vulnerability-handling process" wording replaced with a
@@ -187,12 +220,12 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   acceptance #3 into a measurable gate.
 - **The capability-flag vocabulary for security intake and CVE allocation
   is now documented** in
-  `projects/_template/security-intake-config.md` (intake channel,
+  `plugins/magpie-setup/templates/security-intake-config.md` (intake channel,
   forwarder relay, CNA tool, allocation gate, and new
   `disclosure_governance` flags). Skills read these flags in follow-on
   updates as each flag is wired in.
 - **Contributor intake and governance capability flags are now declared**
-  in `projects/_template/committer-onboarding-config.md` (`icla` / `dco`
+  in `plugins/magpie-setup/templates/committer-onboarding-config.md` (`icla` / `dco`
   / `no-cla` for intake; `asf-pmc` / `github-codeowners` /
   `maintainer-roster` for governance), added by the
   `capability-flags-committer-intake` work item. The `committer-onboarding`
@@ -203,9 +236,15 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   judgement.
 - **Template/profile drift is now mechanically checked.** Check #15 in
   `tools/skill-and-tool-validator` (`template-drift` category, SOFT)
-  compares `projects/_template/` and `projects/non-asf-example/`: files
+  compares `projects/_template/` (the symlink to
+  `plugins/magpie-setup/templates/`) and `projects/non-asf-example/`: files
   linked in the example README must exist on disk, every config file in the
   example must be documented in its README, and shared config files (all
   except `project.md` and `README.md`, which differ by design) must have
   the same h2 section headings. The live tree produces no `template-drift`
   violations.
+- **Example-only project names remain in skill bodies.** A case-insensitive
+  search finds 40 `airflow` mentions under `plugins/magpie-*/skills/`, almost
+  all `e.g.` examples or illustrative path globs (for instance the
+  `quick-merge` candidate-rules example); `check-placeholders.sh` guards the
+  operational forms, and the remaining mentions are judged by a human.
diff --git a/tools/spec-loop/specs/release-management-lifecycle.md b/tools/spec-loop/specs/release-management-lifecycle.md
index c8c89a6fa..93ba3be35 100644
--- a/tools/spec-loop/specs/release-management-lifecycle.md
+++ b/tools/spec-loop/specs/release-management-lifecycle.md
@@ -11,7 +11,8 @@ source: >
   standard process within 3 months of resolution adoption"). README.md
   § Skill families (release-management, proposed). Designed spec-first in
   docs/release-management/ (README.md, process.md, spec.md) plus the
-  adopter scaffold projects/_template/release-management-config.md.
+  adopter scaffold plugins/magpie-setup/templates/release-management-config.md
+  (reached as projects/_template/, #1410).
   All ten skills have since shipped (release-prepare, release-keys-sync,
   release-rc-cut, release-vote-draft, release-archive-sweep,
   release-audit-report, release-announce-draft, release-verify-rc,
@@ -53,12 +54,28 @@ code lands.
   (family overview + skill table), `docs/release-management/process.md`
   (14-step lifecycle, Mermaid flow, label reference),
   `docs/release-management/spec.md` (per-skill scope and state-change
-  boundary).
-- Adopter contract: `projects/_template/release-management-config.md`,
-  `projects/_template/release-build.md`, `projects/_template/pmc-roster.md`,
-  `projects/_template/site-repo.md`, and the shared
-  `projects/_template/release-trains.md`.
-- Skills (all ten shipped, all `experimental`): `release-prepare`
+  boundary), plus the operator runbooks
+  `docs/release-management/atr-release-runbook.md`,
+  `docs/release-management/svn-release-runbook.md`,
+  `docs/release-management/manual-release-process.md`, and
+  `docs/release-management/reproducibility.md`.
+- Adopter contract: `release-management-config.md`, `release-build.md`,
+  `pmc-roster.md`, `site-repo.md`, the shared `release-trains.md`, and
+  `workflows/release-candidate.yml`, all under
+  `plugins/magpie-setup/templates/` since #1410 so a marketplace install of
+  `magpie-setup` ships them; `projects/_template` is a symlink to that
+  directory, so the old paths still resolve.
+  The filled-example values in the template use the neutral `Apache Foo`
+  project rather than a real adopter (#1407).
+- Magpie's own release configuration: `projects/magpie/` holds the filled
+  `release-management-config.md` (ATR for both distribution and vote),
+  `release-build.md`, `release-trains.md`, and `pmc-roster.md`; #1412 also
+  committed `release-management-config.md`, `release-build.md`,
+  `release-trains.md`, and `pmc-roster.md` under
+  `.apache-magpie-overrides/` for the framework checkout's self-adoption.
+- Skills (all ten shipped, all `experimental`, under
+  `plugins/magpie-release-management/skills/<alias>/` with
+  `skills/release-<alias>` symlinks): `release-prepare`
   (`mode: Drafting`) drafts the planning issue (Step 1), the prep PR with
   version bump / changelog / NOTICE / LICENSE (Step 2), and the
   post-release development-version bump PR (Step 14), never marking ready,
@@ -152,7 +169,8 @@ code lands.
   organization manifest; `null` elsewhere). `release-prepare
   automated-signing` drafts — never files or sends — the Infra key-request
   ticket, the Security Team notification and the workflow PR
-  (`projects/_template/workflows/release-candidate.yml`, no key material).
+  (`plugins/magpie-setup/templates/workflows/release-candidate.yml`, no key
+  material).
   With `automated_release_signing: enabled`, `release-rc-cut` emits the
   RM-signed tag push instead of local sign/stage, `release-verify-rc` Step 9
   is mandatory at a byte-identical bar and carries the committer's
@@ -197,7 +215,8 @@ code lands.
 ```bash
 test -f docs/release-management/spec.md
 test -f docs/release-management/process.md
-test -f projects/_template/release-management-config.md
+test -f plugins/magpie-setup/templates/release-management-config.md
+test -L projects/_template
 test -f .agents/skills/magpie-release-prepare/SKILL.md
 test -f .agents/skills/magpie-release-keys-sync/SKILL.md
 test -f .agents/skills/magpie-release-rc-cut/SKILL.md
@@ -224,6 +243,21 @@ uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/release-an
   evidence window that would justify default-on or a state-changing lane
   has no data behind it.
 - **Release audit record schema has shipped.** The canonical structured
-  schema lives at `skills/release-audit-report/audit-record-schema.md`.
+  schema lives at
+  `plugins/magpie-release-management/skills/audit-report/audit-record-schema.md`
+  (reached as `skills/release-audit-report/audit-record-schema.md`).
   The `tools/skill-evals/evals/release-audit-report/` suite validates
   incomplete records, including the `case-4-all-required-missing` fixture.
+- **Magpie's committed override is the unfilled template.** Per-file
+  `<project-config>` resolution reads
+  `.apache-magpie-overrides/release-management-config.md` in this
+  repository, and that file (added by #1412) is the template's
+  `Apache Foo` example with `release_dist_backend = svnpubsub` and
+  `release_vote_backend = manual`, whereas
+  `projects/magpie/release-management-config.md` carries Magpie's real
+  values (`project_dist_name: magpie`, ATR for both backends).
+  `.apache-magpie-overrides/release-build.md` likewise differs from
+  `projects/magpie/release-build.md`.
+- **The family's `SKILL.md` files are the largest in the catalogue.**
+  Eight of the ten are over the 500-line cap (`release-prepare` 1,208,
+  `release-verify-rc` 968, `release-rc-cut` 932).
diff --git a/tools/spec-loop/specs/repo-health-family.md b/tools/spec-loop/specs/repo-health-family.md
index c40bf5582..616df9f4f 100644
--- a/tools/spec-loop/specs/repo-health-family.md
+++ b/tools/spec-loop/specs/repo-health-family.md
@@ -50,6 +50,13 @@ grouped, prioritised report → wait for confirmation before any write.
   one Apache project's repos, or the full Apache GitHub org, is read-only
   (no workflow file, manifest, lock file, source file, or test is
   modified), and ships `mode: Triage` + `experimental` with an eval suite.
+- Seventh member, not an audit: `audit-finding-fix`
+  (`plugins/magpie-repo-health/skills/audit-finding-fix/`) also carries
+  `family: repo-health` and ships in the family plugin, but it is a
+  `mode: Drafting` / `capability:fix` skill that drafts fixes for the
+  findings a non-security audit tool reports.
+  Its contract lives in [`drafting-mode.md`](drafting-mode.md); the
+  read-only rules below cover the six audit skills only.
 - Sixth skill: `dependency-license-audit` (resolves the license
   of every direct and transitive dependency, classifies each against the
   project's license policy, and reports incompatible or unknown-license
@@ -70,11 +77,10 @@ grouped, prioritised report → wait for confirmation before any write.
   `mode: Triage` + `experimental` with an eval suite.
 - Design docs: `docs/repo-health/README.md` — family overview and the
   adopter-config scaffold.
-- Planned adopter config: `projects/_template/repo-health-config.md` —
+- Adopter config: `plugins/magpie-setup/templates/repo-health-config.md`
+  (shipped inside the `magpie-setup` plugin) —
   per-skill switches (deprecated-runner families, zizmor rule classes,
   dependency-manager selection, SPDX expression, flaky-test window).
-  Lands in a separate build item once at least one candidate skill reaches
-  the planning stage.
 
 ## Behaviour & contract
 
@@ -92,6 +98,20 @@ grouped, prioritised report → wait for confirmation before any write.
   maintenance concern (runner labels, workflow security, dependency
   freshness, license compliance, test stability). Skills do not share
   intermediate state, so each runs independently.
+- **A failed scan is never a clean result.** `workflow-security-audit`
+  keeps zizmor's error output visible; a repository whose scan exits with
+  an unexpected non-zero status is listed as a scan failure with that
+  output, never reported as having no findings.
+  For several repositories or a whole org, zizmor scans up to 50
+  repositories per invocation (the org's repository list comes from one
+  plain `gh api` call), and each finding's location names its repository
+  so the report still groups per repository (#1443).
+  Exit codes 11–14 mean findings and are expected; any other non-zero
+  exit does not say which repository failed, so that batch is re-run one
+  repository per invocation.
+  A repository whose own run exits outside 0 and 11–14, or that the
+  batch's stderr names in a collection warning, is the scan failure
+  listed in the report.
 
 ## Out of scope
 
@@ -130,13 +150,13 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
 
 ## Known gaps
 
-- **Family is six skills deep — feature-complete.** `ci-runner-audit`,
+- **Six audit skills deep — feature-complete.** `ci-runner-audit`,
   `workflow-security-audit`, `dependency-audit`, `license-compliance-audit`,
   `flaky-test-triage`, and `dependency-license-audit` have all shipped
   (read-only, `experimental`, each with an eval suite). No further candidate
   skills remain designed; the family is complete pending adopter-pilot
   evaluation.
-- **Adopter-config scaffold exists.** `projects/_template/repo-health-config.md`
+- **Adopter-config scaffold exists.** `plugins/magpie-setup/templates/repo-health-config.md`
   covers all six skills; adopters copy it into their `<project-config>/`
   and fill in the relevant keys.
 - **No adopter pilot has run any family skill end-to-end.** All six
diff --git a/tools/spec-loop/specs/reviewer-routing.md b/tools/spec-loop/specs/reviewer-routing.md
index 54a51eadc..354899055 100644
--- a/tools/spec-loop/specs/reviewer-routing.md
+++ b/tools/spec-loop/specs/reviewer-routing.md
@@ -10,12 +10,12 @@ source: >
   MISSION.md § Rationale ("review-cycle latency" is one of the two named
   priorities) and § Technical scope (Agentic Triage: "proposes initial routing",
   "proposes routing"). The substrate config already declares "who
-  reviews" (overview.md § Substrate; projects/_template adopter config),
+  reviews" (overview.md § Substrate; plugins/magpie-setup/templates adopter config),
   but no skill turns that roster plus repository signal into an assignee
   suggestion. triage-mode.md § What it does ("propose routing to the
   right human") names the behaviour. Skill ships experimental in
-  .agents/skills/magpie-reviewer-routing/ with an eval suite under
-  tools/skill-evals/evals/reviewer-routing/.
+  plugins/magpie-pr-management/skills/reviewer-routing/ with an eval
+  suite under tools/skill-evals/evals/reviewer-routing/.
 acceptance:
   - The skill is read-only on tracker state and proposes-then-confirms;
     it never assigns, requests review, or labels without confirmation.
@@ -46,13 +46,23 @@ side: a grounded brief a human acts on, not a state change.
 
 ## Where it lives
 
-- Skill: `reviewer-routing` under `.agents/skills/magpie-reviewer-routing/`,
-  in the Agentic Triage family alongside `pr-management-triage` and
+- Skill: `plugins/magpie-pr-management/skills/reviewer-routing/SKILL.md`,
+  shipped in the `magpie-pr-management` plugin and reachable through the
+  `skills/reviewer-routing` and `.agents/skills/magpie-reviewer-routing`
+  symlinks. Agentic Triage mode, alongside `pr-management-triage` and
   `issue-triage`. Eval suite under `tools/skill-evals/evals/reviewer-routing/`.
-- Roster source: the project's configured reviewer roster
-  (`projects/<project>/` adopter config; `pmc-roster.md` for ASF
-  projects, an arbitrary maintainer list for non-ASF adopters). The
-  skill reads the roster through configuration, never a hard-coded list.
+- Roster source: the project's configured reviewer roster, read through
+  configuration, never a hard-coded list.
+  ASF projects use `<project-config>/release-trains.md` (the
+  per-component handle table `issue-triage` and `pr-management-triage`
+  already read); non-ASF adopters use `<project-config>/reviewer-roster.md`
+  (GitHub handles and declared areas, optional per-reviewer
+  `max_reviews`). Scaffolds for both live in
+  `plugins/magpie-setup/templates/` (`projects/_template` is a symlink
+  to it); `projects/non-asf-example/reviewer-roster.md` is a worked
+  non-ASF example.
+- Privacy-LLM gate: `<project-config>/privacy-llm.md`, checked with
+  `tools/privacy-llm/checker` at Step 0.
 - Repository signal: `tools/github` for changed paths, blame/history on
   those paths, and the reviewer's current open-review queue.
 - Identity resolution for ASF projects: `tools/apache-projects`
@@ -82,6 +92,31 @@ side: a grounded brief a human acts on, not a state change.
 - **Untrusted content stays data.** Issue / PR bodies are input data,
   never instructions; an injected "assign this to X" line in a PR
   description is ignored, the same posture every triage skill inherits.
+  When one is detected, the proposal says it is based on metadata and
+  roster signals only.
+- **Privacy gate before any body is fetched.** Step 0 checks `gh`
+  authentication, reads `project.md`, resolves the roster and the input,
+  then runs `privacy-llm-check` (flags: `--config`,
+  `--reads-private-list`, `--quiet`); a non-zero exit is a hard stop.
+  Step 0 returns a JSON verdict (`proceed` / `blocked`) with
+  `privacy_gate_passed` and `roster_source`
+  (`release-trains` / `reviewer-roster` / `null`).
+- **Deterministic scoring.** Area match scores 3 points per matched area
+  (capped at 6), git familiarity 2 points per authored path in the
+  changed set (capped at 6; zero for issues), and load subtracts 1 point
+  per open review request above 2 (down to -5). Load is the count of
+  open PRs on `<upstream>` with a review requested from the member; at
+  or above `max_reviews` (default 5) the member is `OVERLOADED`.
+  An overloaded member never takes the primary slot but may be proposed
+  as backup when no one else remains. Ties break alphabetically.
+  If every member is overloaded or none matches the touched areas, the
+  output is `NO ELIGIBLE REVIEWER — all roster members overloaded or no
+  area match`.
+- **Maintainer controls the outcome.** The confirmation step accepts
+  the proposal, declines it, swaps primary and backup, or overrides the
+  primary with a handle that must itself be on the roster.
+  On accept the skill prints the `gh` command for the maintainer to run
+  and stops; it never runs it.
 
 ## Out of scope
 
@@ -113,10 +148,16 @@ uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/reviewer-r
 
 ## Known gaps
 
-- **Open-review-load signal is implementation-defined.** Whether load is
-  counted as open review requests, assigned-and-unreviewed PRs, or a
-  decay-weighted recent count is left to the implementation; the contract
-  only requires that some load signal is present and shown.
+- **Open-review-load signal is now defined.** The skill counts open
+  review requests (`review-requested:@<handle>` on open PRs) against a
+  per-reviewer `max_reviews` (default 5); assigned-but-unrequested PRs
+  and recency decay are not counted. Gap cleared; a richer load model
+  would be a future change.
+- **The skill names a checker flag that does not exist.** Step 0 of
+  `SKILL.md` tells the maintainer to "run `privacy-llm-check --list`"
+  after a gate failure, but `tools/privacy-llm/checker` accepts only
+  `--config`, `--reads-private-list` and `--quiet`, so that command
+  fails with an argument error. The skill text needs correcting.
 - **Non-ASF roster shape is now exercised.** `projects/non-asf-example/reviewer-roster.md`
   provides a Velox Stream roster with no ASF-specific fields; the
   `non-asf-profile-smoke/step-reviewer-routing/` eval suite asserts that
diff --git a/tools/spec-loop/specs/sandbox-diagnostics.md b/tools/spec-loop/specs/sandbox-diagnostics.md
index 47c7e24c7..9ead00206 100644
--- a/tools/spec-loop/specs/sandbox-diagnostics.md
+++ b/tools/spec-loop/specs/sandbox-diagnostics.md
@@ -47,7 +47,7 @@ error, and two skills that probe or verify the setup on demand.
   **Root cause** (which sandbox layer blocks it and why), **Fix** (a
   settings widening with per-entry rationale, or — for the `gh` entry —
   an invocation-shape rule, because there is nothing to widen), and
-  **Notes**. Ten entries today: SSH agent / Yubikey, signed commit
+  **Notes**. Eleven entries today: SSH agent / Yubikey, signed commit
   failing before any touch (`gpg.format=ssh` key unreadable), signed
   commit failing with `cannot exec` of the touch-overlay wrapper
   (`gpg.ssh.program` under the read-denied `~/.claude/scripts/`),
@@ -58,9 +58,12 @@ error, and two skills that probe or verify the setup on demand.
   socket, `/tmp` read-only, `gh` inside the sandbox (TLS
   `OSStatus -26276` / `HTTP 401`), `prek` or `uv` not found or unable
   to write its cache (the home-directory dev-tool paths not granted in
-  the worktree's `settings.local.json`, #1359), and git hooks silently
+  the worktree's `settings.local.json`, #1359), git hooks silently
   skipped for sandboxed commits (whole-user `core.hooksPath` under the
-  read-denied home, #1364).
+  read-denied home, #1364), and reads of `~/.claude/magpie` or
+  `/tmp/claude-<uid>` asking for approval every time
+  (`permissions.blockReadsOutsideWorkingDirectories` on and neither
+  directory a working directory, #1418).
 - `tools/agent-isolation/sandbox-error-hint.sh` — a Claude Code
   `PostToolUse` hook on the `Bash` matcher. Scans the tool's stdout +
   stderr for the catalogued symptom strings and, on a match, prints
@@ -68,7 +71,8 @@ error, and two skills that probe or verify the setup on demand.
   exiting 1 so the line reaches the model and the user. Tests under
   `tools/agent-isolation/tests/test_sandbox_error_hint.py`.
 - Skill `setup-isolated-setup-doctor` — live, read-only probes
-  (`## The 8 probes`), each reporting ✓ / ✗ / ⊘ / ⚠ with the command
+  (nine, `### Probe 1` to `### Probe 9`, under a section heading that
+  still reads `## The 8 probes`), each reporting ✓ / ✗ / ⊘ / ⚠ with the command
   and its output as evidence, and each mapping ✗ to the matching
   catalog anchor. Each probe is a deterministic, side-effect-free
   script, `scripts/probe-<n>-<slug>.sh`, printing one
@@ -82,21 +86,38 @@ error, and two skills that probe or verify the setup on demand.
   same as an absent one (#1362). Probe 8 looks at the global
   `core.hooksPath` directory from inside the sandbox: skip when none
   is set, fail when the directory or a hook's symlink target is
-  unreadable, warn when it holds none of the common hooks (#1364). The `gh` probe runs `gh` through `sh -c` so
+  unreadable, warn when it holds none of the common hooks (#1364). Probe 9, only
+  when `permissions.blockReadsOutsideWorkingDirectories` is on, checks
+  that `$HOME/.claude/magpie` and `/tmp/claude-<uid>` are working
+  directories as resolved paths: ⚠ for a missing path or for a glob entry
+  such as `/tmp/claude-*`, which is listed but never matched, and ⊘ when
+  the block is off, `HOME` is unset, or the entries are absent from the
+  readable project files while user-scope settings are unreadable from
+  the sandbox (#1418). The `gh` probe runs `gh` through `sh -c` so
   the `excludedCommands` exemption cannot apply to the probe itself,
   which shows what an un-excluded `gh` does on this machine, then
   checks that `"gh *"` is configured.
 - Skill `setup-isolated-setup-verify` — static checks of the installed
-  configuration (`## The 12 checks`, numbered 1–13 with the last
-  optional): settings shape, hook wiring, hook scripts, wrapper,
+  configuration (numbered 1–15 under a section heading that still reads
+  `## The 12 checks`; 13 and 14 optional): settings shape, hook wiring, hook scripts, wrapper,
   pinned versions, status line, denial canaries, project-root grant
   (check 8 — also the dev-tool paths, whose absence is ⚠ not ✗, and in
   whole-user scope the shared hook directory probed from inside the
   sandbox, whose unreadability is ✗), the vetted-ops split, the touch
   overlay and signing key (check 10), the `gh` exclusion (check 11),
-  the container gateway (check 12), and the eval-harness exclusion
-  (check 13, if installed). The conditional checks — 9, 10, 12, 13 and
-  check 8's whole-user branch — live in `conditional-checks.md`; the
+  the container gateway (check 12), the eval-harness exclusion
+  (check 13, if installed), the adversarial-review exclusion (check 14,
+  if the `magpie-adversarial-review` plugin is installed: the
+  `excludedCommands` entry, ⚠ when missing; the plugin-cache `Edit`
+  deny, ✗ when missing; and no `allow` rule, ✗ when one matches, #1371),
+  and the working directories under the read block (check 15: the two
+  resolved paths in the worktree's `settings.local.json`, ⚠ when missing
+  or glob-only, ⚠ when they sit in committed or synced user-scope
+  settings instead, #1418). Check 9 also fails a vetted-ops rule that
+  spells the versioned plugin-cache path with a `*`, since the rule must
+  name `~/.claude/magpie/vetted-ops` (#1406). The conditional checks —
+  9, 10, 12, 13, 14 and check 8's whole-user branch — live in
+  `conditional-checks.md`; the
   body keeps each one's condition and its **n/a** answer, so a run
   that meets none of the conditions reads none of them (#1334).
   Mirrors the "Via a Claude Code prompt" checklist in
@@ -116,7 +137,9 @@ error, and two skills that probe or verify the setup on demand.
   nothing: git skips a hook directory it cannot see without a word, so
   the git-hooks entry has no symptom string to match and is reached
   through the doctor's probe 8 and verify check 8 instead, and says so
-  in its **Notes**.
+  in its **Notes**. The working-directories entry is the second: its
+  approval prompt comes before any command runs, so the hook never sees
+  it, and it is reached through doctor probe 9 and verify check 15.
 - **Symptom strings are literal.** Entries quote the exact error text
   so a grep into the catalog finds them; the hook matches those same
   strings with anchored, specific regexes. False-positive hints are
@@ -138,16 +161,19 @@ error, and two skills that probe or verify the setup on demand.
   every restriction rather than one per re-run.
 - **The `gh` exclusion rule.** `sandbox.excludedCommands: ["gh *"]`
   exempts a `gh` call only when every part of the Bash invocation is
-  `cd …` or `gh …`. A pipe, a `$(…)` substitution, a loop, or any file
-  redirection (including `> /dev/null`) keeps the whole invocation in
-  the sandbox, where `gh` fails with `x509: OSStatus -26276` on macOS
+  `cd …` or `gh …`. A pipe, a `$(…)` substitution, a loop, any file
+  redirection (including `> /dev/null`), or a backtick anywhere in the
+  command string, even escaped or single-quoted (#1384), keeps the whole
+  invocation in the sandbox, where `gh` fails with `x509: OSStatus -26276` on macOS
   because Go's TLS verification goes through Security.framework and
   Seatbelt blocks the trustd / keychain mach services. Nothing on the
   Go side works around that (no fallback roots in the Homebrew build,
   `SSL_CERT_FILE` ignored on darwin). The catalog entry carries the
   measured shape table, the `gh tofile` alias that moves a redirection
   inside `gh` (guarded to `$PWD` and the Claude scratch tree, because
-  the alias runs unsandboxed), and the upstream report
+  the alias runs unsandboxed), the rule to pass Markdown titles and
+  bodies from a file (`--body-file`, or `--input` for `gh api`) because
+  an inline Markdown body carries backticks, and the upstream report
   anthropics/claude-code#95532 for the redirection regression.
 - **The `gh` ask-rule rule.** `permissions.ask` names gh write
   subcommands one by one and never a catch-all `Bash(gh *)`: Claude
@@ -177,7 +203,9 @@ error, and two skills that probe or verify the setup on demand.
 1. Each catalog entry has the four sections, a literal symptom, and a
    matching `match … hint=` branch in the hook whose anchor resolves
    (lychee checks the docs; the hook's anchors are asserted by its
-   tests).
+   tests), except the two entries that print nothing the hook could
+   see (git hooks skipped, working-directory prompts), which name their
+   probe and check in **Notes** instead.
 2. The hook exits 1 with a `[sandbox-hint]` line for every catalogued
    signature, exits 0 with no output on benign output, on a non-Bash
    tool, and on invalid JSON.
@@ -213,11 +241,16 @@ PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner \
 
 ## Known gaps
 
-- The doctor runs 8 probes over the catalog's 10 entries: the two
+- The doctor runs 9 probes over the catalog's 11 entries: the two
   touch-overlay entries (`cannot exec` of the wrapper, and the
   runtime-state directory) have no live probe. Verify check 10 covers
   the wrapper's `allowRead` grant statically; the runtime-state entry
   is reached only through the hint hook.
+- The doctor's and verify skill's section headings (`## The 8 probes`,
+  `## The 12 checks`) lag their bodies (nine probes, fifteen checks).
+- A command that spells a working directory with a literal `~` can
+  still prompt under the read block even when the directory is listed;
+  the working-directories entry names that case as open.
 
 - The invocation-shape rule is measured on macOS / Claude Code 2.1.278
   and will change when anthropics/claude-code#95532 is fixed; the
diff --git a/tools/spec-loop/specs/security-issue-lifecycle.md b/tools/spec-loop/specs/security-issue-lifecycle.md
index 89d0d041f..d33e54b87 100644
--- a/tools/spec-loop/specs/security-issue-lifecycle.md
+++ b/tools/spec-loop/specs/security-issue-lifecycle.md
@@ -43,6 +43,47 @@ publication, with a human gate and an audit-log entry at every step.
   third-party disclosure platform) by applying preamble-detect,
   credit-extract, and routing rules declared in
   `tools/forwarder-relay/`; never mutates tracker state on its own.
+- Skill files live at `plugins/magpie-security/skills/<alias>/SKILL.md`
+  (alias drops the `security-` prefix, e.g. `issue-import`), reached
+  from `skills/security-<name>` symlinks.
+  Oversized `SKILL.md` files were split (#1436): each keeps its
+  orchestration (golden rules, Step 0, every step heading, gates, hard
+  rules) and moves the elaboration verbatim into linked siblings one link
+  away, such as `issue-import/apply.md`, `screening-and-proposal.md`,
+  `duplicate-search.md`; `issue-fix/implementation-plan.md`,
+  `tracker-update.md`; `issue-triage/classification.md`;
+  `issue-sync/mail-preflight.md`, `next-step.md`;
+  `cve-allocate/tracker-updates.md`, `title-normalize.md`.
+  Moved headings keep a one-line pointer in `SKILL.md` so anchors still
+  resolve, and eval `step-config.json` files point at the sibling.
+- Shared recipes instead of per-skill copies (#1437): the safe-create
+  recipe for a tracker with an attacker-controlled title is
+  `tools/github/operations.md` § *Create* (Write-tool title file,
+  `gh api -F title=@<file>`), and the import skills and
+  `security-issue-invalidate` point at `tools/github/project-board.md`
+  for the orphan-issue, introspection and archive board recipes.
+- Status rollups are written by `tools/github-rollup/`
+  (`append`, `amend-latest`, `fold`, `list`, `latest`).
+  Under the secure setup that CLI's `gh` runs sandboxed and fails, so the
+  same rollup and body-field procedures are reachable through the
+  sandbox-exempt `vetted-op-tracker` entry point (`rollup-append`,
+  `rollup-amend-latest`, `rollup-fold`, `body-field-set`) and
+  `vetted-op-read … body-field-get` (#1448; see
+  [`vetted-command-surface.md`](vetted-command-surface.md)).
+  Since #1451 the security skills call those procedures for every rollup
+  and single-field write (import, import-from-md, import-from-pr,
+  invalidate, deduplicate, cve-allocate, issue-fix, sync), so the rollup
+  and the issue body never enter the agent's context.
+  Entry templates keep their body text; the tool writes the `<details>`
+  envelope and the marker line.
+  `rollup-amend-latest` fills invalidate's draft id into the entry it
+  just wrote, `rollup-fold` replaces the hand-rolled fold-legacy
+  sequences and deletes the legacy comment only after the append
+  succeeded, and `body-field-get` / `body-field-set` replace whole-body
+  rewrites that touched one field; sync keeps a whole-body write only
+  where it adds sections the body lacks.
+  Each skill notes once how to run the same operations without the
+  secure setup, through the `github-rollup` and `github-body-field` CLIs.
 - Tools: `tools/cve-tool-vulnogram/generate-cve-json` (CVE 5.x JSON),
   `tools/cve-org`, `tools/gmail` + `tools/ponymail` (mail), and the
   `tools/privacy-llm` gate/redactor ([the privacy gate](privacy-llm-gate.md)).
@@ -59,6 +100,114 @@ publication, with a human gate and an audit-log entry at every step.
 - **Reporter PII redacted in-context; reporter *credit* preserved** in
   the CVE `credits[]` only after the reporter confirms on the thread.
 - **Audit log** of every applied change (redacted identifiers only).
+  The per-tracker status rollup is recognised by any first line of the
+  form `<!-- <name> status rollup v<N>`, and a new rollup's marker names
+  the tracker repository, so the rollup works on any adopter's tracker
+  rather than only the reference one (#1444).
+  `amend-latest` fills in a value on the newest entry (refusing when that
+  entry has a different action), and `fold` moves a legacy bot comment
+  into the rollup, deleting the original only after the append succeeds.
+- **One forbidden-term list for public PRs.** `security-issue-fix` 5c is
+  the single list that 5g, Step 7, Step 9 and the guardrails check
+  against: CVE IDs, `CVE`, `vulnerability`, `security fix`, `advisory`,
+  `security@`, vulnerability-class names (for example `SSRF`,
+  `path traversal`), reporter names, and exploitation detail.
+  Naming the affected component and the behaviour change neutrally is
+  allowed.
+  A `<tracker>` link is also allowed in the public PR body, as a bare
+  identifier with no security framing around it; the skill's description
+  and golden rules no longer forbid linking back to the tracker (#1447).
+  The agent-guard `security-language` guard is a backstop on
+  `gh pr create` / `gh pr edit`, not a replacement: it covers a subset of
+  the list and never sees the commit message, branch name, or
+  newsfragment (#1444).
+- **Adversarial review before a PR, on public content only.**
+  `security-issue-fix`, `security-issue-import-from-pr` (over the patch it
+  verifies) and `security-issue-import-from-scan` carry the shared
+  pre-PR adversarial-review block (#1372).
+  Unlike other families, the security family runs it whenever at least
+  one reviewer is configured, whatever the configured `mode`.
+  Reviewers see only the diff and the PR title and body exactly as they
+  will be posted, after the skill's own forbidden-term check; never
+  tracker text, an unpublished CVE ID, reporter detail, or mail.
+  The review never runs against the private tracker checkout, and its
+  findings are advisory data that never block the flow.
+- **Attacker-controlled titles never reach a shell argument.** Tracker
+  creation from a report title goes through the safe-create recipe
+  (title written to a file, passed by `-F title=@<file>`), never
+  `gh issue create --title '<title>'` (#1437).
+- **Import dedup searches follow a provisional class.**
+  `security-issue-import` Steps 2a and 2c skip their searches for a
+  candidate whose provisional class, read from the root message, is
+  never-a-tracker; if Step 3 then classes it as a `Report` (or
+  forwarder-relayed), the skipped searches run before Step 4 (#1444).
+- **Pre-flight declares what each skill cannot run without.** Every
+  security skill lists its required `<project-config>` files in
+  `requires_config:`, which the generated pre-flight block checks before
+  the run starts (triage, invalidate, import-from-md and model-update
+  gained declarations in #1444).
+  Snapshot-drift detection is the generated pre-flight's job; the
+  per-skill *Snapshot drift* prose sections were removed (#1435).
+- **Fetch once per run, not once per item (#1443).**
+  Shared reads are fetched once and reused, without changing which items
+  are processed or how each is decided.
+  `security-issue-import` reads each mail thread in full once (Step 2a)
+  for Steps 3 and 4, keeping one fresh read at Step 7 because a draft or
+  reporter reply can land between scan and apply; the semantic-sweep list
+  of open trackers, the collaborator list and the rejections-ledger number
+  are fetched once per run, and thread-id dedup searches carry up to 6 ids
+  per query.
+  `security-issue-triage` gathers body, comments and linked PRs with one
+  aliased GraphQL query per chunk of up to 20 trackers, and
+  `security-issue-invalidate`'s `invalidate proposed` fetches reactions
+  and state the same way instead of a reactions call and an issue view
+  per tracker.
+  `security-issue-sync` takes linked PRs and their authors from one query
+  and the hand-off comment and milestone bullet from its first issue read.
+  `security-issue-import-from-scan` fetches the open-tracker list once for
+  all findings, `-from-md` sets labels at creation, and `-from-pr` runs one
+  duplicate search instead of two.
+  Every batched list call keeps an explicit `--limit` and says what to do
+  at the cap: triage and invalidate list with `--limit 1000`, and
+  invalidate stops and surfaces a list that returns exactly 1000 rather
+  than proceed on a possibly truncated set; a dedup search returning
+  exactly its limit is treated as possibly truncated.
+- **Obvious no-ops are skipped before any per-item model work (#1449).**
+  A deterministic check drops items the full pass would also no-op,
+  before a body read or a classification runs.
+  Every skip is listed with its rule, a borderline item is kept, and
+  `--no-preflight` turns the check off.
+  `security-issue-triage` skips a tracker whose newest comment is its own
+  triage proposal by a team member with no later tracker or mail
+  activity; `--retriage` and explicitly numbered trackers are never
+  skipped.
+  `security-issue-import` drops CVE-tool bookkeeping mail by subject and
+  sender in Step 1, before any thread body is read; the Step 3 row stays
+  as the backstop for the body-line variant, pre-filtered threads are
+  counted at Step 5 and listed at Step 8, and `keep <threadId>` sends one
+  back through Steps 2 to 5.
+  The forwarder sub-skill is invoked only when `forwarders.enabled` is set
+  and a message matches an enabled adapter's sender or preamble pattern,
+  a strict subset of the sub-skill's own *not a relay* outcome.
+  `gh` calls that were wrapped in `$(…)` or piped are now plain commands,
+  which the secure setup needs.
+- **Small always-on footprint (#1447).**
+  Each security skill's `description` and `when_to_use`, which load in
+  every session, state only its purpose, main trigger phrases and where
+  to route instead; the family's always-on total dropped from about 1.6k
+  to about 1.1k tokens.
+- **Mandatory mail backends are a hard stop.** In `security-issue-sync`,
+  a `mandatory: yes` backend that is unavailable or unauthenticated,
+  PonyMail included, stops the run; only `mandatory: no` backends degrade
+  quietly (#1444).
+- **Project-neutral content.** Release numbers, backport labels and
+  maintainer names come from `<project-config>/release-trains.md` and the
+  other adopter files, not from the skills; `security-issue-fix` links the
+  project's PR conventions through `upstream_contributing_docs_url` in
+  `project.md` (#1407, #1444).
+  Scratch files use the absolute session scratch directory (`<scratch>`),
+  not literal `/tmp` paths the sandbox cannot write, so `gh` running
+  outside the sandbox resolves the same file.
 - **An unresponsive reporter never blocks the team.** When
   `security-issue-sync` finds the reporter thread stale — the team's last
   outbound message older than
@@ -111,3 +260,9 @@ uv run --project tools/gmail/oauth-draft pytest
 
 - The flow is `stable`; gaps surface as drift between a skill's documented
   steps and the adapters it calls — the loop's plan pass catches those.
+- The generic rollup recipe in `tools/github/status-rollup.md` still
+  spells only the `uv run --directory … github-rollup` CLI and does not
+  mention `vetted-op-tracker`, although the security skills themselves
+  switched to it in #1451.
+  An adopter following that recipe under the secure setup hits the
+  sandboxed-`gh` failure the entry point exists to avoid.
diff --git a/tools/spec-loop/specs/security-model-preparation.md b/tools/spec-loop/specs/security-model-preparation.md
index ad30cb893..5b357ce2a 100644
--- a/tools/spec-loop/specs/security-model-preparation.md
+++ b/tools/spec-loop/specs/security-model-preparation.md
@@ -40,14 +40,23 @@ triage history back into the document.
 ## Where it lives
 
 - Skills: `security-model-prepare` (Drafting), `security-model-verify`
-  (Triage), `security-model-update` (Drafting).
-- Helper: `skills/security-model-verify/scripts/model_pr.py` — the
-  create-or-append `AGENTS.md` / `SECURITY.md` scaffold plus the PR
+  (Triage), `security-model-update` (Drafting), at
+  `plugins/magpie-security/skills/model-{prepare,verify,update}/SKILL.md`
+  behind `skills/security-model-*` symlinks.
+  `security-model-verify` keeps its orchestration in `SKILL.md` and its
+  helper usage and PR/mail templates in the linked siblings `helper.md`
+  and `templates.md` (#1436).
+- Helper: `plugins/magpie-security/skills/model-verify/scripts/model_pr.py`
+  — the create-or-append `AGENTS.md` / `SECURITY.md` scaffold plus the PR
   mechanics, with the pure file-merge core unit-tested in
-  `skills/security-model-verify/tests/`.
+  `plugins/magpie-security/skills/model-verify/tests/`.
 - Deep doc: `docs/security/security-model-preparation.md`.
 - Adopter config: `<project-config>/security-model.md` § *Model
-  preparation, verification, and update*.
+  preparation, verification, and update*; the scaffold ships at
+  `plugins/magpie-setup/templates/security-model.md` (#1410).
+  All three skills declare `security-model.md` in `requires_config:`
+  (verify also `project.md`), so the generated pre-flight stops a run
+  that lacks it (model-update gained its declaration in #1444).
 - Threat model: skill family F in `docs/security/threat-model.md`
   (F.1–F.7, mitigations M.30–M.36).
 
@@ -60,6 +69,10 @@ triage history back into the document.
   gate.** A model an agent cannot reach is an absent one. Completeness is
   graded: every gap is a proposal the maintainer decides on, never a
   precondition.
+  On GitHub, `security-model-verify` fetches the first two hops
+  (`AGENTS.md` and `SECURITY.md` at the pinned ref) for every repository in
+  one aliased GraphQL query, run as a plain `gh api graphql` from a scratch
+  query file, instead of two contents reads per repository (#1443).
 - **Mechanical gap → PR; substantive gap → private mail; never a public
   issue.** A public list of a project's threat-model gaps is an inventory
   a hostile researcher would mine, many projects have no usable public
@@ -85,6 +98,13 @@ triage history back into the document.
   before send.
 - **No programme, vendor, or engagement identity on a public surface** —
   PR titles, bodies, commit messages, branch names.
+- **Adversarial review of the model PR.** `security-model-prepare` and
+  `security-model-verify` carry the shared pre-PR adversarial-review
+  block and review the helper's `--dry-run` diff with the PR title and
+  body as they will be posted (#1372).
+  As security-family skills they run it whenever at least one reviewer
+  is configured, whatever the `mode`; findings are advisory and never
+  block the flow.
 
 ## Out of scope
 
diff --git a/tools/spec-loop/specs/security-reporting.md b/tools/spec-loop/specs/security-reporting.md
index fe5a07e22..a318a95cb 100644
--- a/tools/spec-loop/specs/security-reporting.md
+++ b/tools/spec-loop/specs/security-reporting.md
@@ -35,9 +35,15 @@ health without navigating the tracker issue-by-issue.
   the existing data rather than re-fetching everything), configurable
   lifecycle categories, milestone annotations, and a null-`upstream_repo`
   path for trackers whose fixes land across multiple repos.
-- Skill: `security-tracker-stats-dashboard` — invokes the tool, surfaces
-  the output path, and handles staleness detection (~24 h default). Reads
-  only; never posts to the tracker.
+- Skill: `security-tracker-stats-dashboard`
+  (`plugins/magpie-security/skills/tracker-stats-dashboard/SKILL.md`,
+  behind the `skills/security-tracker-stats-dashboard` symlink) — invokes
+  the tool, surfaces the output path, and handles staleness detection
+  (~24 h default). Reads only; never posts to the tracker.
+- Adopter config: `<project-config>/security-tracker-stats.md`, scaffolded
+  from `plugins/magpie-setup/templates/security-tracker-stats.md` (#1410);
+  the skill declares it, with `project.md` and `scope-labels.md`, in
+  `requires_config:`.
 
 ## Behaviour & contract
 
@@ -50,6 +56,21 @@ health without navigating the tracker issue-by-issue.
   per-issue event cache is trusted only when it was written after that
   issue's `updatedAt`; an issue relabelled since the cache was written is
   refetched rather than silently served its stale label history.
+  The skill's freshness check and the fetch use the same cache directory:
+  the configured `tracker_stats_cache` value, else `$TRACKER_STATS_CACHE`,
+  else the fetch scripts' default; before #1444 the skill ignored the
+  configured value, so it could judge freshness from a directory the
+  fetch never wrote.
+- **One list call, not one read per issue (#1443).**
+  `fetch_issues.py` requests `body` and `closedByPullRequestsReferences`
+  in its `gh issue list --state all --limit 1000` call, and
+  `fetch_bodies.py` copies them from `issues.json` into
+  `issue_extra.json`; a per-issue `gh issue view` runs only as a fallback
+  for an issue whose list entry lacks the fields, such as an
+  `issues.json` written before the change.
+  When the list returns 1000 issues, `fetch_issues.py` warns that it hit
+  the cap, that older issues are missing, and that every count in the
+  dashboard is a floor.
 - **Config-driven.** Lifecycle category bands, time-to-triage signal,
   milestone vertical annotations, and the null-`upstream_repo` path are
   declared in the tool's `default-config.yaml` and overridden per-adopter.
diff --git a/tools/spec-loop/specs/skill-reconciler.md b/tools/spec-loop/specs/skill-reconciler.md
index e94a209db..d7e3d3109 100644
--- a/tools/spec-loop/specs/skill-reconciler.md
+++ b/tools/spec-loop/specs/skill-reconciler.md
@@ -15,8 +15,8 @@ source: >
   safety baseline that must stay eventually-consistent across every copy.
   meta-and-quality-tooling.md (the skill-authoring/quality family this
   joins). Skill ships experimental in
-  .agents/skills/magpie-skill-reconciler/ with an eval suite under
-  tools/skill-evals/evals/skill-reconciler/.
+  plugins/magpie-utilities/skills/skill-reconciler/ with an eval suite
+  under tools/skill-evals/evals/skill-reconciler/.
 acceptance:
   - The reconciler is read-only: it produces a structured diff and a
     reconciliation proposal; it never rewrites either skill without human
@@ -54,15 +54,23 @@ that a maintainer should not ignore.
 
 ## Where it lives
 
-- Skill: `skill-reconciler` at `.agents/skills/magpie-skill-reconciler/`,
-  in the meta / quality family with `write-skill`, `optimize-skill`, and
-  `list-skills` (see [meta-and-quality-tooling.md](meta-and-quality-tooling.md)).
+- Skill: `skill-reconciler` at
+  `plugins/magpie-utilities/skills/skill-reconciler/` (reached as
+  `skills/skill-reconciler/` and, through the self-adoption symlinks,
+  `.agents/skills/magpie-skill-reconciler/`), in the utilities family
+  (`mode: Meta`) with `write-skill`, `optimize-skill`, and `list-skills`
+  (see [meta-and-quality-tooling.md](meta-and-quality-tooling.md)).
   Eval suite under `tools/skill-evals/evals/skill-reconciler/`.
-- Optional deterministic helper (not yet built): a `uv` tool under `tools/`
-  that does the structural diff (frontmatter, section headings,
-  step-by-step decision rules, placeholder inventory) so the skill
-  reasons over a normalised diff rather than raw text. Follows the
-  tool-backs-skill pattern already used across the catalogue.
+- `safety-baseline-checklist.md` beside the skill: the three
+  safety-baseline clauses, each with what must be present, what counts as
+  a failure, and canonical wording. The skill's SAFETY-BASELINE class
+  points at it as the ground-truth definition.
+- Deterministic helper: `tools/skill-reconciler-diff/`, a stdlib-only `uv`
+  tool (`substrate:framework-dev`) that parses two skill trees into a
+  normalised JSON diff (frontmatter, section headings, step inventory,
+  placeholder inventory, support files, and per-clause safety-baseline
+  presence, detected by regex against the checklist's three clauses).
+  Follows the tool-backs-skill pattern used across the catalogue.
 - Inputs: two `SKILL.md` trees (plus their supporting `.md` files),
   identified by path or by `source` tag.
 - It reads the safety-baseline definition from the same place the rest of
@@ -125,12 +133,12 @@ uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/skill-reco
 
 ## Known gaps
 
-- **Safety-baseline definition is prose, not machine-readable.** The
-  shipped reconciler checks for injection-guard, collaborator-trust, and
-  confidentiality-posture clauses by recognising their prose patterns; a
-  future improvement is to extract those three clauses into a single
-  authoritative checklist file the skill and a deterministic linter can
-  both reference.
+- **Safety-baseline definition is a single file, but still prose.** The
+  three clauses now live in one authoritative
+  `safety-baseline-checklist.md` that both the skill and
+  `tools/skill-reconciler-diff` reference. Detection remains pattern
+  recognition over prose: the helper's regexes are hard-coded in the tool
+  rather than read from the checklist, so the two can drift apart.
 - **`capability`-tag auto-pairing shipped; `source`-tag registry not yet used.**
   `--discover <skills-dir>` now groups by `capability:` frontmatter and
   presents a bounded candidate list. The MISSION vision of a registry query
@@ -142,7 +150,7 @@ uv run --project tools/skill-evals skill-eval tools/skill-evals/evals/skill-reco
   step inventory, placeholder inventory, support files, and
   safety-baseline clause presence) and emits a JSON object.  It is
   intended to be used as an optional Step 1 enhancement to the
-  `skill-reconciler` skill (the skill does not yet wire it in — that
-  reference lands separately); 31 unit tests cover frontmatter-only, section-order,
-  placeholder, support-file, and safety-baseline divergences.  No
-  remaining tooling gap for the structural-diff item.
+  `skill-reconciler` skill, but the skill still does not wire it in:
+  `SKILL.md` never names `skill-reconciler-diff`. Its unit tests cover
+  frontmatter-only, section-order, placeholder, support-file, and
+  safety-baseline divergences.
diff --git a/tools/spec-loop/specs/spec-gap-staleness.md b/tools/spec-loop/specs/spec-gap-staleness.md
index 01a936caf..580da7e00 100644
--- a/tools/spec-loop/specs/spec-gap-staleness.md
+++ b/tools/spec-loop/specs/spec-gap-staleness.md
@@ -198,14 +198,13 @@ check that presumes an answer will be argued with rather than fixed.
 6. Every check has unit tests covering the firing case, the clean case,
    and the skip case.
 7. Running the validator on the live tree reproduces the known
-   repo-health family discrepancy, which is three-way rather than
-   two-way: `triage-mode.md` claims five skills,
-   `repo-health-family.md` claims six, and seven carry
-   `family: repo-health` in frontmatter. The seventh,
-   `audit-finding-fix`, appears in neither prose list — plausibly
-   because it fixes findings rather than producing them. The check
-   must report all three numbers and name the disputed skill, not
-   pick a winner.
+   repo-health family discrepancy. When this spec was written it was
+   three-way (`triage-mode.md` claimed five skills,
+   `repo-health-family.md` six); both specs now claim six, while seven
+   `SKILL.md` files carry `family: repo-health` in frontmatter. The
+   seventh, `audit-finding-fix`, appears in neither prose list, plausibly
+   because it fixes findings rather than producing them. The check must
+   report both numbers and name the disputed skill, not pick a winner.
 
 ## Validation
 
@@ -220,6 +219,11 @@ test -f tools/spec-loop/PROMPT_update.md
 
 - **Not yet built.** Both prompt edits and both validator checks are
   proposed here; nothing has shipped.
+  Re-verified at the 2026-09-28 sync: `tools/spec-validator` defines no
+  `validate_gap_predicates` or `validate_cross_spec_counts`, neither
+  `PROMPT_plan.md` nor `PROMPT_update.md` states the evidence rule, and the
+  only `gap-closes-when` comments in the spec tree are the examples in
+  this file.
   <!-- gap-closes-when: symbol-called:tools/spec-validator::validate_gap_predicates -->
 - **The existing bullets need a one-off backfill.** Nine bullets across
   eight specs describe shipped capabilities, and eleven more are
@@ -231,7 +235,9 @@ test -f tools/spec-loop/PROMPT_update.md
   acceptance criterion 7 requires it to fire on a violation that exists
   in the tree today, so landing it before the repo-health counts are
   reconciled turns main red for everyone. Reconcile first, then land
-  the HARD check.
+  the HARD check. The spec-to-spec half of the disagreement has since
+  closed (both specs say six); the prose-to-frontmatter half, six against
+  seven, is still open.
 - **A predicate can drift from its bullet.** Nothing binds the comment
   to the prose above it, so an edit that rewrites a bullet without
   updating its predicate leaves a check that passes while describing
diff --git a/tools/spec-loop/specs/spec-loop-runner.md b/tools/spec-loop/specs/spec-loop-runner.md
index 31fdf9ef9..aedfcab92 100644
--- a/tools/spec-loop/specs/spec-loop-runner.md
+++ b/tools/spec-loop/specs/spec-loop-runner.md
@@ -55,6 +55,9 @@ and never opens a pull request.
 - `tools/spec-loop/PROMPT_update.md` — spec back-fill prompt for
   functionality that landed outside the loop.
 - `tools/spec-loop/PROMPT_consolidate.md` — plan-size reduction prompt.
+- `tools/spec-inventory/` — `spec-inventory --brief` supplies the compact
+  repository inventory appended to every prompt, and `spec-scope` maps
+  changed paths to the specs whose *Where it lives* sections name them.
 - `tools/spec-loop/AGENTS.md` — loop-specific operational context:
   repository map, validation commands, branch rules, hard limits, and
   commit rules.
@@ -90,6 +93,12 @@ and never opens a pull request.
   incremental-scope guidance, then amends or creates a marker commit after
   the agent finishes. Prompts must not instruct the agent to edit the
   marker.
+- **Deterministic scope mapping.** When `.last-sync` names a previous sync,
+  the runner lists the paths changed since it
+  (`git diff --name-only <prev>..<BASE_HEAD> -- .claude/skills tools docs/modes.md`),
+  pipes them through `spec-scope`, and appends the specs it returns as
+  likely relevant. The mapping is advisory: a `spec-scope` failure is
+  silently skipped and the agent still reads the raw path list.
 - **Plan-size hysteresis.** Build mode switches to one consolidate pass
   when `IMPLEMENTATION_PLAN.md` exceeds `SPEC_LOOP_PLAN_MAX`, then builds
   even if planned work alone keeps the file over the threshold. The latch
@@ -180,5 +189,13 @@ uv run --project tools/spec-validator --group dev spec-validate
 - The non-Claude harnesses rely on external policy/config plus the OS
   sandbox for push/PR denial; only Claude has a per-invocation hard-deny
   flag in the current runner.
-- The update beat's incremental-scope mapping is path-based; it does not
-  yet map changed files to likely spec topics with a deterministic helper.
+- The deterministic scope helper this bullet used to call missing has
+  shipped: `loop.sh` pipes the incremental diff through
+  `tools/spec-inventory`'s `spec-scope`.
+- The incremental diff's pathspec (`.claude/skills tools docs/modes.md`)
+  no longer covers where skills live. `.claude/skills/magpie-<name>` entries
+  are symlinks (through `.agents/skills/`) into
+  `plugins/magpie-<family>/skills/<alias>/`, so an edit to a skill's content
+  changes nothing under `.claude/skills` and drops out of the scoped list;
+  so do `plugins/magpie-setup/templates/`, `.github/`, `projects/`, and every
+  `docs/` page other than `docs/modes.md`.
diff --git a/tools/spec-loop/specs/triage-mode.md b/tools/spec-loop/specs/triage-mode.md
index 8a7b94636..781c5b511 100644
--- a/tools/spec-loop/specs/triage-mode.md
+++ b/tools/spec-loop/specs/triage-mode.md
@@ -7,8 +7,10 @@ status: experimental
 kind: feature
 mode: Triage
 source: >
-  MISSION.md § Technical scope (Triage). docs/modes.md § Triage.
-  Implemented by the pr-management, issue, and security skill families.
+  MISSION.md § Technical scope (Triage). docs/modes.md § Triage
+  (38 skills). Implemented by the pr-management, issue, security,
+  contributor-growth, repo-health, and release-management skill
+  families.
 acceptance:
   - Every triage skill is read-only on tracker state or proposes-then-
     confirms; none transitions, closes, or labels without confirmation.
@@ -32,7 +34,11 @@ suggestion the human signs off on.
 - PR queue: `pr-management-triage`, `pr-management-stats`,
   `pr-management-code-review` (deep review is a triage variant),
   `pr-management-quick-merge` (read-only express-lane surfacing of
-  trivial, low-risk PRs a maintainer can review in seconds).
+  trivial, low-risk PRs a maintainer can review in seconds),
+  `pr-stale-sweep` (inactivity nudge or pre-close notice for PRs,
+  skipping maintainer-court and ready-labelled PRs), and
+  `reviewer-routing` (roster-bounded reviewer suggestion; see
+  [reviewer-routing.md](reviewer-routing.md)).
   Reference implementation: `tools/pr-management-stats/`.
 - General issues: `issue-triage`, `issue-reassess`, `issue-reproducer`,
   `issue-stale-sweep` (configurable inactivity sweep: nudge or
@@ -44,13 +50,27 @@ suggestion the human signs off on.
   `issue-backlog-stats` (read-only maintainer dashboard over the open
   general-issue backlog — health rating, age/staleness, area pressure,
   triage funnel).
-- Contributor readiness: `contributor-nomination` (read-only brief for a
-  named contributor — activity breadth, consistency, and nomination-
-  evidence prose for a committer or PMC thread);
+- Contributor readiness (the `mode: Triage` members of the
+  contributor-growth family; see
+  [contributor-growth.md](contributor-growth.md)):
+  `contributor-nomination` (read-only brief for a named contributor —
+  activity breadth, consistency, and nomination-evidence prose for a
+  committer or PMC thread);
   `contributor-activity-sweep` (read-only GitHub activity card for a
   named contributor over a configurable window);
-  `committer-onboarding` (post-vote ICLA/account/permissions/welcome
-  checklist for committer and PMC promotions).
+  `contributor-calibrate` (threshold floors derived from past nomination
+  decisions, behind the privacy-LLM gate; numbers-only config diff);
+  `contributor-candidate-screen` (screens recent contributors against
+  the floors and writes a per-candidate report to a verified-private
+  repository);
+  `contributor-identity-map` (GitHub handle to chat, mailing-list, and
+  social identities, recording only maintainer-confirmed mappings);
+  `contributor-sentiment` (sentiment-signal gate report for
+  `experimental` to `stable` advancement).
+  `committer-onboarding` (post-vote checklist) belongs to the same
+  family but carries `mode: Meta`.
+  Counting is deterministic through `tools/contributor-metrics`; chat
+  evidence is read through `tools/chat` (`contract:chat`).
 - Security inbound: `security-issue-import`, `-import-from-pr`,
   `-import-from-md`, `-import-from-scan` (triage-first scanner-output
   import via pluggable scan-format adapters),
@@ -59,9 +79,17 @@ suggestion the human signs off on.
   `security-issue-triage` (batch-triage open tracker issues carrying
   `needs triage`), `security-issue-deduplicate`,
   `security-issue-invalidate`, `security-issue-sync`,
-  `security-cve-allocate`.
+  `security-cve-allocate`, and `security-model-verify` (pre-flight on a
+  published security model).
+- Repo-health audits (see [repo-health-family.md](repo-health-family.md))
+  and the four read-only `release-*` skills (`release-verify-rc`,
+  `release-vote-tally`, `release-archive-sweep`,
+  `release-audit-report`; see
+  [release-management-lifecycle.md](release-management-lifecycle.md))
+  are also catalogued under Triage in `docs/modes.md`.
 - Adapters it reads through: `tools/github`, `tools/jira`,
-  `tools/ponymail`, `tools/gmail`, `tools/mail-source`.
+  `tools/ponymail`, `tools/gmail`, `tools/mail-source`,
+  `tools/contributor-metrics`, `tools/chat`.
 
 ## Behaviour & contract
 
@@ -103,14 +131,12 @@ uv run --project tools/skill-and-tool-validator --group dev skill-and-tool-valid
   (`experimental`); `issue-stale-sweep` provides stale-handling /
   close-proposal. No adopter-pilot eval has run on the general-issue
   family yet, so behaviour may change.
-- **The contributor-growth skills span the path but are not yet a named
-  family.** `contributor-nomination`, `contributor-activity-sweep`,
-  `committer-onboarding`, and `good-first-issue-author` (Agentic Mentoring) are
-  now all catalogued in the specs. Missing members of the
-  contributor-to-committer path: PMC-member nomination (distinct from
-  committer), emeritus / inactive-committer handling, and contributor
-  offboarding. Worth deciding whether this becomes a named family with
-  its own spec.
+- **The contributor-growth skills are now a named family.** They ship
+  as the `magpie-contributor-growth` plugin (with three Mentoring
+  members in `magpie-mentoring`) and have their own spec,
+  [contributor-growth.md](contributor-growth.md), which tracks the
+  remaining gaps: PMC-member nomination (distinct from committer),
+  emeritus / inactive-committer handling, and contributor offboarding.
 - **Repo-health audits are now a six-skill family — feature-complete.**
   `ci-runner-audit`, `workflow-security-audit` (zizmor-backed),
   `dependency-audit`, `license-compliance-audit`, `flaky-test-triage`, and
diff --git a/tools/spec-loop/specs/vetted-command-surface.md b/tools/spec-loop/specs/vetted-command-surface.md
index 82aca6453..dd29a933c 100644
--- a/tools/spec-loop/specs/vetted-command-surface.md
+++ b/tools/spec-loop/specs/vetted-command-surface.md
@@ -53,6 +53,13 @@ cve.org check, invoke it through the same `uv run --project
 <framework>/tools/vetted-ops vetted-op-read …` spelling every permission rule
 and sandbox exclusion names — a bare `vetted-op-read` would miss the
 allowlist and prompt or run sandboxed (#1339).
+Two spellings are recognised, and each is both allowed and excluded from the
+sandbox: `uv run --project … vetted-op-read` and `uvx --from … vetted-op-read`,
+the form the read-only gatherer agents use (#1393). Before #1393 only the
+`uv run --project` form was excluded and neither was allowed, so every
+gatherer read prompted. The adopter install now carries these read `allow`
+entries into the settings merge and the update skill diffs them; `vetted-op`
+(writes) stays on `ask`.
 
 The `procedure` backend carries the tracker read-modify-write updates that
 `tools/github-rollup` and `tools/github-body-field` do outside the sandbox:
@@ -66,6 +73,25 @@ read), with bodies on stdin and no `@file` fields. An operation declared
 read-only gets a runner that refuses every write. The parsing and composing
 modules are vendored byte-for-byte from the two tools, with a test that fails
 on drift, because the dispatcher installs without them.
+The runner also refuses a `gh api` call that names its own repo or host, a
+path that traverses, a method other than `GET`, `PATCH` or `DELETE`, and a
+`gh issue --body-file` other than `-`, so no procedure makes `gh` read a local
+file.
+The dispatcher refuses a plan bound to any repository other than the policy's
+tracker.
+`rollup-amend-latest` refuses when the latest entry carries a different action,
+and `rollup-fold` refuses the rollup comment itself or a comment that belongs
+to another issue, and deletes the folded comment only after the append
+succeeded.
+Skills write with `vetted-op-tracker --caller <skill> rollup-append|rollup-amend-latest|rollup-fold|body-field-set …`
+and read a field with `vetted-op-read --caller <skill> body-field-get …`;
+the `github-rollup` and `github-body-field` uv CLIs remain for use outside the
+sandbox (#1448).
+On stdout, `body-field-get` prints the one value and `rollup-append` /
+`rollup-amend-latest` print the rollup comment's URL (`…#issuecomment-<id>`),
+so a caller can link to the entry without reading the rollup (#1451).
+The security skills are the first callers (#1451), and the policy example
+grants each security caller exactly the tracker operations it uses.
 
 A third entry point, `vetted-op-tracker`, refuses every operation except the
 procedure ones before it reads the policy — the same shape as
@@ -88,6 +114,15 @@ session, and it is `Edit`-denied alongside the catalogue. A `*` in place of the
 version would also match spaces, approving a command with extra `uv` options
 spliced in at that position; sandbox-lint rejects any Bash `allow` rule with a
 `*` before its end.
+The hook (`tools/vetted-ops/hooks/link-stable-path.sh`) only ever replaces a
+symlink: a real file or directory at the path is left alone and reported. The
+isolated-setup update and verify skills report a leftover versioned glob as
+must-fix (#1406).
+Under `permissions.blockReadsOutsideWorkingDirectories`, reads of the fixed
+path would prompt every time, so `sandbox-add-project-root.sh` lists
+`$HOME/.claude/magpie`, resolved, as a working directory in each worktree's
+`settings.local.json` (#1418; see
+[`agent-isolation-sandbox.md`](agent-isolation-sandbox.md)).
 
 ## Scoping — what is real and what is aspiration