Module intent_binding 

The binding: what a piece of work serves, resolved once, before it starts (ADR 0111).

crate::intent::Intents::preflight answers which intent an issue, or some paths, serve. A task needs slightly more than that and nothing different: it may name an intent instead of an issue, it may give an exemption the policy declares instead of either, paths that reach more than one intent are an ambiguity rather than two answers, and the worker who resumes the task later needs to know whether what it was bound to has moved. This module is that layer and only that layer: every link is still judged by the preflight, which is still judged by the coverage intent validate reports from.

Nothing here is stored and nothing here writes. A task record keeps what its worker named — an issue id, an intent id, an exemption with its reason — and two pins. The pins are hashes compared on a later read; the intent, its stage, its verdict and its criteria are derived again every time, as rule project.an-intent-outlives-its-sessions requires.

pin	hashes	moves when
plan_revision	each served intent’s statement, invariants, non-goals and criteria; the issues resolved with what each serves; each critique’s findings and their resolutions	the intent, a link or the critique is edited
evidence_standing	the evidence state of each served criterion	a criterion’s evidence changes state

Two, because they answer different questions and fail differently: an ordinary commit can make evidence stale without anyone having touched what the work is for, and a worker told “your intent changed” on every commit stops reading the line.

use majordomus_cli::intent_binding::{BindingCause, BindingRequest, BindingStanding};
// naming nothing is not a binding
assert!(BindingRequest::default().names_nothing());
assert_eq!(BindingStanding::Exempt.as_str(), "exempt");
assert_eq!(
    serde_json::to_string(&BindingCause::AmbiguousIntent).unwrap(),
    "\"ambiguous_intent\""
);

Structs

BindingDrift

How a binding moved between two reads: what a resumed worker is told.

BindingExemption

The exemption a binding accepted: the class as the policy declares it, and the reason the worker gave.

BindingRefusal

One reason a binding was refused.

BindingRequest

What a worker named when it asked what its work serves. Every field is optional and the combinations are judged, not assumed: an issue alone, an intent alone, an issue beside the intent it should serve, paths alone, or an exemption with its reason.

IntentBinding

What a piece of work is bound to: its standing, what was named, the issues and intents it resolved to with what each intent asks of the worker, the two pins, and every refusal.

Enums

BindingCause

Why a binding was refused, as a word a reader greps for. The first seven are the preflight’s own causes, carried through unchanged; the rest are what only a binding can find.

BindingStanding

Where a piece of work stands against the intents: the one word a start decides on.

Functions

bind

What request is bound to. One derivation: every link is judged by the preflight, and this adds only what a task needs beside it — an intent given by name, a declared exemption, ambiguity, the scope note and the two pins.

start_refusal

Why the start transition of issue is refused, or None when it is not this module’s to refuse: the policy does not say intent.binding: required, or the issue’s binding is bound or maintenance. The sentence is the one majordomus plan start prints in the shell engine, which asks the same capability; cases 133 and 962 hold the two equal.