docs(projects): add Magpie's own pr-management-code-review criteria

[potiuk]

Summary

• pr-management-code-review resolves its rule sources from <project-config>/pr-management-code-review-criteria.md, but Magpie — which self-adopts the framework — never carried that file. Only projects/_template/ had it, so running the skill against apache/magpie silently fell back to a smaller default rule set instead of the project's own rules.
• Adds projects/magpie/pr-management-code-review-criteria.md as a navigation map, not a rule set: every row points at a section that already exists in AGENTS.md, PRINCIPLES.md, CONTRIBUTING.md, or docs/editorial-guidelines.md. No rule text is duplicated and nothing moves out of AGENTS.md — per the framework's own guidance that summaries drift while links don't.
• Found while running a review pass over the open-PR queue: the skill warned that the adopter config was missing and fell back to defaults for all seven PRs reviewed.

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other: adopter config under projects/magpie/ (the live config, not the template)

Test plan

• prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes — no Python touched
• For Groovy bridges touched: command-line invocation tested end-to-end — n/a
• For skill changes: eval suite passes for the affected skill — no skill logic changed; this is config the skill reads
• For skill behaviour changes: a new or updated eval fixture is included — no behaviour change; see note below
• Other: every link and #anchor in the new file is verified by the lychee and markdownlint (MD051) hooks — this was the main correctness risk, since the file is almost entirely cross-references into AGENTS.md and PRINCIPLES.md anchors.

RFC-AI-0004 compliance

• HITL — any new mutation is gated on explicit user confirmation
• Sandbox — no new unrestricted host access; network reach declared in the adapter
• Vendor neutrality — this file is where concrete Magpie values are supposed to live, per PRINCIPLES §12 ("the framework is project-agnostic; concrete names live in adopter config"). It moves nothing concrete into the framework.
• Conversational + correctable — the file is adopter config, so a project can tune its own review criteria map without touching framework code.
• Write-access discipline — no autonomous outbound messages; drafts only, sent on confirmation
• Privacy LLM — private content does not reach a non-approved LLM; redactor invoked where needed

Linked issues

None — the gap was found during a review session rather than reported. Happy to file a tracking issue retroactively if that's preferred.

Notes for reviewers (optional)

Three notes worth a second opinion:

1. Two canonical categories have no row. Database / query correctness and UI (React/TypeScript) don't apply — Magpie ships neither, so a finding in either would be a mis-classification rather than something to link. Worth knowing the trade-off: criteria.md says a category with no anchor row makes the skill "fall back to a plain reference and surface the missing anchor as a one-line warning at the top of the review". If that warning turns out to be noisy in practice, the fix belongs in the framework — the skill arguably shouldn't warn about categories an adopter has deliberately declined — rather than in this file.

2. Navigation map vs. moving text out of AGENTS.md. I read the intent as "point at the criteria that already exist" rather than "relocate them", since the template calls this file a navigation map and criteria.md explicitly says to link rather than summarise. AGENTS.md is unchanged. If you'd rather the review-specific rules physically moved here, that's a different (larger) refactor and I'd do it separately.

3. Anchor targets for the vaguer categories. Code quality → AGENTS.md#before-submitting and API correctness → AGENTS.md#reusable-skills are the best fits I found, but they're the two I'm least sure about; Magpie has no standalone review-instructions doc to anchor into. Architecture-boundary and generated-file findings route to the numbered PRINCIPLES entries (§12, §13), which I'm confident about.

Also adds a Magpie-specific anchor block for categories this repo's reviews actually need but the canonical list doesn't have: placeholder convention, external-content-as-data, privacy-LLM routing, labelling, vendor neutrality, and the inline-comment review default.