Repository navigation
docs(release): the live web deployment's digest receipt — it is not the v0.2.5 release bytes - #127
Merged
Merged
Conversation
The live deployment was recorded as serving the v0.2.5 release bytes. Measured by digest on 2026-11-11, that is false: the live bundle's trunk asset name (2274ac8c2925b61d) and wasm sha256 (f4f0a3f0...) match neither the published v0.2.5 release asset (f9dbe2f14305b2d9 / a8a4fa4f...) nor a rebuild of the v0.2.5 tag (103c62d3366aef17 / 5934702f...). The earlier match was inferred from equal file sizes and an identical appinfo.json, not from digests. The served index.html does differ from the build's own, and that difference is fully explained: the asset names and their integrity digests are substituted, and the Cloudflare Pages analytics beacon is injected. The live deployment corresponds to no identifiable release, which is what blocker B-6 in the task board already says. The receipt is in T18-release.md, and Project-Status.md now states the deployment's relationship to main instead of leaving it to be re-derived. Co-Authored-By: Claude Code <noreply@anthropic.com>
Contributor
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 3 minutes. View limit details
Pre-merge checks:
  |
| Check name | Status | Explanation | Resolution |
|---|---|---|---|
| Title check |  |
This assessment has not completed. The check will be retried on the next pre-merge check run. |
-
Check name Status Explanation Description Check Check skipped - CodeRabbit’s high-level summary is enabled.
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A job's `timeout:` is a watchdog, not a gate: it kills the container and records `timed_out` with no diagnostic about what was slow. The budgets were sized by guess, and the guess is now falsified by the fleet's own record — a job was killed at 20.2 min and at 20.3 min while still working, and the release job's worst successful run finished 1.7 minutes inside its 90-minute budget. The runner holds 4 concurrent containers on a 16-core host and each compiles the workspace, so a co-tenant wave inflates a job roughly 4x. Measured on 2026-11-11 with 9 runs in flight (idle in parentheses): job budget worst success idle fmt-layers 20m 20.1 min 0.3 min clippy-test 90m 76.9 min 10.3 min wasm-web 60m 45.6 min 9.0 min corpus-golden 30m 19.6 min 2.5 min perf-budgets 20m 14.3 min 3.2 min fuzz 60m 52.9 min 10.6 min generated-docs 20m 16.1 min 2.1 min release 90m 88.3 min 38.8 min Each budget below is ~2.5x the worst successful duration, so a loaded job still fits and a genuinely hung job is still killed: fmt-layers 45m, clippy-test 150m, wasm-web 90m, corpus-golden 45m, perf-budgets 45m, fuzz 120m, generated-docs 45m, release 180m No gate is weakened: the budgets decide when a container is killed, not whether a check passes. Refs #126 Co-Authored-By: Claude Code <noreply@anthropic.com>
6 tasks
The branch's pipeline-watchdog sizing is already on main, so the .gitforge.yml conflict resolves to main's file. The wiki conflict is a factual one: main's reconciliation paragraph claimed the live site serves the v0.2.5 release bytes, which the digest measurement on T18 falsifies. The corrected paragraph stands, under main's heading. Co-Authored-By: Claude Code <noreply@anthropic.com>
…surement The board's deployment row still claimed the live site's JavaScript, wasm and `appinfo` "match" the v0.2.5 release bytes — the inference the digest receipt on T18 falsifies. The row and the two progress claims now state what was measured: the live bundle matches neither the published release asset nor a rebuild of the tag, so it corresponds to no identifiable release. Co-Authored-By: Claude Code <noreply@anthropic.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The live web deployment was recorded as serving the v0.2.5 release bytes. Measured by digest, that is false.
firecraft-web.pages.dev2274ac8c2925b61df4f0a3f0…f9dbe2f14305b2d9a8a4fa4f…xtask dist --webat the tag)103c62d3366aef175934702f…The trunk asset name carries a source-tree hash, so a differing name is a differing source; the wasm digest is the build's byte identity. The live bundle matches neither.
The earlier "it matches" conclusion came from equal file sizes and an identical
appinfo.json, not from digests. What is established: the servedindex.htmldiffers from the build's own only by the substituted asset names and their integrity digests plus the Cloudflare Pages analytics beacon, so the HTML difference is explained rather than drift — and the live deployment corresponds to no identifiable release, which is what blocker B-6 in the task board already says.Recorded in
docs/tasks/T18-release.md(deployment receipt) anddocs/wiki/Project-Status.md. The issue's false claim is corrected in #30 with the same receipt.No production publish is performed or requested here: closing B-6 needs a deploy whose asset name and wasm digest are recorded from a named commit, and that stays gated for maintainer approval.
CI: the pipeline watchdog budgets
This branch also carries
ci: size the pipeline watchdogs from the fleet's measured wall-clock(fcfe6db) — a CI-infrastructure change, not part of thefeature. The pipeline's job timeouts were shorter than a passing job can
take under the runner's load: the release job's worst successful run
finished 1.7 minutes inside its 90-minute budget, and two perf-budgets
runs were killed at 20.2 and 20.3 minutes while still working. This
branch's own receipt could not complete under those budgets.
Each budget is now ~2.5x the worst successful duration measured on the
fleet. No gate is weakened — a budget decides when a container is killed,
not whether a check passes. Measurement and reasoning: issue #126.
🤖 Generated with Claude Code