heavy-duty/ceremony

Fork 2

release-init after 0.6.3 — the survey, and the one ruling that decides the next window's identity #268

New issue

Closed

opened 2026-08-26 20:26:46 +00:00 by claude-bot-andresmgsl · 5 comments

claude-bot-andresmgsl commented

2026-08-26 20:26:46 +00:00

Member

Closed unshipped 2026-08-27: the operator ruled option C — no 0.6.4, no
window. The ruling is recorded in the closing comment below and the body is
corrected to match it. This was the release-init working surface for the window
after 0.6.3, opened off that cut per RELEASES.md step 5 — "treat that close as
the trigger for the next window." 0.6.3 had no epic to close, so the cut itself
is the trigger, as triage said it would be on !267.

It deliberately carries no membership record. Under #343 a window stands only
on an open release-labeled issue whose ## Members record holds at least one
open member, with no fallback to the gate — release_window_members reads that
heading and nothing else. Release-init writes that record at step 3, and step
3 never ran. No window ever stood here, no membership call is owed on any mint,
and the sweep draws no window flag.

Predecessor gate

Cleared, with nothing to declare it against. !267 merged as 8f0ef79 at
2026-08-26T20:18:17Z; the door tagged and published 0.6.3 at 20:20:18Z and
re-armed main to 0.6.4-dev at bcbcd90. 0.6.3 cut epic-less, so there is no
predecessor issue for this epic to gate on.

The release is sound on the one check that could only run at the merge:
CI / self-guards is success on 8f0ef796 (run 2399), so
changelog-assembled graded the real fragment set at the real merge base. That
is the check 0.6.2 failed.

Step 1 — the survey

Measured 2026-08-26T20:26Z against origin/main at bcbcd90.

The board is empty. Open issues: exactly one, #265, at post-merge. Open
pull requests: none. Open proposals: none. There is also no predecessor epic, so
there is no "to mint when this arc opens" list to draw from — 0.6.3 left none.

The one accumulated deferral. docs/UPSTREAM-SYNC.md: "Upstream's
drill-record fixes and the upstream 0.7.0 through 0.7.4 line remain deferred
to the next sync campaign." That is the only recorded, unspent deferral in the
tree, and it has grown past what the record says:


ancestry baseline (`.upstream-ref`)	`8c3a4d1dee2bdb5ac06a632a285bb65ab2615214` — upstream `0.6.0`, merged by #198
recorded as deferred	upstream `0.7.0` through `0.7.4`
measured deferred today	upstream `0.7.0` through `0.7.6` — seven releases
upstream `0.7.5`	tagged 2026-08-19, so it was already out when the record was written
upstream `0.7.6`	tagged 2026-08-25

0.6.2's content came across by port (#229, #230) rather than merge, so no
upstream ancestry moved and .upstream-ref still names upstream 0.6.0.

The one finding this survey held back — now minted as #269. That deferral
range is stale by two releases. Whether it was a standalone doc fix or would be
absorbed by a campaign rewriting the whole port record depended on the ruling,
so the survey left it. The ruling answered both halves at once: fix the record
now, and the campaign that eventually consumes it merges rather than ports.
#269 carries both, ready and unblocked.

Steps 2 and 3 — never ran

There was nothing to graph and no membership to write while the ruling stood,
and option C means there never will be: a window with no members has no graph.
## Members stays absent, which is exactly how #343 says a non-window reads.

Step 4 — ruled: C, no window

RELEASES.md names the operator's blessing as the one step this chain never
automates, and it was a hard block rather than a timed default because the
choice sets a published tag's version number. It was answered on
2026-08-27T09:48:51Z: C — no window yet, no 0.6.4, close this epic
unshipped. RELEASES.md release-init anticipates exactly this outcome — "if
init finds no work worth minting, the operator either folds the empty window
into a later release or skips the version, recording that ruling on the epic
before closing it unshipped."

The ruling's two directions are dispatched: the docs/UPSTREAM-SYNC.md record
fix is minted as #269, and the next window's identity — the sync campaign, and
it merges (A/merge) — is recorded both in the closing comment below and,
by #269, in the procedure file itself. Nothing was held waiting on this: the
board was idle by design, not by blockage.

Task list

Step 1 — survey the accumulated work
Steps 2 and 3 — not run, and under C never will be: no members, so no
graph, no waves, and no ## Members record
Step 4 — the operator ruled 2026-08-27: C, no 0.6.4, no window
Step 5 — closed unshipped instead of shipped. This close is not the
trigger for another window: the next release-init runs when there is work to
survey, or when the operator calls for the sync campaign

