release: 0.1.4

Cargo.toml

@@ -7,7 +7,7 @@ members = ["crates/*"]
 exclude = ["firmware/*"]
 
 [workspace.package]
-version = "0.1.3"
+version = "0.1.4"
 edition = "2024"
 license = "MIT OR Apache-2.0"
 repository = "https://github.com/Remade-With-Rust/rusty_esp_mid"
@@ -29,8 +29,8 @@ undocumented_unsafe_blocks = "deny"
 [workspace.dependencies]
 # Internal crates carry BOTH path and version so the set publishes to crates.io
 # in lockstep (the rusty_time pattern).
-rusty_esp_mid-core = { path = "crates/rusty_esp_mid-core", version = "0.1.3", default-features = false }
-rusty_esp_mid-esp = { path = "crates/rusty_esp_mid-esp", version = "0.1.3", default-features = false }
+rusty_esp_mid-core = { path = "crates/rusty_esp_mid-core", version = "0.1.4", default-features = false }
+rusty_esp_mid-esp = { path = "crates/rusty_esp_mid-esp", version = "0.1.4", default-features = false }
 
 # Siblings in the Janus family are consumed BY GIT URL so this repo deploys on
 # its own. Inside the Janus umbrella folder, `.cargo/config.toml` patches the

crates/rusty_esp_mid-core/README.md

@@ -6,6 +6,8 @@ The pure half of the identity package: a P-256 device `did:mata`, the byte-ident
 
 Agreement with the wider MATA stack is a test, not an intention: signatures equal the reference signer for the same key, and the capability check agrees with the reference implementation on **144 of 144 cases**.
 
+New in 0.1.4: the signed status a device answers a hub's nonce with -- `status::StatusProof` (`janus-status-v1`, low-s, with a cross-checked vector) and `status::StatusDocument`, the `/v1/status` body; and `settings_adoption`, an owner's adoption delivered with the settings at boot (`apply`: checked, pinned, stored verbatim, cleared) and read back for the status (`stored`).
+
 New in 0.1.3: `seal::SealedKv` keeps secrets sealed at rest behind the same store seam -- AES-256-GCM, each value bound to its key name, a fresh nonce per write -- under a key the chip derives and never stores. A store provisioned in the clear is sealed where it lies; `inner()` hands the store back so a firmware can scrub what the old values left behind.
 
 ## Where the evidence is

crates/rusty_esp_mid-esp/README.md

@@ -4,6 +4,8 @@
 
 The chip backends for the identity package: the device key's home in the chip's key-value partition behind the store seam, with the encryption check the plan demands, and the hardware entropy source behind the entropy seam. On Track A (`esp-idf`) that is ESP-IDF's NVS and TRNG; on Track B (`esp-hal`) it is the same `identity` partition read and written by `rusty_esp_core::nvs` — Espressif's NVS format in pure Rust — over `esp-storage`, and `esp-hal`'s TRNG. A key minted on one track is read on the other.
 
+New in 0.1.4: nothing of its own; it moves with mid-core 0.1.4, the set released together.
+
 New in 0.1.3: `hal::seal_key` (feature `seal-hmac`) derives the sealing key from the HMAC peripheral and an eFuse key block, so the key never sits in flash; the partition table is read where the build put it (`ESP_BOOTLOADER_ESP_IDF_CONFIG_PARTITION_TABLE_OFFSET`), and through the cache under flash encryption.
 
 New in 0.1.2: `EspNvsKv` reads a value written as an NVS string as well as a blob (what the owner's settings image holds), and `hal::shared` keeps several partitions open on one flash at once -- the owner's settings and the identity, as the Janus setup session holds them.