@tiphys/kernel 0.0.0 → 0.2.0

package/dist/src/checks.d.ts

@@ -0,0 +1,1539 @@
+/**
+ * THE DERIVED-CHECK REGISTRY (kernel plan M3, section 2.3 Kind B; step 8).
+ *
+ * JSON Schema expresses properties of ONE document reachable by one keyword.
+ * A property that compares array elements to each other, resolves a reference
+ * into another document, computes arithmetic over sibling fields or touches
+ * the filesystem is not expressible by any keyword under any DR-0013 option,
+ * and this module is where the plan stopped pretending otherwise (M3R-002).
+ *
+ * Each check runs AFTER schema validation succeeds and reports through the
+ * same contract with its own id attached:
+ *
+ *   INVALID <json-pointer> <message> (check: <check-id>)
+ *
+ * A check that needs a CONTEXT it was not given reports
+ * `SKIPPED <check-id> no context` and the command exits nonzero. That is the
+ * whole point of the mechanism: a cross-document rule must never be able to
+ * pass BY NOT RUNNING, which is the vacuous-pass shape SC-011 and M2-C-2 both
+ * exist to prevent, one layer up.
+ *
+ * DR-0013 clause 8: Kind B rules stay HERE and are never encoded as Ajv
+ * extensions. The Kind A / Kind B boundary is binding.
+ *
+ * D-M3-22: a check that belongs in section 2.3's table and is not in it is a
+ * PLAN DEFECT to escalate, not a script to add quietly.
+ */
+import type { Diagnostic } from "./validate.ts";
+/** What one derived check produced. */
+export interface CheckOutcome {
+    /** Violations, each of which makes the command exit nonzero. */
+    violations: Diagnostic[];
+    /**
+     * Lines the check REPORTS rather than fails on. `plan-dispatchable` is the
+     * instance: a phase whose `fill-in` is present and unfilled is valid for
+     * REVIEW and invalid for DISPATCH, so the validator computes and reports
+     * it instead of rejecting the document.
+     */
+    reports: string[];
+}
+export interface DerivedCheck {
+    id: string;
+    /** The artifact type this check is registered for. */
+    type: string;
+    /**
+     * THE OTHER artifact types this check must ALSO run on. Added by M3-P4 fix
+     * round 2 for CR-001, whose MECHANISM is worth stating at the field rather
+     * than at the one check that tripped over it:
+     *
+     *   A DERIVED CHECK IS REGISTERED PER TYPE AND READS A TYPE-SPECIFIC KEY,
+     *   WHILE THE `$defs` IT GUARDS ARE SHARED ACROSS TYPES BY `$ref`.
+     *   SHARING A DEFINITION THEREFORE DOES NOT SHARE ITS CHECK.
+     *
+     * Keywords travel through a `$ref` and derived checks do not, so a schema
+     * author who moves a rule into a shared definition gets the keyword half of
+     * the sharing for free and the Kind B half not at all. That asymmetry is
+     * invisible at the definition site, which is why `schemas/report.schema.json`
+     * could carry a comment saying a check applied where it did not.
+     *
+     * `guards` below names the shared definitions this check enforces, and
+     * `test/report-contract.test.ts` walks the TRANSITIVE closure of `$ref` in
+     * `schemas/`, failing when a guarded definition is reachable from a type
+     * this check does not list, or when a `guards` pointer resolves to nothing.
+     * REACHABLE was false of the ONE-HOP walk shipped before M3-P4 round 3.
+     */
+    alsoTypes?: readonly string[];
+    /**
+     * The shared `$def`s this check enforces, written as the pointer a
+     * cross-document `$ref` uses (`report.schema.json#/$defs/gateResult`).
+     * Absent means the check enforces nothing shared, which is the ordinary
+     * case: `plan-dispatchable` reads properties that exist in one document
+     * type only.
+     */
+    guards?: readonly string[];
+    /**
+     * True when the check resolves references into documents OTHER than the
+     * instance, so `--context <dir>` is required and its absence is a SKIP
+     * with a nonzero exit rather than a silent pass.
+     */
+    requiresContext: boolean;
+    run(instance: unknown, contextDirectory: string | undefined): CheckOutcome;
+}
+/** Every artifact type one check runs on, `type` first and then `alsoTypes`. */
+export declare function typesOf(check: DerivedCheck): readonly string[];
+/**
+ * A `report-code-disagreement` entry with `verified: false` names a claim
+ * that has NOT been confirmed against the code. R-012 says such a claim
+ * becomes a verification-first step: step 1 is confirm, write down, then
+ * build. So the owning phase must carry a step with `kind:
+ * verification-first`.
+ *
+ * No schema keyword reaches this: it matches an element of ONE array against
+ * a step nested inside an element of ANOTHER array, selected by phase id. A
+ * foreign-key lookup across arrays is not a keyword property.
+ */
+export declare const planVerificationFirstPresent: DerivedCheck;
+/**
+ * A phase whose `fill-in` is present and unfilled is VALID FOR REVIEW and
+ * INVALID FOR DISPATCH. That is a derived boolean over the slots rather than
+ * a property of any one field, so the validator computes and REPORTS it. A
+ * schema cannot express it, and rejecting the document would be wrong: the
+ * plan is legitimately reviewable in that state.
+ */
+export declare const planDispatchable: DerivedCheck;
+/**
+ * Every `hazard-classes[].addressed-by` must RESOLVE. Its two arms resolve
+ * against DIFFERENT things, which is why one witness is not a class here:
+ *
+ *   `criterion <id>`     resolves into the SAME phase's `acceptance[]` ids;
+ *   `later-phase: <id>`  resolves into the PLAN's `phases[]` ids.
+ *
+ * `enum` cannot express either, because the admissible values are computed
+ * per phase rather than fixed. The schema's `pattern` is the Kind A half and
+ * checks only the SHAPE of the string; a shape that resolves to nothing is
+ * precisely the defect section 2.6 was written after finding: a hazard class
+ * that names a criterion which does not exist has documented an obligation
+ * instead of creating one.
+ */
+export declare const planHazardClassesAddressedByResolves: DerivedCheck;
+/**
+ * "Downgrades are declared, never improvised" (blueprint section 8), made
+ * falsifiable: every stage the reference mode `full` runs and this mode does
+ * not must appear in this mode's `skips[]`.
+ *
+ * NO SCHEMA KEYWORD REACHES THIS. It is a set difference between the
+ * `pipeline` of ONE array element and the `pipeline` of a SIBLING element,
+ * selected by id, compared against a third field of the first (M3R-002). The
+ * schema's whole share is that `skips` exists and holds stage ids.
+ *
+ * TWO STRUCTURALLY DIFFERENT WAYS TO EVADE IT, and both are violations here
+ * rather than one being left implied:
+ *
+ *   1. a mode omits a stage and declares NOTHING (`skips: []`);
+ *   2. a mode omits two stages and declares ONE of them, so the document reads
+ *      as a mode that has accounted for itself while one downgrade is silent.
+ *
+ * AND A THIRD, WHICH IS WHY THE MISSING REFERENCE IS A VIOLATION AND NOT A
+ * QUIET RETURN: deleting the `full` mode from the document disables the
+ * comparison for every remaining mode at once, so a document with one
+ * `direct-pr` mode, an empty `skips[]` and no `clean-room-review` would pass a
+ * check that returned early. That is the same defect one level up, so the
+ * absent reference fails closed.
+ *
+ * SOUNDNESS, THE CONVERSE DIRECTION, ADDED IN ROUND 9 (CR-002). Everything
+ * above asks ONE question: is every stage this mode omits DECLARED? It never
+ * asked the converse: is every stage this mode DECLARES actually omitted? A
+ * set checked in one direction only is a set nothing constrains, and `skips[]`
+ * is shipped DATA that any edit can change. The measured consequence was not
+ * hypothetical: `full` keeping its complete twelve-stage pipeline and gaining
+ * ONE bogus `skips[]` entry validated at exit 0, and `tiphys mode show --mode
+ * full` then printed that no phase of the tiphys project had ever been
+ * delivered under the mode this project has delivered every phase under
+ * (delivery/review/clean-room-m3-p3-r8-criteria.md:217).
+ *
+ * SOUNDNESS HAS TWO DIRECTIONS AND ROUND 9 SHIPPED ONE (round 10, V-1).
+ * `skips[]` is defined by the document itself as every stage in `full`'s
+ * pipeline that this mode's pipeline omits AND NOTHING ELSE, so "actually
+ * omitted" is measured against the REFERENCE and an entry can fail it two
+ * ways: (A) this mode's own pipeline runs the stage, and (B) NOTHING runs it,
+ * that is, it is absent from this mode's pipeline and from `full`'s as well.
+ * Round 9 implemented the predicate the reviewer wrote down (A) rather than
+ * the property the same reviewer described thirteen lines earlier, and then
+ * recorded in two shipped documents that the check ran in both directions.
+ * B was reachable on the shipped data with a one-line edit, because the stage
+ * vocabulary has thirteen ids and `full`'s pipeline has twelve: `direct-pr`
+ * gaining `orchestrator-diff-review` validated at exit 0 and `tiphys mode
+ * show` then reported a skipped-stage count one too high with a `skips:` row
+ * naming a stage that is no downgrade at all.
+ *
+ * WHICH SIDE OF THE COMPARISON IS EDITED DOES NOT MATTER, and that is why B is
+ * not merely "a typo in skips". Shrinking `full`'s PIPELINE, touching no
+ * `skips[]` anywhere, turns every other mode's previously correct entry for
+ * that stage into a phantom. The reference is one half of the relation and
+ * either half moving breaks it.
+ *
+ * THE DIRECTION-A PREDICATE RUNS OVER EVERY MODE INCLUDING THE REFERENCE, and
+ * that is load-bearing rather than a detail. The completeness loop `continue`s
+ * past `full` because a mode cannot omit a stage relative to itself; the
+ * soundness question is well posed for `full` too, and `full` is precisely the
+ * mode the sharpest member targeted. A soundness loop that inherited the
+ * completeness loop's skip would have been green against the finding that
+ * caused it to be written.
+ *
+ * DIRECTION A NEEDS NO REFERENCE MODE, so it runs BEFORE the reference is
+ * resolved and its violations survive an absent `full`. A document that both
+ * deletes `full` and carries a contradictory `skips[]` reports both facts
+ * rather than the first one only. DIRECTION B cannot: it is defined by the
+ * reference pipeline, so it runs after the resolution and an absent `full` is
+ * already a violation in its own right.
+ */
+export declare const modeNoUndeclaredDowngrade: DerivedCheck;
+/**
+ * R-024: an adversarial plan review happens before anyone builds.
+ *
+ * THE RELATIVE POSITION OF TWO VALUES IN A VARIABLE-LENGTH ARRAY IS NOT A
+ * KEYWORD PROPERTY (M3R-002). `contains` can say both are present and nothing
+ * in the vocabulary can say which comes first.
+ *
+ * The rule has TWO ARMS because there are two ways to build before a review,
+ * and the plan states both: reorder them, or delete the review. So a mode
+ * whose pipeline contains `implement` and NOT `adversarial-plan-review` must
+ * list the review in `skips[]`, which is the same declared-downgrade
+ * discipline applied to the one stage R-024 is about.
+ */
+export declare const modeStageOrder: DerivedCheck;
+/**
+ * Every `gate-sets[]` entry RESOLVES against `gate-registry.yaml`.
+ *
+ * WHAT "RESOLVES" MEANS HERE, stated because a checker whose promise is vague
+ * is a checker nobody can falsify: the entry names a gate the registry
+ * declares, AND that gate's own `modes` list names this mode. Both halves are
+ * needed, because a reference that resolves to a gate which never runs in this
+ * mode is a mode whose assurance is a name with no gates behind it, which is
+ * the hazard exactly as the plan words it.
+ *
+ * `requiresContext` is TRUE, so invoking the validator without `--context`
+ * prints `SKIPPED mode-gate-sets-resolve no context` and exits nonzero. That
+ * is the point of the mechanism (M3-P1 criterion 4c): a cross-document rule
+ * must never be able to pass BY NOT RUNNING.
+ */
+export declare const modeGateSetsResolve: DerivedCheck;
+/**
+ * The charter schema's mode enums equal the ids declared here.
+ *
+ * `schemas/charter.schema.json` declares the mode vocabulary a project charter
+ * may use, and this document declares what those modes ARE. Two lists, one
+ * fact. Without this check they are a duplication that drifts silently the
+ * first time a mode is added, which is the same drift hole M3-P2 closed for
+ * the gate list.
+ *
+ * BOTH FIELDS, not one. The charter carries `delivery-mode` AND
+ * `assurance-tier`, M3-P1 shipped the identical placeholder enum on both, and
+ * step 4 names both ("Add `mode` and `assurance-tier` validation to the
+ * charter schema's enum"). A check that watched only one would leave the other
+ * free to drift, which is the hazard rather than a smaller version of it.
+ */
+export declare const charterModeEnumMatchesModes: DerivedCheck;
+/** `modes[].id` selects exactly one mode. */
+export declare const modeIdsAreUnique: DerivedCheck;
+/**
+ * `roles[].role` selects exactly one binding. B-004: the SAME defect, in the
+ * document nothing consumes yet, which is why it was latent rather than
+ * demonstrable. It is fixed in the same act because the mechanism is one thing.
+ */
+export declare const roleIdsAreUnique: DerivedCheck;
+/**
+ * The QUOTABLE UNITS of a prose record: every top-level PARAGRAPH and every
+ * OUTERMOST LIST ITEM, each with its marker stripped and its whitespace
+ * normalized.
+ *
+ * WHY THIS EXISTS, and it is the whole of fix round 2. The first version of
+ * this check asked whether each condition OCCURRED ANYWHERE in the record, as
+ * one normalized blob. That is a CONTAINMENT predicate standing in for an
+ * EQUALITY predicate, and containment is trivially satisfiable by short
+ * strings: `conditions: ["a", "the", "review", "merge", "is", "of"]` replaced
+ * every one of DR-0012's six merge-authority conditions with junk and the
+ * check exited 0. Every one of those words occurs in the record.
+ *
+ * The signal was already in this phase's own evidence and was read past: an
+ * earlier probe fabricated `"one"` through `"six"` and got findings for
+ * indices 3, 4 and 5 ONLY, because "one", "two" and "three" occur inside the
+ * record's prose. Three of six caught looked like the check working.
+ *
+ * Comparing against UNITS rather than against the blob makes the predicate an
+ * equality: a condition matches only if it is a WHOLE quoted item of the
+ * record. Both halves matter. Whole, so a fragment cannot match; item rather
+ * than whole document, so a record may carry other prose around the conditions
+ * without anyone having to say which section holds them, which is the
+ * structure assumption that would have made this check project-specific.
+ *
+ * THE COST, stated because it is a real constraint on a consuming project: a
+ * condition must be quoted as a complete list item or paragraph of the record.
+ * A condition that paraphrases, or that quotes half of a longer item, is now
+ * a violation. That is what "quoted from the decision record rather than
+ * summarized" already claimed to mean, and it is now enforced rather than
+ * asserted.
+ *
+ * A LIST ITEM'S UNIT IS THE WHOLE ITEM. An item's continuation paragraphs and
+ * its nested sub-items are CONTENT OF THE ITEM in CommonMark, so emitting them
+ * as units of their own would leave the item's FIRST PARAGRAPH standing as a
+ * whole unit while the item itself carried more, which is a fragment passing as
+ * a whole quote: the defect this check exists to prevent, arriving through the
+ * extractor. It is live in this repository:
+ * `delivery/decisions/DR-0004-elevated-permissions.md` has the shape (an item,
+ * a blank, then its commands indented under it) and
+ * `delivery/decisions/DR-0013-schema-validator-implementation.md` has the
+ * nested-list form. THE COST, stated because it is real: a nested sub-item is
+ * not separately quotable, so a record whose conditions are sub-bullets must
+ * quote the enclosing item whole.
+ *
+ * ------------------------------------------------------------------
+ * THE BLOCK STRUCTURE IS READ FROM A COMMONMARK PARSER (DR-0022, owner
+ * decision, option A2). THE TEXT IS SLICED FROM THE ORIGINAL SOURCE.
+ * ------------------------------------------------------------------
+ *
+ * What stood here until 2026-08-09 was a HAND-ROLLED CommonMark block parser:
+ * a line loop carrying fence state, indented-code state, a list content column
+ * and a deferred-blank flag, with six sites that could end a unit. It took FIVE
+ * fix rounds and produced FIVE defects, the fifth a regression of a shape the
+ * fourth had correct. The owner's decision records the measurement that ended
+ * it: against two independent conformant parsers over 15,000 generated
+ * documents, the hand-rolled loop agreed on about 35 per cent of them.
+ *
+ * The reason the rounds could not converge is worth keeping, because it is a
+ * property of the problem and not of the agents. Whether a line is prose
+ * depends on which block encloses it, and which block encloses it depends on
+ * lines above and sometimes below (a setext underline retroactively makes the
+ * block above it a heading). A loop that decides one line at a time is
+ * reconstructing a parser, and every reconstruction has to be kept in agreement
+ * with the reference BY HAND, with no mechanism that detects divergence. That
+ * is the "guard narrower than the property" family, and this repository has now
+ * recorded it five times in this one function.
+ *
+ * TWO OF THE ELEVEN FINDINGS ACROSS THOSE ROUNDS WERE NOT DEFECTS AT ALL. V-3
+ * ("adjacent paragraphs merge") and the fifth member of V-5 (a nested sub-item
+ * followed by a dedented line) were both cases where a hand-reading of markdown
+ * disagreed with CommonMark and the HAND-READING WAS WRONG: lazy continuation
+ * makes both fusions correct. A round can only find defects it already believes
+ * in, which is the other half of the cost.
+ *
+ * WHY `sourcepos` SLICING AND NOT THE PARSER'S INLINE TEXT, which is the whole
+ * of A2 versus A and is the single most expensive detail here. Walking the AST
+ * and reading each paragraph's inline text is the obvious implementation and it
+ * SILENTLY CHANGES THE SHIPPED CONTRACT, because inline text drops markup:
+ * `` `delivery/review/` `` becomes `delivery/review/`. DR-0012's first
+ * merge-authority condition contains exactly that, so `assurance-modes.yaml`
+ * stops resolving, and 11 of this repository's 19 decision records produce
+ * different unit sets. Slicing the ORIGINAL SOURCE by the parser's own
+ * `sourcepos` offsets keeps the bytes as written, which is what every existing
+ * record and every existing condition relies on.
+ *
+ * SO: this function reads the parser for STRUCTURE ONLY. It never reads
+ * `literal` and never concatenates inline nodes, and a change that starts doing
+ * either is option A, which is a defect. `CommonMarkNode` above declares six
+ * members and none of them is inline text, so the type is the guard.
+ *
+ * WHAT THE FOUR PREVIOUSLY UNMODELLED BLOCK FORMS DO NOW, since the old
+ * docstring listed them as latent hazards:
+ *   - block quote: its contents are treated like the document's, so the quoted
+ *     paragraph is a unit and the `>` marker is NOT part of it. This is a
+ *     DECLARED POLICY CHOICE (see `collectUnits`), not a derivation.
+ *   - HTML block: contributes no unit. Corrected in round 7 (CR-003): it is
+ *     listed in `NOT_QUOTABLE`, but under `commonmark` 0.31.2 that listing is
+ *     not what excludes it. An `html_block` is an AST LEAF, and a unit is only
+ *     ever emitted for a `paragraph` child, so it could contribute nothing even
+ *     if the set were empty. Read `NOT_QUOTABLE`'s own docstring for what the
+ *     set is really for.
+ *   - link reference definition: excluded, and by construction rather than by a
+ *     rule, because the parser removes it before this walk sees the document.
+ *   - pipe table: never was a hazard. CommonMark core has no tables, so a table
+ *     IS a paragraph and treating its lines as prose is correct.
+ *
+ * WHERE THIS IS STILL NOT AN ORACLE: it is right in the sense of "agrees with
+ * `commonmark` 0.31.2". Two conformant CommonMark implementations disagree on
+ * roughly half a per cent of generated documents (an indented line immediately
+ * after a link reference definition is the measured instance), and any
+ * structure-reading option inherits that.
+ */
+export declare function quotableUnits(text: string): Set<string>;
+export declare const modeConditionsQuoteGrantedBy: DerivedCheck;
+/**
+ * WHERE THE SHARED `gateResult` DEFINITION IS REACHED FROM, one row per
+ * artifact type, naming the KEY that type stores its gate results under.
+ *
+ * This table is the concrete form of CR-001's mechanism. The definition is
+ * one object reached by `$ref` from two documents; the PROPERTY NAME differs
+ * between them (`gate-results` in a report, `gate-evidence` in a work
+ * history), so a check that hard-codes one key is blind on the other type
+ * even after it is registered for it. Both halves are needed and only one of
+ * them is visible from the `$ref`.
+ */
+export declare const GATE_RESULT_SITES: readonly {
+    readonly type: string;
+    readonly key: string;
+}[];
+/**
+ * `discovered == passed + failed + skipped + did-not-run`, over one gate
+ * result's sibling fields.
+ *
+ * NO SCHEMA KEYWORD COMPUTES ARITHMETIC over sibling fields, which is what
+ * makes this Kind B rather than a keyword (M3R-002 corrected revision 0's
+ * classification of exactly this check). The property it guards is R-048's:
+ * a suite that reports fewer tests than it discovered is the
+ * silently-dropped-tests case, and it adds up to a green everywhere else.
+ *
+ * THREE THINGS THIS CHECKS, and the second and third are the CONVERSES the
+ * criterion's letter does not name. The plan's criterion 2b(a) names only
+ * `discovered` EXCEEDING the sum. A check that tested only that direction
+ * would pass a record whose sum exceeds `discovered`, which is a different
+ * lie with the same shape, so the test here is EQUALITY. And a count field
+ * that is NEGATIVE is arithmetic nonsense that equality alone can satisfy
+ * (`discovered: 0` with `passed: 1` and `failed: -1` adds up); negativity is
+ * not reachable by any keyword in the declared authoring vocabulary, which
+ * has no `minimum`, so it is checked here beside the sum rather than left to
+ * a keyword that does not exist.
+ *
+ * WHAT IT DOES NOT REACH, stated rather than implied: a gate result carrying
+ * NO count field at all is not examined, because the schema requires the six
+ * counts only of a `green`, and a `red` result that records none of them is a
+ * legitimate record rather than a false one. So this check cannot see a
+ * dropped test in a run nobody counted; it sees one in a run that claims a
+ * count. Nor does it reach a BALANCED loss: an author who drops the same row
+ * from `discovered` and from a bucket satisfies the identity, because nothing
+ * here anchors `discovered` to what the wrapper actually discovered.
+ *
+ * WHERE IT RUNS, and this is CR-001's whole content. It runs on EVERY type
+ * that reaches the shared `gateResult` definition, enumerated by
+ * `GATE_RESULT_SITES` rather than by one hard-coded key. Until M3-P4 fix
+ * round 2 it was registered for `report` alone and read `gate-results` alone,
+ * so a work history recording 9999 discovered and 1 passed exited 0 while the
+ * identical counts in a report exited 1, and the shared definition's own
+ * comment said the check applied.
+ */
+export declare const reportParityArithmetic: DerivedCheck;
+/**
+ * Every id in `inputs[]` appears in `input-findings[]`, exactly once, and no
+ * `input-findings[]` row names an id `inputs[]` does not carry.
+ *
+ * A CROSS-ARRAY COMPLETENESS PROPERTY, which no keyword reaches: `contains`
+ * asks about a fixed shape, not about a value computed from a sibling array.
+ * Revision 0 of the plan listed this once as a schema witness, which was
+ * wrong (M3R-002).
+ *
+ * THREE DIRECTIONS, and only the first is in the criterion's letter. The
+ * criterion names the ORPHAN: an id in `inputs[]` with no row. The PHANTOM
+ * (a row whose id is not an input) and the DUPLICATE (two rows for one id)
+ * are the converses, and they are here because M2-P6 paid for both by
+ * measurement rather than by argument: CR-988 records that its parity mode
+ * scanned inventory ids only, so a row for a renumbered id was silently
+ * accepted, and CR-985 records that a duplicated id defeated the orphan and
+ * phantom checks TOGETHER while inflating every count. A guard narrower than
+ * its own description is what this project keeps re-buying, so the check is
+ * as wide as the relation.
+ *
+ * WHAT IT DOES NOT REACH: a finding dropped from BOTH arrays. The two
+ * documents then agree with each other, and no comparison between them can
+ * see it. That is the same residue `src/gates/coverage.ts` answers with a
+ * config-stated `expectedUnits` anchor, and this schema has no such anchor
+ * because nothing in the plan states one.
+ */
+export declare const finalReportFindingParity: DerivedCheck;
+/**
+ * A report with an EMPTY `findings` array carries a `no-findings-statement`,
+ * and a report that files findings does NOT carry one.
+ *
+ * KIND B BY NECESSITY, AND THE NECESSITY IS MEASURED RATHER THAN ASSERTED.
+ * The natural keyword shape is `if findings has maxItems 0 then require
+ * no-findings-statement`, and `maxItems` is ABSENT from the sixteen keywords
+ * of `AUTHORING_VOCABULARY` (src/validate.ts:111). No other permitted keyword
+ * says "this array is empty": `minItems` says the opposite, `contains` asks
+ * about a member that exists, and `const: []` is not reachable because `const`
+ * is used on scalars here and an array `const` would pin the CONTENTS. So the
+ * emptiness of a sibling array is not a keyword property, which is the same
+ * boundary `report-parity-arithmetic` sits on one field over.
+ *
+ * WHY IT IS HERE AT ALL. `no-findings-statement` exists to price silence: a
+ * report claiming nothing was found must say WHY nothing was found. Optional,
+ * it is absent in exactly the situation it exists for, and the shipped schema
+ * disclosed that as a residue rather than closing it. The orchestrator's
+ * arbitration of M3-P4 round 1 amended section 2.3's table to three rows for
+ * this phase and directed the check to be written; D-M3-22 is satisfied by
+ * that amendment, not by this comment.
+ *
+ * BOTH DIRECTIONS, because the phase's own converse discipline demands it.
+ * The requirement's letter names only the empty-with-no-statement case. A
+ * report that files three findings and ALSO carries "no findings were found"
+ * is the opposite misdeclaration and is equally a false record, so it is a
+ * violation too.
+ *
+ * WHAT IT DOES NOT REACH: whether the statement SAYS anything. The schema
+ * makes an empty or whitespace-only one impossible; a statement reading "n/a"
+ * satisfies both this check and those keywords, and that is M3-P7's
+ * `contract-avoidance` probe rather than anything a schema or a check can see.
+ * It also does not reach a report with NO `findings` key at all, because
+ * `findings` is `required` and the schema rejects that before any check runs.
+ */
+export declare const reportNoFindingsStatement: DerivedCheck;
+/**
+ * No two probes in one checklist share an `id`.
+ *
+ * KIND B, AND THE REASON IS A KEYWORD'S SEMANTICS RATHER THAN A DOCUMENT
+ * BOUNDARY. `uniqueItems` compares WHOLE array items, so two probes sharing
+ * an id and differing in any other field are already unique to it, and the
+ * pair that shares an id is exactly the dangerous instance: `checklist
+ * resolve` looks a probe up by id, so a duplicate makes the resolved list
+ * depend on which one the lookup reached. Uniqueness of a NESTED PROPERTY
+ * across array items is not a keyword property under any DR-0013 option,
+ * which is why the review did not name it and why it lands here.
+ *
+ * `requiresContext` is FALSE: the whole comparison is inside one document.
+ */
+export declare const checklistProbeIdsUnique: DerivedCheck;
+/**
+ * No two framings in one checklist share an `id`.
+ *
+ * THE SAME SHAPE AND THE SAME KEYWORD LIMITATION AS THE PROBE CHECK ABOVE,
+ * one array along. `uniqueItems` on `framings` compares WHOLE items, so two
+ * framings sharing an id and differing in their entry point or their scope
+ * order are already unique to it, and that pair is exactly the dangerous
+ * instance: `resolveChecklist` looks a framing up with `.find()`, first match
+ * wins, so which of two declared entry points a reviewer is handed depends on
+ * FILE POSITION and nothing says so.
+ *
+ * WHY IT MATTERS MORE HERE THAN THE PROBE CASE LOOKS LIKE IT WOULD. A
+ * framing IS the entry point, and T-001's lesson that decorrelation comes
+ * from the starting question is the whole reason `--framing` exists. A
+ * duplicate id means the reviewer's starting question is decided by which
+ * copy sat first in the file, which is the phase's own hazard class ("a
+ * framing that reorders the list without changing the entry point") reached
+ * from the other side.
+ *
+ * `requiresContext` is FALSE: the whole comparison is inside one document.
+ */
+export declare const checklistFramingIdsUnique: DerivedCheck;
+/**
+ * The join M3-P2 deliberately left open, closed in BOTH DIRECTIONS.
+ *
+ * `gate-registry.yaml` carries entries whose `verified-by` is
+ * `clean-room-checklist` and whose `probe` names a probe id this phase
+ * supplies. Nothing on the registry side can check that the probe exists,
+ * because the checklist did not exist when the registry shipped.
+ *
+ * DIRECTION 1, REGISTRY TO CHECKLIST (criterion 3). Every registry entry
+ * verified by a checklist names a probe that RESOLVES in that checklist, and
+ * that probe carries the `verifies-gate` back-reference to the entry. WHICH
+ * checklist is derived from the registry's own vocabulary rather than
+ * hardcoded: `verified-by: clean-room-checklist` names the checklist whose id
+ * is `clean-room`, so an entry is only asserted against the document it
+ * actually names, and running this check on `plan-review.yaml` does not
+ * demand the clean-room probes there.
+ *
+ * DIRECTION 2, CHECKLIST TO REGISTRY (criterion 3c). Every probe carrying
+ * `verifies-gate` names a gate id present in the registry. THE ASYMMETRY IS
+ * THE WHOLE POINT: direction 1 starts from the registry and therefore cannot
+ * see a probe pointing at a gate that no longer exists, which is what the
+ * phase's own hazard class calls an orphan invisible by construction. The two
+ * ways a registry edit orphans a probe fail through DIFFERENT lookups: a gate
+ * id RENAMED leaves the probe pointing at a name that never existed, and a
+ * gate entry DELETED leaves it pointing at a name that used to. Both land
+ * here; neither is reachable from direction 1.
+ *
+ * `requiresContext` is TRUE, so invoking the validator without `--context`
+ * prints `SKIPPED gate-probes-resolve no context` and exits nonzero. A
+ * cross-document rule must never be able to pass BY NOT RUNNING.
+ */
+export declare const gateProbesResolve: DerivedCheck;
+/**
+ * A verdict's `criteria[]` carries one entry per acceptance criterion of the
+ * plan phase it reviews.
+ *
+ * THE DANGEROUS INSTANCE is a review that quietly skipped a criterion: every
+ * entry present is well formed, the schema is satisfied, and the one
+ * criterion nobody walked is invisible. R-053 says each criterion is quoted
+ * with evidence and a verdict, and "each" is a comparison against a DIFFERENT
+ * document, which no keyword reaches.
+ *
+ * BOTH DIRECTIONS, because they are different mistakes. A criterion the
+ * verdict omits is an unwalked criterion; a verdict entry naming a criterion
+ * the phase does not declare is a review walking something that is not in the
+ * contract, usually a criterion id left behind by a plan revision.
+ */
+export declare const verdictCriteriaComplete: DerivedCheck;
+/**
+ * A verdict's `deviations-judged[]` carries one entry per deviation declared
+ * in the phase's work history.
+ *
+ * M3R-005 IS WHY THIS IS A CHECK AND NOT A PROBE. R-057b's "judged, never
+ * assumed by the implementer" has exactly the same completeness shape as
+ * criteria coverage, and revision 0 had left it as a bare probe question for
+ * no stated reason, so a reviewer could silently skip judging one of three
+ * declared deviations and every criterion still passed.
+ *
+ * THE OTHER DOCUMENT IS `work-history.yaml` in the context directory, and it
+ * must be the work history OF THE PHASE THIS VERDICT NAMES: a work history
+ * for another phase would let the check pass by comparing against the wrong
+ * deviation list, which is a vacuous pass wearing a cross-document check's
+ * clothes.
+ */
+export declare const verdictDeviationsJudged: DerivedCheck;
+/**
+ * A HAZARD verdict's `hazard-classes-addressed[]` carries one entry per
+ * hazard class declared by the plan phase it reviews.
+ *
+ * T-007 IS THE INPUT AND M3R-005 IS THE SHAPE. This has exactly the shape
+ * `verdict-criteria-complete` has for criteria, one field along, and for
+ * exactly the same reason: a reviewer could otherwise silently skip one of
+ * three declared hazard classes while every other criterion still passed.
+ * T-007's measured case is a phase meeting fifteen of fifteen executed
+ * criteria while live-locking every supervision command.
+ *
+ * IT APPLIES EXACTLY WHERE THE CONTRACT APPLIES. A verdict whose
+ * `review-contract` is `criteria` is not asserted against, because the
+ * criteria contract is not the one that owes hazard statements, and a check
+ * that reddened on it would push reviewers to fill the array with nothing.
+ * That the criteria arm is unaffected is asserted by a test rather than left
+ * as an implication.
+ */
+export declare const verdictHazardClassesAddressed: DerivedCheck;
+/**
+ * Every `hazard-classes-addressed[].finding` names a `findings[].id` that
+ * exists in the SAME verdict.
+ *
+ * KIND B FOR THE SAME REASON `checklist-probe-ids-unique` IS, AND IT IS THE
+ * ONLY INTRA-DOCUMENT ID REFERENCE THE SHIPPED SCHEMAS DECLARE. The
+ * verdict schema's own `$comment` on `finding` calls it "the `findings[].id`
+ * this class produced", so the join is DECLARED; nothing resolved it, so it
+ * was a bare string with `minLength: 1`. Resolving one array's entry against
+ * another array's ids is not a keyword property under any DR-0013 option,
+ * which is why it lands here and not in the schema.
+ *
+ * WHAT IT PROTECTS, and it is not merely tidiness. The verdict schema ships
+ * exactly ONE rule that can force a verdict off APPROVE: a `findings[]` set
+ * containing a `high` or `critical` entry must carry FIX-ROUND-NEEDED. That
+ * rule reads `findings[]` and nothing else. So a hazard reviewer who records
+ * a class as having produced a finding, and leaves that finding out of
+ * `findings[]`, gets a schema-valid APPROVE with an empty findings array and
+ * the escalation rule never sees the finding it would have fired on. Measured
+ * at 4bfa790 before this check: such a document validated at exit 0, and the
+ * same document with the finding moved into `findings[]` at `severity: high`
+ * exited 1.
+ *
+ * A DANGLING REFERENCE IS ITSELF THE ERROR, not only one that lets the
+ * escalation be evaded, and the reason is that the narrower rule is not
+ * computable. A finding absent from `findings[]` has NO severity, so nothing
+ * can decide whether it would have escalated; the narrower reading would have
+ * to guess, and would clear exactly the document that withheld the most.
+ * Requiring the reference to resolve is decidable, and it puts the severity
+ * back under the escalation rule where the reader can see it.
+ *
+ * `requiresContext` is FALSE: the whole comparison is inside one document.
+ */
+export declare const verdictFindingReferencesResolve: DerivedCheck;
+/**
+ * A `structural-consequence` marked `applied` names a target path that EXISTS.
+ *
+ * KIND B BY NECESSITY: it resolves a string against the filesystem, which no
+ * keyword under any DR-0013 option reaches. `requiresContext` is TRUE, so
+ * running the validator without `--context` prints `SKIPPED
+ * tuition-target-exists no context` and exits nonzero rather than passing by
+ * not running.
+ *
+ * ONLY `applied` IS CHECKED, and that is the point rather than a limitation.
+ * `proposed` names a change nobody has made and `ticketed` names one carried
+ * by a record, so neither claims anything about the tree; `applied` claims the
+ * change is IN the tree, and T-003 is the entry recording that a document can
+ * carry exactly that claim falsely.
+ *
+ * WHAT IT DOES NOT REACH, named here because criterion 3 reads at a glance as
+ * though it covered the whole hazard: whether the file CONTAINS the change
+ * claimed. That is a semantic relation between a prose sentence and a file,
+ * and the plan's own hazard table assigns it to review rather than to a check
+ * (section 2.6 reason 1). The two halves are exactly what this project has
+ * repeatedly found to differ, so the check states which half it is.
+ */
+export declare const tuitionTargetExists: DerivedCheck;
+/**
+ * A PATH REFERENCE inside a `mechanisms[]` entry resolves against the tree,
+ * and a `machine-readable-form` resolves to a real document AND a real key
+ * inside it.
+ *
+ * T-005's checkability rule has two halves and they need two instruments. The
+ * SCHEMA half is `evidence` with `minItems: 1`: a rule with no citation is not
+ * a rule. THIS half is that a citation naming a file which does not exist is
+ * not a citation, which is a filesystem question and therefore Kind B.
+ *
+ * WHAT COUNTS AS A PATH REFERENCE, stated mechanically because a checker whose
+ * subject is vague cannot be falsified: a whitespace-delimited token holding at
+ * least one `/` and ending in a short extension, with surrounding backticks,
+ * brackets and trailing punctuation stripped. Real evidence in this feed reads
+ * `delivery/review/verification-m1-p3-fix-round.md V-1 and V-3`, so the
+ * reference is a token inside a sentence rather than the whole string.
+ *
+ * A `path.ext:LINE` CITATION IS A PATH REFERENCE (HRB-1, fix round 3). It is the
+ * form CLAUDE.md:155 mandates, and the earlier token test silently dropped every
+ * one of them; see `pathReferencesIn` for the measurement and the grammar.
+ *
+ * WHAT IT DOES NOT REACH, and these are real holes rather than tidy ones.
+ *
+ * PROSE-ONLY evidence. `M1-P5 round 4, verified pre-existing against a pristine
+ * build` names no path, so nothing about it is resolvable and this check says
+ * nothing about it. Requiring every citation to be a path would redden entries
+ * whose evidence is a measurement rather than a document, which is a real form
+ * of evidence this project uses. The residue is therefore deliberate: the check
+ * establishes that the paths cited EXIST, never that a rule is supported.
+ *
+ * A CITATION INTO A TREE THIS CONTEXT DOES NOT HAVE (HRB-8, fix round 3). The
+ * feed ships and `delivery/` does not, so in a consumer's install most citations
+ * name a repository that is not there. Those are REPORTED, with their count and
+ * the trees involved, and never counted as violations; see
+ * `unresolvableCitationTree` for why that is the correct answer rather than a
+ * softening, and for the reason it is not a silent pass.
+ *
+ * REGISTERED FOR BOTH TYPES. `mechanisms[]` appears in a tuition entry (where
+ * a rule is authored) and in the mechanism index (where it is projected). A
+ * check registered only for the first would leave the shipped index unchecked,
+ * which is the shared-definition asymmetry `alsoTypes` exists for.
+ */
+export declare const mechanismRuleEvidenceResolves: DerivedCheck;
+/**
+ * Every path-like token in one prose reference. See the check's header for the
+ * definition and for what it deliberately does not treat as a path.
+ *
+ * THE `:LINE` SUFFIX IS STRIPPED BEFORE THE EXTENSION TEST (HRB-1, M3-P8 fix
+ * round 3). CLAUDE.md:155 makes `path.ext:LINE` THE citation form in this
+ * project ("a bare path is not a citation at all") and src/gates/citations.ts
+ * is the gate that enforces it. The earlier form tested the extension at
+ * end-of-string, and a line number sits after it, so every citation written the
+ * way this repository REQUIRES resolved to nothing: an entry whose paths were
+ * entirely fabricated validated at exit 0, and the byte-identical entry with
+ * the suffixes removed went red. A check that passes exactly the mandated form
+ * is not a check.
+ *
+ * The suffix grammar is the citations gate's own, narrowed to what a suffix can
+ * be rather than re-derived: `:<line>`, an optional `-<line>` range, and an
+ * optional `@sha256:<hex>` content pin (src/gates/citations.ts:453). Stripping
+ * is deliberately conservative: a token that does not match keeps its colon and
+ * is then judged by the extension test as before, so `http://x/y.md` and
+ * `a/b.md:notaline` are unchanged.
+ */
+export declare function pathReferencesIn(reference: string): string[];
+/**
+ * THE TREE A CITATION IS ROOTED IN, when this context does not contain it.
+ * Returns that top-level name, or undefined when the citation IS resolvable
+ * here and absence would therefore be a real defect.
+ *
+ * WHY (HRB-8, M3-P8 fix round 3). A citation is relative to the repository that
+ * AUTHORED it. The tuition feed and its index ship in the npm package;
+ * `delivery/`, `src/`, `scripts/` and `test/` do not (package.json's `files`).
+ * So the checks that resolve a document-supplied path were asking a consumer's
+ * install a question only the kernel repository can answer, and answering it
+ * INVALID. Measured at 26ee653: the shipped index produced 16 INVALID lines
+ * from a pristine `npm pack` extraction, and eight of the fifteen shipped
+ * entries produced more. CI never saw it because this repository has
+ * `delivery/`, which is T-009's shape one scope out.
+ *
+ * schemas/mechanism-index.schema.json:5 already stated the governing fact
+ * before this round: resolution "is not computable from an installed package".
+ * This is that sentence made operative rather than decorative.
+ *
+ * THE PREDICATE IS THE TOP-LEVEL SEGMENT, and it is the coarsest one that still
+ * catches everything the kernel repository could catch before. A citation into a
+ * tree that IS present must still resolve, so a fabricated
+ * `delivery/review/invented.md` is as red here as it ever was; only a citation
+ * into a tree that is wholly absent is excused. A path with no directory
+ * component is NEVER excused, because the context root always exists: measured
+ * against the real feed, every `applied` root-level target ships, and the one
+ * root-level absentee (`AGENTS.md`) is `ticketed`, which the check does not read.
+ *
+ * THIS IS NOT A LICENCE TO GO QUIET. Every caller REPORTS what it declined to
+ * resolve and why. "Nothing to check here" and "everything checked and fine"
+ * must never print the same line, which is the SC-011 shape the plan's hazard
+ * row at delivery/plan/kernel-plan-m3.md:4042 polices.
+ */
+export declare function unresolvableCitationTree(contextDirectory: string, path: string): string | undefined;
+/** The three dimensions two verdicts of one head must differ on. */
+export declare const DECORRELATION_DIMENSIONS: readonly string[];
+/** The merge-authority value that makes decorrelation a precondition of merge. */
+export declare const DELEGATED_MERGE_AUTHORITY = "delegated-under-conditions";
+/**
+ * SAY WHAT `produced-by` ACTUALLY COMPARED, ON THE GREEN LINE (CR-VS-003).
+ *
+ * The comparison is `canonicalScalar`: NFKC, whitespace collapse, lowercase,
+ * then `!==`. Reproduced at the swept head with one variable changed: two
+ * `produced-by` strings naming two different MODELS of one vendor, in the
+ * vendor-plus-model-plus-organisation form this project's own reviews use, are
+ * certified "distinct on produced-by", green, exit 0. Two models of ONE family
+ * pass as decorrelated, which is T-001's own property failing inside the
+ * kernel's decorrelation check. The two strings are quoted verbatim in the
+ * sweep evidence rather than here, because no vendor model name may appear in
+ * the kernel's shipped surface (test/schemas.test.ts:800).
+ *
+ * WHY THIS IS A SENTENCE AND NOT A FAMILY VOCABULARY, and the reason is a
+ * settled one rather than an omission. M4-P10 deferred the family comparison to
+ * M4-P11 (delivery/work-history/m4-p10.md:654); M4-P11 DECLINED the mechanism in
+ * its own words, "a closed enum of family names was rejected: no such vocabulary
+ * can be kept current" (delivery/work-history/m4-p11.md:142). That reason holds
+ * and shipping the enum that phase rejected would be reopening it by the back
+ * door. What was never done is the OTHER half of the reviewer's own proposal:
+ * stop the green line reading as a cross-family assertion. A bundle-level green
+ * saying "distinct on produced-by" is read as "two families reviewed this", and
+ * nothing here establishes that. So the line now says what it measured.
+ *
+ * WHAT WOULD CLOSE IT, named rather than left open: a `produced-by-family`
+ * field in `schemas/verdict.schema.json`, required, compared instead of the free
+ * string, with the vocabulary OPEN (any two distinct values decorrelate) so no
+ * list has to be kept current. That is a schema change and a decision record,
+ * both outside this fix round's declared files.
+ */
+export declare function producedByCaveat(compared: readonly string[]): string;
+export interface LoadedVerdict {
+    path: string;
+    record: Record<string, unknown>;
+}
+/**
+ * What reading a candidate document's own `kind` produced, in the THREE
+ * outcomes that fix round 2 exists to keep apart.
+ *
+ * THE MECHANISM FIX ROUND 2 CLOSES: `establishField` already separates ABSENT
+ * from UNUSABLE from UNCANONICAL, and both selection sites consumed it with a
+ * single `!== "established"`, which folds those outcomes back into one silent
+ * skip. So "this document declares no type" and "this document declares a type
+ * nobody could read" printed as the same fact, and that fact is the determinate
+ * negative "not a verdict". Measured at the round-1 head: a third review
+ * reading `verdict: FIX-ROUND-NEEDED` whose `kind:` was a one-element YAML list
+ * was dropped and `scripts/check-dual-review.mjs` reported that the pair
+ * approves. Eight deformations of one refusing document reached that same
+ * green, and the table is in delivery/work-history/m4-p10.md's section 13.
+ *
+ * WHERE THE LINE IS DRAWN, and it is drawn at the PRESENCE OF THE KEY rather
+ * than at the validity of its value:
+ *
+ *   `verdict`     the key is there and canonicalises to the word. A member.
+ *   `other`       the document ANSWERED and the answer is not `verdict`. That
+ *                 is a mapping carrying no `kind` key at all, a document that
+ *                 is not a mapping (a list, a scalar, an empty file), and a
+ *                 `kind` that reads as some other word. Each is a determinate
+ *                 negative: nothing here claims to be a typed document, or it
+ *                 claims to be a different one.
+ *   `unreadable`  the key IS there and its reading failed: a list, a map, a
+ *                 number, a boolean, null, an empty or whitespace-only string,
+ *                 or a string carrying a character outside printable ASCII.
+ *                 Writing a `kind` key is the claim to be a typed document, so
+ *                 a failed reading of it is a failed claim, not an absent one.
+ *
+ * WHY NOT REFUSE EVERY DOCUMENT THAT IS NOT A VERDICT. Because a project is
+ * entitled to keep other YAML beside its reviews, and a check that errored on
+ * it would be unusable. The property is not that every file is a verdict; it is
+ * that a file which LOOKS LIKE a verdict and could not be read as one is NAMED.
+ *
+ * EXPORTED, and that is the other half of the fix. `scripts/check-dual-review.mjs`
+ * had its OWN selection rule, a raw `value["kind"] !== "verdict"`, which is a
+ * second reader of one fact: it dropped `kind: Verdict` and `kind: "  verdict  "`
+ * that this file's canonicalisation admits. Two readers of one fact is the shape
+ * this repository's fix-round contract calls fixing the INSTANCE rather than the
+ * MECHANISM, and the sibling `establishDelegatedRegime` one screen down was
+ * lifted for exactly that reason. There is now one reader.
+ */
+export type VerdictKindReading = {
+    kind: "verdict";
+    record: Record<string, unknown>;
+} | {
+    kind: "other";
+} | {
+    kind: "unreadable";
+    found: string;
+};
+export declare function readVerdictKind(value: unknown): VerdictKindReading;
+/**
+ * WHERE A CORPUS WAS READ FROM, carried WITH the corpus and never assumed.
+ *
+ * THE MECHANISM THIS TYPE EXISTS TO CLOSE (M4-P11 fix round 1, CR-M4P11-001
+ * and CR-M4P11-002). One decision was assembled out of TWO SOURCES OF TRUTH:
+ * the declaration was read from the git object database by
+ * `readReviewFamilies`, and the corpus that is supposed to refute it was read
+ * from the WORKING TREE. Two sources means the two halves can be made to
+ * disagree, and the actor the check exists to guard against controls the half
+ * that is not committed.
+ *
+ * Measured by the reviewer at ONE commit, three arms, only the working tree
+ * changing: all verdicts present gave red exit 1; an UNCOMMITTED `rm` of the
+ * contradicting verdict gave not-applicable exit 20 with the exception
+ * GRANTED; copying the file back gave red again. `git ls-tree` listed the file
+ * throughout and `git show` still read `produced-by: family-b` from it. The
+ * declaration was tamper-EVIDENT and the evidence that refutes it was not.
+ *
+ * So the source is decided ONCE per load and travels with the result, and
+ * every sentence a check prints about a corpus ends with the source it was
+ * actually read from. A reader can tell a claim about a commit from a claim
+ * about somebody's working tree, which is SC-011 applied to the CORPUS rather
+ * than to a single check's verdict.
+ */
+export type VerdictCorpusSource = {
+    kind: "commit";
+    ref: string;
+    refSha: string;
+    scope: string;
+} | {
+    kind: "worktree";
+    reason: string;
+    scope: string;
+};
+/**
+ * The corpus, plus the source it was read from. Never one without the other.
+ *
+ * `unexaminable` IS M4-P10 FIX ROUND 2's CHANNEL, CARRIED ACROSS M4-P11's
+ * RESTRUCTURE RATHER THAN DROPPED. M4-P10 added it to the single filesystem
+ * loop this phase replaced with a commit arm and a worktree arm, and every
+ * caller seeds its violation list from it. A candidate that passed the
+ * extension filter and could not be read, did not decode, or declares a `kind`
+ * whose reading failed is NOT the determinate answer "not a verdict": it is
+ * "nobody knows whether this is a verdict", and dropping it SHRINKS the set the
+ * merge predicates reason over, which is the fail-open direction for a
+ * predicate that approves when the set is clean.
+ */
+export interface LoadedVerdictCorpus {
+    verdicts: LoadedVerdict[];
+    unexaminable: Diagnostic[];
+    source: VerdictCorpusSource;
+}
+/**
+ * How to name the set a check just looked at, in the check's own output.
+ *
+ * SC-011 one scope out: "every verdict this project has committed" and "every
+ * file that happens to be sitting in one directory right now" are different
+ * claims and must not print the same sentence. This renders a TRAILING
+ * parenthetical rather than a clause in the middle of one, so a sentence that
+ * already names its subject keeps its shape and gains a provenance tail.
+ */
+export declare function describeVerdictCorpusSource(source: VerdictCorpusSource): string;
+/**
+ * How to name the source ONE context document was looked for in.
+ *
+ * FIX ROUND 2, DV-001. The regime report line used to say "no charter.yaml"
+ * about a directory with a `charter.yaml` sitting in it, because the probe had
+ * moved to the commit and the sentence had not. A record that names a document
+ * and not the SOURCE it was looked for in is unfalsifiable by the person
+ * reading it, which is the same SC-011 property `describeVerdictCorpusSource`
+ * exists for one scope out.
+ */
+export declare function describeContextDocumentSource(source: VerdictCorpusSource): string;
+/**
+ * The verdict documents a PAIR decision is made over: `delivery/review/`.
+ *
+ * TWO ARMS, AND WHICH ONE RAN IS REPORTED RATHER THAN INFERRED.
+ *
+ * THE COMMIT ARM is taken whenever `<context>` resolves `ref`, and it reads
+ * the directory's entries out of the git object database. The filesystem is
+ * not consulted at all, so an uncommitted addition, deletion or edit cannot
+ * change what this returns. That is the anti-widening rule
+ * `readReviewFamilies` and `loadDeclaration` (src/gates/release.ts:817)
+ * already apply to a DECLARATION, now applied to the evidence beside it. It
+ * closes both directions of the same hole: an uncommitted DELETION can no
+ * longer remove a verdict that contradicts a declaration, and an uncommitted
+ * ADDITION can no longer manufacture the pair DR-0012 condition 2 requires.
+ *
+ * THE WORKTREE ARM is taken only when there is no resolvable ref, which is the
+ * pre-existing behaviour for a context that is not a git repository at all,
+ * and it SAYS SO in every sentence it produces. No exception can be granted on
+ * this arm, because `readReviewFamilies` resolves the same ref and returns
+ * absent or error when it cannot: with no git there is one source of truth and
+ * nothing to disagree.
+ *
+ * THE SCOPE STAYS `delivery/review/` HERE, and widening it was measured wrong.
+ * `headGroupFor` turns this set into the reviews of one `(phase, head)`, and
+ * five of the seven verdict documents in this repository's tree are fixtures
+ * for this check's own tests. See `PAPERWORK_ROOT` above; the widest set is
+ * what the FALSIFIERS use, and it is a different question.
+ *
+ * A file that does not carry `kind: verdict` is SKIPPED rather than reported,
+ * because that directory also holds this project's prose reviews and a check
+ * that reddened on a markdown file would be unusable. What is NOT skipped is
+ * the directory being unreadable, which the caller turns into a violation:
+ * "nothing to compare" and "could not look" are different facts.
+ *
+ * AND A CANDIDATE THAT COULD NOT BE LOOKED AT IS THE SECOND HALF OF THAT SAME
+ * SENTENCE, WHICH THE FIRST ROUND WROTE AND APPLIED AT ONE SITE ONLY. A
+ * `.yaml`, `.yml` or `.json` file here has passed the only filter that
+ * separates a candidate verdict from a prose review, so bytes that cannot be
+ * READ and bytes that do not DECODE are not "this is not a verdict", they are
+ * "nobody knows whether this is a verdict". Dropping such a file SHRINKS the
+ * set the merge predicates reason over, which is the fail-open direction for a
+ * predicate that approves when the set is clean: measured at the reviewed head,
+ * a third review reading FIX-ROUND-NEEDED with one malformed line left
+ * `verdict-pair-approves` printing that the pair approves. So they are returned
+ * as diagnostics and every caller seeds its violation list with them, exactly
+ * as `headGroupFor` already does for a sibling with no usable head.
+ */
+export declare function loadCommittedVerdicts(contextDirectory: string, source?: VerdictCorpusSource): ({
+    ok: true;
+} & LoadedVerdictCorpus) | {
+    ok: false;
+    reason: string;
+};
+/**
+ * Resolve, ONCE, the source every document of one decision is read from.
+ *
+ * EXPORTED because the two merge-precondition checks each resolve it at the
+ * top of their own run and hand the SAME value to the regime reader, the
+ * declaration reader and both corpus loaders. One resolution is what makes
+ * "the halves disagree" unrepresentable rather than merely unlikely.
+ */
+export declare function resolveCorpusSource(contextDirectory: string, ref?: string): VerdictCorpusSource;
+/**
+ * THE MECHANISM THIS SECTION CLOSES, STATED ONE LEVEL UP FROM THE FINDING:
+ * a gate whose verdict is about EVIDENCE THE CALLER SUPPLIED, with no check
+ * that the evidence is about the thing being audited.
+ *
+ * `headGroupFor` above groups by the head THE VERDICT DOCUMENTS THEMSELVES
+ * DECLARE. Before this section nothing compared that value to the commit the
+ * gate was running against, and nothing established that it named a commit at
+ * all. Both arms were reproduced end to end through the shipped script:
+ *
+ *   ARM A  two decorrelated APPROVE verdicts naming
+ *          deadbeefdeadbeefdeadbeefdeadbeefdeadbeef, which
+ *          `git cat-file -t` reports as not an object, in a repository whose
+ *          HEAD is a real commit          -> GREEN, 2 units, exit 0
+ *   ARM B  the same verdicts plus a further commit of work no verdict
+ *          mentions                       -> GREEN, exit 0
+ *
+ * So ONE committed approving pair turned this gate green for that phase at
+ * every later head, indefinitely, on evidence about one old commit. That is
+ * T-009's own rule ("a gate result is evidence only for the configuration it
+ * ran under") failing inside the gate that carries DR-0012's merge grant.
+ *
+ * THE ASYMMETRY THAT MAKES THE FIX SOUND, and it is the whole of the design.
+ * The AUDITED head comes from the CALLER: the gate runner passes `--head` from
+ * the pull-request event (the registry entry now declares `parameters: [head]`,
+ * the same mechanism `scope` has always used), and with no `--head` it is the
+ * commit the context's own `HEAD` resolves to, which is what the checkout put
+ * there. The DECLARED head comes from a document an agent under review wrote.
+ * One of those two is a fact about the run and the other is a claim in the
+ * evidence, and the claim must be measured against the fact rather than
+ * replacing it.
+ */
+/** Resolve one ref to a full commit sha inside a context directory. */
+export declare function resolveCommitIn(contextDirectory: string, ref: string): {
+    ok: true;
+    sha: string;
+} | {
+    ok: false;
+    reason: string;
+};
+/**
+ * The commit a merge gate's verdict is ABOUT.
+ *
+ * THREE OUTCOMES AND NOT TWO, for the same reason `RegimeOutcome` has three:
+ * "there is no commit to anchor to" and "the anchor could not be established"
+ * are different facts. `unanchored` is reached only on the WORKTREE arm with
+ * no `--head`, which is a context that is not a git repository at all, and
+ * every sentence built from it says so rather than implying an anchor that was
+ * never taken.
+ */
+export type AuditedHead = {
+    kind: "anchored";
+    head: string;
+    how: string;
+} | {
+    kind: "unanchored";
+    reason: string;
+} | {
+    kind: "error";
+    reason: string;
+};
+export declare function resolveAuditedHead(contextDirectory: string, requested: string | undefined, source: VerdictCorpusSource): AuditedHead;
+/**
+ * THE MECHANISM THIS SECTION CLOSES, and it is the anchor above written one
+ * relation too narrow: AN ANCHOR EXPRESSED AS EQUALITY WHERE THE RELATION THAT
+ * CAN ACTUALLY HOLD IS ANCESTRY PLUS A CONSTRAINT ON WHAT CHANGED IN BETWEEN.
+ *
+ * `partitionByAuditedHead` compared the declared head to the audited one with
+ * `===`, and no real flow can satisfy that. A reviewer reads commit X and
+ * writes a verdict naming X; COMMITTING that verdict produces X+1; CI audits
+ * X+1, or a merge commit above it. The declared head is therefore ALWAYS a
+ * strict ancestor of the audited one, so under equality every real run reported
+ * not-applicable. Measured on the branch that introduced the anchor, at
+ * 5867a918cda809f7c5d4bc366fc7940458c140c0: the verdicts declared that commit,
+ * the gate audited its DIRECT CHILD 0ddd06a73d49c1910449d01303bc9c2579f5f492,
+ * and the record read not-applicable, exit 21, "is a review of other work and
+ * is not evidence about this head".
+ *
+ * That is the same cannot-do-its-job shape one status along from the defect the
+ * anchor fixed: "green forever once fed" became "never green", and a gate that
+ * cannot go green is as uninformative as one that cannot go red (T-008's own
+ * rule, applied to the other pole).
+ *
+ * WHAT MAKES THE RELAXATION SAFE, AND IT IS THE WHOLE DESIGN. Ancestry ALONE
+ * would restore the original defect wearing a different hat: an approving pair
+ * lands, and every later descendant carries it, including descendants full of
+ * unreviewed source. So ancestry is admitted only when the TREES agree
+ * everywhere except the project's own paperwork root. A verdict is evidence
+ * about the SHIPPED CONTENT it read, and if that content is byte-identical in
+ * the audited commit then the audited commit is the thing the reviewer
+ * approved, whatever paperwork was committed on top of it.
+ *
+ * IT IS A CLAIM ABOUT THE TWO TREES, NOT ABOUT EACH INTERVENING COMMIT, and
+ * the difference is stated rather than left to be discovered. `git diff
+ * --name-only <declared>..<audited>` compares the endpoints, so a commit that
+ * adds `src/x.ts` and a later one that removes it leave no entry and are
+ * admitted, where a per-commit enumeration would refuse them. That case is
+ * admitted DELIBERATELY: the audited tree's shipped content is then exactly
+ * what the reviewers read, which is the property the gate is protecting. A
+ * per-commit walk would refuse an ordinary revert-before-merge and buy nothing,
+ * because there is no shipped byte in the audited tree that no verdict covers.
+ *
+ * `--no-renames` IS LOAD-BEARING. With rename detection on (git's default for
+ * `git diff` since 2.9) a rename from `src/a.ts` to `delivery/b.md` prints the
+ * DESTINATION ONLY, so the deletion of a source file would be invisible and the
+ * gap would read as paperwork. Disabling it prints both sides.
+ */
+/** How a verdict's declared head stands to the commit under audit. */
+export type HeadRelation = 
+/** The verdict names the audited commit itself. */
+{
+    kind: "same";
+}
+/** A strict ancestor whose gap to the audited commit is paperwork only. */
+ | {
+    kind: "evidence-only-ancestor";
+    changed: string[];
+}
+/** A strict ancestor, but shipped content changed in between. */
+ | {
+    kind: "shipped-change";
+    shipped: string[];
+}
+/** A real commit here that the audited commit is an ancestor OF. */
+ | {
+    kind: "descendant";
+}
+/** A real commit here on neither side of the audited one. */
+ | {
+    kind: "unrelated";
+}
+/** Forty hex digits naming no commit in this repository. */
+ | {
+    kind: "unresolvable";
+    reason: string;
+}
+/** git could not answer, so the relation is not known. Never admitted. */
+ | {
+    kind: "undetermined";
+    reason: string;
+};
+/**
+ * Place one declared head against the commit under audit.
+ *
+ * EQUAL PASSES, unchanged, and it is checked first so a context git cannot be
+ * questioned about still answers the one relation that needs no git at all.
+ *
+ * A DESCENDANT IS REFUSED, and it has its own sentence rather than being folded
+ * into "not an ancestor". A verdict naming a commit BELOW the audited one is a
+ * review of work the audited commit does not contain, which is the fail-open
+ * direction stated backwards: the reviewers saw more than is being merged, and
+ * nothing here establishes that what they approved about the extra work says
+ * anything about the tree without it.
+ */
+export declare function relateDeclaredHead(contextDirectory: string, declared: string, auditedHead: string): HeadRelation;
+/** A verdict admitted to the audited corpus, and the relation that admitted it. */
+export interface AdmittedVerdict {
+    path: string;
+    declared: string;
+    relation: HeadRelation;
+}
+/** One verdict that is not about the audited commit, and why it is not. */
+export interface OffHeadVerdict {
+    path: string;
+    declared: string;
+    /** Which route refused it. Printed, never summarised to a boolean. */
+    relation: HeadRelation;
+}
+/** The corpus split by the commit under audit. */
+export interface HeadPartition {
+    onHead: LoadedVerdict[];
+    /**
+     * The same verdicts, with the relation that admitted each one.
+     *
+     * CARRIED SEPARATELY RATHER THAN ATTACHED TO `onHead`, because `onHead` is
+     * the set the checks are RUN OVER and its element type is what every other
+     * caller of the loader consumes. This is the DISCLOSURE half: a green reached
+     * through ancestry and a green reached through equality are different facts,
+     * and a gate that printed one sentence for both would be the unfalsifiable
+     * record `describeVerdictCorpusSource` exists to stop, one relation along.
+     */
+    admitted: AdmittedVerdict[];
+    offHead: OffHeadVerdict[];
+    /**
+     * Verdicts whose own `head` could not be established at all, as DOCUMENTS
+     * and as the sentences that name them.
+     *
+     * BOTH SHAPES, because the two callers need different halves and deriving one
+     * from the other by matching on a message prefix is the string-parsing shape
+     * this file refuses everywhere else. A caller that keeps them in the corpus
+     * needs the documents; a caller that reports them needs the sentences.
+     */
+    unkeyed: Diagnostic[];
+    unkeyedVerdicts: LoadedVerdict[];
+}
+/**
+ * Split a loaded corpus into the verdicts that are about the audited commit
+ * and the ones that are not.
+ *
+ * FIVE REFUSAL ROUTES, AND THEY ARE STRUCTURALLY DIFFERENT RATHER THAN ONE
+ * SHAPE FIVE TIMES, which is what makes them members of a class instead of
+ * instances of a finding:
+ *
+ *   RESOLUTION   the declared head is not a commit in this repository. The
+ *                document is evidence about an object nobody can produce.
+ *   SHIPPED GAP  the declared head IS an ancestor, and shipped content changed
+ *                between it and the audited commit. Unreviewed work is riding
+ *                in on a review of something else.
+ *   DESCENDANT   the declared head is BELOW the audited commit. The reviewers
+ *                read a tree the audited commit does not contain.
+ *   UNRELATED    a real commit on neither side. A review of another line.
+ *   UNDETERMINED git could not place it. Never admitted, because a relation
+ *                nobody established must not read as the one that passes.
+ *
+ * ADMISSION IS TWO ROUTES AND THEY ARE ALSO PRINTED: the declared head IS the
+ * audited commit, or it is an ancestor whose whole gap is paperwork. See
+ * `relateDeclaredHead` for why the second is safe and for what it deliberately
+ * does not refuse.
+ *
+ * Every refusal leaves the verdict out of the audited group and IS PRINTED with
+ * the route it took, because a document silently dropped from a merge
+ * corpus is the fail-open direction this file has already been bitten by at
+ * `loadCommittedVerdicts`, at the `phase` canonicalisation and at
+ * `headGroupFor`. A reader is owed the fact that the corpus holds two
+ * approving reviews of something else.
+ */
+export declare function partitionByAuditedHead(contextDirectory: string, verdicts: readonly LoadedVerdict[], auditedHead: string): HeadPartition;
+/** One operator-facing line per verdict the audit excluded, naming its route. */
+export declare function describeOffHeadVerdicts(offHead: readonly OffHeadVerdict[], auditedHead: string): string[];
+/** One operator-facing line per verdict the audit ADMITTED, naming its route. */
+export declare function describeAdmittedVerdicts(admitted: readonly AdmittedVerdict[], auditedHead: string): string[];
+/** The charter field DR-0038's declaration lives in (M4-D-28). */
+export declare const REVIEW_FAMILIES_FIELD = "review-families";
+/** The document that carries it. */
+export declare const CHARTER_DOCUMENT = "charter.yaml";
+/**
+ * The documents that say WHICH merge-authority regime is in force.
+ *
+ * MOVED HERE FROM `scripts/check-dual-review.mjs` (FIX ROUND 2, DV-001). The
+ * script held its own copy of this list AND its own presence probe, and the
+ * probe read the WORKING TREE while `establishDelegatedRegime` read the
+ * COMMIT. Two probes of one fact against two sources is the mechanism this
+ * phase has now paid for twice: each answered correctly about its own source,
+ * so nothing ever reported a disagreement, and an uncommitted `charter.yaml`
+ * took the gate from error to GREEN on a correlated committed pair.
+ */
+export declare const REGIME_DOCUMENTS: string[];
+/**
+ * The first regime document that is NOT present at the source a decision over
+ * this context would be made from, or `undefined` when both are.
+ *
+ * WHY THE REFUSAL LIVES AT THE MERGE GATE AND THE REPORT LIVES IN THE CHECK,
+ * unchanged from M3-P9 and restated because this round moved the probe: the
+ * derived check runs on ANY verdict with ANY context, and M3-P7's verdict
+ * contexts carry a plan and a work history and no charter, so a check that
+ * reddened on an absent charter reddened eight of that phase's tests. The
+ * check therefore REPORTS, and `scripts/check-dual-review.mjs`, which is the
+ * command DR-0012's grant runs through, refuses. What changed is that the
+ * refusal and the report are now ONE probe with two callers, so they cannot
+ * answer about different sources.
+ *
+ * THE SOURCE IS A PARAMETER, not resolved here, so a caller that has already
+ * resolved one (the gate script resolves it when it loads the corpus) refuses
+ * against the SAME commit it read the verdicts from rather than a second
+ * `rev-parse` that could land elsewhere.
+ */
+export declare function missingRegimeDocument(contextDirectory: string, source?: VerdictCorpusSource): {
+    document: string;
+    source: VerdictCorpusSource;
+    reason: string;
+} | undefined;
+/**
+ * Where a declaration was read from, so a claim nobody can refute is at least
+ * ATTRIBUTABLE AND DATED.
+ *
+ * This is the honest half of DR-0038's third constraint. Two falsifiers below
+ * catch a project whose own record contradicts the declaration. NEITHER of
+ * them catches a project that HAS a second family available and has simply
+ * never used it, and nothing inside the record can: the record holds what was
+ * used, not what was reachable. So the countermeasure for that residue is
+ * provenance rather than detection, on the src/gates/release.ts:1028 pattern,
+ * and the gap is stated here rather than left to be found.
+ */
+export interface ReviewFamiliesProvenance {
+    /** The path inside the commit, as `git show` was asked for it. */
+    path: string;
+    /** The ref the declaration was read from, as the caller spelled it. */
+    ref: string;
+    /** That ref resolved to a commit sha. */
+    refSha: string;
+    /** sha256 of the exact blob bytes the declaration was decoded from. */
+    sha256: string;
+}
+/**
+ * What reading `review-families` produced.
+ *
+ * THREE OUTCOMES AND NOT TWO, for the reason `RegimeOutcome` gives one screen
+ * up: "no declaration" and "a declaration that could not be established" are
+ * different facts. The first leaves DR-0012 condition 1 applying unchanged,
+ * which is a REPORT-nothing. The second is an ERROR, because a check that
+ * cannot establish whether an exception applies must never decide that it does
+ * not apply and carry on (M2-C-3).
+ */
+export type ReviewFamiliesReading = {
+    kind: "absent";
+} | {
+    kind: "error";
+    reason: string;
+} | {
+    kind: "declared";
+    /** Canonicalised, deduplicated by construction, sorted. Compared. */
+    families: string[];
+    /** The operator's own spelling, in document order. Printed. */
+    declaredAs: string[];
+    reason: string;
+    provenance: ReviewFamiliesProvenance;
+};
+/**
+ * Read DR-0038's declaration OUT OF THE GIT OBJECT DATABASE, never out of the
+ * working tree.
+ *
+ * WHY THE COMMITTED BLOB IS THE ONLY ONE THAT COUNTS. This is the anti-widening
+ * rule the scope auditor and `loadDeclaration` (src/gates/release.ts:817) both
+ * already apply, one condition along: a phase must not be able to switch off,
+ * inside its own working tree, the condition that would otherwise have refused
+ * its merge. A declaration read from disk is one an implementer can add,
+ * merge under, and delete, leaving a merged head whose record says the
+ * cross-family requirement was met.
+ *
+ * `HEAD:./charter.yaml` AND NOT `HEAD:charter.yaml`, and the difference is not
+ * cosmetic. A path without the leading `./` is resolved against the repository
+ * ROOT, so a context directory that happens to sit inside a larger repository
+ * (which every fixture staged under a checkout does) would silently read that
+ * repository's charter instead of its own. With `./` git resolves relative to
+ * the directory it was run in, which is the one the caller named.
+ */
+export declare function readReviewFamilies(contextDirectory: string, ref?: string): ReviewFamiliesReading;
+/** One line naming where a declaration came from, for a detail or a report. */
+export declare function reviewFamiliesProvenanceLine(provenance: ReviewFamiliesProvenance): string;
+/** What the single-family arm concluded about one committed corpus. */
+export type SingleFamilyOutcome = {
+    kind: "not-declared";
+} | {
+    kind: "error";
+    reason: string;
+} | {
+    kind: "refused";
+    violations: Diagnostic[];
+} | {
+    kind: "exempt";
+    family: string;
+    reading: Extract<ReviewFamiliesReading, {
+        kind: "declared";
+    }>;
+    reports: string[];
+};
+/**
+ * DR-0038's exception, and its two falsifiers, over one committed corpus.
+ *
+ * THE EXCEPTION NARROWS EXACTLY ONE DIMENSION. `produced-by` stops being
+ * required to differ. `framing` and `review-contract` are untouched, because
+ * T-007's whole finding is that model decorrelation and CONTRACT decorrelation
+ * are different properties: a single-family environment still has two framings
+ * and two contracts available to it, so relaxing those would be relaxing
+ * something the environment does not force.
+ *
+ * FALSIFIER 1, CONTRADICTION BY THE CORPUS. If the project's own committed
+ * verdicts carry two or more distinct canonicalised `produced-by` values, the
+ * declaration is contradicted by the project's own record and this is RED. A
+ * project that has demonstrably used two cannot claim one.
+ *
+ * FALSIFIER 2, THE NAME MUST MATCH. A verdict whose `produced-by` canonicalises
+ * to anything other than the declared family is RED. Without this, a
+ * declaration could name a family nothing in the record uses and still buy the
+ * relaxation.
+ *
+ * THE SCOPE IS THE WHOLE COMMITTED CORPUS, NOT THE ONE (phase, head) GROUP,
+ * and that is deliberate. "This project has one family available" is a claim
+ * about the project, so the widest set of its own verdicts is what can refute
+ * it. Scoping the falsifiers to the group under review would let a project
+ * whose history carries three families declare one, provided the two reviews
+ * in front of the check happened to agree.
+ *
+ * WHAT IT DOES NOT CATCH, said here and not only in the plan: a project with a
+ * second family AVAILABLE that has simply never used it. Nothing in a record of
+ * what WAS used reaches what COULD have been used. `readReviewFamilies` answers
+ * that with provenance rather than detection: the claim is attributable to a
+ * commit and a blob, so it is dated and signed even where it is not refutable.
+ */
+export declare function singleFamilyException(contextDirectory: string, loaded: LoadedVerdictCorpus): SingleFamilyOutcome;
+/**
+ * DR-0012's merge precondition, made into a comparison a command can make
+ * against the verdict FILES rather than against a session's memory (M3R-004).
+ *
+ * WHY THIS IS KIND B AND COULD NOT BE A KEYWORD. Every dimension it compares
+ * lives in a DIFFERENT DOCUMENT from the instance: distinctness is a property
+ * of a PAIR of verdicts, and no keyword under any DR-0013 option can see the
+ * sibling.
+ *
+ * IT ESTABLISHES PRESENCE ITSELF AND DOES NOT BORROW IT FROM THE SCHEMA. An
+ * earlier version of this comment said the verdict schema's `required` buys
+ * absence-freedom, so this check only had to decide difference. That division of
+ * labour was never composed: nothing on the shipped path validates the SIBLING
+ * documents, so a document with `kind: verdict` and a missing required field is
+ * loaded here and compared. The rule the whole section now follows is
+ * `establishField`, one screen up: a value is not comparable until it has been
+ * established, and absence, unusability and difference are three verdicts, not
+ * one.
+ *
+ * IT APPLIES EXACTLY WHERE THE GRANT APPLIES. The regime is read from the
+ * declared mode, not assumed: `charter.yaml` names the delivery mode and
+ * `assurance-modes.yaml` says what that mode's `merge-authority` is. A mode
+ * whose authority is not a delegated grant has no decorrelation precondition to
+ * satisfy, and this check REPORTS that rather than passing silently, because
+ * "nothing to check here" and "everything checked and fine" must never print
+ * the same line (SC-011).
+ *
+ * FIVE DIMENSIONS, AND (e) IS NOT A REFINEMENT OF (b). T-007's whole finding is
+ * that model decorrelation and CONTRACT decorrelation are different properties
+ * and this project had the second by accident: two reviewers on different model
+ * families walked all fifteen criteria of one phase, agreed on every mechanical
+ * fact, and one missed a high-severity defect because both had been given the
+ * criteria contract. So `review-contract` is compared separately and is
+ * witnessed separately (criterion 7b).
+ *
+ * WHAT IT DOES NOT REACH, named rather than left to be found, AND BOTH ITEMS
+ * THIS PARAGRAPH USED TO NAME HAVE BEEN CLOSED BY M4-P10. The first was
+ * condition (d) of step 3b, that neither verdict carries an unresolved high or
+ * medium finding; that is now the sibling check `verdict-pair-approves`, and
+ * the schema's own root `if`/`then` was widened from [high, critical] to
+ * [medium, high, critical] at the same time, because it had been one severity
+ * narrower than DR-0012 condition 2 ever since it shipped. The second was that
+ * nothing decided whether two verdicts describe the same HEAD; the schema now
+ * requires `head` and this check groups by `(phase, head)`.
+ *
+ * WHAT IS STILL NOT REACHED, so the paragraph does not read as complete. This
+ * check compares `produced-by` as a canonicalised STRING, never as a model
+ * FAMILY, so two values naming one vendor pass as decorrelated; that was
+ * measured twice against this repository's own reviews and recorded at
+ * delivery/verification/m4-prototype-probes.md:1. THE DEFERRAL CHAIN FOR IT
+ * TERMINATED WITH NO OWNER, which is what CR-VS-003 found and what this
+ * paragraph used to hide: it said "closing it is M4-P11's declared scope", and
+ * M4-P11 declined the mechanism (delivery/work-history/m4-p11.md:142) and
+ * shipped the single-family EXCEPTION instead, which is a different question.
+ * No later phase picked it up. The string comparison therefore STANDS, and what
+ * the DR-0047 sweep changed is that the green line now says so: see
+ * `producedByCaveat`, which also names what would close it. And a
+ * `produced-by` line is written BY the reviewing agent, so it is forgeable; an
+ * observed alternative exists and is M4-D-06's business, not this check's.
+ */
+export declare const dualReviewDecorrelation: DerivedCheck;
+/**
+ * The severities DR-0012 condition 2 bars an APPROVE from sitting beside.
+ *
+ * `low` is absent DELIBERATELY and the record says why:
+ * delivery/decisions/DR-0012-delegated-merge-authority.md:23 permits merging
+ * with a low finding provided it is fixed or tracked with a reason. The same
+ * three words are the escalation enum in `schemas/verdict.schema.json`, and the
+ * two must agree; M4-P10 widened both together, because the shipped pair had
+ * the schema stopping at `high` while the decision said `medium`.
+ */
+export declare const BLOCKING_SEVERITIES: readonly string[];
+/**
+ * DR-0012 CONDITION 2, MADE INTO A PREDICATE
+ * (delivery/decisions/DR-0012-delegated-merge-authority.md:23).
+ *
+ * WHAT WAS MISSING, stated as the gap rather than as a feature. Before this
+ * check, `scripts/check-dual-review.mjs` could not see a verdict's VALUE at
+ * all: measured against the whole of that script, `grep -c` returned 0 for
+ * `APPROVE`, 0 for `severity` and 0 for `findings`. So two properly
+ * decorrelated reviews that both REFUSED the merge passed the gate green, and
+ * so did an APPROVE sitting beside a finding the review itself ranked medium.
+ * Condition 1 looked checked and condition 2 was asserted by a human, which is
+ * the worse of the two states because it reads as progress.
+ *
+ * WHY IT IS A SEPARATE CHECK RATHER THAN MORE OF `dual-review-decorrelation`.
+ * They are different predicates over the same set, and section 2.3 rule 3's
+ * Kind B falsification is per-check: DEREGISTERING this one must make a
+ * refusing pair pass, which is only a witness if there is one id to deregister.
+ * Folding condition 2 into the decorrelation check would have made that
+ * witness unavailable and would have made one red indistinguishable from the
+ * other in the gate's output.
+ *
+ * WHY IT EVALUATES THE COMMITTED GROUP AND NEVER THE INSTANCE'S OWN FIELDS,
+ * which is the one place its shape differs from its sibling's. DR-0012
+ * condition 2 is a property of the two reviews WRITTEN TO `delivery/review/`
+ * AND COMMITTED. A document handed to this check that is not among them is not
+ * a review the grant can be satisfied by, and it also cannot break the
+ * predicate: what is asserted is about the committed set, which the stray
+ * document is not a member of. So there is no membership test here, and the
+ * empty case is not a hole: a `(phase, head)` selecting fewer than two
+ * committed verdicts is refused by the pair-size rule below.
+ *
+ * WHAT IT DOES NOT REACH, named rather than left to be found. "Unresolved" is
+ * a state of the review THREAD, and this check reads documents: a finding that
+ * was raised, fixed in a later round and left in the file still reddens here.
+ * That is the fail-closed direction and it is a real cost, paid deliberately,
+ * because the alternative is a resolution field an author sets on their own
+ * finding. Nothing here decides whether a `severity` was ranked honestly
+ * either; a review that calls a critical defect `low` passes, and no keyword
+ * reaches that.
+ */
+export declare const verdictPairApproves: DerivedCheck;
+/**
+ * THE SUBJECT ECHO AGREES WITH THE RESOLUTION IT SITS BESIDE, THE RECORD WAS
+ * WRITTEN AFTER THE TURN ENDED, AND AN OVERRIDE WAS PERMITTED BEFORE IT WAS
+ * APPLIED.
+ *
+ * All three compare SIBLING FIELDS of one document, so all three are Kind B
+ * and none of them is reachable from a keyword (schemas/README.md's Kind A and
+ * Kind B section, DR-0013 clause 8). The schema next door can require that
+ * `subject`, `turnEnd` and `resolution` are all PRESENT, which is what makes a
+ * launch-time record unrepresentable, and it stops exactly there: it cannot
+ * say that two present values agree.
+ *
+ * WHY THE ECHO MATTERS AT ALL, since a record that echoes itself sounds
+ * circular. It is not the record checking itself against itself. `subject` is
+ * a VERBATIM copy of the launch request the adapter was handed and
+ * `resolution` is what the adapter's resolver actually consumed, and the
+ * hazard is that those two diverge silently: a resolver that read the wrong
+ * role's row produces a perfectly well-formed record whose family token is
+ * then attributed to a task it was never about. That is the misattribution
+ * guard src/gates/schemas/release-record.schema.json:26 exists for, one seam
+ * along, and the kernel-side half of it is in src/model-resolution.ts where
+ * the request is compared against a copy the kernel itself holds.
+ *
+ * THE OVERRIDE DIRECTION IS THE ONE MOST LIKELY TO BE GOT WRONG. M4-P7
+ * criterion 7 wants BOTH directions: a role whose `charter-override` is
+ * `allowed` takes the charter's tier, and a role whose permission is anything
+ * else does not. The second direction is the one a resolver written from the
+ * happy path silently drops, because nothing about it looks like a failure.
+ */
+export declare const modelResolutionSubjectEcho: DerivedCheck;
+/** Register a check. Later phases append their own (section 2.3's table). */
+export declare function registerCheck(check: DerivedCheck): void;
+/** Remove a check by id. Returns whether one was removed. */
+export declare function deregisterCheck(id: string): boolean;
+/** Every check registered for an artifact type, in stable id order. */
+export declare function checksFor(type: string): DerivedCheck[];
+/** Every registered check, in registration order. Read by the enumeration. */
+export declare function registeredChecks(): readonly DerivedCheck[];
+/** The outcome of running every check registered for a type. */
+export interface ChecksRun {
+    /** Lines to print, in the order they should appear. */
+    lines: string[];
+    /** True when at least one check violated or was skipped for want of context. */
+    failed: boolean;
+}
+/**
+ * Run every registered check for `type`.
+ *
+ * A check whose `requiresContext` is true and which was given none is
+ * SKIPPED and the run FAILS. It is deliberately not an ordinary violation:
+ * "this rule did not run" and "this rule found a problem" are different
+ * facts and a reader must be able to tell them apart, but both are reasons
+ * not to trust a green.
+ */
+export declare function runChecks(type: string, instance: unknown, contextDirectory: string | undefined): ChecksRun;