WordloopWordloop
WorkMeeting RecordingTechnical Design DocMilestones08 Live Tasks And Reconciliation

ML — Live Task Extraction

TaskProducedEvent emission from the same batched insight pipeline as talking points, and final task candidates in the PUT /meetings/:id/tasks/system write-back.

ML — Live Task Extraction

Owner: ML Engineer Domain: ml Complexity: S Prerequisite: Core Task Reconciliation slice merged; ./dev gen all run

When this slice is complete, ML's batched insight pipeline (the same cadence used for talking points) extracts candidate tasks from the live transcript and writes them back to Core as source: system tasks, and the post-meeting synthesis pass produces the final task candidate set through PUT /meetings/{id}/tasks/system.

Required Capabilities

  • ML's batched insight pipeline extracts candidate tasks from the live transcript and posts them via POST /tasks { source: "system" } (service auth) on the same cadence as live talking points.
  • The post-meeting synthesis pass produces the final task candidate set and submits it via PUT /meetings/{id}/tasks/system.

Dependencies

  • Core Task Reconciliation slice must be merged and ./dev gen all run — specifically POST /tasks and PUT /meetings/{id}/tasks/system.
  • Milestone 04 (live-transcript-to-final-rebuild) — the live transcript segment stream this pipeline reads from.

Domain Notes

Coverage gap. No bet-progress test exercises ML's actual task-extraction pipeline. test_milestone_08_live_tasks_and_reconciliation.py's own module docstring is explicit about this: "Live ML task extraction needs a real transcript, so the tests drive the same Core write-back paths the ML service uses: POST /tasks with source: system (service token) for live draft tasks and PUT /meetings/{id}/tasks/system for the final candidate set." Every "draft task" and "final candidate" in the bet suite is created directly by the test via system_client, not produced by ML's real extraction logic (the OpenAI-backed insight pipeline). This proves Core's reconciliation contract thoroughly, but leaves the ML extraction step itself — whether it actually calls POST /tasks at the right cadence, or produces sensible candidates from real transcript content — unverified by the bet suite. Permanent ML unit tests may cover extraction quality in isolation, but there is no end-to-end bet test analogous to M07's live-talking-points streaming proof.

Test Cases

Not yet covered by a bet-progress test. There is no test in tests/bets/meeting-recording/test_milestone_08_live_tasks_and_reconciliation.py (or elsewhere in the bet suite) that exercises ML's real task-extraction pipeline end-to-end. The table below records this explicitly rather than listing rows that do not exist.

TestLocationAssertion
(none — not yet covered)—ML posting a live draft task via its own extraction pipeline (as opposed to a test calling POST /tasks directly) is not exercised by any bet-progress test.
(none — not yet covered)—ML's post-meeting synthesis pass producing the final task candidate set via its own logic (as opposed to a test calling PUT /meetings/{id}/tasks/system directly) is not exercised by any bet-progress test.

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
  • Testing review completed
  • System documentation updated (as applicable)

On this page