Add a controlled Discord channel for Computer

[EthanThatOneKid]

Goal

Give the Wazoo team a durable Discord presence for Computer without changing the TNG-inspired identity or weakening action boundaries.

Requirements

• Use the supported Eve/Chat SDK Discord integration if available; otherwise isolate the adapter behind a channel module.
• Respond only in explicitly configured guilds/channels and to explicit @Computer mentions or approved commands.
• Map Discord guild, channel, and user identity into an Eve principal/session so conversations do not leak across contexts.
• Preserve approval gates for public, destructive, or externally communicative actions.
• Keep the bot token in deployment secrets; never commit credentials.
• Add reconnect/error handling, health visibility, and a focused test or local harness.
• Document setup, allowed-surface configuration, and operator controls.

Dependency

Computer's initial identity and authenticated web access are implemented in PR #2. This issue is the next channel milestone; it is intentionally separate from the identity slice.

[EthanThatOneKid]

Clarification: multi-purpose access model

Computer's Discord presence should support two deliberately separated policy tiers:

1. Public/customer-support tier — available only in explicitly allowlisted public support channels; read-only with respect to Wazoo systems and public-safe knowledge; no private memory, repository mutation, outbound messaging, or elevated tools.
2. Internal team tier — available only when the guild/channel is allowlisted and the mentioning user's Discord identity and roles map to an authorized internal policy. This tier may expose approved internal context and tools, still subject to server-side approval gates for destructive, public, or externally communicative actions.

Authorization should be computed from the full request context: bot mention/command, guild, channel, user ID, and current roles. Channel alone should not grant elevation, and a user's role alone should not grant access outside an allowlisted channel. Default deny, fail closed, and keep public and internal sessions/context isolated. The bot should never reveal internal context merely because it was mentioned in a public channel.

[EthanThatOneKid]

Requirement mapping: PR #14

Every requirement in this issue and in the two-tier clarification is implemented in PR #14. Nothing agent-side remains open.

Base requirements

Requirement	Where it lands in PR #14
Supported Eve/Chat SDK Discord integration first, adapter isolated behind a channel module otherwise	eve's native discordChannel from the registry (implementation: native), wired in agent/channels/discord.ts. Registry-first per AGENTS.md
Respond only in explicitly configured guilds/channels, to explicit commands	Admission via onCommand in agent/channels/discord.ts. The native surface is slash-command-based, so every dispatch is an explicit command. Unlisted guilds, unlisted channels, and DMs resolve to null and never dispatch. Mentions are deliberately not wired because they require the privileged message-content intent, and the spec's "commands or mentions" disjunction is satisfied by commands
Map guild, channel, and user identity into an eve principal/session so conversations do not leak across contexts	Each dispatch builds a SessionAuthContext with tier-scoped principal ids (discord-public:<user> / discord-team:<user>), authenticator: "discord", and attributes for tier, user, channel, guild, roles. Distinct principals per tier mean sessions and context cannot cross tiers
Preserve approval gates for public, destructive, or externally communicative actions	eve HITL renders as Discord components natively. Instructions and standing preferences keep the gated action classes behind human approval. Internal replies are ephemeral so internal context does not linger in shared channels
Bot token in deployment secrets, never committed	No credentials anywhere in the diff. Documented paths: guided Connect setup (token held by Vercel Connect) or DISCORD_APPLICATION_ID / DISCORD_BOT_TOKEN / DISCORD_PUBLIC_KEY deployment secrets
Reconnect/error handling, health visibility, focused test or local harness	Webhook-based Interactions flow has no persistent socket, so reconnect handling does not apply; signature verification, retries, deferred replies, and message splitting come from the native channel runtime. Health is visible through Vercel deployment checks and the /eve/v1/discord route. lib/discord-policy.test.ts covers the admission matrix: 12 node:test cases, all passing, pnpm test
Document setup, allowed-surface configuration, operator controls	README "Discord channel (staged)" section: operator setup checklist, the six allowlist environment variables, the policy summary, and kill-switch controls (clear the allowlists or remove the channel file to silence the bot everywhere)

Clarification requirements (two-tier access model)

Clarification requirement	Implementation
Public tier only in allowlisted public support channels, read-only over Wazoo systems, public-safe knowledge	Public branch of resolveDiscordAccess in lib/discord-policy.ts: public guild AND public channel, nothing else. The tier line in session context states the restriction to the model
Internal tier only where guild/channel is allowlisted and the user's identity and roles map to an authorized policy	Internal branch: internal guild AND internal channel AND (allowlisted user OR allowlisted role). Tested from both directions
Authorization computed from full request context: guild, channel, user id, current roles	The policy takes all four inputs on every call. No static admission
Channel alone should not grant elevation, role alone should not grant access outside an allowlisted channel	Both directions tested: an internal channel with no allowlisted identity denies, an allowlisted role in a non-internal guild denies
Default deny, fail closed	Any unmatched condition returns null. DMs can never match (no guild). Fail-closed behavior pinned by tests
Public and internal sessions/context isolated	Distinct principal ids per tier, tier carried in attributes and context, ephemeral internal replies
Never reveal internal context merely because it was mentioned in a public channel	Public channels cannot reach the internal branch by construction, and public-tier sessions carry a distinct principal

Known gap, tracked

The public tier's "no private memory, repository mutation, outbound messaging, or elevated tools" is enforced at prompt level (tier context line plus instructions), not yet server-side per tool. Tracked as #16 with the design scope written. Not blocking this issue: the public tier stays dark until the operator configures allowlists, and the tracer path is internal.

What remains before close

1. Merge PR feat: stage a controlled two-tier Discord channel #14.
2. Operator-supplied live verification: create the Discord application, run the guided Connect setup or set the three deployment secrets, register /ask, configure the six allowlists, and confirm one admitted command per tier plus one denied interaction. This is the only piece an agent cannot do, per the standing rule that external mutations are human-gated.

Once those two are done this issue closes complete. If the operator prefers, live verification can be split into its own ticket and this issue closed on merge, since all buildable scope is delivered and verified by tests.

[EthanThatOneKid]

Closing: shipped. PR #14 implemented every requirement here plus the two-tier access model, and the mention path (#67) and guild-wide admission (#89) extended it after that. The one open thread from the clarification — server-side enforcement for the public tier — is tracked in #16, which is where public surfaces stay gated.