Adopt Apache Magpie 0.1.0 with project overrides

[Aman-Mittal]

Implements #228.

Adopts Apache Magpie 0.1.0. Nothing runs on its own — no workflow, no schedule, no bot. A maintainer invokes a skill, reviews the output, and decides.

Verified supply chain

Installed from the signed ASF release rather than a git clone:

sha512sum -c  → apache-magpie-0.1.0-source.zip: OK
gpg --verify  → Good signature from "Jarek Potiuk (apache) <potiuk@apache.org>"

The signing key is published in the project's own KEYS file. .apache-magpie.lock records the SHA-512, so any later re-fetch is verified against the same value, and a change to url/ref/sha512 is reviewed as a supply-chain change.

The upstream install recipes are stale on two points: they describe the released-zip method as "not yet available; use Method 3" and name the artefact -source-release.zip. 0.1.0 shipped on 2026-08-03 as apache-magpie-0.1.0-source.zip. Worth an upstream doc PR.

Committed footprint

Path	Tracked	Purpose
.apache-magpie.lock	yes	The version pin
.agents/skills/magpie-setup/	yes	Bootstrap, so a fresh clone can restore the rest
.claude/skills/…, .github/skills/…	yes	Relay symlinks (mode 120000), not copies
.apache-magpie-overrides/	yes	This project's instructions to the skills
.apache-magpie/	no	Framework snapshot — a build artefact

The framework never enters the repository's history. Contributors who do not use it are unaffected: no npm dependency, no build step, nothing to install.

Vendor and model neutrality

Structural, not aspirational. Skills live in .agents/skills/ — the canonical path read by Codex, Cursor, Gemini CLI, Copilot, OpenCode, Cline, Zed and Warp — with per-tool directories as relay symlinks into it, so there is no separate installation per tool and no default runtime.

No model vendor, provider or runtime is named anywhere in the committed overrides; they are written against capabilities, not any client's tool names or output format. Anything requiring a paid subscription belongs in the gitignored .apache-magpie-local/, so participation never depends on one contributor's account.

The overrides are the substance

Generic recipes would ask for things this project deliberately does not do — explicit OnPush (already the v22 default), a facade over the generated client (rejected in ADR-0001), assigning issues (committer-only here) — and, more importantly, would trust this repository's own checks.

That trust is not warranted. Three separate mechanisms have reported success while testing nothing: npm run test ran 2 specs instead of 775 and exited 0; Karma prints TOTAL: n SUCCESS after a bundle failure; the API drift manifest matched only single-line calls and quietly covered less on each regeneration.

So every override asks for evidence that would fail if the claim were false.

Override	Encodes
pr-management-code-review	Four upgradability axes; OnPush-is-already-default; the object-in-a-signal trap; the adapter boundary and shrink-only suppressions baseline; wire-format rules that fail at runtime and never at compile time
workflow-security-audit	ASF Actions policy (only apache/*, github/*, actions/* unreviewed; SHA pins otherwise); untrusted-input paths; build-time-authored config.json as a credential-routing decision
dependency-audit	Generated-client carve-out; the scheduled spec sync as a supply-chain input; the positional-argument hazard it creates; runtime vs build-time exposure
issue-triage	Label vocabulary; the Business Value requirement; symptom-vs-cause evidence bar; never assign
good-first-issue-author	Scoping so nothing blocks; verified worked example; not-a-good-first-issue if it needs a live platform to verify
pairing-self-review	Check the count, not the word; verify wire behaviour against a running platform

Concrete example of what the code-review override catches — all of these compiled cleanly, passed lint and passed the unit suite:

• an unpadded day returning 500 rather than a validation error;
• an empty string rejected as a value where the field was meant to be omitted;
• a list endpoint answering 204 for every query, so the screen was always empty;
• a summary endpoint answering 200 with all totals zeroed because a query parameter was missing.

The security override also captures that allowedApiOrigins entries are offered to users as selectable login endpoints, so whatever they name receives the user's credentials — widening that list is a security change, not configuration.

Repository hygiene

• ASF headers on every new file — scripts/check-license.sh passes.
• Vendored upstream source excluded from RAT and Prettier; reformatting it would create diff noise against every framework upgrade.
• npm run format:check and npm run lint clean. No application code is touched, so build and test behaviour is unchanged.

Scope enabled

setup + utilities (always on), issue, pr-management, repo-health.

Deliberately not enabled: security (needs a PMC decision — it handles reports before they are public), release-management (this project does not cut releases on that cadence), mentoring / contributor-growth (revisit with steadier newcomer traffic). pairing has an override ready and can be enabled per-contributor locally.

repo-health is the intended first trial: this repository already runs Apache RAT, licence compliance, dependency integrity, zizmor and CodeQL, so its audits should largely agree with checks already trusted — a low-risk way to confirm the framework behaves sensibly here before leaning on it for triage.