Aman-Mittal opened a new pull request, #241: URL: https://github.com/apache/fineract-backoffice-ui/pull/241
Implements #228. Adopts [Apache Magpie](https://magpie.apache.org/) 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) <[email protected]>" ``` 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. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