Board note, not part of this window

#265 stays on its own post-merge track and is not a member of anything here.
Its code shipped in d439ff6; only its criterion 8 is outstanding, waiting on an
operator workflow_dispatch of self-labels-sweep.yml with bootstrap=yes.
Re-measured at this survey: ceremony's live needs-triage description is still
"Did not come through triage — owes normalization or conversion to a
discussion", against LABELS.md's "a proposal or stray issue that did not come
through triage — it owes normalization into work or a reasoned refusal".
Unchanged. Its fallback date is unchanged: 2026-09-01T22:20Z.

**Closed unshipped 2026-08-27: the operator ruled option C — no `0.6.4`, no window.** The ruling is recorded in the closing comment below and the body is corrected to match it. This was the release-init working surface for the window after **0.6.3**, opened off that cut per `RELEASES.md` step 5 — *"treat that close as the trigger for the next window."* 0.6.3 had no epic to close, so the cut itself is the trigger, as triage said it would be on !267. **It deliberately carries no membership record.** Under #343 a window stands only on an open `release`-labeled issue whose `## Members` record holds at least one open member, with no fallback to the gate — `release_window_members` reads that heading and nothing else. Release-init writes that record at **step 3**, and step 3 never ran. No window ever stood here, no membership call is owed on any mint, and the sweep draws no window flag. ## Predecessor gate Cleared, with nothing to declare it against. !267 merged as `8f0ef79` at 2026-08-26T20:18:17Z; the door tagged and published `0.6.3` at 20:20:18Z and re-armed `main` to `0.6.4-dev` at `bcbcd90`. 0.6.3 cut epic-less, so there is no predecessor issue for this epic to gate on. The release is sound on the one check that could only run at the merge: `CI / self-guards` is **success** on `8f0ef796` (run 2399), so `changelog-assembled` graded the real fragment set at the real merge base. That is the check 0.6.2 failed. ## Step 1 — the survey Measured 2026-08-26T20:26Z against `origin/main` at `bcbcd90`. **The board is empty.** Open issues: exactly one, #265, at `post-merge`. Open pull requests: none. Open proposals: none. There is also no predecessor epic, so there is no "to mint when this arc opens" list to draw from — 0.6.3 left none. **The one accumulated deferral.** `docs/UPSTREAM-SYNC.md`: *"Upstream's drill-record fixes and the upstream `0.7.0` through `0.7.4` line remain deferred to the next sync campaign."* That is the only recorded, unspent deferral in the tree, and it has grown past what the record says: | | | |---|---| | ancestry baseline (`.upstream-ref`) | `8c3a4d1dee2bdb5ac06a632a285bb65ab2615214` — upstream `0.6.0`, merged by #198 | | recorded as deferred | upstream `0.7.0` through `0.7.4` | | measured deferred today | upstream `0.7.0` through `0.7.6` — **seven** releases | | upstream `0.7.5` | tagged 2026-08-19, so it was already out when the record was written | | upstream `0.7.6` | tagged 2026-08-25 | 0.6.2's content came across by **port** (#229, #230) rather than merge, so no upstream ancestry moved and `.upstream-ref` still names upstream `0.6.0`. **The one finding this survey held back — now minted as #269.** That deferral range is stale by two releases. Whether it was a standalone doc fix or would be absorbed by a campaign rewriting the whole port record depended on the ruling, so the survey left it. The ruling answered both halves at once: fix the record now, and the campaign that eventually consumes it merges rather than ports. #269 carries both, `ready` and unblocked. ## Steps 2 and 3 — never ran There was nothing to graph and no membership to write while the ruling stood, and option C means there never will be: a window with no members has no graph. `## Members` stays absent, which is exactly how #343 says a non-window reads. ## Step 4 — ruled: C, no window `RELEASES.md` names the operator's blessing as the one step this chain never automates, and it was a hard block rather than a timed default because the choice sets a published tag's version number. It was answered on 2026-08-27T09:48:51Z: **C — no window yet**, no `0.6.4`, close this epic unshipped. `RELEASES.md` release-init anticipates exactly this outcome — "if init finds no work worth minting, the operator either folds the empty window into a later release or skips the version, recording that ruling on the epic before closing it unshipped." The ruling's two directions are dispatched: the `docs/UPSTREAM-SYNC.md` record fix is minted as #269, and the next window's identity — the sync campaign, and it **merges** (`A/merge`) — is recorded both in the closing comment below and, by #269, in the procedure file itself. Nothing was held waiting on this: the board was idle by design, not by blockage. ## Task list - [x] Step 1 — survey the accumulated work - [x] Steps 2 and 3 — not run, and under C never will be: no members, so no graph, no waves, and no `## Members` record - [x] Step 4 — the operator ruled 2026-08-27: **C**, no `0.6.4`, no window - [x] Step 5 — closed unshipped instead of shipped. This close is **not** the trigger for another window: the next release-init runs when there is work to survey, or when the operator calls for the sync campaign ## Board note, not part of this window #265 stays on its own `post-merge` track and is not a member of anything here. Its code shipped in `d439ff6`; only its criterion 8 is outstanding, waiting on an operator `workflow_dispatch` of `self-labels-sweep.yml` with `bootstrap=yes`. Re-measured at this survey: ceremony's live `needs-triage` description is still *"Did not come through triage — owes normalization or conversion to a discussion"*, against `LABELS.md`'s *"a proposal or stray issue that did not come through triage — it owes normalization into work or a reasoned refusal"*. Unchanged. Its fallback date is unchanged: 2026-09-01T22:20Z.

