pub struct Amendment {
pub previous_verdict: String,
pub new_verdict: String,
pub new_note: String,
pub reason: String,
}Expand description
One recorded correction to an Entry’s verdict — the audit’s amendment
mechanism (see the module’s own doc comment for why this exists: a
reviewer error, once identified, must be fixable without either silently
rewriting history or leaving a known-false record standing).
Appended, never mutated once written, and the Entry this lives on
never has Entry::verdict/Entry::note overwritten by amend
either — an amendment is additive by construction, so git blame and a
plain read of the TOML both show the original verdict sitting right there
next to the record of what it became and why, rather than requiring
reconstruction from a diff.
Fields§
§previous_verdict: StringThe verdict this amendment supersedes: the entry’s original
Entry::verdict for a first amendment, or the previous
amendment’s new_verdict for a second — recorded explicitly (not
left to be inferred by walking the list) so each amendment reads as
a complete, self-contained “was X, became Y, because Z” statement on
its own.
new_verdict: StringThe corrected verdict, in effect from this amendment forward.
new_note: StringThe note attached to new_verdict, required under the same rule
verdict_requires_note applies to an ordinary verdict — an
amendment to wrong/incomplete with nothing recorded about what
is actually wrong is exactly as useless as a bare initial verdict
would be. Stored separately from Entry::note so the original
note (which may itself be empty, e.g. a correct being amended
away) survives untouched as history.
reason: StringWhy the original verdict was wrong and is being corrected. Always
required, regardless of what the new verdict is — an amendment with
no stated reason is exactly the kind of unauditable rewrite this
mechanism exists to prevent, the same precedent
Entry::include_reason already sets for force-inclusion.