Meeting transcripts

A transcript goes through six steps: check the upload, read the file, summarise it with an AI model, match the action items to Linear tickets and to server members, post the summary in the channel, then send each owner a direct message. Only a button press in that message writes to Linear, whether it files a ticket or changes one. For the member’s view, see Meeting transcripts. A voice call reaches the same pipeline from voice notes.

Settings

Switch it on with MEETING_TRANSCRIPTS_ENABLED; it also needs GEMINI_API_KEY, and LINEAR_API_KEY is optional. The summary channel name, file size limit, daily limit and retention time are set under Meeting transcripts on Configuration, and what each key unlocks under Integrations. REMINDER_ALLOWLIST (Reminders) limits who gets action item messages, not who may upload. The voice notes variables are on Voice notes.

What starts a transcript

A new message starts a transcript only when all of these hold:

• The feature is on, and the message is in the one configured server.
• It is in a text channel whose name is the current summary channel name: the name an admin set, else MEETING_CHANNEL_NAME. The name is read per message, so a rename applies at once. Threads do not count.
• It is not from a bot, and it is a normal message or a reply.
• It has exactly one attachment.

Anything else is handled by the nudges. Edits never start a transcript, and the allowlist is not checked, so any member who can post in the channel can upload.

Uploads and nudges share one queue: 4 at a time, at most 200 waiting or running in all, and 10 per author. Work for one author runs in order. A message the queue refuses is dropped, its hourly allowance is given back, and the bot logs at most one warning a minute, [meetings] queue full, dropped N.

The pipeline

Each step can end the upload. The bot records why on the meeting row. To claim a row (step 4) is to insert or mark it so that only one run works on that upload.

Step	What happens	Ends the upload when
1. Hourly limit	One take from the author’s hourly allowance	The author has used 10 in the last hour. They get a nudge
2. Pause	Is the AI provider paused?	A recent outage paused uploads. The bot replies that the AI service is unavailable
3. Pre-check	Extension and declared size are checked, then the file is downloaded	Wrong extension, too large, or the download fails
4. Claim	A row is inserted for the message and the file hash	The same file or message was already seen: see Duplicates
5. Personal limit	One take from the uploader’s allowance of 5 in 24 hours	The uploader has used all 5
6. Daily limit	One take from the shared daily allowance	The daily limit is used up
7. Read	The file becomes plain text	Not UTF-8 text, empty after reading
8. Summarise and match	AI calls and Linear lookups, below	The AI is unavailable, or an unexpected error
9. Post and notify	The summary is posted, then each owner is messaged	A post fails

The attachment is downloaded over HTTPS, with no redirects, a 30 second limit and the size limit enforced while streaming.

The personal and daily limits are kept in memory, so a restart resets them. Both are taken before the AI is called. A slot comes back only when the run ended because the AI provider was unavailable or the bot was shutting down. Any other failure keeps it, because the model may already have been used and billed. A file refused before the AI is called, for example for its extension, never takes a slot.

Reading the file

The extension decides how the file is read. Only .txt, .vtt, .srt and .md are accepted, and the bot checks the name, not the content.

• The bytes must be valid UTF-8 with no NUL character, or the file is not_text.
• A leading byte order mark is removed and line endings are normalised.
• .txt and .md are used as they are, trimmed.
• .vtt and .srt are read cue by cue. A block counts only if it has a --> timestamp line. WEBVTT, NOTE, STYLE and REGION blocks and bare cue numbers are dropped. Tags and HTML entities in the cue text are removed. A <v Name> voice tag sets the speaker, and consecutive lines from one speaker are joined as Name: text. Tag scanning is a single forward pass, so a hostile file cannot cause slow matching.
• Text over 400,000 characters is cut and ends with [transcript truncated]. The limit is fixed, applies to a voice transcript too, and the channel post then says only the first part was read.

An empty result is empty. The reply wording is on Meeting transcripts.

The summary

