1 Commits (dev)

Author	SHA1	Message	Date
diffwireauto	15754624d5	fix(#999): offer the companion CLI console only on a 1.18 radio ... The companion "CLI console" entry was gated only on the target being a companion. A pre-1.18 radio, including Offband before the absorb, refuses a type-3 send: companion-v1.17.1 CMD_SEND_TXT_MSG accepts only plain and CLI_DATA and answers anything else with ERR_CODE_UNSUPPORTED_CMD (companion-v1.18.0 adds CLI_COMMAND). The connector only logs error frames, so the command waited out its mesh timeout and the console showed the #891 row, which blames the target for a limit of the user's own radio. - Gate: DeviceCliScreen.offersRemoteConsole requires a companion target AND a connected radio that speaks the 1.18 CLI (allowsCliFrame, the same check that gates the local Device CLI; type-3 send and frame 66 shipped together in 1.18). Disconnected or unclassified offers nothing. The chat menu uses it. - Fail fast: RemoteCliTransport fails the command at once with CliConsoleUnsupported when the radio refuses the send. The window arms only when the text frame is written (the onAttempt hook, after the path update) and closes on the command's SENT, which on 1.18 carries an expected-ack of 0. So an unrelated unknown-command refusal before the write, or a DM's SENT, cannot be pinned on this command. Dispose releases a command still waiting. - Console: a refused send shows "<command>: not sent. Your radio's firmware doesn't support remote CLI." (owner-approved), not the timeout row. Tests: the gate (positive and negative across populations, roles, and disconnected); fail-fast on the refusal, ignoring other codes, errors after the radio accepted the send, a DM's SENT, an error before the write, and dispose; the console row. Reviewed by a one-off Sonnet adversarial pass (Gemini budget down). Its Medium finding, that the window armed at run() before the write, is fixed here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	3 weeks ago