Phase log 53: 2026-10-09 - Phase 36: blast radius

Written for the next LLM agent: a changelog and decision record. Version bumped to 0.36.0. Nothing is committed. Read 51-2026-10-09-phase-34-nodes.md (Nodes) and 52-2026-10-09-phase-35-the-config-time-machine.md (config history) first: this phase is a consumer of both, and the commit-script mechanism (a per-file registry, scripts run in phase order) is described in phase log 52 §0 and has been extended here (~/Code/envvault-commit-phase36.ps1, 9 commits; files first touched by 34 or 35 stay in those scripts with a joined message).

1. The problem and the shape of the answer

After a compromise the question is "which credentials were on that machine, and when?". It was never answerable, so the answer was "rotate everything", so nobody did. phase log 23 T6 says the hub knows what it rendered, the node knows what it wrote and the audit chain knows what changed, and that the real work is the log, not the query. Three gaps stood between those facts and an answer:

1. Nothing recorded which secrets a rendered file contained.
2. Local envv exec and --out are deliberately outside the audit chain, so there was no record of what reached this machine.
3. By the time of a compromise an entry may have been rotated, renamed or deleted, so "what is in the vault now" is the wrong thing to look up.

2. What was built

New files

Modified files

3. Decisions and rejected alternatives

1. Exact-value matching, not reference parsing. The tempting design records which ${Provider/field} references a render resolved. It misses a secret typed literally into a chunk field, one that arrived through a composite part or a bundle, and anything the exporter derived. Matching the vault's actual secret values in the rendered text (the engine of envv shield) catches all of those and needs no change to the resolver. Cost: a coincidental match; handled by the short flag (under 8 characters), never by dropping the match.
2. Store the exposure list with each snapshot, inside the hash chain. Reconstructing it at report time from the current vault would miss rotated and deleted entries, which are the interesting ones. The list is derived data, but it is what the report is made from, so editing it must be detectable: it is in the chain (envv-history-v2). Phase 35's data was never released, so changing the chain formula needed no migration.
3. "Still current" by fingerprint comparison, against present values only (version_history excluded). Rejected: comparing last_rotated_at with the deployment time, wrong whenever an entry was edited without being marked rotated or marked rotated without a change.
4. Hub clock, not node clock. node.apply audit rows carry the node's own at inside details; the report uses the audit row's timestamp. A node under investigation is not the source for when things happened. (Test: a_nodes_deployments_are_timed_by_the_hubs_audit_row…; mutation "trust the node's at" is caught.)
5. Record what is about to leave the hub, first. Without it a first push of a vault that was written directly (no save through the server's hook) has no snapshot, so blast radius would list a real exposure as "unaccounted". snapshot_stream runs in process() before the Push; it deduplicates against a save's snapshot. The e2e test a_push_is_recorded_before_it_is_sent… fails without it.
6. A bounded local ring file, outside the chain, for CLI materialisations. It is the shape AGENTS.md already prescribes for read auditing (every read used to write an audit row; pruning would break the chain). A table in vault.db was rejected: a CLI on a workstation using a remote vault has no database to write to, and the machine being investigated is the workstation. The log records entries, fields and fingerprints and never a value; a write with no vault secret in it is not recorded.
7. One command, for the vault's copy only, and the report says so. envv entry rotate '<name>' --generate; … for exactly the still-current entries. Revoking at the issuer is outside the vault; the entry's console_url (http/https only) is printed beside it.
8. Unaccounted, not clean. A deployment whose file hash has no snapshot (history off, or pruned) is listed with its time, target and short hash. Reporting "nothing exposed" for it would be the one false statement this feature must never make.
9. Not covered, written down: a value printed by get --reveal; the app's copy buttons; a node's pull targets (never rendered by the hub); anything that opened the vault directly; a node host's own copy of a secret it already had.

4. Verification

• cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings: clean.
• cargo test --workspace: 601 passed, 0 failed (+28 over phase log 52).
• npm run check: 1409 tests in 78 files, all pass; prettier, eslint --max-warnings 0, tsc clean.
• npm run ui-lab: 167 passed.
• End to end (real agent, real socket): after the agent applies a pushed file, blast on that node names Stripe as still_current with the console link and the command envv entry rotate 'Stripe' --generate, and no value appears in the report; after the vault's key is rotated (old value moved to version_history) the same query says still_current: false and an empty command; an unknown host answers empty, not an error; with history disabled the apply is reported as one unaccounted deployment and no entries.
• Fault injection (harness mut3.py, backups keyed by full path): everything-is-still-current; a refused apply counted as exposure; since ignored (in report and in the dispatcher); a deleted entry counted as still current; no quote safety; history values counted as current; records with no secret written; the node's own timestamp trusted; deferred (not IMMEDIATE) snapshot transactions; the push not recorded before it is sent; write_secret_file not logged; emit --out not logged; exec not logged. All caught.

5. Incidents and dead ends

• A mutation run gave false assurance and was caught by re-reading it. mut3.py reported mutants 11–13 ("write_secret_file / emit / exec not logged") as CAUGHT, but the test I had edited had not actually been changed (cargo fmt had reflowed the file, so my str.replace matched nothing, silently), so the test expected the old count and failed with or without the mutation. The tell was a debug script showing two log records while the test asserted three. Fix: edit the test for real, make the history show use the newest snapshot (snapshot #1 is the empty chunk from before the reference was set and contains no secret, so logging nothing for it was correct), and re-run those mutations. Lesson: a mutation is only "caught" if the unmutated test passes first; run the clean suite immediately before the mutation, and never str.replace into a file cargo fmt may have rewritten without asserting the replacement happened.
• history show --out was not logged because history operations never call Access::load_vault, so no vault had been remembered and note silently did nothing. show/diff with --out now load the vault first. This is a pattern to watch: matlog::note is a no-op without a remembered vault, so any new command that writes real values to a file must load the vault.
• ENVV_SERVER_URL in the shell sent a debug script's CLI at the real server ("Wrong master password"). Known trap (AGENTS.md); the script now unsets it.
• A concurrency hole found while designing the push-time snapshot: two snapshotters (a save's background task and a push) could both read the same chain tail and each extend it, forking the chain so the stream never verifies. Fixed with BEGIN IMMEDIATE and proven with a 4-thread test; the "deferred" mutant is caught by it.
• Pre-existing, not changed: fmt::emit (used by project export --out and every exporter) writes with std::fs::write, so the file gets the default umask (typically 0644), not 0600, although it holds real secrets. write_secret_file is the 0600 writer. Left alone because deploy files often need to be readable by a service user, but it deserves a decision (an --out mode flag?). Recorded here so it is not rediscovered.

6. Not done and traps

• The app has no UI for --host local (by nature: the app's copy actions are not logged). If the app ever logs its own copy/export actions it should write the same ring through a Tauri command.
• matlog::note builds a Matcher per call (O(secrets)); fine for a handful of materialisations per command, wasteful in a loop. Cache the matcher in remember if a command ever materialises per-item.
• The materialisation log lives in the user's state directory; two users on one machine have two logs, and a root-run command logs to root's.
• exposed lists are computed at snapshot time against the vault then: an entry created after the file was written is correctly absent; an entry whose value was identical by coincidence is present (reported, marked short if under 8 characters).
• Run order of the commit scripts matters (34, 35, 36), see phase log 52 §0.

7. Next

Phase 37 (approval) sits on the same push path: the hub renders, a human approves the exact bytes, the hub releases an approval bound to the SHA-256 of the content, and the node refuses a mismatch. The hash is already announced with every Push and re-checked by nodes_apply::apply; what is missing is the pending state, the diff for the human (Phase 35's diff and snapshots are exactly that), and the approval token.