You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The estate CI outage is a heal-then-wipe oscillation, not a one-shot allowlist gap:
The ci-health sweep (scripts/ci-health/{detect,remediate,sweep}.sh) does repopulate allowlists correctly — observed 0 B-ALLOWLIST repos at 06:32Z after a sweep, using the curated superset (action-superset.txt, 76 required patterns incl. hyperpolymath/*).
But allowlists get wiped back to empty/selected-with-no-patterns again afterward, re-triggering startup_failure estate-wide. Something off-tree / outside this repo is resetting actions/permissions/selected-actions on a cadence that undoes the daily sweep.
The detector improvement from #625 (fire B-ALLOWLIST on incomplete supersets, not only missing hyperpolymath/*) is merged and helps the incomplete class, but does not address the wipe itself — the wipe produces fully-empty allowlists that were already detected.
What's needed (owner decisions — I can't reach these)
Find & stop the off-tree wipe. Identify what resets the allowlists (an org-level policy job? a settings-repo apply? a different automation?) and stop it, or make it emit the curated superset instead of clearing.
Cadence decision. Until (1) lands: run the sweep.sh remediation on a schedule that out-paces the wipe, or accept manual re-runs. (Live actions/permissions PUTs are mutating and need explicit go-ahead.)
REST never exposes the startup_failurereason (only the web-UI banner), which is why classification relies on allowed_actions + patterns_allowed shape rather than the run conclusion.
Summary (owner-gated — off-tree root cause)
The estate CI outage is a heal-then-wipe oscillation, not a one-shot allowlist gap:
ci-healthsweep (scripts/ci-health/{detect,remediate,sweep}.sh) does repopulate allowlists correctly — observed 0B-ALLOWLISTrepos at 06:32Z after a sweep, using the curated superset (action-superset.txt, 76 required patterns incl.hyperpolymath/*).selected-with-no-patterns again afterward, re-triggeringstartup_failureestate-wide. Something off-tree / outside this repo is resettingactions/permissions/selected-actionson a cadence that undoes the daily sweep.The detector improvement from #625 (fire
B-ALLOWLISTon incomplete supersets, not only missinghyperpolymath/*) is merged and helps the incomplete class, but does not address the wipe itself — the wipe produces fully-empty allowlists that were already detected.What's needed (owner decisions — I can't reach these)
settings-repo apply? a different automation?) and stop it, or make it emit the curated superset instead of clearing.sweep.shremediation on a schedule that out-paces the wipe, or accept manual re-runs. (Liveactions/permissionsPUTs are mutating and need explicit go-ahead.)startup_failurehistory — those are a different failure class from the incomplete-allowlist class fix(ci-health): detect incomplete allow-lists, not just missing hyperpolymath/* #625 targets.Notes
startup_failurereason (only the web-UI banner), which is why classification relies onallowed_actions+patterns_allowedshape rather than the run conclusion.