Skip to content

T18: reconcile the live web deployment with the local dist #30

New issue
New issue
Open
Open
T18: reconcile the live web deployment with the local dist#30
Labels
bugSomething isn't workingmilestoneMilestone and phase trackingreleaseRelease engineering and packaging work
Milestone
v0.2.6

Description

@aliasfoxkde
aliasfoxkde
opened on Nov 10, 2026

Objective. Establish, with a byte-level receipt, whether the live web deployment serves the current source — and if it does not, decide deliberately whether to redeploy or record why the live artifact is the intended one.

Why. The public deployment's manifest hashes for JavaScript, Wasm, and index differ from the local dist/web. Until someone identifies which artifact the live site actually serves, nobody can say whether the live app matches the current source, and "the hosted app is stale" is a guess rather than a finding. The deployment reconciliation (#104) already narrowed this substantially; this issue closes it.

What is already established. The 2026-11-11 reconciliation claimed that the live site's JavaScript, Wasm, and WebOS app metadata match the v0.2.5 release bytes. That claim is falsified by the digest receipt in the comments: 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. What is established: the served index.html differs from the build's own only by the substituted asset names and the Cloudflare analytics beacon, so the HTML difference is explained rather than drift — and the live deployment corresponds to no identifiable release. Two gaps remain, and they are what this issue tracks:

  1. The live site serves v0.2.5 (2026-11-03), while main has moved on substantially — the source is newer than the published release by design.
  2. The live site is not verified to be served from the canonical release artifact on Pages; its deployed source revision is still unproven.

Work

  1. Identify the deploy target and its provenance: which Pages project/branch the live host serves, and what the CI publish path actually deploys (wrangler pages deploy firecraft-web).
  2. Rebuild dist/web from the same source revision as the deployed artifact and compare byte-for-byte against the live-served bytes. Record the diff explicitly.
  3. Decide and record one of:
    • republish from the canonical release artifact — the deliberate path, requiring maintainer approval because it touches production; or
    • record that the live artifact is the intended one (i.e. v0.2.5 by design, with main ahead of it), with the exact evidence.
  4. Record the answer in docs/tasks/T18-release.md and in the deployment section of docs/wiki/Project-Status.md, so the next reader inherits the finding instead of re-deriving it.

