# Astra: hostfiles path cap, round 4 (revised design)

Round 3 (`CODEX-REVIEW-HOSTFILES-CAP-3.md`) found two P2s in the deep-tombstone removal walk: over-cap parent directories left behind, and an ancestor-rename redirect. Paul ruled to withdraw the walk and refuse over-cap tombstones up front. Commit 54196e88, then merged with main in 3fb0e576.

The rule is `hostfiles.RestorableWithinCap`, which is `manifestWithinCap` under the name Open, OpenAt and Commit use:
- **Refused:** live entries and tombstones past 4095 bytes are ErrTooDeep. The readers (checkManifest: Restore, CopyManifest, ValidateManifest), Open, OpenAt and Commit all apply this.
- **Exempt:** skipped entries, because Restore never touches their path.
- **StageDelete:** for a path past the cap it is a no-op, so an inherited over-cap skipped entry whose file is gone stays skipped.
- **The walk is removed.** removePastCap, its stub, descendCtx and their tests are gone, and Restore's tombstone loop is main's again.

Upstream guards, per #236: moves' cut preflight will call RestorableWithinCap, relocation's pin already calls ValidateManifest, and #250's backfill reports failing manifests per host before activation.

**Judge:**
1. Are round 3's P2s moot now that the walk is gone?
2. Does exempting skipped entries alone leave any path that strands a recovery or a flush? Consider:
   - superseded();
   - Present;
   - the scan, with an over-cap skipped entry whose file still exists on disk (the walk refuses it: is that only an existing #279-class issue, or new?);
   - CopyManifest and NewFromCopy;
   - moves' Establish.
3. Is a StageDelete no-op past the cap safe? Could it hide a real deletion that a reader then misrestores?
4. Census: is the overlay envelope-only, with Plan 9 and Plan 14 legacy units unchanged?
5. **Verdict:** is it ready to merge?

Give findings P1/P2/P3 with file:line. Read-only; run nothing heavy.