fix(issue-feed): correct IssueTriage bot uid case and add mention.uids

[lml2468]

Problem

Two bugs in the shared octo-issue-feed.yml reusable workflow, both traced to the Python script calling /v1/bot/sendMessage directly (bypassing the OpenClaw adapter layer).

Bug 1: mention.uids absent

The send() function did not include a mention field in the payload. WuKongIM received no structured mention, so IssueTriage relied on content-text fallback parsing in the adapter's inbound code to detect the @[uid:name] pattern.

Bug 2: Bot uid lowercase

triage_msg hardcoded 27pmzxx8nad78c9d01e_bot (all-lowercase). The correct value from POST /v1/bot/register (robot_id) is 27pmzxX8NAD78c9d01e_bot (mixed-case). The wrong value was introduced because it was copied from OpenClaw's internal canonicalizeAccountId output (which normalizes config keys to lowercase), not from the actual robot_id returned by the API.

Fix

• send() accepts optional mention_uids and includes payload.mention.uids when provided
• triage_msg uses the correct mixed-case uid 27pmzxX8NAD78c9d01e_bot
• send() call for TRIAGE passes mention_uids=['27pmzxX8NAD78c9d01e_bot']

Root cause analysis

Investigated by Octo助理-小明 and IssueTriage in group chat on 2026-05-18. Full trace:

canonicalizeAccountId('27pmzxX8NAD78c9d01e_bot') → '27pmzxx8nad78c9d01e_bot'
  → hardcoded into SKILL.md trigger pattern (also fixed separately)
  → hardcoded into this workflow's triage_msg
  → mention.uids absent (send() had no mention field)
  → adapter inbound added 3-layer fallback workaround (names 小明 explicitly in comment)

The adapter-side workaround (case-insensitive uid comparison + content-text @[uid:name] fallback) remains as a safety net but this PR fixes the actual source.

[yujiawei]

Code Review — PR #23 (.github)

Summary

Surgical, well-scoped fix for two bugs in the shared octo-issue-feed.yml reusable workflow:

1. send() now accepts an optional mention_uids and emits payload.mention.uids when supplied.
2. The hardcoded IssueTriage bot uid is corrected from the lowercase 27pmzxx8nad78c9d01e_bot to the canonical mixed-case 27pmzxX8NAD78c9d01e_bot.
3. The TRIAGE call passes the uid through mention_uids so the receiver sees a structured mention instead of relying on content-text fallback parsing.

The PR description includes a thorough root-cause analysis tracing the lowercase value back to an canonicalizeAccountId normalization leak — that context is valuable and matches the fix.

Verification

• ✅ The two non-TRIAGE send() call sites (feed_msg, proj_msg) keep their original 2-arg shape; with mention_uids defaulting to None, the emitted payload for them is byte-identical to today's, so existing channels are not impacted.
• ✅ Mixed-case uid is preserved verbatim because it lives inside a Python single-quoted string, not a YAML key — no YAML case-folding concern.
• ✅ The @[uid:name] text in triage_msg and the mention_uids list use the same uid value; sender's view and receiver's mention.uids are consistent.
• ✅ Search of the org (27pmzxx8nad78c9d01e / 27pmzxX8NAD78c9d01e) confirms this uid only appears in this one workflow — no sibling workflow needs the same correction.
• ✅ Existing safety controls remain intact: require_repo_name, require_group_id, API base allowlist, retry/backoff including Retry-After for 429, and 15s timeout. No new external input is introduced (the uid list is hardcoded), so no new injection surface.

Findings

P2 — Nit (non-blocking): duplicated magic uid

The string 27pmzxX8NAD78c9d01e_bot now appears twice in the file (once inside the @[...] mention text, once in the mention_uids=[...] list). Future renames would need to touch both. Optional follow-up: lift to a module-level constant, e.g.

TRIAGE_BOT_UID = '27pmzxX8NAD78c9d01e_bot'
...
triage_msg = (
    f'@[{TRIAGE_BOT_UID}:Octo 助理-IssueTriage] [TRIAGE] '
    f'https://github.com/Mininglamp-OSS/{repo}/issues/{num}'
)
send('151a45970e1546afa9e947ac36a5c4e5', triage_msg, mention_uids=[TRIAGE_BOT_UID])

Not blocking — current form is correct and the values are kept literally in sync within four lines of each other.

Observations (no action required)

• The adapter-side case-insensitive uid comparison plus @[uid:name] content-text fallback remains in place as a safety net per the PR description. That defense-in-depth is appropriate; this PR removes the need to rely on it, which is the right direction.
• The mention is sent only on action == 'opened', matching the previous behavior — no risk of re-pinging IssueTriage on closed/reopened/labeled.

Verdict

Approving. The fix is minimal, backward compatible for the two non-mention call sites, addresses a real interop bug at its source, and is consistent with the documented root cause.