The summary uses the AI service’s default model with low thinking, a 120 second limit per call and a 16,384 token answer limit that the model’s thinking also counts against. The whole step has 5 minutes. The answer must fit a fixed shape; if it does not, the bot asks once more with thinking at its minimum. The transcript goes in <transcript> tags with the file name, angle brackets neutralised. The system prompt says that tagged text is data, not instructions, to write in the transcript’s language, to invent nothing, to add English search keywords for each action item and topic, and to classify each action item as described in Updates to existing tickets.

A transcript over 200,000 characters is cut at line breaks into parts of about 200,000 characters, so at most two parts with the fixed 400,000 limit (the code allows 8). The parts are summarised 3 at a time, and one more call merges them when more than one had anything in it. If one part fails, the whole run fails: a summary that silently leaves out part of the meeting is never posted.

The answer is cleaned before use. A title that describes the act of filing instead of the work is repaired: Create a ticket for the battle axe becomes Add battle axe and Open an issue for the login crash becomes Fix login crash. Other titles are left alone.

Field	Rule
Title	One line, at most 120 characters. When blank, the file name without its extension, then Meeting. A voice meeting has no file, so its name is Voice meeting
Held date	Kept only when it is a real ISO date. Otherwise none
Attendees	Up to 50 names of 80 characters, duplicates removed
Decisions, discussion	Up to 20 lines of 300 characters each, duplicates removed
Action items	Up to 15, duplicates by title removed. A title of at most 120 characters, a description of at most 500, an owner name of at most 80, an English search term of at most 120, up to 10 ticket numbers that match ABC-123, and the kind, update kind, target status and target hint described below
Topics	Up to 20 of 120 characters, each with an English search term
Team hint, project hint	A team name and a project name if one was stated, each of at most 80 characters, else none

Updates to existing tickets

Each action item has a kind. new_work is work that does not exist yet. update_existing changes work that is already tracked, such as “move the login bug to in progress”. A missing or unknown kind is read as new_work, so a bad answer never fails the whole summary.

For an update the model also gives:

• An update kind: status when a status was stated, otherwise comment.
• A target status from a closed list:

Said in the meeting	target_status	Linear state picked
Will be done later	backlog	A state of type backlog, preferring the name Backlog
Planned for the current week	todo	A state of type unstarted, preferring Todo
Being worked on now	in_progress	A started state, preferring In Progress, never one with review in its name
Built with a pull request that is not merged	in_review	A started state with review in its name
Unclear	none	No status, the update is a comment

• A target hint: the words that name the ticket, used as the search term.

There is no value for Done or Canceled, and the extraction schema drops anything else to none. A second guard sits in the Linear layer: pickState returns nothing for a state of type completed or canceled, so even a wrong mapping cannot close a ticket. A team with no matching state gives no_state, and the bot adds a comment saying what the meeting suggested instead of guessing.

The update’s target is the ticket found in the next section: one named in the meeting, or a high search result for the target hint. It is stored on the action item as target_issue_identifier, target_issue_url and target_issue_title. An update with no target is kept, shown as a note, and never selectable.

Matching to Linear

This step runs only with a Linear connection. Without one, every item is kept with no link and the topics have no ticket.

1. Named tickets. A ticket number the model reports must also appear in the transcript or in the item’s own text, so a made-up number is never looked up. The bot looks each one up in Linear, at most 20, 5 at a time: numbers tied to an item or topic first, then numbers said anywhere in the transcript. A private team’s ticket, or one whose team cannot be told, is treated as not found. A verified ticket becomes the item’s existing ticket.
2. Search. For each item and topic with no existing ticket, the bot searches Linear with its English search term, falling back to the title: 5 results, private teams left out, 5 searches at a time. For an update item the term is its target hint. A transcript in any language therefore finds English tickets.
3. Verdict. One call to gemini-3.5-flash-lite (a small, fast Gemini model), with minimal thinking, a 20 second limit and a 2,048 token answer limit, is shown each item and its candidates (candidate title and description cut to 300 characters). It answers high, low or none per candidate, and only a candidate the search actually returned is accepted.
4. Second pass, updates only. An update item that no verdict placed is searched again, one distinctive word at a time (words of the target hint, the search term and the title, at most 5), and the new candidates are judged by meaning, so “add 5 rounds to the crossbow” finds a ticket called “Add crossbow”. New work is never widened this way, so a loose keyword hit cannot hide it as already tracked.

