Update work once

This recipe starts after a meeting. It focuses on project follow-through instead of repeating scheduling, reminders, reception, or CRM logging. It transcribes the selected recording; you provide the attendee emails.

It proposes supported progress updates and new tasks in the projects you share, records what you yourself promised, and reports anything that needs a decision. When approved, those changes keep the work current so the next meeting can prepare from project progress instead of asking attendees to report it again.

Only federated projects

Every project this recipe writes to has to be a federated project. A task assigned to someone in an ordinary local project can never reach them: people receive work by reading a federated project, and a local one gives them nothing to read. Recued used to write those tasks anyway, into your own copy, and call the work assigned.

This does not mean anyone else has to be on Recued. A federated project is simply the container that can become theirs later. Seat a colleague in it by email today, and on the day they run their own Recued you fill in their contract on the participant you already have — every task assigned to them since is theirs immediately, with nothing re-modelled. Starting in a private list means redoing all of it.

So a meeting about a local project produces a review list and no changes. Federate the project first, or act on the review by hand. Selecting a mix is fine — the local ones are simply left out.

Who gets what

Work that belongs to someone else becomes a task in a federated project, assigned to them. That needs exactly one active participant in the project whose email matches the attendee — add them under Add participant, where an email alone is enough. Nobody matching, or more than one, keeps the suggestion in the review list rather than assigning by guesswork.

Work that is yours is recorded as a commitment rather than a task: your own index of what you owe and by when. You can turn commitments off. Promises made to you are not recorded twice: they are already the other person's task, where their progress on it is the better signal.

An existing task can be updated only when the recipe read that task during the same run.

Nothing is created that cannot be shared

A meeting that clearly calls for a new project is reported, never created. A new project would be local, and a local project is exactly what this recipe refuses to write into. Federating one is a deliberate act, not a side effect of a meeting.

In the meeting's language

Task titles and descriptions are written in the language of the meeting's own record — the people they are assigned to read them there.

Review before writing

Preview is the default and changes nothing. Apply writes the supported task changes as soon as you run it, so preview first to see them. Anything you promised is held for your approval before it is recorded.

One meeting, one set of changes

Once a meeting has produced work, Recued records that. Running the same meeting again shows you what it would propose but writes nothing, so a second transcript or a repeated run cannot leave you with two copies of the same tasks. Turn on Allow reconciling a meeting again when you mean to — for instance when a fuller transcript arrived after the first. A run that produced no work records nothing, so it never blocks a later attempt.