# Size question for Jason: W1 and W2 history cost (Vikunja 618)

Written 2026-10-24 by Sage for Mos's mos-1572 and mos-1573. Rows 309 (W1, Glomgold) and 310 (W2, Gyro)
keep building and reviewing on their seat branches. Neither lands on refactor until Jason answers.

Status: complete for Mos, 06:20Z 10-24, with the 209-plus-14 measurement added at 06:39Z (mos-1574). Every number below is measured. W2's figures come from Gyro's
scratch measurement build (gyro-0013, 06:18Z), recorded in `agents/gyro/work/queue-310/BUILD.md` section
"Full-lock measurement results (sage-3992)" on gyro/row310 (pushed, tip 1716f5a22 at 06:32Z).

## Today's repository

`git count-objects -vH` in the canonical checkout, 05:55Z 10-24: size-pack 107.30 MiB, 137,187 objects in
5 packs, 119.26 MiB loose. Every number below adds to that, permanently. Git history isn't pruned here
(invariant 8, no force-push).

## W1, the WordNet thesaurus data (row 309)

- Generated data files: 21,916,660 bytes of text (Glomgold, glomgold-0004).
- Mos's figure for the row's text is about 58 MB, which includes the source data it is generated from.
- Changed text: 58,476,260 bytes across 45 paths (WordNet 3.1 source, generated JSON, generator, tests,
  evidence). No binary file.
- Packed size of the row: 17,480,317 bytes (about 16.7 MiB), from
  `git rev-list --objects d16958bcf..b10711603 | git pack-objects --stdout | wc -c` on glomgold/row309
  tip b1071160363d5d0204de96b06a356c9a04845287 (glomgold-0007, 05:56Z). That's about 16% on top of
  today's 107.30 MiB pack.
- Rebuild cost: the data is regenerated only when the WordNet source or the generator changes, so most
  W1 follow-up rows add little. A regeneration with a changed generator adds a new copy of each changed
  file, compressed against the old one where git's delta search finds it.

## W2, the WordCraft source and WASM build (row 310)

- Imported source, as of gyro-0007 05:47Z: upstream WordCraft 582 files, 21,021,869 bytes (30 icon,
  screenshot and macOS packaging files left out, no notice or license among them). Cargo vendor tree 209
  packages, 10,499 files, 130,737,230 bytes. Total 151,759,099 bytes.
- Non-text input files: 18 upstream (4,853,036 bytes) and 74 vendor (4,168,676 bytes). Fonts, test blobs,
  an MP4 and ICC profiles. No .a, .so, .dll, .wasm or .exe in the inputs. List:
  `agents/gyro/work/queue-310/binary-inputs.json` on gyro/row310.
- The packaging is still being settled. The 209-package vendor tree doesn't resolve against WordCraft's
  538-entry lock without build-copy manifest edits (target sections, dangling feature items, cfg
  evaluation; rulings sage-3976 to sage-3984g). At 05:58Z those edits hit their stop line (gyro-0011).
  Cargo refuses `glifo ^0.2.0`, locked at 0.2.0, which an optional normal dependency of the reviewed
  vello_cpu 0.1.0 requires. Only glifo 0.3.0 is in the 209, and no cfg section controls that edge. The
  edits so far cover 28 manifests, 121 target-dependency sections and 109 dangling feature items, all in
  scratch.
- The full-lock alternative: WordCraft's lock has 538 third-party records, 534 from crates.io and 4 from
  git. Louie's existing toolchain cache holds all 534 .crate archives, 85,234,501 bytes compressed
  (`agents/gyro/work/queue-310/full-lock-cache-size.json`). The 209 reviewed packages are 130,737,230
  bytes extracted. Extracted in scratch from that cache (gyro-0012, 06:06Z), the full lock is
  614,049,226 bytes in 25,378 files, including generated checksum files. That's 329 packages beyond the
  reviewed 209 (328 from crates.io, 1 from git), and about 4.7 times the 209-package tree. Every extra
  package would also need a source and notice review against S0. My read: the full lock is the wrong
  trade for a few hundred MB of permanent history, so the choice is between one more kind of build-copy
  edit for the 209 (optional dependencies no wasm32 feature turns on) and keeping the vendor tree off
  refactor altogether.
- (a) History per rebuild if the WASM stays committed: 16,720,159 bytes (about 15.9 MiB) packed. The
  release build writes four files, 44,142,800 bytes raw: WASM 43,957,877, JS 164,941, HTML 1,604 and an
  icon 18,378. Gyro wrote those four blobs into a scratch bare repository (git 2.55.0, `hash-object -w`,
  then `pack-objects --stdout --threads 4`, no gc) and measured the pack. Receipts:
  `measurement-output-pack.json` and `full-lock-release-measurement.json` in Gyro's packet. Each later
  rebuild that changes the WASM adds roughly that much again, because compiled WASM deltas badly
  against the previous build. Ten rebuilds would be about 160 MiB, more than today's whole pack.