Result	For an action item	For a topic
high	The item’s existing ticket, linked in the post. For an update item it is the target	The ticket is linked under Related issues
low	The item’s possible ticket, shown only in the direct message as a possible match. Pressing Create still files a new ticket	Ignored
none	No link	No link

A failed search, lookup or verdict only means no match. It never stops the upload. A low ticket is stored on the action item as its possible ticket, with its title. A high ticket is stored as the item’s target, for new work as well as for updates. For new work the target marks the item as already tracked, so the direct message shows it but never offers it.

Every verified ticket that no item and no topic carries is added to the topics as a related issue, labelled with its own title, so a ticket mentioned in passing still appears under Related issues.

Team. When the model reports a team name, the bot lists the public Linear teams and keeps the team only when exactly one has that name after ignoring case, accents and extra spaces. Anything else means no team was named.

Project. When a team was named and the model reports a project name, the bot lists that team’s projects and keeps the project only when exactly one has that name, by the same rule. It is stored as linear_project_id. Without a named team there is no project.

Suggested team. When no team was named, or the named one did not resolve, and the meeting has at least one item that is not an update, one more call to gemini-3.5-flash-lite may suggest a public team. It runs beside the Linear matching, with minimal thinking, a 10 second limit and a 128 token answer limit. It is sent the meeting title, the decisions and the action item titles (cut to the first 4000 characters), and the name and one-line Linear description (cut to 300 characters) of each public team, inside tags with angle brackets neutralised. The model is told the tagged text is data, to answer with one listed team name or an empty string, and never to guess. The answer counts only when it matches exactly one public team by name, ignoring case and accents. A meeting that only updates tickets, and a meeting with fewer than two public teams, makes no call. A failed call or team list means no suggestion.

The suggestion is stored as suggested_team_id. It is never written to linear_team_id, so it never decides where a ticket goes and never files anything. It only changes the team drop-down, see Creating the tickets.

Owners

The bot matches each attendee and each item owner to a member of the server by name. Names are normalised as for Linear matching: ignoring case, accents and extra spaces, with no partial match. Members who have left are not considered.

• Exactly one member with that name is the match. Attendees are stored with it, and the item is assigned to that member.
• Two or more, or none, is no match. The item has no assignee and goes to the uploader.

The rule is strict on purpose: a wrong person must never be offered, or given, a ticket.

At most 10 people are sent a message per transcript. When more owners are named, the first ten in item order keep their items and the rest are treated as no owner, so they go to the uploader. One of the ten places is kept for the uploader whenever they will receive anything.

The channel post

The bot stores the draft, then posts the summary as a reply to the upload. A voice meeting has no upload, so its post is not a reply, notifies nobody and goes to the channel chosen for that meeting. Every line is made inert: markdown and brackets are escaped, @ is broken so a name never reads as a mention, mentions are off, and link previews are suppressed. Links are shown only for https and http addresses.

The title is cut to 200 characters, each name to 60, each line to 500. The post is split on line boundaries into messages of at most 2000 characters, so a link is never cut, and at most 4 messages are sent. The first replies to the upload and is the only one that notifies its author. What does not fit ends with -# N more lines not shown., and a cut transcript ends with -# Only the first part of this transcript was read because it is too long.

Parts, in order, each left out when empty except where noted:

1. The title as a heading, then the date as a Discord timestamp, shown in each reader’s own language.
2. Attendees (N), at most 15 names, then and N more.
3. Decisions, at most 6 bullets, then and N more in the transcript.
4. Action items, before the discussion so the work comes first. They are grouped under the owner’s name as said in the meeting, with Unassigned last. A step line is its title, followed by - and an embedded link when a verified ticket covers it. An update step is Update <link>: status to <Status>, Update <link> for a comment, or its title with no matching issue found, so nothing to update. A link appears only for a verified existing ticket and reads ID: title, with brackets removed, @ broken and the title cut to 70 characters. A possible ticket is never shown in the channel. With no action items this part is the small line No action items came up in this meeting.
5. Discussion, at most 6 bullets, with the same overflow line.
6. Related issues: each topic with its ticket, plus verified tickets mentioned anywhere in the meeting that no item carries.
7. When there are action items and Linear is connected, the small line Owners got a DM to turn these into Linear tickets.

