A manager of a discord server should be able to "remove" channel regist…

[quarterback-ai-dev-environment]

Intent

A manager of a discord server should be able to "remove" channel registration. Today they can register, and change the registered channel, but cannot remove registration entirely. I would like to add a "remove" button to the "reporting channel" section of the dashboard/server page. This button, when clicked, should open a confirmation modal. If the user confirms, then it should use htmx to call delete for that particular "discord_guild_settings" entry. If no channel is configured, the UI should say "not configured" and allow the user to click the "change" button. The rest of the workflow remains the same.

Claims proven

• A guild manager can remove a server's reporting-channel registration, after which no discord_guild_settings row exists for that guild. (CAN)
• The DiscordService exposes a method that deletes a guild's reporting-channel settings and treats deleting zero rows as a success (removing an already-absent registration is a no-op, not an error). (CAN)
• The reporting-channel section of the dashboard/server page shows a 'remove' button when a channel is configured and the acting user is a guild manager. (CAN)
• Clicking the 'remove' button opens a confirmation modal, and the DELETE request is issued only from the modal's confirm action (never directly from the remove button). (CAN)
• Confirming removal issues an htmx HTTP DELETE to a guild-scoped channel endpoint that targets #channel-region and swaps outerHTML. (CAN)
• The remove-channel HTTP handler rejects any caller who is not an admin manager of the target guild, leaving the discord_guild_settings row intact. (MUST)
• After a successful removal (and whenever no channel is configured), the reporting-channel section renders the 'not configured' state offering a control to configure a channel. (CAN)

Confidence: medium

[quarterback-ai-dev-environment]

Review findings

Advisory:

• internal/http/handlers/profile_test.go — the two negative-auth subtests (non-manager, non-member) accept either 400 or 200 as the rejection status (rr.Code != BadRequest && != OK → fatal), so a future regression that returned 200-with-error-partial vs a hard 400 would not be caught by the status assertion. The load-bearing guard invariant — len(removeChannelSettingsCalls) == 0 — IS asserted tightly and is what actually proves CLM-6, so this is a hardening nit, not a coverage gap. Consider asserting the exact expected status.