Read the mosquito bundle's renamed effort field (unblocks the weekly refresh)

[tgilbert14]

The incident

Scheduled refresh 31298345511 (2026‑08‑09) failed in rebuild with:

ABBY mosquito effort table lacks required field(s): trap_nights

validate-artifacts and publish skipped, so no artifact byte was written. Canonical SHA‑256 remain cascade 47b98e48… / search a11a072d… / meta 00120c52…, and both live surfaces stayed up on the last good family. The fail-closed guard did its job.

Not related to the cover release — docs/ is outside the build surface.

Root cause

The Mosquito release merged upstream as fdb9aa1 (2026‑08‑05) rebuilt every site bundle under R/mos_bundle_contract.R, whose effort_week now emits effort_days, opportunities, and zero_catches — no trap_nights. Every mosquito site has the new schema; ABBY is just alphabetically first. Timeline fits exactly: 08‑02 refresh succeeded on old bundles → release merged 08‑05 → 08‑09 refresh failed.

This is not a pure rename

	old	new
column	trap_nights	effort_days
value	ifelse(trapHours > 0, trapHours/24, 0)	ifelse(valid_effort, trapHours/24, 0)
population	every trap row	only occurred & duration_ok & identity_ok

Same unit, QC-screened population. The refreshed denominator can only shrink, so mosq_activity (catch ÷ trap-nights) can only rise, on site-years that contained unusable deployments. Mosquito rows are descriptive context and enter no pooled vote, so no inferential claim changes — but published descriptive values will move, which is why the delta preview below exists.

What this PR changes (source only)

• cascade_mosq_effort_field() resolves whichever field the bundle publishes, preferring effort_days exactly as the producing app does; fails closed when neither exists, and refuses a bundle set that mixes bases.
• cascade_mosq_effort_note() appends the QC-screened sentence to the published mosq_trap_nights codebook entry only when the build actually read effort_days — so the caveat travels with the number, and the byte gate stays meaningful under pinned siblings.
• The independent recomputation in test_helpers.R resolves the same two names literally rather than calling the build helper, keeping that adversarial check independent.
• Report-only scripts/report_mosq_effort_delta.R, wired into the refresh job summary, plus a publish dispatch input (default true) that can only ever narrow publication — so a dry run shows the value deltas before anything reaches master.

Expected CI state — please read before judging the red

data/cascade_meta.rds records build_script_md5 and source_adapters_md5, so editing the builder or the adapters necessarily changes the regenerated meta. The exact-reproduction gate is expected to fail on this source head.

Under CI's pinned siblings the adapter falls back to trap_nights, so cascade.rds, search_index.rds and the codebook text should be byte-identical and only those two recorded hashes should move. Please confirm that from the run log before promoting.