claude-bot-andresmgsl added the

epic

release

scope:release-flow

labels 2026-08-26 20:26:46 +00:00

claude-bot-andresmgsl commented

2026-08-26 20:27:37 +00:00

Author

Member

🧭 needs-ruling — what the next release window is, and therefore what version number it cuts.

Options: A — run the deferred upstream sync campaign as the next window and cut at upstream's number B — cut a forge-local 0.6.4 first and defer the sync campaign again C — open no window yet; close this epic unshipped and re-run release-init when work accumulates
Recommend: A, because it is the only accumulated work this survey found, and it has already grown by two releases while sitting deferred.
Blocked: release-init steps 2 and 3 stop here — the dependency graph and the membership record cannot be written against an unidentified window — as does the mint of the stale-range doc fix; everything else continues, the board having no open work issue, no open proposal and no open PR, and #265's post-merge track being untouched either way.
Default: none — hard block. The choice sets a published tag's version number, release.yml refuses to re-release an existing tag, and RELEASES.md reserves this step to the operator in the first place.

Analysis

Why this is a ruling and not triage's pick

Two separate things make it the operator's. RELEASES.md step 4 — "Ask the
operator to bless the order... The operator's blessing is the one step this
chain never automates." And TRIAGE.md outcome 3 — published artifacts. A
version number is published and untakeable back, which is also why the
Default: line above is a hard block rather than a timed default: BUILDER.md
says unsure is not a tie, and published artifacts are hard blocks by
construction.

What each option costs

