feat(bus): post activity-channel to Slack instead of never-configured Telegram

[asachs01]

Summary

• postActivity (src/bus/system.ts) now posts to Slack via SlackAPI instead of a Telegram bot that has never been configured anywhere in the fleet (verified absent 2026-08-15, 2026-09-03, 2026-09-08 — the [HUMAN] BotFather task has 6+ duplicate filings since 2026-07-16 with no progress: task_1786122601201_28151267)
• Text-only: postApprovalToActivityChannel (src/bus/approval.ts) drops the Telegram inline Approve/Deny keyboard — Slack's equivalent needs Block Kit + inbound interactive-payload handling that isn't built yet (socket-mode.ts currently only parses events_api envelopes) — and adds a "resolve via the dashboard" line instead
• Config shrinks to one new value: ACTIVITY_SLACK_CHANNEL_ID. Token is not a new secret — reuses SLACK_BOT_TOKEN from secrets.env, the same key the daemon's Socket Mode connection already uses
• Wired live for wyre against #agent-ops (verified empty before adopting — conversations.create for a fresh #org-activity channel came back missing_scope: channels:manage on the available token)
• Boss-approved: msg 1788869841715-boss-xmbgu, task task_1788869860840_01459423

Test plan

• npx tsc --noEmit clean
• npm run build succeeds
• Updated unit tests (tests/unit/bus/system.test.ts, tests/unit/bus/approval.test.ts) — 73/73 passing
• Live end-to-end: cortextos bus create-approval through the built CLI created a real approval, message verified present in #agent-ops via conversations.history, then deleted (chat.delete) and the test approval rejected — no residue left in Slack or the approvals store

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: 49b858db-81f7-46a5-a92f-1e465985e852

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[asachs01]

Reviewed. Correctness on the two call sites is solid — verified against the actual dependencies rather than trusting the diff in isolation:

1. postActivity's catch-returns-false relies on SlackAPI.postMessage throwing on ok:false — confirmed against src/slack/api.ts's call(), which does throw slack ${method}: ${error} on !json.ok. The "Slack API call fails" test is exercising real behavior, not an untested assumption.
2. parseEnvFile is a strict superset of the old hand-rolled parser (adds BOM/CRLF handling, quote-stripping, inline-comment-stripping) — no regression.
3. Minor positive behavior change: the old code stopped at the first existing candidate path regardless of whether it had the target key; the new loop continues past an existing-but-keyless file to the next candidate. More correct, worth a one-line mention in the PR body since it's an actual (if small) semantic change.

On the _replyMarkup design question: remove it outright. Grepped every call site on this branch — zero callers pass a 5th argument anymore, so there's no live signature-compat need, and the current object type wouldn't help SP3c anyway (Slack Block Kit is a different shape).

One finding beyond what was asked, not a blocker given the PR's stated scope: this PR removes buildApprovalKeyboard, the only producer of appr_allow_*/appr_deny_* callback_data in the repo, but leaves the full consumer chain wired: agent-manager.ts's maybeStartActivityChannelPoller (still starts a Telegram poller on ACTIVITY_BOT_TOKEN/ACTIVITY_CHAT_ID), fast-checker.ts's handleActivityCallback (line 609, still parses the old prefix), and bus/post-activity.sh (still documents the Telegram-only flow). Per the PR's own CHANGELOG these Telegram vars were never configured fleet-wide, so this isn't a live regression — but it's now orphaned code with no possible input. Worth a follow-up cleanup task. Same family, smaller: src/cli/init.ts's org scaffold (~line 128) still writes the old ACTIVITY_CHAT_ID= key and doesn't scaffold ACTIVITY_SLACK_CHANNEL_ID.

LGTM given the stated scope — recommend filing the orphaned-inbound-chain cleanup as a separate follow-up rather than blocking this PR on it.