docs: record data-discord as deployed, and name both surfaces

AGENTS.md

@@ -8,7 +8,10 @@ the runtime, not in this checkout.
 
 - `agent/instructions.md` — Data's prompt. The source of truth; the live Zo persona is
   built from it. Change it here first.
-- `channels/http/` — the `data-http` service: `GET /health`, `POST /ask`.
+- `channels/http/` — the `data-http` service: `GET /health`, `POST /ask`. Data's brain,
+  reached over HTTP.
+- `channels/discord/` — the `data-discord` service: a thin Gateway bridge that forwards an
+  admitted mention to `channels/http/`, so both surfaces share one brain.
 - `channels/discord/` — the `data-discord` service: a thin Gateway socket that forwards
   admitted mentions into `channels/http/`. It carries no prompt and calls no model; it is
   transport, so Data keeps one brain.

README.md

@@ -14,7 +14,8 @@ here is Data's conversations and memory: those belong to the runtime.
 | Path | Contents |
 | --- | --- |
 | `agent/instructions.md` | Data's prompt. The source of truth for who Data is; the live Zo persona is built from it. |
-| `channels/http/` | Data's live surface: `GET /health` and `POST /ask`, deployed as the `data-http` Zo service. |
+| `channels/http/` | Data's brain over HTTP: `GET /health` and `POST /ask`, deployed as the `data-http` Zo service. |
+| `channels/discord/` | Data's Discord channel: a thin Gateway bridge, deployed as the `data-discord` Zo service, that forwards each admitted mention to `channels/http/`. |
 | `channels/discord/` | Data's Discord channel: a thin Gateway socket that forwards admitted mentions into `channels/http/`, deployed as the `data-discord` Zo service. |
 | `services/` | Durable records of the long-running processes that make Data reachable. |
 | `knowledge/` | Durable, verified knowledge: how a subsystem behaves, what a reproduction showed. |
@@ -36,9 +37,12 @@ A category directory is created when the first piece in that category lands.
   file reads, web search and browsing, conversation reads, and read-only views of
   hosting and settings. Data holds no write scope and no shell, so the read-only
   boundary is structural rather than a matter of instruction.
-- **Surface.** The `data-http` service in `channels/http/` routes questions into that
-  persona and returns the answer. `GET /health` reports readiness; `POST /ask` takes
-  `{ question, session? }`. The `data-discord` service in `channels/discord/` is the human
+- **Two surfaces, one brain.** The `data-http` service in `channels/http/` routes questions
+  into that persona and returns the answer: `GET /health` reports readiness, `POST /ask`
+  takes `{ question, session? }`. The `data-discord` service in `channels/discord/` holds
+  the Discord Gateway connection and forwards each admitted mention to `POST /ask` with a
+  `discord:<channel>` session, so Discord gets the same persona and the same continuity as
+  programmatic callers, and no second copy of Data's voice exists. The `data-discord` service in `channels/discord/` is the human
   front door: it holds the Gateway socket, and forwards each admitted mention to
   `POST /ask` with `session=discord:<channel>`, so both channels share one brain and one
   thread of memory.

services/discord.md

@@ -6,7 +6,7 @@ to Data's own HTTP ingress, so the brain stays in one place.
 
 | Field | Value |
 | --- | --- |
-| Zo service ID | `svc_X1tR9cq2PLm` |
+| Zo service ID | `svc__FQ0NilRSiI` |
 | Label | `data-discord` |
 | Mode | `process` (no network endpoint) |
 | Entrypoint | `bun run ./index.ts` |
@@ -17,9 +17,11 @@ to Data's own HTTP ingress, so the brain stays in one place.
 
 ## Environment variable names
 
-`DATA_DISCORD_BOT_TOKEN`, `DATA_DISCORD_APPLICATION_ID`, `DATA_DISCORD_GUILD_IDS`,
-`DATA_DISCORD_ROLE_IDS`; optionally `DATA_DISCORD_OWNER_IDS`, `DATA_DISCORD_CHANNEL_IDS`,
-`DATA_DISCORD_HTTP_URL`, `DATA_HTTP_TOKEN`, `DATA_DISCORD_BOT_USER_ID`. Values are never
+`DATA_DISCORD_GUILD_IDS`, `DATA_DISCORD_ROLE_IDS`, `DATA_DISCORD_HTTP_URL` in the service
+definition; `DATA_DISCORD_BOT_TOKEN` and `DATA_DISCORD_APPLICATION_ID` come from
+`/root/.zo_secrets`. Optional: `DATA_DISCORD_OWNER_IDS`, `DATA_DISCORD_CHANNEL_IDS`,
+`DATA_HTTP_TOKEN`, `DATA_DISCORD_BOT_USER_ID`, `DATA_DISCORD_GATEWAY_URL`,
+`DATA_DISCORD_API_BASE`. Values are never
 recorded here, and the identifiers (guild, channel, role, owner, application, bot user)
 are deliberately absent from this public repository — they live in the service
 definition and in `/root/.zo_secrets`.
@@ -50,6 +52,10 @@ bun run ./index.ts
 
 ## Verification
 
+- 2026-09-23 — all four workspace checkouts clean; registered as `svc__FQ0NilRSiI` and started.
+  It connects, reads its secrets, and then reports `4014 (disallowed intent(s))` with the
+  exact fix, backing off 300s rather than hot-looping: the channel is deployed and waiting
+  on the Message Content toggle, which is the only thing that keeps it from answering.
 - 2026-09-23 — the mention → `data-http` → reply loop was proven against a stub Gateway,
   a stub Discord REST API, and a stub `data-http`: the bridge identified, read a mention
   from a role-holding author, asked the ingress with `session=discord:<channel>`, posted