| 1 | # Astra: hostfiles path cap, live entries only |
| 2 | |
| 3 | Branch `hostfiles-cap-live-entries`, commit 28d086d8, from main 132cf996. Read the commit message first. |
| 4 | |
| 5 | **Background.** Moves' Astra review of a8cebad, posted on amadan #236, found a P2. `checkManifest` capped every entry path at 4095 bytes, tombstones and skipped entries included. A manifest written before the cap could therefore stop `Establish` with ErrTooDeep and strand a moves recovery after a cut. |
| 6 | |
| 7 | **The change:** |
| 8 | - The cap now applies only to live entries. The rule is `LiveEntriesWithinCap`, exported; internally it is `manifestWithinCap`. |
| 9 | - Readers (`checkManifest`), Open, OpenAt and Commit all apply it. |
| 10 | - New writes still refuse over-cap paths: Stage, StageSkipped, StageDelete and the walk. |
| 11 | - A census overlay records the Plan 14 envelope change. |
| 12 | |
| 13 | **Judge:** |
| 14 | 1. Is exempting tombstones and skipped entries safe in every reader and writer? |
| 15 | - Restore's tombstone removal, `removeInside` with `realParents` and `os.Root` `Lstat`/`Remove`, now receives over-cap paths. Can that fail with ENAMETOOLONG, or cost unboundedly? Would the failure be any worse than the old ErrTooDeep refusal? |
| 16 | - Check `superseded`, `Present`/`presentFile`, `CopyManifest`, `NewFromCopy`, and moves' `movesFilesAllowed` / `Establish`. |
| 17 | 2. Is there any reader or writer still applying the old all-entries cap that would strand the same recovery? |
| 18 | 3. Does anything still let a new over-cap live entry be written? |
| 19 | 4. Are the tests sufficient? Is the census overlay correct and envelope-only, with no root-read unit or legacy seal change? |
| 20 | 5. **Verdict:** is it ready to merge, after the release freeze? |
| 21 | |
| 22 | Give findings P1/P2/P3 with file:line. Read-only; run nothing heavy. |
| 23 | |
amadan