Posted message ids are stored per part as each is sent. A re-run of the same meeting, after a failure or a restart, first deletes the messages it had already posted, so the channel never holds a half post next to a whole one. The summary link in the direct messages and in each ticket footer points to the first message. The post is never edited afterwards: the direct messages show which items became tickets.

The action item messages

The direct messages go out after the post is saved, because the buttons act only on a posted meeting. Items are grouped by recipient: the matched owner, or the uploader for items with no owner. Without a Linear connection nobody is messaged, because the buttons could not file anything.

For each group:

1. If the recipient is not allowed by REMINDER_ALLOWLIST, the group is recorded as failed with not_allowlisted and nothing is sent.
2. Otherwise every item is marked selected and one direct message is sent, with no mentions and no link previews. It is built from the items as just selected, so it opens with every item ticked and Create selected (N) already enabled.
3. A failed send is recorded with dm_closed or discord_<code>, otherwise send_failed.

When a send failed or errored, the bot replies to the upload with the people it missed: <names> could not get a DM (their DMs are closed), so their action items are only listed above. Up to five display names are shown, then and N more, and a name the bot does not know reads Someone. A recipient excluded by the allowlist is recorded but not counted there. A voice meeting adds the same sentence to its result line.

What the message shows:

• Size. At most 2000 characters, items numbered. When they do not fit, whole lines are dropped from the end and -# N more not shown is added. The drop-down still lists the first 25, numbered like the message. Item titles are cut to 100 characters and the meeting title to 80.
• Buttons. With one open item: Create ticket and Dismiss, no drop-down. With several: the item drop-down and Create selected (N), disabled at 0.
• Cycle drop-down. While any open item is new work, a drop-down with the placeholder Cycle sits above the buttons with No cycle, Current cycle and Next cycle. It shows the choice stored on the first open new-work item, and a press stores the pick on every open new-work item.
• Links. ID: title, cut to 70 characters. A low match reads this might already be <link>. Check it before creating. and stays selectable. A high match on new work reads already tracked as <link> and is not selectable, so it is never created twice.
• Updates. An update is selectable only when it has a target. A line reads Move <link> to <Status> or Add a note to <link>, and with no target Note: <title> (no matching issue found, nothing to update). After pressing it shows applied or noted with the link. When every open item is an update the wording becomes Apply update, Apply selected (N), the placeholder Choose the items to apply and the footer Nothing is changed until you press Apply update. or Choose items, then press Apply selected. Nothing is changed until you do.
• Working. Every control is disabled and the primary button reads ⏳ Creating… or ⏳ Applying….
• Closed. The message has no components. The footer reads It is created., It is updated. or It is created and updated., and unselected items read not filed. Outcome notes stay under the footer as small -# lines: where the tickets were filed, a cycle miss, details Linear rejected and tickets Linear did not confirm.

Controls

A customid is the identifier Discord sends back when a control is used, in the form prefix:action:arg.

Control	Customid	What it does
Drop-down	meeting:select:<meeting id>	Sets which open items are selected: pending or approved. It saves, then refreshes the message. An item whose Linear issue id is already claimed is left as it is
Create selected (N) or Create ticket	meeting:create:<meeting id>	Files each selected item. With a lone open item there is no drop-down, so pressing Create ticket selects it and files it
Dismiss all or Dismiss	meeting:dismiss:<meeting id>	Marks every open item rejected, except an item whose Linear issue id is already claimed, because that id may belong to a real ticket
Cycle drop-down	meeting:cycle:<meeting id>	Saves none, current or next on the open new-work items. The message is updated from its own components at once, then the owner check and the save run. If the check fails the message is put back, and if a concurrent claim kept an item’s old choice the message is re-read from the database
Team drop-down	meeting:team:<meeting id>:<id of the DM>	The answer to Which Linear team should these tickets go in?. It carries the id of the DM so that message can be closed after the create

