[birme]

Summary

• Add API.forceDisconnectParticipant that calls the backend force-disconnect endpoint (POST /production/:productionId/line/:lineId/participants/:sessionId/disconnect) through the shared handleFetchRequest wrapper (no inline fetch, errors routed consistently).
• Add a per-participant Kick button in user-list.tsx, mirroring the existing MuteParticipantButton pattern and guarded identically (not shown for yourself, program output lines, WHIP or inactive participants).
• Wire the button to the unified ConfirmationModal in production-line.tsx with a confirm dialog and error handling (reuses the existing mute-confirm layout and error-reset effect).
• Add component tests (user-list.test.tsx) for render/confirm wiring and api tests for the POST call and 404 error propagation.

Test plan

• Tests pass (npm test)
• TypeScript compiles (npm run typecheck)
• Lint clean (npm run lint)
• Production build succeeds (npm run build)
• In the admin/control panel, click Kick on another active participant, confirm the dialog, and verify the participant is disconnected from the line
• Cancel the dialog and verify no request is sent
• Simulate a backend failure and verify the error message is shown

Closes #673

🤖 Generated with Claude Code

[birme]

code-reviewer verdict: LGTM (automated review by a separate invocation from the implementer; recorded as a marker because GitHub blocks state-bearing self-review when author and reviewer are the same account).

Summary: Clean, well-scoped implementation mirroring the existing MuteParticipantButton + ConfirmationModal pattern. The new API method routes through the API object and handleFetchRequest, builds the correct backend URL (POST /api/v1/production/:productionId/line/:lineId/participants/:sessionId/disconnect), passes the participant's sessionId (not the local user's), and surfaces errors to the user. Typecheck, lint, and new tests pass. Zero Blocking items.

Warnings (non-blocking)

• The kickParticipant confirm→API→close/error handler in production-line.tsx has no end-to-end test; the button-opens-dialog path and the api.ts method are tested in isolation, but a follow-up should assert confirming invokes the API with the resolved ids, closes on success, and sets the error state on failure.

Suggestions

• No admin/role gating on the Kick button — it is visible under the same condition as Mute, and there is no user-level role concept in the frontend today, so force-disconnect is available to anyone who can see the user list (consistent with Mute; backend enforces auth via the Bearer key). Confirm this matches the intended "admin-only" scope of Frontend: admin panel Kick button + confirm dialog consuming disconnect endpoint #673; if admin gating is expected, it is absent here.
• Error copy "Something went wrong, Please try again" (comma splice, capitalized Please) is copied verbatim from the mute modal — a future cleanup could fix both.

Domain Note

Affects WHIP/WHEP / SMB session lifecycle (backend force-disconnect expires the participant's SMB endpoint and removes the session). Frontend side is a straightforward authenticated POST and looks correct. Consider intercom-expert for disconnect/notify semantics validation on the manager side.