feat/harness!: drop the legacy install step, the pool generation is the only install #109
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/harness-drop-legacy-install"
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?
Part of #107, item one of three, the pre-1.0 Phase 4 cutover. Breaking. wraptool harness install and update no longer run the harness's own installer into the legacy pool trees after realizing a generation. The Install recipe field on harness descriptors is gone together with the npm installer, Antigravity's curl pipe bash, which was the last one in the codebase, the two legacy installers, the per-source warn-instead-of-fail downgrade logic, the version pinning helper and the guix-absent special case, about 1300 lines. A realize failure now fails install and update the way sync already did, with the oci provisioning-image hint folded into the error, and a nil realize error is the guarantee that the host pointer is active because the orchestrator activates on success and reports activation failures through the same channel, so the defensive post-install check the first cut added was removed as unreachable after review. Every registry harness is pool-lockable, pinned by a new registry test. Eight tests that covered only the legacy installer are deleted and eleven converted from warn-and-fall-through to error assertions, every pool-state assertion kept, verified by the reviewer against each deleted body. Mutation making a realize failure warn again fails six tests. Docs in cli-reference, getting-started, platform-guix and terminology, design section 16 status, CLAUDE.md, CHANGELOG second Breaking bullet. Items two and three, the bin and lib layout cleanup and the feature description bump, follow as their own PRs. 🤖 Generated with Claude Code