[Enrique Saurez (esaurez)]

Stacked on #873; this PR retargets to dev when the pull requests below it merge. The chain on dev is #883 → #876 → #871 → #873 → #874, after #863, #864, #865, #866, #867, #868, #869, #870, #872, #875, #878, and #882, which have merged. It builds on #871's third commit, which makes the store generation a nonzero u64: the vectors give a clone's generation as a number, and refuse a generation of 0 and a short restore field.

Part of #838: the last of its three pull requests. A host that gives a guest an activation record must learn from Ready that the guest applied it, and a clone's Ready must also name the restore that it activated, in the same encoding as a cold boot's Ready. This adds the canonical encoding of ReadyActivation, which NVXC v2's Ready (#821) and the test adapter's Ready (#843) can embed, and the conformance vectors of records and of Ready's activation. It removes the configuration identity that #871 defines: Ready reports that the activation applied, and nothing hashes the record. It changes no behavior: nothing reports or checks Ready's activation yet.

What changed

Ready's activation (nvx-rs/src/activation/ready.rs). ReadyActivation holds a clone's transaction ID, or none for a cold boot, and ReadyActivation::of takes it from a record's restore section. ReadyActivation::encode writes 0 for a cold boot, or 1 and the clone's 16-byte transaction ID: ReadyActivation::COLD_LEN, 1, or ReadyActivation::CLONE_LEN, 17, bytes. ReadyActivation::decode reads them back and refuses every other form with ActivationError::Ready.

No configuration identity. Ready reports that the activation applied, and no digest of the record. A clone's transaction ID ties its Ready to the record of its restore, since the host picks a new transaction ID for each restore and sends no other record under it, and a guest would compute a digest from the bytes that it received, not from what it applied. So neither the host nor the guest hashes the record, and this removes ConfigurationIdentity, which #871 defines, and its field in ReadyActivation. The record's VERSION stays 1, since the record and its encoding don't change.

Features. None. The records and both encodings need no features, so every adapter's framing can carry them, and the guest feature keeps its dependencies. The guest binaries, built with nvx.py build-guest-binaries on Linux x86_64, are byte-identical to those of #873's head, 5edab9f, and none holds SHA-256's constants.

Conformance vectors (nvx-rs/tests/vectors/activation-v1.txt), in the line format of #727's files: five records, from the smallest to the largest of 602 bytes, cold boots and clones; what Ready reports about each of them; 47 byte strings that every decoder must refuse as a record, one for each rule; and 7 that it must refuse as Ready's activation. A separate Python implementation of the module's definitions computed their bytes, not nvx. tests/vectors/README.md lists the file.

Documentation. The module documentation defines Ready's activation and its encoding, and the crate's README describes them and the tests of the vectors.

Tests, all without features:

• activation/codec/tests/vectors.rs: each record vector's values encode to its bytes, and its bytes decode to its values; every invalid record is refused;
• activation/ready/tests.rs: cold-boot and clone activations encode to their bytes and read back; every flag byte, and every length after it, are refused but the two forms; Ready reports each record vector's transaction ID, or none for a cold boot, in the bytes of the Ready vector of the same name; the Ready vectors and the invalid ones; and properties: generated activations round-trip, while their prefixes and longer forms are refused, and the decoder returns, never panics, and accepts only canonical encodings.

Validation

At fa45e48, on Windows and on Linux x86_64:

• cargo fmt --check; cargo clippy with --all-targets --all-features, --lib, --lib --no-default-features, and --lib --no-default-features --features guest, and on Linux also for x86_64-unknown-linux-musl, -D warnings; cargo test with all, default, and no features; cargo doc with -D warnings; cargo +1.89 check;
• the runtime adapter's protocol-only and host-only configurations, and, on Linux, its guest-only configuration;
• aci_edge_sandboxes' checks;
• on Linux, also the bundled artifacts test, the macOS check of both crates, the guest binaries' lint, tests, build, and check, and the Markdown link check.

Left to CI: the whole matrix, which runs once this pull request targets dev.

[Copilot]

🟢 Approval recommended

The bounded, additive implementations match the documented contracts, have comprehensive test coverage, and have no identified blocking issues.

No open issues 🎉

What changed in this PR

Completes the activation-record work in #838 by adding configuration identities and a shared Ready activation encoding for future host and guest integration. This PR adds the building blocks without changing runtime behavior.

Changes:

• Adds domain- and version-separated SHA-256 identities for canonical activation records.
• Adds strict Ready activation encoding and decoding for cold boots and clones.
• Adds conformance vectors, unit and property tests, and documentation; enables sha2 for the guest feature.

File	Description
nvx-rs/​tests/​vectors/​README.md	Documents the activation vector file and shared format.
nvx-rs/​tests/​vectors/​activation-v1.txt	Adds record, identity, Ready, and rejection vectors.
nvx-rs/​src/​tests.rs	Exposes activation vectors to shared test helpers.
nvx-rs/​src/​lib.rs	Updates the activation module overview.
nvx-rs/​src/​activation/​ready/​tests.rs	Tests Ready encoding, rejection rules, and canonical round trips.
nvx-rs/​src/​activation/​ready.rs	Implements the cold-boot and clone Ready codec.
nvx-rs/​src/​activation/​mod.rs	Documents the contracts and adds the Ready decoding error.
nvx-rs/​src/​activation/​identity/​tests.rs	Tests identity vectors, field sensitivity, and Ready construction.
nvx-rs/​src/​activation/​identity.rs	Implements record hashing and ReadyActivation::of.
nvx-rs/​README.md	Documents APIs, feature requirements, and test coverage.
nvx-rs/​Cargo.toml	Enables sha2 under the guest feature.
doc/​project-structure.md	Adds configuration identity to the activation module description.

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The additive APIs match the specified identity and encoding contracts, with comprehensive targeted coverage and no identified blocking issues.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The bounded hashing and strict codec implementations match the documented contract, with comprehensive coverage and no unresolved blocking findings.

No open issues 🎉

_{Review effort: Balanced}

[Copilot]

🟢 Approval recommended

The bounded codec matches the specified wire forms, with conformance and property coverage and no identified blocking issues.

No open issues 🎉

_{Review effort: Balanced}