The button handler is registered at every start, so messages already sent keep working when the feature is switched off. The two controls that touch Linear, Create selected and the team drop-down, answer Meeting tickets are turned off. while there is no LINEAR_API_KEY. The item drop-down, the Cycle drop-down and Dismiss all do not need Linear.

A control defers its answer first, because Linear and the label model can be slow; the Cycle drop-down instead answers with an update of its own. Then it loads the meeting:

• A meeting that is not posted answers This meeting is no longer available. Nothing was created.
• The clicker’s items are the ones assigned to their member row, plus items with no assignee when they uploaded the transcript. With none, These action items are not for you.

Creating the tickets

Create selected handles the clicker’s approved items, and any left creating:

1. The clicker must still be in the server.
2. The bot works out the teams offered to the clicker, as for ticket prompts: their Linear teams when linked and they have any, otherwise all public teams. Name matching runs here if they are not linked and have never been decided on. If the list cannot be read in time the clicker is told Linear is slow right now. Try again in a moment.
3. The team is the meeting’s named team when it is one of the teams offered to this clicker, else the single offered team. Otherwise the clicker is asked with a private follow-up holding the drop-down Choose a team, the DM is drawn again at the same time, and the tickets are created on their answer. The DM is closed when the answer files something. The picked team must be one of the offered teams. When the meeting named no team, the pick is saved on the meeting, so the next approver is not asked again if that team is offered to them.
4. When the meeting has a suggested team and the clicker is offered it, that team is listed first with the description Suggested from the meeting, so the 25-option cut cannot drop it. Nothing is preselected. With no suggestion, or one the clicker is not offered, the drop-down is unchanged. When there was a suggestion the bot logs [meetings] team suggestion kept or changed, counts only.
5. The project is the meeting’s project, only while it is still one of the chosen team’s projects. When the chosen team is the meeting’s own, its project, labels and cycles are looked up while the team list and any updates are still working.
6. When the AI is configured and the team has labels, the model picks up to 3 labels for each ticket. A failure means no labels.
7. Each item is claimed with beginCreate, which moves it to creating and fixes its Linear issue id, then Linear creates the issue with that id. Up to 3 items are created at the same time, each claimed on its own. Each Linear step has the same limits as for ticket prompts.
8. The cycle is read from the choice on the claimed row, so a pick made after the click was read still counts until the claim. It is resolved once per choice against the team: current or next becomes that cycle, dropping a current cycle that has ended and a next cycle that has started. A team that does not use cycles, or has no such cycle, gives no cycle and a note: <team> does not use cycles, has no current cycle or has no next cycle, so the ticket was filed without one, or Could not read <team>'s cycles when the lookup failed. The note is kept in the closed message, one per choice that filed tickets.
9. The assignee is the clicker’s Linear user, only for an item assigned to the clicker. An item with no owner is unassigned.
10. The description is the item’s description with every line made plain text (markdown, links and images escaped, www. broken), because it is model output over an uploaded file. Then a blank line, --- and a footer: From the meeting "<title>" in [Discord](<link>), Approved by [<name>](<link to the profile>) and, for an item with no assignee but a named owner, Owner in the meeting: <name>.

If Linear rejects the ticket as invalid while an assignee, labels, project or cycle were sent, the bot tries once more with the same issue id and without any of them, and logs [tickets] create retried without extras. The same helper serves ticket prompts. The reply says how many tickets lost what, for example Linear rejected some details, so ENG-12 was filed without its labels or cycle. An issue found again by its id after Linear was too slow to confirm it gets Linear did not confirm the details of ENG-12, so check it in Linear. and no team or cycle claim. After a failure no new item is started, the failed item goes back to approved and the rest stay selected. Failures are logged as [meetings] create failed: <kind> (<name>).

On success the item becomes created with the issue id, identifier and link, and the direct message shows created: with the link.

Applying updates

In the same press, update items are applied first, then new tickets are created. An update never uses the create path, the team picker or labels.

