Summary

• Problem: Telegram polling startup diagnostics were routed through the monitor error logger.
• Why it matters: healthy polling startup looked like a gateway error in console output and could trigger false alarms.
• What changed: normal [telegram][diag] monitor/polling diagnostics now use runtime.log, while non-diag [telegram] warnings/errors and offset persistence/delete failures stay on runtime.error.
• What did NOT change (scope boundary): Telegram polling, webhook, offset, retry, and transport behavior are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Telegram polling startup diagnostic is logged at error level #82957
• Related #
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior addressed: Telegram polling startup emits the normal [telegram][diag] polling cycle started ... diagnostic through the normal log channel instead of the error channel, while non-diag [telegram] warnings/errors remain on the error channel.
• Real environment tested: Local checkout running the Telegram monitor seam with the repo's Telegram Vitest project config.
• Exact steps or command run after this patch: node scripts/run-vitest.mjs extensions/telegram/src/monitor.test.ts
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): Terminal capture from the passing run shows the startup diagnostic on stdout, not stderr, and the restart warning test preserves non-diag output on runtime.error:

Test Files  1 passed (1)
Tests  34 passed (34)

• Observed result after fix: The regression test logs polling startup diagnostics without using the error channel passes, the regression test keeps polling restart warnings on the error channel preserves non-diag warning output on runtime.error, and the full Telegram monitor test file reports 34 passed (34).
• What was not tested: A live Telegram bot/gateway session was not run because the local evidence is a log-severity routing bug at the monitor seam and live credentials are not available in this workflow.
• Before evidence (optional but encouraged): Redacted original evidence showed the normal startup diagnostic rendered with error coloring:

"[telegram] [diag] polling cycle started inFlight=0 outcome=not-started startedAt=n/a finishedAt=n/a durationMs=n/a offset=n/a"
rendered with ERROR coloring in console output.

Root Cause (if applicable)

• Root cause: monitorTelegramProvider collapsed all polling monitor output to opts.runtime?.error ?? console.error, and TelegramPollingSession sends normal lifecycle diagnostics through the injected logger.
• Missing detection / guardrail: There was no monitor-level assertion that normal polling startup diagnostics avoid the error channel or that non-diag warnings remain on the error channel.
• Contributing context (if known): The lower-level polling session only receives a simple line logger, so the severity decision belongs at the monitor boundary.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/telegram/src/monitor.test.ts
• Scenario the test should lock in: Starting the polling monitor logs polling cycle started via runtime.log and does not call runtime.error, while non-diag polling restart warnings still call runtime.error.
• Why this is the smallest reliable guardrail: The bug is at the monitor-to-polling logger wiring boundary, not in Telegram networking or polling behavior.
• Existing test that already covers this (if any): None before this PR.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Normal Telegram [telegram][diag] polling startup diagnostics no longer appear as error-level console output. Non-diag Telegram warnings/errors remain error-level output.

Diagram (if applicable)

Before:
Telegram monitor -> polling session diagnostic -> runtime.error -> error-colored startup line

After:
Telegram monitor -> [telegram][diag] polling session diagnostic -> runtime.log -> normal startup line
Telegram monitor -> non-diag [telegram] warning/error -> runtime.error -> error output
Persistence failures -> runtime.error -> error output

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Local checkout
• Runtime/container: Node v24.15.0 for local test execution
• Model/provider: N/A
• Integration/channel (if any): Telegram plugin polling monitor
• Relevant config (redacted): Test fixture with isolated ingress disabled

Steps

1. Run the Telegram monitor with an injected runtime logger.
2. Start one polling cycle.
3. Inspect runtime log and error calls.

Expected

• polling cycle started is logged through runtime.log.
• runtime.error is not called for normal [telegram][diag] startup diagnostics.
• Non-diag [telegram] warnings/errors remain on runtime.error.

Actual

• Before this patch, the monitor's injected logger was runtime.error.
• After this patch, the monitor logger routes [telegram][diag] lines to runtime.log; the regression tests confirm runtime.error is untouched for startup diagnostics and still receives non-diag restart warnings.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Full Telegram monitor test file passes locally with the Telegram-specific Vitest config.
• Edge cases checked: Offset persistence/delete error paths still call logError/runtime.error; [telegram][diag] diagnostics use runtime.log; non-diag [telegram] warnings/errors remain on runtime.error.
• What you did not verify: Live Telegram bot polling against Telegram API.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Normal [telegram][diag] Telegram monitor diagnostics become less visually prominent.
  • Mitigation: Actual non-diag warnings/errors and offset persistence/delete failures still use runtime.error; the changed startup line is explicitly a normal lifecycle diagnostic.