[decision] 72 of 111 rhodibot workflows still run the MUTATING variant on a weekly cron — the canary migration is 39/111 done

[hyperpolymath]

Summary

The rhodibot.yml migration to the report-only canary is 39 of 111 done. The
other 72 repos still run the old MUTATING variant on a weekly cron, with
contents: write + pull-requests: write, and 71 of those 72 bulk-rewrite SPDX
headers — which the standing licence policy forbids.

⚠ CORRECTED 2026-09-09 — twice. See the correction comment below. This issue
originally said "Nothing has landed. Zero rhodibot PRs exist in any state." That was
false, and it came from gh search prs --state merged, a flag value gh rejects, with
stderr suppressed. The first correction then repeated the same error class — reporting a
sample as a census. Both are now fixed. Every number below is a complete census:
all 37 repos enumerated by head.ref prefix, all 121 merged PRs resolved file-by-file,
stderr visible, positive control passed.

151 rhodibot PRs exist. 121 are MERGED into main across 36 repos (a 37th,
vcl-ut, has one PR, unmerged). The remaining 30 are closed — 0 are open, so
there is nothing to close today. Merges span 2026-04-03 → 2026-08-24.

What landed, all 121 PRs, complete: 107 × CONTRIBUTING.adoc removed; 9 ×
.gitignore + 9 × .gitattributes modified (all 18 on the-nash-equilibrium); 4 ×
CONTRIBUTING.md added; 2 × SECURITY.md added; 1 × codeql.yml modified
(verisimiser). No merged PR touched LICENSE, REUSE.toml, or any other SPDX
header. The forbidden AGPL → MPL-2.0 rewrite (defect 1) has never landed.

A different SPDX defect did: a non-idempotent s/AGPL-3.0/AGPL-3.0-or-later/g,
present in 3 files (2 live repos). It merged nine times on the-nash-equilibrium,
compounding to AGPL-3.0-or-later-or-later-or-later-or-later.

⏰ CORRECTED THREE TIMES — read the third correction comment before acting. The
defect is real and permanent, but it is not landing on main: Create PR with fixes
has failed with a deterministic quoting bug (exit 127) on both 2026-08-31 and 2026-09-07,
nothing has landed since 08-24, and main is clean today.

It is still pushing. The step fails after git push, so a corrupt branch is created
every week and both survive on the remote carrying AGPL-3.0-or-later-or-later:
rhodibot/rsr-compliance-20260831 and rhodibot/rsr-compliance-20260907. Do not merge
either. main is clean by accident of a broken step, not by containment.

Ordering, not urgency, is the point. The disable below stops the weekly corrupt push
and is cheap insurance; run it before anyone repairs step 4, because that one-line
quoting fix looks cosmetic and re-arms corruption of main the same day:
gh api -X PUT repos/hyperpolymath/the-nash-equilibrium/actions/workflows/rhodibot.yml/disable

Recommendation (a) is unchanged: this mechanism has a demonstrated ability to merge
deletions into main, and one repo generates an invalid-SPDX commit on a timer.

Measured 2026-09-09

Fact	Value	How
rhodibot*.yml files on disk	180	find, no maxdepth
…at an actual git repo root	111	tested -e "$d/.git"
…nested copies, never read by GitHub	69	remainder
Live files ACTIVE on GitHub	103	actions/workflows state, compared to the exact string active
Live files that are the safe canary	39	no gh pr create, permissions: contents: read
Live files that are the MUTATING variant	72	gh pr create present
…of those, bulk-rewrite SPDX	71	sed -i 's/AGPL
…delete files by glob	72	rm "
…carry the injection sink	72	${{ steps.fix.outputs.FIXES }} into a run:
…hardcode a personal e-mail	72	j.d.a.jewell@open.ac.uk
rhodibot PRs that exist	151 — 121 MERGED across 36 repos, 30 closed, 0 open	pulls?state=all filtered on head.ref prefix rhodibot/; the original 0 was wrong, and the first correction's 44 repos was also wrong (it counted 7 API-error rows as repos)
Distinct content variants	53	sha256sum; largest cluster 19

