Two ceremony boards: this one is the development line, the Forgejo copy is a consumed snapshot at 0.4.0 — and today's portability work order was routed to the copy

[dan-claude-bot]

A stray issue arrived at the door this morning and left 44 minutes later without triage ever holding it: #219, filed 08:02:50Z by @claude-bot-andresmgsl carrying needs-triage, closed 08:46:11Z by its own filer as "Superseded and filed in the wrong place. This work belongs on the heavy-duty Forgejo instance, where the affected consumer lives: #188 on forgejo.heavyduty.builders. Closing; do not build from this copy."

"Do not build from this copy" is a claim about which board owns this repo's source. That is not triage's call, and it is not a claim I can take on prose — so I measured both copies before bringing it here.

Measured 2026-08-02 09:20–09:26Z

Read-only, unauthenticated api/v1 on the Forgejo side; gh and git ls-remote on this one.

	github.com/heavy-duty/ceremony	forgejo.heavyduty.builders/heavy-duty/ceremony
head of main	80da0a8 — 2026-08-01 18:15Z	84bb1a4 — 2026-07-29 12:27Z (this repo's 0.4.1-dev re-arm commit)
branches	many	main alone
tags	0.1.0 … 0.4.1	0.1.0 … 0.4.0
PRs	214, the newest merged 2026-08-01	none anyone opened — every PR there is an import carrying this repo's numbering, newest touched 2026-07-29
open issues	5 — #1, #112, #205, #216, #218	3 — #1, #112, #188
repo created	2026-07-22	2026-07-26

So the Forgejo copy is a consumption snapshot synced through 0.4.0, not a second development line. It is missing 0.4.1 and the two displacement fixes that release carries (#208, #209).

It exists for a good reason: Forgejo Actions resolves uses: against its own instance, and rig's caller there pins heavy-duty/ceremony/.github/workflows/labels.yml@0.3.0, which can only resolve to the copy.

What is actually broken there, verified rather than quoted

#219 reported "65 consecutive failures" of labels on the Forgejo instance. The instance's own task API is readable without an account, so I counted it independently instead of citing it:

• rig's labels workflow there: 161 runs in the window the API exposes (2026-08-01 18:56Z → 2026-08-02 09:15Z), 161 failures, zero successes — one every 15 minutes, on schedule and on issues events alike. Newest is run 971 at 09:15:04Z.
• Its install, db-integration and release workflows are green in that same window. It is the ceremony machinery that is inert, and only the ceremony machinery.
• The cause actions/* + lib/* — ceremony is gh-only, so the reconcilers cannot run on a Forgejo consumer (rig's board has been unreconciled since it moved) #219 names holds up: the reconcilers shell out to gh, gh speaks /api/v3, Forgejo serves /api/v1. There is no forge indirection in lib/ today.
• GitHub-side rig is unaffected — its scheduled labels runs are green through 2026-08-02 07:15Z. That is precisely why this is invisible from this board unless someone goes and looks.

Why the routing is the question, and not the port

The work #219 describes — 65 gh call sites across actions/*, lib/* and .github/workflows/release.yml, plus the choice between porting to stoke, speaking REST directly, or a two-backend shim in lib/ — is work on this line's source. Built on the copy it would land a release behind, on the only branch that copy has, with no path back here, and no consumer that pins a GitHub tag would ever see it. rig's symptom is genuinely on the Forgejo instance; the fix has its source here.

I am not asserting the close was wrong. The pieces are split across two forges and a reasonable person routes it either way. What I am asserting is narrower and, I think, not arguable: an untriaged work order now sits on a board this triage has no account on (no Forgejo credentials here, and stoke — which #219 measured — has no label, comment or review commands at all), while the door it came through has no record of the decision. That is the "board that lies" failure with an extra forge in it.

The ruling ask is in the comment below. Nothing on this board is held by it.

[dan-claude-bot]

🧭 needs-ruling — which board owns ceremony's source, and where does Forgejo-portability work get minted?
Options: A — this board stays the development line; the Forgejo copy is a consumption mirror re-synced at each tag, and the port is minted here B — the Forgejo copy becomes upstream for the family; this board winds down and its open work migrates there C — two deliberate lines, each with its own triage, each cutting its own tags
Recommend: A, because every tag a consumer pins is cut here, the copy has no branch and no PR of its own, and A is the only option that requires nothing to be built before it is true.
Blocked: Nothing on this board stops — #205, #216 and #218 stay ready and claimable, and #112's two open adoptions (box#168, cast#144) are on GitHub boards either way. What waits is #219's substance: the shim decision (stoke / raw REST / two-backend lib/ shim, plus what happens to gh api graphql, which Forgejo has no equivalent of) has no venue while the issue carrying it sits needs-triage on a board I cannot serve. rig's board stays unreconciled meanwhile — 161 consecutive labels failures and counting, one every 15 minutes.
Default: none — hard block. Where the org's source lives and which board its agents serve is org policy, which LABELS.md makes a hard block by construction.

Analysis

Why this is yours and not mine

Triage's job is to decide what becomes work. It is not to decide where the work lives — and this question is upstream of the port, of #219's A/B/C, and of every issue either board mints from here on. Picking it would also be self-serving in a way worth naming: option B is triage deciding this board should wind down, and option A is triage deciding it should not.

The case for each, stated fairly

A — this board stays upstream. Matches every fact I could measure: 0.4.1 was cut here yesterday, five consumers pin GitHub tags, the copy has one branch and zero native PRs. The Forgejo instance keeps working exactly as it does today — it consumes tags, and a re-sync at each tag is a mechanical step someone already performs (the copy tracked 0.4.0 within the hour). Its cost is honest: rig cannot be reconciled until the port lands here and ships in a tag, so the 161-failure run continues for as long as that takes, and someone must keep the copy in sync or consumers silently pin stale machinery — which is what 0.4.0 vs 0.4.1 is right now.

B — Forgejo becomes upstream. Puts the source where the forge that hosts the affected consumer is, and ends the sync obligation. Its cost is the whole GitHub-side board: five consumers pinning heavy-duty/ceremony@X.Y.Z on github.com, this repo's issue history and its three open ready issues, the release evidence in drills/, and the agent identities that have accounts here and not there. It also inverts the mirror rather than removing it, unless every consumer moves too.

C — two deliberate lines. Honest about the current state, and the only option under which #219's close was straightforwardly right. Its cost is that ceremony's founding claim — one implementation, tested once, documented once (#1) — becomes two implementations that will diverge, starting from the 0.4.0/0.4.1 gap that already exists. Two boards also means two triage roles and no single door, which is the thing TRIAGE.md exists to prevent.

What I did with #219 in the meantime

Nothing that forecloses any option. It stays closed — its filer's routing call stands, and TRIAGE.md's own remedy for a stray issue is to convert its substance back into a discussion rather than to re-mint it, which is what this thread is. If you rule A, #219's substance comes back here as a discussion for the shim question (it carries an open A/B/C decision in its own spec, so it cannot be minted as an issue as written), and the copy's #188 is closed pointing at it. If you rule B or C, this board's triage stops at the door and the port is theirs.

What is not in this ask

The shim choice itself (stoke / REST / two backends) and the GraphQL question. Those are engineering calls that follow from this one and belong wherever this ruling puts them. Also not here: whether the copy should be re-synced to 0.4.1 today. That is a one-command operator action under A, meaningless under B, and a policy question under C — I have not touched it.

The measurements again, so the decision does not need the thread scrolled

• Forgejo copy: main alone at 84bb1a4 (2026-07-29 12:27Z), tags to 0.4.0, zero native PRs, three open issues.
• This board: main at 80da0a8, tags to 0.4.1, five open issues, 0.4.1 released 2026-08-01 18:15Z.
• rig on Forgejo: labels 161/161 failures 2026-08-01 18:56Z → 2026-08-02 09:15Z; install, db-integration, release green in the same window.
• rig on GitHub: labels green on schedule through 2026-08-02 07:15Z.

The thread is where you decide; I am waiting here. @danmt

[dan-claude-bot]

✅ Decision — the routing question has been answered, and it was answered on the other board

Anchored to the escalation at 2026-08-02T09:27:30Z; it is now 2026-08-03T13:01Z, 27h34m in, past the 24h rung. Default: was none — hard block, and it did not fire. What I found before picking is that the decision the rung would have had me make already exists — taken by a human, on the instance where the work lives, seventeen hours before that rung came due. Triage does not get to pick over a ruling; it records it. So this is a record, and the only judgement in it is what this board does next.

The ruling, quoted rather than paraphrased

On the Forgejo copy's own #188, at 2026-08-02T15:17:34Z, @andres wrote:

okay first all.. we should forget on doing any change on github, we have to do all the changes here, with what we have (it should work for now). I know Ceremony github repo is more advance than the one Cremony here, but does not an issue for us.. Implement the solution here, the PR here and adapt all your comments based on this..

That bench recorded it as term 8 of a frozen 8-term spec — "develop, PR, review, tag/release on this Forgejo instance … Do not change, sync from, or depend on the GitHub ceremony repo for this work. Divergence is accepted for now" — alongside the earlier ruling on the shim's shape (C: lib/forge.sh selecting a github or forgejo backend, at 14:27:50Z). @andres then moved the issue to ready himself at 18:13:43Z.

Measured on that instance today, 12:50–13:00Z (read-only api/v1; this identity still has no account there)

	at the escalation, 2026-08-02 09:20Z	now
copy's main	84bb1a4, 2026-07-29	84bb1a4, unchanged
branches	main alone	main + build/188-forge-preflight
native PRs	none	!189 — "actions/ + lib/* — one forge abstraction, two backends (#188)"*, opened 18:30Z by @cluade-reviewer-andresmgsl, not a draft, 10 commits, in panel round, last touched 2026-08-02 21:32Z
its #188	needs-triage, unclaimed	claimed, assigned, spec frozen to the 8 terms
rig's labels there	161 runs, 161 failures	still red, every 15 minutes — run 357 at 2026-08-03 12:45:03Z; install, db-integration, release green in the same window

So the sentence that opened this thread — "an untriaged work order now sits on a board this triage has no account on" — has stopped being true in the way that mattered: it is triaged, claimed, specced and building. It is simply not building here.

What that settles, and what it does not

Settled — where the port is minted: there. #219's close stands, this board mints nothing for the forge port, and the shim question (stoke / raw REST / two backends, plus the GraphQL sites) is answered there as C. Nothing about that is triage's to revisit.

Settled by facts rather than by ruling — this board is still the development line. 0.5.0 was cut here today: panel 4/4, merged by @danmt at 12:40:36Z, tag published 12:40:50Z, five consumers pinning GitHub tags, and crew#320 adopting it in review right now. Nothing in @andres's ruling asks this line to stop, and it plainly has not.

Therefore the outcome is A's shape for this line, with a carve-out that is honestly C's shape for the port, and it is worth naming rather than smoothing over: term 8 says the port will "tag/release here", and the copy is a release behind (0.4.0 vs 0.5.0) on top of a branch this line does not have. That is two lines cutting their own tags, which is option C — accepted deliberately, by the person whose call it is, and scoped "for now". I am recording that as the answer, not re-litigating it.

Not settled, and deliberately not re-escalated here: how the divergence ends. Ceremony's founding claim is one ceremony for the whole family (#1), and that claim now has a due date nobody has set. Re-flagging this thread would start a fresh ladder on a question no one is blocked on today, so instead it goes where it can be scanned: epic #1 already carries a row for the forge split, and I have updated it with today's facts and this ruling. It ticks when the family consumes one ceremony again — whichever forge that turns out to be. @danmt — FYI, nothing owed: the row is the place to disagree with that, and one word there or here reopens this thread.

One thing owed on the other board that this triage cannot do

Term 7 of the frozen spec assigns triage there the minting of a separate issue for the runner-isolated Forgejo false-negative, explicitly out of #188's scope. It does not exist yet — that instance's issue list holds #188 and two imports, and nothing matching. I have no account on the instance (unauthenticated reads only, and stoke exposes no issue-mint verb this identity could use), so I cannot file it and am not pretending otherwise. Whoever serves triage there owns it; naming it here is the most this door can do.

Outcome

Converged. Closing this discussion: the routing question it asked has an answer, the port has a home, a builder and a live PR, and the reconvergence question it exposed is tracked on epic #1 instead of as an open thread waiting on nobody.

Triage, 2026-08-03. Measurements above are re-runnable: the instance's api/v1 is readable without an account.