Skip to content

Meetings and tasks — capture, schedule, record, and actually close things

Angel, 2026-09-13: "We need something to capture these meetings, record them, schedule them, make tasks etc."

What exists today, honestly

  • Minutes: ~/Notes/meetings/YYYY-QN.md, written by hand from a pack quarterly-pack generates.
  • Tasks: - [ ] lines under ## Open in ten project notes. Ten lists, no owner, no due date, no way to ask "what is overdue". SOP-015 already promises an audit check for open actions and there is nothing for it to read.
  • Scheduling: nothing. Google Workspace exists but the server has no calendar credentials (the service-account route is blocked by an organisation policy — recorded in embeddedera-business).
  • Recording: nothing. ffmpeg is installed; no speech-to-text.

The shape

One task register, many sources. A meeting action, a feedback item accepted, an audit failure and an RMA cause are the same object: a thing someone owes, by a date. One table, one list, one place to see what is overdue. Sources link back: meeting:2026-Q3, feedback:41, audit:SOP-002.description-quality, rma:RO-0007.

Meetings are records, not calendar entries. A meeting row holds kind, date, attendees, a link to its pack, its minutes, and its actions. Scheduling is a convenience on top; the record is the point.

Phase 1 — the task register (build first)

  • sqlite tasks(id, created, source, source_ref, title, detail, owner_role, owner_email, due, state, closed_at, closed_by, note), states open → done | dropped with a reason on both closings.
  • Admin card: what is open, grouped by owner, overdue in red; add, edit, close, drop.
  • Assistant: list_tasks, and create_task behind the usual confirm card, for every department; "what do I owe" and "add a task to fix the five descriptions" both work.
  • The vault stays readable: a nightly job writes ~/Notes/tasks.md from the table, so the notebook still shows the truth without being the source of it. The ## Open sections in project notes get migrated once and then generated.
  • Audit: SOP-015.open-actions (an action from the last review still open with no new date) and a new overdue-tasks warn.

Phase 2 — meetings as records

  • sqlite meetings(id, kind, starts_at, attendees, pack_path, minutes_path, state).
  • Admin card: upcoming and past, "generate pack" (runs quarterly-pack), "open minutes", and "turn minutes into tasks" — parses the - [ ] lines out of the minutes file and creates tasks with owner and due date, showing them for confirmation first.
  • Weekly review (SOP-013) and quarterly review (SOP-015) both become meeting kinds, so the weekly feedback triage gets the same treatment as the big one.

Phase 3 — scheduling, the cheap way

No calendar API on the server, so: generate an .ics invitation and email it with Resend from hello@ to the attendees. Their own calendars do the rest, including reminders. Recurring rules for the weekly and quarterly reviews. If Google ever grants a service account, this becomes a real calendar write; the .ics keeps working either way.

Phase 4 — recording and minutes from audio

  • Upload an audio file on the admin page (phone recording is fine). ffmpeg normalises it.
  • faster-whisper on the CPU, small model, transcribes offline — nothing leaves the building. Four cores and 6 GB free is enough for a 90-minute meeting well inside an hour, run as a background job.
  • The transcript is stored beside the minutes. Then, and only then, the assistant is asked to draft minutes and propose actions from the transcript, shown for editing before anything is saved.
  • Rules: everyone in the room is told it is being recorded; the audio is deleted after the minutes are approved, with the transcript kept; nothing is auto-published anywhere.

Order and cost

Phase 1 is the one that changes behaviour, and it is half a day. Phase 2 is a day. Phase 3 is a couple of hours. Phase 4 is a day plus a model download, and it is the least important — a meeting that produces three clear actions beats a perfect transcript nobody reads.

Related: mrp, roles-and-skills, reporting.

Known limitation: the server cannot write to Google Calendar

The Workspace org policy blocks service-account key creation (iam.disableServiceAccountKeyCreation), so the server has no credential it could hold. Invitations therefore go out as .ics attachments emailed from Angel's own address, and the normal calendar client handles the reminders. That works today and costs nothing. Revisit only if the policy is relaxed or a per-user OAuth consent flow is worth the build. Tracked as task

113 in ~/Notes/tasks.md.

Log

  • 2026-09-13: plan written.