telegram_ask result must report which surfaces the question was posted to and which surface answered

[TerrifiedBug]

This was generated by AI during triage.

Reported from TerrifiedBug/conductor#114, after the mount and answer-routing paths were repaired and verified on the recovered live fleet in omp-telegram@0.11.4. The remaining defect is in the tool-result contract.

Observed

telegram_ask renders a question on both the interactive terminal and Telegram, then returns whichever answer arrives first. Its result reports the answer but not:

• which surfaces successfully received the question;
• which surface supplied the answer; or
• whether posting to one surface failed while another remained usable.

On 2026-08-13 the recovered conductor fleet made two telegram_ask calls that returned answers. The operator later reported that neither question had arrived on Telegram; he had answered at the terminal, where both questions also rendered. The caller had no way to distinguish that from a successful Telegram round trip. Even asking "did this arrive on Telegram?" through the tool proved nothing because the terminal displayed and answered the same question. Full evidence: conductor#114 comment.

A failed Telegram post can therefore succeed silently as a terminal-only ask. A headless or away-mode caller may believe the operator was reached when the only rendered surface was unattended.

Requested contract

The telegram_ask result should:

1. enumerate every surface on which the question was successfully posted (for example, terminal and telegram);
2. identify the surface that supplied the accepted answer; and
3. report a loud, per-surface posting error when Telegram delivery fails instead of presenting terminal-only success as an unqualified successful round trip.

The exact field names are not important. The result must let callers distinguish answered from delivered and must preserve partial-delivery evidence.

Acceptance

• dual-surface + terminal answer reports both posted surfaces and terminal as the answer origin;
• dual-surface + Telegram answer reports both posted surfaces and Telegram as the answer origin;
• terminal-only operation reports only terminal;
• Telegram post failure is explicit in the result even when the terminal remains usable;
• focused tests pin those four result shapes.

Not asking for

No change to answer routing, mounted-tool discovery, or the rule that cancellation/error is not an answer. Those paths are already fixed; this issue is only about truthful delivery and answer provenance in the tool result.

[TerrifiedBug]

Live verification of the merged contract failed after publishing and deploying omp-telegram@0.11.5 to Hermes. The restarted fleet session rendered LIVE115 only in its terminal; no Telegram question arrived. Provenance correctly exposed the defect as posted:["terminal"] with no Telegram error, proving no Telegram post was attempted.

The failure is deterministic locally: a resumed daemon session with a hydrated token and paired owner, but no pre-resolved prompt target, executes telegram_ask with an interactive terminal and reports only terminal. Root cause: paired-owner fallback is guarded by !canTerminal, even though explicit telegram_ask should use every available surface. A regression test now goes red on that exact shape and green when the fallback is allowed alongside the terminal. The follow-up PR and release will close this only after another live Telegram-origin smoke succeeds.

[TerrifiedBug]

Live acceptance now passes on Hermes after publishing and deploying omp-telegram@0.11.6 and restarting the fleet into the same resumed session. The operator sent the fresh LIVE116 prompt to the fleet and answered its Telegram button. The raw tool result was:

Ask provenance: {"posted":["terminal","telegram"],"answeredBy":"telegram","errors":{}}
User selected: CONFIRM-LIVE-116

This proves both surfaces received the question and Telegram supplied the accepted answer. PR #54 fixed the resumed/custom-turn target fallback; PR #55 released 0.11.6. Closing with live evidence.