[potiuk]

Summary

• Every security skill works for a maintainer who installed Magpie for themselves, without the project adopting it. Pre-flight already resolved requires_config from the personal layer, but two tools only looked in the committed .apache-magpie-overrides/: vetted-ops (every tracker operation) and generate-cve-json (CVE JSON in cve-allocate, issue-sync, issue-deduplicate). Both now fall back to the personal layer (<git-common-dir>/apache-magpie/tools/…, legacy .apache-magpie-local/), committed first. setup config gains a step that drafts both for an unadopted project.
• The personal vetted-ops policy is protected like the committed one. New required permissions.deny rules (//**/.git/**/apache-magpie/tools/vetted-ops/**, .svn/…, .apache-magpie-local/…), merged into the sandbox write-deny; vetted-ops reads a personal policy only in those protected shapes, and never through a symlink. The agent cannot write it — the user saves it from the draft.
• Marketplace installs get the tools. magpie-security shipped only skills/, so <framework>/tools/<tool> did not exist without a framework checkout. New substrate plugin magpie-security-tools carries the tools the security skills run (packaged pyprojects drop the workspace-only dev group and point inter-tool deps at sibling copies). Its session hook materialises a writable copy per version at ~/.cache/apache-magpie/framework/<version> with current → it, so <framework> = ~/.cache/apache-magpie/framework/current and the skills' uv run --project <framework>/tools/<tool> … works unchanged (as does uvx --from). Setup installs it with magpie-security; pre-flight and upgrade name it when missing; Codex catalog included.
• Wording: the <project-config> placeholder no longer claims to be the snapshot; user.md reads use the documented resolution order, and issue-fix never offers to save personal data into the committed overrides.

Type of change

• Skill change (setup, isolated-setup-*, security skills' wording)
• Python package (tools/vetted-ops, tools/cve-tool-vulnogram/generate-cve-json, tools/sandbox-lint, tools/security-management, tools/setup-preflight)
• Cross-cutting (sandbox deny rules, AGENTS.md <framework>)
• CI / dev loop (check-family-plugins.py packaging, hook filter, plugins/pyproject.toml exclusions)
• Documentation

Test plan

• prek run on every changed file passes
• New tests: personal-layer policy lookup (committed wins, submodule, custom gitdir refused, symlinked layer refused), personal CVE-JSON config, packaged pyproject rewrite, tool coverage of the plugin, the framework-copy hook (writable, follows upgrades, concurrent starts, stale-lock recovery), the companion floor check
• All packaged tools run with uv run --project, uv run --directory and uvx --from from a read-only copy of the plugin
• Several rounds of roborev review, findings fixed

RFC-AI-0004 compliance

• HITL — a personal policy is drafted, never written by the agent
• Sandbox — new deny rules; the writable framework copy holds only tools that run sandboxed
• Vendor neutrality — unchanged

Notes for reviewers

• Not covered here: issue-invalidate's canned-response links point into the tracker repo, so a solo user's posted link can be dead; local-tracker custom parsers still read only the committed directory.

---

Gen-AI disclosure: drafted with Claude Code (Opus 5); reviewed by the submitter.

🤖 Generated with Claude Code