up: refuse, not just notice, an existing dev container that lacks the harness-pool runtime mount

pti commented

2026-10-20 08:55:43 +02:00

Owner

Follow-up to #102 and #107 found while reviewing the Phase 4 closure docs. On the devcontainer runtime, wraptool up requires devcontainer.json to declare the read-only runtime/ mount and refuses otherwise. But a container created before that declaration was added is reused as-is by devcontainer up, since a container's mounts are fixed at creation. Today devcontainerStaleRuntimeMountNotice in cmd/up.go only prints a notice to stderr and proceeds, so a container built against the unsupported wraptool:0 major keeps running the per-image binary with no pool generation involved, which contradicts the no-fallback rule every other path enforces. Proposal: when devcontainerRuntimeMountStale reports the live container has no mount at /opt/wraptool-harness/runtime, stop before devcontainer up with an error naming wraptool down --rm and wraptool up, the same way the missing-declaration case already does. Keep the notice text as the error body. Add a test on the stale path mirroring the missing-declaration tests. TODO.md keeps this as the one open Before 1.0 sub-item until it lands.

pti referenced this issue from a commit

2026-10-20 08:56:38 +02:00

docs(harness): review fixes for the Phase 4 closure, reopen the stale-container item

pti referenced this issue

2026-10-20 08:57:04 +02:00

docs/harness: close Phase 4, the wraptool:0 feature major is unsupported #112

pti referenced this issue from a commit

2026-10-20 09:39:51 +02:00

fix(up)!: refuse an existing dev container that lacks the runtime mount

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

2026-10-20 09:40:07 +02:00

fix/up!: refuse an existing dev container that lacks the harness-pool runtime mount #114