How this works

A build log and working field guide for one 2015 Tacoma in Juneau. 14 projects, planned through abandoned.

No figure appears unless it was measured or sourced

Every number that rolls up carries a confidence level. One that is not known yet reads as unverified, says what would close it, and is never counted in a total. Any unknown in scope makes a total a floor.

This matters most on payload. A budget that treats three unknown projects as weighing nothing reads as reassurance while being wrong.

Content is not presentation

Everything here is rendered from YAML at the root of the repository. A project is a directory with a project.yaml and up to five optional files. Adding one touches no code, and editing a step from a phone through GitHub’s web editor is a supported way to work. Model in docs/content-model.md, procedure in docs/adding-a-project.md.

Routes and recurring work

A project can fork on a decision: the power system is built in the cab or the bed, and that changes two of its twelve phases. Progress is keyed by step id, so switching routes never destroys a tick.

Maintenance has intervals rather than a sequence. Step completion is a list of dated records everywhere, so a checkbox and a service interval are the same shape.

Nothing leaves your browser

No backend, no account, no analytics, which is why it works with no signal. All of it exports as one file from your data, and log entries copy out as YAML ready to commit.

What it is not

Not a substitute for the manual that came with your own hardware. Where a project was extracted from a source, what that source got wrong is written down rather than resolved silently.