Developer control loop

projects should reduce developer overhead, not create a second project-management job.

The operating loop is therefore:

sense remote facts
      ↓
project drift
      ↓
triage only material changes
      ↓
decide semantic/lifecycle changes
      ↓
execute in the owning repository
      ↓
verify there
      ↓
reproject the estate

What should run by itself

Mechanical observation is a good automation target:

• repository existence and GitHub numeric identity;
• current repository name after rename;
• visibility/archive/default-branch metadata;
• recent push/readiness evidence;
• whether a selected repository exposes SYSTEM.yaml, AGENTS.md, Makefile, workflows and obvious public entrances;
• whether committed generated projections still match canonical estate sources.

These facts may become stale quickly and do not require a portfolio decision merely to observe them.

What must remain reviewable

Automation must not infer or silently mutate:

• lifecycle (active, maintenance, superseded, archive readiness);
• authority ownership;
• scientific or accounting semantics;
• a canonical provider or crosswalk policy;
• repository archive/delete/visibility settings;
• system membership from name similarity;
• runtime compatibility merely because two repositories changed recently.

The machine should surface those as bounded drift, not manufacture an answer.

Two-layer estate

Observed layer

Fresh factual evidence from GitHub. GitHub numeric repository ID is the durable observed identity. Repository name is a mutable locator.

The current operator command is:

make estate-scan

It requires authenticated GitHub access and writes the observed inventory evidence. It is deliberately excluded from ordinary CI.

Semantic layer

The curated registry under estate/ describes domain, system, role, lifecycle and authority. It may lag the observed layer temporarily without making the observed facts false or forcing a rushed semantic decision.

make estate-observation-all

projects known drift into reviewable generated artifacts.

One human-facing sensing command

For an authenticated operator:

make sense

refreshes the account inventory, refreshes the selected-core readiness evidence, and projects estate observation drift. It does not change another repository.

The normal deterministic gate remains:

make check

make check never requires network credentials.

Automation decision

A scheduled GitHub Actions sensing job is useful only when it can observe the same estate that the human can. The repository-scoped GITHUB_TOKEN is not assumed to have account-wide private-repository visibility.

Therefore a cadence should be enabled only after a dedicated read-only account/installation credential is configured for sensing. If that credential is installed, the preferred behavior is:

1. run one or two times per week, not continuously;
2. update one consolidated observation branch/PR or one consolidated drift issue;
3. remain silent when there is no material drift;
4. never auto-merge semantic/lifecycle decisions;
5. never use the sensing credential to write to participating repositories.

Until that credential exists, adding a scheduled workflow would create either false completeness or recurring red noise. make sense is the truthful intermediate operator path.

Grooming rule

Backlog is downstream of current evidence. Before executing an old queue item:

1. check whether recent repository work already satisfied its acceptance condition;
2. check whether the repository boundary changed enough to make the item obsolete;
3. close/reclassify completed or superseded work instead of preserving it for historical continuity;
4. create new work only for a current red state with an observable acceptance condition.

The desired steady state is a small exception queue, not an exhaustive list of everything that could be improved.