reads: hydration, filter/count endpoints, secondary indexes + benchmark
the appview grows up: membership sets per (kind, state / flow / parent)
in burner-redis — the same shape as the cloud prototype's redis run-
state indices — back POST /flow_runs/filter, /count, /task_runs/filter
and /flows/filter. boot now rebuilds the whole appview by replaying the
repo (entities, then the event log in TID order), so reads survive
restarts: the delete-the-cache-replay-the-truth property is exercised
on every boot.
docs/access-patterns.md grounds the design against guidry's proofs in
prefectlabs/object-store-orchestration (latency bands, the delta-size
lever, the disproven many-small-objects pattern) and lays out the
three-tier aggregation story (maintained counters / bounded scans /
CAR-export analytics).
scripts/bench-reads runs the same seeded workload against any prefect
REST target. results (docs/bench-results.md): membership reads 4-11x
faster than python on sqlite or postgres, bulk lists tied at n=300,
202/s writes while signing a commit and rewriting the CAR every
mutation. all four client read paths (point + filter) now pass against
a restarted server.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>