feat(launch): instance lifecycle over the host adapters - #18
Merged
Conversation
Builds the rvm-launch surface out from four modules into the full ADR-289 verb set — inspect, verify, run, suspend, resume, checkpoint, witness, terminate — as a library first, with the CLI, the Tauri reader through rvm-ffi, and Forge through rvm-node all calling into it. ADR-289 rejects the alternative in its own alternatives section: three callers enforcing three different things. Four invariants are structural rather than documented: Nothing executes before verification succeeds — Instance::create takes a VerifiedPackage whose only constructor rejects a failed report, so there is no path from a failed verify to a running instance. Inspection is not execution — inspect and verify read headers, hash payloads and check signatures without mapping a segment or resolving an entry point, so a scanner can open an untrusted artifact without becoming an execution surface for it. Illegal transitions are errors, not no-ops, and each refusal is witnessed before it is returned. State binds to its lineage — a checkpoint carries the base RVF identity it was produced under (ADR-288 §4) and restore refuses one from a different base before touching the state machine. Instance identity is provenance, not a gate, because ADR-289 criterion 7 requires resuming under a different host adapter. 233 tests across the three crates, clippy clean under -D warnings, workspace checks. Co-Authored-By: claude-flow <ruv@ruv.net> Claude-Session: https://claude.ai/code/session_01ParP55bZs2iTGEGvpnUecx
ruvnet
force-pushed
the
feat/rvforge-integration
branch
from
August 5, 2026 13:50
b94c593 to
c622025
Compare
ruvnet
added a commit
that referenced
this pull request
Aug 5, 2026
The README stated that rvm-host and rvm-launch were "not yet in this repo" and that an RVForge package "can be verified and capability- mapped on RVM, not executed by it". Both landed in v1.6.0 and #18, so the section understated the repo by two crates and a lifecycle. Corrections, each checked against origin/main rather than memory: rvm-host and rvm-launch are present — added to the crate table and to the flow diagram, and removed from the not-yet list. rvm-ffi and rvm-node genuinely are absent, and rvm-wasm still carries MAX_MODULE_SIZE, so those claims stay. The overview link pointed at the gist; it now points at the walkthrough at ruvnet.github.io/RuVector/rvforge. The integration map called rvm-rvf "in progress on feat/rvforge-integration" and rvm-host/rvm-launch roadmap. All three are marked landed. The rvm-native row now says what actually blocks it — bare-metal execution — rather than crates that have since shipped. npm reference bumped to @ruvector/rvforge@0.2.0, which is the version that can author an .rvf rather than only consume one. Added the invariants that came with the lifecycle: nothing runs unverified, illegal transitions are witnessed errors, and state binds to its lineage. Claude-Session: https://claude.ai/code/session_01ParP55bZs2iTGEGvpnUecx
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows v1.6.0. Builds
rvm-launchout from four modules into the full ADR-289 verb set.rvm inspectinspectrvm verifyverifyrvm runInstance::createthenInstance::startrvm suspend/resumeInstance::suspend/resumervm checkpointInstance::checkpointrvm witnessInstance::witnessrvm terminateInstance::terminateThe surface is a library first and a CLI second, because ADR-289 rejects the alternative explicitly: the CLI, the Tauri reader via
rvm-ffi, and Forge viarvm-nodemust not each enforce their own version of these rules.Four invariants, held structurally
Nothing executes before verification succeeds.
Instance::createtakes aVerifiedPackage, whose only constructor rejects a failed report — there is no path from a failedverifyto a running instance, rather than a convention that callers should check first.Inspection is not execution.
inspectandverifyread headers, hash payloads and check signatures. Neither maps a segment, resolves an entry point, or interprets a payload, so a scanner can open an untrusted artifact without becoming an execution surface for it.Illegal transitions are errors, not no-ops. The state machine permits nothing outside its table, and each refusal is witnessed before it is returned.
State binds to its lineage. A checkpoint carries the base RVF identity it was produced under (ADR-288 §4), and
restorerefuses one from a different base before it touches the state machine or a runtime. Instance identity is recorded as provenance but deliberately does not gate — ADR-289 criterion 7 requires suspending under one host adapter and resuming under another, so the far-side instance is new by construction.Verification
🤖 Generated with claude-flow
https://claude.ai/code/session_01ParP55bZs2iTGEGvpnUecx