[gHashTag]

Closes #10860. Part of epic #10863. Stacked on #10874 (t27b watch); retargets to master after it lands.

t27b build writes <out>.build next to the object and skips the next build when nothing that feeds the object changed. --force builds anyway.

Where the decisions live

• specs/tri/t27b/build_record.t27 (new): which parts a native object has (root spec, use closure, the t27b binary, the byte-changing flags), the reason words, --force, rewrite only on different bytes, write a record only after a successful build. The reuse rule itself is specs/verified/reuse.t27 through use: MISSING never counts as SAME, the reason is the first part that differs. 8/8 tests under t27c test-report, 0 vacuous.
• gen/rust/tri/t27b/build_record.rs: t27c gen-rust output (sha256 697e3671...35c4).
• cli/t27b/src/main.rs: thin glue. The record is sha256sum format (# lines for the head and flags), hashed and checked by the system sha256 tool (sha256sum, else shasum -a 256). cmd_build and watch leave the object untouched when the new bytes are identical, so a hot-reloading app does not restart on a comment edit. This PR's own diff in the file is 40 added / 41 removed: four multi-line arg parsers became one-liners and ten comment lines that restated specs/tri/t27b/usage.t27 were dropped.
• specs/tri/t27b/usage.t27 + gen/rust/tri/t27b/usage.rs: --force in t27b help.
• docs/reports/t27b_expectations.json: build_record.t27 listed for the ratchet.

Measured on the Railway lab

t27b build specs/tri/t27b/watch_build.t27 -o /tmp/br/wb.o --elf --time:

• first build: no-record, record of 16 lines (head, flags, 13 closure files, the binary);
• second identical build: reuse, 17 ms wall, no front end run;
• --macho then --elf: flags-changed both times;
• comment appended to the spec: spec-changed, rebuilt, object sha256 5f6cb42f...325c unchanged and its mtime unchanged (0 rewrites);
• edit to a closure member (specs/verified/reuse.t27): closure-changed;
• --force: forced.

🤖 Generated with Claude Code