[sentry-junior]

Step 2 of #2207. Plugin webhook routes get ctx.agent.dispatchForIdentity({ subjectId, idempotencyKey, input, replyAttribution? }). It starts private work in a Slack DM for the person behind one provider account. The result is { status: "created" | "already_exists", id } or { status: "not_linked" }. The call does not throw because the person is untrusted.

Core decides who counts, in code and before any model call:

• The provider is always the plugin that calls. A plugin cannot name another provider's Identity. Core namespaces (junior, slack) never match.
• The match uses only the exact provider account id that the OAuth account-linking flow stored (empty tenant, kind user, linked user). Handles, emails, and display names never match.
• That user must have exactly one Slack Identity in the bot workspace. If there are none or more than one, the result is not_linked.
• users.info must show a current human member of the bot team: same team, not deleted, not a bot. This repeats the revocation check from Slack ingress.
• No Slack bot or no team id also gives not_linked. Other Slack and storage errors reach the route.

On a match, core opens the bot DM and creates a normal plugin dispatch with private visibility and a private-direct-conversation credential subject for that Slack user. Binding, validation, and enqueue use the same code as heartbeat dispatches. No second authority path exists.

Not in this PR:

• Step 3 (action review provenance for the person's instruction) and step 4 (connecting the GitHub webhook and adding the optional reply) come next.
• Per-plugin rate limits for route dispatches. The route context lives for the whole app, so a heartbeat-style counter does not fit. Today every created dispatch needs a distinct linked member and its own idempotency key. A limit can follow when step 4 shows real traffic.

via BYK.

--

View Junior Session [Sentry]

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
junior-docs	Ready	Preview	Oct 29, 2026 6:43pm UTC

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f4c3a14. Configure here.}

[BYK]

Plugin webhook routes get ctx.agent.dispatchForIdentity({ subjectId, idempotencyKey, input, replyAttribution? }). It starts private work in a Slack DM for the person behind one provider account.

We need to rework some of this logic. If the origin is a public GitHub repo, then the work should be considered public, even if we decide to message the author on a private Slack DM. The reverse is a bit tricky though: once we open a public-facing PR or issue from a private DM we still need to make sure no private or proprietary information goes back to public but the "work" itself is public.

[sentry-junior]

Thanks @BYK. As agreed, this PR stays private-only, and it has no code change for origin visibility.

Per-Conversation visibility will be its own step, before the GitHub webhook work (step 4). Today Conversation visibility comes from the shared junior_destinations.visibility row for the Slack channel. If one public-origin dispatch marked a DM as public, all other Conversations in that DM would read as public. The next normal DM message would then flip the row back to private. The reverse case (a private DM run that writes to a public issue or PR) stays with step 3 / #773 and the "no private data in public output" check. I updated the plan on #2207.