Meetings

Record a meeting, and Wrengle saves the transcript and the report together in one note. The visible workflow stays simple: Transcript → Final notes.

When the transcript and live report draft are visible together, drag their divider to change how much space each gets. The report and transcript also have a resizable divider while the final note is being created. You can focus these dividers with Tab and resize with the arrow keys. Each layout remembers your chosen sizes on this device, and both reading areas scroll independently.

Record a meeting

The meeting view gives you Record, a Recording for... context picker, and More meeting actions for diagnostics and other secondary controls. Depending on what your platform supports, you can record Mic + System, Mic only, or System only — Mic + System is the default wherever it is supported.

Only one meeting lifecycle is admitted at a time. Pressing Stop seals that meeting's encrypted local audio timeline and releases the physical devices, but the same lifecycle keeps the process-wide meeting slot through final transcription, note save, and any automatic report. Record and voice capture wait until that work settles, so long-running model and provider work cannot stack across meetings.

Recording is blocked when capture or saving would be unsafe: no vault open, no suitable local Whisper model available, another meeting still recording or finishing, unresolved meeting recovery, or the selected source missing a startup-approved platform permission. The context picker never blocks an ad-hoc recording; you can pick a timed calendar event or No calendar event, and Wrengle snapshots whichever you chose the moment recording starts.

When Google Calendar is disconnected, the picker offers Connect Google Calendar; an expired or changed grant offers Reconnect Google Calendar. Connection uses the system browser, then immediately refreshes the primary calendar's seven-day window. Disconnect removes only Wrengle's local Calendar tokens and cached Google rows, reloads any independent ICS events, and returns the picker to No event.

When you select a Google event, its event ID, source, title, and times are copied into the frontmatter of the meeting note you own. Those fields remain there until you edit or delete the note, even after the seven-day Calendar cache expires.

Meeting capture can need microphone access and, where your platform supports it, system-audio access. On macOS 14.2 or later, open Settings → Privacy & Data → Desktop access and choose Enable and test before using System only or Mic + System. Wrengle explains that the test plays a short, quiet tone, opens the audio-only prompt when macOS requires it, confirms the tone was captured, and discards those buffers before any meeting starts.

A successful result is remembered for the same backend and app identity, so recording itself never plays the test tone. If you later change access in System Settings or change output device, use Test again. macOS does not provide a reliable read-only permission status: if the test cannot hear its tone, Wrengle reports Needs attention because permission and output-device problems can look the same.

macOS 13.4–14.1 uses the broader upper Screen & System Audio Recording permission. On macOS 14.2 or later, Use legacy screen-capture permission selects that path only when you ask; Wrengle never switches to it automatically. A new legacy grant can require Restart Wrengle. Wrengle never silently changes Mic + System to another source. Record never opens an operating-system permission prompt. For an old stale legacy grant, follow the one-time stale Screen Capture recovery.

On the current unpackaged Windows build, capture permission always shows as Not required. That build cannot yet reliably request or report per-app capture consent, so startup does not probe a device or check the global desktop-app microphone switch. If that switch is off, or the selected device cannot actually capture, Record fails prompt-free with a source-specific device-open error instead of a permission prompt. The Privacy settings page always offers a Windows microphone Settings link so you can fix it.

Configured transcription, report-provider, account, Calendar, action, plugin, and workflow credentials are also preloaded during startup and held in memory for the session. Startup does not begin capture, sync Calendar, refresh OAuth, contact a provider, or prepare a report. If a required item is unavailable, the meeting view reports that capability as limited instead of quietly retrying the Keychain read while you are recording.

The transcript

Live captions always run locally, on your device, during the recording. When you choose Stop, Wrengle finishes the final transcript and saves it to a stable meeting-note target. Once speech is confirmed, Wrengle can create that same target early with the best available draft transcript so recovery and report preparation have a stable destination. Stop replaces its managed transcript region with the final transcript; Wrengle does not create a second notes-stage document.

If the final note save fails, the meeting inbox offers Retry save while the finalized transcript is still available in the app. If that in-memory retry is no longer available, the inbox directs you to Recovery instead. Wrengle blocks another recording until the failed save or its Recovery item is resolved.

If an audio source disappears, the encrypted spool cannot keep up, or disk headroom reaches its safety reserve after speech has already been captured, Wrengle stops recording and finalizes the valid prefix. The saved card is explicitly labeled Meeting note saved — recording ended early, and the managed transcript region in the note begins with a durable incomplete-capture warning. Neither the card nor a note reopened after restart presents that prefix as a complete meeting. Check the selected source and available disk space before recording again.

Live captions always use the local Whisper model. Wrengle downloads local model files into the operating-system app-data directory rather than bundling them with the app, and it can run on a smaller installed model while a larger selected model finishes downloading in the background.

For the local final pass, Wrengle processes long recordings in fixed-size chunks. With Prepare final transcript while recording on — the default for eligible local transcription — it can finish those chunks during capture itself whenever your device has the decode capacity to keep up, leaving only the tail for Stop to finish. This keeps running even when report preparation is After Stop or report generation is Manual; it is independent of both, and it never sends audio off your device. Turn it off to run the whole local final pass after Stop instead.

During capture, completed audio is written as independently authenticated, encrypted five-second blocks in Wrengle's private operating-system app-data directory. Their authentication binds them to the exact vault and recovery directory that created them, so a copied recovery row cannot open or delete another vault's timeline. Only a short rolling window remains in memory. The audio does not live in your vault or its Git history. Wrengle removes it after a canonical final pass succeeds; if finalization needs attention, it retains the encrypted timeline so recovery can continue without the original meeting-sized memory buffer.

The encrypted timeline also binds the local or cloud finalization route chosen when capture starts. Before the first cloud request, Wrengle durably binds that provider, model, and key generation in private app data. Editing or rolling back synced recovery files cannot turn local capture into a cloud upload or redirect an explicit retry to another provider, model, or key generation.

Turning on cloud transcription only affects the final pass, after you press Stop. Live captions stay local no matter what. If the cloud final pass is selected, Wrengle plans contiguous, silence-aligned requests of no more than eight minutes and sends them one at a time to that same provider and model. Each chunk gets one provider attempt. A failed response or a network outcome where the provider may already have received the audio stops at Needs attention; Wrengle preserves the local draft and does not automatically resend, combine cloud output with a local final pass, or switch providers. Choosing Recover is the explicit action that can authorize a retry still bound to the original provider, model, and credential generation. ElevenLabs is not a meeting final-pass provider in this release. Meeting transcription is a separate system from in-app dictation, with its own settings and its own consent.

Wrengle does not publish a guaranteed maximum meeting duration yet. The storage, paging, and chunking paths are designed to avoid memory growth with duration, but long-session qualification is currently an internal macOS test target rather than a public eight-hour support promise. Available disk space, model speed, sleep, provider limits, and interruption recovery still affect how long background finalization takes. One finalization run has a wall-clock budget of three times the recorded duration, with a 30-minute minimum and 24-hour maximum; unfinished jobs stay recoverable instead of holding the meeting lifecycle indefinitely.

The report

When the transcript is ready, Wrengle builds a report with six fields:

• Summary — a concise recap.
• Decisions — decisions reached in the meeting.
• Action items — owner-tagged follow-up tasks.
• Follow-up — a ready-to-send message.
• Discussion — the main topics in order.
• Open questions — unresolved items.

An empty field still appears and shows None. The report is written into one managed region that renders as normal editable blocks in your note. Meeting report generation decides when: Automatic creates one final report as soon as the transcript is saved, and Manual waits for you to press Generate report. For a saved meeting whose report is idle, Generate report stays available in either mode. This is your recovery path if automatic scheduling was cancelled, the resolved route changed, or the generation setting itself could not be saved — Wrengle shows the setting error instead of claiming the report is still scheduled.

Watching the report take shape

While you are recording, a read-only Live draft can pull out likely decisions, actions, and questions from captions as they are committed — no AI provider involved. It is independent of report mode and report preparation: a conservative view over committed captions, not a saved note and not an AI conclusion. A later refinement recomputes that same caption's contribution so corrected wording never leaves stale facts behind. If report preparation is eligible, Wrengle can replace this with a Live AI draft once a provider update has been validated. After Stop, the current preview stays visible, labeled Final report draft. A UI reload can reattach while the active desktop process keeps the meeting session open.

All three are bounded, copyable, memory-only previews that are never written to the note, a recovery file, another disk file, logs, or telemetry. They can change right up until they are cleared — which happens the moment the meeting reaches a final outcome, or the app restarts. Separately, once the transcript is finalized, Wrengle can hold its finished text in memory for up to 30 seconds so a reload that lands right after finishing still shows the final version. If that reload is already paging its bounded immutable copy, each page renews a 30-second idle lease, but never beyond ten minutes from attachment. That copy is tied to the exact vault-open session and clears on release, vault switch, idle or hard expiry, or restart.

For an automatic meeting, Ready means the managed report region and its recovery metadata are safely saved — Wrengle does not hold that status behind a best-effort whole-vault backup snapshot, which runs afterward on its own schedule. Manual saved-note operations keep their existing scoped commit ordering, unchanged by this.

If the report provider fails, times out, or returns something invalid or oversized, the saved transcript stays usable and Wrengle shows a retry instead. If you edited the report region after it was generated, Wrengle keeps your edit and shows Review final report rather than overwriting it. Editing the transcript itself never blocks an otherwise-valid report from becoming ready.

For the saved-transcript path, a transcript of 32,000 characters or less uses one OpenAI or Anthropic call. That call can request up to 16,384 completion tokens, has a 32,000-character response cap, and can run for up to 60 seconds. A longer transcript can make multiple sequential calls in one Generate report or Try report again action: one call for each contiguous transcript shard, followed by hierarchical reduction calls. Every long-path shard or reduction call is capped at 3,000 output tokens, 12,000 response characters, and 60 seconds. Bounded user-note and title/prompt context can accompany each call. Total runtime, transmitted context, provider logging or retention exposure, usage, and billing therefore grow with the number of shard and reduction calls; 60 seconds is not an action-wide deadline. The saved-path budgets do not apply to during-recording preparation or its Stop-tail drain. An explicit retry authorizes another report attempt that may make another sequence of calls. Wrengle never automatically replays an ambiguous or failed provider call.

Key rejection, rate limiting, an unavailable model, an incomplete response, and an invalid response now produce separate guidance. Provider response bodies and internal error details are discarded rather than written to the note, recovery data, logs, or telemetry. If the normal 30-second final display and any already active bounded reconnect lease have expired, the meeting panel says the transcript is saved in the meeting note and keeps Open note available; this is not transcript loss.

Preparing a report while you record

Report preparation controls whether Wrengle does any of this work before Stop. After Stop is the clean-install default and holds off entirely until recording ends. Auto is an opt-in path: with it on, and with Meeting report generation set to Automatic, Wrengle can keep an in-memory six-field report updated from completed, final-quality transcript chunks while you are still recording. Turning report preparation off does not touch the independent local transcript cache described above — it only stops report-provider work during capture. Both settings fail closed if their stored values cannot be read.

Manual mode only changes when report generation happens, not what a cloud route can receive once you do generate a report. Switching to Manual delays the request; it does not change the data boundary described below.

The updater works through one transcript chunk at a time, always moving to the newest one, and it caps how much source text, prompt text, response text, and report content — including its lists and individual fields — it keeps in memory. This also needs a saved note target, local chunked final transcription with enough decode capacity to keep up, and an eligible OpenAI or Anthropic report route with a readable saved key. Retained local report routes never run. An eligible cloud route can receive several transcript-text requests while you are still recording, so provider usage, billing, logging, and retention can apply even if Wrengle later discards the result.

This prepared state is advisory, not a live-notes document. It is never saved to recovery storage, and Wrengle never accepts the state, the source frontier, the revision, the schema, or the route binding from model output directly — it stays tied to the exact provider, model, route, and destination it was prepared against. At Stop, a separate tail task gets one bounded opportunity to cover whatever is left of the transcript, running independently so a slow preparation request never delays saving the transcript itself. Stop closes the normal preparation cycle, though a request already under way before Stop may still finish. If coverage is still incomplete, the provider was already warmed up, and the remaining gap is small enough to fit in one update, the worker may start one more full six-field pass to close it — and no more than one.

Report generation waits for that tail decision, and only uses the prepared state when the coverage, revision, schema, route, and note bindings all still match. If no tail attempt happened, or the remaining piece was invalid or too large, Wrengle falls back to the saved transcript context instead. Once a tail attempt starts, Wrengle never sends a second automatic request; if the exposure stays unresolved or the note context changes afterward, it needs manual review and a manual retry.

Before each cloud preparation request, Wrengle durably records a content-free provider-exposure claim under .app/live/, bound to the exact route and destination, and records completion once the request settles — the claim itself is never prepared report content. If an interruption leaves a request's completion unproven, Wrengle does not start another automatic provider request; the meeting shows Manual retry required so you can choose whether to retry with the currently resolved route.

Auto preparation can shorten the wait between Stop and a finished report, but it cannot guarantee a particular latency or fuller coverage on every device or route. Choosing After Stop avoids report-provider work during capture entirely.

Inputs at or below 32,000 transcript characters are sent in full. Longer transcripts are split into contiguous shards that cover every source character. Wrengle extracts evidence from each shard, checkpoints completed evidence for recovery, and reduces the narrative hierarchically. Decisions, action items, and open questions are combined deterministically from every shard rather than resampled from five windows. User-owned note context remains independently bounded to 8,000 characters, uses a condensed five-window representation above that cap, and is labelled Condensed when the note cap applies.

Choosing a report model

Reports use the direct OpenAI or Anthropic provider, or the Wrengle AI tier, selected under Settings → Models. The route is explicit: connecting another key does not change it. With no usable selected route, report generation waits for provider setup, managed sign-in, or sufficient credit as applicable.

Selecting a cloud model is your consent to send that meeting's report content to the provider. Before report input is dispatched, Settings → Meetings → Reports → Cloud meeting report access discloses the exact resolved provider, effective model, and destination for that cloud report route. Selecting a cloud model is your consent to send the complete meeting transcript in bounded contiguous shards, bounded user-owned meeting-note text, and meeting title/prompt context directly to OpenAI or Anthropic, or through Wrengle to OpenAI on a selected managed tier. Report requests send text, not meeting audio; do not generate a report if that text must stay on your device. Changing the provider, model, or destination cancels an in-flight request bound to the old route — that work is cancelled or discarded rather than replayed. A request that may have already reached a provider is not automatically replayed on either the old route or the new one; it needs an explicit manual retry instead. The disclosure itself is read-only; there is no separate authorize or revoke step.

A request already received by a provider cannot be pulled back. The provider's own billing, logging, and retention terms can still apply after you cancel locally. Choosing a cloud report route never uploads meeting audio — cloud final-pass transcription is a separate, separately consented audio boundary with its own provider key.

OpenAI and Anthropic models use the native six-field structured-output contract with capped response validation. Wrengle sends no app-defined OpenAI prompt_cache_key or Anthropic cache_control directive for meeting reports, though a provider's own default caching, logging, and retention may still apply.

Provider preparation cannot hold the meeting slot indefinitely. Changing the route or model, turning off Automatic generation, losing recovery ownership, or reaching the preparation deadline cancels that attempt and releases the slot. Setup already running inside platform code that cannot be interrupted can keep finishing on its own after that — but its result is discarded and cannot repopulate report state. Keychain credential reads share one lane with a 30-second caller deadline, though the report-specific deadline can end an attempt sooner. Provider preparation is capped at 20 seconds.

File safety for meeting notes

Ordinary Markdown, chart projection, and editor-sidecar reads have a 16 MiB per-file cap, and app-owned meeting-note writes use that same cap — a larger note fails closed before Wrengle attempts a report, a save, or recovery processing. Ordinary document and editor-sidecar operations, plus privacy-sensitive recovery inputs, reject hardlinked files, unsafe symlink/reparse paths, and parent or target identity swaps. This single-link/no-follow rule is scoped to those app-managed document, sidecar, and recovery paths; it does not describe every file you might keep in a vault.

Recovery

During capture, finalization, save, and report generation, Wrengle writes a strict, versioned recovery record under .app/live/ in the open vault. Current sessions page committed, refined, and final transcript rows into bounded 256-record files and keep a strictly validated finalization ledger for the exact audio ranges. The record can also hold the exact note target and identity, the selected meeting context, provider-exposure state, and a contiguous report attempt revision. It never holds raw meeting audio. Partial captions and the complete rendered report preview remain memory-only. Long-report evidence checkpoints do persist, however, and can contain derived summary, decision, action-item, follow-up, discussion, and open-question content from transcript shards. Provider-exposure claims themselves remain content-free request-safety records.

Because .app/live/ sits inside the vault, any filesystem sync or backup you have configured can copy these temporary records to its service or another device while they exist — they are not guaranteed to stay on only the recording machine.

Each live session also carries a content-free owner lease — just a random identifier and timestamps — which Wrengle refreshes every 15 seconds while capture, finalization, save, or a detached automatic report is running. Its counter and file lock keep cooperating Wrengle processes in step, but only when they open the exact same lock-capable file in one clock domain.

On Unix, Recovery discovery can re-attest a released lease when a remount changed only the device identifier of the same lock file. Wrengle holds the current lock and advances the lease generation before touching any meeting artifacts. This repair does not rebind the saved note target. A fresh owner, a replaced lock file, or malformed or otherwise unreadable ownership metadata still stays hidden and fails closed.

Closing normally makes a non-blocking attempt to release the lease right away, which completes promptly on a responsive filesystem. If another process is holding the lock, or the filesystem stalls, cleanup continues anyway instead of hanging the app, and the record becomes recoverable once that filesystem's clock shows the last heartbeat as at least two minutes old. An ordinary synced copy of that record is a separate, possibly stale object, not a distributed lock, and a replica with a different or skewed clock sits outside this protection — so do not open or recover the same temporary meeting item concurrently on multiple synced devices.

Recovery first authenticates the sealed audio timeline and validates the exact-range finalization ledger. Local jobs interrupted before publication become retryable; completed jobs are reused without decoding their ranges again. A cloud request interrupted after dispatch becomes ambiguous and is never resent by a background scan. The explicit Recover action can authorize that retry only while its original provider, model, and credential generation still match. Once every exact range is ready, Recovery publishes the paged canonical final transcript. Legacy text-only records use the latest completed transcript rows. An incomplete five-second audio block or transcript write in progress at the moment of an interruption can still be lost. A failed final note save keeps the canonical transcript available after the live window is gone. Wrengle never starts provider work just by scanning recovery files. If Stop had already recorded a pending automatic-report request, a successful save retry or recovery resumes that request — but only once it still matches the current mode, the resolved route's credential and destination bindings, the note identity, and the attempt revision. A visible retry always uses whichever route is currently resolved.

If the note was published but the filesystem could not confirm its durability, Wrengle treats that as storage maintenance rather than a retryable save failure. The meeting inbox shows Repair note and keeps the canonical final transcript until re-materialization succeeds. A confirmed, usable final note does not block another recording while that maintenance row remains; an unconfirmed target does.

If recovery finds a cloud request whose completion was never confirmed, automatic generation stays at Manual retry required rather than risk silently repeating a request the provider may already have received.

Recovery records are temporary, not an archive. Wrengle removes them after a successful save or report, after recovery, after a discard, or after no-speech cleanup. If cleanup itself fails, the meeting view keeps a visible cleanup action so you can clear it by hand. Back up the whole vault folder only if you intentionally need to preserve an unsaved recovery item.

Retained encrypted audio is not deleted because a fixed amount of wall-clock time passed. Unresolved timelines count against bounded local recovery capacity, so enough unfinished recovery items can block a new recording until you complete Recovery, cleanup, or discard for those items. When authorized audio deletion starts, Wrengle first authenticates the exact vault/recovery owner and writes a durable receipt bound to that owner and the audio session's directory identity. A restart resumes any matching secure-cleanup quarantine, and that pending quarantine continues to count against admission until deletion is proven complete.

Recovery reads, accumulated transcript text, and directory scans all have hard byte and entry limits. An oversized or malformed session is isolated as a discard-only row while other valid sessions keep scanning normally; a session whose owner lease is itself unreadable or oversized stays hidden and fails closed while its siblings keep scanning. The only automatic identity repair is the released, same-file Unix remount case described above. If the whole recovery root has too many entries, the scan fails safely until the excess app-managed entries are cleared.

Saved notes and review

Meeting notes are created under notes/meetings/. Calendar-linked notes use a safe slug built from the event title and recording timestamp; ad-hoc recordings use a meeting- prefix instead. The meeting view offers Open note once the transcript is saved, and report status stays visible as preparing, ready, retryable, manual retry required, or review required.

An edited or malformed report region is preserved for review rather than overwritten. Before preparing a new post-Stop provider, Wrengle checks that region locally. Check note and retry repeats that provider-free check after you repair the note; while the issue remains, it makes no provider request.

Final local transcripts label channels as You and Participants — that is channel attribution, not identification of individual speakers. A transcript saved from a cloud final pass has no speaker labels in this release.

Before saving, finalization keeps one copy of immediately adjacent segments whose cleaned text and channel are exactly the same. It preserves differently cased or punctuated text, cross-channel and nonadjacent repetition, and repeated phrases that occur inside one segment.

Wrengle does not save a raw recording archive. Transcription quality depends on audio quality, model choice, hardware, and platform support, so review important transcripts and reports before treating them as authoritative.