**Note** from Bead: Slack Integration · [canonical source](https://redfish.acequia.io/guerin/.agents/c915581b-4179-409e-9e13-085531521fd9/2026-06-22/notes/02-debbie-slack-acequia-sketches.md) · session 2026-06-22 · discussion: Talk: Slack Integration
Rough, rendered, interactive sketches (sketch-ux mode, Buxton: the design lives in the **transition**) for the team who lives in Slack today. They answer two questions Stephen posed: **(a) what is going on now**, and **(b) how we eventually migrate off Slack**. The frame is fixed from 01-auth-goes-inta-goes-outa: **acequia is the core, Slack is peripheral; auth lives at the membrane** — *goes-inta* (ingest) and *goes-outa* (egress) — riverbed-and-gates, not a reified connector. Each parciante runs the bridge under their **own** Slack user token. Running theme: **every constraint is soft** — the migration is a desire-line being paved, reversible at each step. **Rendered file:** https://redfish.acequia.io/guerin/.agents/c915581b-4179-409e-9e13-085531521fd9/2026-06-22/artifacts/sketches/slack-acequia-agent-sketches.html Each card poses ONE question with clickable forks (flip the stage) and a ▶ replay transition, plus an answer row that PUTs `{card, question, choice, notes}` JSON to this bead's dock `uploads/answers/` (ambient cookie / locally-pasted bearer; on 401 it offers the JSON for a manual drop — no embedded write token in a public sketch).
## The five cards ### S1 — What IS the agent? - **Question:** is the bridge a **thin CLI you invoke**, a **standing agent-bead with a dock** that watches/mirrors on demand, or a **Slack bot that pushes events**? - **Forks:** `1A CLI adapter` · `1B agent-bead + dock` · `1C Slack bot pushes`. - **Transition:** a message (📎 Q2-draft.pdf) sits in a Slack channel and a packet flies across the *goes-inta* gate into `people/Graydon/newsletter/`. The trigger differs by fork: 1A waits for you to press ▶ run, 1B's dock pulls on demand, 1C fires the instant the message lands (no human in the loop, no per-message control). ### S2 — Direction & trust at the gate - **Question:** is the membrane **goes-inta only** (read, safe, one-way) or **bidirectional** with goes-outa write-back? Trade-off: **blast radius vs. actually leaving Slack**. - **Forks:** `2A goes-inta only` · `2B bidirectional`. - **Transition:** a file crosses the membrane IN (`files:read`); in 2B a second file crosses OUT (`chat:write`/`files:write`). 2A draws the outa lane closed (you can never post from acequia, so you never leave Slack); 2B pays for egress with bigger scopes. ### S3 — What the team SEES - **Question:** how is a mirrored channel represented? A **folder of files + thread.md**, a **live dashboard**, or a **per-person inbox**? - **Forks:** `3A folder + thread.md` · `3B live dashboard` · `3C per-person inbox`. - **Transition:** a Slack channel resolves into the chosen view — 3A files in stagger into a directory (PDF + `.slack.json` provenance + a readable `thread.md`); 3B one live HTML panel fades in; 3C only items addressed to you appear, the rest stay quiet. ### S4 — The migration arc *(centerpiece, full-width, phase scrubber)* - **Question:** how do we leave Slack — **hard cutover**, **gradual read-first**, or **gradual post-first**? - **Forks:** `4A hard cutover` · `4B gradual read-first` · `4C gradual post-first`. - **Transition:** a **phase scrubber** (P0 today → P1 mirror → P2 read here → P3 post here → P4 archive) drives the **Slack box shrinking** (purple) while the **acequia box grows** (green); the *outa* lane lights up once acequia takes posting. The fork changes the *shape* of the curve — 4A is a single hard FLIP at the midpoint (the team lands in a half-built namespace, no fallback); 4B is a gentle accelerating ramp that holds at each phase because it is **soft / reversible**; 4C lets acequia lead on posting early, leaning on egress scopes up front. ▶ replay animates the whole arc. ### S5 — Identity at the gate - **Question:** per-parciante **own token** (`xoxp-`, self-sovereign) or a **shared service identity** (one admin bot)? - **Forks:** `5A own token each` · `5B shared service id`. - **Transition:** in 5A two people's own tokens light up **only their own** channels (membership-scoped; channel #6 nobody's stays dark); in 5B one central bot reaches into **all** channels at once (one big revocable-by-nobody blast radius).
## First-cut recommendation **S1-B · S2 bidirectional-but-staged · S3 folder + thread.md · S4 gradual read-first · S5 own-token.** A **standing agent-bead with a dock** (not a CLI you must remember, not a bot that floods you) mirrors Slack **on demand** into a **folder of files + a thread `.md`** per channel. It defaults to *goes-inta* read-only with *goes-outa* as an explicit, staged second leg. Migration is **gradual, read-first**: mirror → team reads in the namespace → posting shifts over → Slack demotes to a write-through gateway → archive. Identity stays **per-parciante own-token**: you see exactly your channels, you revoke yourself, no admin bottleneck. This composes directly with the worked example already run (the Q2-draft PDF copied with its `.slack.json` provenance) and with the `slack-to-acequia.mjs` adapter.
## The one un-pre-decided question for Stephen / the team **When does goes-outa become the default — and who flips it?** Read-first migration is safe, but the team only truly leaves Slack when **posting** happens in acequia first and write-throughs back to Slack. Is that a **per-person switch** each parciante throws when ready (soft, ragged, honest), or a **team-wide phase** the mayordomo declares once a quorum has migrated? That is the real fork — answerable inside **S4**.
## Links - Frame: 01-auth-goes-inta-goes-outa - Design: [00-slack-integration-design.md](https://redfish.acequia.io/guerin/.agents/c915581b-4179-409e-9e13-085531521fd9/2026-06-22/notes/00-slack-integration-design.md) - Onboarding: [get-slack-user-token.md](https://redfish.acequia.io/guerin/.agents/c915581b-4179-409e-9e13-085531521fd9/2026-06-22/skills/get-slack-user-token.md) - Method: [sketch-ux SKILL](https://redfish.acequia.io/skills/sketch-ux/SKILL.md)