Enum EffectiveThreshold 

pub enum EffectiveThreshold {
    Inert,
    Approvals(u32),
    Unsatisfiable,
}

The approval bar a Quorum Mode QuorumThreshold imposes on one session.

Produced only by QuorumThreshold::effective, which is the single implementation of that rule. It lives in macp-core because two crates need it — QuorumMode::effective_threshold in macp-modes and evaluate_quorum_commitment_outcome in macp-policy — and when they each carried their own copy they disagreed: the mode truncated a fractional value (0.5 → 0) while the evaluator ceiled it (0.5 → 1), so one policy produced two different thresholds. RFC-MACP-0011 §7 forbids exactly that (“implementations MUST derive the same quorum state and the same commitment eligibility”). A third caller must call this, not re-derive it.

Deliberately not #[non_exhaustive], unlike its neighbours in this crate (crate::error::MacpError, crate::mode::ModeResponse, crate::mode::MessageContext, crate::session::Session, super::PolicyDecision, super::CommitmentMode). That attribute binds every crate except the defining one, so here it would force a _ arm at exactly the two call sites — QuorumMode::effective_threshold in macp-modes and evaluate_quorum_commitment_outcome in macp-policy — whose compile-time exhaustiveness is the guarantee unifying this rule buys. A fail-closed _ arm would be strictly worse for a governance kernel: a future variant would silently decline instead of failing to build, which is the same class of silent mis-handling as issue #145. Adding a variant later is not a silent break either — enum_variant_added is a major cargo-semver-checks lint and release-plz.toml sets semver_check = true, so it blocks the release PR. The residual cost is release coordination, not an undetected breakage.

Variants

Inert

The rule imposes no bar (value <= 0, including the schema default), so the caller keeps its own default.

The two callers’ defaults differ, and unifying them is out of scope for the rounding fix: the mode falls back to the ApprovalRequest’s required_approvals, while the evaluator applies no threshold check at all. See ASSUMPTIONS.md, “Quorum threshold.value = 0”.

Approvals(u32)

This many approvals are required to seal a positive commitment. Never zero: a bar of zero would be met before any ballot was cast.

Unsatisfiable

No number of approvals can satisfy the rule, so the session can seal no positive commitment. Returned for type: "weighted" (unimplemented here — threshold.value is typed integer by quorum-rules.schema.json, so a weighted sum is not expressible and per-participant quorum weights are not modelled), for any unrecognised type, and for a percentage over an empty participant set.

Registration refuses the first two (PolicyRegistry::validate_quorum_threshold), so reaching those needs a directly-constructed PolicyDefinition; the empty-participant-set case is not catchable there, since registration has no participant count, and QuorumMode::on_session_start blocks it instead. It fails closed rather than silently reinterpreting the value as a raw approval count, which is what the old shared _ arm did.

Trait Implementations

impl Clone for EffectiveThreshold

fn clone(&self) -> EffectiveThreshold

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Copy for EffectiveThreshold

impl Debug for EffectiveThreshold

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl Eq for EffectiveThreshold

impl PartialEq for EffectiveThreshold

fn eq(&self, other: &EffectiveThreshold) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl StructuralPartialEq for EffectiveThreshold