Core — Recording Limits

Owner: Core Engineer Domain: core Complexity: M Prerequisite: Milestone 05 merged

When this slice is complete, a per-start max_duration_seconds can only lower the server's RECORDING_MAX_DURATION_SECONDS ceiling, never raise it; Core warns the client at roughly 80% of the limit via duration_warning.v1 and auto-stops at the limit with stopped.v1 { reason: "duration_limit" }, continuing the recording through the normal finalization pipeline. A second recording start for the same user — a different meeting, or the same meeting from another tab — is refused session_conflict while the original session continues unaffected, and GET /meetings?has_active_recording=true lists every live session. Every lifecycle, health, and stop-reason signal is captured in a newest-first diagnostics history, exposed only to service auth.

Required Capabilities

• StartRecordingCommand.max_duration_seconds overrides the server ceiling downward only; the effective limit is echoed on started.v1.
• Core emits com.wordloop.recording.duration_warning.v1 { meeting_id, remaining_seconds, auto_stop_at } at roughly 80% of the limit.
• Core auto-stops the recording at the limit with stopped.v1 { reason: "duration_limit", last_received_sequence } and no error event, then proceeds through the normal post_processing → completed pipeline.
• A second recording start for the same user — a different meeting, or the same meeting under a different client_recording_id — is refused with recording.error.v1 { code: "session_conflict", severity: "error" }; the original session is unaffected.
• GET /meetings?has_active_recording=true lists every meeting with an active or stopping recording for the user; a stopped meeting leaves the list.
• GET /meetings/{id}/recording/events (service auth only — bearer and impersonated-user auth get 403) returns a newest-first diagnostics history including started, status_changed, health, duration_warning, and stopped entries, each with id, created_at, and a payload object.
• GET /meetings/{id}/recording/events for an unknown meeting answers 404.

Dependencies

• Milestone 05 (live-audio-durability-recovery) must be merged — the recordings row and status-transition machinery this slice extends with limits, the session lock, and diagnostics history.

Domain Notes

max_duration_seconds is a ceiling that individual starts may lower but never raise — the test compose sets RECORDING_MAX_DURATION_SECONDS=30 and starts pass 12, never the reverse. The session lock is per-user, not per-meeting: a second tab is refused even when it targets a different meeting than the one already recording.

Test Cases

Test cases map to tests/bets/meeting-recording/test_milestone_11_recording_hardening.py. Run via ./dev test bet meeting-recording.

Completion Checklist

• Code merged and deployed
• Bet progress tests pass (./dev test bet meeting-recording)
• Permanent service tests implemented per testing strategy
• Code review completed
• API review completed (GET /meetings/{id}/recording/events diagnostics endpoint)
• Testing review completed
• Schema review completed (recording_event_history table)
• System documentation updated (as applicable)