rbrooks/Quest-Board

Watch

Fork 0

A web-started recording can run with no announcement (consent model) #839

New issue

Closed

opened 2026-09-26 14:33:37 +00:00 by claude-bot · 2 comments

claude-bot commented

2026-09-26 14:33:37 +00:00

Collaborator

Found by the lane 10 survey (#736), read against origin/main at 20dcabd8. The consent model has one requirement: a channel announcement when recording begins (CLAUDE.md). Two paths break it.

No notification channel set. The backend sends channel_id "0" (app/routers/sessions.py:1974). The bot finds no channel (bot/cogs/recording.py:1188), starts capture anyway (:1225), and skips the announcement (:1253).
The announcement post fails. The error surfaces after capture has started (:1225-1258). The web page reports a failure, and the session isn't marked live (D116), but the bot keeps recording.

Also, in the same file: the upload post still says "You'll be notified here when the summary is ready" (recording.py:1840), which D96 retired.

The fix, following the lane 10 survey's recommendation (O3(a), provisional until the owner answers):

the bot announces in the campaign's channel;
if it can't, it announces in the voice channel's own text chat, where the people being recorded are;
if it can post in neither, it doesn't record, and says why, to the web page (as a 409 with a plain detail) and to the Discord caller;
announce first, then capture. A failed announcement never leaves capture running.

This applies to web-started and Discord-started recordings alike.

Refs #736, #731.

Found by the lane 10 survey (#736), read against `origin/main` at `20dcabd8`. **The consent model has one requirement: a channel announcement when recording begins** (`CLAUDE.md`). Two paths break it. 1. **No notification channel set.** The backend sends `channel_id "0"` (`app/routers/sessions.py:1974`). The bot finds no channel (`bot/cogs/recording.py:1188`), starts capture anyway (`:1225`), and skips the announcement (`:1253`). 2. **The announcement post fails.** The error surfaces after capture has started (`:1225-1258`). The web page reports a failure, and the session isn't marked live (D116), but the bot keeps recording. **Also, in the same file:** the upload post still says "You'll be notified here when the summary is ready" (`recording.py:1840`), which D96 retired. **The fix,** following the lane 10 survey's recommendation (O3(a), provisional until the owner answers): - the bot announces in the campaign's channel; - if it can't, it announces in the voice channel's own text chat, where the people being recorded are; - if it can post in neither, it **doesn't record**, and says why, to the web page (as a 409 with a plain `detail`) and to the Discord caller; - **announce first, then capture.** A failed announcement never leaves capture running. This applies to web-started and Discord-started recordings alike. Refs #736, #731.

rbrooks referenced this issue from a commit

2026-09-26 14:48:56 +00:00

fix(bot,webapp): announce a recording before capturing it, or don't record (#839)

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

2026-09-26 14:48:58 +00:00

fix(bot,backend): never record without announcing it (#839) #842

claude-bot referenced this issue

2026-09-26 14:49:05 +00:00

/record start: a refusal can be public, and a refused start leaves the session live #843

claude-bot referenced this issue from a commit

2026-09-26 16:57:46 +00:00

Merge PR #842: never record without announcing it (#839)

claude-bot closed this issue

2026-09-26 16:57:46 +00:00

claude-bot commented

2026-09-26 16:58:41 +00:00

Author

Collaborator

Fixed by #842, merged 2026-09-26.

The new order. Both start paths now go join voice → announce → listen.

The announcement goes to the campaign's channel. If there isn't one, or the post fails, it goes to the voice channel's own text chat. That fallback is O3(a), still provisional until the owner answers.
If neither channel takes the post, the bot leaves without ever capturing. The web path gets a 409 with a plain reason, and /record start tells the GM why.

What changed on the backend. It never sends channel_id "0". The bot contract stays at v2, because the change is additive.

Follow-ups are in #843:

the refusal's visibility;
D116 marks the session live before the bot connects.

Fixed by #842, merged 2026-09-26. **The new order.** Both start paths now go join voice → announce → listen. - The announcement goes to the campaign's channel. If there isn't one, or the post fails, it goes to the voice channel's own text chat. That fallback is O3(a), still provisional until the owner answers. - If neither channel takes the post, the bot leaves without ever capturing. The web path gets a 409 with a plain reason, and `/record start` tells the GM why. **What changed on the backend.** It never sends `channel_id "0"`. The bot contract stays at v2, because the change is additive. **Follow-ups are in #843:** - the refusal's visibility; - D116 marks the session live before the bot connects.

rbrooks referenced this issue from a commit

2026-09-26 18:59:29 +00:00

feat(bot,webapp): record even when the announcement can't be posted (D171, #839)

claude-bot referenced this issue

2026-09-26 18:59:42 +00:00

feat(bot,webapp): record even when the announcement can't be posted, and tell the GM (D171) #853

claude-bot commented

2026-09-26 21:23:08 +00:00

Author

Collaborator

Amended by the owner's D171 (O3 (c), confirmed 2026-09-26) and #853, merged.

The bot still tries to announce first, in the campaign's channel and then in the voice channel's chat. If neither post succeeds, it now records anyway rather than refusing.

The GM is told plainly: "Recording — but I couldn't post the announcement. Tell the table it's being recorded." This shows:

on the recording panel and the table's recording bar, where it survives a reload via announced_in: null;
privately in Discord.

Both failed posts are logged. The bot contract stays at v2.

CLAUDE.md's consent-model paragraph still says the announcement is the one requirement. That's for the owner to update.

**Amended by the owner's D171 (O3 (c), confirmed 2026-09-26) and #853, merged.** The bot still tries to announce first, in the campaign's channel and then in the voice channel's chat. If neither post succeeds, it now records anyway rather than refusing. The GM is told plainly: *"Recording — but I couldn't post the announcement. Tell the table it's being recorded."* This shows: - on the recording panel and the table's recording bar, where it survives a reload via `announced_in: null`; - privately in Discord. Both failed posts are logged. The bot contract stays at v2. CLAUDE.md's consent-model paragraph still says the announcement is the one requirement. That's for the owner to update.