vault inject_map emits a params-only body that fails UBF validation and dead-letters

[mmeyerlein]

The vault cell's params.inject_map push at unlock never reaches its target: the emission is a params-only body, and the UBF body schema requires one of system / messages / attachments. The debug-build validation in the colony's outputs arm therefore rejects it as InvalidUbfBody and it goes to the dead-letter queue — before a message_log row is written.

Measured on a booted flat topology with a vault whose inject_map names a live llm cell:

DLQ InvalidUbfBody Path("/brain") ... body: Inline(Object {"params": Object {"http_referer": String("<the secret>")}})

So the one documented path by which a plaintext credential leaves the vault does not work at all. The unlock still reports which name went where under which key, so the answer says a delivery happened that did not.

Found while building the no-plaintext pin for #421, where this path was going to serve as the counter-proof — a test that asserts the grep WOULD find a plaintext if one were there. It could not, because nothing plaintext ever lands in the log on this path. The counter-proof now uses vault.put over the user channel instead, which is a real plaintext path and also explains why the pin fills the vault straight into its cell.db rather than by message.

Note on priority: inject_map is deprecated as of #421 (the sealed delivery replaces it) and is empty on a fresh instance, so nothing shipped depends on it. docs/roadmap.md carries its removal with a trigger. Two honest options: fix the emission shape, or bring the removal forward. Either is a decision rather than a patch, which is why this is a report and not a fix.

[mmeyerlein]

Ruling (Marcus, 2026-08-26): do not repair — pull the removal forward.

The path is deprecated since #421, functionally replaced by sealed delivery, empty on fresh instances, and provably broken before it ever logs a line. A path that cannot function has no users; removing it breaks nobody, repairing it would resurrect a plaintext-leaking road only to retire it again. The roadmap row's trigger ("the first release that bundles breaking changes") is this wave's Release B — the removal lands there, including re-anchoring the counter-evidence test in gh421_no_plaintext_on_the_wire.rs as the roadmap entry already prescribes.

[mmeyerlein]

Removed per ruling R10 in 0bce623d (spec, versions and CHANGELOG in 2fa2e798) — not repaired.

The reasoning the ruling took from this report: the path was already deprecated and superseded by the sealed delivery, and the measurement here showed it had never worked. A mechanism with no users and no working delivery is not worth a migration.

Gone: the inject_map param field, the Injection type, the KNOWN entry, the parse block, injections(), and inject_all() together with its unlock emission. op_unlock no longer needs the sink and answers with locked and key_id. The inject_map slot is out of templates/access/vault/config.json too.

In place of the four deleted injection tests there is now one pin, the_injection_param_is_gone_and_an_old_config_says_so: a config that still carries the key fails loudly at spawn as an unknown param, instead of silently doing nothing — which is the honest failure mode for a key that used to be accepted.

The counter-proof branch. the_grep_would_find_a_plaintext_if_one_were_there in crates/meclaw-cells/tests/gh421_no_plaintext_on_the_wire.rs was already hung on vault.put rather than on inject_map — precisely because of this finding, when the pin was first built. So there was nothing to re-point; what moved with this change is the fixture line that set inject_map to {} and the doc comment explaining the choice, which now tells the story in the past tense. The control case still fires: 1 hit across 4 message_log rows, while the pin next door sweeps 34 rows and 30 blobs clean.

The roadmap line "params.inject_map entfällt" is resolved into docs/archive/roadmap-resolved.md, including the correction of its own assumption — it carried the trigger "the first release that bundles breaking changes" because it assumed removal would be a break, and the measurement disproved that.

The CHANGELOG lists it under Breaking anyway, and says why: the classification follows the surface, not the damage. The params of a shipped cell are public contract, so a key that was accepted yesterday and aborts the boot today breaks that contract — even when it hurts nobody, and that it hurts nobody is measured rather than assumed. Migration: delete the key from the vault config; whoever needs the value of a credential spends a grant on vault.deliver.

Gates: workspace 5518 passed / 0 failed / 9 ignored across 629 suites; clippy -D warnings, cargo fmt --check, cargo deny check licenses, both corridor byte gates, the claim and ADR-anchor gates all green.