sealkeep 0.5.2 → 0.6.0

package/ARCHITECTURE.md

@@ -94,7 +94,7 @@ Full specification, test vectors, and tamper coverage: `packages/vaultline-crypt
 
 ## 4. Control-plane API v1
 
-Authentication is on by default. `VAULTLINE_CONTROL_PLANE_DEV=1` disables device signatures
+Authentication is on by default. `SEALKEEP_CONTROL_PLANE_DEV=1` disables device signatures
 and keeps state in memory for local interface work; `/health` reports
 `mode: development-interface` so a misconfigured deployment is visible in one request.
 
@@ -198,4 +198,4 @@ Four gates remain open, none closable by writing more code in this repository:
 3. **OS code-signing certificates.** Releases carry npm provenance and an Ed25519-signed manifest only.
 4. **Browser and accessibility QA** of the dashboard.
 
-Uploads remain off unless `VAULTLINE_ENABLE_SIGNER=1` is set explicitly.
+Uploads remain off unless `SEALKEEP_ENABLE_SIGNER=1` is set explicitly.

package/CHANGELOG.md

@@ -3,6 +3,36 @@
 Notable changes, by published version. Sealkeep is pre-1.0: minor versions
 may change behavior, and say so here when they do.
 
+## 0.6.0 — 2026-08-19
+
+**A second machine no longer wipes your search index.** The content index is
+shared by every machine of a vault, but each machine pruned it from its own
+records: a laptop that had never sealed anything concluded every entry was
+dead, deleted them, and pushed the emptied index back — after which the machine
+that built it could not search its own history either. A machine now forgets
+only what it itself indexed. If this bit you, `sealkeep index build` on the
+machine holding the archives restores the phonebook for the whole vault.
+
+- Cross-machine search now finds ordinary uploaded archives, not just streamed
+  ones: a hit with no local record is rebuilt from the archive's own frame.
+- Environment variables are `SEALKEEP_*`. The Vaultline-era names still work,
+  so nothing on an existing machine breaks; the new name wins when both are set.
+- The CLI honours `SEALKEEP_DATA_DIR` — the variable `mcp install` already
+  writes into agent configs — so the agent and the CLI cannot silently work on
+  different vaults.
+- New: `npm run acceptance` drives 22 end-to-end scenarios through the shipped
+  CLI (see `docs/acceptance-matrix.md`).
+
+## 0.5.3 — 2026-08-19
+
+The account now knows what every destination holds. Machines stamp
+per-target usage (Drive, your bucket, cloud) into the routing rules they
+already sync, so the panel's new headline reads like the truth:
+"3.7 GB in Sealkeep cloud · 56 MB in Google Drive". The panel also got
+its polish pass: status headline first, routing rules as three short
+bullets, per-row "holds X", compact editors, your current package leads
+with the tiers as chips, and Drive shows as "folder <name>".
+
 ## 0.5.2 — 2026-08-19
 
 - "Manage in cloud" now opens sealkeep.spala.ai — the panel URL was still

package/CONTROL_PLANE.md

@@ -6,7 +6,7 @@ The control plane stores device identities, encrypted manifests, and provider co
 
 ```sh
 npm run control-plane                       # authenticated, durable
-VAULTLINE_CONTROL_PLANE_DEV=1 npm run control-plane   # unauthenticated, in memory
+SEALKEEP_CONTROL_PLANE_DEV=1 npm run control-plane   # unauthenticated, in memory
 docker build -t vaultline-control-plane . && docker run -p 8787:8787 -v vaultline-data:/data vaultline-control-plane
 ```
 
@@ -35,7 +35,7 @@ presented in `x-vaultline-device`, `x-vaultline-timestamp`, `x-vaultline-nonce`,
 refused, and a nonce cache rejects verbatim replays. Binding method, path, and body hash
 into the signature means a captured signature cannot be redirected to another endpoint.
 
-`VAULTLINE_CONTROL_PLANE_DEV=1` disables this and keeps state in memory. It exists for
+`SEALKEEP_CONTROL_PLANE_DEV=1` disables this and keeps state in memory. It exists for
 local interface development. If `/health` reports `development-interface` on anything you
 deployed, stop it.
 
@@ -61,7 +61,7 @@ Input is ciphertext-only metadata: archive ID, encrypted byte length, SHA-256 of
 
 Every lease carries `status` and `uploadable`. In this build they are always `pending-signer` and `false`. `assertLeaseUsable` is the single gate an upload path must pass: it checks expiry first, so a replayed lease is refused as `lease_expired` rather than as an unsigned one, and it then refuses anything that is not an `active` uploadable lease with `signer_not_configured`.
 
-`VAULTLINE_ENABLE_SIGNER=1` permits registering a `ProviderUploadClient`, but no implementation ships. With the flag off, registration and lookup both fail; turning it off again immediately withdraws every registered client.
+`SEALKEEP_ENABLE_SIGNER=1` permits registering a `ProviderUploadClient`, but no implementation ships. With the flag off, registration and lookup both fail; turning it off again immediately withdraws every registered client.
 
 For S3/R2 the response contains `createMultipart`, per-part presigned PUT URLs, and a completion endpoint. For GCS it contains a signed initiation URL plus the resumable session URI returned to the local agent. The client validates the remote checksum and then calls `POST /v1/archives/complete`.
 

package/README.md

@@ -30,7 +30,7 @@ heartbeat every cycle, so `status`, the dashboard, and the local API all answer
 "is it running, when did it last check, and what has it sealed" from the same fact.
 It also raises a native notification when disk is reclaimed or something needs a
 decision — never for routine sealing, which would just train you to ignore it.
-Silence it entirely with `VAULTLINE_NOTIFICATIONS=off`.
+Silence it entirely with `SEALKEEP_NOTIFICATIONS=off`.
 
 Prefer to drive it yourself? `sealkeep quickstart` does the same setup without installing
 a service, and you run `sealkeep queue run` when you feel like it.
@@ -70,7 +70,7 @@ Autopilot runs all four on a loop. To unlock the vault without a human present,
 your phrase in the OS keystore — macOS Keychain, Freedesktop Secret Service, or Windows
 DPAPI. That is a real trade-off, stated plainly: anything running as you can read it once
 you are logged in. Opt out with `--no-remember` and supply
-`VAULTLINE_RECOVERY_PHRASE` to the service yourself. Either way, the phrase you wrote down
+`SEALKEEP_RECOVERY_PHRASE` to the service yourself. Either way, the phrase you wrote down
 stays your disaster-recovery path.
 
 ## Your recovery phrase is 24 words
@@ -191,7 +191,7 @@ and phrase still never leave your machine.
 ```sh
 sealkeep storage configure --provider r2 --bucket encrypted-sessions --prefix accounts/me
 echo '{"accessKeyId":"…","secretAccessKey":"…"}' | sealkeep storage credentials set
-VAULTLINE_ENABLE_SIGNER=1 sealkeep upload --all
+SEALKEEP_ENABLE_SIGNER=1 sealkeep upload --all
 ```
 
 Or skip storage entirely and keep everything local. Sealkeep still seals every archive; it