From 61763cb52871fd96ab915514e1063e18253796d7 Mon Sep 17 00:00:00 2001 From: j3w1 Date: Tue, 13 Oct 2026 20:15:36 -0500 Subject: [PATCH 1/2] docs: Update CE Meta integration references --- AGENTS.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 20b10744..2e13d976 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -146,25 +146,25 @@ generated inline color swatch (D-014). - Do not claim a manual keyboard or screen-reader pass without a recorded protocol and environment. -## CE Metadata integration +## CE Meta integration -This repository joined the CE Metadata portfolio on 2026-09-22. Nothing is installed here and -nothing is imported: CE Metadata is a service that reads this repository through one GitHub App +This repository joined the CE Meta portfolio on 2026-09-22. Nothing is installed here and +nothing is imported: CE Meta is a service that reads this repository through one GitHub App installation, and this section is the cooperation contract an agent working in it needs. **Right now it writes nothing here.** Being in the portfolio means this repository is read and censused and its objects are visible. It does not mean any writer reaches them. Reviewed classification rules may decide labels only in the repositories named by -`classification_authority.repositories` in [`policy/object-metadata.yaml`](https://github.com/j3w1/ce-metadata/blob/main/policy/object-metadata.yaml), +`classification_authority.repositories` in [`policy/object-metadata.yaml`](https://github.com/j3w1/ce-meta/blob/main/policy/object-metadata.yaml), and the canonical label definitions are written only in the repositories named by -`coverage_repositories` in [`policy/label-management.yaml`](https://github.com/j3w1/ce-metadata/blob/main/policy/label-management.yaml). +`coverage_repositories` in [`policy/label-management.yaml`](https://github.com/j3w1/ce-meta/blob/main/policy/label-management.yaml). This repository is in neither yet. Each is its own reviewed change, made once this repository's corpus has been classified — so the first labels that appear here will have been reviewed before they were written, not after. **Protected CE label prefixes:** `ce-systems`, `cross-repo`, `historical-evidence`, `type:`, `area:`, `concern:`. Labels outside them are never touched — including the ones GitHub creates by -default and the ones Dependabot applies. Within them CE Metadata is authoritative once a writer +default and the ones Dependabot applies. Within them CE Meta is authoritative once a writer reaches this repository: a reviewed rule states an object's whole managed label set, so a CE label added by hand and absent from that rule is drift, and the sweep removes it. @@ -174,14 +174,14 @@ the labels are wrong, the reviewed policy is wrong: report the exact object, the the plan and the readback, and the fix is a policy change. **Classification decides labels; it is not only evidence.** Every sweep classifies uncovered -objects, and since [ADR 0038](https://github.com/j3w1/ce-metadata/blob/main/docs/adr/0038-reviewed-classification-rules-as-label-authority.md) +objects, and since [ADR 0038](https://github.com/j3w1/ce-meta/blob/main/docs/adr/0038-reviewed-classification-rules-as-label-authority.md) a complete, canonical, unambiguous classification derived from reviewed rules *is* an object's exact managed label set where no explicit reviewed rule covers it — in the repositories that declaration names. The half that fails closed matters more here. An object whose evidence does not decide a single `type:` and a single `area:` sits at `NEEDS_REVIEW` and writes nothing. Since -[ADR 0039](https://github.com/j3w1/ce-metadata/blob/main/docs/adr/0039-semantic-pr-evidence.md) a pull request is classified from the +[ADR 0039](https://github.com/j3w1/ce-meta/blob/main/docs/adr/0039-semantic-pr-evidence.md) a pull request is classified from the files it changed **as well as** its title: where they disagree in an exclusive namespace structure wins and the title rule's whole contribution is set aside, and where they agree they merge. Within one class of evidence there is no principled winner, so two conflicting title rules and two @@ -189,26 +189,26 @@ conflicting structural rules both fail closed. An incomplete changed-file list f fact closed — "every path here is documentation" cannot be established from a truncated list — but an *existential* one can still hold. -Since [ADR 0046](https://github.com/j3w1/ce-metadata/blob/main/docs/adr/0046-classification-evidence-from-title-convention.md) the +Since [ADR 0046](https://github.com/j3w1/ce-meta/blob/main/docs/adr/0046-classification-evidence-from-title-convention.md) the classifier reads this portfolio's own title conventions: a conventional-commit prefix (`feat:`, `fix:`, `ci:`), a leading imperative verb, or an identifier or bracketed tag followed by one. The identifier itself is skipped and cannot be read — the patterns answer identically for any scheme — so a `CE-####` prefix implies neither a type nor an area. What decides a type is the verb after it. -**No CE task identifier is allocated by any of this.** CE Metadata cannot create `CE-GD`, `HQ`, +**No CE task identifier is allocated by any of this.** CE Meta cannot create `CE-GD`, `HQ`, `IAR`, `IAP`, `MQ`, `D3` or `DONE` state, approve anything, mark anything ready, or merge. This repository's existing delivery process is untouched. **Do not create a competing writer.** A second workflow, Action or agent writing the same labels or the same Project membership is exactly the failure `NO_DUAL_WRITER` exists to prevent. Project membership is written by the owner-authenticated Project bridge, never by the App, and Project -Status belongs to GitHub's own native workflows rather than to CE Metadata. +Status belongs to GitHub's own native workflows rather than to CE Meta. **This repository's profile is reviewed policy, not a claim made here.** Its role is `design-system`, its membership writer is `OWNER_AUTHENTICATED_BRIDGE`, its default area is `area:design-system`, and the prefixes above are what protected policy currently allows it. Read them from -[`policy/repositories.yaml`](https://github.com/j3w1/ce-metadata/blob/main/policy/repositories.yaml) rather than from this file, and +[`policy/repositories.yaml`](https://github.com/j3w1/ce-meta/blob/main/policy/repositories.yaml) rather than from this file, and verify the live grant before assuming a writer is active — a grant names exact repositories and, at a canary ring, exact objects, so being in the allowlist is not the same as being covered by a live grant. From c533ce764c94b6b1f6439267c29920e4ad9c2c6a Mon Sep 17 00:00:00 2001 From: j3w1 Date: Tue, 13 Oct 2026 21:32:46 -0500 Subject: [PATCH 2/2] Correct the active CE Meta labels authority --- AGENTS.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 2e13d976..bd352dbe 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -152,15 +152,15 @@ This repository joined the CE Meta portfolio on 2026-09-22. Nothing is installed nothing is imported: CE Meta is a service that reads this repository through one GitHub App installation, and this section is the cooperation contract an agent working in it needs. -**Right now it writes nothing here.** Being in the portfolio means this repository is read and -censused and its objects are visible. It does not mean any writer reaches them. Reviewed -classification rules may decide labels only in the repositories named by -`classification_authority.repositories` in [`policy/object-metadata.yaml`](https://github.com/j3w1/ce-meta/blob/main/policy/object-metadata.yaml), -and the canonical label definitions are written only in the repositories named by -`coverage_repositories` in [`policy/label-management.yaml`](https://github.com/j3w1/ce-meta/blob/main/policy/label-management.yaml). -This repository is in neither yet. Each is its own reviewed change, made once this repository's -corpus has been classified — so the first labels that appear here will have been reviewed before -they were written, not after. +**It writes labels here.** This repository is named by `classification_authority.repositories` in +[`policy/object-metadata.yaml`](https://github.com/j3w1/ce-meta/blob/main/policy/object-metadata.yaml) +and by `coverage_repositories` in +[`policy/label-management.yaml`](https://github.com/j3w1/ce-meta/blob/main/policy/label-management.yaml), +so the App's labels writer applies the exact managed label set that reviewed policy decides for each +object here, and the label-definition writer keeps the canonical label definitions here. Whether any +other writer reaches an object here — a rule in `policy/repository-metadata.yaml`, or a Project +membership grant — is stated by that policy and its live grant, not by this file. An object whose +reviewed evidence decides nothing sits at `NEEDS_REVIEW` or `HOLD` and writes nothing. **Protected CE label prefixes:** `ce-systems`, `cross-repo`, `historical-evidence`, `type:`, `area:`, `concern:`. Labels outside them are never touched — including the ones GitHub creates by