Skip to main content

Repository health authority

Status​

Canonical semantic boundary for repository-estate health and readiness.

Owner​

projects owns repository-health semantics because repository health is a property of the GitHub estate, not of Office operational fronts.

Meaning​

Repository health is not one score. It is a projection over distinct estate-owned dimensions:

  • identity — stable repo_id and current GitHub name;
  • lifecycle — declared repository lifecycle and authority posture;
  • observability — whether current remote metadata has been sensed and when;
  • contract readiness — presence/consistency of declared repository contracts such as SYSTEM.yaml;
  • operational readiness — bounded outstanding readiness actions already defined by the estate policy;
  • evidence freshness — age and provenance of the observation used for the projection.

A repository may be healthy on one dimension and require action on another. Consumers must not collapse these dimensions into a universal quality score unless a separate policy explicitly defines that aggregation.

Authority rules​

  1. projects defines repository-health/readiness vocabulary and projections.
  2. Authenticated sensing records facts only. It never changes lifecycle or authority automatically.
  3. Participating repositories remain authoritative for their own runtime behavior and domain semantics.
  4. projects never imports or executes arbitrary participating-repository code to determine health.
  5. Missing/stale observations produce unknown or action-needed context, not invented conclusions.
  6. Office may consume repository context, but repository context does not directly mutate Front Registry, Carry State, horizon, priority, or escalation.

Safe sensing boundary​

Allowed estate sensing is GitHub-remote, metadata-only, deterministic or reproducibly projected from committed evidence. Examples include:

  • repository accessibility, visibility, archived state, and default branch;
  • presence of root AGENTS.md, Makefile, SYSTEM.yaml, or selected workflow metadata;
  • bounded workflow classification/outcome observations;
  • declared lifecycle/system/authority metadata;
  • outstanding readiness actions from the existing readiness policy.

Not part of this control plane:

  • running repository Make targets, tests, notebooks, migrations, scrapers, or models;
  • inspecting uncommitted local environments;
  • executing repository-specific plugins;
  • mutating repository settings, issues, releases, deployments, or data;
  • treating activity recency as an automatic lifecycle decision.

Compatibility with Office Repo Health​

office-auto-lab historically hosts a broader Repo Health engine containing policy, plugins, local execution, cloud persistence, compiler logic, and operational surfaces. After this migration:

  • semantic authority lives here;
  • safe estate sensing/projection lives here;
  • any remaining Office implementation is compatibility-only and must not redefine repository-health meaning;
  • local/plugin execution that violates the safe sensing boundary is not migrated merely to achieve code ownership symmetry.

Public projection​

context:github-repositories@1 is the bounded downstream projection. It is keyed by repo_id, contains no front_id, and may expose lifecycle, readiness, observation time, and factual signals. Office owns any front-to-repository association and any operational consequence.