Source document copied on 20 October 2026. Its dated evidence and limitations remain as written. Feedback and decisions can be given in chat.

Slack surface for the JR overhaul: source review, 2026-10-20

This is a source review and planning checkpoint, not a live integration pass. It is aligned to Astra's draft spec and tickets, which I read without editing. I made no Slack call, read no token, changed no scope, install or membership, ran no test and made no commit. Astra owns the spec, the tickets, the visual and the commit of this file. The sources and their revisions are in the source index, and the 340-method inventory is in the TSV.

Run by claude-haiku-5-5. The launching process's arguments read --model claude-haiku-5-5 --effort xhigh. That shows the requested model and effort flags. It does not show the effort applied to each call.

The slack-plugin-vs-yours doc is not in this worktree, the JA repo, the agent-setup repo or the orca workspace, so I could not compare against it.

Summary

• JR uses existing Lists and needs no new List. Calls on the existing Lists need lists:read or lists:write on the calling token, and neither token in the supplied readback has them. A later scope or access grant is a permission change. It needs exact approval after app inspection.
• The native event ID binds into the existing Work record. WobOS already has an exclusive-create record keyed by task ID and a turn lock. The event ID becomes a receipt on that record, with no new table and no timer.
• Bolt acks Events API listeners before their handler runs. That changes what Slack's retry can recover. The details are in the Bolt section.
• The conversations.replies token rule is not stated on its page. The published rule sits on conversations.history. Treating the replies page as the same is an inference, and the checkpoint should test it.
• No List change event appears in the Events index I read. That is a source finding, not a claim the API cannot emit one. JR refreshes Lists on relevant requests and authorized continuations, not on a new timer.

Identity and scope readback

SLACK_JA_OPS_BOT_TOKEN is the Keychain service label for the bot token. Astra's auth.test on that token resolved to justanotheragent (U0BRM7JT8F4) in T0AUYDT2V2B. So the bot identity is one observed token, and this note does not treat it as a second app. The bot app's ID and its event and interactivity settings are still unread. That is app inspection at implementation time.

The table below uses the readback supplied on 2026-10-20. "Not in readback" means the full scope header did not list that scope. No service call has tested it, so nothing here shows a scope is rejected.

The Socket Mode contract

Socket Mode is the native transport this review recommends. Here is the contract as the docs state it.

