Adopt Apache Magpie for agent-assisted triage and maintenance

## Requirement

Adopt [Apache Magpie](https://magpie.apache.org/) ([apache/magpie](https://github.com/apache/magpie)) in this repository. Magpie became an ASF Top-Level Project on 29 June 2026. It is a curated set of agent recipes for the repetitive parts of running a project — issue and PR triage, contributor mentoring, fix drafting, security-report handling — with human review kept in the loop throughout.

This is a requirement for the project, not an open question. What remains open is *scope and sequencing*, tracked in the checklist below.

**Status: implementation open in #241**, pinning the signed **0.1.0** release with project overrides.

## Business value

This repository is young, moving quickly, and has a small number of people doing the maintenance. The cost of that shows up in specific, recurring places:

- **Triage backlog.** Issues arrive faster than they get labelled, scoped and routed. Newcomer-sized work in particular tends to sit unlabelled, which is exactly the work that most needs to be findable.
- **Newcomer onboarding.** Getting a first-time contributor productive here means explaining an Angular 22 signal-based codebase, an adapter boundary, a generated API client that must not be hand-edited, and an e2e suite split between mocked and real-backend projects. That explanation is currently repeated by hand each time.
- **Review load.** Reviewers spend attention on mechanical checks — conventions, missing tests, missing translations — before reaching the parts that actually need judgement.

Magpie targets each of these directly, and it does so without adding a vendor dependency: it is explicitly vendor-neutral across models, and its stated design constraints are privacy, security and supply-chain integrity, with an affordability commitment so participation does not require a paid subscription.

The thing it buys is maintainer attention. Every hour not spent labelling and re-explaining is an hour available for design and review, which is the scarce resource here.

## Non-negotiables for the adoption

These are requirements on *how* it is adopted, and any implementation has to satisfy them:

1. **Vendor and model neutral.** Skills install to `.agents/skills/`, the canonical path shared by Codex, Cursor, Gemini CLI, Copilot, OpenCode, Cline, Zed and Warp, with per-tool directories as relay symlinks. No model vendor, runtime, or provider-specific feature may be named in any committed override. Anything requiring a paid subscription belongs in the gitignored personal override directory, so participation never depends on one contributor's account.
2. **Verifiable supply chain.** Install from the signed ASF release with SHA-512 and GPG signature verification, not a `git clone`. The committed lock records the hash so re-fetches are checked against it. A change to the lock is reviewed as a supply-chain change.
3. **Small committed footprint.** Lock file, bootstrap skill and overrides only. The framework snapshot stays gitignored and is never vendored into the repository's history.
4. **Nothing runs on its own.** No workflow, no schedule, no bot. A maintainer invokes a skill, reviews the output, and decides.
5. **Overrides carry the project's real constraints.** The generic recipes are not useful here without them, and a wrong one is worse than none — see below.

## Why the overrides are the substance

The framework's skills are project-agnostic. Left generic, they would ask for things this project deliberately does not do — explicit `OnPush` annotations (already the Angular 22 default), a facade over the generated client (rejected in ADR-0001), assigning issues (committer-only here).

More importantly, they would trust this repository's own checks. That trust is not warranted: **three separate mechanisms have reported success while testing nothing.**

- `npm run test` resolved to the `fineract-mfe` placeholder project and ran 2 specs instead of 775, exiting `0`.
- Karma prints `TOTAL: n SUCCESS` after a bundle failure, silently skipping the specs that failed to compile.
- The API drift manifest matched only single-line calls, so Prettier-wrapped calls were invisible and each regeneration quietly covered less.

So every override adopted here asks for *evidence that would fail if the claim were false*, and the code-review override encodes the failure modes that pass CI: unpadded dates returning `500` rather than a validation error, empty strings rejected as values, endpoints answering `204` or a zeroed `200` that render as a plausible empty screen.

## Scope

| Family | Status upstream | Decision |
|---|---|---|
| `setup`, `utilities` | always-on | required |
| `issue` | stable | **enable** — triage, deduplication, reproduction |
| `pr-management` | stable | **enable** — triage and reviewer routing |
| `repo-health` | opt-in | **enable** — workflow security, dependency and licence audits, flaky-test detection |
| `pairing` | opt-in | override written; enable per-contributor locally |
| `mentoring`, `contributor-growth` | experimental / opt-in | later — revisit with steadier newcomer traffic |
| `release-management` | experimental | not yet — this project does not cut releases on that cadence |
| `security` | stable | **needs a PMC decision** before enabling |

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

## Checklist

- [x] Install from the verified signed release and pin it
- [x] Write the project overrides (code review, issue triage, good-first-issue authoring, workflow security, dependency audit, self-review)
- [x] Document adoption, upgrade and the committed/ignored split (`DOCS/MAGPIE.md`)
- [ ] Trial `repo-health` and compare its findings against existing CI
- [ ] Trial `issue` triage on a handful of open issues
- [ ] Decide on `security` family with the PMC
- [ ] Revisit `mentoring` once newcomer traffic is steadier

## Open questions

These remain genuinely open and do not block the adoption itself:

- Does anything need to go past the PMC before enabling agent-authored PRs on an ASF repository?
- Do we want agent-drafted fixes at all initially, or only triage and labelling to start with?
- The `security` family handles reports before they are public — that needs an explicit PMC decision, not a maintainer one.

Start with implementation issue #241 and DOCS/MAGPIE.md, then review the committed lock, .agents/skills/ layout, and project overrides described here. Check the pinned signed 0.1.0 release and existing CI checks before assessing the repo-health trial. Done means the remaining checklist items have documented outcomes and the PMC decision is recorded where required.

Written by the indexing model from the issue text.