apache · potiuk · Jul 11, 2026 · Jul 11, 2026
diff --git a/.asf.yaml b/.asf.yaml
@@ -18,7 +18,7 @@
 # https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
 ---
 github:
-  description: "Agent-assisted maintainership and development framework for Apache projects — Triage and Drafting (agent-authored fixes with human review); Mentoring, Pairing (developer-side dev-cycle), and Auto-merge on the roadmap."
+  description: "Agent-assisted maintainership and development framework for Apache projects — Triage, Mentoring, Drafting (agent-authored fixes with human review), and Pairing (developer-side dev-cycle) skills shipping; Agentic Autonomous (auto-merge) on the roadmap."
   homepage: "https://magpie.apache.org/"
   labels:
     # Note that GitHub only supports <=20 labels/topics per repo! Pipeline
@@ -111,17 +111,19 @@ github:
   # ever existed, so the protection now lives here next to the rest
   # of the repo config.
   #
-  # TEMPORARY POSTURE — REVISIT AT PMC FORMATION
-  # --------------------------------------------
-  # Pull-request approvals are intentionally NOT required while the
-  # framework is in its bootstrap phase under the Airflow PMC
-  # umbrella with a small set of committers (see MISSION.md). Once
-  # the project establishes its own PMC, this block MUST be
-  # revisited: add a `required_pull_request_reviews:` section with
+  # PMC FORMED — REVIEW REQUIREMENT IS A PMC DECISION
+  # -------------------------------------------------
+  # Pull-request approvals are currently NOT required. This was the
+  # bootstrap posture from when the framework ran under the Airflow
+  # PMC umbrella with a small set of committers (see MISSION.md);
+  # Magpie is now a Top-Level Project with its own PMC, so the PMC
+  # should decide whether to keep self-merge-after-CI or add a
+  # `required_pull_request_reviews:` section with
   # `required_approving_review_count: 1` (or higher) and
   # `dismiss_stale_reviews` / `require_code_owner_reviews` tuned to
-  # the new committer / CODEOWNERS shape. Until then, status checks
-  # alone gate merges — a maintainer can self-merge after CI green.
+  # the committer / CODEOWNERS shape. Until the PMC changes it,
+  # status checks alone gate merges — a maintainer can self-merge
+  # after CI green.
   protected_branches:
     main:
       # Required status checks. Listed contexts MUST run on every PR
@@ -174,7 +176,8 @@ github:
           # same.
           - "tests-ok"
       # `required_pull_request_reviews:` deliberately omitted — see
-      # the TEMPORARY POSTURE note above. Re-add at PMC formation.
+      # the PMC-decision note above. Re-add once the PMC settles the
+      # review requirement.
       #
       # Linear history matches `enabled_merge_buttons.squash: true`
       # above — squash is the only enabled merge mode, so every
@@ -191,19 +194,14 @@ github:
       required_signatures: false
 
 notifications:
-  # The framework is hosted under the Airflow PMC umbrella, and its
-  # commit / PR / issue / discussion traffic lands on the PMC's own
-  # lists rather than the previously-used `dev-magpie@` sub-list.
-  # Traffic volume on the Airflow PMC's lists is already strong and
-  # noisy enough that adding this repo's events does not materially
-  # change the signal/noise profile — separating them onto a
-  # dedicated sub-list was not worth the cost of subscribers having
-  # to follow a second list to see what was happening here. When the
-  # framework eventually moves to its own TLP it will inherit its
-  # own `commits@` list and the schemes below will be re-pointed at
-  # that list in the same change.
+  # Magpie is a Top-Level Project with its own mailing lists. All
+  # commit / PR / issue / discussion traffic routes to the project's
+  # own `commits@magpie.apache.org` list. (During the bootstrap phase
+  # the framework ran under the Airflow PMC umbrella and its events
+  # rode the Airflow PMC's lists; with TLP status Magpie now has its
+  # own `commits@` and the schemes below point at it.)
   #
-  # Routing follows Airflow's `.asf.yaml` destinations:
+  # Routing:
   #   - jobs            → jobs@    (CI run notifications)
   #   - everything else → commits@
   #

diff --git a/MISSION.md b/MISSION.md
@@ -29,6 +29,13 @@
 
 # Apache Magpie
 
+> [!NOTE]
+> **Status:** Apache Magpie was established as an Apache Top-Level
+> Project by ASF Board resolution on **17 June 2026**.
+> The text below is the original establishment proposal, kept as a
+> historical record of the project's founding mission, scope, and
+> design commitments.
+
 > [!IMPORTANT]
 > **Motto:** *"Give maintainers time back, so they can do what matters."*
 

diff --git a/README.md b/README.md
@@ -37,10 +37,10 @@ for the canonical distribution mechanism we will adopt.
 
 > [!IMPORTANT]
 > The motivation, scope, and design commitments behind this work
-> live in [`MISSION.md`](MISSION.md) — the **draft** project-
-> establishment proposal for an Apache Top-Level Project built on
-> this framework. Read that for the *why*; this README is the
-> *how* once you've decided to adopt.
+> live in [`MISSION.md`](MISSION.md) — the founding mission of the
+> Apache Magpie Top-Level Project, originally filed as its
+> establishment proposal. Read that for the *why*; this README is
+> the *how* once you've decided to adopt.
 
 ## How adoption works
 

diff --git a/docs/board-resolution-draft.md b/docs/board-resolution-draft.md
@@ -13,10 +13,11 @@
 
 # Board resolution — Establish the Apache Magpie Project (draft)
 
-> **Status:** *Draft.* Working text for the forthcoming ASF Board resolution
-> establishing Apache Magpie as a Top-Level Project. The companion supporting
-> document is [`MISSION.md`](../MISSION.md), which the Board is expected to
-> read alongside the resolution.
+> **Status:** **Adopted.** Apache Magpie was established as an Apache
+> Top-Level Project by ASF Board resolution on **17 June 2026**.
+> The text below is the establishment resolution as drafted, kept as a
+> historical record. The companion supporting document is
+> [`MISSION.md`](../MISSION.md), which the Board read alongside the resolution.
 >
 > The resolution itself is short and procedural by ASF convention; rationale,
 > roster lineage, scope justification, and the donated-code story live in

diff --git a/docs/rfcs/RFC-AI-0002.md b/docs/rfcs/RFC-AI-0002.md
@@ -59,7 +59,7 @@ This RFC proposes a layered, opt-in secure setup that an ASF project handling *
 
 The setup is built around four layers — a **clean-env shell wrapper**, a **filesystem sandbox** (bubblewrap on Linux, Seatbelt on macOS), a set of **tool-permission rules** in the agent's own configuration, and a **forced-confirmation** policy for write-side actions visible to others — plus two **visibility mechanisms** (a status-line indicator and a per-call bypass-warn hook) that make sandbox state continuously legible to the operator.
 
-A reference implementation ships in the [`apache/magpie`](https://github.com/apache/magpie) incubator-podling project (the ASF Incubator's maintainership tooling for a tracker repo). This RFC abstracts the lessons of that implementation into a pattern other ASF projects can adopt with or without depending on `magpie` itself.
+A reference implementation ships in the [`apache/magpie`](https://github.com/apache/magpie) Top-Level Project (agent-assisted repository maintainership tooling for a tracker repo). This RFC abstracts the lessons of that implementation into a pattern other ASF projects can adopt with or without depending on `magpie` itself.
 
 ## Motivation