#[non_exhaustive]pub struct MultiRow {
pub id: String,
pub level: String,
pub outcomes: Vec<Option<Outcome>>,
}Expand description
One clause’s row across every judged revision.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.id: StringThe requirement ID (AREA-NNN).
level: StringThe requirement’s RFC 2119 level, as registry text ("MUST", …).
outcomes: Vec<Option<Outcome>>Outcome under each judged revision, aligned by index with
MultiReport::revisions. None means the clause does not exist at that
revision — absent, not Outcome::NotApplicable.
Implementations§
Source§impl MultiRow
impl MultiRow
Sourcepub fn differs(&self) -> bool
pub fn differs(&self) -> bool
Whether this clause’s presence-or-outcome is not uniform across the judged revisions.
How much this discriminates depends on the registries judged, and against
the two this build ships it discriminates nothing: the registries are
extracted per revision rather than sharing entries, so a clause restated
with narrower text at the later revision gets its own ID — the reason
2025-11-25’s BASE-003 (no reuse within a session) and 2026-07-28’s
BASE-045 (no reuse while in flight) are two clauses and not one. The ID
spaces are therefore disjoint, every row is absent on one side, and
differs is true for all of them. Read the pattern instead: pass then
absent is a clause the migration removes, absent then pass one it
adds. A row that differs in outcome while present at both revisions —
the one a review would want first — cannot occur here, and would only
arise for a revision pair that does share clauses.