feat(security): add security-model prepare / verify / update skills

[potiuk]

Summary

• The security family routes inbound reports against a project's security model,
  but had no skills for producing or maintaining that model. Three skills close the
  loop: draft a first model and land it, pre-flight an existing one, and read the
  accrued triage decisions back into it.
• The rubric for what a model contains is referenced by URL from
  alpha-omega-security/threat-model
  rather than vendored. A second copy of a specification is a second specification;
  what the framework owns is the workflow around it — consent, the discoverability
  chain, PR mechanics, confidentiality scrubbing, and the feedback loop.
• Generalised from the ASF security team's own model-preparation workflow: PMC
  vocabulary is gone, replaced by <governance-body> / <upstream> /
  <project-config>, and the ASF-specific license header and apache/ repo prefix
  in the PR helper are now flags.

Skill	Mode	What it does
security-model-prepare	Drafting	Draft-first production of a first model; lands it plus the AGENTS.md → SECURITY.md chain as one PR per repository. Consent on the private list before the first repository write.
security-model-verify	Triage	Per-repository pre-flight. Discoverability is the only hard gate; completeness is graded, and every gap is a proposal. Mechanical gaps get a PR, substantive ones a private mail.
security-model-update	Drafting	Reads closed trackers, reporter threads and canned responses back into the model — known-non-finding entries plus a model-gap list.

The parts worth reviewing closely

security-model-update is fenced deliberately. Known non-findings sit first
in the model's disposition precedence and are fed to automated triagers verbatim as
a negative prompt, so a loose entry suppresses a whole class of reports ahead of
every other safeguard. The rules that follow from that:

• Only a recurring BY-DESIGN: property-disclaimed close feeds the section. No
  OUT-OF-MODEL:* route is ever promoted — those sit below it in the precedence
  order, so relabelling one lifts it above the checks that decided it.
• Report quality (no reproducer, reachability not demonstrated) is forbidden as
  a match condition. An unreproduced report stays open pending a reproducer.
• The discharging claim must exist in the model and cover the entry's component.
• The regression check is blocking: the proposed model is re-run against every
  historically fixed report, and one that would now close does not ship. Narrowing
  is the only permitted resolution — never widening.

Why mail and not a public issue for substantive findings: many projects have no
usable public tracker; a public list of a project's threat-model gaps is an
inventory a hostile researcher would mine; and maintainers who read mail may never
see a tracker notification. PRs are the exception — they need a repo write anyway
and carry no inventory.

Type of change

• Skill change — eval fixtures included (35 cases, 7 steps)
• Cross-cutting (security threat model: STRIDE family F, mitigations M.30–M.36)
• Documentation (docs/security/security-model-preparation.md, modes,
  capabilities, mode-economics, marketplaces)
• Project template (projects/_template/security-model.md)
• Other: new spec tools/spec-loop/specs/security-model-preparation.md;
  helper script + tests under skills/security-model-verify/

Test plan

• prek passes on every changed file (doctoc, SPDX, markdownlint, typos,
  lychee, check-placeholders, symlink-lint, check-family-plugins,
  skill-and-tool-validate, spec-validate)
• skill-and-tool-validate clean — no violations, and the eval-coverage
  advisory is cleared for all three skills
• Workspace checks: ruff 29/29 members, mypy 26/26, pytest 32/32 — including
  25 new unit tests on the PR helper's create-or-append merge core
• Eval suites pass 35/35 (--cli "claude -p"): verify 11/11,
  prepare 9/9, update 15/15 — 0 failed, 0 manual, 0 errored
• vendor-neutrality-score --in-place regenerated: 74/74 skills, 0
  vendor-coupled

Caveat on the eval numbers: that was a self-eval — the authoring model grading
its own fixtures. Per AGENTS.md that is a smoke test for the cheap failure class,
not independent evidence. A cross-model pass is worth running before merge.

RFC-AI-0004 compliance

• HITL — every external write is shown and approved first; PRs open via
  gh pr create --web; security-model-update is read-only on the tracker
• Sandbox — the helper is stdlib-only and reaches only git / gh
• Vendor neutrality — check-placeholders passes; the ASF-specific header
  and repo prefix are now flags with neutral defaults
• Write-access discipline — drafts only; consent gate before the first
  repository write on a project you do not maintain
• Privacy LLM — the update loop's scrub step runs before display, not
  before send

Notes for reviewers

Three things I'd flag rather than bury:

1. I widened one taxonomy definition. capability:authoring was "skills that
   author or maintain other skills"; it now also covers the project's own security
   model. The alternative was mislabelling these as fix or resolve. Happy to
   add a new capability instead if you'd prefer the old definition held.
2. STRIDE family F was scope I added. docs/security/threat-model.md is
   release-blocking and says each new Drafting skill ships with its own row, so
   leaving "the twelve skills" stale would have been a defect. It is a
   security-review artefact and wants a real read, not my say-so.
3. tools/spec-loop/.last-sync is 12 commits behind main — pre-existing, not
   from this PR. I added a spec for this change but deliberately did not bump
   .last-sync, since that would falsely claim those 12 commits are spec-synced.
   Worth a companion sync PR.

Not included: eval coverage for the composition steps (PR body, mail body). Those
are prose and would need structural fixtures.

🤖 Generated with Claude Code

https://claude.ai/code/session_01So3JRGXrbqSGrohtZuHWKg

[potiuk]

ported from the security scans.