slack: no public way to obtain trigger_id from the Raw escape hatch (modal-open flow unreachable)

[ThomasK33]

Problem

The Slack adapter preserves trigger_id and response_url on the Raw Platform Escape Hatch of chat.Command / chat.Interaction, and exposes OpenModal / OpenModalForTenant that require a trigger_id. But the concrete types behind Raw (commandForm, interactionPayload) are unexported, and the only trigger-ID extractor is TriggerIDForTest in adapters/slack/export_test.go — test-only.

Consequences:

• RespondURL(ctx, raw any, msg) works because it accepts the escape hatch directly.
• The modal-open flow is effectively unreachable from application code: there is no supported way to obtain the trigger_id for OpenModal without re-parsing the original webhook JSON yourself.

Surfaced by the codex review of #11 (docs restructure): the interactive-components how-to could not show a followable modal example. The guide currently documents this as a known gap pointing at this issue.

Proposal

Either:

1. Export a small accessor, e.g. slack.TriggerID(raw any) (string, bool) (mirroring the test helper), or
2. Make the modal API accept the escape hatch directly, e.g. OpenModalFromRaw(ctx, raw any, view any) error, matching the RespondURL shape.

Option 2 keeps trigger_id opaque and symmetric with RespondURL; option 1 is more general (native content targeting, logging). Update docs/how-to/interactive-components.md to show the real flow once available.

---

Generated with mux • Model: anthropic:claude-fable-5 • Thinking: xhigh

[ThomasK33]

Scope extension from the round-4 codex review of #11: the same unexported-payload problem blocks reading a menu interaction's selected option value (and view state) from chat.Interaction.Raw — application code can route on ActionID but cannot inspect the chosen option without re-parsing the webhook JSON. Whatever accessor shape lands here should cover trigger_id, response_url (already usable via RespondURL), selected action values, and view state — or normalize the action value onto chat.Interaction directly.

[ThomasK33]

Triage: accepted — ready-for-agent.

This is a real usability bug in a supported-tier adapter: we ship OpenModal but no supported way to obtain its required trigger_id. A modal API you can't reach from application code fails the "production in a day" bar.

Decision: option 2 — OpenModalFromRaw(ctx, raw any, view any) error (and the tenant variant), matching the RespondURL shape. Rationale: keeps trigger_id opaque plumbing rather than public API, symmetric with the existing escape-hatch pattern, and doesn't commit us to a general raw-accessor surface. Option 1 (exported TriggerID accessor) stays on the table if a concrete non-modal need shows up — file it separately with the use case if so.

Scope also includes updating docs/how-to/interactive-components.md to show the real modal flow (after #11 lands) and retiring the test-only extractor where it becomes redundant.

---

Generated with mux • Model: anthropic:claude-fable-5 • Thinking: xhigh