Hard-Capped Window Planning
Cover every byte with complete records, bounded overlap, and no window above the cap.
- Reconstruct windows from record sizes and a hard cap.
- Distinguish full coverage from exclusive coverage.
- Explain why overlap may be smaller than requested.
Core model
Windows make large files addressable without pretending they fit in one context. The planner adds complete physical records until the next one would exceed the cap. A requested overlap is only an upper bound: it shrinks when needed so the next exclusive record can make progress.
Mental model: Pack whole books into boxes with a weight limit. You may repeat the last book as context, but you cannot tear a book or exceed the limit just to preserve the repetition.
For synthetic record sizes `[30,25,20,35]`, cap 60, overlap 1: full windows are records `[0,2)` bytes `[0,55)`, records `[1,3)` bytes `[30,75)`, and records `[2,4)` bytes `[55,110)`. Full spans overlap; exclusive ranges partition `[0,110)` with no gap. A single record above 60 fails the manifest.
Boundary table
| Question | Observed boundary | Owner | Verdict |
|---|---|---|---|
| W0 | records [0,2) | bytes [0,55) | 55 B |
| W1 | records [1,3) | bytes [30,75) | 45 B · overlap 25 B |
| W2 | records [2,4) | bytes [55,110) | 55 B · overlap 20 B |
Primary local source
docs/fable-session-mining/U2-MANIFEST-SCOPE.mdrecords = [30, 25, 20, 35] maxWindowBytes = 60 overlapRecords = 1 // W0 [0,55) · W1 [30,75) · W2 [55,110)
Synthetic lab
Inspect a candidate plan under cap 60.
Retrieval and feedback
May the planner keep two overlap records if that leaves no room for the next new record?
Retrieval cards
Check your model
Which ranges must partition the file with no duplicates?
Evidence ledger
Authority: docs/fable-session-mining/LOOP-LOG.md. Tests never upgrade a missing live receipt.