The database is a projection of a Markdown file

In most systems the database is the truth, and any file, a config, an export, a README, is a second-class copy that drifts the moment someone edits a row. My command center runs the other way around.

The truth is a markdown file in git. The database is a projection of that file: something I can drop entirely and rebuild from the text, with nothing of value lost.

The database is a view I can throw away and rebuild. The source of truth is a text file I can read, diff, and review.

The system that plans and ships my projects has a plain rule: the plan lives in a git-tracked markdown file, and the database row is generated from it. If the two disagree, the file wins, and the row gets rebuilt.

A dashboard is where you look at state. It is a bad place to own state, because its history is thin and its edits are invisible. Git is the opposite.

The payoff is not aesthetic. It is that all the machinery I already trust for code now applies to my intentions. A plan change is a diff. It gets a commit message, a history, and a review before it lands.

Changing what the system will do is a pull request, not a quiet edit to a row at midnight that no one can reconstruct later.

This pattern is not free. It works only if you hold two lines, and the whole thing collapses the moment you break either.

• Never hand-edit the projection as a shortcut. A row changed outside the file is a lie the next rebuild will erase, or worse, will not.
• Exercise the rebuild. Drop the projection and regenerate it from the text often enough that you know it still works, not just in theory.

A projection you never rebuild is just a second source of truth wearing a disguise.

1. Pick one kind of state you edit in a dashboard and move its source into a git-tracked file.
2. Generate the database rows from the file, and make the file win on any conflict.
3. Review changes to that state as diffs, with commit messages and history.
4. Drop and rebuild the projection on a cadence, so the rebuild stays real.