[Bot] Put a deep link in every Discord notification embed

claude-bot commented

2026-08-25 20:42:27 +00:00

Collaborator

Impact: HIGH

Found in the August 2026 session lifecycle review (#319).

What the user experiences

Of thirteen Discord notification event templates, exactly one contains a link back to the web app. Every other embed — reminders, confirmations, the session-summary notification — makes the user find the relevant session by hand. The session_summarised footer even claims "Full transcript available to GMs on Quest Board" without linking to it.

Evidence

bot/questboard_bot/cogs/notifications.py:489 — the only template that builds [Open in Quest Board](…), via session_url built at webapp/backend/app/tasks/reminder_tasks.py:1917.
bot/questboard_bot/cogs/notifications.py:690 — the session_summarised footer text names the web app without linking it.
The only other URL the bot builds anywhere is the account-link DM (bot/questboard_bot/cogs/linking.py:71-74).

Why it matters for a hosted product

Combined with the dashboard "needs you" surface in this milestone, this is most of the fix for "nobody knows anything is waiting" — a notification that doesn't link back to the app requires the user to independently navigate there and find the right page themselves.

Proposed fix

session_url already exists and is used in one template — thread it through the other twelve. This is the audit's P21.

Acceptance criteria

All thirteen Discord notification templates include a link back to the relevant web app page.
The session_summarised footer's "Full transcript available to GMs on Quest Board" text is an actual link.

**Impact: HIGH** Found in the August 2026 session lifecycle review (#319). ## What the user experiences Of thirteen Discord notification event templates, exactly one contains a link back to the web app. Every other embed — reminders, confirmations, the session-summary notification — makes the user find the relevant session by hand. The `session_summarised` footer even claims *"Full transcript available to GMs on Quest Board"* without linking to it. ## Evidence - `bot/questboard_bot/cogs/notifications.py:489` — the only template that builds `[Open in Quest Board](…)`, via `session_url` built at `webapp/backend/app/tasks/reminder_tasks.py:1917`. - `bot/questboard_bot/cogs/notifications.py:690` — the `session_summarised` footer text names the web app without linking it. - The only other URL the bot builds anywhere is the account-link DM (`bot/questboard_bot/cogs/linking.py:71-74`). ## Why it matters for a hosted product Combined with the dashboard "needs you" surface in this milestone, this is most of the fix for "nobody knows anything is waiting" — a notification that doesn't link back to the app requires the user to independently navigate there and find the right page themselves. ## Proposed fix `session_url` already exists and is used in one template — thread it through the other twelve. This is the audit's P21. ## Acceptance criteria - [ ] All thirteen Discord notification templates include a link back to the relevant web app page. - [ ] The `session_summarised` footer's "Full transcript available to GMs on Quest Board" text is an actual link.

claude-bot added this to the v4.3.0 - Product Surface: Navigation, Attention & Feedback milestone

2026-08-25 20:42:27 +00:00

claude-bot added the

bot

bug

labels

2026-08-25 20:42:27 +00:00

claude-bot referenced this issue

2026-09-06 00:34:01 +00:00

v4.3.0 build order: Product Surface in eight phases #514

claude-bot referenced this issue

2026-09-06 00:41:01 +00:00

[Bot] Stop announcing failed transcriptions as "Session Summary Ready" #372

claude-bot commented

2026-09-06 00:41:03 +00:00

Author

Collaborator

Picking this up as part of v4.3.0 phase 1 (#514), shipping early as v4.2.3. The backend will put session_url (or campaign_url for campaign-level events) in extra for every notification it enqueues, built by one helper, and every bot template renders the link when present. Additive payload field, so no contract bump; both sides in one commit per CLAUDE.md.

Picking this up as part of v4.3.0 phase 1 (#514), shipping early as v4.2.3. The backend will put `session_url` (or `campaign_url` for campaign-level events) in `extra` for every notification it enqueues, built by one helper, and every bot template renders the link when present. Additive payload field, so no contract bump; both sides in one commit per CLAUDE.md.

claude-bot referenced this issue

2026-09-06 00:41:43 +00:00

v4.3.0 build order: Product Surface in eight phases #514

rbrooks referenced this issue from a commit

2026-09-06 01:43:22 +00:00

feat(bot/webapp): put a Quest Board deep link in every notification embed (#391)

claude-bot referenced this issue from a pull request that will close it,

2026-09-06 01:44:10 +00:00

fix(bot): stop lying in Discord: failed summaries, deep links, and the unused privileged intent (phase 1 of v4.3.0) #517

claude-bot closed this issue

2026-09-06 01:59:45 +00:00

rbrooks referenced this issue from a commit

2026-09-06 02:00:15 +00:00

chore(release): v4.2.3

claude-bot referenced this issue

2026-09-06 02:00:16 +00:00

[Bot] Stop announcing failed transcriptions as "Session Summary Ready" #372

claude-bot commented

2026-09-06 02:00:22 +00:00

Author

Collaborator

Implemented in PR #517 (merged), both sides in one commit, shipping in v4.2.3.

Backend: app_url_for / session_url_for / campaign_url_for / session_url_extra in app/services/bot_pubsub.py, next to stamp_event_id because like it they shape the payload rather than talk to Redis. All twelve session-scoped enqueue sites now splat **session_url_extra(...) into extra: reminders, at-risk, vote posts and vote updates, confirmations and RSVP prompts, proposals, cancellations, completions, summary ready/failed/approved, audio-deletion warnings, and shelf reveals. The vote reminder's inline f-string, the only link that existed, is now the same helper. For session_summarised the splat lives inside _notify_bot_summarised rather than at its three callers, so success, failure and the queue timeout all carry it and none can be the one that forgets.

When APP_URL is unset the helpers return None and the field is omitted, never a relative or half-built URL: a Discord embed can only carry an absolute one and a partial renders as literal text in the channel.

Bot: one _add_quest_board_link(embed, extra) helper called unconditionally by all thirteen templates; the "should there be a link" decision belongs to the backend that either sent the key or did not. The summary footer's "Full transcript available to GMs on Quest Board", a signpost with no link because Discord embed footers cannot hold one, moves into that field as a real link, falling back to the footer only when there is no URL. /sessions/:id and /campaigns/:id were confirmed to be real frontend routes before pointing anything at them.

No BOT_CONTRACT_VERSION bump: additive event field, and the contract governs /api/bot/* shapes, not the event vocabulary. Tests: a 13-case parametrised pair over every template (link renders as markdown when present; embed still posts with no ]( when absent), the footer conversion, a vote-reminder regression guard, and the campaign_url fallback; backend covers both URL shapes, the blank-app_url behaviour, and an actually enqueued payload carrying and omitting session_url. docs/DEVELOPMENT.md's "adding a notification event" section now says to include the link, so the next event gets one by construction.

campaign_url_for ships tested but uncalled: no backend event is campaign-only today, and the bot already reads campaign_url as a fallback, so the first campaign-level event needs no bot change.

Implemented in PR #517 (merged), both sides in one commit, shipping in v4.2.3. Backend: `app_url_for` / `session_url_for` / `campaign_url_for` / `session_url_extra` in `app/services/bot_pubsub.py`, next to `stamp_event_id` because like it they shape the payload rather than talk to Redis. All twelve session-scoped enqueue sites now splat `**session_url_extra(...)` into `extra`: reminders, at-risk, vote posts and vote updates, confirmations and RSVP prompts, proposals, cancellations, completions, summary ready/failed/approved, audio-deletion warnings, and shelf reveals. The vote reminder's inline f-string, the only link that existed, is now the same helper. For `session_summarised` the splat lives inside `_notify_bot_summarised` rather than at its three callers, so success, failure and the queue timeout all carry it and none can be the one that forgets. When `APP_URL` is unset the helpers return `None` and the field is omitted, never a relative or half-built URL: a Discord embed can only carry an absolute one and a partial renders as literal text in the channel. Bot: one `_add_quest_board_link(embed, extra)` helper called unconditionally by all thirteen templates; the "should there be a link" decision belongs to the backend that either sent the key or did not. The summary footer's "Full transcript available to GMs on Quest Board", a signpost with no link because Discord embed footers cannot hold one, moves into that field as a real link, falling back to the footer only when there is no URL. `/sessions/:id` and `/campaigns/:id` were confirmed to be real frontend routes before pointing anything at them. No `BOT_CONTRACT_VERSION` bump: additive event field, and the contract governs `/api/bot/*` shapes, not the event vocabulary. Tests: a 13-case parametrised pair over every template (link renders as markdown when present; embed still posts with no `](` when absent), the footer conversion, a vote-reminder regression guard, and the `campaign_url` fallback; backend covers both URL shapes, the blank-`app_url` behaviour, and an actually enqueued payload carrying and omitting `session_url`. `docs/DEVELOPMENT.md`'s "adding a notification event" section now says to include the link, so the next event gets one by construction. `campaign_url_for` ships tested but uncalled: no backend event is campaign-only today, and the bot already reads `campaign_url` as a fallback, so the first campaign-level event needs no bot change.

claude-bot referenced this issue

2026-09-06 02:01:27 +00:00

chore(release): v4.2.3 #518

claude-bot referenced this issue

2026-09-06 09:30:26 +00:00

chore(release): v4.3.0 #533