CI/CD regularisation: owner decisions O1–O10 (batch, non-blocking)

[hyperpolymath]

Spec: PR #714 → docs/superpowers/specs/2026-09-02-cicd-regularisation-design.md (§12). One reply covering all ten is enough; execution steps 1–3 proceed regardless.

• O1 GitHub Team for metadatastician. Open https://education.github.com → dashboard → "Upgrade your academic organizations". Is metadatastician listed? If yes, upgrade (free). If not, apply for GitHub for Nonprofits (Team free). Until then metadatastician stays on per-repo rulesets (org rulesets 403 "Upgrade to GitHub Team", live 2026-09-02).
• O2 Settings App (Probot) — is it installed anywhere? If not, every .github/settings.yml is dead and gets deleted.
• O3 Dispositions: boj-build.yml "BoJ Server Build Trigger" (255 repos; DROP if BoJ retired) · mirror.yml targets (142 repos skip for missing forge secrets: keep on which?) · rhodibot.yml (93 repos, 78% red: retire or remake?) · ClusterFuzzLite cflite_* (keep on which Rust/Zig repos?).
• O4 Repo moves beyond the first cut (games, befunge-cracker, stealth-glider → metadatastician; proofs/tooling stay). List any others, or "later".
• O5 Three bypass-actor app IDs I cannot resolve (API returns 403 to a gh token): 1561, 85455, 946600. Settings → Applications on the account shows names. Remove if unrecognised?
• O6 Gates vs bypass. Bypass applies to the whole ruleset, status checks included, so all nine bypass apps can merge around every GATE. Options: (a) single ruleset as planned, or (b) a second checks-only ruleset with bypass = claude, dependabot, github-actions, oikosbot, so the AI reviewers are held to the gates. Default if silent: (a).
• O7 Julia private registry. julia-professional-registry exists. If Dependabot's Julia support cannot read it (pilot will tell), Renovate stays on those repos only. Acceptable?
• O8 Squash-only, knowingly. Correction to the plan text: the LIVE ruleset (Optimus-Branch, every sampled repo) has no required_linear_history and allows merge, squash and rebase. The plan would ADD linear history and lock squash, because squash is the only method GitHub can sign server-side while keeping history linear (rebase merges cannot be signed). On 08-31 you replaced a ruleset on two repos to allow merge commits, so this is a real choice: (a) add linear history + squash-only estate-wide, or (b) keep merge commits allowed and no linear-history rule. Which?
• O9 metadatastician app installs with no ruling: slack, microsoft-teams-for-github, thanks-dev, linear-data-importer, linear-code. Keep or uninstall? (codacy-production, gitar-bot, renovate, semgrep-app go per R1/R4/R5.)
• O10 workflow-templates/ on a User-account .github. GitHub documents it for organisations only. I will plant one and check the "New workflow" page; if invisible, hyperpolymath new-repo distribution = rsr-template-repo only. No action from you unless you prefer another route.

[hyperpolymath]

O11 — plant the estate App credential on standards (found during step 1, 2026-09-02)

hyperpolymath/standards holds no GitHub App credential: gh variable list has no APP_ID, gh secret list has no APP_PRIVATE_KEY. signed-push-smoke.yml reads both and has failed on every run since 2026-08-24 (e.g. run 32717664038).

Two things in the approved design depend on that credential and are blocked until it exists:

• the periodic lock-refresh workflow (spec §6.4) that owns actions.lock pin bumps estate-wide;
• App-created tags under config/rulesets/immutable-tags.json (creation reserved to admins + OikosBot 2538504 in always mode).

Decision needed: which App is the estate App — OikosBot (2538504, your own) or a new one — then plant APP_ID (Actions variable) and APP_PRIVATE_KEY (Actions secret) on hyperpolymath/standards only. One credential, one repo. The smoke workflow going green is the acceptance test.

Until then: tags stay admin-only, and lock refresh is manual.

Also recorded in step 1 (no decision needed, FYI): ADR- autolinks are repo-local everywhere, not estate-central; 92 repos (35 of them metadatastician) have no autolinks at all; 10 repos point ADR- at a repo that has since been renamed.

[hyperpolymath]

