Commits preserve milestones.
Rewind preserves development.

Between two clean commits may be dozens of meaningful states: experiments, partial implementations, debugging attempts, refactors, generated changes, AI-assisted edits, mistakes, and working versions you later wish you had kept.

Rewind treats those intermediate states as useful history without forcing every checkpoint to pretend it is a finished unit of work.

“Make history follow the work instead of making the work follow the history.”

Two levels of history.
One small vocabulary.

Notes preserve the detailed trail. Finishes describe what was ultimately accomplished. You get readable project history without throwing away how you got there.

Built around history,
not around an inherited format.

Chronicle is Rewind's purpose-built storage direction. Durable history records are the source of truth; indexes and acceleration structures are rebuildable. Optimization can change without changing what the repository means.

The format direction uses a Rewind-owned binary wire representation rather than making JSON or a language-specific serializer authoritative. That leaves compatibility, validation, deterministic representation, migration, and future evolution under Rewind's control.

Don't just keep history.
Know where code came from.

rewind trace <file> follows provenance through current and historical line attribution, revision-level history, and rename-following. The goal is to answer not only what changed, but where a piece of code originated and how it survived.

rewind undo handles the immediate working state. rewind recover <id> handles recorded history. Current mistakes and historical recovery are deliberately different operations.

Checking history should
never rewrite history.

rewind check performs read-only reachable-history integrity verification. Full verification can additionally inspect unreachable loose objects, inactive packs, and garbage without treating valid unreachable data as corruption.

Integrity checking does not silently repair, migrate, prune, sync, or upgrade the repository. A verification command should be trustworthy precisely because it does not change the thing it is verifying.

Rewind remembers how.
Git can publish what mattered.

Rewind does not need to recreate every Git command to be useful. Its core question is narrower: what should version control look like when development history itself is the primary object?

Every command needs
a reason to exist.

Less ceremony.
More useful history.