app.meeting-intake-worker

OPA Meeting Intake Worker

Deployable, provider-neutral host for recurring calendar and meeting-recorder intake. It claims owner-scoped PostgreSQL executions, calls an allowlisted deployment composition, and completes, retries, or terminally settles each job with its exact lease token.

Set OPA_MEETING_INTAKE_WORKER_COMPOSITION_MODULE to an allowlisted @lssm-tech/integration.meeting-intake-worker-* package. The composition owns fresh authority, protected configuration and credential resolution, provider construction, durable occurrence/review ports, and the governed opa.recording.source_bind call. This host never accepts browser sessions or raw credentials and never logs meeting content.

/healthz answers liveness. /readyz answers 200 only when the worker has assigned scopes, completed a cycle recently and skips no scope. Its body lists provisioningBlockers from the composition's optional provisioningBlockers() ({ code, tenantRef, workspaceRef, jobRef? }, closed codes and opaque references only). Readiness fails closed: while a blocker remains it answers 503 with state: "not-ready", although the other scopes keep running. Point liveness and restart probes at /healthz; a restart does not resolve a provisioning conflict (see docs/operations/founder-ops-v2/meetings-enable.md, section 3).

The production image includes @lssm-tech/integration.meeting-intake-worker-postgres-http. It uses the canonical SQL queue and a strict bearer-authenticated HTTPS execution boundary; see that package for required environment variables and receipt semantics.

Hosting choice

CompanyOS runs the same queue cycle in-process through the API cron /api/cron/meeting-intake (kill switch OPA_MEETING_INTAKE_ENABLED=1; see docs/evidence/opa/meeting-intake-prep-2026-10-19.md). Deploy this worker only where a long-running host is preferred, and never alongside the cron for the same owner scopes: jobs are unique per owner and connection.