---
name: quoted-measurement-decays-when-you-mutate-the-subject
description: "A size/state figure you quoted in an OFFER goes stale when your own subsequent work mutates the subject — re-measure at the moment of the act, not the moment of the offer; measured 2026-08-04, a pool I quoted at 5.94 GB was 10.04 GB by teardown because my own verification legs grew it."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 87b58026-d20f-461b-ab3f-9060ba59aff3
  modified: 2026-08-04T17:17:39.035Z
---

**The class:** you measure something, quote the number to someone as part of an offer ("I can reap this 5.94 GB pool"), then do work that CHANGES the thing you measured, then act on the offer using the number from before. The staleness is self-inflicted and lands between the quote and the act.

**Measured 2026-08-04 (er-seams pool, hertz).** I classified the lane pool at 5.94 GB / 8749 files and told doyle that figure while offering the teardown. Then I ran the `ab48676` fixup verification: a `-D warnings` check leg and a nextest codegen build. At teardown the pool was **10.037 GB / 19016 files** — my own verification had grown it ~4.1 GB after I quoted the size. I caught it only because the teardown discipline *forces* a fresh before-measurement; the offer's number would otherwise have gone into the record and into doyle's box-capacity arithmetic, where he was working a >80 GB floor and 4 GB is a real error.

**Why it is easy to miss:** the number was correct when taken, and nothing about doing normal verification work announces "you have invalidated a figure you are holding." Unlike a stale *instruction*, which at least has a condition you can go re-read, a stale *measurement* has no condition — it is just a number that was true once, and it reads as a fact rather than as a snapshot. The more careful you are about measuring before offering, the more likely you are to be carrying one.

**Cheap correction fact worth its own line:** changing `RUSTFLAGS` (e.g. adding `-D warnings`) invalidates EVERY fingerprint in the pool and forces a full rebuild of all deps — that is where most of my 4.1 GB came from. Corollary that saved the next leg: run subsequent legs under the SAME `RUSTFLAGS` and they reuse the cache (my `mock-adapter` build finished in 1.98s doing exactly this). Deliberate flag changes are a real disk cost, not just a time cost.

**How to apply:**
- Re-measure at the moment of the ACT, never carry the offer's number into it. The teardown discipline already mandates before/after — the lesson is that "before" means *now*, not *when you first looked*.
- When the corrected number reaches the person who holds the old one, **lead with the correction and say the old figure is dead** ("do not carry the 5.94 anywhere"), rather than quietly reporting the new one and letting two numbers circulate. doyle named this the report he wants.
- Ask, before quoting any figure in an offer: *is anything I am about to do going to change this?* If yes, quote it as provisional or quote it after.
- Report the SUBTREE size as the claim and the free-space delta as corroboration — they will not match (mine: 10.037 GB subtree vs +9.238 GB free delta) and averaging them invents a third number that is nobody's measurement.

Kin: [[stale-carried-forward-sentence]] (same decay, but of an instruction and usually from an EXTERNAL change — this one you cause yourself), [[confirmation-without-postop-sha]], [[verify-the-subject-not-just-the-measurement]], [[measure-what-costs-one-command]].