[gHashTag]

Refs gHashTag/t27#10229 (t27 PR: gHashTag/t27#10241, t27-mcp PR: gHashTag/t27-mcp#18)

The vendored copy under apps/website/public/t27f/graph/ was synced by hand and its PROVENANCE.txt pins drifted. This adds the build record next to it and a cheap check.

• apps/website/public/t27f/graph/t27f.build: the lines of the gHashTag/t27-mcp wasm/t27f.build record that name files kept here (# input lines, then <sha256> <file> for the wasm, the view constants and the vendored specs).
• npm run check:t27f (apps/website): grep -v '^#' t27f.build | shasum -a 256 -c - -- exits 1 and names a file whose bytes differ from the record. Verified OK on this branch.
• PROVENANCE.txt points at the record instead of a hand-pasted Checksums block.

No new hand-written code: the record is data, the check is one package.json script line using shasum. The vendored wasm and mjs are not changed here; they already match the record (the cold lab rebuild reproduced the 7b2a0f0c wasm byte for byte).

Not added: a CI step that runs check:t27f (workflow files are owner gate files). Follow-up for the owner.

🤖 Generated with Claude Code

[tri-claw]

Summary by t27-bees

This PR adds a machine-verifiable build record (t27f.build) for the vendored t27f graph assets and an npm script (check:t27f) that validates the vendored files against that record using shasum. It replaces the hand-maintained checksum block in PROVENANCE.txt with a reference to the record.

Worth a look

• apps/website/package.json:117 — The check:t27f script uses shasum, which is not installed by default on Windows. Developers or CI runners on Windows without Git Bash/WSL will get "command not found" unless the environment provides it.
• apps/website/public/t27f/graph/t27f.build — The record lists files with two spaces between hash and path (standard shasum output). If any listed file is missing or renamed in the vendored directory, shasum -c will fail with "No such file or directory" rather than a hash mismatch, which is correct but worth knowing.
• apps/website/public/t27f/graph/PROVENANCE.txt:41-47 — The new text says the record is "produced by the rule in gHashTag/t27 specs/t27f/build.t27 (#10229), not typed by hand." If that generation rule ever drifts from the actual vendored files, the check will catch it, but the provenance claim would become inaccurate.

---

_{Read: 3 files, +18 -10, the whole diff. Head 9c03e97. Model: openai-compatible/nvidia/nemotron-3-ultra-550b-a55b. Commands: @t27-bees review | summary | help | pause | resume. Free for every repository.}

[dmitrii-f-t27]

@gHashTag, two actions on this PR would unblock it (head 9c03e971f21e, 1 ahead / 5 behind main, read 2026-10-21):

1. Required check T27 work report fails on the PR body, not the code: the report job says PR body must contain exactly one <!-- t27-work-report --> … <!-- /t27-work-report --> block (job). Adding that block to the description re-runs the check.
2. checks (pure gates) / website gate fail on check:queen-fallback-parity: pages/Course.css:743 .course-shelf writes rgba(255, 255, 255, 0.12) while index.css:7 declares 0.08 (job). This PR does not touch that file; fix(website): the course shelf's border fallback says what --border says (pure gates green) #1700 (merged 8e535bc9bb9c) fixed it on main, so updating the branch from main should clear it. website gate failed only because pure gates failed.

After that the T27F graph build record (#1648) can be checked on the published site. I have no write access to this branch, so I did not push anything.

Dmitrii Fedorov (@dmitrii-f-t27)