Module resolution 

Flight Rules resolution, approval pinning, and drift refusal (KRZ-342, design D-D/D-E/D-G): the deterministic applicability predicate over a loaded corpus, the engine-authored standardsManifest plan pin, and the final-validation/merge drift checks that consume only the pin and the trusted base. Flight Rules deterministic resolution, approval pinning, and drift refusal (ticket .kranz/tickets/flight-rules-resolution-pin.md, KRZ-342; design docs/scoping/flight-rules-engineering-standards.md, decisions D-D, D-E, and D-G over the KRZ-341 schema-4 corpus).

WHY the engine, not a model, selects (D-D): applicability is a pure function of declared rule metadata and three selection inputs — the workflow stage, the mission task class, and the touch paths — so the same inputs always select the same stable-sorted rules. Domains are browsing/reporting labels and are NEVER a selection input. Lifecycle is part of the predicate (D-B): retired rules never apply, draft rules apply only on lint/authoring surfaces (this module serves mission surfaces, so drafts never resolve here), and approved/enforced rules apply.

WHY two touch-path interpretations: approval resolves against the APPROVED TOUCH SET — gitignore-style globs, not real paths — so a declared glob and a rule’s when-paths prefix are compared by OVERLAP (either’s literal extent sits at/below the other), a conservative SUPERSET: any actual path admitted by the touch set that a rule scopes to was already selected at approval. Final validation and merge resolve against REAL changed paths with the exact prefix match ([crate::merge_gate::when_paths_match]). The superset property is what makes “newly applicable at validation” mean “the mission escaped its approved envelope” rather than a matching artifact — an empty touch set selects no path-scoped rule at approval, so an enforced path-scoped rule the actual diff activates is correctly an escape.

WHY the pin is engine-authored (D-E): the plan contract’s standardsManifest is a consent artifact. Approval reloads the TRUSTED source — tracked base blobs for a repo-relative pack (crate::pack::standards::load_at_ref, the merge-gates ownership idiom: a mission-branch edit is structurally invisible to it) or a single capability read for an external pack — resolves, and writes the pin. A plan CARRYING a manifest that differs from the fresh resolution is stale or substituted and approval rejects it; a plan carrying none is pinned by the engine (the planner never authors policy). Every later stage consumes the pin, never a later filesystem or branch read: an external pack edit after approval cannot change a run, and a mission that edits its own repo-relative pack is judged by the OLD base version.

WHY drift refusal at merge (D-E): the approved pin records what the operator consented to. Merge re-resolves the LIVE base policy against the exact scratch integration diff; if the applicable ENFORCED set differs from the approved one — a rule added, removed, re-revised, re-scoped, or re-bound — merge refuses with standards.drifted rather than grandfather-skipping current policy or silently applying new policy to an old consent artifact. The comparison re-resolves BOTH sides with the same inputs (merge stage, the pin’s task class, the integration paths), so an unchanged base policy can never false-positive.

Structs

DriftReport

The merge-time drift verdict: the applicable ENFORCED set resolved from the live base differs from the approved pin’s.

Enums

TouchInput

How the touch-paths selection input is interpreted (D-D).

Constants

APPROVAL_SURFACE

The resolution surface recorded on standards.resolved for the approval-time pinning resolution. Stage-specific projections (KRZ-345) emit their own surfaces; this slice resolves the mission-wide set once, at approval.

Functions

approval_pin

Resolve the standards pin for a plan approval: load the TRUSTED source, resolve the mission-wide applicable set against the plan’s touch set, and reconcile with the manifest the plan already carries. Returns the pin to attach to the plan (None — and a byte-identical approval — when no standards-configured pack governs).

approval_pin_with_context

approval_pin with explicit read-only applicability context. Used by review-artifact consumers so rules scoped to the reviewed source are selected without authorizing that source for mutation.

evaluation_paths

Actual changed paths plus approval-pinned, read-only context. The latter affects rule and checker applicability but never the contract write sweep.

merge_drift

The merge-time policy-drift check (D-E): re-resolve the LIVE base policy against the exact scratch integration diff and compare the applicable ENFORCED set against the approved pin’s, both sides resolved with the same inputs (merge stage, the pin’s task class, the integration paths) so an unchanged base can never false-positive. Ok(None) — no drift — lets the merge proceed. External pins skip entirely: advisory-only, and the pinned bytes remain the authority (a later filesystem edit cannot change a run).

newly_applicable_enforced

The final-validation envelope check: re-read the pinned source snapshot (the mission’s pinned base_sha — immutable, so exactly the bytes approval read) and resolve it against the ACTUAL changed paths. Any effectively ENFORCED rule that is applicable now but was not pinned is a newly applicable enforced rule: the mission escaped its approved policy envelope and must be revised/reapproved, not silently judged against a moving set. Returns the offending rules as pin-shaped snapshots.

pin_from_manifest

Build the approval pin from a freshly resolved trusted manifest.

pin_from_manifest_with_context

pin_from_manifest with read-only selection context. Context paths affect applicability but are not part of the mission’s writable touch set.

render_pin_section

The plan.md section for a pin: source identity + digest, the selection inputs, and every applicable rule’s id, revision, effective status, statement, scopes, and checker binding — the review surface D-G requires.

resolve

Resolve one stage’s applicable rules over a live manifest (D-D): lifecycle-filtered and stable-sorted by id, so identical inputs always produce an identical selection.

resolve_mission_set

The mission-wide applicable set pinned at approval (D-E/D-G’s “one resolved set”): the union over the four workflow stages — a rule is selected when it applies at ANY of them. Stage projections later filter this set back down per stage.

resolve_pin

Re-resolve a PIN at one stage over touch — final validation and merge read the approved snapshot through this, never a live source. A pinned stage string that no longer parses scopes the rule to NO stage: the pin is engine-written, so an unparseable entry means a hand-edited plan, and the merge drift check then fails closed against the live side.