Bisect the packaging-cost threshold between 2 and 4 MiB

[TBarregren]

The question

Per-part packaging cost grows about twice as fast as the part up to 2 MiB, and then jumps roughly 26× somewhere between 2 and 4 MiB. Where that discontinuity sits, and what causes it, is unidentified.

php://temp, whose 2 MB spill threshold would have fit the shape elegantly, was removed by plan 006 and is structurally absent from the code. Nothing else has been tested.

Method, cost and instrumentation are already established: one controlled single-file extraction per point, about ten minutes each, exactly as run in docs/measurements/2026-08-19-chunk-size-curve.md. Two or three points bisect it.

Why this is ready-for-human rather than agent work

It cannot be settled from a laptop. Nothing on a local NVMe reproduces the cost — the same code path is roughly three orders of magnitude cheaper there — so it needs a real managed host, and the only host with a measured baseline is a live client site. Never touch that site without being asked. Choosing where to run this, and getting consent for it, is an operator decision.

Method notes that cost this project time to learn

• Vary one thing. The first 4 MiB reading was confounded: it came from mid-clone against a container already a gigabyte long, while every other figure came from a fresh one, so part size and container state moved together. A fresh single-file control is what separated them, and the wrong conclusion was published before the confound was caught.
• Read the part count, not the config, to confirm a setting is actually live. A 36 MB file yields 139 parts at 256 KB and 9 at 4 MiB.
• Run an independent sampler alongside the job — GET /extractions/{id} every 30 s into a CSV and the full body into JSONL. Both diagnoses in this project came from such a series, and neither could have come from the client's own poller, which returns one terminal verdict and no history. The attempts array is bounded at eight entries, so it is only informative when captured continuously. Preserved scripts: ~/Clients/SafeTeam/preserved-20260818/.
• Bound the watcher and treat a purged job as terminal, or it polls forever once consume deletes the record and the poll starts 404-ing.

What an answer here does and does not unlock

It informs the shipped default and the per-run parameter. It does not discharge rule R1. R1 is gated on attributing the per-chunk cost of ordinary small files (#30), which is a different measurement, and the adaptation family stays frozen until that one lands.

Blocked by

An operator decision about which host to measure on.

[TBarregren]

This was generated by AI during triage.

Triage outcome: deliberately deferred, stays ready-for-human

No measurement is being scheduled now. The maintainer's decision, in their words: 3.5 hours for a full clone is acceptable for the time being, so that a stable and working release can go out — and the ~229 ms is worth digging into after that.

So this is not wontfix. It is intended work with no date, and the reason it cannot be ready-for-agent is unchanged and unfixable by grilling: it needs a run on a real managed host. Nothing on a local NVMe reproduces the cost, where the same code path is roughly three orders of magnitude cheaper. The host decision is an operator decision, and the only host with a measured baseline is a live client site that must never be touched unasked.

What was decided about the blocker

The option weighed at triage was a dedicated scratch site at the same provider, on the same PHP version and the same LiteSpeed setup — representative, and without going near the client site. That option stands and is what to reach for when this is picked up. It was not taken now, and only because a release comes first.

What did change

#39 was split out of #30 and is ready-for-agent: per-phase timing inside a packaging tick, gated behind a Config knob and off by default. That is pure code with no host dependency, and #30 said itself that the work is "instrumentation work first, then a run on a real host". Landing it makes the eventual measurement cheap instead of blocked — when someone does get a host, the build can already answer the question.

#39 is sequenced after the release, since it adds a debug surface and the immediate goal is a stable tag carrying #27's 256 KB default.

Rule R1 is untouched

R1 still holds the adaptation family shut — host-limit raising, budget halving, the attempt counter, the floor — until #30 is answered. That was considered and deliberately left alone: the gate exists so that three budgets, a counter, a floor and a halving rule chosen blind do not get a fourth sibling on a guess, and the maintainer intends to answer the question rather than abandon it. Rewriting the gate would only make sense if the measurement were never going to happen.

Any issue proposing adaptation work should still say it is blocked by #30.