GitHub estate campaign backlog

Campaign status

Campaign	State	Completion boundary
1. Authoritative estate registry	Review-ready	Complete when the registry PR is merged and make estate-check passes on 114 visible repositories.
2. Repository front doors	Next	Repair active and maintained READMEs using the registry queue.
3. Lifecycle normalization	Prepared	Confirm proposed lifecycle assignments; apply archive/delete/settings actions separately.
4. Freshness and deployment truth	Prepared	Execute five current-data audits and public-surface checks.
5. Namespace and settings	Prepared	Produce rename packets; Matías applies settings changes.
6. Authority and topology	Prepared	Resolve the open collision report through bounded decision memos.
7. Light engineering quality	Deferred	Add SYSTEM.yaml, command adapters, and deeper checks only after semantic boundaries are accepted.
8. Annual maintenance	Seeded	Use the generated annual-review queue and refine cadence after the first cycle.

Campaign 1 definition of done

Campaign 1 is structurally complete when:

1. all repositories visible to the connected GitHub account search are represented exactly once;
2. paginated search and cohort counts reconcile;
3. every repository has every required governance field, with unknowns represented explicitly;
4. stable system identifiers and domains exist;
5. cross-repository relationships live in a separate edge registry;
6. unresolved authority collisions are first-class data;
7. all required reports are generated deterministically;
8. a standard-library validator passes;
9. the inventory scope and connector limitations are documented;
10. no product repository, settings, deployment, or runtime implementation is changed.

Semantic certainty is not required for every repository. The registry distinguishes observed metadata from proposed interpretation so that later work can refine the control plane cumulatively.

Immediate next campaign

After Campaign 1 is merged, start the README/front-door campaign from generated/missing-entrances.csv.

The first batch should prioritize explicit repair-required entries, especially active public surfaces and repositories making live-data or deployment claims. Unknown entrances should be inspected before editing rather than upgraded automatically.

The expanded campaign rationale and historical disposition remain in notes/compiled-github-estate-backlog.md.