A — the sync campaign is the window. Standing resolution #197 D2 is that
VERSION and both CEREMONY_SELF_REF carriers take upstream's number, so
this window would cut 0.7.6 (or upstream's number when it closes), not
0.6.4. The merge door's re-arm of main to 0.6.4-dev at bcbcd90 is
mechanical and the campaign would overwrite it; that is a consequence to expect,
not a defect to repair first.

This option carries one sub-decision that does not need its own ruling now,
because docs/UPSTREAM-SYNC.md already frames it: port or merge. "If that
campaign merges rather than ports, it is the campaign that advances
.upstream-ref; another port leaves the ancestry baseline unchanged." 0.6.2
was a port, so the ancestry baseline is still upstream 0.6.0 (8c3a4d1) while
upstream has cut seven releases past it. The gap between "content baseline" and
"ancestry baseline" widens with every port. I would graph that choice at step 2
and put it in front of you with the waves at step 4 — but if you want to settle
it in the same breath as this ruling, say A/merge or A/port.

B — a forge-local 0.6.4 first. This is the option the survey cannot
support on its own: there is no forge-local work on the board to fill it. Open
issues total one, #265, and it is post-merge — already shipped code awaiting a
single dispatch. Picking B is therefore also a statement that work exists which
this survey could not see, and I would need it named before steps 1 through 3
could run.

C — no window yet. Cheapest and fully reversible. RELEASES.md provides for
it: "If init finds no work worth minting, the operator either folds the empty
window into a later release or skips the version, recording that ruling on the
epic before closing it unshipped." The board is already idle and truthful, so C
costs nothing today; its only price is that the sync deferral keeps growing, and
the record of it in docs/UPSTREAM-SYNC.md stays two releases stale.

Why the recommendation is A

The deferral is not theoretical and it is not static. It was written naming
upstream 0.7.0 through 0.7.4; upstream 0.7.5 was in fact already tagged
(2026-08-19) when it was written, and 0.7.6 landed 2026-08-25. Seven upstream
releases now sit outside this tree's ancestry. Each further port widens the
delta that the next merge has to reconcile, so the campaign gets more expensive
the longer C runs — which is the argument for A over C, and there is no
identified work behind B.

What I am not doing on my own

Not minting the docs/UPSTREAM-SYNC.md range fix. Under A the campaign rewrites
that whole port record and the standalone fix becomes churn; under B or C it is
a real small mint. Minting it now would decide this question by the back door.

Not writing a membership record. Under #343 that heading is the window, so
writing one before this ruling would stand a window whose contents nobody has
blessed, and would immediately start charging every new mint a binary membership
call against it.

🧭 **needs-ruling** — what the next release window *is*, and therefore what version number it cuts. **Options:** A — run the deferred upstream sync campaign as the next window and cut at upstream's number B — cut a forge-local `0.6.4` first and defer the sync campaign again C — open no window yet; close this epic unshipped and re-run release-init when work accumulates **Recommend:** A, because it is the only accumulated work this survey found, and it has already grown by two releases while sitting deferred. **Blocked:** release-init steps 2 and 3 stop here — the dependency graph and the membership record cannot be written against an unidentified window — as does the mint of the stale-range doc fix; everything else continues, the board having no open work issue, no open proposal and no open PR, and #265's `post-merge` track being untouched either way. **Default:** none — hard block. The choice sets a published tag's version number, `release.yml` refuses to re-release an existing tag, and `RELEASES.md` reserves this step to the operator in the first place. <details><summary>Analysis</summary> ### Why this is a ruling and not triage's pick Two separate things make it the operator's. `RELEASES.md` step 4 — *"Ask the operator to bless the order... The operator's blessing is the one step this chain never automates."* And `TRIAGE.md` outcome 3 — published artifacts. A version number is published and untakeable back, which is also why the `Default:` line above is a hard block rather than a timed default: `BUILDER.md` says unsure is not a tie, and published artifacts are hard blocks by construction. ### What each option costs **A — the sync campaign is the window.** Standing resolution #197 D2 is that `VERSION` and both `CEREMONY_SELF_REF` carriers take **upstream's** number, so this window would cut `0.7.6` (or upstream's number when it closes), not `0.6.4`. The merge door's re-arm of `main` to `0.6.4-dev` at `bcbcd90` is mechanical and the campaign would overwrite it; that is a consequence to expect, not a defect to repair first. This option carries one sub-decision that does not need its own ruling now, because `docs/UPSTREAM-SYNC.md` already frames it: **port or merge.** *"If that campaign merges rather than ports, it is the campaign that advances `.upstream-ref`; another port leaves the ancestry baseline unchanged."* 0.6.2 was a port, so the ancestry baseline is still upstream `0.6.0` (`8c3a4d1`) while upstream has cut seven releases past it. The gap between "content baseline" and "ancestry baseline" widens with every port. I would graph that choice at step 2 and put it in front of you with the waves at step 4 — but if you want to settle it in the same breath as this ruling, say `A/merge` or `A/port`. **B — a forge-local `0.6.4` first.** This is the option the survey cannot support on its own: there is no forge-local work on the board to fill it. Open issues total one, #265, and it is `post-merge` — already shipped code awaiting a single dispatch. Picking B is therefore also a statement that work exists which this survey could not see, and I would need it named before steps 1 through 3 could run. **C — no window yet.** Cheapest and fully reversible. `RELEASES.md` provides for it: *"If init finds no work worth minting, the operator either folds the empty window into a later release or skips the version, recording that ruling on the epic before closing it unshipped."* The board is already idle and truthful, so C costs nothing today; its only price is that the sync deferral keeps growing, and the record of it in `docs/UPSTREAM-SYNC.md` stays two releases stale. ### Why the recommendation is A The deferral is not theoretical and it is not static. It was written naming upstream `0.7.0` through `0.7.4`; upstream `0.7.5` was in fact already tagged (2026-08-19) when it was written, and `0.7.6` landed 2026-08-25. Seven upstream releases now sit outside this tree's ancestry. Each further port widens the delta that the next merge has to reconcile, so the campaign gets more expensive the longer C runs — which is the argument for A over C, and there is no identified work behind B. ### What I am not doing on my own Not minting the `docs/UPSTREAM-SYNC.md` range fix. Under A the campaign rewrites that whole port record and the standalone fix becomes churn; under B or C it is a real small mint. Minting it now would decide this question by the back door. Not writing a membership record. Under #343 that heading *is* the window, so writing one before this ruling would stand a window whose contents nobody has blessed, and would immediately start charging every new mint a binary membership call against it. </details>

claude-bot-andresmgsl added the

needs-ruling

label 2026-08-26 20:27:42 +00:00

claude-bot-andresmgsl referenced this issue

2026-08-26 20:29:27 +00:00

release: forge 0.6.3 #267

forgejo-actions commented

2026-08-27 09:01:27 +00:00

@claude-bot-andresmgsl — this ruling is 12 hours past its labeled event: the ladder's
12h rung (BUILDER.md — the ruling ask,
heavy-duty/ceremony#50 D13). Mechanically read, the escalation carries
Default: none — a hard block; no default ever fires.

The rung's duty is the flag-setter's: re-read the Default: against
everything that has landed since the flag went up — does it still hold, and
has reasonable doubt appeared? A stale default does not fire, and new doubt
makes it a hard block. The rungs run on the labeled clock and do not
reset on activity; this comment fires once per flag episode.

@claude-bot-andresmgsl — this ruling is 12 hours past its `labeled` event: the ladder's 12h rung ([BUILDER.md — the ruling ask](https://github.com/heavy-duty/ceremony/blob/main/BUILDER.md#the-ruling-ask), heavy-duty/ceremony#50 D13). Mechanically read, the escalation carries `Default: none` — a hard block; no default ever fires. The rung's duty is the flag-setter's: re-read the `Default:` against everything that has landed since the flag went up — does it still hold, and has reasonable doubt appeared? A stale default does not fire, and new doubt makes it a hard block. The rungs run on the `labeled` clock and do not reset on activity; this comment fires once per flag episode.

claude-bot-andresmgsl commented

2026-08-27 09:07:29 +00:00

Author

Member

⏱️ 12h rung — the re-read, not a fire. I set this flag, so the rung is mine to answer. Re-measured 2026-08-27T09:07Z, against everything that has landed since the labeled event at 2026-08-26T20:27:42Z.

Nothing has landed that touches it.

	at the survey	now
`origin/main`	`bcbcd90` (`VERSION` = `0.6.4-dev`)	unchanged
open issues	#268, #265	unchanged — #265 still `post-merge`, labels unchanged
open pull requests	none	none
upstream's highest tag	`0.7.6`	still `0.7.6` (`git ls-remote --tags github.com/heavy-duty/ceremony`)
`.upstream-ref`	`8c3a4d1` — upstream `0.6.0`	unchanged
this epic's label events	the four mint-time adds	unchanged — no ruling has arrived as a label

The Default: still holds, and it cannot go stale. Default: none — hard block does not rest on a measurement that could move: RELEASES.md step 4 reserves the blessing to the operator, the choice sets a published tag's version number, and release.yml refuses to re-release an existing tag. Nothing that could land would convert that into a timed default. No default fires; the block stands.

No new doubt appeared, so there is nothing to harden — it was a hard block on day one. The recommendation is unchanged: A. Its case moves in one direction only, and it did not move in these twelve hours: no upstream release cut, so the range recorded in docs/UPSTREAM-SYNC.md is stale by exactly the same two releases as at the survey, not three.

The Blocked: line is also still true as written. Release-init steps 2 and 3 stop, and the docs/UPSTREAM-SYNC.md range fix stays unminted; nothing else is held. The board's idleness is by design — there is no open work issue, no open proposal, no open PR — so the wait costs nothing today beyond the deferral's own growth.

What the next rung does, so the shape of the wait is visible. The 24h rung falls at 2026-08-27T20:27:42Z. Because triage set this flag, that rung and the past-24h rung land on the same actor: if the ruling has not arrived by then, it becomes my duty to pick, record the pick as a decision, and stay accountable for it (TRIAGE.md outcome 3, #50 D13–D14). I would pick A, and would take the unresolved sub-decision as A/merge unless you say otherwise, since a further port is what keeps widening the ancestry gap. Nothing publishes by that: the version stamp still lands in a release PR you gate at merge, and the membership record steps 2 and 3 would write is a heading, editable and reversible.

A one-word reply — A, A/merge, A/port, B, or C — closes this out and I run the held steps in the next tick.

⏱️ **12h rung — the re-read, not a fire.** I set this flag, so the rung is mine to answer. Re-measured **2026-08-27T09:07Z**, against everything that has landed since the `labeled` event at 2026-08-26T20:27:42Z. **Nothing has landed that touches it.** | | at the survey | now | |---|---|---| | `origin/main` | `bcbcd90` (`VERSION` = `0.6.4-dev`) | unchanged | | open issues | #268, #265 | unchanged — #265 still `post-merge`, labels unchanged | | open pull requests | none | none | | upstream's highest tag | `0.7.6` | still `0.7.6` (`git ls-remote --tags github.com/heavy-duty/ceremony`) | | `.upstream-ref` | `8c3a4d1` — upstream `0.6.0` | unchanged | | this epic's label events | the four mint-time adds | unchanged — no ruling has arrived as a label | **The `Default:` still holds, and it cannot go stale.** `Default: none — hard block` does not rest on a measurement that could move: `RELEASES.md` step 4 reserves the blessing to the operator, the choice sets a **published** tag's version number, and `release.yml` refuses to re-release an existing tag. Nothing that could land would convert that into a timed default. No default fires; the block stands. **No new doubt appeared**, so there is nothing to harden — it was a hard block on day one. The recommendation is unchanged: **A**. Its case moves in one direction only, and it did not move in these twelve hours: no upstream release cut, so the range recorded in `docs/UPSTREAM-SYNC.md` is stale by exactly the same two releases as at the survey, not three. The `Blocked:` line is also still true as written. Release-init steps 2 and 3 stop, and the `docs/UPSTREAM-SYNC.md` range fix stays unminted; nothing else is held. The board's idleness is by design — there is no open work issue, no open proposal, no open PR — so the wait costs nothing today beyond the deferral's own growth. **What the next rung does, so the shape of the wait is visible.** The 24h rung falls at **2026-08-27T20:27:42Z**. Because triage set this flag, that rung and the past-24h rung land on the same actor: if the ruling has not arrived by then, it becomes my duty to pick, record the pick as a decision, and stay accountable for it (`TRIAGE.md` outcome 3, #50 D13–D14). I would pick **A**, and would take the unresolved sub-decision as `A/merge` unless you say otherwise, since a further port is what keeps widening the ancestry gap. Nothing publishes by that: the version stamp still lands in a release PR you gate at merge, and the membership record steps 2 and 3 would write is a heading, editable and reversible. A one-word reply — `A`, `A/merge`, `A/port`, `B`, or `C` — closes this out and I run the held steps in the next tick.

andres commented

2026-08-27 09:48:51 +00:00

Owner

Ruling: C — no window yet.

A is the right destination, but not now. Measured: upstream 0.7.0–0.7.6 is
448 commits / 87 files / +24,161 lines — roughly 25× the 0.6.2 port — and it
rewrites all three files the forge delta lives in (runner-isolated +1619,
labels-reconcile +889, issueflow-reconcile +758). That is not a campaign to
open while crew's burn work is unfinished and its main is red.

The "it gets more expensive while you wait" argument doesn't carry the decision:
the cost is the 24k lines already standing, and upstream adds about one release
a week. A short wait is noise against that.

B is unsupported — the survey is right that there is no forge-local work to fill
a 0.6.4.

So: close this epic unshipped per RELEASES.md, no 0.6.4, no window.

Two directions:

Mint the docs/UPSTREAM-SYNC.md range fix now. The record says 0.7.0
through 0.7.4; it is 0.7.0 through 0.7.6. Under C that is a real small
mint, and the record should be true while it waits.
The next window is the sync campaign, and it merges — A/merge.
.upstream-ref has been pinned at upstream 0.6.0 since #198 because 0.6.2
came across as a port. Another port leaves it pinned and guarantees a third,
larger campaign. When it runs, it advances the ancestry baseline.

Re-run release-init when there is work to survey, or when I call for the sync.

**Ruling: C — no window yet.** A is the right destination, but not now. Measured: upstream `0.7.0`–`0.7.6` is 448 commits / 87 files / +24,161 lines — roughly 25× the 0.6.2 port — and it rewrites all three files the forge delta lives in (`runner-isolated` +1619, `labels-reconcile` +889, `issueflow-reconcile` +758). That is not a campaign to open while crew's burn work is unfinished and its main is red. The "it gets more expensive while you wait" argument doesn't carry the decision: the cost is the 24k lines already standing, and upstream adds about one release a week. A short wait is noise against that. B is unsupported — the survey is right that there is no forge-local work to fill a 0.6.4. So: close this epic unshipped per `RELEASES.md`, no `0.6.4`, no window. Two directions: 1. **Mint the `docs/UPSTREAM-SYNC.md` range fix now.** The record says `0.7.0` through `0.7.4`; it is `0.7.0` through `0.7.6`. Under C that is a real small mint, and the record should be true while it waits. 2. **The next window is the sync campaign, and it merges — `A/merge`.** `.upstream-ref` has been pinned at upstream `0.6.0` since #198 because 0.6.2 came across as a port. Another port leaves it pinned and guarantees a third, larger campaign. When it runs, it advances the ancestry baseline. Re-run release-init when there is work to survey, or when I call for the sync.

claude-bot-andresmgsl referenced this issue

2026-08-27 09:58:14 +00:00

docs/UPSTREAM-SYNC.md — the deferral record names a ceiling that expired before it was written, and an if the operator has now answered #269

claude-bot-andresmgsl commented

2026-08-27 10:00:20 +00:00

Author

Member

✅ Ruling recorded — C. This epic closes unshipped, and needs-ruling comes off with it.

I set this flag, so closing it out is mine (TRIAGE.md outcome 3). The decision, in one place, so nobody has to reconstruct it from the thread:


Question	what the release window after 0.6.3 is, and therefore what version number it cuts
Decided by	the operator (@andres), 2026-08-27T09:48:51Z
Chosen	C — open no window yet; close this epic unshipped and re-run release-init when work accumulates
A, rejected for now	right destination, wrong moment: the deferred upstream delta rewrites all three files the forge delta lives in, and it is not a campaign to open while crew's burn work is unfinished and its main is red
B, rejected	unsupported — the survey found no forge-local work to fill an `0.6.4`, which is what step 1 said and the ruling confirmed
The recommendation I made	A. Overturned, and the reason is on the record: the "it gets more expensive while you wait" argument does not carry the decision, because the cost is the ~24k lines already standing and upstream adds about one release a week — a short wait is noise against that

RELEASES.md provides for exactly this outcome — "if init finds no work worth minting, the operator either folds the empty window into a later release or skips the version, recording that ruling on the epic before closing it unshipped." The body above has been corrected to match the ruling rather than left describing a pending block: steps 2 and 3 are marked never-run, step 4 carries the answer, and the task list no longer shows an open ladder.

The two directions, both dispatched in this tick

1. The docs/UPSTREAM-SYNC.md record fix is minted: #269, ready and unblocked. It is the mint this survey deliberately held back, and C is what releases it. No collision edge is owed (#288) and no membership call is owed (#343): board read 2026-08-27T09:57Z — no open PRs, and #265 is post-merge, so it is neither claimable nor a carrier.

#269 fixes the range and the sentence beside it in one edit, because the ruling made both stale at once. The record said upstream 0.7.0 through 0.7.4; the floor is right and the ceiling expired before it was written — 0.7.5 was tagged 2026-08-19, five days before fdb7d75 recorded the range on 2026-08-24, and 0.7.6 landed 2026-08-25. So #269 records a floor and a dated measurement instead of a new ceiling that would expire inside a month at upstream's tagging rate.

2. The next window is the sync campaign, and it merges — A/merge. That answers the sub-decision I flagged as unresolved at the 12h rung, and it is recorded twice on purpose: here, and by #269 in docs/UPSTREAM-SYNC.md itself under a new ## The next campaign merges section. A decision that only lives in a closed epic is one the next sync will not read; the procedure file is where it will be looked for. .upstream-ref has been pinned at 8c3a4d1 — upstream 0.6.0, merged by #198 — since 0.6.2 came across as a port, and another port would leave it pinned and guarantee a third, larger campaign. The campaign that runs advances the ancestry baseline.

Board state after this tick

No release-labeled issue is open; no window stands and none ever did here — ## Members was never written, which under #343 is silence rather than a false flag. No mint owes a membership call.
Open issues: #269 (ready, unblocked, unassigned) and #265 (post-merge, criterion 8 still waiting on an operator workflow_dispatch of self-labels-sweep.yml with bootstrap=yes, fallback date 2026-09-01T22:20Z — untouched by this ruling either way). No open PRs.
main stays at bcbcd90, VERSION = 0.6.4-dev. The ruling does not reserve 0.6.4: under standing resolution #197 D2 the sync campaign cuts upstream's number, so the re-arm's -dev string is mechanical and decides nothing. Nothing was tagged or published, which is why C is fully reversible.
No attention is set: this epic is unassigned and #269 is unclaimed, and flagging an unassigned issue is a board bug rather than a demand.

Closing this epic releases nothing — no open issue declares it as a blocker — and this close is not a trigger for the next window, which is the one way it differs from a shipped close. The next release-init runs when there is work to survey, or when @andres calls for the sync.

✅ **Ruling recorded — C. This epic closes unshipped, and `needs-ruling` comes off with it.** I set this flag, so closing it out is mine (`TRIAGE.md` outcome 3). The decision, in one place, so nobody has to reconstruct it from the thread: | | | |---|---| | **Question** | what the release window after 0.6.3 *is*, and therefore what version number it cuts | | **Decided by** | the operator (@andres), [2026-08-27T09:48:51Z](https://forgejo.heavyduty.builders/heavy-duty/ceremony/issues/268#issuecomment-24045) | | **Chosen** | **C** — open no window yet; close this epic unshipped and re-run release-init when work accumulates | | **A, rejected for now** | right destination, wrong moment: the deferred upstream delta rewrites all three files the forge delta lives in, and it is not a campaign to open while crew's burn work is unfinished and its main is red | | **B, rejected** | unsupported — the survey found no forge-local work to fill an `0.6.4`, which is what step 1 said and the ruling confirmed | | **The recommendation I made** | A. Overturned, and the reason is on the record: the *"it gets more expensive while you wait"* argument does not carry the decision, because the cost is the ~24k lines already standing and upstream adds about one release a week — a short wait is noise against that | `RELEASES.md` provides for exactly this outcome — *"if init finds no work worth minting, the operator either folds the empty window into a later release or skips the version, recording that ruling on the epic before closing it unshipped."* The body above has been corrected to match the ruling rather than left describing a pending block: steps 2 and 3 are marked never-run, step 4 carries the answer, and the task list no longer shows an open ladder. ## The two directions, both dispatched in this tick **1. The `docs/UPSTREAM-SYNC.md` record fix is minted: #269**, `ready` and unblocked. It is the mint this survey deliberately held back, and C is what releases it. No collision edge is owed (#288) and no membership call is owed (#343): board read 2026-08-27T09:57Z — no open PRs, and #265 is `post-merge`, so it is neither claimable nor a carrier. #269 fixes the range and the sentence beside it in one edit, because the ruling made both stale at once. The record said upstream `0.7.0` through `0.7.4`; the floor is right and the ceiling expired before it was written — `0.7.5` was tagged 2026-08-19, five days *before* [`fdb7d75`](https://forgejo.heavyduty.builders/heavy-duty/ceremony/commit/fdb7d75) recorded the range on 2026-08-24, and `0.7.6` landed 2026-08-25. So #269 records a floor and a dated measurement instead of a new ceiling that would expire inside a month at upstream's tagging rate. **2. The next window is the sync campaign, and it merges — `A/merge`.** That answers the sub-decision I flagged as unresolved at the 12h rung, and it is recorded twice on purpose: here, and by #269 in `docs/UPSTREAM-SYNC.md` itself under a new `## The next campaign merges` section. A decision that only lives in a closed epic is one the next sync will not read; the procedure file is where it will be looked for. `.upstream-ref` has been pinned at `8c3a4d1` — upstream `0.6.0`, merged by #198 — since 0.6.2 came across as a port, and another port would leave it pinned and guarantee a third, larger campaign. The campaign that runs advances the ancestry baseline. ## Board state after this tick - No `release`-labeled issue is open; **no window stands and none ever did here** — `## Members` was never written, which under #343 is silence rather than a false flag. No mint owes a membership call. - Open issues: **#269** (`ready`, unblocked, unassigned) and **#265** (`post-merge`, criterion 8 still waiting on an operator `workflow_dispatch` of `self-labels-sweep.yml` with `bootstrap=yes`, fallback date 2026-09-01T22:20Z — untouched by this ruling either way). No open PRs. - `main` stays at `bcbcd90`, `VERSION` = `0.6.4-dev`. **The ruling does not reserve `0.6.4`**: under standing resolution #197 D2 the sync campaign cuts *upstream's* number, so the re-arm's `-dev` string is mechanical and decides nothing. Nothing was tagged or published, which is why C is fully reversible. - No `attention` is set: this epic is unassigned and #269 is unclaimed, and flagging an unassigned issue is a board bug rather than a demand. Closing this epic releases nothing — no open issue declares it as a blocker — and **this close is not a trigger for the next window**, which is the one way it differs from a shipped close. The next release-init runs when there is work to survey, or when @andres calls for the sync.

claude-bot-andresmgsl removed the

needs-ruling

label 2026-08-27 10:00:23 +00:00

claude-bot-andresmgsl closed this issue

2026-08-27 10:00:24 +00:00