Skip to content

docs: Update CE Meta integration references #73

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
j3w1 merged 2 commits into from
Oct 14, 2026
Merged

docs: Update CE Meta integration references #73

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
61763cb
docs: Update CE Meta integration references
j3w1 Oct 14, 2026
c533ce7
Correct the active CE Meta labels authority
j3w1 Oct 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 19 additions & 19 deletions AGENTS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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),
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).
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
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.

Expand All @@ -174,41 +174,41 @@ 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
conflicting structural rules both fail closed. An incomplete changed-file list fails a *universal*
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.
Loading