fix(tools): chat_id schema accepts negative IDs (groups/channels)

[claudiusthebot]

Summary

PR #150 shipped heartbeat outbound send / react with two bugs that compound — surfaced together by the canonical PR #150 / #151 test path Dylan asked the next heartbeat to exercise (send(chat_id=-1001426819337) to Pandario at 2026-05-12 18:13Z):

1. Schema rejects negatives. chat_id: idSchema, but idSchema enforces .positive() — designed for message/user/reply IDs. Telegram supergroup/channel chat IDs are negative. First call failed at the zod layer with expected number, received string.
2. send.execute strips chat_id. Even after the schema accepts it (e.g. for a positive DM chat_id like 352042062), send.execute builds per-case explicit bridge payloads that all OMIT chat_id. createBridge reads params.chat_id from the bridge payload, not the tool-input params, to promote to _chatId — so chat_id never reaches the gateway and the gateway rejects with "No active chat context and no explicit numeric chat_id".

Both ends of the chain — gateway routing (gateway-http.test.ts:343-401, already tested) and bridge promotion (createBridge at bridge.ts:29) — were correct. The break was the two MCP-tool-layer hops.

react was unaffected by #2 — it uses bridge("react", { ...rest }) with the full param spread (minus end_turn), so chat_id passes through naturally.

Changes

Commit 1: schema accepts negative chat IDs

• New chatIdSchema in src/core/tools/schemas.ts — union of non-zero signed integer OR signed-integer string. Accepts both negative (group/channel) and positive (DM/user) chat IDs. Rejects zero (gateway already treats it as falsy-unrouted), non-integers, non-numeric strings, booleans, null, whitespace-padded strings.
• src/core/tools/messaging.ts — send.chat_id and react.chat_id now use chatIdSchema. Field descriptions mention the negative-supergroup convention. idSchema itself is unchanged.
• 24 schema tests (chat-id-schema.test.ts) — pin accept/reject contract, including the exact -1001426819337 from Dylan's test.

Commit 2: send.execute threads chat_id to every bridge call

• src/core/tools/messaging.ts — every bridge() call inside send.execute now includes chat_id: params.chat_id. Local chat_id hoisted out of the switch for consistency across all 14 sites (text plain / scheduled / buttoned, photo, file, video, voice, audio, animation, sticker, poll, location, contact, dice). Comment block at top of execute documents the contract.
• 16 pass-through tests — for every type case, send.execute calls bridge with exactly one action AND payload contains chat_id verbatim. Uses a captured fake-bridge spy, no network.

Test plan

• npx tsc --noEmit clean
• npx prettier --check clean on all 3 changed files
• npx vitest run on chat-id-schema + tool-id-coercion + gateway-http + bridge + compose-tools → 340/340 pass
• Existing tool-id-coercion tests confirm idSchema is unchanged — message/user/reply ID fields still get the strict positive contract
• Existing gateway-http negative-chat_id tests still pass

Follow-up

After this lands, the heartbeat outbound test should succeed in any group OR DM. The long-tail tools tracked in #149 (list_chats, plus chat_id on edit_message, delete_message, pin_message, read_chat_history) should use chatIdSchema from the start, and any new bridge() call in send.execute (e.g. new media types) must remember to forward chat_id — the new comment in execute documents this.

Surfaced-by: 2026-05-12 18:13Z heartbeat outbound test (Dylan)

🤖 Generated with Claude Code