v0.1.7: max_workspaces_per_sandbox — the second #216 control, blocked on pair 1 (#179)

[yifanxuaaa]

Current focus (owner direction, 2026-09-21)

Two cases are the optimization targets, and each is to be matched against
v0.1.6 rather than argued about from memory:

	case	family	route	timer	size	hops to the Store
1	namespace-10000	init_namespace	namespace	layerstack_init_ns	10,000 files / 300 MB + 100 MB anchor = 400 MB	direct, host-side
2	payload-create-100m	payload_create_read	workspace	pure_call_sum_ns	100 MB payload	container FUSE + daemon to the host service

Acceptance bar — APPROVED (owner, 2026-09-21). namespace-10000 must
(1) reproduce ≤ 578.245 ms (≥ 691.8 MB/s) with a declared cache contract and a
passing verification, (2) pair against the v0.1.6 reference arm — same seed,
fresh-output, topology, harness and image identity, same declared cache state — with
the candidate median ≤ the reference median, both with spread, and (3) be met by
one declared sample per arm, never by selecting the fastest of several runs. The
executing plan is
issue219-namespace-10000-plan.md.

Case naming. In init_namespace the number in the case id is a file count,

not megabytes**: namespace-{100,1000,10000,100000} at 100 files / 5 MB (+1 MB
anchor), 1,000 / 20 MB (+5 MB), 10,000 / 300 MB (+100 MB) and 100,000 / 500 MB
(+100 MB). There is no namespace-100mb case; the 100 MB is the anchor file
(NAMESPACE_ANCHOR_BYTES), which only the two largest tiers carry. Case 1 is
therefore the 10,000-file tier with the 100 MB anchor, and namespace-100000 is its
larger sibling with the same anchor.

Neither focus case has a baseline arm (per init_namespace case: 100 = 11
candidate / 3 baseline, 1,000 = 6 / 0, 10,000 = 8 / 0, 100,000 = 32 / 15;
payload_create_read = none at all), so both must produce their reference arm.
namespace-100000 is the substitute if a case with an existing pair is preferred.

