Ask why
The question that matters most is usually “why did it say that?”why walks the full chain behind one run’s output: which guideline versions were inlined, which brain passages were retrieved, and which tools were called. Use it when you have an output you are unhappy with.
Claim-level history
Every## heading in a guideline is a claim with its own id and version chain, addressed as <path>#<heading-slug> - so a rule that changed reads back on its own rather than as a diff of the whole file.
log prints when the section first appeared, and every version that changed it. Hand edits are picked up too: px0 notices them on the next command and records them, the same as any other change.
The store-wide change log
A change is one atomic write across the store - a workflow build, a guideline the build wrote, a hand edit px0 noticed, a migration.changes is that log, one entry per event rather than per file, newest first:
builder for workflow and guideline builds, update for schema migrations, and user:manual for hand edits it detects on its checkpoint scan.
This is the view you want for “what happened to my store last week?” A single change can span several files - a workflow build that also wrote a new guideline, for instance - and changes show prints the diff for each file it touched. changes revert undoes the whole thing as one unit, in one new change, which is exactly what you want when a build went sideways. The revert is itself recorded, so it can be undone in turn.
Schema migrations are forward-only and are not undone by changes revert. px0 update rollback reinstalls a previous px0 version and says so explicitly when the update it is rolling back had run migrations.
Which command do I want?
What is not versioned
brain/ and output/ are not versioned, on purpose. The brain is bulk reference material, rebuildable from its source URL; output is a product of a run, and the run record already says how it was made. Version history for either would be noise you have to scroll past to find the history that matters.