¶Meetings

An agenda before, notes during, minutes after — and the action items become issues on the project's board.

That last part is the reason this belongs in a tracker rather than beside one. A decision that produced work produces a row somebody is accountable for, and it shows up in the workload report, on the Gantt and in a timesheet without meetings knowing any of those exist.

Off by default. Administration → Workspace → Features turns it on per workspace, and FELAGI_MEETINGS=false removes it from the installation entirely — a per-team switch that could override an installation-wide one would not be a kill switch.

¶Scheduling

A meeting belongs to a project, never to a workspace alone. Without one there is no answer to "which of these matter to me", and a tracker with forty projects grows one undifferentiated list of every meeting anybody held.

Saving a meeting sends nothing. Invitations go out when you send them, because a typo in a title should not already be an email everybody has.

¶The invitation

An .ics attachment, which is what makes it an invitation rather than an email about a meeting. Without one every recipient copies a time into their own calendar by hand and one of them gets it wrong.

Two details matter and are easy to get wrong:

• The identifier is stable for the life of the meeting, and derived from the ULID rather than the row id — so an installation restored into a new database keeps its calendar entries instead of issuing duplicates of every meeting.
• A sequence number rises with each change, which is what makes a second email an update to the entry already in somebody's calendar rather than a second entry beside it. A duplicate is how somebody ends up in the wrong room.

Cancelling sends METHOD:CANCEL, so the entry disappears from a calendar instead of sitting there looking valid.

Nobody is re-invited once they have replied. An organiser adding a seventh person a week later must not reset the six replies they already have.

¶Repeating

Pick an interval when scheduling and Félagi keeps the next few occurrences in existence, topped up daily by felagi:meetings.

Generated, not extended. The same reason cycles are: a series somebody has to remember to extend lapses in March, and nobody notices until the sync is not in a calendar.

The pattern is kept apart from the occurrences, and that separation is the point. Conflating them is what makes every calendar application confusing — edit one Tuesday and you are asked whether you meant all Tuesdays, because the Tuesday you clicked is both an event and a description of every event. Here a meeting is always one meeting: edit it, rename it, move it, cancel it, and the series carries on producing the ones after it.

Some consequences worth knowing:

• Attendees are inherited from the newest occurrence. Add somebody to next week's sync and they are on it from then on; remove them and they stop. A separate attendee list on the pattern would be a second copy of the truth, and the copy that drifts is the one nobody opens.
• The agenda is not carried forward. A standing agenda that repeats is one nobody reads by the fourth week, and an agenda copied from last time describes a meeting that already happened.
• The next slot follows the last occurrence, not today. Counting from today would drift: a fortnightly series topped up on an off-week would move to the other week and stay there.
• Nothing is backfilled. A series created today does not invent the Wednesdays it would have had last year.

Stop repeating ends it. Scheduled occurrences with nothing written on them are removed; anything with notes or circulated minutes stays, because that is the record of a meeting that happened rather than a plan. If the occurrence you were looking at was one of the empty ones, you land back on the list — sparing the one you happened to open would make the rule depend on where you clicked from.

¶Status

Worked out, not set. A status somebody has to remember to change is a status that lies within a week.

Awaiting minutes is the list that makes the feature worth having. A meeting whose minutes were never written is invisible in a calendar; it shows up here and nowhere else.

¶Notes and minutes

Two fields, kept apart on purpose.

Notes are what somebody types while the meeting happens — fragments, names, half sentences. Plain text, because they go to a model verbatim and a rich-text editor would send markup as content.

Minutes are the version other people read.

The notes are kept after the minutes exist. A summary whose source has been overwritten is an assertion nobody can check.

Minutes are circulated once. Minutes that quietly change after people have read them are worse than late ones, so the timestamp both records the event and prevents the second one.

Everybody who was invited gets them, in their inbox and by email. The email carries the summary and a link, not the whole document: minutes with action items in them are read once and referred to for months, and the action items are tracked issues whose status changes after the mail was sent.

¶Drafting the minutes

Optional, off unless an operator turns it on, and the one place in Félagi where the server calls a model.

Everything an agent does happens in a CLI on hardware you control. This is the exception, so the reasoning is worth stating:

• It is not agent work. Nothing is checked out, nothing is executed, no credentials are involved. It is one text transformation on text a person just typed.
• Running it through the task queue would mean minutes only work for a team that has a daemon, a runtime and a registered agent. Meetings are a human activity — a team using Félagi as a tracker with no agents at all should be able to write minutes.
• It is off unless a provider is named. An installation that does nothing makes no outbound model call, ever.

FELAGI_MINUTES_PROVIDER=anthropic
FELAGI_MINUTES_MODEL=claude-haiku-4-5-20251001

What is sent: the notes, the agenda, the meeting title and the attendee names. That is the honest cost, and it is stated here rather than in a footnote — meeting notes are often more sensitive than source code.

¶Why structured output rather than a summary

Asked for a summary, a model returns a paragraph that reads well and buries the two sentences somebody needed: what was decided, and who is doing what by when. Asked for a schema, it has to separate them.

The separation is also what makes the result usable. Every decision and every action item lands in its own field, so an action item can become a real issue — which is a thing a paragraph cannot become.

The instructions do the opposite of what a summariser usually does: they forbid invention. Minutes are a record, and a plausible sentence in a record is worse than a gap, because a gap is visible.

¶Nothing is saved until you accept it

The draft opens in a panel. A draft written straight over the minutes is the failure this feature is most likely to have, and only the person who called for it can tell whether the model read the room correctly.

The panel leads with what the model could not work out — the field that makes the rest trustworthy. Without somewhere to put an ambiguity, a model resolves it silently and the minutes contain a decision nobody made.

The headings in the finished document are rendered by Félagi, not asked of the model. A model asked for formatted prose returns a different shape each time, and minutes that look different every month are minutes nobody skims correctly.

¶Owners

Matched by name against the people who were in the room, on the full name and then the first name. Never created, and never guessed at beyond that: an action item whose owner could not be matched is unassigned, which somebody fixes in a second. An invented user is a mess.

A due date the model got wrong is dropped rather than stopping the issue from existing.

¶Not there yet

• Weekly intervals only. "The last Friday of the month" and "the 31st" are two different intentions and February disagrees with both, so a monthly rule needs a policy nobody wants to read.
• One series per meeting. A sync that moves permanently is a new series.
• No inbound RSVP. Replies are recorded in Félagi; a reply sent from a mail client to the .ics does not reach it.
• No attachments on a meeting, and no minutes in the knowledge base — though an article can link to one.
• No series over the API, and no sending invitations or circulating minutes over it either — both are irreversible broadcasts. Reading and scheduling are there.
• Not in the import or the export.
• No attendees who are not members. An external participant has no account, and inviting an address Félagi cannot show a page to would be an email pretending to be a feature.
• Agents do not attend. The attendee column is user_id and not a morph, because a polymorphic column where one of the two values can never appear is worse than a plain one.