Update once, prepare from progress

Keep projects and tasks current as work happens. This recipe reuses those updates to prepare the project portion of an upcoming Cal.com meeting, so attendees do not have to report the same progress again before the meeting. The more current the work is, the less separate preparation remains.

It reads one booking and its attendees, parses the previous meeting notes, and checks the projects you select. Booking intake and an optional existing brief supply genuinely new topics; they do not replace current project state or ask people to repeat it.

What is ready and what still needs attention

The result separates progress already prepared from project updates, unresolved items carried from the previous meeting, decisions that still need the room, and new context from the booking or 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 the previous meeting’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 an email from the Cal.com booking matches exactly one active participant in that project. Missing or ambiguous matches are reported under omissions instead of exposing that project’s tasks.

Running it before the meeting

Turn this on under Automation and Recued checks every fifteen minutes for bookings starting within your lead time (two hours by default) that it has not prepared yet, and prepares the soonest one. Each meeting is recorded once, so a later check moves on to the next rather than repeating itself; running a meeting by hand is never blocked by that record. Nothing due is a quiet stop, not a failure. What Recued has already prepared is recorded per month, so the check stays the same size however long you run it.

Cal.com has no “before the meeting” webhook — it can tell Recued when a booking is made or when a meeting starts, one too early to be useful and one too late — so the timing is Recued’s own. Each automatic run asks permission to record what it prepared — once per meeting, not once overall. Answer them promptly: a run waiting on approval counts as a failed run, and five in a row switch the automation off until you re-enable it. If you would rather it never asked, lower the risk on the storage operation in Settings; turning the approval off is a decision about your own bookkeeping, not about the meeting.

Inputs and limits

Nothing is required except a Cal.com connection. Use the UID of one future booking occurrence, not a recurring-series UID.

Everything else is found for you, and every part of it can be overruled:

• Previous meeting — by default the most recent past booking with the same first attendee on the same event type. Set Previous booking UID to pin a different one; both the activity window and the prior-meeting notes then come from that single booking, so re-running gives the same result. Set Previous meeting to skip to ignore earlier meetings entirely — nothing is searched, nothing is downloaded, and no approval is requested.
• Previous meeting time — the end of that booking. Supply your own to widen or narrow the window regardless of which meeting was used.
• Previous meeting notes — that booking’s own Cal.com transcript, when one exists. Recued asks before downloading it, because transcript links are private and expire after an hour. Anything you attach is a supplement, not a replacement: your file and the transcript are both read and both go to the preparation, each labelled with where it came from. Attach notes for a meeting Cal.com did not record, or a fuller account of one it did. Use skip when you want nothing from the past read at all.
• Projects — the project IDs Recued recorded on the booking when it created it. Supply your own list to override.

None of this is a chain you have to be at the end of. A first meeting on a project works with nothing to look back on: with no earlier booking and no time supplied there is no activity window at all, every current row is in scope, and coverage says so. Prior-meeting context is optional throughout — without notes the recipe still prepares from current project and task progress, and coverage reports exactly which sources it used and which it could not. The upcoming brief is optional and should contain new agenda material rather than another status report. Choose at most eight project IDs; extra selections are reported as omitted. Task reads are capped at 50 per included project and report any remaining count. The recipe performs no durable writes.