fix(cli): the run record kept a tier the run had not achieved

[AminChirazi]

The last of the three places that read a predicted tier instead of the achieved one. #345 fixed the printed report and the --json payload; the run record — the artifact an auditor actually keeps — still called agent_flow::containment(spec) for itself.

This one costs evidence, not just a label

containment is read twice in build_control_record: once as the record's own tier line, and once to decide whether the blocked lane is evidence at all. So the two tiers disagreeing decides whether the destinations a run refused are carried or discarded — and it fails in both directions:

• an optimistic probe over a run that was not contained presents destinations nothing on this run blocked;
• a pessimistic probe over a run that was contained throws away the only proof that run produced.

The achieved tier is now passed in. None for a step-engine flow, which has no agent run to ask.

The test asserts the pessimistic direction, and that is a retreat

Stating this plainly because the PR would otherwise look like it tests the wrong thing.

The interesting production case is the opposite one: a Windows run that was contained, over a probe predicting otherwise. It cannot be made falsifiable here. This suite runs on Linux, where the probe already answers Enforced — so a test asserting "the achieved Enforced won" passes identically when the achieved tier is ignored altogether.

I wrote it that way first. It survived the mutation, which is the definition of a test that proves nothing, and it would have shipped as a green tick that was never asked a question.

Turned around, it pins the half that can fail on this platform, and that half is the safety-critical one: an uncontained run must not inherit an optimistic probe's evidence. The test also asserts up front that the probe and the run genuinely disagree on this host, so it fails loudly rather than silently going vacuous somewhere the probe answers differently.

Mutation-checked in that direction: making build_control_record ignore the achieved tier fails it.

The fixture guard earned its keep again

The first draft wrote the cassette as [] rather than {"turns": []}. The lane failed to parse, so blocked came back empty — and the emptiness assertion would have passed for entirely the wrong reason. The guard that the neighbouring test added after exactly this bug caught it immediately.

Verification

• cargo test --workspace --all-features — green
• cargo fmt --check — clean
• ratchets — diff size 117 <= 400, tests 775 -> 776, nothing silenced

With this, all three readers of the containment tier — stdout, --json, and the run record — report what the run achieved.

---

Generated by Claude Code

[Copilot]

Pull request overview

Updates the CLI’s run-record generation so containment tier and blocked-evidence attribution can be based on what the run actually achieved (rather than only the host probe prediction), addressing audit-evidence correctness.

Changes:

• Adds an achieved: Option<&Containment> parameter to build_control_record and prefers it over agent_flow::containment(spec) when present.
• Threads achieved containment into the single-spec agent run path (cmd_run) and updates other call sites with None.
• Adds a regression test asserting that an uncontained achieved tier does not inherit blocked evidence from an optimistic probe/fixture.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.