1. The app calls apps.connections.open with the app-level token (xapp-, scope connections:write), sent in the Authorization header. The page says a POST parameter errors. Slack returns a WebSocket URL.
2. The app connects. Slack sends a hello envelope, then pushes events_api envelopes and interactive envelopes (block_actions, view_submission and similar).
3. Each envelope carries an envelope_id. The app acknowledges by replying with that ID. The Socket Mode page says the ack is how Slack decides whether to retry.
4. Disconnects come as warning (about 10 seconds' notice), refresh_requested, or link_disabled when Socket Mode is switched off in app settings.
5. Interactivity is an app setting, not a scope. The starter's manifest carries settings.interactivity.is_enabled.

The starter's entry point shows the split between the two tokens:

app = App(token=os.environ.get("SLACK_BOT_TOKEN"))
...
SocketModeHandler(app, os.environ.get("SLACK_APP_TOKEN")).start()

The bot token identifies the app for every Web API call the App makes. The app-level token only opens the socket. Without connections:write on the app-level token, the socket fails to open, and the bot's Web API calls still work.

The starter is the reference for that shape, not something to run. Its sample scopes and events are replaced by JR's set, and the work happens in the isolated WobOS slice. Running it unchanged in a live workspace is not part of this plan.

HTTP is the alternative that was not chosen. The comparison shows why.

The 3-second deadline is written for HTTP. The Socket Mode page states no deadline.

What Bolt does with an envelope

This comes from Bolt for Python at 649cfc8632254559d4ad133c99b02d60f1b0d15f, read as source. Astra's subsequent source check found no Slack/Bolt dependency in the candidate's pyproject.toml or uv.lock. Adoption and qualification of a concrete version belong to the later implementation.

The Socket Mode handler calls run_bolt_app, which calls App.dispatch. Then send_response acks the envelope, but only when the response status is 200. Any other status gets logged and nothing is sent. The Socket Mode adapter also copies Slack's retry_attempt into the x-slack-retry-num header, so listeners see retries the same way they do over HTTP.

Listener registration sets one of two acknowledgment paths.

• Events API listeners (event() and message()) register with auto-ack on (app.py lines 855 and 916). The thread runner calls ack() before the handler starts, and then runs the handler on an executor. So the envelope is acked before the handler runs. An exception inside the handler is logged after that ack. There is no option on event() to change this.
• Interactive listeners (command, shortcut, action, block_action, view and the rest) register with auto-ack off. The handler must call ack(). Dispatch waits up to ack_timeout, which defaults to 3 seconds. If no ack arrives, Bolt logs didn't call ack(), dispatch falls through to its initial 200 with an empty body, and send_response acks that. The handler may still be running. So a slow button handler gets an empty ack at 3 seconds, and any reply it meant to return is lost.

Global middleware runs before either path, so it runs before any ack. If middleware raises, dispatch returns 500, and send_response sends no ack. Slack then treats the delivery as unacknowledged.

Two consequences follow from the source. Both are inferences from the code and the Socket Mode page, and neither has been run.

1. With Bolt's ack-first event path, a crash inside the handler happens after Slack already has the ack. Slack's retry is decided by the ack, so it would not redeliver that event. Recovery has to come from JR's own Work record, which is what the receipt step below provides.
2. A receipt written in global middleware happens before the ack. If the write fails and the middleware raises, no ack goes out, and Slack's retry path applies.

Where the native event ID goes

WobOS's Work module at 8a986ec already provides most of the mechanism:

• A Work record is a JSON file named by its task_id (path_for). start takes a lock and refuses to create a record that already exists (work record already exists).
• claim_session gives one run ownership of a turn, and mark_turn_accepted records the provider accepting it.
• Turn inputs are named from the task ID and the turn number: work:{task_id}:{turn_number}, with :ask appended for the input. No Slack identifier appears in them today.

So a native event reaches the Work by no existing identifier. The recommended binding, for WobOS to confirm at implementation:

1. For a thread's first message, derive task_id from the team, channel and thread_ts. start creates the record exclusively and raises ValueError when the path exists. The middleware must handle that refusal in two ways. A replay, where the event ID is already in the accepted list, is acknowledged and adds nothing. A different first event that lost the create race reloads the record and appends itself under the same lock, because it is new input.
2. For later messages, keep an accepted-event list on the Work record. Check the native event_id against it and append it under the same lock start and claim_session use. Do this in global middleware, before the ack. A replay finds its ID and does nothing new.
3. A thread attached later, through an authorized exact reference, is recorded in a linked_threads list on the Work. An unknown thread is found by a bounded scan of the permitted open Work records in the same workspace and channel. No separate index is added.
4. Each input carries its Slack actor ID in a per-input field. author stays fixed to captain: plus the task ID.
5. Pending inputs are a new ordered pending_inputs list. The claim takes the oldest queued input, and restart returns an unfinished in-turn input to the queue. The single pending_ask value cannot hold an order.

The existing lock and restart path carry this. It adds fields and a list to the record, but no table and no timer. Astra's subsequent Git comparison found no WobOS/work.py difference between the spec's c15b3c4 and the reviewed 8a986ec. Replay behavior remains untested.

On the retry primitive itself, the Events docs say event_id is globally unique. They do not say whether a retry carries the same event_id, and the Socket Mode page does not describe the retry schedule. The design above holds only if retries reuse the ID, so that is the first thing to confirm when the slice runs.

Thread reads (conversations.replies)

conversations.replies returns a thread, cursor-paginated (tier 3). Its ts argument names the parent message or any message in the thread. Its frontmatter lists the same history scopes for a bot and a user. Scope names alone do not settle access, though.

The replies page has no access section and no not_in_channel error. The retrieving-messages guide says the method covers public and private channels and direct messages, without naming a token type. The rule that is published sits on conversations.history:

• Bot token: any conversation the bot is a member of.
• User token: any private conversation the user is a member of, and all public conversations.
• not_in_channel: "Only user tokens can access public channels they are not in."

The tokens guide agrees on the user side. A user token with channels:history gets access to any public channel.

Working assumption, inferred and to be tested: conversations.replies follows the same rule. Under that assumption, a bot cannot read a thread in a channel it has not joined, a user token is what reads a public thread the bot is not in, and a private thread needs membership on either token. The replies page does not say this, so the checkpoint decides it.

Rate limits: conversations.replies is tier 3 for Marketplace and internal customer-built apps. For new, commercially distributed, non-Marketplace apps it is 1 request per minute with limit capped at 15, from 29 May 2025. Whether JA's app counts as internal customer-built is not established here.

Verified actors

The actor key in each payload is a Slack user ID. The socket is pre-authenticated, so the app does not re-verify each envelope, but it still has to decide which person each ID belongs to. The installation binding Astra described does that. The fields below are what it binds to.

The spec says a stale click cannot approve newer content. message_ts identifies the message, not its text. So an approval has to be bound to a content hash that JR stored, not to the timestamp alone.

Threads and multi-person Work

A thread's identity is the team, the channel and the parent message's ts. Each reply carries thread_ts pointing at its parent. A resumed Work does not depend on thread history: it resumes from its stored pending inputs and source references. conversations.replies may supply a backfill or a scoped source read, and each message still names its own user, so a backfilled speaker comes from Slack, not from the model's memory. Its token rule and rate tier are the unverified items listed below.

The spec's rule is that a later speaker does not inherit an earlier speaker's access. Each turn therefore needs its own actor check. Reading the thread gives the app every actor's identity. It does not give the app permission to use what each actor could see. That check stays in JR.

Membership changes and audience checks

member_joined_channel and member_left_channel fire for public and private channels and group DMs. The join event excludes one-to-one DMs. Both carry user, channel, channel_type and team. The join event lists channels:read, groups:read and mpim:read. The leave event lists channels:read and groups:read.

An event is a change notice, not an audience proof. The spec wants a read before each context injection and each delivery:

• conversations.members (tier 4, *:read) for current membership, including group DMs.
• conversations.info for shared and external status. It returns is_private, is_mpim, is_shared, is_ext_shared, is_org_shared, shared_team_ids and pending_shared. How these behave for Slack Connect members is unverified.

The membership read and the send are separate calls. chat.postMessage has no precondition tied to the read, so a member who joins between them can receive the message. The join event arrives only after the fact. The spec's response is a hold on further sends in that thread and a context rebuild. The window itself is not closed.

Audience rules from WOB-72

WOB-72 is closed, with its accepted scope recorded on 9 October 2026. The rules the spec applies are these:

• Toberton and Ben: JA finance records, including bank details. Private replies stay available to them.
• Teammate Tobi (read as Tobi A. by inference, not yet bound to an account): event revenue, costs and payouts. Bank details stay with Toberton and Ben.
• Every reply: every member of the destination conversation must be allowed to see the information.
• Personal records and private sections of mixed recordings stay private.
• Teammates' own tasks: requested progress, completion and explicitly requested due-date changes.
• Changes affecting someone else's task: prepared for review.

The recorded answers were "Use that scope" for finance and "Allow those edits to their own tasks" for task edits. WOB-72 also states that recording these decisions changed no app scopes, Slack membership, sharing, bot identity or finance access.

This review keeps two layers apart. The audience rules decide who may see an answer, and JR enforces them in its own logic. A physical grant (a scope, bot membership in a channel, or a List access entry) is a separate permission change, and it needs its exact effect approved after app inspection. WOB-72 settled the audience. It granted no Slack permission. The membership read is what makes the "every member" rule enforceable.

Lists: existing records, scopes and access

• No new List is needed. Existing Lists are the owning task records, so JR calls the existing ones.
• Calls need both a scope and an access entry. slackLists.access.set grants read or write to users or channels, and owner to users only. Only the current owner can set another owner, and owner upgrades across teams are refused. access.delete removes an entry.
• Row people columns are data. Columns such as assignee, user and todo_assignee hold a row's people as cell values, and they grant nothing. For a teammate-task change, which column JR reads as "the owner" is a schema decision for the owning List.
• Writes have no precondition. items.update takes list_id and cells and no prior-revision argument. items.list and items.info return updated_by and updated_timestamp, and items.update's response carries neither. So the write-time check is read, compare, write and read back, with a race window in between. The spec's action-revision design must accept that window or narrow it.
• The creator owns a new List. This matters only if a List is created, and JR does not create one, so it is not a decision now.

Revision-bound actions

• Modals have a real precondition. views.update takes an optional hash. A mismatch returns hash_conflict. For modal approvals, Slack enforces compare-and-set.
• Messages have none. chat.update addresses a message by channel and ts, replaces the whole text, and has no precondition. The approved content is stored as a hash on JR's side, and the app compares it before sending.
• Lists have evidence, not a precondition. Described above under Lists.

Events and dedupe

Every event carries an event_id, which the Events page describes as globally unique. The dedupe rule and its limits are in the Bolt and WobOS sections above. A handler that acts on every delivery can act twice when a retry arrives, and the receipt on the Work record is what stops that.

Edits and deletions follow the same channel and ts identity. message_changed and message_deleted need channels:history and groups:history, as those pages state. chat.update edits only ordinary messages and returns cant_update_message for others. Its error table lists edit_window_closed. chat.delete depends on the token type. A user token may delete messages that user could delete in Slack. A bot token may delete only messages that bot posted.

For mentions, app_mention needs app_mentions:read. The event page's frontmatter writes app_mentions.read with a dot, while the scope index and the assistant manifest use the colon form. I treat the colon form as correct, and the event page as the outlier, unverified against the API. channel_joined lists no scope in its frontmatter, so its requirement is unverified.

No List change event appears in the Events index I read. Stated as a source finding, that means JR learns about row changes by reading Lists when a request or an authorized continuation needs them. It does not call for a timer, and it is not a claim that the API cannot emit such an event.

Vendor surface inventory

The method index lists 340 methods. I read each method page's frontmatter for token types and scopes. 104 accept both token types, 45 are bot-only, 147 are user-only and 44 list no scope. A method with no listed scope is not necessarily open. apps.connections.open, for example, takes an app-level token.

Capability table

"Readback" is the scope list supplied on 2026-10-20. "Not in readback" means the header did not show the scope, not that a call was rejected.

Proof checkpoints

Nothing here has run, and nothing runs now. All checks happen at implementation time, inside the isolated WobOS slice, against Toberton's own DM or a labeled disposable test channel or List, under the standing live-testing permission. A simulated check, such as feeding the same envelope twice through a fake client, proves the receipt logic and not Slack's redelivery, and it must be labeled that way. Anything that changes a permission needs Toberton's approval of its exact effect first.

The permission gap, kept separate

The scope gap is a fact about tokens. The audience rules in WOB-72 are a fact about who may see what. Neither decides the other. A later grant to any token will be presented with its exact effect after app inspection, and it is not a prompt in the current build.

Unverified

• The installed app's app-level token, event subscriptions, interactivity setting and bot app ID. Not inspected.
• Whether conversations.replies applies the history rule, and whether a bot can read a thread in a channel it has not joined.
• Whether a retry carries the same event_id, and Socket Mode's retry schedule.
• Whether the Bolt version later adopted matches the acknowledgment behavior read at 649cfc8.
• Whether bot users can hold a List owner or write entry, and whether channel-level entries apply to bot writes.
• Whether any existing JA List is owned by Toberton's account or the bot's.
• The scope for channel_joined, which the frontmatter does not list.
• How is_shared, is_ext_shared and shared_team_ids behave for Slack Connect members.
• The replies rate-limit tier depends on how the app is distributed. JA's status as internal is not established here.

Tools and network

• Slack: no call of any kind.
• Linear: one read of WOB-72.
• GitHub: public raw files and commit metadata at the pinned revisions.
• WobOS: read-only inspection of the local checkout at 8a986ec. Its uncommitted changes were not touched.
• Ref Context: two earlier searches, used as a cross-check.
• Parallel: not used, since every primary page was reachable by URL.
• Not run: no tests, no installs, no starter run, no commits.