heavy-duty/ceremony
7
0
Fork 2
Code Issues 1 Pull requests Projects Releases 8 Packages Wiki Activity Actions

adopt upstream 0.6.1–0.6.3 as forge release 0.6.2 — sync epic #228

New issue
Closed
opened 2026-08-17 22:26:57 +00:00 by claude-bot-andresmgsl · 15 comments
claude-bot-andresmgsl commented 2026-08-17 22:26:57 +00:00
Member
Copy link

Context

Upstream ceremony (github.com/heavy-duty/ceremony — READ-ONLY source, never
write there) has released past what this forge carries. Measured 2026-08-17
against a fresh fetch:

  • This repo's history contains upstream 0.6.0 (merge-base 8c3a4d1); it
    does NOT contain upstream 0.6.1, 0.6.2, or 0.6.3 — 30 non-merge
    commits, 16 files, +798/−75.
  • The tag names collide but the content does not: this forge's 0.6.1
    (tag at 338cf5f) is its own consolidation release and shares nothing
    but ancestry with upstream's 0.6.1. Every child of this epic must cite
    upstream tags as upstream-0.6.x to keep the two lines unconfusable.
  • Upstream has also shipped 0.7.0–0.7.4. Out of scope here — that
    is the next sync campaign, and this epic's runbook record is what makes
    it cheap.

The adoption model is the one this forge's own 0.6.1 set: consolidate the
upstream releases into ONE forge release, 0.6.2, with a
docs/UPSTREAM-SYNC.md record and #220-style gap statements where forge
adaptations diverge from upstream bytes.

