Running always-on · in daily use
Mobile capture — phone to workspace, intact
A thought sent from my phone lands once, unmodified, in the workspace inbox — and the system asks me about it at the start of the next session so I never have to remember it exists.
- 1
- file per message — idempotent by update id
- 3
- capture kinds: text · photo · document
- 23
- tests, CI-gated
Most capture systems fail at the same point: the moment of capture asks too much. Choose a folder, add a tag, decide what the thought is. By the time you've done that on a phone, the thought has either degraded or been abandoned. This service's design position is that capture and interpretation are different jobs that happen at different times — so the capture step does almost nothing, on purpose.
How it works
I send a message to a private Telegram bot — text, a photo, a PDF. Within a couple of seconds a watcher process on my machine writes it into the workspace inbox as a plain markdown file and replies with a capture id. That's the whole transaction. The file carries machine metadata (when, from where, what kind); classifying it — is this an idea, a task, a document to file — happens later, at the desk, through the same routing step that handles everything else entering the workspace. The original text is never rewritten.
Telegram is transport, nothing more. The durable system is the inbox folder and the routing discipline behind it; the messaging app could be swapped without rebuilding anything.
The reliability work is the actual work
The happy path took an afternoon. What makes the service trustworthy took longer:
- Exactly-once capture. Every write is keyed to Telegram's message sequence number, so a crash and restart can't duplicate a capture, and a missed poll can't lose one — the sequence picks up where it stopped. Offline periods catch up on wake.
- A poisoned message can't jam the queue. A message that repeatedly fails to process is quarantined and skipped, loudly, instead of blocking everything behind it.
- Failure has to be visible. The hardest bug found in live use was a process that looked healthy to the supervisor while its polling loop had silently died — capturing nothing. The fix was to make the process exit hard when the loop stops, so the system restarts it automatically. A service that can fail quietly will, eventually.
What it deliberately doesn't do
No AI touches the message on the way in — no summarising, no auto-filing, no interpretation. Anything consequential waits for a human at the desk. And the service log records ids and kinds only, never contents: the capture channel carries personal material, and observability was designed to work without exposing any of it.