Skip to content

[umbrella] Estate control plane — close the automation loop (the last link was never connected) #633

Description

@hyperpolymath

The finding, in one line

The estate's automation chain is nearly complete and the last link was never connected. Detection works. Fan-out works. Nothing merges the result, so policy never lands.

Measured 2026-08-25

Measurement Value
Pinned references to standards reusables across the estate 1,152
Distinct SHA generations those pins span 25
Times standards current HEAD (d67def67) appears among them 0
Most-used pin (5b1d0022) 510 references

A policy change made in standards today reaches nothing. That is the symptom. Below is the cause.

The chain, and where it breaks

hypatia detects            gitbot-fleet dispatches        farm opens PRs           ??? merges them
(sha_bump_propagation.ex)  (fix-script-registry.json)     (sha-bump-propagate.sh)
      ✓ wired                     ✓ wired                    ✓ wired, ≤500 repos      ✗ NOTHING

Every merge path is off:

  • gitbot-fleet/inbox-steward.ymldisabled_manually (confirmed via the Actions API), NEUTERED 2026-06-16 by owner directive, */15 cron removed after the 3,041-notification burst of 2026-07-20/21
  • hypatia/merge-orchestrate.ymlactive, ticking hourly at :17, but token-free by design; its two token-bearing halves observe.sh and actuate.sh live in .git-private-farm/scripts/, were written 2026-07-13, and are called by no workflow anywhere in the estate
  • standards/scripts/propagate-workflow-pins.sh — header states it "NEVER commits or pushes"
  • farm/scripts/wait-for-pr-merge.sh — unwired

The architecture is correct. Hypatia holds no PAT so a compromised scanner cannot write to 400 repos; the privileged hands sit separately and independently re-verify safety invariants. That separation is good design. It was simply never plugged in.

Children

1. Wire the merge actuator ⟶ in progress, observe half shipped

Owner ruling 2026-08-25: observe-only first. Do not wire actuation before that review. The 3,041-notification incident is the thing being designed against.

2. One census, not three

Four numbers, none authoritative, all disagreeing:

Register Count How it updates
farm-manifest.json 25 (23 auto-propagate) hand-edited
farm/repo-list.txt 362 static snapshot, header says "Generated: 2026-05-12"
reposystem/repos.toml manual just repos-manifest
actual GitHub 418 (384 hyperpolymath + 34 metadatastician)

READMEs variously claim ~300, ~400, ~500. Nominate one authoritative register, regenerate it on a cron, derive the other two from it. A repo created today joins none of these lists.

3. Re-pin sweep — the payload the merge loop exists to deliver

Bring 1,152 references from 25 generations to standards HEAD. Supervised and batched. Blocked on child 1: without a merge path the PRs simply queue.

4. Arm the quality gate

  • 201 local repos run hypatia-scan.yml
  • 28 have .hypatia-baseline.json

hypatia-scan-reusable.yml arms its blocking gate only when the caller commits both the baseline and scripts/apply-baseline.sh. So ~173 repos run a scan whose own summary says it "never fails the build; a green check here does not mean zero critical findings." Nothing seeds a baseline into a new repo, so a fresh repo enters the estate permanently advisory.

5. Findings must become issues

Hypatia's scan output is SARIF plus a JSON artifact. gh issue create appears nowhere in its scan/rescan/remediation path. The only findings→issues path in gitbot-fleet is scripts/process-review-findings.sh:150, and the Justfile review recipe hardcodes --dry-run.

There is exactly one working model in the estate — farm/drift-detect.yml, which opens and updates a labelled drift issue on schedule. Copy it.

6. Ruleset propagation

hyperpolymath is a user account, so there are no org-level rulesets — migrate-classic-to-rulesets.sh says so in its own comments. Each of ~400 repos needs its own POST. Three scripts can do it (migrate-classic-to-rulesets.sh, ci-deadlock-realign-rulesets.sh, ci-deadlock-degate.sh); all three are --apply-gated and all three are unwired. ci-deadlock-realign.sh:163 refuses outright: "ruleset-imposed required contexts are reported but NOT auto-written; edit rulesets manually."

Coupled to cicd-squabbler's two unimplemented self-wins — required-context reconcile and reusable-workflow re-pin — which are blocked on exactly this API.

7. Mirroring covers 7%

batch-propagate.yml (Sun 03:00) iterates farm-manifest.json entries with auto_propagate == true23 repos of 418. drift-detect.yml checks the same 23. The other ~395 are mirrored to no forge and drift-checked never.

What each system contributes

Answering the question directly — how these five combine into full automation:

System Role State
standards policy authority + 12 reusable workflows ✅ works as a library; ✗ has no outbound propagation by design
rsr-template-repo the spine every repo is minted from ✅ substrate solid; ✗ instantiation is a human at an interactive prompt
hypatia detector, 33 rule modules the most wired repo in the estate
gitbot-fleet + .git-private-farm actuators ⚠️ fan-out wired, merge unwired
reposystem coordination layer, census, thread runner ✗ entirely human-invoked
cicd-squabbler per-repo pipeline fighter ✗ consumed by nothing; its two missing self-wins are what child 6 needs
oikosbot-estate measurement / DEA efficiency ⚠️ one snapshot only; ledger never reconciled

The missing piece that ties them together is chartered separately as git-logistics-office.


Horizon: pin counts are from hyper-repos/* + meta-repos/* local checkouts (1,152 references), not all 418 GitHub repos — the true figure is higher, not lower. Workflow states (disabled_manually, active) were read from the GitHub Actions API and are authoritative. Repo counts were cross-checked two ways and are not page-size artefacts.

Metadata

Metadata

Assignees

No one assigned

    Labels

    cicdCI/CD: workflows, actions, lockfiles, pins, runners, release gatesmeta:umbrellaParent issue aggregating child issuesscope:estateAffects many or all repos across the estate

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions