Voice Memo Inbox: capture first, review later

Recording a thought is easy. Remembering where it went—and doing something useful with it later—is the part that needs a system.

A voice memo should not require a filing decision before it exists. This workflow gives the recording one intake point, turns the audio into readable text, and puts that text somewhere it can be reviewed. Capture happens first. The decision about what the thought means comes later.

The job it needed to do

The aim was an iPhone-to-Mac capture route: save a recording to a specific iCloud Drive folder, let the Mac process new audio, and preserve a usable transcript. Completed audio should leave the intake queue so the same ordinary scan does not keep finding it.

That is a narrower job than managing every idea. A transcript can contain a reminder, a rough article thought, a reflection, or nothing that needs further action. Getting the words into an inbox does not decide which of those it is.

The flow

What the implementation actually does

The script scans the intake folder for supported audio files. It checks for nonempty files whose modification time is old enough to pass a configurable waiting period. That reduces the chance of starting on a file that is still arriving, although a waiting period is only a heuristic—not proof that cloud transfer has finished.

An eligible recording is copied into a local working folder and passed to the chosen transcription engine. The current script supports Parakeet and Whisper. It expects a transcript file, then creates a Markdown record with source information, processing details, an overview, and the full transcript. A separate note is also written into LifeOS.

The overview is an excerpt assembled from the beginning of the transcript. It is not an independent interpretation of the memo. That distinction keeps a convenient preview from being mistaken for a conclusion.

Two ways to keep the queue understandable

First, the script records processed items. Its fingerprint uses the file’s path, size, and modification time. That helps it recognize an unchanged file it has already handled; it is not a content-based duplicate detector. Renaming, moving, or modifying a recording can make it appear new.

Second, successfully processed audio moves into an archive. If a destination name already exists, the script chooses a new name instead of overwriting it. Items with transcription errors stay out of the successful archive path so they remain available for investigation.

Neither mechanism makes the entire workflow an exactly-once transaction. A crash, a partial write, or a later notification failure can leave work to reconcile. The state record and saved artifacts make that investigation more concrete, but they still need an operator.

A transcript is not automatically a task

Ordinary memos are treated as captured material. The implementation also has an explicit command mode and optional messaging behavior. Those are separate capabilities, not a reason to treat every sentence in a recording as an instruction.

The useful boundary is that a spoken thought can wait for review. A task or decision needs an intentional handoff into the operational system. LifeOS holds the reference material; OpenClaw holds current operational state. This capture route should make that handoff easier to inspect, not silently merge the two jobs.

What this changes—and what it does not

The design replaces searching through a recording list with a readable note that can be found and reviewed. The original audio remains available for checking names, uncertain wording, or a passage the transcription misunderstood. There is no measured time-savings claim here: the benefit is a clearer intake and review path.

Transcription accuracy still depends on the recording. Background noise, unfamiliar names, and ambiguous speech need checking against the audio. iCloud delivery and the Mac’s availability are dependencies. Local transcription also does not make the whole route local-only: audio arrives through iCloud, and optional messaging can send text beyond the Mac.

Evidence and the next improvement

This note describes the implementation reviewed on October 31, 2026, alongside its original build record. The script confirms local transcription, Markdown output, processed-state tracking, and archiving. A new recording was not processed as part of preparing this page, so this is not a fresh end-to-end runtime test.

The next useful improvements are stronger transfer-completion checks, clearer recovery after partial failure, and a review view that distinguishes captured, reviewed, and intentionally handed-off notes. A separate audio catalogue would also be a further feature, not something this note claims is complete.