harness pool: complete the Phase 4 cutover, remove per-image provisioning and the legacy bin and lib trees before 1.0 #107
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Decision 2026-10-19: per-image provisioning does not ship in 1.0. Every harness in the registry is pool-lockable, claude, opencode and pi through npm, agy through the archive source, omp through releases, so the legacy installer has no remaining purpose, and the wiring-only feature major wraptool:1, the two-mount scaffold and the migrated examples are already in place. This reverses design/release-1-0.md section 3.5 which deferred the cutover to 1.1. Scope, after #102 lands the hard-fail in up: one, harness install, update and sync drop the legacy install step entirely, legacyInstall, legacyInstallVersionLocked, maybeInstallLocked and warnInsteadOfFailForRealizedGeneration in cmd/harness.go and the Install recipes on the harness descriptors, which also deletes the last curl pipe bash in the codebase, and a realize failure then fails the command the way sync already does. Two, the pool layout stops creating or exposing bin and lib, the guix runtime exposes runtime only, gc with the legacy flag and the legacy-removed marker become a plain one-time cleanup of leftover trees, and the harness list ACTIVE column drops its legacy state. Three, docs and design, section 16 Phase 4 closed in design/harness/unified-harness-pool.md, the 1.0 note updated, CHANGELOG breaking entry telling users to run wraptool harness install name once after upgrading, and the wraptool:0 feature documented as unsupported while its published artifact stays. One PR per item with a reviewer pass each. Found while reviewing the accepted Sonar S1135 TODO findings in cmd/up.go.