🤖 from Claude (filed at espg's direction, from the PR #28 review discussion, 2026-07-31)
Deferred surface
PR #28 refuses window="all" (the reserved all-time token) rather than half-exposing the all-time folds — correctly, because the old path produced an incoherent tree: overview orders opened the all.zarr cross-window folds while the source order emptied (a windowed store has no all-time source leaf — the fold is of the windows, not a written leaf). This issue is the legitimate opt-in surface, deliberately not a window label.
Gating question (needs an espg ruling before API design)
What does the source node mean under an all-time read on a windowed pyramid store? The candidates differ semantically:
- Overviews-only tree — the all-time view simply has no source-order node (honest about what is materialized; breaks the source+overviews-siblings invariant, so it should be a visibly different surface, e.g.
open_overview_order(..., all_time=True) returning fold nodes only).
- Computed source fold — recompute the cross-window fold at source order on read (requires the fields' merge laws; it is exactly what the overview family does, done lazily at order
shard_order — cost and semantics both nontrivial).
- Lazy concat over windows — rows repeated per window with a window coordinate (not the same cells axis; arguably a different product view, not "all-time").
Option (1) is the cheapest honest surface and my lean; (2)/(3) are reader-model questions in zagg's O14 DataTree territory and should not be improvised moczarr-side.
Scope once ruled
The opt-in kwarg (or sentinel) on open_overview_order/open_store, D4 stamp admission for the all.zarr fold objects, the §4.2 naming stays reserved in the window grammar (moczarr#30 harmonizes the refusal), tests on the committed all-time fixture (PR #28's overview fixture already materializes per-window + all-time folds).
Refs PR #28 ("Questions for review" item 1), moczarr#30, zagg spec §4.2, zagg O14 (DataTree reader model, sparse_coverage.md §8.2).
🤖 from Claude (filed at espg's direction, from the PR #28 review discussion, 2026-07-31)
Deferred surface
PR #28 refuses
window="all"(the reserved all-time token) rather than half-exposing the all-time folds — correctly, because the old path produced an incoherent tree: overview orders opened theall.zarrcross-window folds while the source order emptied (a windowed store has no all-time source leaf — the fold is of the windows, not a written leaf). This issue is the legitimate opt-in surface, deliberately not a window label.Gating question (needs an espg ruling before API design)
What does the source node mean under an all-time read on a windowed pyramid store? The candidates differ semantically:
open_overview_order(..., all_time=True)returning fold nodes only).shard_order— cost and semantics both nontrivial).Option (1) is the cheapest honest surface and my lean; (2)/(3) are reader-model questions in zagg's O14 DataTree territory and should not be improvised moczarr-side.
Scope once ruled
The opt-in kwarg (or sentinel) on
open_overview_order/open_store, D4 stamp admission for theall.zarrfold objects, the §4.2 naming stays reserved in the window grammar (moczarr#30 harmonizes the refusal), tests on the committed all-time fixture (PR #28's overview fixture already materializes per-window + all-time folds).Refs PR #28 ("Questions for review" item 1), moczarr#30, zagg spec §4.2, zagg O14 (DataTree reader model, sparse_coverage.md §8.2).