Update once, prepare from progress

Keep projects and tasks current as work happens. This recipe reuses those updates to prepare the project portion of a meeting you are about to have, so the people in it do not have to report the same progress again. The more current the work is, the less separate preparation remains.

No calendar involved

You name the meeting: what it is, when it starts, and who is in it. Nothing is read from a calendar and nothing is written to one, so this works for a meeting in any calendar Recued does not speak to, or one that was never in a calendar at all — a call that got scheduled in a chat thread, a conversation you know is coming this afternoon.

Because you name it, it only runs when you ask. There is no scheduled check: a calendar can be swept for meetings that are coming up, and a meeting only you know about cannot.

What is ready and what still needs attention

The result separates progress already prepared from project updates, unresolved items carried from the last time you met, decisions that still need the room, and new context from an optional brief. Coverage and omissions show what Recued could not prepare.

This is a project-context supplement, not the whole meeting brief. It stays temporary: nothing is saved as a note, meeting record, or project record, and topics outside the supplied files and selected projects remain outside its claims.

Promises still owed

When an earlier meeting recorded something you promised, it is carried into this preparation as an open item with its own id — read back from what was recorded, not re-read out of anyone’s notes. Only promises still outstanding on the projects in scope appear; anything already settled stays out, so a meeting does not reopen a closed decision.

What “updated” means

Recued reads each selected project and up to 50 current tasks per included project. A task is in the update window when its current updated_at falls on or after Previous meeting time. A project is in the window when its updated_at or last_activity_at does. These timestamps prove only that a row was touched during the window. They are not an audit log and cannot prove which field changed or what its old value was.

Federated projects

A selected local project is eligible directly. A selected federated project is eligible only when one of the attendee emails you entered matches exactly one active participant in that project. Missing or ambiguous matches are reported under omissions instead of exposing that project’s tasks.

Inputs and limits

Required: what the meeting is, when it starts, and at least one project. Everything else is optional.

• Previous meeting time — when you last met about this. Leave it blank and there is no activity window at all: every current row is in scope, which is the right answer for a first meeting, and coverage says so. A value that is not a real date is refused rather than quietly treated as blank.
• Previous meeting notes — attach notes from last time if you have them. Nothing from the past is read unless you attach it. The parsed result stays temporary.
• Existing brief or agenda — optional, and best used for genuinely new topics. Current project progress is reused automatically and does not need repeating here.
• Meeting reference — optional. A calendar event id or any stable string, kept with the preparation so you can line it up with whatever calendar you actually use.

Choose at most eight project IDs; extra selections are reported as omitted. With none chosen the run stops — there is no calendar to take them from. Task reads are capped at 50 per included project and report any remaining count. The recipe performs no durable writes.