O12 (new) + one FYI, from the step-1 canon review (PR #716)

O12 — allowlist enforcement. config/settings/actions-allowlist.json keeps verified_allowed: true. That means Marketplace-verified creators (Snyk, Codecov, SonarSource, Semgrep…) run whether or not they are on the pattern list, so the 118→92 prune is hygiene only; R1 is actually enforced by deleting the workflows in the sweep. Decision: after the sweep, flip verified_allowed to false? I will only propose it once a uses: census proves every verified-creator action still in use is on the explicit list. Default if unruled: stays true.

FYI, no decision needed. base.json gives every bypass actor (admin included) mode pull_request and has no always actor. After apply, main is PR-only for everyone, including you: a direct push, force-push or branch delete bounces. The live rulesets let maintain-role always through; the canon drops that on purpose. Emergency path = temporarily disable the ruleset in Settings → Rules, push, re-enable.

Also fixed in #716 and worth knowing: the copied ADR- autolink (docs/decisions/ADR-<num>.adoc) 404s on every repo because ADR files are named ADR-<num>-<slug>.adoc. Canon uses a code-search URL instead.

[hyperpolymath]

O13 + O14 + O8 evidence, from the double-track-browser pilot (2026-09-02)

O13 — security.txt MUST or SHOULD? The Well-Known (RFC 9116 + RSR) governance job (spec §14, folding wellknown-enforcement.yml, 60 repos) blocks on a missing /.well-known/security.txt. Ruling wanted: MUST (keep blocking, every public repo ships one) or SHOULD (warn only, blocks nothing). Until ruled the job keeps today's severity.

O14 (new) — bypass actors are per-repo installs. The first live PUT of config/rulesets/base.json (over ruleset 10843345 on double-track-browser) returned 422 three times: Actor GitHub Actions integration must be part of the ruleset source or owner organization, then the same for ChatGPT Codex Connector; copilot-swe-agent is not installed there either. A bypass Integration must be installed on that repository. So the R3 list is a superset; the step-3 applier will filter it to installed apps and report what it dropped per repo. Decision wanted: when an R3 app is not installed on a repo, (a) silently omit it (proposed), or (b) install it estate-wide so the bypass list is uniform.

O8 evidence. double-track-browser's ruleset history shows an owner edit on 2026-08-31 10:33 BST, so it is one of the two repos where merge commits were re-allowed. The pilot PUT kept allowed_merge_methods: [merge, squash, rebase] rather than forcing squash-only; nothing else from the live ruleset survived. O8 still needs the estate-wide answer.

Pilot result so far: ruleset 10843345 now = Base rules (deletion, non_fast_forward, required_signatures, pull_request, required_status_checks) with 17 machine-derived contexts; six unsatisfiable rules and the four phantom contexts (CodeQL, CodeRabbit, SonarCloud, Code quality + docs) are gone. rust-ci.yml is absent there despite rust_core/Cargo.toml, so no Rust gate context was derived (reported, not invented).

[hyperpolymath]

Batch update 2026-09-03 — smtp-notify-action track, plus O11/O12

One reply resolves all of these. Nothing here is blocking; each item says what
happens if you say nothing.

1. Apply the Base ruleset to smtp-notify-action (one command)

The repo has no ruleset at all (verified three times). So main is
unprotected, and PRs #12 and #13 merged CLEAN because nothing is required —
not because gates bound them. That is the same fake-green shape we have been
hunting estate-wide, in the one repo we are holding up as the model.

gh api -X POST repos/hyperpolymath/smtp-notify-action/rulesets \
  --input /home/hyperpolymath/developer/.claude/checkpoints/ruleset-smtp-notify-action-base.json

The JSON is the canonical Base shape from the design spec: squash-only, 0
approvals, signatures, linear history, deletion + non-fast-forward, and three
required contexts. Two deliberate departures, both worth your eye:

• Bypass = RepositoryRole admin only. No app list. A bypass app that is
  not installed on the repo 422s the entire PUT, and the estate list is a
  superset. It also means Dependabot and the bots must actually pass the gates
  here.
• The Gmail TLS canary is NOT a required context. It talks to an external
  server and can go red for a reason that is not about our code. Required
  contexts must be things we control.

The three contexts were derived from the live check-runs API and
diff-matched against emitted job names — zero phantom contexts. They were not
typed. (Typed contexts are how we got seven spellings of "CodeQL".)

2. Does the A4 sweep wait for a v0.2.0 tag? ← the one real decision

This is the item I would most like an answer on.

Resuming the A4 sweep now repins roughly 320 remaining repos at @v0.1.0,
whose secure input fails open — an unrecognised value silently meant
plaintext. The fix (fail-closed, with an explicit plaintext opt-in) is merged
on main and untagged. So a sweep today propagates the known-bad transport
default to 320 repos, and a later retag does not reach them.

• Say "wait" → I hold A4 until you cut v0.2.0, then sweep once at the good tag.
• Say "go" → I sweep at v0.1.0 and we accept a second sweep later.
• Say nothing → I hold. Repinning 320 repos to a fail-open default is not a
  default I will pick unattended.

Estate exposure today is zero: every existing consumer pins @v0.1.0 or a
SHA, so nothing changes under anyone until we sweep.

3. Cutting v0.2.0 — the part that is easy to get wrong

The tag is yours to cut, but it is not just git tag. action.yml carries the
release asset URL and both binary SHA-256 pins, and they must be correct in
the tagged commit itself, because consumers pin the action ref and the ref
determines the binary:

• line 118 — asset URL, still says v0.1.0
• lines 107 / 111 — x86_64 and aarch64 SHA-256 pins

Tag first and those three lines point a v0.2.0 action at v0.1.0 binaries.
The merge-to-tag window is open and documented in CHANGELOG.adoc.

4. Mail credentials — census result

I ran a full census rather than leaving the old six-repo claim standing.
434 repos (all hyperpolymath + metadatastician), all three Actions-readable
tiers — repo-level secrets, repository-environment secrets, and the
metadatastician org. 434 of 434 rows returned ok; zero error rows, which
is the number that makes an absence result mean anything: with errors present, an
empty column and a failed call look identical.

• 293 repos hold at least one repo-level secret; 36 distinct names estate-wide.
• 355 repos have an environment (351 github-pages, plus copilot, Production,
  Staging, Preview, Docker Hub) — and 0 of them hold an environment secret.
• orgs/metadatastician/actions/secrets — empty, re-measured today.
• Exactly one mail-shaped name in the whole estate: AUR_EMAIL on bunsenite,
  which is an Arch packager identity, not a sending credential.

So: there is no SMTP credential anywhere, and the 325 disabled mail workflows
cannot be re-armed. Re-enabling them turns 325 green-because-disabled into 325
red at AUTH — this action makes AUTH a mandatory row in its state machine, so it
cannot even fall back to unauthenticated relay.

What I need from you: create SMTP_* secrets, and say where. This is the
awkward bit — hyperpolymath is a User account with no org-secrets mechanism, so
the options are per-repo secrets ×~330, or a reusable workflow in standards
called with secrets: from thin callers (one place, one credential).
metadatastician is an org and can simply hold one. I am not proposing a
re-arm as something I do unattended either way.

Evidence kept at developer/.claude/checkpoints/secret-census-2026-09-03.{tsv,sh}.

5. O11 and O12 (this issue is titled O1–O10; these are newer)

• O11 — standards holds no App credential. No APP_ID / APP_PRIVATE_KEY,
  and signed-push-smoke has been red since 08-24. The §6.4 central
  lock-refresh design depends on that credential: it is the one mechanism
  that lets a single App fix lockfiles estate-wide instead of one secret per
  repo × 389. Until it exists, lock-refresh cannot be built, and the estate's
  top startup_failure cause stays.
• O12 — the ADR- autolink 404s estate-wide. The template points at
  ADR-<num>.adoc but the files are ADR-NNN-slug.adoc, so every autolink is
  dead. Separately, verified_allowed=true makes the allowlist decorative.

6. Upstream Zig report is blocked, not forgotten

ziglang/zig is set to collaborators_only, so the prepared comment on
#25747 cannot be posted from
this account. It is parked verbatim at docs/upstream/ziglang-zig-25747.md
with retry instructions. This is a moderation control and is not being worked
around. It carries findings upstream does not have: the five-provider survey,
the Kqueue site, and the ConnectError observation.

[hyperpolymath]

Correction to the secrets census above — env tier re-probed

Two defects in my own comment, found on review. The conclusion is unchanged
(no mail credential exists at any Actions-readable tier; the 325 disabled mail
workflows still cannot be re-armed), but two of the figures behind it were not
what I said they were.

1. "351 github-pages" is wrong — it is 355 of 355. Every environment-bearing
repo carries github-pages; the other names are additive, not a partition:
copilot (7), Production (2), Staging, staging, Preview, Docker Hub
(1 each), across 11 repos. The 351 was a subtraction I never actually performed.

2. The env-secrets tier had no error channel, so "0 environment secrets" was
not yet evidence. The census called environments/{e}/secrets and discarded
failures — no status change, no error line — so an empty column there meant "no
secrets" or "the call failed". The 434/434 status=ok I leaned on covered only
the repo-secrets and environments-list calls, never this one. Docker Hub makes
it concrete: a raw space is not a legal path segment, so that call almost
certainly failed and reported nothing.

Re-probed with stderr captured, exit status recorded, and names URL-encoded
(Docker%20Hub):

• all 13 non-github-pages environments across 11 repos → ok, 0 secrets
• a 10-repo sample of github-pages → ok, 0 secrets
• positive control: a deliberately absent environment → ERROR (HTTP 404)

That last row is the load-bearing one: it is what makes ok / 0 mean "succeeded
and found nothing" rather than "failed quietly".

Not re-probed: the remaining 345 github-pages environments. They are
auto-created by the Pages deploy action and the sample was uniformly empty, so
that portion is sampled, not swept — I am not claiming otherwise.

Artefacts: developer/.claude/checkpoints/secret-census-2026-09-03.{sh,tsv} and
env-reprobe.{sh,tsv}.

Worth recording as its own lesson: this comment was itself the correction of a
6-repo overclaim, and in adding a tier it reproduced the overclaim one tier down.
Adding a tier to a census adds an instrument, and an instrument with no error
channel manufactures absences.