up: hard-fail on a missing or stale harness pool pointer once per-image provisioning is retired

pti commented

2026-10-19 23:08:19 +02:00

Owner

Tracks the TODO at cmd/up.go resolveDevcontainerPoolPlan, design/harness/unified-harness-pool.md section 16 Phase 4 item 5 and section 12.2. Today a missing or stale active pointer makes wraptool up fall back to the per-image provisioned binary with a deprecation notice, the mixed-state posture of Phase 2. The wiring-only feature major is published as wraptool:1, but the per-image wraptool:0 feature is still published and the legacy bin and lib trees are still mounted, so the fallback stays. When the Phase 4 cutover lands, retiring per-image provisioning and dropping the legacy exposes and PATH entry, up must instead refuse with the exact section 12.2 text, naming the harness, the platform key and the wraptool harness sync --platform command that fixes it. Scope of this issue is the up side of that cutover, the guix and devcontainer runtimes alike, plus the doctor check and docs that describe the fallback. Found via the three accepted Sonar S1135 TODO findings in cmd/up.go.

pti referenced this issue

2026-10-19 23:54:24 +02:00

harness pool: complete the Phase 4 cutover, remove per-image provisioning and the legacy bin and lib trees before 1.0 #107

pti referenced this issue from a pull request that will close it,

2026-10-20 00:34:04 +02:00

feat/up!: require an active harness-pool generation, no fallback to the legacy install #108

pti closed this issue

2026-10-20 00:48:29 +02:00

pti referenced this issue from a commit

2026-10-20 08:46:27 +02:00

feat(harness)!: stop creating or exposing the legacy bin/ and lib/ pool trees

pti referenced this issue from a commit