Case 1 writes the namespace into the host-owned Store directly (the runner stages
it under payload/, and namespace/store-footprint are the routes that take no
payload/input staging and no daemon hop). Case 2 carries its payload from the
container through the daemon and the host service into the same Store
(LAYERFS_EXEC_TRANSPORT=daemon, LAYERFS_FUSE_TRANSPORT=daemon; the receipt's
scope line is "Linux daemon/FUSE container command window; host coordinator/Store
process CPU/RSS/IO reported separately"). Both end in one Store commit.

The namespace-init multi-worker count (4 = SMALL_CONTENT_WORKERS,
crates/layerfs-layerstack-store/src/objects.rs; 8 =
construction_worker_limit(), crates/layerfs-workspace/src/changes.rs) is
recorded and is not treated as the explanation for our slowness: it is the
cheapest thing to refute by measurement, and the RCA continues past it.

Exploration, pairing and gap-finding come first; no optimization is authorized by
this section. The prompt is
issue219-two-case-rca-prompt.md.

Status: Blocked; not implemented. Nothing in the product admits, counts or refuses Workspace creation today.

Why this exists

#216 defined two primary operator-facing concurrency controls. Its writer half — max_concurrent_writes_per_store — landed in #217 (merge 1f34ac939) and is measured and tested. The other half, max_workspaces_per_sandbox, could not be implemented there: there is no Workspace, sandbox or FUSE lifecycle component in this tree, because pair 1 (#179) owns it and is not merged. #216 was closed as completed by owner decision; this issue carries the remaining acceptance row so it is not lost.

The control, as defined in #216

Setting	max_workspaces_per_sandbox (proposed name)
Meaning	maximum live Workspace instances owned by one sandbox
Unit	a live instance, not a Branch, Commit or stored root. A frozen generation and its live successor are one instance
Enforcement owner	pair 1 sandbox/Workspace lifecycle
Reservation	capacity is checked and reserved before the instance becomes visible
Teardown	an incomplete teardown keeps counting until its resources are released
Aggregation	separate sandboxes have independent counts; this needs a trusted sandbox identity and an explicit rule if more than one caller can create Workspaces

Default, supported range, validation and configuration-change behavior are open and must be selected with the implementation. The previously discussed 16 was illustrative and is not an approved default. The writer control's own precedent is available: one persisted value, an explicit refusal at the bound, retained ownership that a lowering never releases, and a documented change path (Store::set_max_concurrent_writes).

Acceptance

• Exactly one operator-facing Workspace-count control is documented with scope, default, supported range, validation and configuration-change behavior; no hidden cap prevents the selected setting.
• Creation admits up to the limit, refuses the next without partial visibility, and releases capacity correctly on teardown; separate sandboxes have independent counts.
• A frozen generation and its live successor count once.
• Retained/incomplete-teardown instances keep counting and cannot be bypassed by changing the configuration.
• The writer control is unchanged by this work, and both controls are described together in one place.

Boundaries

Blocked on #179; do not invent a Workspace lifecycle here, and do not enforce the limit in a component that does not own creation. No new durability, no third-party patching, no aggregate gate.

[yifanxuaaa]

Handoff filed (merged as 705f1d961):
issue219-v016-gap-rca-handoff.md — five questions, five subagent squads with stop conditions, the binding measurement rules, and the findings from this session that must be cited rather than redone.

One thing to settle before the RCA runs: the 700 MB/s figure appears to be a millisecond column, not a rate. In docs/roadmap/0.1/0.1.4/issue91-campaign/terminal-r26/campaign/r26-report-repair/report/report.md (header line 236, rows 241–242):

| Test | Tier / files / bytes | Timer | Time (ms) | Exec / SDK / Commit (ms) | Host / container peak (MiB) | Previous (ms) | ... |
| payload-create-100m | 100 / 0 / 0 | pure_call_sum_ns | 662.003 | 282.778 / — / 361.895 | 54.61 / 12.02 | 682.771 | ... |
| payload-create-500m | 500 / 0 / 0 | pure_call_sum_ns | 2701.168 | 1215.713 / — / 1468.741 | 55.53 / 12.53 | 3068.250 | ... |

• 682.771 is the Previous (ms) cell: 0.683 s for a 100 MB payload → ~146 MiB/s. The 500 MB cell in the same column is 3068.250, which is exactly the v0.1.3 changelog row "Payload creation | Create 500 MiB payload | 3.068 s" (docs/releases/v0.1.3/CHANGELOG.md:119), which is what fixes the column's meaning.
• Current candidate receipts for the same family on the v0.1.6-era harness (benchmark-results/issue152/g5*, all source_arm=candidate, route=workspace, timer pure_call_sum_ns) are in the same band: 0.4389–0.7236 s for 100 MB, 2.1442–3.3690 s for 500 MB.
• No reference-arm receipt for this family was found anywhere in benchmark-results/, and benchmark-results/v016/ does not contain the family. Squad S1 is commissioned to locate the reference rows or prove their absence with the search recorded.

What the row does establish, and it is the useful part: Commit is 361.895 ms of the 662.003 ms for 100 MB and 1468.741 of 2701.168 ms for 500 MB — about 55% of the create path is the database commit, on a route that also runs FUSE in a container. That matches this session's store-path attribution (construct 617 MiB/s against save 165 MiB/s; deduplicating content stores 0.3 MiB and runs the save at 1778 MiB/s).

Scope note for this issue: the control this issue carries (max_workspaces_per_sandbox) is still unimplemented and blocked on #179. What the handoff commissions is separate evidence work — the Workspace/payload-create path against v0.1.6 — and it is tracked here because the Workspace route is this issue's subject. The store-path levers stay in #218.

If you have a different 700 MB/s source in mind, point me at the file and I will reconcile it exactly; the search above covers the committed evidence and the whole benchmark-results tree.

[yifanxuaaa]

Preliminary gap inventory (single agent, not S5-reviewed)

Starting S1's inventory produced seven gaps. They are recorded here so the squads start from them rather than rediscovering them; the inventory is not independent and S1 must still complete and S5 re-derive it.

1. The family has no baseline/reference arm at all. Across ~/Ephemeral-AI-Lab/layerfs/benchmark-results/, receipts tally candidate: 1614, baseline: 75, and the baseline arms cover only init_namespace, dedup_branch_history, tiny_file_churn, edit_length_preserving. payload_create_read has none. So no paired v0.1.6-vs-current comparison exists for the family the premise is about, and the r26 table's Previous (ms) column is not a substitute (different era, different arm definition).

2. Verification never ran for this family, and where it ran it failed. All 24 located payload-create* receipts carry verification_status: NOT_RUN in both the header and the summary record. And benchmark-results/issue152/g5/verify-payload-create-100m/failure.log reads:

fs-benchmark-pro failed: exit 1
fs-benchmark-pro: host continuation returned/published Commit mismatch
fs-benchmark-pro: selected Workspace operation failed

That is a correctness failure on the workspace continuation/commit path of that tree, not merely a missing check. Those create rows are performance-only, and their PASS is a protocol status. Triaging whether the mismatch reproduces on current source is S2's first job; quoting the rows as validated is not allowed until it does or does not.

3. Cache state is undeclared. Every one of the 24 receipts has cache_contract: null. Under AGENTS.md §1 a row whose cache state is undeclared is INCOMPLETE/INELIGIBLE for a cache-sensitive claim — and the commit cost these rows measure is exactly cache-sensitive.

4. Era mismatch. The 700 MB/s cell is v0.1.4-era (r26), and its Previous column traces to v0.1.3 (3068.250 ms = the v0.1.3 changelog's 3.068 s). Nothing in the chain is a v0.1.6 measurement.

5. No comparable phase split exists. r26 reports Exec / SDK / Commit; the receipts report only pure_call_sum_ns; this session's split (construct / accept / finish) is on the service+Store route with no Workspace or FUSE. So no artifact shows where the current product spends time on the workspace route — it has to be measured.

6. The comparison cannot be run against the current product as framed. There is no Workspace/FUSE path in the tree (pair 1, #179, unmerged). The nearest evidence is candidate rows on the same harness: 100 MB in 0.4389–0.7236 s (138–228 MiB/s), 500 MB in 2.1442–3.3690 s (148–233 MiB/s) — i.e. not slower than r26's previous column (~146 MiB/s) — but with a 1.65x spread across receipts and no in-window control, so even that ordering is not established.

7. Arithmetic residue in the rows being quoted. 662.003 − 282.778 − 361.895 = 17.330 ms (2.6%) unassigned on the 100 MB row; 2701.168 − 1215.713 − 1468.741 = 16.714 ms (0.6%) on 500 MB. Small, but it means "commit is 55%" is a floor and the row's three coarse phases cannot attribute the rest.

[yifanxuaaa]

Correction accepted — the figure is init_namespace, and here are its numbers

Merged as 1c3d45e39; the handoff now carries this as section 1b. Case sizes are from benchmark/fs-bench-pro/families/init_namespace/mod.rs; medians are from all 75 located init_namespace receipts under benchmark-results/**/perf.jsonl, converted with those byte counts.

case	files / logical / anchor	bytes	arm	medians (ms)	implied rate
namespace-100-compact-v3	100 / 5 MB / 1 MB	6 MB	baseline	19.318 / 19.854 / 23.847	252–311 MB/s
			candidate	9.352 / 9.771 / 10.105 / 11.409 / 19.663 / 19.792 / 20.300 / 22.689 / 28.704 / 31.667	190–642 MB/s
namespace-1000-compact-v3	1,000 / 20 MB / 5 MB	25 MB	candidate	39.891 / 40.458 / 41.252 / 88.213 / 112.733 / 130.367	192–627 MB/s
namespace-10000	10,000 / 300 MB / 100 MB	400 MB	candidate	402.721 / 407.598 / 578.245 / 928.022 / 1020.422 / 1100.711	363–993 MB/s (578.245 ms = 691.8 MB/s)
namespace-100000	100,000 / 500 MB / 100 MB	600 MB	baseline (PASS)	364.861 / 379.521 / 383.796 / 924.895 / 992.546 / 1036.158	579 MB/s–1.64 GB/s
			candidate (PASS)	279.165 / 291.630 / 291.948 / 361.444 / 386.761 / 402.517 / 2289.462 / 2734.598 / 2787.320 / 2850.586 / 7073.456 / 8578.672 / 105945.138	5.7 MB/s–2.15 GB/s
			both, *-cold-v2	2734–4986, TARGET_MISS	120–219 MB/s

Your recollection is right in order of magnitude for the 10k/100k tiers: 400 MB of namespace init in 578.245 ms is 691.8 MB/s, and the best 100k rows reach 604 MB/s–2.15 GB/s. The 2.7 s cold Init target in AGENTS.md §3.8 is 600 MB / 2.7 s ≈ 222 MB/s, which is exactly the band the -cold-v2 TARGET_MISS rows occupy.

The important consequence, and it changes the RCA's first target. init_namespace is the only family permitted multi-worker construction. So the two reproducible facts are both inside the current product, on the same Store and schema:

• namespace init (multi-worker exception): 0.36–2.15 GB/s on 400–600 MB of mixed small-file + 100 MB anchor payload;
• ordinary single-producer save path: ~115–165 MiB/s (this session: construct 617 MiB/s against save 165 MiB/s).

That is a 5–15x spread inside one product, and it is measurable today without pair 1, FUSE or a v0.1.6 rebuild. The handoff therefore leads with that spread rather than with a v0.1.6 pairing.

Gaps in the figure itself, recorded so it cannot be quoted bare:

1. All 75 receipts carry verification_status: NOT_RUN and cache_contract: null — no verification arm, cache state undeclared, so no single row supports a cache-sensitive claim.
2. The candidate 100k rows span 279 ms to 105.9 s (≈380x), with TARGET_MISS rows in both arms: a headline "700 MB/s" must name row, arm, cache state and setup identity, or it is a best-of.
3. The baseline arm's version is unpinned — the example row lives under host-store/issue118/20260912/infra-pair-1-baseline/ with a different image and product identity from the candidate rows, so "v0.1.6 was faster" is not yet supported by any of them. S1 must pin it or say it cannot.
4. Each case mixes a 100 MB anchor file with 10k/100k small files: one MB/s headline conflates a bandwidth workload with a cardinality workload, and the RCA must split them per phase.
5. namespace-100 is a 6 MB case with 9–32 ms medians, where timer resolution and the +1 MB anchor dominate — it cannot carry a bandwidth claim in either direction.

[yifanxuaaa]

Focus set: the two cases, and what the harness says about each

Merged as 063810fe5; the issue body now opens with this focus, and the prompt is issue219-two-case-rca-prompt.md.

Your model checks out, with two refinements:

	case	family	route	timer	size	path to the Store
1	namespace-100-compact-v3	init_namespace	namespace	layerstack_init_ns	100 files / 5 MB + 1 MB anchor = 6 MB	direct, host-side
2	payload-create-100m	payload_create_read	workspace	pure_call_sum_ns	100 MB	container FUSE + daemon -> host service

• Case 1 "directly into the DB" is right. In shared/runner.py, namespace and store-footprint are the routes that take no payload/input staging and no daemon hop; the runner stages them under payload/ and the workload builds the namespace into the host-owned Store. Timer layerstack_init_ns.
• Case 2 "daemon to host service and DB" is right. The workspace route sets LAYERFS_EXEC_TRANSPORT=daemon and LAYERFS_FUSE_TRANSPORT=daemon, and its receipt scope line reads "Linux daemon/FUSE container command window; host coordinator/Store process CPU/RSS/IO reported separately in records; host CPU is not container-capped". Timer pure_call_sum_ns.
• Refinement 1: they are not size- or mix-matched. 6 MB against 100 MB, and 100 small files plus a 1 MB anchor against one 100 MB blob. Any comparison has to say which of the two it is making; that is Q4 in the prompt.
• Refinement 2, and it shapes the plan: the pairing is asymmetric. Across benchmark-results, baseline arms exist for init_namespace (3 rows for namespace-100, many for 100k) and none for payload_create_read (tally: 1,614 candidate, 75 baseline, covering only init_namespace, dedup_branch_history, tiny_file_churn, edit_length_preserving). So case 1 can be paired from existing receipts while case 2 must produce the missing arm — and the prompt requires establishing what baseline actually selects before any pair is quoted, because the baseline and candidate images and product_identity values differ.

On the worker count: recorded as 4 (SMALL_CONTENT_WORKERS, crates/layerfs-layerstack-store/src/objects.rs) and 8 (construction_worker_limit(), crates/layerfs-workspace/src/changes.rs), and per your direction it is not treated as the explanation. It is kept as the cheapest one-difference refutation arm (Q3), and the RCA must name what does explain the gap if the measurement agrees with you.

Both families also share the same evidence gaps: every located receipt for each is verification_status: NOT_RUN with cache_contract: null, so no existing row can carry a cache-sensitive claim on its own.

[yifanxuaaa]

Case correction: namespace-10000, and what "100 MB" means

Merged as 74d2ef2c9; both the issue focus and the prompt are corrected.

In init_namespace the number in the case id is a file count, not megabytes. The eight registered ids are namespace-{100,1000,10000,100000} × {-compact-v3, -text-v1}:

id	files	logical	anchor	total
namespace-100-compact-v3	100	5 MB	1 MB	6 MB
namespace-1000-compact-v3	1,000	20 MB	5 MB	25 MB
namespace-10000	10,000	300 MB	100 MB	400 MB
namespace-100000	100,000	500 MB	100 MB	600 MB

So there is no namespace-100mb case. "100 MB" is the anchor file (NAMESPACE_ANCHOR_BYTES = 100_000_000), and only the two largest tiers carry it. Your case is therefore namespace-10000 — the 10,000-file tier with the 100 MB anchor — and namespace-100000 is its larger sibling with the same anchor. namespace-10000 is registered with route namespace, timer layerstack_init_ns, setup fresh-output, topology host-store, 2 container CPUs.

This changes the pairing plan, and not in a convenient direction: neither focus case has a baseline arm.

case	candidate rows	baseline rows
namespace-100-compact-v3	11	3
namespace-1000-compact-v3	6	0
namespace-10000	8	0
namespace-100000	32	15
payload-create-100m	24	0

So both focus cases must produce their reference arm before a paired answer exists. If you would rather pair against rows that already exist, namespace-100000 carries the same 100 MB anchor and has 15 baseline rows — say so and I will switch case 1 to it.

The measured standing of namespace-10000 (candidate only, 400 MB case size): 402.721 / 407.598 / 578.245 / 928.022 / 1020.422 / 1100.711 ms = 363–993 MB/s, with 578.245 ms at 691.8 MB/s — which is where the "700 MB/s" recollection comes from. Two rows are INCOMPLETE. The 100 MB anchor is what makes the case bandwidth-bearing at all, so the prompt now requires the anchor's share to be reported separately from the small-file count (Q4).

[yifanxuaaa]

Case fixed: namespace-10000. Bar proposed — your call

namespace-10000 is the case in the issue and in the prompt (no change needed; it was corrected in 74d2ef2c9). What was still missing is the bar, and the repository does not supply one, so I have written a proposed bar (section 1c of the prompt, merged 0b67cb23b) rather than leave "gap" undefined.

Why no bar exists today. The declared targets are times, and the case is already far inside them: 15 s reporting-only family target (shared/runner.py:39, PASS iff elapsed <= 15 s), the payload_create_read ordinary development target of 1–5 s, the strict tier-100 pure_call_sum_ns < 1 s assessment (#47), and the waived 2.7 s cold Init target — which applies to namespace-100000, not to namespace-10000.

Proposed bar, in two parts (not approved until you say so):

1. Reproducibility first. namespace-10000 must reproduce ≤ 578.245 ms (≥ 691.8 MB/s) on a run with a declared cache contract and a passing verification. Right now that row is cache_contract: null and verification_status: NOT_RUN, the six candidate medians span 402.721–1100.711 ms (median 753.13 ms ≈ 531 MB/s), and two rows are INCOMPLETE — so 691.8 MB/s is one unverified, cache-undeclared sample, not evidence. This step buys reproducibility and verification, not speed.
2. Then the pair. Same case on the v0.1.6 reference arm — same seed, fresh-output setup, topology, harness and image identity, same declared cache state — with the candidate median ≤ the reference median, both reported with spread. namespace-10000 has 8 candidate / 0 baseline rows, so producing that arm is part of meeting the bar; namespace-100000 (15 baseline rows, same 100 MB anchor) remains the substitute if you prefer to pair from existing receipts.
3. No best-of. One declared sample per arm at the declared cache state; every non-passing and INCOMPLETE row stays in the report.

payload-create-100m carries the same shape with its own numbers: 24 candidate rows spanning 0.4389–0.7236 s (138–228 MiB/s), no baseline arm, and the r26-era Previous (ms) 682.771 ms (~146 MiB/s) as the only reference-era figure — so its bar is the pairing plus a verification and cache declaration, not a number borrowed from another era.

Reply with approve (and I will mark section 1c approved and hand the worktree prompt to the agents), or tell me the bar you want instead — e.g. a straight rate bar on the reference's own numbers (namespace-10000 ≥ 993 MB/s = the reference's best recorded row, or ≥ 692 MB/s = the row behind your recollection).

[yifanxuaaa]

Bar approved, and the plan to match namespace-10000 is in

Merged as b0260df3a. The issue body now carries the approved bar, and the executing document is issue219-namespace-10000-plan.md (158 lines).

The approved bar, restated: (1) reproduce ≤ 578.245 ms (≥ 691.8 MB/s) with a declared cache contract and a passing verification; (2) pair against the v0.1.6 reference arm — same seed, fresh-output, topology, harness and image identity, same declared cache state — candidate median ≤ reference median, both with spread; (3) no best-of: one declared sample per arm, every INCOMPLETE row kept.

Plan shape — six gated stages, exploration before any change:

stage	owns	gate
S0 custody	receipt inventory, pairing feasibility, the two mechanics below	written decision on how a reference row can exist, with identities
S1 reproduce	candidate row with cache declared + a verify.sh arm	a verified, cache-declared row ≤ 578.245 ms, or a documented miss
S2 attribute	100 MB anchor vs 10,000 small files, phases, host vs container cost	every cell sourced or NOT_MEASURED, a mechanism not a correlation
S3 pair	reference arm beside the candidate	candidate median ≤ reference median, or a documented gap with its mechanism
S4 close	pre-registered treatments, one difference per arm (only if S3 shows a gap)	matched arms, unchanged results/refusals, a measured change
S5 verify/report	passing verification arm, receipts, LOC, gaps	every claim traceable to a receipt

Worktree: git worktree add ../layerfs-219-ns10000 -b codex/219-ns10000 origin/main, own Cargo target directory, per-worktree measurement lock. Subagents S0–S4 plus a read-only S5 reviewer that re-derives the arithmetic from raw files.

Two harness mechanics I found while writing it — both are traps the plan requires S0 to confirm:

1. --source-arm baseline selects nothing for this family's performance runs. infra.rs:499 parses and validates LAYERFS_BENCH_SOURCE_ARM, but the init_namespace performance branch calls namespace_init_diagnostic, whose signature (main.rs:2936–2944) takes no arm argument; the arm reaches only the verify path. So a "baseline" row produced by that flag on a current build would be mislabelled — it would run the same code as the candidate. A genuine reference row for this case can only come from a build of the reference product, which is consistent with the existing baseline rows carrying a different product_identity and image.
2. namespace-10000 has no cold contract. shared/cold.py:22–25 applies only when there is no sequence and family == "init_namespace" and case == "namespace-100000". So the bar's "declared cache contract" cannot be satisfied through that mechanism for this case: the run must declare its cache state another deterministic way, or be reported honestly as ordinary-OS-cache with no cold claim.

Stop conditions forbid manufacturing a reference row, claiming a cold row without the contract, raising worker counts/timeouts/cache size to pass, shrinking the workload, or modifying the reference crates as a fix.

Your call next: the plan is ready to hand to agents. Say go and I will dispatch it (worktree + S0/S1 first), or adjust any stage first — in particular whether S3 should build the v0.1.6 reference arm in-tree or reuse the existing baseline rows for a case that has them.

[yifanxuaaa]

S0/S1/S2 on namespace-10000 — the bar's figure is cache-credited, and the v0.1.6 arm is not a distinct product

Branch codex/219-ns10000 @ 4bc826e4d, worktree ../layerfs-219-ns10000, sealed at b0260df3a (LAYERFS_SOURCE_DIRTY=false). No product change. Nothing is closed. Evidence: docs/roadmap/0.1/0.1.7/evidence/issue219-{s0-custody,s1-reproduction,s2-attribution}-20260921T031259Z/.

S1 — reproduced, and it is a documented miss

	bar	measured
layerstack_init_ns	≤ 578.245 ms	944.881 ms (pseudorandom), 708.991 ms (-text-v1)

One sample per arm, fresh --output, both PASS, both verified separately in verification mode with identity-matched receipts (pass / cleanup pass / reopen pass / root pass-reopen-equality). Product seal b3e3cb7453…, compilation seal 9be9bc95…, image sha256:d152ced8d21c…, harness 8a6d76dd…, workload e29d728e….

Cache state is declared and it is not cold: cache_contract is null because shared/cold.py:22-25 gates the only cold contract on namespace-100000; the record-level declaration is reused-first-sample-uncontrolled, and the receipts confirm it — 0.73 MB read against 300 MB scanned. These rows are cache-credited and are not reported as cold.

Why 578.245 ms is not a reachable target for this build

The plan asked S0 to inventory the recorded rows. Doing that turned up two things the plan did not have:

1. The three fastest rows are SOURCE_DIRTY=true — including the 578.245 ms figure the bar names. A dirty source seal cannot be compared against a sealed arm.
2. Those same rows read 0.0 MB from storage while scanning 300 MB. The rows that show a plausible per-byte cost (≈1.1 MB read per MB scanned) are the slow ones (1020.422 ms / 337.4 MB, 1100.711 ms / 322.2 MB). CPU does not explain the split: the fast rows spend more CPU (1.6–1.8 s) than the slow ones (1.8–2.2 s).

The bar's row and this clean build also disagree on candidate_objects (54,463 vs 25,158 — 2.16× for the same 300 MB fixture), consistent with its dirty tree and with its commit 56fc884e differing from HEAD in 74 production files under crates/. So the 578.245 ms figure is a different product, measured on a dirty tree, with the cache uncontrolled.

S0 — the v0.1.6 reference arm cannot be built as a distinct arm

Both plan mechanics confirmed by reading the code: --source-arm baseline selects nothing on this family's performance path (namespace_init_diagnostic takes no arm argument, main.rs:2936-2944), so such a row would be mislabelled; and this case has no cold contract.

Beyond that, the pairing itself does not exist:

• git show v0.1.6:benchmark/fs-bench-pro/families/init_namespace/mod.rs is byte-identical to current, and so are src/main.rs, src/infra.rs, shared/{runner,runtime,cold}.py, perf.sh, verify.sh — the tag would even carry the same harness_identity.
• git diff --stat v0.1.6..HEAD -- 'crates/*/src/**' is empty. v0.1.6 and current main share 216 production files with zero content differences; HEAD adds only five examples/tests. The LAYERFS_PRODUCT_SEAL difference is entirely those test/example files.

A v0.1.6 arm would therefore be a second measurement of the same compiled product, reporting build noise as a v0.1.6-vs-current difference. The tree's genuine baseline rows are real reference arms — their commits differ from HEAD in 34–42 production files — but every one of them is cache_contract: null and a different image/harness, and none exists for namespace-10000.

S2 — the mechanism is store bytes, not traversal

The one controlled contrast inside one build is content compressibility at identical file count and bytes:

	pseudorandom	-text-v1
layerstack_init_ns	944.881 ms	708.991 ms
user + system CPU	1788.8 ms	1531.9 ms
system CPU	752.0 ms	381.6 ms
store_growth_bytes	304.7 MB	8.4 MB (36×)
admission transactions	73	73

Same file work (identical transaction geometry), 36× difference in bytes the Store must hold, and the delta is carried by system CPU while user CPU falls. The 100 MB anchor does not flow through the admission path — it is 24× larger than the largest single admission transaction (4.15 MB). The anchor's share of the timer and the per-file/per-byte split are marked NOT_MEASURED, with the treatments that would close them pre-registered (no registered case varies anchor size at fixed file count, or bytes at fixed file count).

Host, not container: 1788.8 ms process CPU (getrusage(RUSAGE_SELF), includes the init worker threads; CPU/wall 1.89×) against 12.0 ms of container command-window CPU.

Where this stops

Per the plan's stop conditions: the pair cannot be produced, and the reason is recorded. S3 is not satisfiable as written (its reference arm does not exist as a distinct product) and S4 is not entered — the plan forbids implementing an optimization before the gap is established, and no optimization was implemented.

Two rulings are needed before this case can carry a defensible pair, and neither is mine to make:

1. Which reference arm? A real reference must be a commit whose production source actually differs. If the intent is "v0.1.6-era behaviour", the honest arm is a v0.1.4-era commit such as f8bb6dcb (34 differing production files) — but that changes the arm the bar names.
2. What cache state? If the bar is meant to be a cold claim, namespace-10000 needs the cold contract extended to it (a harness change, which under benchmark/AGENTS.md needs rebuilt matched arms) — or the bar should be restated against the declared cache state the harness can actually enforce.

Everything above is traceable to a raw perf.jsonl / verification.json on disk; the S0 reader (inventory.py) and its full 55-row TSV are committed with the reports. No re-run was made to seek a passing number, and no historical receipt was retuned or relabelled.