This is an automated email from the ASF dual-hosted git repository.
potiuk pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow-steward.git
The following commit(s) were added to refs/heads/main by this push:
new 5ea1654 docs: refer to the framework as Apache Magpie (#436)
5ea1654 is described below
commit 5ea165459361c7bf2d98554575a2678d546cee16
Author: Jarek Potiuk <[email protected]>
AuthorDate: Tue Jun 2 19:03:46 2026 +0200
docs: refer to the framework as Apache Magpie (#436)
The framework's name has been settled on Apache Magpie (confirmed
available via PODLINGSEARCH). Update the documentation to use the
Magpie name throughout instead of the "Steward" / `<PROJECT_NAME>`
placeholders, and rewrite the naming-history notes (README, MISSION,
AGENTS, CONTRIBUTING, board resolution) to record that Magpie was
chosen and the bikeshed alternates (Beacon / Guild / Lichen) are no
longer in play.
Scope is documentation only: skill names, file/path references, the
`apache/airflow-steward` repo slug, and the `<PROJECT>` runtime
placeholder for adopting projects are deliberately left unchanged.
Generated-by: Claude Code (Opus 4.8)
---
AGENTS.md | 11 +++---
CONTRIBUTING.md | 9 ++---
MISSION.md | 59 +++++++++++++++------------------
PRINCIPLES.md | 8 ++---
README.md | 41 +++++++++--------------
docs/board-resolution-draft.md | 9 +++--
docs/rfcs/RFC-AI-0002.md | 2 +-
docs/rfcs/RFC-AI-0003.md | 8 ++---
docs/rfcs/RFC-AI-0004.md | 34 +++++++++----------
docs/security/new-members-onboarding.md | 2 +-
docs/security/threat-model.md | 2 +-
docs/setup/install-recipes.md | 20 +++++------
docs/setup/secure-agent-setup.md | 6 ++--
docs/setup/unadopt.md | 18 +++++-----
tools/agent-isolation/README.md | 2 +-
tools/egress-gateway/README.md | 2 +-
tools/privacy-llm/checker/README.md | 2 +-
tools/privacy-llm/redactor/README.md | 2 +-
tools/spec-loop/specs/overview.md | 2 +-
19 files changed, 112 insertions(+), 127 deletions(-)
diff --git a/AGENTS.md b/AGENTS.md
index e5de3a5..d276381 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -61,11 +61,12 @@ choices matter.
## Repository purpose
-This repository (currently `apache/airflow-steward`, **to be
-renamed** — final name TBD per a working-group poll, see the
-`Heads-up — rename in flight, name not yet chosen` note at the
-top of [`README.md`](README.md) for the candidate list and
-timeline) is the **generic, project-agnostic framework**.
+This repository (the **Apache Magpie** framework — name
+confirmed available via PODLINGSEARCH; still served from the
+legacy `apache/airflow-steward` slug until the GitHub rename
+lands, see the heads-up note at the top of
+[`README.md`](README.md)) is the **generic, project-agnostic
+framework**.
It contains skills, tool adapters, generic process documentation,
and a project-template scaffold — and **no project-specific
content**. Adopting projects fetch this repository as a gitignored
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 51743fd..9daa795 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -36,10 +36,11 @@
Thanks for helping improve this repository. It is the **generic,
project-agnostic framework** for agent-assisted repository
maintainership across ASF projects (and equally for any non-ASF
-open-source community that wants in). The framework currently
-lives at `apache/airflow-steward`; a rename to **Apache Magpie**
-is in flight — see [`MISSION.md`](MISSION.md) and the heads-up
-at the top of [`README.md`](README.md).
+open-source community that wants in). The framework is named
+**Apache Magpie** (confirmed available via PODLINGSEARCH); it
+still lives at the legacy `apache/airflow-steward` slug until the
+GitHub rename lands — see [`MISSION.md`](MISSION.md) and the
+heads-up at the top of [`README.md`](README.md).
Before sending a patch, please skim this file end-to-end: it lays
out the layering the repository depends on, the cross-cutting
diff --git a/MISSION.md b/MISSION.md
index f1950ba..fd482f1 100644
--- a/MISSION.md
+++ b/MISSION.md
@@ -2,11 +2,11 @@
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with
[DocToc](https://github.com/thlorenz/doctoc)*
-- [Apache `<PROJECT_NAME>`](#apache-project_name)
+- [Apache Magpie](#apache-magpie)
- [Mission](#mission)
- [Abstract](#abstract)
- [Proposal](#proposal)
- - [Proposed Names](#proposed-names)
+ - [Name](#name)
- [Rationale](#rationale)
- [Initial Goals](#initial-goals)
- [Technical scope](#technical-scope)
@@ -23,7 +23,7 @@
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
-# Apache `<PROJECT_NAME>`
+# Apache Magpie
> [!IMPORTANT]
> **Motto:** *"Give maintainers time back, so they can do what matters."*
@@ -38,7 +38,7 @@ development-cycle skills, and narrowly-scoped fix-and-merge
automation
## Abstract
-Apache `<PROJECT_NAME>` is platform infrastructure for **agent-assisted
repository maintainership and development** — across the ASF and equally for
any open-source project that wants in. Four streams of day-to-day work:
+Apache Magpie is platform infrastructure for **agent-assisted repository
maintainership and development** — across the ASF and equally for any
open-source project that wants in. Four streams of day-to-day work:
- **Security-issue handling** end-to-end — inbound triage, deduplication,
agent-drafted reporter replies under human review, CVE allocation hand-off,
audit-logged status tracking through publication.
- **Issue and PR triage and management** — including audit-tool findings
(Apache Verum, Apache Caer, equivalents) ingested as actionable issues.
@@ -49,28 +49,23 @@ One conviction underneath: each project picks how much
automation actually fits.
## Proposal
-The Apache Software Foundation establishes the Apache `<PROJECT_NAME>` Project
as a Top-Level Project by Board resolution, scope: agent-assisted repository
**maintainership and development** infrastructure under the Apache License,
Version 2.0.
+The Apache Software Foundation establishes the Apache Magpie Project as a
Top-Level Project by Board resolution, scope: agent-assisted repository
**maintainership and development** infrastructure under the Apache License,
Version 2.0.
-## Proposed Names
+## Name
-The founding-PMC bikeshed ran 8–12 May 2026; convergence is on **four names in
priority order**, ratified by a [LAZY CONSENSUS] call closing **Friday 15 May
2026, 12:00 UTC** and a parallel `[email protected]` review. The first of
these to clear `trademarks@`'s formal review becomes the final name:
+The project's name is **Apache Magpie**. It was selected by the founding PMC
during the naming bikeshed (8–12 May 2026) and confirmed available via
**PODLINGSEARCH**.
-1. **Apache Magpie** — primary
-2. **Apache Beacon** — backup 1
-3. **Apache Guild** — backup 2
-4. **Apache Lichen** — backup 3
-
-The Board resolution will carry whichever name clears `trademarks@` before
**Friday 15 May evening**.
+For the historical record, three alternates were carried as priority-ordered
backups during the bikeshed in case the primary failed the name search —
**Apache Beacon**, **Apache Guild**, and **Apache Lichen**. Magpie cleared
PODLINGSEARCH, so it is the final name and the alternates are no longer under
consideration. The Board resolution carries the Apache Magpie name.
## Rationale
-Open-source projects share the same shape of problem: contributors keep
arriving, reviewers don't scale to match, and the highest-stakes work —
security-issue handling — is the *most* manual, the *most* reviewer-intensive,
and the *most* embarrassing to get wrong. The two complaints heard most loudly
— **onboarding latency** and **review-cycle latency** — are the priorities the
ASF Responsible AI Initiative names. `<PROJECT_NAME>` is the operational layer
for those goals: not a position [...]
+Open-source projects share the same shape of problem: contributors keep
arriving, reviewers don't scale to match, and the highest-stakes work —
security-issue handling — is the *most* manual, the *most* reviewer-intensive,
and the *most* embarrassing to get wrong. The two complaints heard most loudly
— **onboarding latency** and **review-cycle latency** — are the priorities the
ASF Responsible AI Initiative names. Magpie is the operational layer for those
goals: not a position paper, wor [...]
Four design choices set the project apart from "just bolt a code-review bot on
it":
**Project autonomy is the structural starting point — and "project" includes
non-ASF.** Five modes — **Triage**, **Mentoring**, **Drafting** (agent-authored
fix with human review), **Pairing** (developer-side development-cycle skills
with mentorship intrinsic), and **Auto-merge** (narrowly-scoped fix-and-merge)
— ship as separate, independently-toggleable skills. Each project picks the
modes that match its culture and risk tolerance. ASF integrations (private
lists, Vulnogram CVE flows, [...]
-**Security-issue handling is a load-bearing use case, not a footnote on
triage.** The work that became `<PROJECT_NAME>` started as a framework for
handling ASF security reports — high-stakes, high-procedure,
every-step-needs-an-audit-trail flows that turn out to be exactly what
agent-assisted-with-human-gates is good at. Every mode has to clear the
security-flow bar (private content stays private, every outbound draft has a
human signature, every state change is logged) before it ships. [...]
+**Security-issue handling is a load-bearing use case, not a footnote on
triage.** The work that became Magpie started as a framework for handling ASF
security reports — high-stakes, high-procedure, every-step-needs-an-audit-trail
flows that turn out to be exactly what agent-assisted-with-human-gates is good
at. Every mode has to clear the security-flow bar (private content stays
private, every outbound draft has a human signature, every state change is
logged) before it ships. Projects w [...]
**Mentoring is a first-class mode, not a side-effect of triage.** The lever
the ASF — and the wider open-source world — actually needs and the one
off-the-shelf agent tooling skips. Meets new contributors where they are,
explains conventions, points at the relevant prior PR, asks the clarifying
question *before* a reviewer burns time on it. This is where the Responsible AI
Initiative's contributor-empowerment goal gets operationalised: the mode that
produces the outcomes RAI is trying to [...]
@@ -78,8 +73,8 @@ Four design choices set the project apart from "just bolt a
code-review bot on i
## Initial Goals
-- Stand up `github.com/apache/<PROJECT_NAME>` with project skeleton, CI, and
contributor docs.
-- Provision standard ASF infrastructure: `private@`, `dev@`, `commits@`;
GitHub Issues; site at `<PROJECT_NAME>.apache.org`.
+- Stand up `github.com/apache/magpie` with project skeleton, CI, and
contributor docs.
+- Provision standard ASF infrastructure: `private@`, `dev@`, `commits@`;
GitHub Issues; site at `magpie.apache.org`.
- Get **Triage**, **Mentoring**, and **Drafting** running against **3–4
friendly pilots within 3 months** — at least one ASF PMC running the full
security-issue flow (Airflow, given the project's lineage), one ASF PMC running
just Triage + Mentoring (Arrow or ATR), and **at least one non-ASF project from
day one** (Python core has folks interested). Non-ASF in the first cohort, not
later — the project-governance-agnosticism claim is only worth what it can
prove.
- Cut a first Apache release through the standard process within 3 months of
resolution adoption, with artefacts usable directly by non-ASF adopters (no
ASF-only assumption baked into the install path).
- Wire **Triage**, **Mentoring**, and **Drafting** up to Apache Verum and
Apache Caer findings, and to at least one non-ASF audit-tool equivalent (a
CodeQL output stream is the likely first non-ASF case).
@@ -111,14 +106,14 @@ The substrate also handles per-project config (which
modes are on, eligible chan
Most maintainers have never built an agentic application before. The mental
model is genuinely different from what twenty years of writing services and
CLIs trained us for: behaviour is **probabilistic, not deterministic**; prompts
and skill files **are code** in every meaningful sense; **evaluating output is
harder than testing a function**; the unit of authorship shifts from "a
function in a file" to "a skill the agent invokes". The instincts that keep
regular code reliable — strict ty [...]
-`<PROJECT_NAME>` runs a maintainer-facing education stream as a **first-class
part of the project**, not an afterthought wiki page:
+Magpie runs a maintainer-facing education stream as a **first-class part of
the project**, not an afterthought wiki page:
- **Pattern catalogue** — copy-pasteable skill / prompt / tool-use patterns
with notes on what worked, what didn't, and why. The same way the early days of
Python testing or distributed systems were taught: war stories with code
attached.
-- **Eval-driven development examples** — how to think about correctness when
"correct" is a distribution. Worked examples from real `<PROJECT_NAME>` modes;
integration with Apache Plumb so the eval methodology is shared, not reinvented
per-project.
-- **Workshops and pairing sessions** — scheduled office-hour sessions where
maintainers from any project (ASF or not) can show up with their use case and
pair with the `<PROJECT_NAME>` team. Recordings published.
+- **Eval-driven development examples** — how to think about correctness when
"correct" is a distribution. Worked examples from real Magpie modes;
integration with Apache Plumb so the eval methodology is shared, not reinvented
per-project.
+- **Workshops and pairing sessions** — scheduled office-hour sessions where
maintainers from any project (ASF or not) can show up with their use case and
pair with the Magpie team. Recordings published.
- **A "your first skill" path** — equivalent of "your first PR" docs, but for
landing a working skill in your project. Aim: any motivated maintainer can take
a working agentic skill from zero to merged in a weekend, without first having
to learn LLM internals.
-Every `<PROJECT_NAME>` release ships with the docs and patterns the
maintainers using it actually need. The steepness of this learning curve is
currently one of the larger barriers to broader agentic adoption in open
source; lowering it is part of the platform's job.
+Every Magpie release ships with the docs and patterns the maintainers using it
actually need. The steepness of this learning curve is currently one of the
larger barriers to broader agentic adoption in open source; lowering it is part
of the platform's job.
## Privacy, security, and supply-chain integrity — the top-most priority
@@ -131,17 +126,17 @@ Most maintainers asked about agentic tooling lead with
the same fears, in roughl
- *Can the agent quietly exfiltrate code or contributor data?*
- *If something goes wrong, can I see what happened and undo it?*
-Not theoretical — the actual reason a lot of capable maintainers are *not*
using agentic tools today, even when those tools would help. `<PROJECT_NAME>`'s
response, baked into the project's foundation rather than retrofitted later:
+Not theoretical — the actual reason a lot of capable maintainers are *not*
using agentic tools today, even when those tools would help. Magpie's response,
baked into the project's foundation rather than retrofitted later:
- **Clean-environment wrapper** around every agent invocation — no envvars
from the surrounding shell unless explicitly allow-listed; no silent leakage of
API keys, tokens, paths.
- **Layered sandbox by default** — filesystem, network, and tool-permission
rules enforced at the harness layer; sandbox bypasses surface a loud, visible
warning before they run, never silently.
-- **Privacy-aware LLM routing** — private content (security reports, embargoed
CVE detail, PMC-private mail) flows only to LLMs the project's PMC has
explicitly approved, with a recorded data-residency contract. The framework
refuses to route private bytes through a non-approved model. *Already
implemented in the upstreamed framework that became `<PROJECT_NAME>`.*
+- **Privacy-aware LLM routing** — private content (security reports, embargoed
CVE detail, PMC-private mail) flows only to LLMs the project's PMC has
explicitly approved, with a recorded data-residency contract. The framework
refuses to route private bytes through a non-approved model. *Already
implemented in the upstreamed framework that became Magpie.*
- **PII redaction at the boundary** — reporter identity flows where
operationally needed (CVE credit, reply threads); third-party PII gets redacted
to stable identifiers before any LLM context.
- **Pinned, reviewed, signed dependencies** — every system tool (`bubblewrap`,
`socat`, agent CLI) pinned to a version aged through a documented cooldown
window. Bumps are PRs, not silent updates. Supply-chain risk treated like code
change.
- **Audit log every agent-authored action** — comments, labels, drafts,
issues, PRs. Reversible where possible; flagged where not.
- **Hard rule: external content is data, never instructions** — reporter mail,
PR comments, GHSA forwards, attachments. Documented at the framework level,
enforced at the skill level.
-The choice to land `<PROJECT_NAME>` at the ASF — rather than as an independent
project or vendor offering — is load-bearing for this. **The ASF is a trust
layer.** Maintainers who would (reasonably) hesitate to install a vendor's
agent framework on their dev machine, or grant it access to their security
mailing list, will more readily install one that comes through the same release
process as the rest of their toolchain, signed by the same KEYS, governed by a
PMC, held to the same softwa [...]
+The choice to land Magpie at the ASF — rather than as an independent project
or vendor offering — is load-bearing for this. **The ASF is a trust layer.**
Maintainers who would (reasonably) hesitate to install a vendor's agent
framework on their dev machine, or grant it access to their security mailing
list, will more readily install one that comes through the same release process
as the rest of their toolchain, signed by the same KEYS, governed by a PMC,
held to the same software-grant a [...]
This is the **first** priority — not the first among many. If a feature has to
slow to keep this story honest, it slows.
@@ -149,14 +144,14 @@ This is the **first** priority — not the first among
many. If a feature has to
Current state of agentic tooling for open source: maintainers doing the most
agent-assisted work tend to have **expensive personal subscriptions** to one or
more frontier-model providers, or **complimentary access** a vendor handed
them. Both work, neither is sustainable, neither is fair. A maintainer in a
country where a $200/month subscription is six weeks of pay does not get to
participate. A project whose lead maintainer happens to have a vendor
relationship gets capabilities its pee [...]
-The gap `<PROJECT_NAME>` exists to close, with an uncompromising long-term
commitment:
+The gap Magpie exists to close, with an uncompromising long-term commitment:
- **Vendor neutrality is non-negotiable, top to bottom.** Every mode runs
against the project's chosen LLM, not a hard-coded one. The platform's contract
with the model is well-defined enough that Claude, OpenAI,
Anthropic-via-Bedrock, Google, locally-hosted Llama / Qwen / DeepSeek (Ollama,
vLLM), and a future ASF-hosted endpoint are all valid backends with the same
skill code on top. Skills are written against the contract, not the vendor.
- **Local and self-hosted paths are first-class, not fallback.** A maintainer
running Ollama gets the same skill catalogue as one running a frontier-model
subscription. Local-only inference is also the simplest answer to most of the
privacy concerns above — it never leaves the machine.
- **An ASF-hosted inference endpoint is on the long-term roadmap** —
`inference.apache.org` (name TBD): a community-affordable, foundation-governed,
audit-logged inference layer any open-source maintainer (ASF or not) can use to
participate in agentic development without paying a vendor or accepting a
vendor's gift. The long-term shape of "release software for the public good" in
the agentic era.
-- **Economics get documented honestly.** `<PROJECT_NAME>`'s docs include a
"what does each mode actually cost to run" page — token counts per typical
invocation, per mode, per model class — so a maintainer evaluating adoption can
make an informed call instead of guessing. The same data informs the case for
the ASF-hosted endpoint when the community is ready to ask the question.
+- **Economics get documented honestly.** Magpie's docs include a "what does
each mode actually cost to run" page — token counts per typical invocation, per
mode, per model class — so a maintainer evaluating adoption can make an
informed call instead of guessing. The same data informs the case for the
ASF-hosted endpoint when the community is ready to ask the question.
-The ASF mission line — *"to provide software for the public good"* — has
always meant the *running* software, not just the source code. For agentic
tooling, the running software increasingly *is* the model, and the public-good
commitment has to extend that far. **If `<PROJECT_NAME>` ends up being a thing
only well-resourced maintainers can run, it has failed its core mission,
regardless of how good the code is.**
+The ASF mission line — *"to provide software for the public good"* — has
always meant the *running* software, not just the source code. For agentic
tooling, the running software increasingly *is* the model, and the public-good
commitment has to extend that far. **If Magpie ends up being a thing only
well-resourced maintainers can run, it has failed its core mission, regardless
of how good the code is.**
## Initial PMC composition (target)
@@ -207,15 +202,15 @@ on the project from day one:
## Required resources
-- **Mailing lists:** `private@<PROJECT_NAME>.apache.org`,
`dev@<PROJECT_NAME>.apache.org`, `commits@<PROJECT_NAME>.apache.org`.
-- **Source control:** `github.com/apache/<PROJECT_NAME>`.
+- **Mailing lists:** `[email protected]`, `[email protected]`,
`[email protected]`.
+- **Source control:** `github.com/apache/magpie`.
- **Issue tracking:** GitHub Issues.
-- **Website:** `<PROJECT_NAME>.apache.org`.
+- **Website:** `magpie.apache.org`.
- **Release infrastructure:** `dist.apache.org` per standard ASF process.
## Source and IP
-Green-field project, with substantial project-agnostic code being moved over
from existing ASF projects — Apache Airflow (where the security-issue handling,
PR triage, mentoring, and drafting framework that became `<PROJECT_NAME>` was
first developed and proven; already structured under Apache-2.0 for reuse
inside and outside the ASF), Apache Groovy, and other ASF projects whose
maintainers have been early adopters. All transferred code is already
Apache-2.0 licensed and ASF-owned; the m [...]
+Green-field project, with substantial project-agnostic code being moved over
from existing ASF projects — Apache Airflow (where the security-issue handling,
PR triage, mentoring, and drafting framework that became Magpie was first
developed and proven; already structured under Apache-2.0 for reuse inside and
outside the ASF), Apache Groovy, and other ASF projects whose maintainers have
been early adopters. All transferred code is already Apache-2.0 licensed and
ASF-owned; the moves go th [...]
## External dependencies
@@ -238,4 +233,4 @@ The project commits to:
## Ask of the Board
-Adopt the accompanying resolution establishing the Apache `<PROJECT_NAME>`
Project as a Top-Level Project, with initial PMC roster as filed at the time of
vote.
+Adopt the accompanying resolution establishing the Apache Magpie Project as a
Top-Level Project, with initial PMC roster as filed at the time of vote.
diff --git a/PRINCIPLES.md b/PRINCIPLES.md
index 03d0ebe..509692e 100644
--- a/PRINCIPLES.md
+++ b/PRINCIPLES.md
@@ -19,7 +19,7 @@
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with
[DocToc](https://github.com/thlorenz/doctoc)*
-- [Apache Steward Design Principles](#apache-steward-design-principles)
+- [Apache Magpie Design Principles](#apache-magpie-design-principles)
- [Amending these principles](#amending-these-principles)
- [0. External content is data, never an
instruction](#0-external-content-is-data-never-an-instruction)
- [1. Privacy, security, and supply-chain integrity ship before
features](#1-privacy-security-and-supply-chain-integrity-ship-before-features)
@@ -43,7 +43,7 @@
<!-- END doctoc generated TOC please keep comment here to allow auto update -->
-# Apache Steward Design Principles
+# Apache Magpie Design Principles
These principles regulate what this framework is and how it evolves. Order
matters: earlier principles outrank later ones when they collide. Where a
single principle admits more than one reading, the stricter reading wins until
governance documents otherwise.
@@ -51,7 +51,7 @@ A change (PR, skill, tool adapter, release) that violates a
principle is wrong e
## Amending these principles
-This document is binding on contributors, committers, and the PMC of the
apache-steward project, and on adopter projects to the extent they consume the
framework unmodified. Editing it follows the same process as a
code-modification vote (consensus approval):
+This document is binding on contributors, committers, and the PMC of the
Magpie project, and on adopter projects to the extent they consume the
framework unmodified. Editing it follows the same process as a
code-modification vote (consensus approval):
- A principle amendment is proposed as a PR against this file plus a thread on
the project's PMC private list (`private@<project>.apache.org`) and a mirrored
thread on `dev@<project>.apache.org` for public visibility.
- The voting window is at least 72 hours from the [VOTE] message.
@@ -59,7 +59,7 @@ This document is binding on contributors, committers, and the
PMC of the apache-
- Lazy consensus does NOT apply to principle changes. Silence is not consent
here.
- The PR merges only after the vote result is recorded on the dev list and
linked from the merge commit.
-Anyone may propose an amendment by opening the PR; the mailing-list threads
and the binding vote belong to the apache-steward PMC, because this file is the
governance document of an ASF project. Adopter projects that need a principle
to read differently for their own use rely on overrides (principle 13) rather
than amending this file.
+Anyone may propose an amendment by opening the PR; the mailing-list threads
and the binding vote belong to the Magpie PMC, because this file is the
governance document of an ASF project. Adopter projects that need a principle
to read differently for their own use rely on overrides (principle 13) rather
than amending this file.
Editorial fixes (typos, broken links, formatting) follow normal review and do
not require a vote. Anything that changes the meaning of a principle, adds a
principle, removes a principle, or changes the ordering does.
diff --git a/README.md b/README.md
index 487709a..177c14a 100644
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with
[DocToc](https://github.com/thlorenz/doctoc)*
-- [Apache Steward (to be renamed)](#apache-steward-to-be-renamed)
+- [Apache Magpie](#apache-magpie)
- [How adoption works](#how-adoption-works)
- [Adopting the framework](#adopting-the-framework)
- [1. Bootstrap (copy-pasteable shell)](#1-bootstrap-copy-pasteable-shell)
@@ -18,32 +18,21 @@
<!-- SPDX-License-Identifier: Apache-2.0
https://www.apache.org/legal/release-policy.html -->
-# Apache Steward (to be renamed)
+# Apache Magpie
-> **Heads-up — rename in flight, [LAZY CONSENSUS] in progress.**
-> This repository is currently served from
-> `apache/airflow-steward` and is going to be renamed to a
-> **different** name — *not* `apache/steward`. The current name
-> carries `airflow` for legacy reasons, but the framework is
-> project-agnostic (it stewards multiple ASF project workflows,
-> not just Airflow's), so the working group steering it picked
-> a new name that reflects that.
+> **Heads-up — the project is named Apache Magpie; the GitHub
+> slug rename is still pending.**
+> The framework's name is **Apache Magpie**. The current
+> `apache/airflow-steward` slug carries `airflow` for legacy
+> reasons, but the framework is project-agnostic (it stewards
+> multiple ASF project workflows, not just Airflow's), so the
+> working group steering it chose a name that reflects that.
>
-> The founding-PMC bikeshed ran **8–12 May 2026**; convergence
-> is on four names in priority order, with a [LAZY CONSENSUS]
-> call closing **Friday 15 May 2026, 12:00 UTC** and a parallel
-> `[email protected]` review in flight. The first of these
-> to clear `trademarks@`'s formal review becomes the final name:
->
-> 1. **Apache Magpie** — primary
-> 2. **Apache Beacon** — backup 1
-> 3. **Apache Guild** — backup 2
-> 4. **Apache Lichen** — backup 3
->
-> The Board resolution establishing the project as an ASF
-> Top-Level Project is scheduled for **Wed 20 May 2026** and
-> will carry whichever name clears `trademarks@` before
-> Friday 15 May evening.
+> **Magpie** was selected by the founding PMC and confirmed
+> available via **PODLINGSEARCH**. Three alternates were carried
+> as historical backups during the bikeshed — *Beacon*, *Guild*,
+> and *Lichen* — but Magpie cleared the name search and is the
+> final name; the alternates are no longer in play.
>
> Until the rename lands on the GitHub side, every clone URL and
> CI integration still uses the legacy `apache/airflow-steward`
@@ -162,7 +151,7 @@ done. Open a PR.
### Subsequent contributors
Future contributors who clone your repo just say "adopt
-apache-steward in this repo" (or invoke `/setup-steward`).
+Magpie in this repo" (or invoke `/setup-steward`).
The skill reads `.apache-steward.lock` (already committed)
and re-installs to the same version your project pinned. No
need to redo the manual recipe — the committed lock is the
diff --git a/docs/board-resolution-draft.md b/docs/board-resolution-draft.md
index a5e8b98..ebad365 100644
--- a/docs/board-resolution-draft.md
+++ b/docs/board-resolution-draft.md
@@ -111,11 +111,10 @@ to land them in the right place at the right time:
*"7 or more members"* size criterion and the diversity / developer-
experience criteria in MISSION.md § Initial PMC composition.
-- **PMC name vs. trademark review** — `MISSION.md` § Proposed Names lists
- four candidates (Magpie / Beacon / Guild / Lichen) pending parallel
- `[email protected]` review. The first to clear `trademarks@` becomes
- the final name. Replace "Magpie" in the resolution text above with
- whichever name is cleared before the resolution lands on the agenda.
+- **PMC name** — the project name is **Apache Magpie**, confirmed
+ available via PODLINGSEARCH (see `MISSION.md` § Name). The historical
+ bikeshed alternates (Beacon / Guild / Lichen) are no longer in play,
+ so the resolution text above carries the final name as-is.
- **Special Order number** — assigned by the Board Secretary when the
agenda is built. Placeholder `[NN]` above.
diff --git a/docs/rfcs/RFC-AI-0002.md b/docs/rfcs/RFC-AI-0002.md
index 2fc37a8..1073595 100644
--- a/docs/rfcs/RFC-AI-0002.md
+++ b/docs/rfcs/RFC-AI-0002.md
@@ -32,7 +32,7 @@
<!-- Source: ASF Confluence wiki (RFCs space). Public-safe re-export:
wiki-internal links and members-only references have been stripped
- per the Apache Steward project's RFC-AI-0004 § Privacy-by-Design
+ per the Apache Magpie project's RFC-AI-0004 § Privacy-by-Design
principle (no exposing of SSO-gated URLs in public artefacts).
The authoritative source remains the Confluence page; this file
is a public mirror for review by adopters who do not have ASF SSO. -->
diff --git a/docs/rfcs/RFC-AI-0003.md b/docs/rfcs/RFC-AI-0003.md
index cc20f58..c033297 100644
--- a/docs/rfcs/RFC-AI-0003.md
+++ b/docs/rfcs/RFC-AI-0003.md
@@ -39,14 +39,14 @@
<!-- Source: ASF Confluence wiki (RFCs space). Public-safe re-export:
wiki-internal links and members-only references have been stripped
- per the Apache Steward project's RFC-AI-0004 § Privacy-by-Design
+ per the Apache Magpie project's RFC-AI-0004 § Privacy-by-Design
principle (no exposing of SSO-gated URLs in public artefacts).
The authoritative source remains the Confluence page; this file
is a public mirror for review by adopters who do not have ASF SSO. -->
# RFC-AI-0003: Privacy-aware LLM routing for foundation private information
-Apache Steward (to be renamed) — third-party PII redaction + approved-LLM gate
+Apache Magpie — third-party PII redaction + approved-LLM gate
apache/airflow-steward maintainers
@@ -59,14 +59,14 @@ apache/airflow-steward maintainers
| Field | Value |
|---|---|
| **Status** | Provisional — pending ASF Privacy VP/Legal VP ratification |
-| **Targets** | `apache/airflow-steward` (the Apache Steward (to be renamed)
framework) + adopting projects |
+| **Targets** | `apache/airflow-steward` (the Apache Magpie framework) +
adopting projects |
| **Implemented in** | [PR
#48](https://github.com/apache/airflow-steward/pull/48) (foundation), [PR
#50](https://github.com/apache/airflow-steward/pull/50) (refinement +
skill-side redactor wiring), [PR
#51](https://github.com/apache/airflow-steward/pull/51) (gate-check +
skill-side gate wiring) |
| **Source-of-truth docs** |
[`tools/privacy-llm/{tool,pii,models,wiring}.md`](https://github.com/apache/airflow-steward/tree/main/tools/privacy-llm),
[`docs/setup/privacy-llm.md`](https://github.com/apache/airflow-steward/blob/main/docs/setup/privacy-llm.md),
[`AGENTS.md →
Privacy-LLM`](https://github.com/apache/airflow-steward/blob/main/AGENTS.md) |
| **Reference implementation** |
[`tools/privacy-llm/redactor/`](https://github.com/apache/airflow-steward/tree/main/tools/privacy-llm/redactor)
(PII redactor, stdlib-only Python, 48 unit tests),
[`tools/privacy-llm/checker/`](https://github.com/apache/airflow-steward/tree/main/tools/privacy-llm/checker)
(approved-LLM gate-check, stdlib-only Python, 33 unit tests) |
## 1. Abstract
-The Apache Steward (to be renamed) framework lets agents drive ASF security
workflows that read **two distinct classes of private mail**: external
reporters' mail to a project's `<security-list>` and PMC-internal mail on
`<private-list>`. Both classes must not leak through any LLM in the active
stack — but they require **different** remediations, and a single conflated
mechanism would either over-block (refuse to process `<security-list>` content
needlessly) or under-protect (let `<priva [...]
+The Apache Magpie framework lets agents drive ASF security workflows that read
**two distinct classes of private mail**: external reporters' mail to a
project's `<security-list>` and PMC-internal mail on `<private-list>`. Both
classes must not leak through any LLM in the active stack — but they require
**different** remediations, and a single conflated mechanism would either
over-block (refuse to process `<security-list>` content needlessly) or
under-protect (let `<private-list>` bodies [...]
This RFC describes — and the linked PRs implement — a **two-mechanism design**:
diff --git a/docs/rfcs/RFC-AI-0004.md b/docs/rfcs/RFC-AI-0004.md
index 3bdda0f..66369d6 100644
--- a/docs/rfcs/RFC-AI-0004.md
+++ b/docs/rfcs/RFC-AI-0004.md
@@ -43,7 +43,7 @@
- [Anti-patterns to avoid](#anti-patterns-to-avoid-5)
- [References to the broader privacy
posture](#references-to-the-broader-privacy-posture)
- [How the six principles compose](#how-the-six-principles-compose)
- - [Adoption guidance for non-Steward (to be renamed)
projects](#adoption-guidance-for-non-steward-to-be-renamed-projects)
+ - [Adoption guidance for non-Magpie
projects](#adoption-guidance-for-non-magpie-projects)
- [What this RFC does NOT specify](#what-this-rfc-does-not-specify)
- [References](#references)
- [Internal (this repository)](#internal-this-repository)
@@ -57,7 +57,7 @@
<!-- Source: ASF Confluence wiki (RFCs space). Public-safe re-export:
wiki-internal links and members-only references have been stripped
- per the Apache Steward project's RFC-AI-0004 § Privacy-by-Design
+ per the Apache Magpie project's RFC-AI-0004 § Privacy-by-Design
principle (no exposing of SSO-gated URLs in public artefacts).
The authoritative source remains the Confluence page; this file
is a public mirror for review by adopters who do not have ASF SSO. -->
@@ -69,11 +69,11 @@
| **RFC** | AI-0004 |
| **Title** | Principles of agentic interaction for open-source maintainers |
| **Status** | Draft |
-| **Authors** | The Apache Steward (to be renamed) project (see
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md)
for roster) |
+| **Authors** | The Apache Magpie project (see
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md)
for roster) |
| **Initial draft** | 2026-05-07 |
| **Supersedes** | None |
| **Superseded by** | None |
-| **Reference implementation** | [`apache/airflow-Steward (to be
renamed)`](https://github.com/apache/airflow-steward) |
+| **Reference implementation** |
[`apache/airflow-steward`](https://github.com/apache/airflow-steward) |
| **License** | Apache License 2.0 |
---
@@ -82,7 +82,7 @@
This RFC describes six principles that govern how AI agents should interact
with open-source projects when **the human in the interaction is a project
maintainer** — committer, PMC member, release manager, security-team member,
triager. The six principles — **(1) human-in-the-loop on every state change**,
**(2) secure sandbox by default**, **(3) vendor neutrality across LLM backends
and project governance**, **(4) conversational, correctable agentic skills**,
**(5) write access and outbo [...]
-The RFC is normative for the Apache Steward (to be renamed) framework
([`apache/airflow-Steward (to be
renamed)`](https://github.com/apache/airflow-steward), the working draft of
which is summarised in
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md))
and is offered as a **pattern other projects can adopt or adapt** when
integrating agentic tooling into their own maintainership workflow.
+The RFC is normative for the Apache Magpie framework
([`apache/airflow-steward`](https://github.com/apache/airflow-steward), the
working draft of which is summarised in
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md))
and is offered as a **pattern other projects can adopt or adapt** when
integrating agentic tooling into their own maintainership workflow.
It is **not** a specification of any particular implementation detail (LLM
choice, prompt format, model size, scaffolding library). The principles are
independent of those choices.
@@ -90,10 +90,10 @@ It is **not** a specification of any particular
implementation detail (LLM cho
## Status of this document
-This is a **Draft**. The Apache Steward (to be renamed) project's reference
implementation operationalises every principle in this RFC, but the RFC itself
is the project's first attempt to extract the principles from the
implementation and frame them as a portable contract. The next two milestones
are:
+This is a **Draft**. The Apache Magpie project's reference implementation
operationalises every principle in this RFC, but the RFC itself is the
project's first attempt to extract the principles from the implementation and
frame them as a portable contract. The next two milestones are:
1. **Public review** — comments solicited from ASF Members, non-ASF
maintainers running similar agentic frameworks, and the ASF Responsible AI
Initiative working group.
-2. **Pilot validation** — the four principles tested against the Apache
Steward (to be renamed) pilot cohort (one ASF PMC running the full
security-issue flow, one ASF PMC running just triage + mentoring, at least one
non-ASF project) before promotion from `Draft` to `Stable`.
+2. **Pilot validation** — the four principles tested against the Apache Magpie
pilot cohort (one ASF PMC running the full security-issue flow, one ASF PMC
running just triage + mentoring, at least one non-ASF project) before promotion
from `Draft` to `Stable`.
---
@@ -115,7 +115,7 @@ This RFC names the four shifts that, taken together, make
agentic tooling accept
| Term | Definition |
|---|---|
| **Agent** | A program that selects and executes actions to advance a
maintainer-stated goal, where at least one of those actions is mediated by an
LLM and where action selection is conditioned on natural-language conversation
rather than a pre-coded flow chart. |
-| **Skill** | A package of agent-readable text (typically a markdown file with
YAML frontmatter and bundled scripts/references) that scopes the agent to a
single workflow. The Apache Steward (to be renamed) framework's skills
(`security-issue-import`, `pr-management-triage`, etc.) are reference
instances. |
+| **Skill** | A package of agent-readable text (typically a markdown file with
YAML frontmatter and bundled scripts/references) that scopes the agent to a
single workflow. The Apache Magpie framework's skills (`security-issue-import`,
`pr-management-triage`, etc.) are reference instances. |
| **Maintainer** | A human with write access (or comparable governance
authority) on the target project. PMC members, committers, triagers, release
managers all qualify; bots and agents do not. |
| **State change** | Any operation observable by parties outside the
maintainer's local machine: posted comment, edited issue body, applied label,
merged PR, sent email, written file under the repo's tracked path, etc.
Operations that touch only the maintainer's `/tmp` or `~/.config/<framework>/`
cache are **not** state changes. |
| **Confirmation** | An explicit, in-session, reversible-only-by-history act
by the maintainer that authorises one specific state change. Standing
approvals, "yes to all", and pre-approved-via-config are explicitly **not**
confirmations. |
@@ -143,7 +143,7 @@ A skill that triages 200 PRs in 10 minutes is doing 200
state changes. If the ma
### Narrow auto-merge carve-out
-Auto-merge ("narrowly-scoped fix-and-merge", in Apache Steward (to be
renamed)'s terminology) is the explicit exception. It permits auto-merge, but
only after **all** of the following gate conditions hold:
+Auto-merge ("narrowly-scoped fix-and-merge", in Apache Magpie's terminology)
is the explicit exception. It permits auto-merge, but only after **all** of the
following gate conditions hold:
- The change class is on a per-project, per-class allow-list (lint fixes,
dependency bumps within an allow-list, license headers, formatting, broken-link
repair). Security-class changes are explicitly out.
- The project has been running Triage, Mentoring, and Drafting with HITL
confirmation for at least two release cycles, and a contributor-sentiment
evaluation says the project is healthier, not just faster.
@@ -213,7 +213,7 @@ The reference implementation (see
[`docs/setup/secure-agent-internals.md`](http
1. **Pluggable backend.** The framework's skills cite no model name in their
flow logic. "Use the strongest model available" / "use a fast model for this
lookup step" are acceptable hints; "must be Claude Sonnet 4.5" is not.
2. **Pluggable adapters.** Private-mailing-list, CVE-tool, release-process,
and audit-finding ingest MUST live behind adapter modules. The reference
implementation's `tools/<adapter>/` directories (`tools/cve-tool-vulnogram/`,
`tools/gmail/`, `tools/ponymail/`) are this pattern.
-3. **Pilot diversity.** Validation runs (per the Apache Steward (to be
renamed)
[MISSION.md](https://github.com/apache/airflow-steward/blob/main/MISSION.md))
cover at least one frontier-model backend, at least one fully-local inference
setup (Ollama / vLLM / equivalent), and at least one Apache-hosted or
Apache-aligned endpoint. A framework that only validates against one vendor is
a vendor-locked framework that has not noticed yet.
+3. **Pilot diversity.** Validation runs (per the Apache Magpie
[MISSION.md](https://github.com/apache/airflow-steward/blob/main/MISSION.md))
cover at least one frontier-model backend, at least one fully-local inference
setup (Ollama / vLLM / equivalent), and at least one Apache-hosted or
Apache-aligned endpoint. A framework that only validates against one vendor is
a vendor-locked framework that has not noticed yet.
4. **Privacy-LLM gating is vendor-neutral by construction.** Private content
(security reports, embargoed CVE detail, PMC-private mail) flows only to LLMs
the project's PMC has explicitly approved. "Approved" is per-PMC, not
per-framework — the framework's contribution is the gate check, not the policy.
See
[`tools/privacy-llm/`](https://github.com/apache/airflow-steward/blob/main/tools/privacy-llm/)
for the reference gate.
5. **License + IP posture.** Framework code AL2.0 / MIT. Skills AL2.0.
Generated artefacts (commit messages, PR bodies, advisory drafts) inherit the
maintainer's commit licence; the framework MUST NOT introduce a vendor's
model-output licence by reference.
@@ -240,7 +240,7 @@ The shift the maintainer makes is from "this tool needs a
code change" to "this
### Five concrete consequences
1. **Skills are markdown.** Not YAML. Not JSON. Not a DSL. Markdown with YAML
frontmatter and inline code blocks. The maintainer reads them like
documentation; the agent reads them like instructions; the diff between two
revisions is reviewable in the normal PR review surface.
-2. **Local override before upstream PR.** The reference implementation's
`.apache-steward (to be renamed)-overrides/<skill>.md` convention lets a
maintainer encode "for this project, do X differently" without forking the
framework. The override file is committed in the adopter's repo; the framework
reads it at runtime and merges agent-readable modifications before executing
the default behaviour.
+2. **Local override before upstream PR.** The reference implementation's
`.apache-steward-overrides/<skill>.md` convention lets a maintainer encode "for
this project, do X differently" without forking the framework. The override
file is committed in the adopter's repo; the framework reads it at runtime and
merges agent-readable modifications before executing the default behaviour.
3. **Upstream loop is first-class.** When an override has stabilised —
typically after a few weeks of running — the `setup-override-upstream` skill
(or equivalent) walks the maintainer through promoting the override into a
framework PR. Some overrides stay local forever (project-specific policy); some
belong upstream (general improvement). The framework MUST surface the choice
explicitly.
4. **Correction is in-conversation.** The maintainer says "stop using `--repo`
argument; my project uses `--repository`" and the agent acknowledges, applies
the change in this session, and surfaces the override-file path so the
correction persists across sessions. The maintainer is not expected to know the
framework's source layout to make a behaviour change stick.
5. **Skills carry their own provenance.** Every skill cites what it does, what
it does **not** do, the placeholders it uses, the adapter-config knobs it
consults, and (where applicable) the upstream commit it was derived from. The
maintainer who reads the skill knows what they are trusting.
@@ -312,7 +312,7 @@ The reference implementation operationalises this principle
in [`tools/privacy-
### Five concrete consequences
-1. **Approved-LLM gate.** The project's PMC declares the set of LLMs that may
receive private content. The list is per-PMC, not per-framework — Apache
Steward (to be renamed)'s gate-check tool (`tools/privacy-llm/checker/`)
enforces the gate but the *policy* is the project's. The reference list
defaults to "Claude Code trusted; `*.apache.org` auto-approved; `localhost` for
local-inference setups; everything else requires explicit opt-in."
+1. **Approved-LLM gate.** The project's PMC declares the set of LLMs that may
receive private content. The list is per-PMC, not per-framework — Apache
Magpie's gate-check tool (`tools/privacy-llm/checker/`) enforces the gate but
the *policy* is the project's. The reference list defaults to "Claude Code
trusted; `*.apache.org` auto-approved; `localhost` for local-inference setups;
everything else requires explicit opt-in."
2. **Redact-before-read.** When a skill fetches Gmail or PonyMail private
content, it pipes the fetched bytes through the framework's PII redactor
(`tools/privacy-llm/redactor/`) *before* the LLM sees them. Reporter names →
`N-<hash>`, email addresses → `E-<hash>`, IPs → `IP-<hash>`. The skill operates
on the hash-prefixed identifiers; the reverse map lives only on the
maintainer's local disk (mode 0600, never committed), and the *reveal* step
happens at draft-write time inside the maint [...]
3. **Reporter-PII is redacted, but reporter *credit* is not.** The redaction
is for in-context PII — the reporter's name and email when the agent is
reasoning about routing, triage, deduplication. The reporter's
*publicly-credited* identity (e.g., "Reported by Jane Smith" in the CVE
record's `credits[]` field) is a deliberate output and passes through
unredacted, only after the maintainer confirms the credit shape with the
reporter on the inbound thread.
4. **Confidentiality scrub before public emission.** Every skill that emits a
public artefact (advisory email, public PR body, public CVE-record JSON, GitHub
Security Advisory) MUST run a confidentiality scrub against the draft body:
regex match for `CVE-\d{4}-\d{4,7}` (forbidden in pre-disclosure public PRs),
reporter names from the private mapping table, mailing-list addresses, and any
string the project's policy file enumerates as private. The scrub fires before
the draft is shown to [...]
@@ -377,17 +377,17 @@ Drop any one of the six and the system regresses to a
recognisable bad pattern:
---
-## Adoption guidance for non-Steward (to be renamed) projects
+## Adoption guidance for non-Magpie projects
-A project that wants to adopt these principles without adopting Apache Steward
(to be renamed) as a whole has the following minimum bar:
+A project that wants to adopt these principles without adopting Apache Magpie
as a whole has the following minimum bar:
1. **Pick an agent host with HITL primitives.** Claude Code, Cursor's
Composer, and Aider all support per-action confirmation. Avoid hosts that
default to "auto-apply suggested changes".
2. **Wrap the host in an OS sandbox.** On Linux, `bubblewrap` + a
network-allow-list HTTP proxy is one day's work. On macOS, a `sandbox-exec`
profile is similar. The agent's parent shell runs in the sandbox; every
subprocess inherits.
-3. **Treat skill files as code.** Land them in a `skills/` directory under
your project's main repo or a sibling `<project>-Steward (to be renamed)` repo.
PR them. Review them. Diff them. Don't hand-edit them on production machines
without committing.
+3. **Treat skill files as code.** Land them in a `skills/` directory under
your project's main repo or a sibling `<project>-steward` repo. PR them. Review
them. Diff them. Don't hand-edit them on production machines without committing.
4. **Document the adapter boundaries.** What is project-specific (your release
process, your CVE flow, your private mailing list)? Move those into a
`<project-config>/` directory with documented placeholders and let the skills
consult them.
5. **Pilot before scale.** Run the agent against your project's own backlog
for a release cycle before letting it touch contributor-facing artefacts at
full speed. The contributor-sentiment data you collect during the pilot is the
only honest signal that the framework is helping, not just speeding up the harm.
-The Apache Steward (to be renamed) project is happy to consult on the lift —
see
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md)
for the maintainer- education stream.
+The Apache Magpie project is happy to consult on the lift — see
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md)
for the maintainer- education stream.
---
@@ -415,4 +415,4 @@ The Apache Steward (to be renamed) project is happy to
consult on the lift — s
## Acknowledgements
-This RFC distils principles operationalised in the Apache Steward (to be
renamed) reference implementation. The PMC roster and collaborator list (see
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md))
includes the people whose discussion, code, and incident-review work shaped
these principles. The framing of the principles here owes a particular debt to
the 2026-05 prompt-injection audit
([gist](https://gist.github.com/andrew/0bc8bdaac6902656ccf3b1400ad160f0) [...]
+This RFC distils principles operationalised in the Apache Magpie reference
implementation. The PMC roster and collaborator list (see
[`MISSION.md`](https://github.com/apache/airflow-steward/blob/main/MISSION.md))
includes the people whose discussion, code, and incident-review work shaped
these principles. The framing of the principles here owes a particular debt to
the 2026-05 prompt-injection audit
([gist](https://gist.github.com/andrew/0bc8bdaac6902656ccf3b1400ad160f0)) that
surfaced t [...]
diff --git a/docs/security/new-members-onboarding.md
b/docs/security/new-members-onboarding.md
index 154121d..49ab0ce 100644
--- a/docs/security/new-members-onboarding.md
+++ b/docs/security/new-members-onboarding.md
@@ -126,7 +126,7 @@ week. A good starting routine:
6. **Set up your per-user config** if (and only if) you plan to run
the agent skills. Copy
`.apache-steward-overrides/user.md` (scaffolded automatically when
- the project adopts steward) and fill in your GitHub handle, email,
+ the project adopts Magpie) and fill in your GitHub handle, email,
governance-gate status (whatever
`<project-config>/project.md → governance.cve_allocation_gate`
declares — for the ASF/Airflow named example: PMC membership),
diff --git a/docs/security/threat-model.md b/docs/security/threat-model.md
index 9e3077d..cfb3942 100644
--- a/docs/security/threat-model.md
+++ b/docs/security/threat-model.md
@@ -46,7 +46,7 @@
## Purpose
-Apache Steward automates the [16-step security-issue
+Apache Magpie automates the [16-step security-issue
lifecycle](process.md) on behalf of a project's security team.
Every skill that ships in the framework either reads from, writes
to, or moves data across a trust boundary the project treats as
diff --git a/docs/setup/install-recipes.md b/docs/setup/install-recipes.md
index fb34e5a..f8159d5 100644
--- a/docs/setup/install-recipes.md
+++ b/docs/setup/install-recipes.md
@@ -2,7 +2,7 @@
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with
[DocToc](https://github.com/thlorenz/doctoc)*
-- [Install recipes — bootstrap apache-steward in an adopter
repo](#install-recipes--bootstrap-apache-steward-in-an-adopter-repo)
+- [Install recipes — bootstrap Magpie in an adopter
repo](#install-recipes--bootstrap-magpie-in-an-adopter-repo)
- [Method 1 — released zip from ASF
distribution](#method-1--released-zip-from-asf-distribution)
- [Method 2 — git tag](#method-2--git-tag)
- [Method 3 — git branch (defaults to
`main`)](#method-3--git-branch-defaults-to-main)
@@ -14,7 +14,7 @@
<!-- SPDX-License-Identifier: Apache-2.0
https://www.apache.org/legal/release-policy.html -->
-# Install recipes — bootstrap apache-steward in an adopter repo
+# Install recipes — bootstrap Magpie in an adopter repo
Three copy-pasteable shell recipes for fetching the framework
into a new adopter project's repo. Each recipe is **the
@@ -70,7 +70,7 @@ Pick the recipe that matches your distribution preference:
> [Method 3 — git-branch](#method-3--git-branch-defaults-to-main).
```bash
-# === apache-steward bootstrap — Method 1: signed zip from ASF dist ===
+# === Magpie bootstrap — Method 1: signed zip from ASF dist ===
# Replace <PROJECT> with the host adopter's ASF dist subdirectory
# (e.g. `airflow` once releases land at
# https://dist.apache.org/repos/dist/release/airflow/).
@@ -127,7 +127,7 @@ cp -r .apache-steward/.claude/skills/setup-steward
.claude/skills/setup-steward
# 3. Add gitignore entries (idempotent — re-run is safe)
cat >> .gitignore <<'GITIGNORE'
-# apache-steward — gitignored snapshot of the framework, refreshed
+# Magpie — gitignored snapshot of the framework, refreshed
# by /setup-steward upgrade. Build artefact, not source.
/.apache-steward/
@@ -159,7 +159,7 @@ cat >> .gitignore <<'GITIGNORE'
/.github/skills/list-steward-*
GITIGNORE
-# 4. Tell your agent: "follow /setup-steward to finish adopting steward."
+# 4. Tell your agent: "follow /setup-steward to finish adopting Magpie."
# The skill will write .apache-steward.lock (committed) and
# .apache-steward.local.lock (gitignored), ask which skill family
# to wire up, create the gitignored framework-skill symlinks, and
@@ -171,7 +171,7 @@ GITIGNORE
## Method 2 — git tag
```bash
-# === apache-steward bootstrap — Method 2: pinned git tag ===
+# === Magpie bootstrap — Method 2: pinned git tag ===
# Replace <TAG> with the framework tag you want
# (e.g. `v1.0.0` once tags exist on apache/airflow-steward).
@@ -194,7 +194,7 @@ cp -r .apache-steward/.claude/skills/setup-steward
.claude/skills/setup-steward
# Add gitignore entries (same block as Method 1 step 3 — see there)
-# Tell your agent: "follow /setup-steward to finish adopting steward."
+# Tell your agent: "follow /setup-steward to finish adopting Magpie."
```
---
@@ -204,7 +204,7 @@ cp -r .apache-steward/.claude/skills/setup-steward
.claude/skills/setup-steward
The default WIP path while the framework is pre-release.
```bash
-# === apache-steward bootstrap — Method 3: git branch (default: main) ===
+# === Magpie bootstrap — Method 3: git branch (default: main) ===
cd /path/to/your/repo
BRANCH=main # or another branch you want to track
@@ -224,7 +224,7 @@ cp -r .apache-steward/.claude/skills/setup-steward
.claude/skills/setup-steward
# Add gitignore entries (same block as Method 1 step 3 — see there)
-# Tell your agent: "follow /setup-steward to finish adopting steward."
+# Tell your agent: "follow /setup-steward to finish adopting Magpie."
```
---
@@ -235,7 +235,7 @@ Once the recipe completes, `setup-steward` is in your repo
and
the snapshot is on disk (gitignored). Tell your agent:
```text
-follow .claude/skills/setup-steward to adopt steward
+follow .claude/skills/setup-steward to adopt Magpie
```
(or invoke `/setup-steward` directly). The skill walks through
diff --git a/docs/setup/secure-agent-setup.md b/docs/setup/secure-agent-setup.md
index 5b0be13..5d6b039 100644
--- a/docs/setup/secure-agent-setup.md
+++ b/docs/setup/secure-agent-setup.md
@@ -645,8 +645,8 @@ The operator picks one during install; both are reversible.
| Scope | What it covers | Mechanism | Reversal |
|---|---|---|---|
-| **Per-project** (default) | The single adopter repo the operator is sitting
in when running the install skill. Each subsequent adopter project needs the
install skill re-run there. | The helper runs once with `--all-worktrees`
against the current repo; nothing global is touched. The per-repo
`post-checkout` hook (installed by `/setup-steward adopt` in steward-adopted
repos) chains into the helper on future `git checkout` operations within that
repo. | None needed — per-project scope is [...]
-| **Whole-user** | Every git repo on the operator's host, existing and future.
Includes non-steward Claude-Code-aware projects (any project with a `.claude/`
directory). | Walks the operator's existing checkouts under prompted root dirs
and writes each one's `settings.local.json`; sets `git config --global
core.hooksPath ~/.claude/git-hooks/` and installs the universal
[`git-global-post-checkout.sh`](../../tools/agent-isolation/git-global-post-checkout.sh)
there. | `git config --global - [...]
+| **Per-project** (default) | The single adopter repo the operator is sitting
in when running the install skill. Each subsequent adopter project needs the
install skill re-run there. | The helper runs once with `--all-worktrees`
against the current repo; nothing global is touched. The per-repo
`post-checkout` hook (installed by `/setup-steward adopt` in Magpie-adopted
repos) chains into the helper on future `git checkout` operations within that
repo. | None needed — per-project scope is [...]
+| **Whole-user** | Every git repo on the operator's host, existing and future.
Includes non-Magpie Claude-Code-aware projects (any project with a `.claude/`
directory). | Walks the operator's existing checkouts under prompted root dirs
and writes each one's `settings.local.json`; sets `git config --global
core.hooksPath ~/.claude/git-hooks/` and installs the universal
[`git-global-post-checkout.sh`](../../tools/agent-isolation/git-global-post-checkout.sh)
there. | `git config --global -- [...]
#### Important trade-off — `core.hooksPath` shadows per-repo hooks
@@ -678,7 +678,7 @@ See
touch global git config.
- You have per-repo hooks (pre-commit, commit-msg, etc.) you
rely on and do not want shadowed.
- - You are evaluating apache-steward and have not yet decided
+ - You are evaluating Magpie and have not yet decided
whether to commit to the framework.
- **Pick whole-user** when:
diff --git a/docs/setup/unadopt.md b/docs/setup/unadopt.md
index 249c0ef..7e66a46 100644
--- a/docs/setup/unadopt.md
+++ b/docs/setup/unadopt.md
@@ -2,7 +2,7 @@
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
**Table of Contents** *generated with
[DocToc](https://github.com/thlorenz/doctoc)*
-- [Removing apache-steward from an adopter repo
(unadopt)](#removing-apache-steward-from-an-adopter-repo-unadopt)
+- [Removing Magpie from an adopter repo
(unadopt)](#removing-magpie-from-an-adopter-repo-unadopt)
- [Quick removal](#quick-removal)
- [Invocation](#invocation)
- [What you'll be asked to confirm](#what-youll-be-asked-to-confirm)
@@ -21,9 +21,9 @@
<!-- SPDX-License-Identifier: Apache-2.0
https://www.apache.org/legal/release-policy.html -->
-# Removing apache-steward from an adopter repo (unadopt)
+# Removing Magpie from an adopter repo (unadopt)
-If your project has decided to stop using apache-steward,
+If your project has decided to stop using Magpie,
or the adoption was experimental and is now over, this
page walks through the removal. It reverses everything an
install recipe in [`install-recipes.md`](install-recipes.md)
@@ -78,13 +78,13 @@ The following will be REMOVED:
<skills-dir>/<symlink-1> →
.apache-steward/.claude/skills/<skill-1>/
<skills-dir>/<symlink-2> → ...
.github/skills/<symlink-1> (Pattern B only — second
physical layer)
- .git/hooks/post-checkout (if it contains the steward
recipe)
+ .git/hooks/post-checkout (if it contains the Magpie
recipe)
Committed (will show in `git status`):
.apache-steward.lock (your project's pin)
- .gitignore (the steward entries)
+ .gitignore (the Magpie entries)
README.md (the adoption section, if
present)
- AGENTS.md (the apache-steward framework
section, if present)
+ AGENTS.md (the Magpie framework section,
if present)
CONTRIBUTING.md (the adoption section, if
present)
<skills-dir>/setup-steward/ (this skill itself —
self-destructive)
@@ -178,7 +178,7 @@ rm .claude/skills/<name>
### `post-checkout` hook with extra logic
If your `.git/hooks/post-checkout` contained anything
-beyond the steward `verify --auto-fix-symlinks` recipe,
+beyond the Magpie `verify --auto-fix-symlinks` recipe,
`unadopt` left the entire hook in place and told you which
line to delete. Edit it by hand:
@@ -201,12 +201,12 @@ grep apache-steward .gitignore
`unadopt` only touches your adopter repo. None of the
following are removed — retire each one only if you are
-also retiring apache-steward from this machine entirely:
+also retiring Magpie from this machine entirely:
- **`~/.config/apache-steward/user.md`** — the recommended
per-user identity / tool-picks config. One file, shared
across every adopter repo on this machine. If you still
- use apache-steward in any other repo, leave it.
+ use Magpie in any other repo, leave it.
Otherwise:
```bash
diff --git a/tools/agent-isolation/README.md b/tools/agent-isolation/README.md
index a7c4664..55e2635 100644
--- a/tools/agent-isolation/README.md
+++ b/tools/agent-isolation/README.md
@@ -35,7 +35,7 @@ versions.
| [`sandbox-status-line.sh`](sandbox-status-line.sh) | Claude Code
`statusLine` helper. Renders `<model> [sandbox]` (green) or `<model> [NO
SANDBOX]` (bold red) based on `sandbox.enabled` in the active settings —
project `settings.local.json` first, then project `settings.json`, then
user-scope, mirroring Claude Code's own precedence. Reflects in-session
`/sandbox` toggles (which persist to project `settings.local.json`).
Recommended user-scope. |
| [`sandbox-status-line-rich.sh`](sandbox-status-line-rich.sh) | Opt-in richer
alternative to `sandbox-status-line.sh`. Same sandbox-state detection, plus
folder name (hash-coloured), git branch + dirty + ahead/behind, per-branch PR
title (cached, gated by `gh`), and a yellow `[sandbox-auto]` tag for the
`autoAllowBashIfSandboxed` setting. Wire one *or* the other into
`statusLine.command`. |
| [`sandbox-add-project-root.sh`](sandbox-add-project-root.sh) | Adds the
current adopter repo's project root (and, with `--all-worktrees`, every linked
git worktree's working dir) as an explicit absolute path to
`sandbox.filesystem.allowRead` and `allowWrite` in the project-local,
gitignored `<repo>/.claude/settings.local.json` — one entry per worktree, each
in that worktree's own settings file. Defensive against [issue
#197](https://github.com/apache/airflow-steward/issues/197) — `allo [...]
-| [`git-global-post-checkout.sh`](git-global-post-checkout.sh) | Universal
`post-checkout` git hook installed at `~/.claude/git-hooks/post-checkout` when
the operator picks **whole-user** scope in `setup-isolated-setup-install`.
Activated by `git config --global core.hooksPath ~/.claude/git-hooks/` so every
`git checkout` / `git clone` / `git worktree add` across the host invokes it.
Two responsibilities (both best-effort + idempotent + `\|\| true`): (1)
`setup-steward verify --auto-fix- [...]
+| [`git-global-post-checkout.sh`](git-global-post-checkout.sh) | Universal
`post-checkout` git hook installed at `~/.claude/git-hooks/post-checkout` when
the operator picks **whole-user** scope in `setup-isolated-setup-install`.
Activated by `git config --global core.hooksPath ~/.claude/git-hooks/` so every
`git checkout` / `git clone` / `git worktree add` across the host invokes it.
Two responsibilities (both best-effort + idempotent + `\|\| true`): (1)
`setup-steward verify --auto-fix- [...]
## Usage at a glance
diff --git a/tools/egress-gateway/README.md b/tools/egress-gateway/README.md
index 847d1ca..1be0d90 100644
--- a/tools/egress-gateway/README.md
+++ b/tools/egress-gateway/README.md
@@ -19,7 +19,7 @@
**Capability:** capability:setup
A local **host-allowlisting HTTP(S) forward proxy** for the
-apache-steward framework. It is the egress-control chokepoint: framework
+Magpie framework. It is the egress-control chokepoint: framework
tools point `HTTPS_PROXY`/`HTTP_PROXY` at it, and the gateway rejects any
connection to a host that is not on its allowlist — before a socket is
opened. This is defence-in-depth for
diff --git a/tools/privacy-llm/checker/README.md
b/tools/privacy-llm/checker/README.md
index 8aa35eb..6b95125 100644
--- a/tools/privacy-llm/checker/README.md
+++ b/tools/privacy-llm/checker/README.md
@@ -31,7 +31,7 @@
# checker
Stdlib-only Python project implementing the approved-LLM gate-check
-for the apache-steward privacy-llm tool. One console script:
+for the Magpie privacy-llm tool. One console script:
| Console script | Purpose |
|---|---|
diff --git a/tools/privacy-llm/redactor/README.md
b/tools/privacy-llm/redactor/README.md
index e96f4fc..2abb2a6 100644
--- a/tools/privacy-llm/redactor/README.md
+++ b/tools/privacy-llm/redactor/README.md
@@ -31,7 +31,7 @@
# redactor
Stdlib-only Python project implementing the PII redactor for
-the apache-steward privacy-llm tool. Three console scripts:
+the Magpie privacy-llm tool. Three console scripts:
| Console script | Purpose |
|---|---|
diff --git a/tools/spec-loop/specs/overview.md
b/tools/spec-loop/specs/overview.md
index 2aebdc0..9d4881a 100644
--- a/tools/spec-loop/specs/overview.md
+++ b/tools/spec-loop/specs/overview.md
@@ -3,7 +3,7 @@
# Product overview
-Apache Steward (working name; rename in flight) is a **project-agnostic
+Apache Magpie is a **project-agnostic
framework for agent-assisted repository maintainership and development**.
It is not an application with a `src/` tree — it is a substrate plus a
catalogue of agent-readable **skills** (Markdown + YAML) and deterministic
