Skip to content

Session handover — 2026-07-18 pt2

The corpus went from "vehicle built" to running. Two owner's calls opened the session (corpus proceeds WITHOUT the Wix-key widening; EC2 port first); the EC2 port then landed in one slice (positive control 87.3 vs the 87.2 deployed baseline, same sole veto); Cathal's wixbuilds.csv pick was probed and merged (42 corpus hosts); and the 42-site corpus run launched on EC2 ~14:20 — in flight overnight at close, ETA 12–16 h. Mobile surfaced as a question and was banked with a trigger, not scoped.

Where to look

  • scope-2026-07-18-cms-batch-runner — criterion (e) CLOSED with the EC2 numbers; new EC2 runbook section (box facts, bundle-sync mechanics, the NODE_OPTIONS=--max-old-space-size=2560 requirement, the stale-crawl trap, the detached launch command, measured wall-clocks).
  • known-issues — Slice 6 entry gains the two owner's-call amendments (videoDebt reads as "shortfall, cause UNATTRIBUTED" until the key is widened; EC2 port complete — only the run itself remained at close). NEW entry: mobile is unmeasured on both sides — Wix mobile is a separately authored view, so the fidelity target itself is undefined; 10-site live-mobile-vs-live-desktop divergence probe + Cathal's build-practice answer are the reopen trigger. No new dimension before corpus evidence.
  • calibration/corpus-hosts.txt — 42 sites (3 reference/blind + 39 from the pick). Exclusions with reasons + the pick tally live in its comments.
  • Commits: 9aa84b9 (EC2 port + owner's calls), 1ac1965 (corpus hosts), 77668a5 (mobile entry), plus this handover.

What shipped

  • EC2 port (the slice). Incremental git-bundle sync (a500dab..bfd407f; the box's May-era dirty tree is preserved on branch rescue/pre-0718-sync — verified no unpushed commits first); .dev.vars by scp; npm ci + Playwright Chromium. One real incident, as scoped in risks: the apps/cms astro build SIGABRTs (134) at Node's default ~1 GB heap cap on the 2 GB box — fixed with NODE_OPTIONS=--max-old-space-size=2560 + a 4 G swapfile; the loud-fail machinery captured the full stderr tail in the batch report exactly as designed. Control re-run: S 82.3 / T 100 / G_det 84.4 → 87.3 HOLD(videoDebt) vs Windows 82.1/100/84.4 → 87.2. batch-scorecard consumed it on EC2 (the two blind sites loud-skip there — their artifacts live on the Windows box only). Regression check: N/A — no shared canonical surface touched; the runner itself was not modified.
  • Corpus picks probed before committing the night to them. 41 sites from wixbuilds.csv: all normalized, zero first-label collisions, zero redirect drift, 39× 200+Wix-markers. Excluded dead-at-source (no live render → zero calibration signal): sinnotts.com (TLS cert expired) and asesoria-consulting.ie (Wix-served 404 on www AND apex) — both are broken for real visitors today; worth flagging to the clients. Pick tally (the handover ask): e-commerce 0/41, booking 1/41 (svco.ie) — Woo-lane prevalence in this pool is nil.
  • The 42-site corpus run, launched. Detached on EC2 (~/corpus-run-0718.log, EXIT: is the completion marker), sequential, resumable from artifacts if it dies. Startup verified healthy (WCP skipped its fresh artifacts, rebuilt, seeded local D1). Check: ssh cathals-demo 'tail -5 ~/corpus-run-0718.log; grep -c "=====" ~/corpus-run-0718.log'
  • Disk sized before launch: WCP's 972 M decomposes to ~260 M of CMS-lane artifacts + 712 M of demoted static-lane residue — the run fits in the 22 G free with reserves (~/.npm 3.8 G, ~/replatform 2.9 G reclaimable).

The honest parts

  • The corpus outcome is unknown at close — the run was ~1 site in when the session ended. Per-site failures are corpus data (capture robustness), not slice failure; the mesh-generation count among them is the segmentation gap's reopen number.
  • Every site pays ~3 min of cms-build (the baked seed is per-site; no artifact skip possible) — that's most of the sequential wall-clock.
  • EC2 is at 1ac1965 — two wiki commits behind local; harmless (the runner reads none of them); the next bundle-sync picks them up.
  • The 18 legacy pre-crawled sites on the box are not in the corpus (not picked); if ever added, the presence-only crawl skip rule makes their May-era artifacts a stale-crawl trap — --force crawl,theme (runbook).
  • The corpus is deliberately light: --slides off (carousel heroes render poster-only on our side — instrument config, not site debt), desktop-viewport only, no video acquisition. Read scores accordingly; label from what the instrument sees.

Next

  1. Morning: check EXIT: in ~/corpus-run-0718.log → node scripts/batch-scorecard.mjs calibration/corpus-hosts.txt on EC2 → skim builds/cms-batch-report.json failures (count 0-section mesh sites — the segmentation gap's prevalence number).
  2. Cathal labels ship / needs-polish / hold per site (the human half of Slice 6). Desktop-only instrument — note mobile-only concerns separately, don't fold them into the labels.
  3. fit-calibration → review the candidate → promote only if fitted:true and precision holds (the CLI refuses to overwrite calibration.json by design).
  4. Fix from the aggregated ranked list — inline-left's trigger already fired (salttherapysolutions); mesh gap ranks by its measured prevalence; videoDebt rows stay unattributed until the key question reopens.
  5. Watch emdash #1158 for an upstream response (save race — product blocker per ADR-0013 §4).
  6. Post-corpus: the mobile divergence probe (known-issues trigger) + Cathal's build-practice answer (did the team author Wix mobile views?).