Acceptance

  • A receipt names the deployed artifact's build revision and the byte-level diff (or a stated match) against the current source.
  • The Cloudflare analytics beacon's contribution to the HTML-manifest difference is documented, so it is not re-litigated.
  • The decision is either an approved republication (with the maintainer's approval recorded) or a written rationale for leaving v0.2.5 live.
  • docs/wiki/Project-Status.md states the deployment's relationship to main — today it says the source is newer than the published release, which is true but not the whole story.

Boundaries. Production deployment and any production tag remain gated for explicit maintainer approval. This issue authorizes the measurement and the decision, not the production publish itself.

Tracking: task #158; ticket docs/tasks/T18-release.md.

Next action (owner: release). Resolve the deploy provenance question first — name the Pages project and branch the live host serves, and whether the publish path is the canonical release artifact or a branch build. That answer decides whether step 3 is a republish or a written rationale.

Activity

  1. aliasfoxkde
    added this to the v0.2.6 milestone on Nov 10, 2026
  2. aliasfoxkde
    added
    bugSomething isn't working
    releaseRelease engineering and packaging work
    milestoneMilestone and phase tracking
    on Nov 10, 2026

  3. aliasfoxkde commented on Nov 10, 2026

    @aliasfoxkde
    aliasfoxkde
    on Nov 10, 2026
    OwnerAuthor

    Tracked as T27-50 in the release ledger; this issue carries it.

  4. aliasfoxkde commented on Nov 10, 2026

    @aliasfoxkde
    aliasfoxkde
    on Nov 10, 2026
    OwnerAuthor

    Status: IN PROGRESS

    Landed: docs/release/ARTIFACT-MATRIX.md (on main via PR #14's merge) records the four wasm sizes in play — 21,238,451 B published (v0.2.5), 21,231,517 B CI-built, 21,235,599 B the in-source comment, 21,274,323 B a local rebuild — and names the live deployment bundle 2274ac8c2925b61d against the published f9dbe2f14305b2d9 and the local rebuild e44296eb8407adf3. The discrepancy is recorded; it is not closed.
    Still outstanding: the live deployment's artifact is still not identified against the current source, and no byte-for-byte comparison of the deployed bundle against a fresh dist/web is on record.
    Next: identify the deployed artifact, rebuild, compare byte-for-byte, and either redeploy deliberately or record why the live artifact is the intended one. Owner: release engineering, with the web deploy owner.
    Note: #81 tracks the same task (T18) from the release-lane side — one of the two should carry the receipt.

  5. aliasfoxkde commented on Nov 11, 2026

    @aliasfoxkde
    aliasfoxkde
    on Nov 11, 2026
    OwnerAuthor

    Receipt — the live bundle is not the v0.2.5 release bytes, and not the v0.2.5 tag either.

    Measured 2026-11-11 by digest, not by file size. 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.

    Bundle trunk asset name wasm bytes wasm sha256
    live — https://firecraft-web.pages.dev 2274ac8c2925b61d 21 231 377 f4f0a3f06fa3f5057485715c5c039fda50de9a6a0e72a451a62bf56366dbdb11
    v0.2.5 release asset (firecraft-web-0.2.5.zip) f9dbe2f14305b2d9 21 238 451 a8a4fa4f28aa81a9e5fa6bb2a24eec1fe8a38b7ae4759333e12cc8c38b201865
    v0.2.5 tag rebuild (xtask dist --web at tag v0.2.5) 103c62d3366aef17 21 229 720 5934702ff141ea4cc7b0557abebaf95b78219adbc9ed2dc64607740a4a3e9e7b

    What the measurement establishes

    1. The live bundle is not the v0.2.5 release artifact. Different asset name, different wasm digest, different byte count. The JS text differs only in wasm-bindgen closure shim_idx values and the internal wasm-bindgen symbol hashes — a toolchain difference, not by itself proof of a source difference; the asset name is the source identity, and it differs.
    2. The live bundle is not reproducible from the v0.2.5 tag with the current CI toolchain either — the tag rebuild carries a third asset name. So the published v0.2.5 asset was built from a tree that is neither the tag nor the live deployment.
    3. The live HTML difference is fully explained. The served index.html is the build's own index.html with the asset names and their integrity digests substituted, plus the Cloudflare Pages analytics beacon the CDN injects. That accounts for the whole 2 195 → 2 409 byte difference; there is no unexplained drift.
    4. appinfo.json matches the release asset byte for byte (7d039c36f28e9b1f67f5ee45fd7bdfd705873e716cc13b09d093be19ea0a3ffa), so the live app reports version 0.2.5 — but every commit since the v0.2.5 stamp also reports 0.2.5, so the version stamp identifies nothing.

    Correction. This issue's body recorded that the live site's JavaScript and wasm "match the v0.2.5 release bytes". That is falsified: the digests differ, and the match was inferred from equal file sizes and an identical appinfo.json rather than from digests. The accurate statement is the one the task board already carries (blocker B-6): the live web deployment serves a bundle that corresponds to no identifiable release.

    Recorded in docs/tasks/T18-release.md (deployment receipt) and docs/wiki/Project-Status.md.

    What would close this. Deploy a bundle whose asset name and wasm digest are recorded in the ticket, from a named commit, and re-measure the live host against that record. That is a production publish and stays gated for explicit maintainer approval — this issue authorizes the measurement, not the publish.

  6. aliasfoxkde commented on Nov 12, 2026

    @aliasfoxkde
    aliasfoxkde
    on Nov 12, 2026
    OwnerAuthor

    PR #127 landed 2026-11-12 (8d5c442): the deployment digest receipt is now in docs/tasks/T18-release.md. The live bundle matches neither the v0.2.5 release asset nor a tag rebuild, so the live deployment corresponds to no identifiable release. Publishing a bundle with recorded digests remains maintainer-gated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingmilestoneMilestone and phase trackingreleaseRelease engineering and packaging work

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions