notes #

working notes, kept as they're learned. published at notes.zzstoatzz.io and as standard.site records on the atproto network.

provenance #

most of these notes aren't handwritten — they're distilled by an agent from working sessions with the author, kept as a living corpus and meant to get more accurate over time. some are handwritten; the voice is shared. either way there will be mistakes nobody has noticed yet — treat a note as a useful distillation, not a final word.

organization #

• ai/ — the AI domain: retrieval, memory, local models
• systems/ — design patterns above any specific tool: queues, delivery semantics, cursors, batch/serving splits
• operations/ — running and shipping software: observability, diagnosis, configuration, sizing (plus home-infra/, the home-box cluster)
• web/ — the browser as a platform: graphics (canvas, webgl, engine exports), media, mobile, network and cache behaviour
• storage/ — concrete storage systems (redis, sqlite, turso, turbopuffer)
• data-structures/ — implementation tradeoffs in structures such as bloom filters
• languages/ — language idioms (python, typescript, zig)
• protocols/ — atproto, MCP
• music/ — music production tooling (ableton: LOM, .als, automation)
• sources/ — raw transcripts and captures (not notes; see its README)

conventions #

• a note is distilled, not recounted — it holds knowledge that was hard to get and holds outside the project that produced it. a project's decisions, status, incidents, and changelog live in that project's docs. most work produces no note; when a session teaches something, rewrite the claim it changes rather than appending a dated paragraph.
• titles name the subject — "bounded scans" beats "a bound is only as cheap as its check". a note is found by the thing it is about, and a title that argues gets stale faster than one that names.
• the idea leads, the incident does not — write the transferable claim in present tense and standard technical English. a specific system, date, or outage appears in the body only where it makes the mechanism concrete, and the narrative itself belongs in the sources footer or in the source repo's own retro.
• every note ends in ## sources — repository, document path, date. that footer is what makes a claim checkable later without carrying the story in the body. nothing follows it.
• one topic, one home — when a topic touches two sections, it gets a designated home and the other side links to it. links over copies.
• no singleton sections — a new top-level directory needs several notes to earn its existence; until then, file under the nearest section and link.
• idioms don't live under versions — version-keyed migration notes go in a versions/ subdir (see languages/ziglang/versions/); everything else is a topic note annotated with the release it was learned on.
• sources are not notes — raw material lands in sources/ verbatim; the note it produces lives in the taxonomy and links back.