Add optional Telegram run reporting to reusable workflows

[ineedjet]

Summary

Let reusable workflows optionally report what they did to a Telegram chat, so a human can watch which action was triggered and what was actually executed without digging through Actions run logs — faster debugging during development.

Motivation

Right now the only way to see what a reusable workflow (route-issue-shared.yml, collect-issues-shared.yml, collect-pull-requests-shared.yml, and the proposal-lifecycle jobs proposed in #11) actually did on a given run is to open the Actions log. That's slow feedback while iterating on a consumer repo, and there's no push notification when something unexpected happens (no-op, error, unexpected route, etc.).

Proposed shape

• Two new optional consumer-supplied values: a Telegram chat id (workflow_call input) and a bot token (workflow_call secret).
• When both are present, a shared notification step posts a message via the Telegram Bot API (sendMessage) reporting: which job/workflow ran, what triggered it (event, issue/PR number), and the outcome (action taken, no-op, or error).
• When either is omitted, behavior is unchanged today — fully opt-in per consumer, not a required input.
• Implemented once as a shared composite action/step rather than duplicated inline HTTP calls in each workflow, so every reusable workflow can adopt it the same way.
• A failure to deliver the Telegram notification must not fail the underlying workflow run.

Acceptance criteria

• telegram_chat_id (input) and telegram_bot_token (secret) are optional on the reusable workflows that adopt this; omitting both is a clean no-op, not an error.
• One shared step/action composes the report from job name, trigger context, and outcome — not copy-pasted per workflow.
• The bot token is never logged or echoed into workflow output.
• At least route-issue-shared.yml and one collect-*-shared.yml adopt it as reference implementations.
• A Telegram API failure is caught and does not fail the calling job.
• Documented in the README alongside the other reusable workflows.

Related

• Explore a persistent multi-channel agent runtime #7 already lists Telegram as one of several transports for a future persistent multi-channel runtime; this issue is a narrower slice scoped to today's ephemeral Actions workflows — outbound reporting only, no inbound commands.
• Add configurable process lifecycle hooks #6 covers hooking process outcomes to enqueue further agent work (fix/retrospective loops); this issue is a lighter-weight sibling — reporting an outcome, not acting on it.

[ineedjet]

Status: shipped for one consumer, adoption elsewhere still open

actions/telegram-notify is live as of v0.7.0 — #48:

• Optional chat_id/bot_token inputs; missing either is a clean no-op, not an error
• One shared composite action composes the report (job, action, status, details) rather than per-workflow copy-paste
• The bot token is never printed; a delivery failure is caught (::warning::) and never fails the calling job
• Wired into all five jobs of proposal-shared.yml (Extract reusable proposal and review primitives #11) as the first adopter

Not done yet:

• route-issue-shared.yml and a collect-*-shared.yml haven't adopted it — the acceptance criteria ask for at least one of each as reference implementations
• No standalone README section for the action itself (it's currently only mentioned inline under proposal-shared.yml's docs)

Leaving open until at least one more reusable workflow adopts it.