feat(p19): a direction must NAME the requirement that binds it, and have READ it

Two paid rounds scored 0 of 26 fasit concepts opened -- the same number twice.
P18 closed the navigation side (a listing is a window, an invented path is
refused by name) and it did not move, which makes it a ROLE question: nothing
in the loop ever asked the model to say what requirement binds the direction it
committed to, so opening one was never on the critical path to an answer.

A PREMISE OF THE ORDER WAS FELLED BEFORE ANYTHING WAS BUILT ON IT. A1 places
the demand in _INSTRUCTIONS[HYPOTHESISER_ROLE] alone. Measured: the stress
command sends --mandate and NOT --explore, the two are refused together by
name, and none of the nine round-1/2 outboxes holds a {run_id}-exploration.json
-- the hypothesiser never runs in a stress round, so A3 would have been
unreachable in exactly the paid runs this order commissions.

A2's own sentence resolves it: the refusal goes to the model "som en tur den
kan rette (samme mekanisme som quick_validate's nekt), ikke som en raise" --
and quick_validate IS a tool. declare_requirement therefore lives in
navigator_tools, held by BOTH roles that navigate (the exploration, and since
S2c the debate). It EXISTS only when the caller offers both sinks, which keeps
every pre-P19 call site byte-identical; one sink without the other is refused
at construction. 'opened' is the SAME list ExplorationToolRecorder fills, so
the refusal reads the run's own read trace.

The marked hypothesis carries 'requirement' as a REQUIRED key: omitted is a
hard error, explicit null is legal and needs 'why_none', a half-named one is
refused. A minted approach carries it; a seed never acquires one. The proposer
prompt names it only when the field exists, and the judge counts a hit against
THIS approach's fasit concepts, never against the base.

Load-bearing measured (12 arms), four mutations all red against the whole
suite, green control 1711/5 and demo-transcript.stdout byte-unchanged.
A-iii's predicted signature was FALSIFIED: the golden stays green because the
demo runs without a mandate, so _build_messages' approach branch is never
taken there. A-iv was GREEN first -- the repo's vacuous-gate class, 24th time:
the arm drove _attributable while the hit is computed at the call site.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -460,6 +460,18 @@ when the seam is detached, so the loop cannot silently degrade into theater.
   None of them has a default, because an omitted cap falls back to an *unbounded* loop rather than
   a conservative one.
 
+  **Naming the requirement that binds a direction.** Whoever navigates a knowledge base — the
+  exploration's hypothesiser and, since the debate started navigating, the proposer — is asked to
+  name the ONE requirement that binds the direction it commits to, and to declare it with
+  `declare_requirement(bundle_id, path, ref)` after reading it. A declaration naming a document
+  the run never opened is **refused by name** (`RequirementNotRead`) and comes back as a turn the
+  model can correct by going and reading it; nothing is recorded until it has. A marked hypothesis
+  therefore carries `"requirement": {"path": ..., "ref": ...}`, or an explicit `null` together with
+  `"why_none"` — a base that holds no requirement for a direction is a finding worth stating, and
+  the field is never simply omitted. Where an approach carries one, the proposer's prompt names it
+  and asks for it back verbatim in `measure`, and the declaration is written to
+  `{run_id}-debate.json` / `{run_id}-exploration.json` under `requirements`.
+
   **Answering the plan review (`--plan-review`).** With `enable_plan_review` set, the exploration
   stops before the loop is allowed to run and asks you to sign the plan off. `--plan-review`
   answers it *at your terminal*: you are shown the plan, and you type `approve` or