developer
one trail per project. write the bug out until you see it. pin the fix, the command, the reason.
one trail per project
a debugging session
the keys look the same in the logs. they are not: the build hash is in the key, and every deploy changes it. so every deploy is a cold cache. same shape as → tilecache:the march outage.
key = f"tiles:{z}:{x}:{y}:{style_version}"
# not build_hash: it changes on every deploy the page is for the part before the fix: the wrong theories, the log line you misread, the moment it turns. none of that belongs in the git log. it belongs somewhere you can think, and then let go.
what the project keeps
the way back
the build command and the open bugs are marked ↻. choose tilecache for a new page and both are already on it, so a session starts with the list instead of a search for it. only pins kept on tilecache itself come back this way, once, when the page first joins the trail.
the error message you wrote down in march and never pinned is in memory. search finds it, with the page you were on when you saw it.
from the keyboard
/ brings a block to the cursor: a code block, a table, a recipe, a decision, a chart. @ reaches a page on any trail, a trail, or a pin kept on this trail, a trail above it, or no trail at all. mod+k opens the trail index and the command palette. mod+p pins from the cursor, mod+f finds in the page, alt+↑ and alt+↓ move a block, and mod+shift+c copies a block as markdown, ready for an issue or a pull request.
local-first
the writing is a database on your device, so it opens and saves without a connection. on linux it installs from flathub (x86_64 and arm64), and the source is on github. sync is optional and end-to-end encrypted: the relay holds what it cannot read, and neither can we. you can run the relay yourself. every page exports as a markdown file into a folder you choose.