Systems with a model inside — and the checks that keep it honest.

Writing a journal entry returns in 0 ms — the text hits disk first. Chunking, embedding, entity extraction and the graph commit all happen in the background, so a capture never depends on the model succeeding. If extraction fails the entry is still there and still re-ingestible. The same person mentioned twice resolves to one node; two mornings' runs stay two events.

Then you ask a question in plain language. Read the next screenshot carefully, because it is the whole thesis.

There is no step in that chain where you have to take the model's word for anything. What stops an ungrounded answer is not a line in the prompt — it is three properties of the code path:

Four crates sit behind a typed IPC boundary: the domain model with typed ids and secrets that wipe on drop, a provider gateway with local-first routing and OS-keychain storage, the encrypted store, and the engine. The project was migrated from Flutter to Tauri 2 against a written go/no-go gate — cleared only once the app built, installed and launched on Android with a working IPC boundary — and the Dart tree was then deleted rather than left to rot.

The interesting part is what happens after Tailor. The model is asked to select, reorder and rephrase the user's real bullets for a target job — never to invent experience — and every tailored bullet must cite the source_bullet_id it came from. The output is then verified against the master profile before it can be attached to an application:

A document that fails is still stored so it can be inspected and edited — but flagged factual_check_passed = false with notes naming the check that failed.

"experiences": [{ "company": "Northwind Logistics",
  "bullets": ["Reduced p99 dispatch latency from 1.8 s to 240 ms by swapping a
               synchronous fan-out for an async, queue-backed worker pool.", …] }],
"ats_keywords_covered": ["Python","FastAPI","PostgreSQL","Kafka","async","queue", …],
"factual_check_passed": true,
"factual_check_notes": "Verified against master profile: all bullets, skills and
                        numbers traceable.",
"metadata_scrubbed": true

Every number in that output traces back to a bullet the user actually wrote. The rephrasing is the model's; the facts are not.

Behind it: 82 Python modules, 20 service modules covering discovery across sources, matching, tailoring, PDF/DOCX rendering, an IMAP sync that parses recruiter replies, a scheduler and notifications — and 88 tests across 13 modules. When a key is unset the endpoint returns 503 and the interface says so in words, rather than failing silently.

Two front ends over one engine. The corpus parser, aligner and renderer are a plain Python package; a desktop app and a web app both sit on top, so the work that matters is written once.

The hard part is alignment. ASR output for chanted Sanskrit does not match the written corpus token for token: sandhi joins words, elision drops them, and chant-style vowel lengthening moves every boundary. A naive “display what Whisper heard” approach produces a screen full of subtly wrong verse. So the transcript supplies timing only, the corpus supplies the text, and fuzzy alignment joins the two. The screen always shows the correct verse, and the highlight still lands on the right word.

Frames stream to ffmpeg one at a time so memory stays flat however long the recitation runs. Devanagari typesetting is handled explicitly — the app manages its own Noto Serif Devanagari and lays out conjunct-heavy lines without clipping, which is where most naive text rendering falls over.

Step 2 is the interesting one. A weaker loop answers from the first thing that looks like a version number.

The response is a Pydantic model, so the schema is the contract: a required thought field first, then one of thirteen actions — click, type, scroll, navigate, hover, drag-and-drop, keypress, select, download, find-in-page, get-page-text, execute-code, done — each field documented for the model to read, including the warning that generated code must print its output or the agent will never see it.

The parts that stop bad trajectories: code runs in an isolated subprocess with a timeout, so a hanging snippet costs one step rather than the run; the screenshot is skipped on the turn after code execution because the page hasn't changed; and a consecutive-failure counter aborts after three unparseable responses instead of spinning against a rate limit.

Three modules exist because the naive scan is silently wrong, which is worse than incomplete — an audit that looks fine and is worthless is the worst possible failure mode for a document handed to a paying client.

The report also states its own limits in print: automated testing reliably detects roughly a third of WCAG success criteria, cannot judge whether alt text is accurate, and is not a certification.

notes + screenshots
   └─► INTAKE  (claude-haiku-4-5)  → title, client guess, ≤4 gap-filling questions
        └─► answers
             └─► CASE STUDY (claude-opus-5) → structured study → D1 + R2 → public page

Two models, chosen per job, each labelled in one line:

/** Model for the cheap, high-volume intake pass. */
export const INTAKE_MODEL = "claude-haiku-4-5";

/** Model for the thing the freelancer puts their name on. Do not downgrade. */
export const CASE_STUDY_MODEL = "claude-opus-5";

The intake prompt is the product. It encodes a theory rather than a persona —

“Freelancers write down what they built; prospects want to know what changed.”

— and then constrains the ways the model would go wrong. Ask at most four questions, because every extra one is a chance for the freelancer to abandon the form. Never ask about something already answered in the notes or in an attached screenshot: “if a chart shows the completion rate going 41.2% to 63.8%, the completion rate is answered, and asking for it anyway tells the freelancer you did not look at what they gave you.” Ask for specifics, not essays. Give every question a one-line “why” so the field doesn't get a shrug. And, the rule most prompts are missing — if the notes are genuinely complete, return an empty list; do not invent questions to fill space.

Caching is treated as an economic decision. Every prompt is a frozen constant, because caching is a prefix match and one byte of drift before the breakpoint invalidates the entry — “the difference between ~87% and ~40% gross margin, and expensive to retrofit.” Cache minimums are documented as non-monotonic across model generations (512 tokens for Opus, 4,096 for Haiku) and then deliberately not gamed: padding the intake prompt purely to earn a cache hit would cost more than it saves. Images go before text in the user turn, both because that is the documented ordering and because it keeps the varying text where caching wants it. Token usage is logged per generation, so margin per study stays visible instead of arriving on a bill.

Failure is typed. A ConfigError — bad key, dead model id — is loud in the log and never invites a retry; a GenerationError is written for the user to read. Without that split, “a 401 reads as ‘try again in a moment’, which is how you end up retrying a misconfigured API key forever.”

That behaviour is not theoretical: it fired while this page was being written. The Anthropic account is out of credit, so a live generation returned a 400 — and the Worker classified it as a deployment fault, logged CONFIG ERROR — needs a fix, not a retry, and declined to suggest trying again. That is why there is no generated-page screenshot here; the error path did exactly what it was built to do.

Note what that output also shows: the 2FA code was not caught. The denylist and pattern set are a starting point, not a finished secret detector, and the project's own notes say so. Naming what a control does not yet cover is the difference between a security story and a security claim.

forget is the other half — it VACUUMs after deleting, because rows removed from SQLite stay on disk and forensically recoverable otherwise. That detail is what separates a real erase button from a checkbox.

Behind the CLI is a design document that takes the original specification and states where it is wrong:

The query planner is rule-based on purpose. The schema was designed first, so swapping the heuristic parser for a small local model later is a drop-in replacement for one function body — callers only ever see a query plan, never how it was produced. Its known limitations are listed in the file rather than discovered afterwards. The ask command already goes further: retrieve evidence, then synthesize a cited answer through a local model on Ollama, with a deterministic fallback when Ollama isn't reachable.