Observable outcome
Design an explicit, auditable disposition protocol for incomplete retained root, manifest and head stages. PR #99 deliberately preserves these stages and blocks publication; it does not claim automatic-discard safety.
Scope and acceptance
- Specify which evidence authorizes each disposition and who supplies that authority. Preserve demonstrated corruption and uncertainty distinctly; finding no contradiction is not a canonical-completion proof.
- If automatic disposal is proposed, establish the stronger completion-feasibility contract, including declared future-entry ordering and all partial-field combinations that matter to that authorization.
- Specify source identity checks, supported cooperating-writer namespace model, interruption/restart states, failing-operation effects and durability uncertainty. Never imply that a handle makes pathname mutation inode-conditional.
- Add boundary regressions with exact outcomes and preserved evidence for unauthorized disposition; deterministic fault/restart evidence for authorized effects. Calibrate distinct assertions and observe bug regressions RED on the unfixed revision.
- Update recovery API, normative requirements, user guidance and evidence together. No instruction to blindly delete retained stages.
- Keep the merge result independently correct: unsupported or ambiguous states continue to preserve evidence and block publication.
Dependencies and exclusions
This executable follow-up builds on #99's bounded landing contract; #99 does not depend on this work. Durable-format or namespace changes require their own explicit design approval and are not implicit acceptance criteria here. No repository-wide filesystem audit, performance optimization or physical power-loss claim is included.
Observable outcome
Design an explicit, auditable disposition protocol for incomplete retained root, manifest and head stages. PR #99 deliberately preserves these stages and blocks publication; it does not claim automatic-discard safety.
Scope and acceptance
Dependencies and exclusions
This executable follow-up builds on #99's bounded landing contract; #99 does not depend on this work. Durable-format or namespace changes require their own explicit design approval and are not implicit acceptance criteria here. No repository-wide filesystem audit, performance optimization or physical power-loss claim is included.