🤖 from Claude
Reminder issue at espg's request, so the old stores don't linger after #199.
Once #199 lands (both phases: decimal shard-id strings, then the hive tree), every store written under the old format — flat layout, raw packed-word integer shard keys in CSR subgroup paths and .status/ object keys — is unreadable debris by decision: the pre-1.0 hard break from espg/mortie#48, with no migration tooling warranted (we are the only user).
To clear out, once the new layout is producing data:
- S3 output stores from benchmark and test runs (and their
<store>.status/ channels) written in the old key format
- Any ad-hoc / scratch stores from interactive sessions
- Local test-store directories and notebook caches that pin old-format paths or shard ids
Operator task — bulk S3 deletion is destructive and stays with espg, not the routine (left unlabeled deliberately). One suggestion: do the sweep after the first full-AOI benchmark re-pin lands, so nothing old is accidentally still being compared against.
🤖 from Claude
Reminder issue at espg's request, so the old stores don't linger after #199.
Once #199 lands (both phases: decimal shard-id strings, then the hive tree), every store written under the old format — flat layout, raw packed-word integer shard keys in CSR subgroup paths and
.status/object keys — is unreadable debris by decision: the pre-1.0 hard break from espg/mortie#48, with no migration tooling warranted (we are the only user).To clear out, once the new layout is producing data:
<store>.status/channels) written in the old key formatOperator task — bulk S3 deletion is destructive and stays with espg, not the routine (left unlabeled deliberately). One suggestion: do the sweep after the first full-AOI benchmark re-pin lands, so nothing old is accidentally still being compared against.