1. Authorisation. The bot writes with its own Linear key and any member can upload a transcript, so the clicker must have an admin-made link to a Linear user (linear_link_source = 'manual'; a name match can be copied by choosing the same display name) and be a member of the target ticket’s team. Membership comes from the clicker’s own teams, read fresh from Linear each time (never the cached list) and never the all-public-teams fallback. A ticket whose team is private or cannot be read counts as not found. A refused item changes nothing and takes no claim. If the check itself fails, nothing is changed and the loop stops with Could not check your access in Linear, so nothing was changed. Try again in a moment.
2. Claim. beginApply moves the item from approved to creating, or takes over a creating item not updated for 2 minutes. No Linear issue id is invented.
3. Write. A status update sets the picked state. A ticket already in that state is unchanged and nothing is written. When the team has no matching state, or the update is a comment, the bot adds a comment: Meeting note: <title>. <description> or, for a missing state, The meeting suggested the status "<Status>", which this team has no matching state for., then a footer with the meeting link and approver, as for tickets. Comments are cut to 2,000 characters. A comment carries the item’s id as its Linear comment id, so a retry after a timeout or a crash finds the stored comment instead of posting a second one.
4. Finish. markApplied sets the item to created with the ticket’s identifier and link. A ticket that vanished releases the claim and answers Could not find <ticket> in Linear, so nothing was changed. A Linear error releases the claim, stops the loop and leaves the rest selected.

A retry is harmless: setting a state is idempotent, and a timeout reply tells the person to check the ticket first, because a comment could have been added.

Why a retry cannot make a second ticket

The Linear issue id is chosen before the create call and reused on every retry, so a timeout cannot cause a duplicate: the retry looks the issue up by that id. A creating item not updated for 2 minutes can be claimed again, which is longer than three Linear steps of 20 seconds. A fresh creating item answers Still creating that ticket. Give it a few seconds.

Duplicates

Each upload is keyed twice: by its message and by the SHA-256 of the file’s bytes. Either key already existing means the file was seen.

The earlier row is	What the bot does
Posted, with nothing to resend: every message went out, or there is no Linear connection, or fewer than 2 minutes since its last update	Replies I already summarised this file: [see the summary](<link>), or Already received this file. when no summary message id was kept, and does nothing else
Posted, with messages not yet sent, and 2 minutes or more since its last update	The messages that had not gone out are sent now, and the bot replies Sent the action item DMs that had not gone out. (or names the people who could not be reached). Only with a Linear connection
Processing, less than 10 minutes since its last update	Replies That file is already being processed.
Processing for 10 minutes or more	Treated as a crash and taken over
Failed	Taken over, so uploading a file again after an outage works

A taken-over meeting is claimed with a compare-and-set (an update that succeeds only if the row still has the status the bot last read), so two uploads of the same file cannot both run it; the other gets That file is already being processed. A live run refreshes its row every minute, which is how a stale one is told from a live one.

A file rejected before it is read, for example for its extension, is keyed on its message instead of its bytes, so it never blocks a corrected file.

A voice meeting has no message. It is keyed by the SHA-256 of its transcript, its voice channel and its start time, with source_message_id left empty, so finishing the same meeting twice finds the first row.

Restarts and retries

The bot saves its progress so that a restart leaves nobody with nothing or with duplicates:

• The meeting row is claimed before any work and kept alive by a heartbeat (the run refreshes the row every minute, so a crashed run shows up as stale).
• The ids of the posted messages are saved one by one. A re-run deletes them and posts again.
• Each action item has its own message state, so messages that did not go out can be sent later by uploading the same file again, after 2 minutes.
• A ticket creation is claimed before the Linear call and reuses one issue id.
• A voice meeting running at a restart is saved and finished at the next start. See Restart and recovery.

Nudges

A message in the channel that is not an upload gets a reply, at most once an hour per person for each kind:

The message	The reply
More than one attachment	Please upload one file at a time.
Text and no attachment	Please upload the transcript as a file (.txt, .vtt, .srt or .md) and I will summarise it, or run /notes start in a voice channel to take notes live.
One attachment but over the hourly limit	You have uploaded a lot of files recently. Please try again later.

A message with no text and no file gets nothing.

When the AI is down

When an upload fails because the AI provider times out, is rate limited, is failing (status 408, 429 or 500 to 599) or rejected the key (401 or 403), the bot replies that the service is unavailable and pauses all new uploads for 60 seconds. It logs [meetings] AI unavailable, pausing for 60 s.

