Repository navigation
Releases
v0.9.1
v0.9.0
v0.8.1
v0.8.0
v0.7.0
v0.6.0
v0.5.1
v0.5.0
v0.4.1
v0.4.0
Minor over v0.3.1. One new write op, nothing removed, no migration.
Added
amend rewords a recorded decision without superseding it (#10, #11).
precedent amend --id <id> [--title ...] [--statement ...] [--rationale ...]
A decision could already be superseded — the decision changed — or regretted — the choice was wrong everywhere it was made. Neither fits a decision that was simply described badly, and that gap was expensive: check prints the title first, so the title is the text quoted back as the user's own reasoning. A decision titled more narrowly than it is reads as not-applicable, gets re-litigated, and is answered a second time. Duplicate decisions are the thing the graph exists to prevent.
Both available workarounds were wrong for it. record --supersedes writes a second decision and makes check carry both, asserting a change of mind that never happened. Hand-editing journal.jsonl works, but breaks the append-only property this tool states as a design invariant, with no validation and no record that an amendment occurred.
amend appends an {"op":"amend","id":...} journal line carrying only the fields being reworded, which rebuild folds onto the existing record. Append-only survives, because the amendment is itself an appended fact, and check shows one current entry rather than a supersede chain.
What it will and will not change
title, statement and rationale — how the decision was described. Topics, options, scope and the project are what was decided; changing one of those is a different decision, which is still record --supersedes. Conflating the two is what made the old workaround unattractive, so the line is drawn in code rather than in prose. An absent field means unchanged, never cleared: amend --title cannot blank a rationale.
The decision id does not change, including the now-stale title slug embedded in it. The id is identity; the slug within it is an accident of how it was minted — the same split this project already made between Project.portable and Project.id in docs/adr/0002. Everything already holding an id keeps resolving: a SUPERSEDES edge, a Principle's DERIVED_FROM, a rule file, a commit message. See docs/adr/0008 for the alternatives considered and why each was rejected.
Upgrading
Straight replacement. The store format, the ten skills, the hook and the statusline script are identical to 0.3.1 — no migration, nothing to re-record.
The journal schema stays at v1 on purpose. An amend line read by a 0.3.x install is reported as one skipped unknown op while the rest of the journal replays; bumping the schema would instead have made that install refuse every line written after the bump, plain record lines included. A store written by 0.4.0 therefore stays readable by 0.3.x, minus the amendments themselves.