frankenbit/cellblock
Watch
17
0
Fork
You've already forked cellblock
 0
Code Issues 3 Pull requests Projects Releases 4 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

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

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

✅ 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

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
Some checks are pending
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
pr / gates (pull_request)
Required

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   
kind
chore
 Maintenance, tooling, refactor

  
priority
low
 Low priority, address when convenient

  
size
S
 Small: simple change, ~1-2h

  
status
blocked
 Cannot start until a named dependency resolves

No labels
kind
chore
priority
low
size
S
status
blocked
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.