- (b) Could the release build make the WASM itself, so only source is committed? Facts so far:
  - `scripts/stack-copy.sh` builds nothing from source. It `git archive`s COPY_PATHS (:29-41, :72) and
    runs `npm ci --no-audit --no-fund` in the copy (:74), which needs the npm registry. So a release copy
    is already not offline today.
  - The pinned toolchain is Rust/Cargo 1.99.1 with the wasm32-unknown-unknown target, Trunk 0.22.0,
    wasm-bindgen 0.2.129 and wasm-opt 131 (W2 brief, S0). This host's PATH has Arch's rustc and cargo
    1.98.0 (not the pin), no rustup, and no trunk, wasm-bindgen or wasm-opt. A release host would need
    all five pinned and hash-checked. That's an install row of its own, and it touches infra on .53/.54,
    which is Jason's.
  - Build time: 172 to 393 s per release build in Louie's and S0's baseline runs. Gyro's offline
    release build took 397.9 s from a fresh target directory at nice 19, 4 CPUs, 4 Cargo jobs and 4
    Binaryen cores. A first attempt (388.8 s) started at nice 15, inherited from the harness, so it
    doesn't count. That's about 6.6 minutes per activation on this host, if the release builds it.
  - No network: the build ran in an isolated network namespace with no external interface, Cargo and
    Trunk set offline and update checks off, and exit 0. Nothing was fetched or installed. It used the
    full-lock vendor set extracted in scratch, not the 209-package tree, so it proves an offline build
    from vendored source works, not that the 209 alone suffice.
  - Gyro also saw that the resolver used 14 packages outside the compiled closure (14,523,104 bytes,
    `measurement-resolution-extra-packages.json`). That suggests a vendor set near 209 plus those 14
    might resolve without the manifest edits. Nobody has tried it. This timing isn't restricted-adapter
    or CSP evidence (M1 to M14).
  - Precedent: row 154's editor bundle commits the built `packages/webui/src/public/editor.js`
    (758,420 bytes of text) next to its third_party source, and `editor-provenance.test.mjs` rebuilds it
    with the pinned esbuild on the landing gate (`MOSAIC_REQUIRE_EDITOR_BUILD=1`). W2 committing its WASM
    and proving a rebuild on the gate follows that pattern. Building in stack-release.sh would be new.

## The 209-plus-14 option, measured (mos-1574)

Mos asked for this option to be measured before Jason chooses. Everything ran in scratch and nothing is
on refactor. Gyro's packet: gyro/row310 tip 1716f5a22, `agents/gyro/work/queue-310/BUILD.md` section
"223-source measurement" (line 498).

- Size: the 223 packages are 11,201 files, 145,260,334 bytes raw, 26,538,894 bytes packed. The 14 extras
  alone are 702 files, 14,523,104 bytes raw, 1,720,566 bytes packed. Compare the full lock at 614 MB.
- Resolution: the existing build-copy filter script, unchanged, gives 31 changed manifests. With it,
  cargo resolves offline only after writing its own lock. Against WordCraft's pinned lock (558 entries,
  sha256 06b745e4...) that lock removes 332 entries and adds or changes none (name, version, source,
  checksum), so it's a strict subset. The pinned lock itself is untouched.
- Build: it builds. Gyro's offline release build with the pruned lock under --frozen/--locked exited 0
  in 380.7 s (gyro-0018, 06:38Z), with the same settings as the full-lock run (nice 19, 4 jobs, isolated
  netns, fresh directories, no retry used). S0's root closures matched before compiling: 214 normal and
  224 normal plus build, including 15 local. Outputs: WASM 43,952,335 bytes, JS 164,941, HTML 1,604,
  icon 18,378 (`measurement-223-build.json`). The WASM is 5,542 bytes smaller than the full-lock build's
  and its sha256 differs (0322beb9... against c1c15050...). The two builds had different vendor sets, so
  this proves nothing either way about reproducibility. A repeat build of one input set would.
- Source and notice review of the 14 (Gladstone, Codex, gladstone-0026, 06:37Z, not a verdict): all 14
  archives match the pinned lock's checksums byte for byte, and the extract matches the archives except
  three filtered Cargo.toml files. 10 pass. 4 have notice concerns to settle before adoption:
  - cursor-icon 1.2.0 and winit 0.30.13 apply W3C license terms inside source files (src/lib.rs,
    src/keyboard.rs), which the filename-based notice collector missed. They need adding to M13.
  - dpi 0.1.2 is "Apache-2.0 AND MIT", not an expression on S0's list. Both texts must stay.
  - spirv 0.4.0 declares Apache-2.0 but its archive has no license text, so the standard text has to be
    supplied under M13.
  - winit also carries four example PNGs (under 3 KB each) and a Web Worker path. Neither is in the
    measured build's closure, but the binary inventory must list the PNGs and the Worker source isn't
    cleared for runtime use.
- Notice follow-up (gyro-0019 at 9522d2356, Gladstone's recheck gladstone-0027, 06:44Z): the four gaps
  are now collected as evidence. The W3C terms for cursor-icon and winit are in the notice bundle with
  their source hashes, both dpi texts and the libm headers stay, spirv maps WordCraft's pinned
  LICENSE-APACHE text explicitly, and winit's four PNGs are inventoried. Gladstone found no further
  gaps. What stays open is policy: the W3C form isn't among S0's accepted licenses, and the PNGs and
  the Worker source need explicit classification if adopted.
- What adopting it would mean: commit a cargo-pruned lock in place of WordCraft's (a packaging change
  for S0's reviewer), the 14 packages' source, the collected notices, and an owner decision on the W3C
  license form.

## What Jason is asked

1. Whether the roughly 260 MB of raw text and source (W1 plus W2's inputs) goes into permanent history,
   given the packed numbers above. For W2 that now includes which vendor tree: the 209 reviewed
   packages with build-copy manifest edits (blocked at glifo, would need a further kind of edit), the
   209 plus the 14 the resolver needed (measured above: 145 MB raw, 26.5 MB packed, a pruned lock and
   four notice fixes), or the full 538-record lock (614 MB extracted, 329 more packages to review). I
   recommend 209 plus 14.
2. For W2's output, one of: commit the WASM and rebuild-check it on the landing gate (the row 154
   pattern, adding (a) per rebuild), or build it during release (needs the toolchain on every release
   host, adds the build time per activation, and stack-copy.sh changes).
3. Option C from sage-3978 (Git LFS or an off-tree artifact store) stays open if neither cost is
   acceptable.