What the three upstream releases contain:

  • upstream-0.6.1 (docs): CONTRIBUTING routes the vendored set through
    docs/VENDORED.txt (#316, #311); BUILDER.md scopes the green-check
    precondition to the act it governs (#330); RELEASES.md gains the
    post-merge gate-member split rule (#329).
  • upstream-0.6.2 (docs): BUILDER.md parked-claim ordering — an
    operator-owned remainder parks the claim, never the handoff; a session
    does not block on a producer it cannot prove alive (#336).
  • upstream-0.6.3 (code): a release issue records window membership
    under a ## Members heading and the standing-window decision reads that
    record with no gate fallback (#343); release-window carriers are excluded
    from their own gates and stale board-flag claims are suppressed (#327);
    the membership-row parser is hardened to CommonMark (three-space indent
    bound, nine-digit ordered markers, code blocks and sub-rows are non-rows).
  • Upstream's workflow diffs in the range are pure CEREMONY_SELF_REF
    pin-stamps — no behavior; the forge stamps its own pins at release.

Overlap that forces adaptation (both lines touched these since the
merge-base): actions/issueflow-reconcile/issueflow-reconcile.sh,
test/issueflow-reconcile.test.sh, CONTRIBUTING.md, the three workflows,
CHANGELOG.md, VERSION. Port the LOGIC onto the forge's Forgejo-adapted
files — never overwrite them with upstream bytes.

Spec — children in dependency order

  1. #229 — doctrine docs: upstream-0.6.1 + upstream-0.6.2 content (all docs).

  2. #230 — reconciler: upstream-0.6.3 membership record + gate fixes + parser
    hardening, adapted to the forge reconciler and its test.

  3. #231 — release 0.6.2: three stamps, consolidated changelog section crediting
    upstream-0.6.1–0.6.3 with gap statements, UPSTREAM-SYNC.md records the new
    content baseline (upstream-0.6.3) beside the unchanged ancestry
    baseline (8c3a4d1), consumer-pin follow-up noted for crew's .ceremony/
    mirror.

    (Corrected 2026-08-24: this line read "merge-base advanced". It never could
    be. This campaign adopts upstream by PORT — the model this epic's Context
    states — so no merge exists and .upstream-ref stays at 8c3a4d1, which
    test/upstream-delta.test.sh requires to be an ancestor of HEAD. The
    phrase sent #231's builder into a hard block on 2026-08-24T00:38Z; #231's
    spec item 3 now carries the two-baseline form.)

3a. #246 — the 0.6.2 release prose, as a fragment. Preparatory to #231 and
minted 2026-08-24: the upstream credits this epic's second acceptance
criterion demands cannot be typed into the assembled section, because
changelog-assembled replays the merge base's fragments byte-for-byte.
They land as changelog.d/246.md on main before #231 assembles — the
standing resolution #220 set for the 0.6.1 release. Not an adoption child,
listed here because #231 cannot finish without it.

Task list

  • #229 — doctrine docs: upstream-0.6.1/0.6.2 ports
  • #230 — issueflow reconciler: upstream-0.6.3 membership record, gate fixes, parser hardening
  • #231 — release 0.6.2: three stamps, consolidated changelog, UPSTREAM-SYNC record
  • #246 — changelog.d/246.md: the release prose #231 assembles (preparatory, not an adoption child)
  • #263 — CHANGELOG.md + changelog.d/238.md: the ruled option-B correction of the shipped 0.6.2 section (remedial, not an adoption child)

Phase 3 is done as work, and this epic's wake has fired: !250 merged
2026-08-24T15:55:13Z as 5a8fce8, and 0.6.2 is tagged and published. The
release door ran itself through from there — tag 0.6.2 at 5a8fce8, release
published 16:10:40Z (not a draft, not a prerelease), and main re-armed to
0.6.3-dev as ca7ce6e at 16:10:57Z by release.yml's own step rather than a
second PR. The sweep moved #231 to post-merge and released the claim at
15:58:08–09Z, with its transition comment at 15:58:06Z. Every paragraph that
stood in this block described a build in flight — a draft flag, a panel round, a
state:addressing — and all of it is spent; it is replaced rather than
annotated, because a stale epic misleads every scan. Label events for this
epic and for #231 paged by hand at 2026-08-24T16:21–16:31Z, not read off the
thread.

#231 is closed on all seven criteria as of 2026-08-25T18:36:14Z, and #263 with
it at 18:34:09Z. The block that follows is why the last box took a day and a
ruling to tick, kept because it explains the shape of the campaign's end. Six of
its seven acceptance criteria were verified on the day of the release; the
seventh — "tag exists; release published; guards green" — had two legs verified
and one that fails. CI / self-guards is RED at the tagged commit 5a8fce8:
changelog.d/238.md landed on main at 15:54 with !249, after !250's merge
base 7bdae45, so bin/changelog-assemble never consumed it and
changelog-armed refuses the released tree. The guard is green again on
main — corrected 2026-08-25T04:45Z, because ca7ce6e is not where it was
measured: release.yml's own re-arm push triggers no ci.yml run, so that
commit carries no grade at all. The first measured green self-guards after
the tag is 46458ba (2026-08-24T18:53:47Z), and every graded main commit
from there forward is green on it — the ungraded re-arm is the only gap in the
chain, and this is written as that invariant rather than as a head that expires.
main is healthy and the red is bounded to the tagged commit. The material consequence was not cosmetic: 0.6.2 contains #238's
code and its published section does not credit it — and that half is now
repaired on the tree, though deliberately not in the publication.

Disposition of a published release's notes is the operator's call, never
triage's, so it was escalated on #231 with needs-ruling set 2026-08-24T16:27:54Z
— three options (accept and let the fragment fold into 0.6.3; consume it into the
0.6.2 section on main; that plus re-publish the body), recommendation B, hard
block. That ladder has run out and the flag is gone. The operator answered
nothing — no comment and no label event from @andres anywhere in #231's
timeline — so at the 24h rung on 2026-08-25T17:01Z triage picked option B,
recorded it as a decision on #231, removed needs-ruling in the same comment,
and minted the work as #263: the 0.6.2 section on main gains #238's entry
in the assembler's own canonical position, changelog.d/238.md is consumed, and
the published release body and the tag are left exactly as they are. The red at
5a8fce8 is accepted as permanent and bounded — that commit is immutable, so no
pull request can ever re-grade it.

That chain of two has run, and it closed this epic. #263 was claimed
2026-08-25T17:07:13Z, built at !264 and merged 18:28:48Z as 0533766. Triage
measured both post-merge facts against main at 18:31Z — the 0.6.2 section
byte-identical to the assembler's own seven-fragment output (diff empty) and
changelog.d/238.md absent — moved #263 by hand from claimed to post-merge,
ticked its list and closed it at 18:34:09Z; that discharged #231's first
criterion, which was ticked and closed at 18:36:14Z; and this epic closes on that
act. Nothing else on this board ever waited on any of it: #231 was unassigned
and carried no attention throughout, and #263 flagged nobody and collided with
nothing (an open post-merge issue is not a #288 carrier, so the CHANGELOG.md
overlap with #231 took no edge in either direction).

The one thing the campaign leaves permanently unequal, and it is the ruling's
own choice rather than a loose end. From 0533766 forward the tree's 0.6.2
section carries #238's entry and the published 0.6.2 release body does not.
changelog.d/263.md states that divergence in the notes 0.6.3 will ship, so a
consumer meets it without reading this board. The red at 5a8fce8 stays red
forever, accepted and bounded to one immutable commit.

The seventh criterion of #231 was triage's own and is discharged. The crew
pin-bump follow-up is minted: heavy-duty/crew#122,
ready and unblocked, moving crew's ten 0.6.1 refs to 0.6.2 — nine
uses: lines plus the @0\.6\.1 literal buried in .github/actionlint.yaml's
ignore pattern, which a grep for uses: misses — and re-mirroring .ceremony/
with docs-sync --fix in the same commit, because one pin governs machinery and
doctrine. Measured before minting: exactly three mirrored files move under
0.6.2 (BUILDER.md, RELEASES.md, TRIAGE.md), and the three reusable
workflows changed only their own CEREMONY_SELF_REF stamp between the tags, so
no caller contract moves.

Two issues this epic's child was holding as a carrier were released from that
hold, and neither has waited on it since, both
flipped by hand in the same tick because the sweep flips only on a closed
blocker: #241 (collision on .github/workflows/labels.yml; the stamp is on
main and post-merge is not a claimable carrier under #288) went ready at
16:24:01Z, and #251 (whose declared condition was !250's merge, not #231's
close) went ready at 16:25:49Z. Both declarations were rewritten away in the
same tick, and both issues' premises were re-measured against main first —
#241's three labels.yml line references all still hold, and #251's five token
counts in drills/README.md are unchanged. What each has done with its
freedom since is the board's to show, not this epic's, and no reading of it is
kept here — neither is a child of this epic, neither appears in its
## Task list, and nothing either does flows back. (The clause that stood here
reported #241's claim, and was one merge behind within eight hours; it is
replaced by the rule it served rather than corrected a second time.)

The claim history, kept only because it explains the shape. #231 was claimed
twice. The first claim ran 2026-08-24T00:32:17Z → 12:32:23Z, parked on
changelog.d/246.md until !248 landed it at 12:06:55Z, and was released rather
than resumed — a clean exit, since an unpark is a claim like any other and
takes the slot (BUILDER.md). It left no branch and no
worktree; !245, its only PR, closed at 10:47:31Z with its staging commit
preserved as refs/pull/245/head = dcdf30dd5a1900be3605d868c69f4a18636934ce.
The second claim, 13:18:31Z → the merge, cut build/231-release-0-6-2 fresh from
main on a same-repo head and carried the work through. Four attention
episodes opened and closed on #231 across that span, the last at 14:25:46Z; all
four are spent, and no flag stands on either child.

The gate that made the release child claimable is spent and stays spent: #229
landed 2026-08-22 as 4f887a7 (!233), #230 landed 2026-08-23 as 1f5dd39
(!239 merged 16:58:12Z), the sweep flipped #231 to ready at 17:00:57Z, and
release returned in the same triage tick per the lead's stated return
condition of 2026-08-17T23:33:02Z. The label stands no window — #343's
membership record has no fallback to the gate and #231 enumerates no ## Members,
so it is not a window carrier and draws no window flag.

Not a child of this epic, but it gated the release child: #232 — the
test/labels.test.sh:249 roster fixture — landed 2026-08-23 as f69224c
(!237 merged 00:52:05Z) and is closed. test/labels.test.sh is back to 44/44 on
main. It was upstream-independent debt rather than an adoption child, tracked
and closed on #232 itself; this epic did not close on it.

Acceptance criteria

  • Every child closed or explicitly deferred here with its reason. All five
    are closed on verified criteria: #229, #230 and #246 on the day they
    landed; #263 at 2026-08-25T18:34:09Z on its two measured post-merge facts;
    and #231 at 18:36:14Z on all seven of its own, the last of which the
    option-B ruling re-aimed from a green that cannot arrive at 5a8fce8 to
    #263's edit being on main. The deferrals — upstream's drill-record
    bookkeeping fixes and the whole upstream 0.7.x line — are recorded in
    the fourth criterion below and in the shipped 0.6.2 section itself.
  • Forge 0.6.2 released; CHANGELOG.md names the three upstream
    releases and the issues (#316 #311 #330 #329 #336 #343 #327 upstream
    numbering, marked as upstream's). Verified 2026-08-24T16:31Z at
    ca7ce6e: released and published 16:10:40Z; the ## 0.6.2 — 2026-08-24
    section names upstream-0.6.1, upstream-0.6.2 and upstream-0.6.3, and
    all seven issue numbers appear exactly once each in the upstream#N form
    that keeps the two lines unconfusable.
  • docs/UPSTREAM-SYNC.md records this sync and both baselines — the
    new content baseline upstream-0.6.3 and the unchanged ancestry
    baseline 8c3a4d1 — so the 0.7.x campaign starts from a written fact,
    not archaeology, and knows it is the campaign that would advance
    .upstream-ref if it merges rather than ports. Verified: both baselines
    named separately, .upstream-ref byte-unchanged across
    7bdae45..ca7ce6e at 8c3a4d1dee2bdb5ac06a632a285bb65ab2615214, and
    CHANGELOG.md's provenance header carrying the port clause.
  • Explicitly deferred, recorded here: upstream's drill-record
    bookkeeping fixes (86dc2eb, a72085b, 13ffb0d) — they correct
    upstream's own drill files, which this forge does not mirror; and the
    whole upstream 0.7.x line. Recorded twice over: in this criterion, and
    in the shipped 0.6.2 section — "Upstream's drill-record fixes and the
    upstream 0.7.0–0.7.4 line are deferred to the next sync campaign
    (#246)" — so a reader of the published changelog meets the deferral
    without opening this epic.

Dependencies

None open on this board, and the parse over this body is empty. Successor to the
forge 0.6.1 release (epic #197, closed 2026-08-09). The fleet-cutover epic
(crew#1) is independent.

Downstream, and outside this epic's close condition:
crew#122 adopts
0.6.2 in crew. It is a consumer of this release, not a member of this campaign,
and this epic does not wait on it — a cross-repo pin bump is the consumer's work
on the consumer's board, and #231's criterion asked only that it be minted and
linked, which it is.

## Context Upstream ceremony (github.com/heavy-duty/ceremony — READ-ONLY source, never write there) has released past what this forge carries. Measured 2026-08-17 against a fresh fetch: - This repo's history contains upstream `0.6.0` (merge-base `8c3a4d1`); it does NOT contain upstream `0.6.1`, `0.6.2`, or `0.6.3` — 30 non-merge commits, 16 files, +798/−75. - **The tag names collide but the content does not**: this forge's `0.6.1` (tag at `338cf5f`) is its own consolidation release and shares nothing but ancestry with upstream's `0.6.1`. Every child of this epic must cite upstream tags as `upstream-0.6.x` to keep the two lines unconfusable. - Upstream has also shipped `0.7.0`–`0.7.4`. **Out of scope here** — that is the next sync campaign, and this epic's runbook record is what makes it cheap. The adoption model is the one this forge's own `0.6.1` set: consolidate the upstream releases into ONE forge release, `0.6.2`, with a `docs/UPSTREAM-SYNC.md` record and #220-style gap statements where forge adaptations diverge from upstream bytes. What the three upstream releases contain: - **upstream-0.6.1** (docs): CONTRIBUTING routes the vendored set through `docs/VENDORED.txt` (#316, #311); BUILDER.md scopes the green-check precondition to the act it governs (#330); RELEASES.md gains the post-merge gate-member split rule (#329). - **upstream-0.6.2** (docs): BUILDER.md parked-claim ordering — an operator-owned remainder parks the claim, never the handoff; a session does not block on a producer it cannot prove alive (#336). - **upstream-0.6.3** (code): a release issue records window membership under a `## Members` heading and the standing-window decision reads that record with no gate fallback (#343); release-window carriers are excluded from their own gates and stale board-flag claims are suppressed (#327); the membership-row parser is hardened to CommonMark (three-space indent bound, nine-digit ordered markers, code blocks and sub-rows are non-rows). - Upstream's workflow diffs in the range are pure `CEREMONY_SELF_REF` pin-stamps — no behavior; the forge stamps its own pins at release. Overlap that forces adaptation (both lines touched these since the merge-base): `actions/issueflow-reconcile/issueflow-reconcile.sh`, `test/issueflow-reconcile.test.sh`, `CONTRIBUTING.md`, the three workflows, `CHANGELOG.md`, `VERSION`. Port the LOGIC onto the forge's Forgejo-adapted files — never overwrite them with upstream bytes. ## Spec — children in dependency order 1. #229 — doctrine docs: upstream-0.6.1 + upstream-0.6.2 content (all docs). 2. #230 — reconciler: upstream-0.6.3 membership record + gate fixes + parser hardening, adapted to the forge reconciler and its test. 3. #231 — release `0.6.2`: three stamps, consolidated changelog section crediting upstream-0.6.1–0.6.3 with gap statements, UPSTREAM-SYNC.md records the new **content** baseline (`upstream-0.6.3`) beside the **unchanged ancestry** baseline (`8c3a4d1`), consumer-pin follow-up noted for crew's `.ceremony/` mirror. *(Corrected 2026-08-24: this line read "merge-base advanced". It never could be. This campaign adopts upstream by PORT — the model this epic's Context states — so no merge exists and `.upstream-ref` stays at `8c3a4d1`, which `test/upstream-delta.test.sh` requires to be an ancestor of `HEAD`. The phrase sent #231's builder into a hard block on 2026-08-24T00:38Z; #231's spec item 3 now carries the two-baseline form.)* 3a. **#246 — the 0.6.2 release prose, as a fragment.** Preparatory to #231 and minted 2026-08-24: the upstream credits this epic's second acceptance criterion demands cannot be typed into the assembled section, because `changelog-assembled` replays the merge base's fragments byte-for-byte. They land as `changelog.d/246.md` on `main` before #231 assembles — the standing resolution #220 set for the 0.6.1 release. Not an adoption child, listed here because #231 cannot finish without it. ## Task list - [x] #229 — doctrine docs: upstream-0.6.1/0.6.2 ports - [x] #230 — issueflow reconciler: upstream-0.6.3 membership record, gate fixes, parser hardening - [x] #231 — release 0.6.2: three stamps, consolidated changelog, UPSTREAM-SYNC record - [x] #246 — `changelog.d/246.md`: the release prose #231 assembles (preparatory, not an adoption child) - [x] #263 — `CHANGELOG.md` + `changelog.d/238.md`: the ruled option-B correction of the shipped 0.6.2 section (remedial, not an adoption child) **Phase 3 is done as work, and this epic's wake has fired: !250 merged 2026-08-24T15:55:13Z as `5a8fce8`, and `0.6.2` is tagged and published.** The release door ran itself through from there — tag `0.6.2` at `5a8fce8`, release published 16:10:40Z (not a draft, not a prerelease), and `main` re-armed to `0.6.3-dev` as `ca7ce6e` at 16:10:57Z by `release.yml`'s own step rather than a second PR. The sweep moved #231 to `post-merge` and released the claim at 15:58:08–09Z, with its transition comment at 15:58:06Z. **Every paragraph that stood in this block described a build in flight — a draft flag, a panel round, a `state:addressing` — and all of it is spent; it is replaced rather than annotated, because a stale epic misleads every scan.** Label events for this epic and for #231 paged by hand at 2026-08-24T16:21–16:31Z, not read off the thread. **#231 is closed on all seven criteria as of 2026-08-25T18:36:14Z, and #263 with it at 18:34:09Z. The block that follows is why the last box took a day and a ruling to tick, kept because it explains the shape of the campaign's end.** Six of its seven acceptance criteria were verified on the day of the release; the seventh — *"tag exists; release published; guards green"* — had two legs verified and one that fails. **`CI / self-guards` is RED at the tagged commit `5a8fce8`**: `changelog.d/238.md` landed on `main` at 15:54 with !249, *after* !250's merge base `7bdae45`, so `bin/changelog-assemble` never consumed it and `changelog-armed` refuses the released tree. The guard is green again on `main` — corrected 2026-08-25T04:45Z, because `ca7ce6e` is not where it was measured: `release.yml`'s own re-arm push triggers no `ci.yml` run, so that commit carries no grade at all. The first *measured* green `self-guards` after the tag is `46458ba` (2026-08-24T18:53:47Z), and **every graded `main` commit from there forward is green on it** — the ungraded re-arm is the only gap in the chain, and this is written as that invariant rather than as a head that expires. `main` is healthy and the red is bounded to the tagged commit. The material consequence was not cosmetic: **`0.6.2` contains #238's code and its published section does not credit it** — and that half is now repaired on the tree, though deliberately not in the publication. Disposition of a published release's notes is the operator's call, never triage's, so it was escalated on #231 with `needs-ruling` set 2026-08-24T16:27:54Z — three options (accept and let the fragment fold into 0.6.3; consume it into the 0.6.2 section on `main`; that plus re-publish the body), recommendation B, hard block. **That ladder has run out and the flag is gone.** The operator answered nothing — no comment and no label event from `@andres` anywhere in #231's timeline — so at the 24h rung on 2026-08-25T17:01Z triage picked **option B**, recorded it as a decision on #231, removed `needs-ruling` in the same comment, and minted the work as **#263**: the `0.6.2` section on `main` gains #238's entry in the assembler's own canonical position, `changelog.d/238.md` is consumed, and the published release body and the tag are left exactly as they are. The red at `5a8fce8` is accepted as permanent and bounded — that commit is immutable, so no pull request can ever re-grade it. **That chain of two has run, and it closed this epic.** #263 was claimed 2026-08-25T17:07:13Z, built at !264 and **merged 18:28:48Z as `0533766`**. Triage measured both post-merge facts against `main` at 18:31Z — the `0.6.2` section byte-identical to the assembler's own seven-fragment output (`diff` empty) and `changelog.d/238.md` absent — moved #263 by hand from `claimed` to `post-merge`, ticked its list and closed it at 18:34:09Z; that discharged #231's first criterion, which was ticked and closed at 18:36:14Z; and this epic closes on that act. **Nothing else on this board ever waited on any of it**: #231 was unassigned and carried no `attention` throughout, and #263 flagged nobody and collided with nothing (an open `post-merge` issue is not a #288 carrier, so the `CHANGELOG.md` overlap with #231 took no edge in either direction). **The one thing the campaign leaves permanently unequal, and it is the ruling's own choice rather than a loose end.** From `0533766` forward the tree's `0.6.2` section carries #238's entry and the published `0.6.2` release body does not. `changelog.d/263.md` states that divergence in the notes 0.6.3 will ship, so a consumer meets it without reading this board. The red at `5a8fce8` stays red forever, accepted and bounded to one immutable commit. **The seventh criterion of #231 was triage's own and is discharged.** The crew pin-bump follow-up is minted: **[heavy-duty/crew#122](https://forgejo.heavyduty.builders/heavy-duty/crew/issues/122)**, `ready` and unblocked, moving crew's **ten** `0.6.1` refs to `0.6.2` — nine `uses:` lines plus the `@0\.6\.1` literal buried in `.github/actionlint.yaml`'s ignore pattern, which a grep for `uses:` misses — and re-mirroring `.ceremony/` with `docs-sync --fix` in the same commit, because one pin governs machinery and doctrine. Measured before minting: exactly three mirrored files move under `0.6.2` (`BUILDER.md`, `RELEASES.md`, `TRIAGE.md`), and the three reusable workflows changed only their own `CEREMONY_SELF_REF` stamp between the tags, so no caller contract moves. **Two issues this epic's child was holding as a carrier were released from that hold, and neither has waited on it since**, both flipped by hand in the same tick because the sweep flips only on a *closed* blocker: **#241** (collision on `.github/workflows/labels.yml`; the stamp is on `main` and `post-merge` is not a claimable carrier under #288) went `ready` at 16:24:01Z, and **#251** (whose declared condition was !250's *merge*, not #231's close) went `ready` at 16:25:49Z. Both declarations were rewritten away in the same tick, and both issues' premises were re-measured against `main` first — #241's three `labels.yml` line references all still hold, and #251's five token counts in `drills/README.md` are unchanged. **What each has done with its freedom since is the board's to show, not this epic's, and no reading of it is kept here** — neither is a child of this epic, neither appears in its `## Task list`, and nothing either does flows back. (The clause that stood here reported #241's claim, and was one merge behind within eight hours; it is replaced by the rule it served rather than corrected a second time.) **The claim history, kept only because it explains the shape.** #231 was claimed twice. The first claim ran 2026-08-24T00:32:17Z → 12:32:23Z, parked on `changelog.d/246.md` until !248 landed it at 12:06:55Z, and was **released rather than resumed** — a clean exit, since an unpark is a claim like any other and takes the slot ([BUILDER.md](BUILDER.md#claiming)). It left no branch and no worktree; !245, its only PR, closed at 10:47:31Z with its staging commit preserved as `refs/pull/245/head` = `dcdf30dd5a1900be3605d868c69f4a18636934ce`. The second claim, 13:18:31Z → the merge, cut `build/231-release-0-6-2` fresh from `main` on a same-repo head and carried the work through. Four `attention` episodes opened and closed on #231 across that span, the last at 14:25:46Z; all four are spent, and no flag stands on either child. The gate that made the release child claimable is spent and stays spent: #229 landed 2026-08-22 as `4f887a7` (!233), #230 landed 2026-08-23 as `1f5dd39` (!239 merged 16:58:12Z), the sweep flipped #231 to `ready` at 17:00:57Z, and `release` returned in the same triage tick per the lead's stated return condition of 2026-08-17T23:33:02Z. **The label stands no window** — #343's membership record has no fallback to the gate and #231 enumerates no `## Members`, so it is not a window carrier and draws no window flag. Not a child of this epic, but it gated the release child: **#232** — the `test/labels.test.sh:249` roster fixture — landed 2026-08-23 as `f69224c` (!237 merged 00:52:05Z) and is closed. `test/labels.test.sh` is back to 44/44 on `main`. It was upstream-independent debt rather than an adoption child, tracked and closed on #232 itself; this epic did not close on it. ## Acceptance criteria - [x] Every child closed or explicitly deferred here with its reason. **All five are closed on verified criteria: #229, #230 and #246 on the day they landed; #263 at 2026-08-25T18:34:09Z on its two measured post-merge facts; and #231 at 18:36:14Z on all seven of its own, the last of which the option-B ruling re-aimed from a green that cannot arrive at `5a8fce8` to #263's edit being on `main`. The deferrals — upstream's drill-record bookkeeping fixes and the whole upstream `0.7.x` line — are recorded in the fourth criterion below and in the shipped `0.6.2` section itself.** - [x] Forge `0.6.2` released; `CHANGELOG.md` names the three upstream releases and the issues (#316 #311 #330 #329 #336 #343 #327 upstream numbering, marked as upstream's). **Verified 2026-08-24T16:31Z at `ca7ce6e`: released and published 16:10:40Z; the `## 0.6.2 — 2026-08-24` section names `upstream-0.6.1`, `upstream-0.6.2` and `upstream-0.6.3`, and all seven issue numbers appear exactly once each in the `upstream#N` form that keeps the two lines unconfusable.** - [x] `docs/UPSTREAM-SYNC.md` records this sync and **both** baselines — the new content baseline `upstream-0.6.3` and the unchanged ancestry baseline `8c3a4d1` — so the 0.7.x campaign starts from a written fact, not archaeology, and knows it is the campaign that would advance `.upstream-ref` if it merges rather than ports. **Verified: both baselines named separately, `.upstream-ref` byte-unchanged across `7bdae45..ca7ce6e` at `8c3a4d1dee2bdb5ac06a632a285bb65ab2615214`, and `CHANGELOG.md`'s provenance header carrying the port clause.** - [x] Explicitly deferred, recorded here: upstream's drill-record bookkeeping fixes (`86dc2eb`, `a72085b`, `13ffb0d`) — they correct upstream's own drill files, which this forge does not mirror; and the whole upstream `0.7.x` line. **Recorded twice over: in this criterion, and in the shipped `0.6.2` section — "Upstream's drill-record fixes and the upstream `0.7.0`–`0.7.4` line are deferred to the next sync campaign (#246)" — so a reader of the published changelog meets the deferral without opening this epic.** ## Dependencies None open on this board, and the parse over this body is empty. Successor to the forge `0.6.1` release (epic #197, closed 2026-08-09). The fleet-cutover epic (crew#1) is independent. **Downstream, and outside this epic's close condition:** [crew#122](https://forgejo.heavyduty.builders/heavy-duty/crew/issues/122) adopts `0.6.2` in crew. It is a consumer of this release, not a member of this campaign, and this epic does not wait on it — a cross-repo pin bump is the consumer's work on the consumer's board, and #231's criterion asked only that it be minted and linked, which it is.
claude-bot-andresmgsl added the
epic
release
 labels 2026-08-17 22:26:57 +00:00
claude-lead-andresmgsl commented 2026-08-17 23:03:34 +00:00
Member
Copy link

Identity note for the record: the lead now writes as claude-lead-andresmgsl (this account). All prior lead acts in this campaign — issue minting, dispatch comments, the roster hotfixes, the manual panel request on crew!44 — were signed cluade-bot-andresmgsl, which from here on belongs exclusively to the duty engine (andres-claude reviewer box + andres-agent-lead triage box). Operator-created split, 2026-08-17.

Identity note for the record: the **lead** now writes as `claude-lead-andresmgsl` (this account). All prior lead acts in this campaign — issue minting, dispatch comments, the roster hotfixes, the manual panel request on crew!44 — were signed `cluade-bot-andresmgsl`, which from here on belongs exclusively to the duty engine (andres-claude reviewer box + andres-agent-lead triage box). Operator-created split, 2026-08-17.
claude-bot-andresmgsl added the
enhancement
scope:release-flow
 labels 2026-08-17 23:34:15 +00:00
claude-bot-andresmgsl commented 2026-08-21 03:11:21 +00:00
Author
Member
Copy link

Board pass 2026-08-21T03:1xZ — one act, a body correction here.

What I changed: the Task list now records that the release child also
gates on #232, which is a 0.6.2 window member but not an adoption child.
Before this edit a scan of this epic said 0.6.2 waits on #229 and #230; it
actually waits on #229, #230 and #232 — #231's own gate has named
#232 since 2026-08-17T23:34 (echoed there as {#229, #230, #232}), and
#232 is today the board's only ready item. The epic was the one place that
did not say so.

Deliberately not written as a dependency declaration. This epic carries
release, and the reconciler stands a window from any open release issue
whose body parses a non-empty gate — the exact premature window the lead
stood down on #231 at 2026-08-17T23:33Z. So the note names the gate in prose
that the blocker parse does not read, and this epic's gate stays empty. It
returns when #231 goes ready, per that lead act.

Rest of the board, verified against label events and linked items rather
than prose:

  • #229 claimed @codex-bot-andresmgsl — !233 open, head 9f07c91, updated
    2026-08-20T23:29Z. Inside the 48h reclaim window with a live PR; no
    reclaim. The attention set here 2026-08-20T01:22Z was acked and removed
    at 01:31Z.
  • #230 blocked — parse {#229}, #229 open. Correct.
  • #231 blocked — parse {#229, #230, #232}, all three open. Correct; no
    release label, so no window stands.
  • #232 ready, unassigned, no open PR — correct for unclaimed work, and its
    remaining spec item is real: test/labels.test.sh:249 still reads
    glm-reviewer-andresmgsl on main at 27f702a, so the suite is still
    43/44. Not obsolete.
  • Queue invariant holds: every open issue is epic or carries exactly one of
    ready / claimed / blocked / post-merge. No needs-triage, no
    post-merge, no stray attention, no unresolved automation conflict
    comment.

Nothing else needed flipping, reclaiming, or closing.

Board pass 2026-08-21T03:1xZ — one act, a body correction here. **What I changed:** the Task list now records that the release child also gates on #232, which is a 0.6.2 window member but not an adoption child. Before this edit a scan of this epic said 0.6.2 waits on #229 and #230; it actually waits on #229, #230 and #232 — #231's own gate has named `#232` since 2026-08-17T23:34 (echoed there as `{#229, #230, #232}`), and #232 is today the board's only `ready` item. The epic was the one place that did not say so. **Deliberately not written as a dependency declaration.** This epic carries `release`, and the reconciler stands a window from any open `release` issue whose body parses a non-empty gate — the exact premature window the lead stood down on #231 at 2026-08-17T23:33Z. So the note names the gate in prose that the blocker parse does not read, and this epic's gate stays empty. It returns when #231 goes `ready`, per that lead act. **Rest of the board, verified against label events and linked items rather than prose:** - #229 `claimed` @codex-bot-andresmgsl — !233 open, head `9f07c91`, updated 2026-08-20T23:29Z. Inside the 48h reclaim window with a live PR; no reclaim. The `attention` set here 2026-08-20T01:22Z was acked and removed at 01:31Z. - #230 `blocked` — parse `{#229}`, #229 open. Correct. - #231 `blocked` — parse `{#229, #230, #232}`, all three open. Correct; no `release` label, so no window stands. - #232 `ready`, unassigned, no open PR — correct for unclaimed work, and its remaining spec item is real: `test/labels.test.sh:249` still reads `glm-reviewer-andresmgsl` on `main` at `27f702a`, so the suite is still 43/44. Not obsolete. - Queue invariant holds: every open issue is `epic` or carries exactly one of `ready` / `claimed` / `blocked` / `post-merge`. No `needs-triage`, no `post-merge`, no stray `attention`, no unresolved automation conflict comment. Nothing else needed flipping, reclaiming, or closing.
claude-bot-andresmgsl commented 2026-08-23 17:17:32 +00:00
Author
Member
Copy link

Task list brought current (triage, 2026-08-23) — phase 2 is done; phase 3 is the only one left. No label moved.

Label events re-read by hand immediately before this write: this epic carries epic, release, enhancement and scope:release-flow, set 2026-08-17 and untouched since. No queue label, correctly — builders never pick the epic itself.

#230 is ticked. The reconciler port — upstream-0.6.3's membership record, the carrier-gate fixes and the CommonMark row hardening — landed 2026-08-23 as 1f5dd39 (!239 merged 16:58:12Z by @andres) and is closed. That was the second and last of the two build children.

What that unlocked. #231's gate is now empty: the sweep flipped it to ready at 17:00:57Z, and its release label returned in the same triage tick on the lead's own recorded return condition of 2026-08-17T23:33:02Z. The label stands no window — #343's membership record has no fallback to the gate, and #231 enumerates no ## Members — which is exactly the false-window class the child that just landed was ported to close. Recorded on #231.

Also corrected here: the trailing #232 paragraph still read "#231's gate now names only #230", true until 16:58:12Z and not after. It now reads that the gate is empty. The paragraph is otherwise preserved verbatim as the record that #232 was tracked and closed on itself, not on this epic.

This epic stays open. Its first acceptance criterion — every child closed or explicitly deferred with its reason — is not met while #231 is open, and #231's own close is this epic's closing condition. Nothing here is claimable.

**Task list brought current (triage, 2026-08-23) — phase 2 is done; phase 3 is the only one left. No label moved.** Label events re-read by hand immediately before this write: this epic carries `epic`, `release`, `enhancement` and `scope:release-flow`, set 2026-08-17 and untouched since. No queue label, correctly — builders never pick the epic itself. **#230 is ticked.** The reconciler port — upstream-0.6.3's membership record, the carrier-gate fixes and the CommonMark row hardening — landed 2026-08-23 as `1f5dd39` (!239 merged 16:58:12Z by @andres) and is closed. That was the second and last of the two build children. **What that unlocked.** #231's gate is now empty: the sweep flipped it to `ready` at 17:00:57Z, and its `release` label returned in the same triage tick on the lead's own recorded return condition of 2026-08-17T23:33:02Z. The label stands no window — #343's membership record has no fallback to the gate, and #231 enumerates no `## Members` — which is exactly the false-window class the child that just landed was ported to close. Recorded on #231. **Also corrected here:** the trailing #232 paragraph still read *"#231's gate now names only #230"*, true until 16:58:12Z and not after. It now reads that the gate is empty. The paragraph is otherwise preserved verbatim as the record that #232 was tracked and closed on itself, not on this epic. **This epic stays open.** Its first acceptance criterion — every child closed or explicitly deferred with its reason — is not met while #231 is open, and #231's own close is this epic's closing condition. Nothing here is claimable.
claude-bot-andresmgsl commented 2026-08-24 01:25:59 +00:00
Author
Member
Copy link

📎 Epic corrected (triage, 2026-08-24) — spec item 3's "merge-base advanced" was never achievable under this epic's own adoption model, and #246 is added as the release child's preparatory issue. No label moved; this epic stays epic, release, enhancement, scope:release-flow.

What was wrong. Spec item 3 asked #231 to record "the new baseline (upstream-0.6.3, merge-base advanced)". This epic's Context decides the opposite in the same body: "Port the LOGIC onto the forge's Forgejo-adapted files — never overwrite them with upstream bytes." A port advances no ancestry, so git merge-base cannot move and .upstream-ref must stay at 8c3a4d1 — test/upstream-delta.test.sh refuses a recorded ref that is not an ancestor of HEAD, so writing upstream-0.6.3's SHA there would be false and red. @codex-bot-andresmgsl hit that contradiction as a hard block on !245 at 2026-08-24T00:38Z.

What it says now. Two baselines, named separately: the content baseline upstream-0.6.3, adopted by port through #229 and #230, and the ancestry baseline 8c3a4d1, unchanged. The third acceptance criterion carries the same split, and adds the note the 0.7.x campaign needs — that it is the campaign which advances .upstream-ref, if it merges rather than ports. #231's spec item 3 was rewritten in the same tick.

#246 is added to the task list — changelog.d/246.md, the upstream credits and deferral prose this epic's second acceptance criterion demands. It is not an adoption child: it exists because changelog-assembled replays the merge base's fragments byte-for-byte, so release prose cannot be typed into the assembled section and must land as a fragment on main first. That is #220's standing resolution from the 0.6.1 release, and the row says so.

Status. #231 is claimed by @codex-bot-andresmgsl since 2026-08-24T00:32:17Z with !245 open as a draft, its claim parked on #246. Nothing else in this epic moved: the adoption model, the deferrals, the two landed children and the release-window read are untouched.

📎 **Epic corrected (triage, 2026-08-24) — spec item 3's "merge-base advanced" was never achievable under this epic's own adoption model, and #246 is added as the release child's preparatory issue. No label moved; this epic stays `epic`, `release`, `enhancement`, `scope:release-flow`.** **What was wrong.** Spec item 3 asked #231 to record "the new baseline (`upstream-0.6.3`, merge-base advanced)". This epic's Context decides the opposite in the same body: *"Port the LOGIC onto the forge's Forgejo-adapted files — never overwrite them with upstream bytes."* A port advances no ancestry, so `git merge-base` cannot move and `.upstream-ref` must stay at `8c3a4d1` — `test/upstream-delta.test.sh` refuses a recorded ref that is not an ancestor of `HEAD`, so writing upstream-0.6.3's SHA there would be false and red. @codex-bot-andresmgsl hit that contradiction as a hard block on !245 at 2026-08-24T00:38Z. **What it says now.** Two baselines, named separately: the **content** baseline `upstream-0.6.3`, adopted by port through #229 and #230, and the **ancestry** baseline `8c3a4d1`, unchanged. The third acceptance criterion carries the same split, and adds the note the 0.7.x campaign needs — that it is the campaign which advances `.upstream-ref`, if it merges rather than ports. #231's spec item 3 was rewritten in the same tick. **#246 is added to the task list** — `changelog.d/246.md`, the upstream credits and deferral prose this epic's second acceptance criterion demands. It is not an adoption child: it exists because `changelog-assembled` replays the merge base's fragments byte-for-byte, so release prose cannot be typed into the assembled section and must land as a fragment on `main` first. That is #220's standing resolution from the 0.6.1 release, and the row says so. **Status.** #231 is `claimed` by @codex-bot-andresmgsl since 2026-08-24T00:32:17Z with !245 open as a draft, its claim parked on #246. Nothing else in this epic moved: the adoption model, the deferrals, the two landed children and the release-window read are untouched.
claude-bot-andresmgsl commented 2026-08-24 11:17:26 +00:00
Author
Member
Copy link

🔧 Body correction (triage, 2026-08-24T11:18Z) — the Task list's phase-3 paragraph described !245 as an open draft and named it as the merge base. !245 has been closed since 2026-08-24T10:47:31Z. No label moves; the checklist itself is unchanged, both remaining boxes still open.

What the paragraph now says, all of it re-read rather than carried forward:

  • #231 is still claimed, still @codex-bot-andresmgsl's, still parked on #246 — but the park now stands with no open PR. !245 carried the release stamps as a draft and its author closed it on the lead's close-or-carry demand of 10:33:16Z: a draft PR holds ceremony's single build slot, and that slot was what stopped anyone — the assignee included — from claiming #246, the fragment the park waits on.
  • The merge base named here is a future main, not !245's. That was the stale phrase most likely to mislead a scan: it implied the fragment had to become reachable from a branch that no longer exists. The release PR is re-cut from a main that already carries changelog.d/246.md.
  • The staging commit survives; the branch does not. The close deleted build/231-release-0-6-2 from the remote (git ls-remote, 2026-08-24T11:14Z); dcdf30d is held by refs/pull/245/head. #231's header carries the recovery command — this epic just records the fact so a scan of the campaign does not go looking for a branch.
  • Phase 3 is in flight as #246, not as #231: #246 went claimed at 10:50:52Z with !248 open, non-draft, against main.

Label events for both children were paged by hand immediately before this write, not read off the thread: no attention stands on either (#231's second episode opened 10:33:16Z and closed 10:45:44Z), and no queue label has moved since 10:50:52Z.

The epic's acceptance criteria are untouched and none is newly satisfiable — #231 is what closes them, and it has not run its ceremony yet.

🔧 **Body correction (triage, 2026-08-24T11:18Z) — the Task list's phase-3 paragraph described !245 as an open draft and named it as the merge base. !245 has been closed since 2026-08-24T10:47:31Z.** No label moves; the checklist itself is unchanged, both remaining boxes still open. What the paragraph now says, all of it re-read rather than carried forward: - **#231 is still `claimed`, still @codex-bot-andresmgsl's, still parked on #246** — but the park now stands with **no open PR**. !245 carried the release stamps as a draft and its author closed it on the lead's close-or-carry demand of 10:33:16Z: a draft PR holds ceremony's single build slot, and that slot was what stopped anyone — the assignee included — from claiming #246, the fragment the park waits on. - **The merge base named here is a future `main`, not !245's.** That was the stale phrase most likely to mislead a scan: it implied the fragment had to become reachable from a branch that no longer exists. The release PR is re-cut from a `main` that already carries `changelog.d/246.md`. - **The staging commit survives; the branch does not.** The close deleted `build/231-release-0-6-2` from the remote (`git ls-remote`, 2026-08-24T11:14Z); `dcdf30d` is held by `refs/pull/245/head`. #231's header carries the recovery command — this epic just records the fact so a scan of the campaign does not go looking for a branch. - **Phase 3 is in flight as #246**, not as #231: #246 went `claimed` at 10:50:52Z with !248 open, non-draft, against `main`. Label events for both children were paged by hand immediately before this write, not read off the thread: no `attention` stands on either (#231's second episode opened 10:33:16Z and closed 10:45:44Z), and no queue label has moved since 10:50:52Z. The epic's acceptance criteria are untouched and none is newly satisfiable — #231 is what closes them, and it has not run its ceremony yet.
claude-bot-andresmgsl commented 2026-08-24 12:40:04 +00:00
Author
Member
Copy link

🔧 Epic body corrected — phase 3's last child returned to the queue. @codex-bot-andresmgsl acked the unpark attention on #231 at 2026-08-24T12:30:56Z and then released the claim rather than retaking the slot: claimed → ready, self-unassigned at 12:32:23–24Z, taking #238 at 12:35:08Z instead. That is a clean exit — an unpark is a claim like any other and takes the slot (BUILDER.md) — and it leaves nothing behind: no branch, no worktree, no open PR (git ls-remote and the open-PR list, both read 2026-08-24T12:36Z).

So #231 is ready, unassigned and claimable by any builder from current main (7bdae45), which already carries changelog.d/246.md. Two sentences in this body said otherwise — that #231 sat claimed under a live attention — and are rewritten in place rather than negated, together with the "assignee's fork" phrasing for !245's head, which no longer has an assignee to refer to. The corresponding correction is on #231, with the resume checklist for whoever claims it.

The Task list is unchanged: #246 stays ticked, #231 stays open, and this epic's closing condition is still #231's close. No label moved on either issue and no attention is set — flagging an unassigned issue would be a board bug, not a demand.

🔧 **Epic body corrected — phase 3's last child returned to the queue.** @codex-bot-andresmgsl acked the unpark `attention` on #231 at 2026-08-24T12:30:56Z and then **released the claim rather than retaking the slot**: `claimed` → `ready`, self-unassigned at 12:32:23–24Z, taking #238 at 12:35:08Z instead. That is a clean exit — an unpark is a claim like any other and takes the slot ([BUILDER.md](BUILDER.md#claiming)) — and it leaves nothing behind: no branch, no worktree, no open PR (`git ls-remote` and the open-PR list, both read 2026-08-24T12:36Z). So **#231 is `ready`, unassigned and claimable by any builder from current `main` (`7bdae45`)**, which already carries `changelog.d/246.md`. Two sentences in this body said otherwise — that #231 sat claimed under a live `attention` — and are rewritten in place rather than negated, together with the "assignee's fork" phrasing for !245's head, which no longer has an assignee to refer to. The corresponding correction is on #231, with the resume checklist for whoever claims it. The Task list is unchanged: #246 stays ticked, #231 stays open, and this epic's closing condition is still #231's close. No label moved on either issue and no `attention` is set — flagging an unassigned issue would be a board bug, not a demand.
claude-bot-andresmgsl commented 2026-08-24 13:57:31 +00:00
Author
Member
Copy link

🔧 Epic body corrected (triage, 2026-08-24T13:57Z) — the task-list prose said this epic's last child was claimable, and it is being built.

Label events paged by hand immediately before this write, not read off the thread. Two sentences under ## Task list were falsified between the 12:36Z measurement they carried and now:

  • "this epic's last child is ready, unassigned and claimable by any builder" — @codex-bot-andresmgsl re-claimed #231 at 2026-08-24T13:18:30–31Z (ready off, claimed on, self-assign at 13:18:31Z), posted its plan of record at 13:19:33Z, and opened !250 (build/231-release-0-6-2, head on heavy-duty/ceremony) at 13:39:39Z. Triage set attention on #231 at 13:26:00Z carrying a three-point contract amendment, and that flag stands unacked as of this read.
  • "the lane will not pick this child up until !249 lands (crew#118)" — wrong on the mechanism, and #231's own header already carried the correction. crew#118's slot classifier calls a draft PR active and a non-draft, mergeable PR whose panel round is pending parked. !249 reads draft: false, mergeable: true with its round running, which is how this claim was taken while it was open.

The later sentence asserting "no attention stands on either child, and none is owed on #231 while it is unassigned" is corrected in the same pass: a fourth attention episode opened 13:26:00Z and is still open.

No checkbox moved and no label moved. - [ ] #231 is still unticked, correctly — the child is open. This epic's wake is !250's merge, not a claim. Both corrections are written as corrections rather than negated in place, and the park history that explains the shape is kept.

🔧 **Epic body corrected (triage, 2026-08-24T13:57Z) — the task-list prose said this epic's last child was claimable, and it is being built.** Label events paged by hand immediately before this write, not read off the thread. Two sentences under `## Task list` were falsified between the 12:36Z measurement they carried and now: - *"this epic's last child is `ready`, unassigned and claimable by any builder"* — @codex-bot-andresmgsl **re-claimed #231 at 2026-08-24T13:18:30–31Z** (`ready` off, `claimed` on, self-assign at 13:18:31Z), posted its plan of record at 13:19:33Z, and opened **!250** (`build/231-release-0-6-2`, head on `heavy-duty/ceremony`) at 13:39:39Z. Triage set `attention` on #231 at 13:26:00Z carrying a three-point contract amendment, and that flag **stands unacked** as of this read. - *"the lane will not pick this child up until !249 lands (crew#118)"* — wrong on the mechanism, and #231's own header already carried the correction. crew#118's slot classifier calls a **draft** PR active and a **non-draft, mergeable PR whose panel round is pending** *parked*. !249 reads `draft: false`, `mergeable: true` with its round running, which is how this claim was taken while it was open. The later sentence asserting *"no `attention` stands on either child, and none is owed on #231 while it is unassigned"* is corrected in the same pass: a fourth `attention` episode opened 13:26:00Z and is still open. **No checkbox moved and no label moved.** `- [ ] #231` is still unticked, correctly — the child is open. This epic's wake is !250's merge, not a claim. Both corrections are written as corrections rather than negated in place, and the park history that explains the shape is kept.
claude-bot-andresmgsl commented 2026-08-24 14:43:07 +00:00
Author
Member
Copy link

🔧 Epic body corrected (triage, 2026-08-24T14:45Z) — the ## Task list prose, in three places. No checkbox moved, no child's label moved, nothing claimed or re-flagged. Phase 3 is still the only phase left and #231 is still the whole of it.

Label events for both open items paged by hand immediately before this write, not read off the thread.

1. The !250 status paragraph was twelve minutes old and every fact in it had moved. It said: draft at head fdb7d75, blocker:ci-red since 14:17:46Z, and drills/0.6.2.md not yet written, with the builder still measuring the doors-unchanged conditions. All three are spent. The drill record was written — drills/0.6.2.md is added in !250's diff — and blocker:ci-red came off at 14:41:15Z. The PR is out of draft at head 809b7e9 on base 7bdae45, and its builder posted round answered at head 809b7e9 at 14:35:33Z. state:addressing still stands from the 14:17:46Z red; that is the panel round's to clear, not this epic's. This epic's wake is unchanged: !250's merge.

2. An internal contradiction, now closed. The paragraph block at the top said the fourth attention episode on #231 was answered at 14:25:46Z; a later sentence still said it "is still open". The later one is corrected: the fourth episode ran 13:26:00Z → 14:25:46Z, and no attention stands on either child as of this read.

3. The !249 sentence has been rewritten as history rather than a live reading. It asserted in the present tense that !249 is draft: false and mergeable: true. That was true when #231 was re-claimed — which is the point the sentence exists to make, since crew#118's slot classifier calls a non-draft, mergeable PR with a pending round parked — but !249 has since flipped back to draft: true under state:addressing, a fix round. The flag has now moved twice in one day, so the passage records the moment the claim was taken and says out loud that no value of it reaches this epic. The same volatile reading was de-volatilized on #240 in this tick, for the same reason.

Unchanged and re-verified: #229, #230 and #246 stay ticked and closed on verified criteria; #231 stays claimed by @codex-bot-andresmgsl (13:18:30–31Z) and unticked; the acceptance criteria and ## Dependencies are untouched.

🔧 **Epic body corrected (triage, 2026-08-24T14:45Z) — the `## Task list` prose, in three places. No checkbox moved, no child's label moved, nothing claimed or re-flagged.** Phase 3 is still the only phase left and #231 is still the whole of it. Label events for both open items paged by hand immediately before this write, not read off the thread. **1. The !250 status paragraph was twelve minutes old and every fact in it had moved.** It said: draft at head `fdb7d75`, `blocker:ci-red` since 14:17:46Z, and `drills/0.6.2.md` not yet written, with the builder still measuring the doors-unchanged conditions. All three are spent. **The drill record was written** — `drills/0.6.2.md` is `added` in !250's diff — and `blocker:ci-red` came off at **14:41:15Z**. The PR is **out of draft** at head `809b7e9` on base `7bdae45`, and its builder posted `round answered at head 809b7e9` at 14:35:33Z. `state:addressing` still stands from the 14:17:46Z red; that is the panel round's to clear, not this epic's. **This epic's wake is unchanged: !250's merge.** **2. An internal contradiction, now closed.** The paragraph block at the top said the fourth `attention` episode on #231 was answered at 14:25:46Z; a later sentence still said it "is still open". The later one is corrected: the fourth episode ran **13:26:00Z → 14:25:46Z**, and **no `attention` stands on either child** as of this read. **3. The !249 sentence has been rewritten as history rather than a live reading.** It asserted in the present tense that !249 is `draft: false` and `mergeable: true`. That was true when #231 was re-claimed — which is the point the sentence exists to make, since crew#118's slot classifier calls a non-draft, mergeable PR with a pending round *parked* — but !249 has since flipped back to `draft: true` under `state:addressing`, a fix round. The flag has now moved twice in one day, so the passage records the moment the claim was taken and says out loud that no value of it reaches this epic. The same volatile reading was de-volatilized on #240 in this tick, for the same reason. Unchanged and re-verified: #229, #230 and #246 stay ticked and closed on verified criteria; #231 stays `claimed` by @codex-bot-andresmgsl (13:18:30–31Z) and unticked; the acceptance criteria and `## Dependencies` are untouched.
claude-bot-andresmgsl commented 2026-08-24 16:33:00 +00:00
Author
Member
Copy link

📊 Epic swept (triage, 2026-08-24T16:31Z) — the wake fired: 0.6.2 is cut, tagged and published. The Task-list prose is rewritten to match, and three of four epic acceptance criteria are ticked. No label moves; the epic stays open on its last child.

Label events paged by hand at 16:31Z, not read off the thread: epic + release at the 2026-08-17T22:26:57Z mint, enhancement + scope:release-flow at 23:34:15Z, and nothing since. Unassigned, no attention. Builders never pick the epic itself.

The release landed

!250 merged 2026-08-24T15:55:13Z as 5a8fce8; the sweep moved #231 to post-merge and released the claim at 15:58:08–09Z. The release door then ran itself through with no second PR: tag 0.6.2 at 5a8fce8, release published 16:10:40Z (not a draft, not a prerelease), main re-armed to 0.6.3-dev as ca7ce6e at 16:10:57Z by release.yml's own step.

Everything this epic's Task-list block previously said is spent. It described a build in flight as of 14:44Z — a draft flag, a pending panel round, state:addressing, a drill record not yet written. Rather than annotate a fifth correction onto a paragraph that has been corrected four times in one day, the whole block is replaced with the outcome. A stale epic misleads every scan, and this one had become mostly a changelog of its own corrections.

Criteria

criterion verdict
Every child closed or deferred with its reason open — #229, #230, #246 closed on verified criteria; #231 post-merge and open on one
0.6.2 released; CHANGELOG names the three upstream releases and seven issues ✅ all seven upstream#N present exactly once each, in the form that keeps the two lines unconfusable
UPSTREAM-SYNC records both baselines ✅ content upstream-0.6.3 and ancestry 8c3a4d1…5214 named separately; .upstream-ref byte-unchanged across 7bdae45..ca7ce6e
Deferrals recorded ✅ recorded here and in the shipped section, so a reader of the published changelog meets them without opening this epic

Why #231's box stays unticked

Six of its seven criteria are verified and ticked. The seventh — "tag exists; release published; guards green" — has two legs verified and one that fails: CI / self-guards is RED at the tagged commit 5a8fce8. changelog.d/238.md landed on main at 15:54 with !249, after !250's merge base 7bdae45, so the assembler never consumed it and changelog-armed refuses the released tree. Green again at ca7ce6e; the red is one commit wide and it is the tagged one.

The consequence is not cosmetic: 0.6.2 contains #238's code and its published section does not credit it. Disposition of a published release's notes is the operator's, so it is escalated on #231 with needs-ruling set at 16:27Z — three options, recommendation B, hard block, 24h rung 2026-08-25T16:27Z. This epic's close waits on that and on nothing else.

The 0.6.1 ceremony is the control that makes this a first occurrence rather than the shape of a release commit: changelog.d/ was empty at that tag and its changelog-armed is green.

What this epic released downstream, in the same tick

  • crew#122 minted ready — #231's seventh criterion, triage's own, discharged. Ten refs from 0.6.1 to 0.6.2, not nine: the tenth is the @0\.6\.1 literal in .github/actionlint.yaml's ignore pattern, which a grep for uses: misses and whose omission turns all six release-guards.yml refs into lint errors. The .ceremony/ mirror moves in the same commit because one pin governs machinery and doctrine.
  • #241 → ready at 16:24:01Z. Its collision edge was on .github/workflows/labels.yml; the stamp is on main and post-merge is not a claimable carrier under #288. Flipped by hand — the sweep flips only on a closed blocker.
  • #251 → ready at 16:25:49Z. Its declared condition was !250's merge, not #231's close, exactly as its declaration said at mint.

Both flips re-measured the successor's premises against main before writing, because a blocker's merge can invalidate a successor's criteria: #241's three labels.yml line references all still hold, and #251's five token counts in drills/README.md are unchanged.

This epic is otherwise complete. Phase 1 (#229) and phase 2 (#230) closed on verified criteria; the preparatory fragment (#246) closed at 12:13Z. Nothing here waits on crew#122 — a consumer's pin bump is the consumer's work, and #231's criterion asked only that it be minted and linked.

📊 **Epic swept (triage, 2026-08-24T16:31Z) — the wake fired: `0.6.2` is cut, tagged and published. The Task-list prose is rewritten to match, and three of four epic acceptance criteria are ticked. No label moves; the epic stays open on its last child.** **Label events paged by hand at 16:31Z, not read off the thread**: `epic` + `release` at the 2026-08-17T22:26:57Z mint, `enhancement` + `scope:release-flow` at 23:34:15Z, and **nothing since**. Unassigned, no `attention`. Builders never pick the epic itself. ## The release landed !250 merged **2026-08-24T15:55:13Z** as `5a8fce8`; the sweep moved #231 to `post-merge` and released the claim at 15:58:08–09Z. The release door then ran itself through with no second PR: tag `0.6.2` at `5a8fce8`, release published **16:10:40Z** (not a draft, not a prerelease), `main` re-armed to `0.6.3-dev` as `ca7ce6e` at 16:10:57Z by `release.yml`'s own step. **Everything this epic's Task-list block previously said is spent.** It described a build in flight as of 14:44Z — a draft flag, a pending panel round, `state:addressing`, a drill record not yet written. Rather than annotate a fifth correction onto a paragraph that has been corrected four times in one day, the whole block is replaced with the outcome. A stale epic misleads every scan, and this one had become mostly a changelog of its own corrections. ## Criteria | criterion | verdict | |---|---| | Every child closed or deferred with its reason | **open** — #229, #230, #246 closed on verified criteria; #231 `post-merge` and open on one | | `0.6.2` released; CHANGELOG names the three upstream releases and seven issues | ✅ all seven `upstream#N` present exactly once each, in the form that keeps the two lines unconfusable | | UPSTREAM-SYNC records both baselines | ✅ content `upstream-0.6.3` and ancestry `8c3a4d1…5214` named separately; `.upstream-ref` byte-unchanged across `7bdae45..ca7ce6e` | | Deferrals recorded | ✅ recorded here **and** in the shipped section, so a reader of the published changelog meets them without opening this epic | ## Why #231's box stays unticked Six of its seven criteria are verified and ticked. The seventh — *"tag exists; release published; guards green"* — has two legs verified and one that fails: **`CI / self-guards` is RED at the tagged commit `5a8fce8`.** `changelog.d/238.md` landed on `main` at 15:54 with !249, **after** !250's merge base `7bdae45`, so the assembler never consumed it and `changelog-armed` refuses the released tree. Green again at `ca7ce6e`; the red is one commit wide and it is the tagged one. The consequence is not cosmetic: **`0.6.2` contains #238's code and its published section does not credit it.** Disposition of a published release's notes is the operator's, so it is escalated on #231 with `needs-ruling` set at 16:27Z — three options, recommendation B, hard block, 24h rung 2026-08-25T16:27Z. This epic's close waits on that and on nothing else. The 0.6.1 ceremony is the control that makes this a first occurrence rather than the shape of a release commit: `changelog.d/` was empty at that tag and its `changelog-armed` is green. ## What this epic released downstream, in the same tick - **crew#122** minted `ready` — #231's seventh criterion, triage's own, discharged. Ten refs from `0.6.1` to `0.6.2`, not nine: the tenth is the `@0\.6\.1` literal in `.github/actionlint.yaml`'s ignore pattern, which a grep for `uses:` misses and whose omission turns all six `release-guards.yml` refs into lint errors. The `.ceremony/` mirror moves in the same commit because one pin governs machinery and doctrine. - **#241 → `ready`** at 16:24:01Z. Its collision edge was on `.github/workflows/labels.yml`; the stamp is on `main` and `post-merge` is not a claimable carrier under #288. Flipped by hand — the sweep flips only on a *closed* blocker. - **#251 → `ready`** at 16:25:49Z. Its declared condition was !250's **merge**, not #231's close, exactly as its declaration said at mint. Both flips re-measured the successor's premises against `main` before writing, because a blocker's merge can invalidate a successor's criteria: #241's three `labels.yml` line references all still hold, and #251's five token counts in `drills/README.md` are unchanged. **This epic is otherwise complete.** Phase 1 (#229) and phase 2 (#230) closed on verified criteria; the preparatory fragment (#246) closed at 12:13Z. Nothing here waits on crew#122 — a consumer's pin bump is the consumer's work, and #231's criterion asked only that it be minted and linked.
claude-bot-andresmgsl commented 2026-08-25 00:19:45 +00:00
Author
Member
Copy link

🧹 Body corrected (triage, 2026-08-25T00:20Z) — one paragraph in the Task-list block, and the correction is a form change rather than a fact change. No label moves, no checkbox moves, and no acceptance criterion is touched.

Label events paged by hand immediately before this write, for this epic and for the issue the paragraph names, not read off .labels: #241 went ready off 2026-08-24T23:53:05Z / claimed on 23:53:06Z, assignee @codex-bot-andresmgsl, and attention on 2026-08-25T00:13:03Z (triage, an amended-criteria read, not rework). This epic itself is unchanged since the mint: epic, enhancement, release, scope:release-flow, unassigned, no flag.

What was stale. The paragraph opened "Two issues this epic's child was holding as a carrier are now claimable" — written 16:2xZ when both had just been flipped by hand. #241 was claimed seven and a half hours later, so a present-tense "claimable" now invites a builder to pick an issue somebody else is building. The header is rewritten to the durable fact — both were released from that hold, and neither has waited on it since — and one sentence records that #241 was claimed and entered build, dated, so it cannot go stale in turn. Everything else in the paragraph was already historical and stands: both flips, both timestamps, and both re-measurements against main.

Why the form and not just the date. This is the same correction I have now made twice on #231, whose escalation carried a dated roster of the board that went stale within hours of each writing (recorded there at 00:18Z, with the roster replaced by its invariant). An epic that enumerates who holds what this hour is a scan that lies between ticks; an epic that records what it caused does not. #241's live queue state belongs on #241.

Nothing here moves this epic's position. Its last open criterion is still #231's first — "tag exists; release published; guards green" — which is with @andres under needs-ruling on #231, anchored 2026-08-24T16:27:54Z, 12h rung 2026-08-25T04:27Z, 24h rung 2026-08-25T16:27Z. #229, #230 and #246 stay ticked and closed.

🧹 **Body corrected (triage, 2026-08-25T00:20Z) — one paragraph in the Task-list block, and the correction is a form change rather than a fact change. No label moves, no checkbox moves, and no acceptance criterion is touched.** **Label events paged by hand immediately before this write**, for this epic and for the issue the paragraph names, not read off `.labels`: **#241** went `ready` off **2026-08-24T23:53:05Z** / `claimed` on **23:53:06Z**, assignee @codex-bot-andresmgsl, and `attention` on **2026-08-25T00:13:03Z** (triage, an amended-criteria read, not rework). This epic itself is unchanged since the mint: `epic`, `enhancement`, `release`, `scope:release-flow`, unassigned, no flag. **What was stale.** The paragraph opened *"Two issues this epic's child was holding as a carrier **are now claimable**"* — written 16:2xZ when both had just been flipped by hand. #241 was claimed seven and a half hours later, so a present-tense "claimable" now invites a builder to pick an issue somebody else is building. The header is rewritten to the durable fact — both were *released from that hold, and neither has waited on it since* — and one sentence records that #241 was claimed and entered build, dated, so it cannot go stale in turn. Everything else in the paragraph was already historical and stands: both flips, both timestamps, and both re-measurements against `main`. **Why the form and not just the date.** This is the same correction I have now made twice on #231, whose escalation carried a dated roster of the board that went stale within hours of each writing (recorded there at 00:18Z, with the roster replaced by its invariant). An epic that enumerates who holds what this hour is a scan that lies between ticks; an epic that records what it *caused* does not. #241's live queue state belongs on #241. **Nothing here moves this epic's position.** Its last open criterion is still #231's first — *"tag exists; release published; guards green"* — which is with @andres under `needs-ruling` on #231, anchored 2026-08-24T16:27:54Z, 12h rung 2026-08-25T04:27Z, 24h rung 2026-08-25T16:27Z. #229, #230 and #246 stay ticked and closed.
claude-bot-andresmgsl commented 2026-08-25 06:57:50 +00:00
Author
Member
Copy link

🧹 Body corrected (triage, 2026-08-25T06:57Z) — one clause, in the paragraph about the two issues #231 was holding as a carrier. No checkbox moved, no label moved, and this epic's state is unchanged.

The clause read "#241 was claimed at 2026-08-24T23:53:06Z by @codex-bot-andresmgsl and entered build". #241 merged and closed at 2026-08-25T06:38:19Z (!256 as 6dc8bf6, Closes #241, merged by @andres), so a scan of this epic would have read a finished issue as still in flight.

It is deleted rather than updated. The sentence it hung off already says the right thing — what #241 and #251 do with their freedom is the board's to show, not this epic's — and then contradicted itself by keeping a reading that decays. It now states only the rule: neither issue is a child here, neither is in the ## Task list, and nothing either does flows back. That clause had been corrected once already at 2026-08-25T00:20Z and was one merge behind eight hours later; a second correction would have bought the same decay again.

Nothing else about this epic moved. Its one open criterion is still #231's seventh — "tag exists; release published; guards green" — and the needs-ruling escalation on #231 is unchanged: options A/B/C, Recommend: B, Default: none — hard block, anchor 2026-08-24T16:27:54Z. The 12h rung fired 04:43:15Z and the setter's re-read at 04:46:03Z left all three unchanged; the 24h rung is 2026-08-25T16:27Z, past which triage picks and records B and stays accountable for it. Nothing on this board waits on that: main is green, no pull request is open, and #243, #251 and #247 are all ready and independently claimable.

🧹 **Body corrected (triage, 2026-08-25T06:57Z) — one clause, in the paragraph about the two issues #231 was holding as a carrier. No checkbox moved, no label moved, and this epic's state is unchanged.** The clause read *"#241 was claimed at 2026-08-24T23:53:06Z by @codex-bot-andresmgsl and entered build"*. **#241 merged and closed at 2026-08-25T06:38:19Z** (!256 as `6dc8bf6`, `Closes #241`, merged by @andres), so a scan of this epic would have read a finished issue as still in flight. It is **deleted rather than updated**. The sentence it hung off already says the right thing — what #241 and #251 do with their freedom is the board's to show, not this epic's — and then contradicted itself by keeping a reading that decays. It now states only the rule: neither issue is a child here, neither is in the `## Task list`, and nothing either does flows back. That clause had been corrected once already at 2026-08-25T00:20Z and was one merge behind eight hours later; a second correction would have bought the same decay again. **Nothing else about this epic moved.** Its one open criterion is still #231's seventh — *"tag exists; release published; guards green"* — and the `needs-ruling` escalation on #231 is unchanged: options A/B/C, `Recommend: B`, `Default: none — hard block`, anchor 2026-08-24T16:27:54Z. The 12h rung fired 04:43:15Z and the setter's re-read at 04:46:03Z left all three unchanged; **the 24h rung is 2026-08-25T16:27Z**, past which triage picks and records B and stays accountable for it. Nothing on this board waits on that: `main` is green, no pull request is open, and #243, #251 and #247 are all `ready` and independently claimable.
claude-bot-andresmgsl commented 2026-08-25 09:11:31 +00:00
Author
Member
Copy link

🧹 Body corrected (triage, 2026-08-25T09:10Z) — one sentence, in the block about the tagged commit's red guard. No checkbox moves, no label moves, and this epic's state is unchanged. Nothing here asks anything of anyone.

The sentence read "the first measured green self-guards after the tag is 46458ba (2026-08-24T18:53:47Z) and current main e55e996 is green too". main has moved twice since — 6dc8bf6 (!256, #241, 2026-08-25T06:38:19Z) and f6f2ec7 (!260, #251, 08:57:40Z) — so the head named there is no longer current.

It is replaced by the invariant it was serving rather than re-dated: 46458ba is the first measured green after the tag, and every graded main commit from there forward is green on self-guards, the ungraded re-arm ca7ce6e being the only gap in the chain. That sentence had already been corrected once, at 04:45Z, when ca7ce6e turned out to carry no ci.yml run at all; re-dating it a second time would only buy the next reader another expiry. The bound it carries — the red is bounded to the tagged commit — holds on the measured chain, so the epic's remaining criterion does not move.

#231's body carries the same correction in the same tick, with the measured per-commit table. Its escalation is untouched: options A/B/C stand, Recommend: B stands, Default: none — hard block stands, and the 24h rung is 2026-08-25T16:27Z. changelog.d/238.md is still present and unconsumed on main at f6f2ec7 and CI / self-guards is still failure at 5a8fce8, re-measured 09:08Z — so nothing about this epic's last open criterion has changed.

This epic's ## Task list is current: #229, #230 and #246 are ticked and closed; #231 is unticked and post-merge, open on that one criterion. Label events for this epic re-read by hand immediately before this write — it carries enhancement, epic, release, scope:release-flow, is unassigned, and nothing has moved on it.

🧹 **Body corrected (triage, 2026-08-25T09:10Z) — one sentence, in the block about the tagged commit's red guard. No checkbox moves, no label moves, and this epic's state is unchanged. Nothing here asks anything of anyone.** The sentence read *"the first measured green `self-guards` after the tag is `46458ba` (2026-08-24T18:53:47Z) and current `main` `e55e996` is green too"*. `main` has moved twice since — `6dc8bf6` (!256, #241, 2026-08-25T06:38:19Z) and `f6f2ec7` (!260, #251, 08:57:40Z) — so the head named there is no longer current. It is **replaced by the invariant it was serving** rather than re-dated: `46458ba` is the first measured green after the tag, and **every graded `main` commit from there forward is green on `self-guards`**, the ungraded re-arm `ca7ce6e` being the only gap in the chain. That sentence had already been corrected once, at 04:45Z, when `ca7ce6e` turned out to carry no `ci.yml` run at all; re-dating it a second time would only buy the next reader another expiry. The bound it carries — the red is bounded to the tagged commit — holds on the measured chain, so **the epic's remaining criterion does not move**. #231's body carries the same correction in the same tick, with the measured per-commit table. Its escalation is untouched: options A/B/C stand, `Recommend: B` stands, `Default: none — hard block` stands, and the **24h rung is 2026-08-25T16:27Z**. `changelog.d/238.md` is still present and unconsumed on `main` at `f6f2ec7` and `CI / self-guards` is still `failure` at `5a8fce8`, re-measured 09:08Z — so nothing about this epic's last open criterion has changed. This epic's `## Task list` is current: #229, #230 and #246 are ticked and closed; #231 is unticked and `post-merge`, open on that one criterion. Label events for this epic re-read by hand immediately before this write — it carries `enhancement`, `epic`, `release`, `scope:release-flow`, is unassigned, and nothing has moved on it.
claude-bot-andresmgsl commented 2026-08-25 17:05:16 +00:00
Author
Member
Copy link

🧭 Epic updated in the same tick as the ruling on #231 — one new child row, and the escalation prose replaced by its outcome.

The needs-ruling episode this epic described is over. Triage picked option B at the 24h rung (2026-08-25T17:01Z, on #231) after the operator answered nothing — no comment and no label event from @andres anywhere in #231's timeline — removed the flag in that same comment, and minted the work as #263.

What changed in this body, so a reader does not have to diff it:

  • ## Task list gains #263, unticked: the ruled option-B correction of the shipped 0.6.2 section. Remedial rather than an adoption child, listed for the same reason #246 is — this epic cannot close without it.
  • The escalation paragraph is replaced, not annotated. It described a live flag with a pending 24h rung; both are spent. It now records the pick, the reason the red at 5a8fce8 is accepted as permanent (that commit is immutable, so no pull request can re-grade it), and the fact that the published body and the tag are untouched.
  • The first acceptance criterion is re-stated as the two-step wake it now is: #263 merges → triage ticks and closes #231 → this epic closes on that act. It is still this epic's only outstanding criterion.

Nothing else on this board moved and nothing waits on a builder here. #231 stays post-merge, unassigned, unflagged and unclaimable; #263 is ready, unblocked and claimable now, and it collides with nothing — a post-merge issue is not a #288 carrier state, so the CHANGELOG.md overlap between #263 and #231 correctly takes no edge in either direction.

🧭 **Epic updated in the same tick as the ruling on #231 — one new child row, and the escalation prose replaced by its outcome.** The `needs-ruling` episode this epic described is over. Triage picked **option B** at the 24h rung (2026-08-25T17:01Z, on #231) after the operator answered nothing — no comment and no label event from `@andres` anywhere in #231's timeline — removed the flag in that same comment, and minted the work as **#263**. What changed in this body, so a reader does not have to diff it: - **`## Task list` gains `#263`**, unticked: the ruled option-B correction of the shipped `0.6.2` section. Remedial rather than an adoption child, listed for the same reason #246 is — this epic cannot close without it. - **The escalation paragraph is replaced, not annotated.** It described a live flag with a pending 24h rung; both are spent. It now records the pick, the reason the red at `5a8fce8` is accepted as permanent (that commit is immutable, so no pull request can re-grade it), and the fact that the published body and the tag are untouched. - **The first acceptance criterion is re-stated as the two-step wake it now is**: #263 merges → triage ticks and closes #231 → this epic closes on that act. It is still this epic's only outstanding criterion. **Nothing else on this board moved and nothing waits on a builder here.** #231 stays `post-merge`, unassigned, unflagged and unclaimable; #263 is `ready`, unblocked and claimable now, and it collides with nothing — a `post-merge` issue is not a #288 carrier state, so the `CHANGELOG.md` overlap between #263 and #231 correctly takes no edge in either direction.
claude-bot-andresmgsl commented 2026-08-25 17:59:11 +00:00
Author
Member
Copy link

🧹 Epic body corrected (triage, 2026-08-25T17:58Z) — two sentences, both the same expired reading of #263's queue state. No checkbox moves, no label moves, and the ## Task list is unchanged and current.

What moved on the board. #263 went claimed at 2026-08-25T17:07:13Z — ready REMOVE 17:07:12Z, claimed ADD 17:07:13Z, assignee @codex-bot-andresmgsl — and !264 opened 17:10:31Z at head f221647. Read from label events, not from .labels or the thread. This epic's own label events were paged by hand immediately before this write: epic, release, enhancement, scope:release-flow, nothing since 2026-08-17T23:34:15Z.

The two corrections.

  1. "#263 is ready, unblocked and claimable now" → #263 is open and unblocked, and its merge discharges #231's first criterion. Its queue state in between is the board's to show and not this epic's — the same treatment this epic already gives #241 and #251, applied now to its own remaining child.
  2. Acceptance criterion 1: "#263 is ready and open" → "#263 is open".

The wake is unchanged and is still a chain of two: #263 merges → triage ticks #263's post-merge criterion and discharges #231's first criterion → #231 closes → this epic closes on that act. #263's row stays unticked, which is correct: nothing has merged. #231 was corrected for the same class in this same tick.

🧹 **Epic body corrected (triage, 2026-08-25T17:58Z) — two sentences, both the same expired reading of #263's queue state. No checkbox moves, no label moves, and the `## Task list` is unchanged and current.** **What moved on the board.** #263 went **`claimed` at 2026-08-25T17:07:13Z** — `ready` REMOVE 17:07:12Z, `claimed` ADD 17:07:13Z, assignee @codex-bot-andresmgsl — and **!264 opened 17:10:31Z** at head `f221647`. Read from label events, not from `.labels` or the thread. This epic's own label events were paged by hand immediately before this write: `epic`, `release`, `enhancement`, `scope:release-flow`, nothing since 2026-08-17T23:34:15Z. **The two corrections.** 1. *"#263 is `ready`, unblocked and claimable now"* → #263 is open and unblocked, and its **merge** discharges #231's first criterion. Its queue state in between is the board's to show and not this epic's — the same treatment this epic already gives #241 and #251, applied now to its own remaining child. 2. Acceptance criterion 1: *"#263 is `ready` and open"* → *"#263 is open"*. **The wake is unchanged and is still a chain of two**: #263 merges → triage ticks #263's post-merge criterion and discharges #231's first criterion → #231 closes → this epic closes on that act. #263's row stays unticked, which is correct: nothing has merged. #231 was corrected for the same class in this same tick.
claude-bot-andresmgsl commented 2026-08-25 18:37:12 +00:00
Author
Member
Copy link

🎯 The campaign is complete and this epic is closed. All five rows in the
## Task list are ticked and all four acceptance criteria are verified. The
## Task list prose was rewritten in this same tick rather than annotated —
every paragraph in it described a wait, and a stale epic misleads every scan.

How the last step ran, in one chain. #263 was claimed 2026-08-25T17:07:13Z
and merged as !264 at 18:28:48Z (0533766). Triage measured both post-merge
facts against main at 18:31Z — the ## 0.6.2 — 2026-08-24 section
byte-identical to the assembler's own seven-fragment output (diff empty
against a 7bdae45 worktree assembly with changelog.d/238.md restored) and
changelog.d/238.md absent from main — moved #263 by hand from claimed
to post-merge because the sweep had not derived it yet, ticked its list and
closed it at 18:34:09Z. That discharged #231's first acceptance criterion,
the one the option-B ruling re-aimed from a green that cannot arrive at 5a8fce8
to a fact about the tree; #231 was ticked and closed at 18:36:14Z. This epic
closes on that act.

What upstream 0.6.1–0.6.3 adoption delivered, so a reader of the 0.7.x
campaign starts from a written record rather than archaeology:

  • #229 doctrine docs, #230 the reconciler (membership record, gate fixes,
    CommonMark row parser), #246 the release prose as a fragment, #231 the
    release itself — 0.6.2 tagged at 5a8fce8 and published 2026-08-24T16:10:40Z
    — and #263 the ruled correction of its shipped changelog section.
  • The ancestry did not move and was never meant to. .upstream-ref stays at
    8c3a4d1 (upstream 0.6.0, merged by #198); the content baseline is
    upstream-0.6.3. docs/UPSTREAM-SYNC.md names both separately, and the 0.7.x
    campaign is the one that would advance .upstream-ref if it merges rather than
    ports.
  • Two things are deferred on the record: upstream's own drill-record
    bookkeeping fixes, and the whole upstream 0.7.0–0.7.4 line.

Two facts the campaign leaves standing, both deliberate rather than loose.
CI / self-guards is red at the tagged commit 5a8fce8 permanently — that
commit is immutable, no pull request can re-grade it, and option B accepted the
bounded red rather than chasing it. And from 0533766 forward the tree's 0.6.2
section carries one entry the published 0.6.2 release body does not;
changelog.d/263.md states that divergence in the notes 0.6.3 will ship, so a
consumer meets it without opening this board. main itself is green on
self-guards at every graded commit from 46458ba (2026-08-24T18:53:47Z)
forward; 0533766's own run was queued 18:28:49Z and had not reported when this
was written, which is named rather than claimed, and if it breaks that chain it
is a fresh fact about main and earns its own issue, not a reopen of anything
here.

Downstream and outside this close:
crew#122 adopts
0.6.2 in crew — ten 0.6.1 refs plus the .ceremony/ mirror. It is a consumer
of this release, not a member of this campaign; this epic asked only that it be
minted and linked, which it is, and it stays open on crew's board under crew's
own contract.

🎯 **The campaign is complete and this epic is closed.** All five rows in the `## Task list` are ticked and all four acceptance criteria are verified. The `## Task list` prose was rewritten in this same tick rather than annotated — every paragraph in it described a wait, and a stale epic misleads every scan. **How the last step ran, in one chain.** #263 was claimed 2026-08-25T17:07:13Z and merged as !264 at **18:28:48Z (`0533766`)**. Triage measured both post-merge facts against `main` at 18:31Z — the `## 0.6.2 — 2026-08-24` section **byte-identical** to the assembler's own seven-fragment output (`diff` empty against a `7bdae45` worktree assembly with `changelog.d/238.md` restored) and **`changelog.d/238.md` absent from `main`** — moved #263 by hand from `claimed` to `post-merge` because the sweep had not derived it yet, ticked its list and closed it at **18:34:09Z**. That discharged #231's first acceptance criterion, the one the option-B ruling re-aimed from a green that cannot arrive at `5a8fce8` to a fact about the tree; #231 was ticked and closed at **18:36:14Z**. This epic closes on that act. **What upstream 0.6.1–0.6.3 adoption delivered**, so a reader of the 0.7.x campaign starts from a written record rather than archaeology: - **#229** doctrine docs, **#230** the reconciler (membership record, gate fixes, CommonMark row parser), **#246** the release prose as a fragment, **#231** the release itself — `0.6.2` tagged at `5a8fce8` and published 2026-08-24T16:10:40Z — and **#263** the ruled correction of its shipped changelog section. - **The ancestry did not move and was never meant to.** `.upstream-ref` stays at `8c3a4d1` (upstream `0.6.0`, merged by #198); the content baseline is `upstream-0.6.3`. `docs/UPSTREAM-SYNC.md` names both separately, and the 0.7.x campaign is the one that would advance `.upstream-ref` if it merges rather than ports. - **Two things are deferred on the record**: upstream's own drill-record bookkeeping fixes, and the whole upstream `0.7.0`–`0.7.4` line. **Two facts the campaign leaves standing, both deliberate rather than loose.** `CI / self-guards` is red at the tagged commit `5a8fce8` **permanently** — that commit is immutable, no pull request can re-grade it, and option B accepted the bounded red rather than chasing it. And from `0533766` forward the tree's `0.6.2` section carries one entry the published `0.6.2` release body does not; `changelog.d/263.md` states that divergence in the notes 0.6.3 will ship, so a consumer meets it without opening this board. `main` itself is green on `self-guards` at every graded commit from `46458ba` (2026-08-24T18:53:47Z) forward; `0533766`'s own run was queued 18:28:49Z and had not reported when this was written, which is named rather than claimed, and if it breaks that chain it is a fresh fact about `main` and earns its own issue, not a reopen of anything here. **Downstream and outside this close:** [crew#122](https://forgejo.heavyduty.builders/heavy-duty/crew/issues/122) adopts `0.6.2` in crew — ten `0.6.1` refs plus the `.ceremony/` mirror. It is a consumer of this release, not a member of this campaign; this epic asked only that it be minted and linked, which it is, and it stays open on crew's board under crew's own contract.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
build/275-merge-base-release-shape
build/273-resume-merge-door
build/271-atomic-forgejo-release
build/269-upstream-sync-record
release-0.6.3
build/265-needs-triage-description
build/263-consume-stranded-changelog
build/247-proposal-intake
build/243-forgejo-workflow-name
build/251-release-path-doc
build/241-fork-labels
probe/241-same-head
build/253-stranded-fragments
build/240-exhaustive-timeline
build/234-bind-refs-token
build/238-review-requests
build/231-release-0-6-2
build/246-upstream-release-fragment
0.6.3
0.6.2
0.6.1
0.4.1
0.4.0
0.3.0
0.2.0
0.1.0
Labels
Clear labels   
attention

A demand is parked here for the assignee: pick up the thread, ack by removing this label

  
blocked

Waiting on another PR or issue to land first

  
blocker:ci-red

A check is failing — the agent owes a fix (not a rebase)

  
blocker:conflict

Does not merge — the branch conflicts and the agent owes a rebase

  
blocker:drill-pending

A release PR whose version has no drills/X.Y.Z.md record — correct but unevidenced

  
blocker:unrequested

Somebody still owes a verdict and nobody was asked for one

  
bug

Something isn't working

  
claimed

A builder owns it: assignee set, draft PR expected shortly

  
documentation

Improvements or additions to documentation

  
enhancement

New feature or request

  
epic

Organizes other issues via a dependency-ordered task list — builders never pick it

  
merge-next

Head of the merge queue — merge this one next (set by hand/agent, cleared here)

  
needs-ruling

A human decision is pending — question, options and a recommendation are in the comment

  
needs-triage

Did not come through triage — owes normalization into work or a reasoned refusal

  
offsite

Issue deliverable is a PR in another repository — claim clock paused

  
post-merge

Refs-linked PR merged; post-merge criteria remain and triage owns completion

  
ready

Triaged, spec complete, unblocked — a builder can start now and succeed

  
release

Release flow and version/packaging work

  
scope:docs

README doctrine, CONSUMERS.md, the role files

  
scope:guards

changelog-armed / changelog-monotonic / drill-recorded

  
scope:labels

The labels workflow, reconciler, the taxonomy

  
scope:release-flow

The reusable release workflow, decide, the doors

  
stale

No activity for 48h — needs a poke (sweep-managed)

  
state:addressing

All bots reviewed — coding agent owes the single reply + fixes

  
state:bots-reviewing

Waiting on the bot reviewers to finish the round

  
state:building

Pre-round: the builder is still building — draft is evidence for it, not the definition

  
state:needs-human

No blockers, all bots approve — waiting on the human reviewer

No labels
attention
blocked
blocker:ci-red
blocker:conflict
blocker:drill-pending
blocker:unrequested
bug
claimed
documentation
enhancement
epic
merge-next
needs-ruling
needs-triage
offsite
post-merge
ready
release
scope:docs
scope:guards
scope:labels
scope:release-flow
stale
state:addressing
state:bots-reviewing
state:building
state:needs-human
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/ceremony#228
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?