The Telegram feed path appears to have a contract mismatch between the edge relay endpoint, the browser UI model, and the public intelligence API.

What I found:

• /api/telegram-feed proxies the relay response body through unchanged.
• The browser-side Telegram service/panel expects items[] with fields like ts, url, and channelTitle:
  • src/services/telegram-intel.ts
  • src/components/TelegramIntelPanel.ts
• The server/public API defines messages[] with fields like timestampMs, sourceUrl, and channelName:
  • server/worldmonitor/intelligence/v1/list-telegram-feed.ts
  • docs/api/IntelligenceService.openapi.yaml

Why this matters:

• The browser code currently does a plain cast after res.json() and does not normalize or validate the payload shape.
• If the relay returns the documented server-style shape (messages[]), the panel reads response.items || [] and silently shows an empty list / zero count.
• Even beyond the top-level array name, the item field names differ enough that the panel cannot consume the API model directly.

Related issue:

• api/telegram-feed.js also checks only parsed.items when deciding whether to apply the “empty feed” short cache TTL, so a non-empty messages[] payload may be cached as if it were empty.

Suggested fix:

• Pick one canonical raw Telegram payload shape.
• Add an explicit adapter for the browser panel instead of relying on a TypeScript cast.
• Make the edge proxy/cache logic understand the canonical shape.
• Add regression tests for:
  • browser mapping from raw Telegram payload -> UI model
  • server/API handler mapping from relay payload -> ListTelegramFeedResponse

I did not verify the live Railway relay payload, so the main problem here is repo-internal inconsistency: the UI contract and the API contract currently disagree.