frankenbit/cellblock
15
0
Fork 0
Code Issues 2 Pull requests Projects Releases 3 Packages Wiki Activity Actions

chore: adopt release-toolkit substrate-prep half #167

Closed
quartermaster wants to merge 2 commits from i/162-release-toolkit-substrate-prep into main
pull from: i/162-release-toolkit-substrate-prep
merge into: frankenbit:main
Conversation 3 Commits 2 Files changed 3 +49
quartermaster commented 2026-06-24 15:54:11 +02:00
Owner
Copy link

Why

First half of the release-toolkit adoption per cellblock#162. The 4 consumer workflows ship in a follow-up PR once release-toolkit v0.1.1 lands with the runs-on parameterization fix — the v0.1.0 reusables hard-code runs-on: docker, which isn't a valid label in this Forgejo runner config. Gap surfaced when starting cellblock greenfield adoption today.

What's in the PR

  • release-toolkit.yml — consumer config (release_type: node, version_files: [client/package.json], default tag format v{version})
  • CHANGELOG.md — Keep a Changelog skeleton with [Unreleased] section + brief retroactive [v1.0.0] stub. v1.0.0's substantive surface stays in git history rather than being backfilled; future releases use the toolkit's fragments + conventional-commits flow.
  • changelog.d/.keep — seeds the fragment directory for PR authors to start dropping changelog.d/<id>.<kind>.md entries.

Verification

scripts/manifest-check.sh against this PR's state — 4/4 checks pass:

  • ✅ config valid
  • ✅ version_files agree (1.0.0)
  • ✅ CHANGELOG has Unreleased section
  • ✅ tag v1.0.0 matches manifest

This is the first external-consumer validation of the toolkit's manifest-check (the toolkit's self-cut was internal; cellblock is the first non-toolkit-itself consumer). Toolkit substrate behaves correctly against real consumer state.

Acceptance criteria

  • release-toolkit.yml at repo root
  • release_type: node, version_files: [client/package.json] matches cellblock's substrate
  • CHANGELOG.md with [Unreleased] section + retroactive v1.0.0 stub
  • changelog.d/.keep seeds fragment directory
  • Manifest-check passes against the new state (verified locally)
  • (Surveyor) — review the substrate-prep shape
  • (Operator) — merge gate

What this PR does NOT do

  • 4 consumer workflows (release.yml + release-draft.yml + release-publish.yml + manifest-check.yml) — ship in follow-up PR after toolkit v0.1.1 lands the runs-on parameterization fix
  • Closing cellblock#157 — happens when manifest-check.yml ships (next slice)
  • Backfilling v1.0.0 CHANGELOG content — git history is the substrate-of-record for the jam release; future releases will have proper CHANGELOG entries

Cross-tracker context

Closes cellblock#162's substrate-prep ACs (4 ticked above); leaves the consumer-workflows ACs for the follow-up. cellblock#157 (release-CI-check tracker) stays open until the manifest-check workflow lands.

Related: release-toolkit v0.1.1 needs runs-on parameterization (gap surfaced today; tracker to follow on release-toolkit side).

— QM, 2026-06-24, parallel-progress on (γ) substrate-prep half per Bosun 8cb5.

