chore(cli-version): verify agy against 1.1.20

[kaizhou-lab]

Moves VERIFIED_AGY_VERSION from 1.1.19 to 1.1.20.

Gate	Result
A — contract	DEGRADED — agy publishes no protocol schema; gate B carries the weight
B — live e2e	PASS 7/7, 171.02s
C — release notes	CLEAR — read from agy changelog on the candidate binary

What supports this bump

Gate B, 7/7 against a manifest-downloaded 1.1.20 whose sha512 was checked before it ran. The suite log reports only version=1.1.20, so it cannot be a green against a different binary.

Gate C read from agy changelog on the candidate itself, captured as changelog-from-cli.txt. The rendered web page is no longer the source — it has been frozen at 1.1.17 since 2026-08-22.

A retracted A/B

1.1.20’s notes say print mode stopped "treating benign tool execution errors and permission denials as fatal run failures". We drive that surface and deny tools routinely, so an A/B was attempted against what was believed to be a retained 1.1.19 binary. That attribution does not hold, and the comparison is retracted.

The two runs did differ — result.status was ERROR in one and SUCCESS in the other — but the "1.1.19" binary rewrote itself mid-probe. Its mtime is 02:02:48, the probe ran at 02:02, and its size is now byte-for-byte 1.1.20’s:

/tmp/agy-1.1.18   mtime=08:47:56  size=177913904  ver=1.1.18   <- untouched
/tmp/agy-1.1.19   mtime=02:02:48  size=179469984  ver=1.1.20   <- self-updated during the probe
/tmp/agy-1.1.20   mtime=08:26:49  size=179469984  ver=1.1.20

agy self-updates any copy of itself that is executed, including one in a temp directory under a version-named path. The path name is not a pin. So the ERROR may be 1.1.19’s behaviour or an artifact of a binary being rewritten under a running process, and nothing here separates them. It is not repeatable either: the manifest now serves 1.1.20 and no 1.1.19 binary exists here or on npm.

Both captures are kept in the record as probe-benign-tool-error-run-{a,b}.ndjson, renamed off their misleading version labels.

What is verified, by reading rather than by probe

translate.rs:80-86 maps the terminal frame, so a result.status other than SUCCESS becomes a failed turn for the user whatever emits it:

let is_error = !r.status.eq_ignore_ascii_case("SUCCESS");
match status {
    "SUCCESS"     => TurnOutcome::EndTurn,
    "INTERRUPTED" => TurnOutcome::Cancelled { .. },
    _             => TurnOutcome::Failed,
}

And the exit code the note talks about is not our channel: conn.rs:805 consults it only when no terminal frame arrived (if !saw_terminal), and result was emitted in both runs.

The other permission note does not reach us

Improved permission management by automatically granting workspace-scoped read access under the default review mode…

We never run in that mode: build_argv always passes --dangerously-skip-permissions (argv.rs:76), because agy cannot prompt headlessly, and AionUi gates each call in its own PreToolUse hook bridge. Stated limit: gate B does not exercise that bridge — its only permission test is claude’s — so this rests on the argv and the CLI’s own scoping, not on a live run.

Flag surface

--help 1.1.19 → 1.1.20 adds mic-serve and removes nothing; models --help is unchanged; all nine flags build_argv emits are still present.

Tests

Pinned assertions moved with the constant, including the literal verified-release case. cargo test -p aionui-session --lib cli_version: 14/14. Clippy clean, fmt clean.

Record: ~/aion/protocols/samples/antigravity-cli/1.1.20/

Constants and record only — no source change.