Next step (needs R — I don't have it in this container)

1. Rscript --vanilla scripts/rebuild_all.R with the seven sibling clones present.
2. Confirm only the two build-code hashes moved under pinned siblings.
3. Commit the regenerated family as a direct child of this head, merge.
4. Dispatch refresh-data.yml with publish=false and read the mosquito delta report before letting a scheduled run publish.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CP23xFrMeWj7PS4i19aH7Q

---

Generated by Claude Code

[tgilbert14]

CI blocker — not fixable from a source-only change

rebuild-contracts failed on c838b9e4 (run 31318332872), and the PR description named the wrong gate. Correcting that here.

It failed at the first step, Validate committed snapshot and extract immutable source lock:

Error: cascade.rds build-logic lineage differs from the running source; run scripts/rebuild_all.R.

That is global.R's boot-integrity guard comparing the artifact's recorded build_script_md5 / source_adapters_md5 against the running files. It fires on source("global.R") — long before the git diff --exit-code byte gate I predicted. Right about why (editing the builder or adapters changes the recorded lineage), wrong about where.

Consequence for reviewing this PR: every later step skipped — sibling fetch, rebuild, byte gate, manifest compare. So this run produced no evidence about whether any value moves. My expectation that only the two hashes move under pinned siblings is still just a code-reading claim; treat it as unverified until a regeneration says otherwise.

Why I am not pushing a fix

The guard is fail-closed by design and there is no source-only way past it — the artifact family has to be regenerated. That needs Rscript --vanilla scripts/rebuild_all.R, and this agent container has no R. Installing one here would build against an unpinned toolchain, violating the R 4.5.2 / Haswell / one-thread / 2026-07-15-snapshot contract and producing artifacts that could not reproduce deterministically. Weakening or bypassing the guard to get a green check would defeat exactly the mechanism that kept last night's bad build from publishing. So this stops here rather than manufacturing a pass.

To unblock

1. Rscript --vanilla scripts/rebuild_all.R with the seven sibling clones present, on the pinned toolchain.
2. Confirm from that run whether anything beyond build_script_md5 / source_adapters_md5 moved. Under pinned siblings the adapter falls back to trap_nights and cascade_mosq_effort_note() returns the identical sentence, so cascade/search/codebook bytes are expected unchanged — please verify rather than assume.
3. Commit the regenerated family as a direct child of this head; CI should then pass exact-head.
4. After merge, dispatch refresh-data.yml with publish=false to read the mosquito delta report against fresh siblings before any scheduled run publishes.

The weekly refresh stays red until step 3 lands. Nothing is at risk in the meantime: the live app and Pages continue serving the last good family, and the failed refresh wrote no bytes.

---

Generated by Claude Code

[tgilbert14]

I tried the regeneration here. It doesn't hold up — reverted.

Correcting my earlier comment: I said this container couldn't regenerate the family because it had no R. It turned out to be the same OS as CI (Ubuntu 24.04.4 noble), so I installed the pinned contract — R 4.5.2 from Posit r-builds, OpenBLAS 0.3.26 Haswell/one-thread, the closure installed with pak from the 2026-07-15 snapshot — cloned the seven siblings at the commits in the artifact's own source lock, and ran scripts/rebuild_all.R. All 9/9 stages passed and promoted (467a400), and I re-registered the eight canonical-hash registries (0e4a3f9).

CI then failed at the byte gate, and it was right to. 33d0e50 backs both commits out.

The decisive test

rebuild-contracts reported all three RDS differing while data/neon-cascade-codebook.csv — plain text — matched exactly. That's an encoding signature, not a content one. So I rebuilt unmodified master 0f61ee63 in a clean worktree here, with the same pinned siblings, and diffed against its own committed artifacts:

NOT REPRODUCED — container is not byte-compatible with CI

The delta is environmental and pre-existing, nothing to do with the mosquito change. Comparing CI's cascade.rds against this container's rebuild of identical code:

identical content: TRUE
CI-built: 110113 bytes    container: 110122 bytes

Byte-identical content, a ~9-byte difference in the compressed stream. saveRDS uses default compression (build_cascade.R:1250); sweeping gzip/xz/bzip2 at levels 1–9 reproduced neither CI's size nor its bytes. It's a zlib/runtime-level deflate difference that can't be dialled in from R. The hashes in my two previous handoff entries are withdrawn — they came from a non-conforming builder and must not be registered anywhere.

What the exercise did prove

The adapter change is correct. Under the pinned siblings the full contract suite passed here, including mosquito index matches effort-calendar source recomputation at 416 site-years and mosquito effort-only zero-catch years remain explicit zeroes. Every scientific component compared byte-identical at the content level, and the codebook regenerated byte-identical — independently confirming cascade_mosq_effort_note() held the base sentence on the trap_nights path. Those are content facts and don't depend on the byte environment.

The real blocker is a process gap, and it's your call

A build-code change necessarily changes the recorded lineage, so rebuild-contracts cannot go green on a source-only head. The artifacts must come from a byte-conforming builder, and the eight registries then re-registered to whatever that builder emits. Today there's no in-CI path that produces and commits such a family from a PR branch — refresh-data.yml builds on ubuntu-24.04 and would be byte-correct, but its gate and publisher are restricted to master.

Three options:

1. Regenerate on your pinned machine and commit the family plus registry updates as a direct child of this head. This is the documented entry point in AGENTS.md.
2. Merge with rebuild-contracts knowingly red, then run refresh-data.yml on master to produce a conforming family — following it immediately with the registry update, since the registries will be stale the moment it publishes.
3. Add a PR-scoped regeneration workflow that uploads a CI-built family for promotion. The durable fix, and it removes this trap for every future build-code change.

I'd suggest (1) now to unblock the weekly refresh, and (3) when there's time.

Nothing is degraded meanwhile: the failed refresh wrote no bytes, the canonical family is untouched, and both live surfaces serve it normally.

---

Generated by Claude Code