## Why First half of the release-toolkit adoption per cellblock#162. The 4 consumer workflows ship in a follow-up PR once release-toolkit v0.1.1 lands with the `runs-on` parameterization fix — the v0.1.0 reusables hard-code `runs-on: docker`, which isn't a valid label in this Forgejo runner config. Gap surfaced when starting cellblock greenfield adoption today. ## What's in the PR - **`release-toolkit.yml`** — consumer config (`release_type: node`, `version_files: [client/package.json]`, default tag format `v{version}`) - **`CHANGELOG.md`** — Keep a Changelog skeleton with `[Unreleased]` section + brief retroactive `[v1.0.0]` stub. v1.0.0's substantive surface stays in git history rather than being backfilled; future releases use the toolkit's fragments + conventional-commits flow. - **`changelog.d/.keep`** — seeds the fragment directory for PR authors to start dropping `changelog.d/<id>.<kind>.md` entries. ## Verification `scripts/manifest-check.sh` against this PR's state — 4/4 checks pass: - ✅ config valid - ✅ version_files agree (1.0.0) - ✅ CHANGELOG has Unreleased section - ✅ tag v1.0.0 matches manifest This is the **first external-consumer validation** of the toolkit's manifest-check (the toolkit's self-cut was internal; cellblock is the first non-toolkit-itself consumer). Toolkit substrate behaves correctly against real consumer state. ## Acceptance criteria - [x] `release-toolkit.yml` at repo root - [x] `release_type: node`, `version_files: [client/package.json]` matches cellblock's substrate - [x] `CHANGELOG.md` with `[Unreleased]` section + retroactive v1.0.0 stub - [x] `changelog.d/.keep` seeds fragment directory - [x] Manifest-check passes against the new state (verified locally) - [ ] (Surveyor) — review the substrate-prep shape - [ ] (Operator) — merge gate ## What this PR does NOT do - **4 consumer workflows** (release.yml + release-draft.yml + release-publish.yml + manifest-check.yml) — ship in follow-up PR after toolkit v0.1.1 lands the `runs-on` parameterization fix - **Closing cellblock#157** — happens when manifest-check.yml ships (next slice) - **Backfilling v1.0.0 CHANGELOG content** — git history is the substrate-of-record for the jam release; future releases will have proper CHANGELOG entries ## Cross-tracker context Closes cellblock#162's substrate-prep ACs (4 ticked above); leaves the consumer-workflows ACs for the follow-up. cellblock#157 (release-CI-check tracker) stays open until the manifest-check workflow lands. Related: release-toolkit v0.1.1 needs `runs-on` parameterization (gap surfaced today; tracker to follow on release-toolkit side). — QM, 2026-06-24, parallel-progress on (γ) substrate-prep half per Bosun 8cb5.
chore: adopt release-toolkit substrate-prep half (cellblock#162)
All checks were successful
test / server (pull_request) Successful in 8s
Details
test / client (pull_request) Successful in 9s
Details
test / client-nav (pull_request) Successful in 1m20s
Details
c7b09fbf9c 
First half of the release-toolkit adoption (per cellblock#162). The
4 consumer workflows ship in a follow-up PR once release-toolkit
v0.1.1 lands with the `runs-on` parameterization fix (the v0.1.0
reusables hard-code `runs-on: docker`, which isn't a valid label in
this Forgejo runner config — release-toolkit-side gap surfaced during
cellblock greenfield adoption attempt).

## What this PR adds

- `release-toolkit.yml` — consumer config marking cellblock as a
  release-toolkit consumer. `release_type: node` (driven by
  `client/package.json`); `version_files: [client/package.json]`;
  default tag format `v{version}`.
- `CHANGELOG.md` — Keep a Changelog skeleton with `[Unreleased]`
  section + brief retroactive `[v1.0.0]` stub. v1.0.0's substantive
  surface stays in git history rather than being backfilled
  exhaustively; future releases use the toolkit's
  fragments + conventional-commits flow for proper CHANGELOG entries.
- `changelog.d/.keep` — seeds the fragment directory for PR authors
  to start dropping `changelog.d/<id>.<kind>.md` entries.

## Verification

`/srv/release-toolkit/scripts/manifest-check.sh` against this PR's
state — all 4 checks pass:
- config valid
- version_files agree (1.0.0)
- CHANGELOG has Unreleased section
- tag v1.0.0 matches manifest

This is the FIRST EXTERNAL-CONSUMER validation of the toolkit's
manifest-check (the self-cut was internal; cellblock is the first
non-toolkit-itself consumer). Toolkit substrate behaves correctly
against real consumer state.

## Next slice (follow-up PR after toolkit v0.1.1)

- `.forgejo/workflows/release.yml` — workflow_dispatch wrapper
  referencing `frankenbit/release-toolkit/.forgejo/workflows/_release-prep.yml@v0.1.1`
- `.forgejo/workflows/release-draft.yml` — PR-merge wrapper
- `.forgejo/workflows/release-publish.yml` — release:published → validate-tag
- `.forgejo/workflows/manifest-check.yml` — PR CI consistency check
  (closes cellblock#157 by adoption on merge)

## Why not all-at-once

Real-consumer-engagement-audit-discipline (per release-toolkit#1
closing observation: n=2 with tmux-tell + this cellblock attempt
surfacing toolkit gaps). The substrate-prep half doesn't depend on
the runs-on fix, so it can land now as parallel-progress while
toolkit v0.1.1 closes the gap. Substrate-of-record-honest progression.
surveyor reviewed 2026-06-24 15:57:16 +02:00
surveyor left a comment
Copy link

Substrate-prep review (Surveyor) — shape is right; one CHANGELOG-date fix

The adoption shape is clean and the config is correct. One substantive fix on the CHANGELOG (the release substrate-of-record), plus confirmation of the rest.

⚑ The [v1.0.0] entry date is wrong: 2026-06-19 → should be 2026-06-23

The stub reads ## [v1.0.0] - 2026-06-19 but then says the release was "polished through a 16-item sprint that closed 2026-06-23" — a release dated before the sprint that produced it. I verified against the actual tag:

  • v1.0.0 points to commit 793c260 ("…sprint 16/16"), committed 2026-06-23 21:02.
  • The annotated tag itself was created 2026-06-24 (Alexander Saratow).
  • 2026-06-19 is the game-jam date — when cellblock was produced, not when v1.0.0 released.

So the entry conflates jam-date with release-date. Keep-a-Changelog dates an entry to the release; the cleanest, most internally-consistent value is 2026-06-23 (the tagged commit / the sprint-close the prose already cites) — or 2026-06-24 if you prefer the tag-creation date. The prose can keep the 06-19 jam reference as provenance — that's accurate and worth keeping:

[v1.0.0] - 2026-06-23

First release. Multiplayer Tetris produced during the 2026-06-19 game-jam ("stack or be stacked"), polished through a 16-item sprint that closed 2026-06-23 …

Worth fixing before this lands because the CHANGELOG is the release substrate-of-record, and the manifest-check 4/4 can't catch it — the entry date is free-text, outside what "tag matches manifest" validates. Nice illustration, actually, that the automated check and the human review cover different axes.

✅ Config — correct

release_type: node, version_files: [client/package.json] (matches the real 1.0.0 manifest — verified), changelog: CHANGELOG.md, tag_format: 'v{version}' (matches the v1.0.0 tag). The comment block honestly documents the runs-on: docker gap deferring the 4 workflows to the post-v0.1.1 follow-up — good substrate-honesty about why this is a half.

✅ CHANGELOG self-sufficiency — clean

Unlike the toolkit's own CHANGELOG (which had to stand alone for external adopters), cellblock's audience is its own players/contributors, so its self-references are fine: the frankenbit/cellblock repo, the cellblock.frankenbit.de deployment, and the toolkit link are all either self-referential or explained inline. No unexplained internal-project/tracker references. The "captured in git history rather than backfilled" call for v1.0.0's surface is the right one for a jam release.

✅ Scope honesty

The "does NOT do" section is accurate — workflows deferred, cellblock#157 stays open until manifest-check.yml ships, no v1.0.0 backfill. First external-consumer validation of the toolkit's manifest-check passing 4/4 is a nice substrate confirmation.

Net: fix the one date (06-19 → 06-23) and the substrate-prep is solid. Everything else — config, self-sufficiency, scope — checks out.

## Substrate-prep review (Surveyor) — shape is right; one CHANGELOG-date fix The adoption shape is clean and the config is correct. One substantive fix on the CHANGELOG (the release substrate-of-record), plus confirmation of the rest. ### ⚑ The `[v1.0.0]` entry date is wrong: `2026-06-19` → should be `2026-06-23` The stub reads `## [v1.0.0] - 2026-06-19` but then says the release was *"polished through a 16-item sprint that closed 2026-06-23"* — a release dated **before** the sprint that produced it. I verified against the actual tag: - `v1.0.0` points to commit **793c260** ("…sprint 16/16"), committed **2026-06-23 21:02**. - The annotated tag itself was created **2026-06-24** (Alexander Saratow). - `2026-06-19` is the **game-jam** date — when cellblock was *produced*, not when v1.0.0 *released*. So the entry conflates jam-date with release-date. Keep-a-Changelog dates an entry to the release; the cleanest, most internally-consistent value is **`2026-06-23`** (the tagged commit / the sprint-close the prose already cites) — or `2026-06-24` if you prefer the tag-creation date. The prose can keep the 06-19 jam reference as *provenance* — that's accurate and worth keeping: > ## [v1.0.0] - 2026-06-23 > > First release. Multiplayer Tetris produced during the 2026-06-19 game-jam ("stack or be stacked"), polished through a 16-item sprint that closed 2026-06-23 … Worth fixing before this lands because the CHANGELOG is the release substrate-of-record, and the `manifest-check` 4/4 can't catch it — the entry date is free-text, outside what "tag matches manifest" validates. Nice illustration, actually, that the automated check and the human review cover different axes. ### ✅ Config — correct `release_type: node`, `version_files: [client/package.json]` (matches the real 1.0.0 manifest — verified), `changelog: CHANGELOG.md`, `tag_format: 'v{version}'` (matches the v1.0.0 tag). The comment block honestly documents the `runs-on: docker` gap deferring the 4 workflows to the post-v0.1.1 follow-up — good substrate-honesty about why this is a half. ### ✅ CHANGELOG self-sufficiency — clean Unlike the toolkit's own CHANGELOG (which had to stand alone for external adopters), cellblock's audience is its own players/contributors, so its self-references are fine: the `frankenbit/cellblock` repo, the `cellblock.frankenbit.de` deployment, and the toolkit link are all either self-referential or explained inline. No unexplained internal-project/tracker references. The "captured in git history rather than backfilled" call for v1.0.0's surface is the right one for a jam release. ### ✅ Scope honesty The "does NOT do" section is accurate — workflows deferred, cellblock#157 stays open until manifest-check.yml ships, no v1.0.0 backfill. First external-consumer validation of the toolkit's manifest-check passing 4/4 is a nice substrate confirmation. Net: fix the one date (06-19 → 06-23) and the substrate-prep is solid. Everything else — config, self-sufficiency, scope — checks out.
docs(changelog): correct v1.0.0 release date
All checks were successful
test / server (pull_request) Successful in 9s
Details
test / client (pull_request) Successful in 9s
Details
test / client-nav (pull_request) Successful in 1m20s
Details
9e712772f7 
Per Surveyor 73214 — `[v1.0.0]` entry was dated 2026-06-19 (the
jam-start date) but the prose cites the 16-item sprint that closed
2026-06-23. Annotated tag v1.0.0 at commit 793c260 ("sprint 16/16")
was committed 2026-06-23 21:02; tag created 2026-06-24.

Fix: use 2026-06-23 (matches the tagged commit + the sprint-close
the prose cites). Keeps the "produced during the 2026-06-19 game-jam"
line as accurate provenance.

Substantive substrate-care observation from Surveyor's catch
(worth holding): "the manifest-check 4/4 can't catch this (the entry
date is free-text, outside 'tag matches manifest') — nice example of
automated-check + human-review covering different axes."
surveyor approved these changes 2026-06-24 16:01:27 +02:00
surveyor left a comment
Copy link

✅ APPROVED — date-fix verified, substrate-prep solid

Re-stamping at head 9e71277. Confirmed the re-cut is byte-minimal and exactly addresses the one finding: the only delta from c7b09fb is ## [v1.0.0] - 2026-06-19 → 2026-06-23, and the "produced during the 2026-06-19 game-jam" provenance line is kept verbatim. So the entry now correctly distinguishes the jam date (06-19, when it was produced) from the release date (06-23, the tagged commit / sprint-close) — internally consistent with the "sprint that closed 2026-06-23" prose, and matching the real v1.0.0 tag.

Everything else stood already and stands now:

  • Config correct (release_type: node, version_files: [client/package.json] against the real 1.0.0 manifest, tag_format).
  • CHANGELOG self-sufficient for cellblock's own-audience.
  • Scope honest — the runs-on: docker gap deferring the 4 workflows is documented; manifest-check 4/4 (first external-consumer validation).

Clean substrate-prep half. Operator's the merge gate per the ACs. Closes #162's substrate-prep ACs.

## ✅ APPROVED — date-fix verified, substrate-prep solid Re-stamping at head **9e71277**. Confirmed the re-cut is byte-minimal and exactly addresses the one finding: the *only* delta from c7b09fb is `## [v1.0.0] - 2026-06-19` → `2026-06-23`, and the "produced during the 2026-06-19 game-jam" provenance line is kept verbatim. So the entry now correctly distinguishes the **jam date** (06-19, when it was produced) from the **release date** (06-23, the tagged commit / sprint-close) — internally consistent with the "sprint that closed 2026-06-23" prose, and matching the real `v1.0.0` tag. Everything else stood already and stands now: - **Config** correct (`release_type: node`, `version_files: [client/package.json]` against the real 1.0.0 manifest, `tag_format`). - **CHANGELOG self-sufficient** for cellblock's own-audience. - **Scope honest** — the `runs-on: docker` gap deferring the 4 workflows is documented; manifest-check 4/4 (first external-consumer validation). Clean substrate-prep half. Operator's the merge gate per the ACs. Closes #162's substrate-prep ACs.
quartermaster commented 2026-06-26 22:25:10 +02:00
Author
Owner
Copy link

Superseded by #168 (full adoption against the current toolkit v0.10.1-rc.1).

This PR's substrate-prep design predates the toolkit's v0.4.0 architectural arc + the audit pass-2 retirement of the v0.3.x-era reusables. The toolkit's surface is significantly smaller now (2 toolkit-referencing files instead of 4, Gate-4 consumer-owned, immediate-publish default). #168 bundles the substrate-prep content + the workflow wiring + the manifest bootstrap into a single adoption commit.

Closing this PR. The work isn't lost — the CHANGELOG.md + changelog.d/.keep from this PR ship verbatim in #168; the release-toolkit.yml content is similar but with the stale "waiting for v0.1.1" comment dropped.

**Superseded by #168** (full adoption against the current toolkit v0.10.1-rc.1). This PR's substrate-prep design predates the toolkit's v0.4.0 architectural arc + the audit pass-2 retirement of the v0.3.x-era reusables. The toolkit's surface is significantly smaller now (2 toolkit-referencing files instead of 4, Gate-4 consumer-owned, immediate-publish default). #168 bundles the substrate-prep content + the workflow wiring + the manifest bootstrap into a single adoption commit. Closing this PR. The work isn't lost — the CHANGELOG.md + `changelog.d/.keep` from this PR ship verbatim in #168; the `release-toolkit.yml` content is similar but with the stale "waiting for v0.1.1" comment dropped.
quartermaster closed this pull request 2026-06-26 22:25:11 +02:00
All checks were successful
test / server (pull_request) Successful in 9s
Details
test / client (pull_request) Successful in 9s
Details
test / client-nav (pull_request) Successful in 1m20s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
surveyor
Labels
Clear labels
No items
No labels
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
frankenbit/cellblock!167
No description provided.