• An upload that arrives during the pause gets the same reply and is not claimed or queued, so uploading it again later works.
• The upload whose run hit the outage is marked failed, which also lets it be uploaded again. The run gives its limit slots back; a run that fails any other way does not.
• A voice meeting that ends during the pause is saved instead of being refused, see Writing the notes.

Retention

The transcript text is stored in its own table, meeting_transcripts, and nowhere else. At every start, even with the feature off, and then once a day, the bot deletes the rows older than MEETING_TRANSCRIPT_RETENTION_DAYS days. A failure is logged as [meetings] prune failed: ... and tried again the next day.

What stays: the meeting row with its title, date, summary text, who uploaded it (for a voice meeting, who started it) and the ids of the channel posts, the attendee names, and each action item with its status and ticket link. A ticket already created in Linear is not removed.

The channel

The summary channel is where uploads are read and where summaries of open voice meetings are posted. Its name is the one an admin set with /notes-admin summary-channel set, stored in meeting_settings, or MEETING_CHANNEL_NAME when none was set. It is loaded once at startup, and a failed read stops startup.

• It is not created at startup. It is created the first time a voice meeting that goes to the shared channel starts, and only if no text channel with the name exists. See The summary channel. With voice notes off, nothing creates it: create a text channel with the configured name yourself.
• Uploads wait for it. An upload is read only in a text channel with the current name. Until one exists, an upload is ignored with no reply.
• It is created with the topic Upload a meeting transcript (.txt, .vtt, .srt, .md) for a summary and action items, or run /notes start in a voice channel. and no permission overwrites, so every member of the server can read it. This is a single-server assumption that must become an explicit rule before the bot serves more than one server.
• Creating it needs Manage Channels. Without it the bot logs [meetings] channel create failed: <class> and, for a voice meeting, keeps the summary in the voice chat.
• Renaming never moves or deletes the old channel. Summaries already posted stay where they are.
• A channel found by name is used as it is. The bot needs View Channel, Send Messages and Read Message History in it.

The channel is an ordinary channel

The bot stores every normal message in a text channel it can read, so the upload message is stored like any other, with its text and attachment details. The file itself is never read into the message copy or into embeddings. Text typed in the channel is stored and embedded like any other message, so a transcript pasted as text becomes searchable chat history. The bot’s own summary post is stored as a bot message, and bot messages are never embedded.

When it is off, or a key is missing

Situation	What happens
MEETING_TRANSCRIPTS_ENABLED is false	Logs [meetings] disabled. No upload is read and no channel is created, and voice notes are off too. Direct messages already sent keep working while LINEAR_API_KEY is set
On, but no GEMINI_API_KEY	Logs [meetings] off: needs GEMINI_API_KEY. The same as off
On with a Gemini key	Logs [meetings] enabled, #<channel>, max N/day, linear on, allowlist N members, and linear off when there is no Linear key
On, no LINEAR_API_KEY	Summaries post with no ticket links and no action item message is sent. Nothing can be filed

Status lifecycle

Statuses are stored as text.

Meeting status	Set when	Next
processing	The claim, before the file is read	posted or failed
posted	The summary is in the channel	Final
failed	The upload ended with a reason, such as unsupported, too_large, not_text, empty, fetch_failed, ai_unavailable, daily_cap, uploader_cap, no_channel, recovery_failed, aborted or generic	posted, when the same file is uploaded again and succeeds. The status stays failed while it is read again. A voice meeting that failed with aborted is finished at the next start, see Restart and recovery

Action item status	Set when	Next
pending	The draft is saved. A DM then selects it, and an owner can untick it	approved or rejected
approved	The message opened with it selected, or the owner selected it in the drop-down	pending, rejected or creating
rejected	Dismiss all or Dismiss	Final
creating	Create selected or Create ticket claimed it	created, or back to approved on a failure
created	Linear made the ticket, or the update was applied	Final

Each item also has a direct message state: pending, sent or failed, with the reason when it failed.

Next

• Meeting transcripts for what members see.
• What the bot stores for what is kept.
• Data for the tables.
• AI and embeddings for the calls the bot makes.