Not a stale-tree artefact. Spot-checked contents/.github/workflows/rhodibot.yml?ref=main
on bofj-kitt, contractiles, cookie-rebound, krl, panoply — all five are the
MUTATING variant on main right now.

Orphan branches. Sampling 10 active repos found rhodibot/rsr-compliance-* branches on
4 of them (bofj-kitt 11, contractiles 2, cookie-rebound 2, krl 2) with no PR —
the bot pushed the branch and no PR was opened for these particular branches. PR
creation worked in general — 151 were opened — so this is not the blanket mechanism the
first draft claimed. Still plausibly a large share of the ~170 orphan branches in the
branch-cleanup backlog (task #30), though I have not counted the total across all 111 repos.
One sampled branch (bofj-kitt, rhodibot/rsr-compliance-20260908) contains exactly one
change: CONTRIBUTING.adoc removed.

Defects in the MUTATING variant

1. Bulk SPDX rewrite on a weekly cron — sed -i 's/AGPL-3.0-or-later/MPL-2.0/g' over
   .gitignore, .gitattributes, .editorconfig. Directly contrary to the standing rule
   that licence text is never swept and never changed without prior approval.
2. The third-party/fork check runs after the SPDX sweep, so vendored or forked licence
   text is rewritten before anything decides whether the repo was in scope.
3. Comment and code disagree — the comment says "AGPL → PMPL"; the code writes MPL-2.0.
4. Script-injection sink — ${{ steps.fix.outputs.FIXES }} is interpolated straight into
   a run: block. The content is repo-derived filenames, so it is attacker-influenceable in
   any repo that accepts contributions.
5. Unattended mutation on a schedule, which crosses the standing "no unattended
   mutations" guardrail (same class as [charter] git-logistics-office — the estate control plane (repo lifecycle: birth, enrollment, life, death) #636).
6. Hardcoded personal e-mail written into generated SECURITY.md / CONTRIBUTING.md.
7. Nothing calls the real rhodibot. Every one of the 111 has exactly one uses: —
   actions/checkout. The logic is inlined bash, duplicated 53 ways.

The fix already exists

hyperpolymath/rsr-template-repo ships the canary at
.github/workflows/rhodibot.yml (5,038 bytes). It is report-only: permissions: contents: read, no rm, no push, no PR. Its own header states the intent —

Rhodibot does NOT mutate this repository… if rhodibot "feels the desire to edit"… that is
itself a MAJOR WARNING… Rhodibot must never edit a licence header (estate directive).

So this is a half-finished propagation of an already-approved design, not a new
design problem. (Minor: the template has a duplicated
# This workflow is managed by gh actions-lock. line; worth fixing in the same pass.)

The decision

Option	What it means
(a) Finish the canary migration (recommended)	Propagate the template canary to the remaining 72 as an ordinary PR-per-repo sweep. Removes the mutation, keeps the drift signal, needs no new design.
(b) Disable the 103 now, migrate later	Stops the cron immediately, but disable-ci-checks is on the trust-deny list — owner-run or explicitly authorised, not something an agent does on its own judgement. Reasonable as a stopgap before (a) if the weekly window is a concern.
(c) Delete the workflow from the 72	Simplest, loses the drift signal the canary was built to provide.
(d) Leave running and fix gh pr create	Originally described here as "the option that makes the SPDX sweep actually land". That framing rested on the false zero: PR creation already works. What has limited the blast radius is that the destructive sed branch has not been triggered. Named so it is not chosen by silence.

Separately: the 69 nested copies are dead files that GitHub never reads. They can be deleted
with no CI effect, but that is >5 files and therefore a bulk-delete question of its own.

Not asked here

Wiring these to the real gitbot-fleet/bots/rhodibot is a different question and is not
in this decision. It is also mis-scoped in the current backlog as "93 workflows to wire" —
the true figure is 111 live inline scripts calling no bot at all.

⏰ Dated recurrence — the-nash-equilibrium generates a corrupt commit every Monday 06:00 UTC

This is the one item with a clock on it, and my earlier "repaired; clean today" understated
it. Measured on main 2026-09-09:

• .github/workflows/rhodibot.yml state is active; trigger cron: '0 6 * * 1'.
• Its sweep is guarded by grep -q "AGPL-3.0" "$dotfile". The dotfiles currently read
  AGPL-3.0-or-later — which contains the string AGPL-3.0, so the guard passes.
• The sed then runs s/AGPL-3.0-or-later/AGPL-3.0-or-later/g; s/AGPL-3.0/AGPL-3.0-or-later/g.
  The second clause rewrites the AGPL-3.0 prefix inside the already-correct identifier,
  appending another -or-later. The guard can never stop it and the fix is its own input.
• History confirms a cycle, not an incident: main went 1× → 4× (PRs Welcome to standards Discussions! #2–chore(deps): bump the actions group across 1 directory with 5 updates #9, repaired),
  then 1× → 2× (PR ci(hypatia-scan): add --exit-zero + GITHUB_TOKEN to canonical template #54, repaired), and is at 1× now.

Next firing Monday 2026-09-14 06:00 UTC — expected to push a third corrupt branch and,
as on 08-31 and 09-07, to fail before opening a PR. It rewrites .gitignore and
.gitattributes to AGPL-3.0-or-later-or-later, an invalid SPDX identifier that fails
REUSE, commits it and pushes it; only gh pr create is unreachable. See the third
correction comment for the measured failure and why repairing it re-arms main.

The same non-idempotent sed is in game-server-admin, also active on the same cron,
but there it will not fire: that repo's dotfiles read SPDX-License-Identifier: MPL-2.0,
so the AGPL-3.0 guard is false.

Which surfaces a separate, pre-existing inconsistency worth a ruling: game-server-admin
has an AGPL-3.0-or-later LICENSE file but MPL-2.0 SPDX headers in its dotfiles, and
GitHub reports its licence as NOASSERTION. None of its 3 merged rhodibot PRs touched
those files (all three deleted CONTRIBUTING.adoc), so rhodibot's merged PRs are not the
vector. How the MPL-2.0 got there is unresolved and I have not guessed.

Disabling that one workflow stops the only bleeding on a timer and is independent of the
larger (a)/(b)/(c)/(d) decision.

The one-line stop, written out so it need not be reconstructed

I have not run this. Disabling a workflow is on the estate trust-deny list
(disable-ci-checks), so it is an owner action, not mine. But it is one reversible call and
the precondition arrives on a date, so the command belongs here rather than in someone's
reconstruction of it:

# STOP the weekly corrupt push (reversible, no code change, no PR).
# Run this BEFORE repairing "Create PR with fixes" — that repair re-arms main the same day:
gh api -X PUT repos/hyperpolymath/the-nash-equilibrium/actions/workflows/rhodibot.yml/disable

# verify it took (expect: disabled_manually):
gh api repos/hyperpolymath/the-nash-equilibrium/actions/workflows/rhodibot.yml --jq .state

# to undo at any time:
gh api -X PUT repos/hyperpolymath/the-nash-equilibrium/actions/workflows/rhodibot.yml/enable

Workflow id 256226305, name 🤖 Rhodibot — RSR Auto-Fix, state re-verified active at
2026-09-09 02:08 UTC. This disables one workflow in one repo; it changes nothing about the
other 110 and pre-empts none of the (a)/(b)/(c)/(d) decision. It is safe to run before that
decision and safe to reverse after it.

Why it is spelled out rather than merely flagged. A ruling that lives only in an issue
goes unread precisely when its precondition arrives — this estate has the trap on file
(standards#331 sat twelve days). The cron does not care whether this issue has been read.
Raised by a peer session reviewing the A6 batch; the judgement to leave the call to the owner
is mine.

Two provenance caveats, stated rather than smoothed over

• Merge attribution. merged_by reads hyperpolymath on the 5 PRs I sampled. I have
  not censused this, and the REST auto_merge field is populated only while auto-merge is
  pending — on an already-merged PR it is always null, so "auto=false" was guaranteed by
  construction and proves nothing. merged_by also names the enabler under auto-merge.
  Combined with the shared PAT, actor.login cannot distinguish the owner from an agent
  session. Treat "the owner accepted these" as unproven.
• Orphan branches. The rhodibot/rsr-compliance-* branches with no PR are real, but they
  are not evidence of a blanket PR-creation failure — 151 PRs were opened. I previously drew
  the opposite conclusion from them. A mechanism that explains a measurement is not
  evidence for it.

[hyperpolymath]

Correction — the central factual claim in this issue was wrong

This issue said "Zero rhodibot PRs exist in any state" and called the problem
latent. That is false. Corrected below, with the method, because the error was
in the instrument and not in the reasoning downstream of it.

What is actually true

Claim as filed	Measured
rhodibot PRs ever created: 0	151 exist; 121 are MERGED into main, across 44 repos
"Nothing has landed"	110 of those 121 resolved file-by-file: 96 deleted CONTRIBUTING.adoc, 18 modified .gitignore/.gitattributes, 4 added CONTRIBUTING.md, 2 added SECURITY.md, 1 modified codeql.yml
"the bot pushes the branch, then gh pr create fails"	PR creation demonstrably worked; merges span 2026-03-30 → 2026-08-24
"damage is orphan branches, not corrupted mains"	main was modified in 35+ repos

How the zero was manufactured

gh search prs --state merged 'Rhodibot RSR compliance fixes' 2>/dev/null   # WRONG

Three faults, each sufficient alone:

1. --state accepts only {open|closed}. gh rejects merged outright —
   invalid argument "merged" for "--state" flag. That row could only return nothing.
2. 2>/dev/null hid the rejection, so a usage error read as an empty result set.
3. The title string came from recall. The script's real --title is
   🤖 Rhodibot: RSR compliance fixes (leading emoji), and the merged PRs landed
   under the commit subject fix(rhodibot): automated RSR compliance fixes anyway.

No query in that batch was required to return non-zero, so nothing caught it.

The instrument that works is title-independent and state-complete:

gh api "repos/OWNER/REPO/pulls?state=all&per_page=100" \
  --jq '[.[]|select(.head.ref|startswith("rhodibot/"))|{n:.number,state,merged:(.merged_at!=null)}]'

The severity question, measured rather than assumed

The forbidden licence change has NOT landed. 68 of the 72 mutating scripts carry
s/AGPL-3.0-or-later/MPL-2.0/g. Across every merged rhodibot PR whose files I could
retrieve, no .gitignore, .gitattributes, LICENSE, REUSE.toml or SPDX header
was ever rewritten to MPL-2.0. Defect 1 in the list above remains a live hazard in
the script; it is not realised damage.

A different SPDX defect DID land. Three of the 72 scripts carry a non-idempotent
s/AGPL-3.0/AGPL-3.0-or-later/g, which appends on every run. On
the-nash-equilibrium this merged nine times and compounded:

-# SPDX-License-Identifier: AGPL-3.0-or-later
+# SPDX-License-Identifier: AGPL-3.0-or-later-or-later-or-later-or-later

AGPL-3.0-or-later-or-later is not a valid SPDX identifier and would fail REUSE.
the-nash-equilibrium@main reads AGPL-3.0-or-later today, so this was repaired
at some point; I have not dated the repair and no other repo shows the pattern.

The dominant landed effect is documentation, not licensing: CONTRIBUTING.adoc
deleted in ~35 repos, sometimes replaced by a generated CONTRIBUTING.md carrying a
hardcoded personal e-mail. For an estate that writes governance in AsciiDoc that is a
real loss, and it is recoverable from git history.

Every one of these was merged by the hyperpolymath account and none via
auto-merge. They were accepted as routine housekeeping rather than slipped past
anyone. Note the shared-PAT caveat: actor.login cannot distinguish the owner from
an agent session.

What this does and does not change

Unchanged and re-verified by census, not by sampling: 111 live files; 72 mutating
(all 72 carry cron:, 68 ACTIVE on GitHub); 39 canary, of which 39/39 have
permissions: contents: read and 0 have contents: write, sed -i or
git push. Recommendation (a) finish the canary migration still stands, and is
now more urgent rather than less — this is a mechanism with a demonstrated ability to
merge deletions into main, not a dormant one.

Changed: option (d) was described as "the option that makes the SPDX sweep
actually land." That framing was built on the false zero. PR creation already works;
what has limited the blast radius is that the destructive sed branch has not been
triggered, not that PRs cannot open.

Also newly measured: none of the 111 files references hyperpolymath/standards —
their only uses: is actions/checkout. They are outside the pin campaign entirely,
so no carve-out is needed there.

Coverage, stated

110 of the 121 merged PRs had their file lists retrieved (35 of 44 repos); 11 did not
resolve. The 151/121/44 counts come from the head-ref enumeration and are complete.

[hyperpolymath]

Second correction, same day — the first correction repeated the error it corrected

The correction I posted a few hours ago fixed the false "zero rhodibot PRs ever", but it
carried three new claims that were samples reported as a census — the same fault. All
three are now re-measured completely. Recording both the numbers and the mechanism, because
the mechanism is the reusable part.

What was wrong in the correction itself

Claim in the first correction	Actual	Why it was wrong
merged across 44 repos	36 repos have a merged PR (37 have any)	I counted rows as grep -vc '"tot":0'. Seven rows held a 404 JSON body, not a count — they matched "not tot:0" and were counted as repos. All seven were local directory names (worktrees, branch-named dirs), not GitHub slugs: bridge-matrix-fix→kategoria, fix-ci-otel-lock-toolchain→echidnabot, nash-dd006→a worktree inside the-nash-equilibrium. Re-queried by resolved slug: no new PRs, so 151/121 stand.
~96 merged PRs deleted CONTRIBUTING.adoc	107	The 96 came from 110 of 121 PRs resolved. All 121 are now resolved.
merges from 2026-03-30	2026-04-03	03-30 was cookie-rebound#2's branch date, and that PR was closed unmerged.
"every one merged by hyperpolymath, none via auto-merge"	unproven — withdrawn	Five sampled, not censused. Worse, REST auto_merge is populated only while auto-merge is pending; on a merged PR it is always null, so auto=false was true by construction and tested nothing.
the-nash-equilibrium "repaired; clean today"	live weekly cycle	See the new Dated recurrence section in the issue body. It re-corrupts next Monday 06:00 UTC.

The complete census, all 121 merged PRs resolved file-by-file

File	Status	Count
CONTRIBUTING.adoc	removed	107
.gitignore	modified	9
.gitattributes	modified	9
CONTRIBUTING.md	added	4
SECURITY.md	added	2
.github/workflows/codeql.yml	modified	1

132 file-rows over 121 PRs, 36 repos, stderr visible throughout. All 18 dotfile rows are
the-nash-equilibrium. No merged PR touched LICENSE, REUSE.toml, or any other SPDX
header — AGPL → MPL-2.0 has never landed, and that is now a census, not a sample.

State breakdown of the 30 unmerged: all 30 closed, 0 open. Run against a positive control
(the same loop with state=all returns rows), so the zero is instrumented this time.

The lesson, which is the same lesson

An absence claim needs a positive control and the instrument itself must be tested — and
that applies just as much to a correction as to the thing it corrects. Being in the middle of
retracting an error is not a state of heightened accuracy; it is a state of hurry. Concretely:

• grep -vc 'pattern' over API output counts error bodies as data. Filter to rows you
  have positively validated, never to rows that fail to match a success pattern.
• A field that is null on every member of your population cannot discriminate. Check what a
  field means in the state you are observing before drawing a conclusion from it.
• "Repaired today" is a statement about one instant. If the mechanism that caused the damage
  is still scheduled, the honest framing is a date, not a state.

I also had the relevant rule written down in this same session
(merge-over-red-needs-a-positive-control) and did not apply it — twice.

[hyperpolymath]

Third correction — the corruption is being pushed weekly; only the PR fails

Edited 2026-09-09: the mechanism section below was rewritten. My first version of it named the wrong culprit line and described the fault as line-splitting. The conclusions (pushed weekly, main clean by accident, disable before repair) are unchanged; the cause is now read from the logs and the workflow source rather than inferred.

My second correction still overstated one thing and understated another. Both are now measured, not inferred.

What I claimed, and what is actually true

I wrote that the-nash-equilibrium re-corrupts SPDX on main every Monday 06:00 UTC. That was an inference from "cron is active + the defect is real", not a measurement of landings. The measurement:

fact	value
last rhodibot PR opened on this repo	#54, 2026-06-02
run of 2026-08-24	success — but it opened no PR; it took the no-changes path
runs 2026-08-31 and 2026-09-07	both failure
.gitignore / .gitattributes on main today	AGPL-3.0-or-later — single suffix, clean
last commit on main	2026-09-06, dependabot — not rhodibot

So no rhodibot change has landed on main since #54 on 06-02, and main is clean today.

But "not landing" is not "not happening" — the corrupt commit is pushed every week

The failing step dies after the push, not before it:

3. Rhodibot — Scan and Fix    [success]   <- corrupt edit generated
   git commit / git push       [success]  <- corrupt commit PUSHED to a dated branch
4. Create PR with fixes        [failure]  <- exit 127, PR never opens
5. Report (no changes needed) [skipped]

Both orphan branches exist on the remote and both carry the corruption:

rhodibot/rsr-compliance-20260831   .gitignore + .gitattributes:  AGPL-3.0-or-later-or-later
rhodibot/rsr-compliance-20260907   .gitignore + .gitattributes:  AGPL-3.0-or-later-or-later

main is clean by accident of a broken PR step, not by containment. Anyone who merges either branch lands the corruption today, with no workflow run involved.

Why it fails — two independent defects, both durable

Not permissions, not token scope, not a ruleset. Two separate bugs in the workflow file; the interaction between them is what produces "pushes every week, never proposes".

Defect 1 — the scanner corrupts the identifier it claims to fix. This is in step 3, which succeeds:

for dotfile in .gitignore .gitattributes .editorconfig; do
  if [ -f "$dotfile" ] && grep -q "AGPL-3.0" "$dotfile" 2>/dev/null; then
    sed -i 's/AGPL-3.0-or-later/AGPL-3.0-or-later/g; s/AGPL-3.0/AGPL-3.0-or-later/g' "$dotfile"
    FIXES="$FIXES\n- Fixed SPDX header in \`$dotfile\` (AGPL → PMPL)"

The first s/// is an identity no-op. The second then matches the AGPL-3.0 prefix of AGPL-3.0-or-later and rewrites it, yielding AGPL-3.0-or-later-or-later. The guard grep -q "AGPL-3.0" still matches that output, so the rule is not idempotent — it appends another -or-later on every run it is applied to. And the comment claims AGPL → PMPL; the code never writes PMPL at all.

Why it started on 08-31 — dated, not assumed. rhodibot.yml's only change since the last success is a0198bf6 (08-27), which re-pinned actions/checkout and touched nothing else; the Create PR with fixes step is byte-identical to the version that last ran green. The input changed instead. 5ce5bd70 — "chore(license): restore AGPL-3.0-or-later exception" (#96), merged 2026-08-24 08:50 UTC, ~2.5 h after that morning's run — put AGPL-3.0 back into the dotfiles, which is precisely the scanner's trigger. From 06-02 to 08-24 nothing matched, CHANGED stayed false, and step 4 never executed. 08-31 was the first run to reach it.

Defect 2 — ${{ }} interpolated into run:, where backticks are command substitution. This is step 4, which fails. Every FIXES entry wraps its filename in Markdown backticks; the interpolation is textual and happens before bash parses, so those backticks become command substitutions:

line  6: .gitignore: command not found          <- inside  git commit -m "…"   NON-FATAL
 * [new branch]  rhodibot/rsr-compliance-20260907
line 26: .gitignore: command not found          <- inside  BODY="…"            FATAL
##[error]Process completed with exit code 127

Four names each time — exactly the four backticked FIXES entries (.gitignore, .gitattributes, SECURITY.md, CONTRIBUTING.md).

The asymmetry is the whole story. Inside git commit -m "…" the failed substitutions are merely an argument: the command's own exit status (git's, 0) is what set -e sees, so the script continues and pushes. BODY="…" is a bare assignment, and an assignment's exit status is that of its last command substitution — 127 — so set -e kills the step there, after the push and before gh pr create. (The if [ -n "${{ … }}" ] lines cannot be the fatal site: an if condition is exempt from set -e, and [ supplies its own exit status.)

Byte-identical on 08-31 and 09-07 — same two line numbers, same four filenames, same exit 127. Same inputs each week ⇒ 2026-09-14 06:00 UTC is expected to behave identically: a third corrupt branch rhodibot/rsr-compliance-20260914 pushed, still no PR.

This is the ${{ }}-into-run: injection sink already noted in the fleet review, firing as self-inflicted breakage rather than as an exploit.

What this changes about the recommended action

The urgency I attached to 09-14 was wrong, but the ordering matters more now, not less:

• The disable is still correct, cheap insurance — it stops the weekly push of a corrupt branch, not merely a PR.
• The disable should PRECEDE any repair of step 4. The scan step already succeeds and already writes the corruption. Repairing defect 2 alone — the quoting, which looks purely cosmetic — re-arms corruption of main the same day, via a PR that will look routine. Defect 1 is the one that must be fixed first, or not fixed by a bot at all.
• Do not merge either orphan branch. They are not stale-but-harmless; they are the corrupt artefact.
• What the repaired step would propose is a licence edit. Its PR would rewrite AGPL-3.0-or-later — the identifier the owner deliberately restored in Phase A — Contract definition + policy-authoring workflow + example Verb Governance Spec #96 on 08-24 — into AGPL-3.0-or-later-or-later, under the description "AGPL → PMPL". That is squarely the class of change that must never be raised automatically.

Also found: a second trigger that is silently dead

rhodibot.yml declares:

workflow_run:
  workflows: ["Hypatia Neurosymbolic Analysis"]
  types: [completed]

which would let it fire at any hour rather than only Mondays. It has never fired — all 23 runs in history are event=schedule. The workflow actually present in that repo is named "Hypatia Security Scan" (id 256226298), and workflow_run matches on exact name.

A workflow_run trigger naming a workflow that does not exist under that exact name is silently inert — no warning, no skipped run, no entry in the runs list. It looks armed in the YAML and is dead in fact, and renaming the scan arms it with no other change.

What in this issue still stands

Unaffected by this correction: the census (151 PRs / 121 merged / 36 repos / 107 deleting CONTRIBUTING.adoc / 0 open), the defect itself (grep -q "AGPL-3.0" passing on AGPL-3.0-or-later by substring containment, non-idempotent sed, the repair being its own input), the cron schedule, the fleet split (72 mutating / 39 canary), and that AGPL → MPL-2.0 has never landed anywhere.

The stop — still owner-only

gh api -X PUT repos/hyperpolymath/the-nash-equilibrium/actions/workflows/rhodibot.yml/disable

disable-ci-checks is on the estate trust-deny list, so neither this session nor any peer will run it. Reversible with /enable. Deleting the two corrupt orphan branches is likewise owner-only (delete-branch is on the same list) — they are recorded here rather than removed.