Deliverable and sidecar materialization (D5, D6)
Goal
A built binary and its debug sidecar are materialized as a coherent pair the debugger resolves, and reclaiming the cache entry never frees a deliverable the user still holds.
Implementation Sketch
Derived from compiler_repo/docs/ori_lang/proposals/approved/binary-generation-lifecycle-proposal.md. Depends on the cache root, budget, collection pass, and D3a in-flight-reference primitive delivered by plans/cache-lifecycle/ (approved cache-lifecycle-proposal.md). Implement the work items in order.
Spec References
- Approved proposal:
compiler_repo/docs/ori_lang/proposals/approved/binary-generation-lifecycle-proposal.md - Depends on:
compiler_repo/docs/ori_lang/proposals/approved/cache-lifecycle-proposal.md(D3a primitive, composed bound) - Umbrella invariant T4:
compiler_repo/docs/ori_lang/proposals/approved/toolchain-philosophy-proposal.md
Work Items
- Materialize the deliverable from the current generation — POSIX hard-link (copy across filesystems), Windows copy via the D2 replace primitive with an actionable in-use-executable diagnostic; a materialized deliverable never blocks reclaim (reclaim unlinks only the cache-side name)
- Materialize the debug sidecar alongside its deliverable transactionally, handling a directory-shaped macOS
.dSYMbundle; the pair is published and reclaimed as one unit with discovery resolving against the deliverable location (sidecar-then-binary ordering)