@@ -19,6 +19,12 @@
 
 # Exercise the default-OFF dual-leaf identity/desynchronisation
 # regression guard in an explicit opt-in matrix leg.
+# It also carries `tests/dual_leaf_v2_noir_pin.rs` (same `dual-leaf` feature):
+# the host/circuit pin tying every `global` in zk/dual-leaf-v2/src/lib.nr to its
+# `dual_leaf_v2` host derivation. The Noir half of that mirror runs as `nargo test`
+# in `.github/workflows/zk-toolchain.yml`; this leg is where the HOST half runs, so
+# the two cannot drift apart unnoticed. The leg NAME is unchanged, so
+# scripts/tests/feature-matrix-legnames.golden.txt is untouched.
 - name: "sparq-zk (dual-leaf — identity/desync regression guard)"
   crate: "sparq-zk"
   features: "dual-leaf"
 
@@ -66,8 +66,12 @@ on:
       # sq-5reoy: narrowed from zk/** to zk/compose/** — the zk/ieee754 and
       # zk/xpath trees were externalized to the sparq-org/noir_IEEE754 and
       # sparq-org/noir_XPath face repos (#1599), whose own CI covers their nargo tests
-      # and the ieee754 differential oracle. zk/compose is the only in-tree Noir tree left.
+      # and the ieee754 differential oracle. zk/compose is the only in-tree Noir tree that
+# PROVES anything; zk/dual-leaf-v2 (the DualLeafV2 sentinel/constants mirror, no deps,
+# imported by no member) is the one other in-tree Noir package and runs its nargo tests
+# in this lane too.
       - "zk/compose/**"
+      - "zk/dual-leaf-v2/**"
       - "bench/zk-compose/campaigns/**"
       - "bench/zk-bindings/**"
       - "crates/sparq-conformance/examples/proof_corpus.rs"
@@ -88,6 +92,7 @@ on:
       # sq-5reoy: narrowed from zk/** to zk/compose/** (see the pull_request
       # paths note above — the ieee754/xpath trees moved to their face repos, #1599).
       - "zk/compose/**"
+      - "zk/dual-leaf-v2/**"
       - "bench/zk-compose/campaigns/**"
       - "bench/zk-bindings/**"
       - "crates/sparq-conformance/examples/proof_corpus.rs"
@@ -391,6 +396,17 @@ jobs:
         working-directory: zk/compose
         run: nargo test --package sparq_zk_compose_core
 
+      # The DualLeafV2 sentinel/constants mirror (zk/dual-leaf-v2). A separate Nargo
+      # package on purpose: every *.nr under zk/compose is sha256-pinned by the
+      # bench/zk-compose measurement evidence, whose verifier requires the measured
+      # inventory to equal the tree EXACTLY (verify_result_evidence.py), so a new file
+      # there would invalidate a measurement that only dedicated hardware can redo.
+      # Dependency-free, imported by no member: compile + execute only, seconds.
+      - name: Run the DualLeafV2 constants-mirror Noir tests (nargo test)
+        if: steps.changes.outputs.zk == 'true'
+        working-directory: zk/dual-leaf-v2
+        run: nargo test
+
       # The load-bearing step: run EVERY `#[ignore]`d test in the ZK crates. With the
       # toolchain on PATH the forge tests do a REAL bb prove and assert every forgery is
       # REJECTED (and the positive controls verify); the empirical bb anchors re-validate
 
@@ -189,7 +189,7 @@ A `zk/compose/` **member** is a `bin`-type Noir package directory under `zk/comp
 2. **Run the Rust gate locally:** `cargo nextest run -p sparq-zk-compose` (NOT just `nargo test`). `snapshot_covers_every_member` runs WITHOUT the `nargo`/`bb` toolchain — it only reads the `zk/compose/` directory names against the snapshot — so this step catches a missing baseline even on a box without the ZK toolchain. The `gate_count_regression` bloat check additionally needs `nargo`+`bb` (it skips cleanly when absent).
 
 This is **Gate G5** territory for top-level `zk/` `bin` circuits (`snapshot_covers_top_level_circuits`); the `zk/compose/`-family coverage is enforced by `snapshot_covers_every_member` in the same test file.
-**Externalized Noir dependencies (sq-5reoy / #1599).** The former in-tree `zk/ieee754` and `zk/xpath` trees were split out to the [`sparq-org/noir_IEEE754`](https://github.com/sparq-org/noir_IEEE754) and [`sparq-org/noir_XPath`](https://github.com/sparq-org/noir_XPath) face repos and removed from this repo. Their latest releases are **`v0.11.0`** (noir_IEEE754) and **`v0.3.0`** (noir_XPath, cut 2026-07-06 — see `research/zk-audit-readiness-dossier.md` §1.3). Those are the face repos' own release trains and are NOT automatically what this repo consumes: `zk/compose` pins `sparq_ieee754 @ v0.11.0`, and the XPath differential harness pins `XPATH_TAG: "v0.3.0"` (`.github/workflows/xpath-differential.yml`, `zk/xpath/scripts/run_differential_harness.sh` — bumped off v0.2.0 by #5456, so that lane's evidence is now about the current release) — read the pin, not this note, when you need to know what a lane actually verifies. `zk/compose` is the only in-tree Noir tree left; `zk/compose/compose_core/Nargo.toml` now consumes `sparq_ieee754` as a **pinned Nargo git dependency** (`{ git = "…/noir_IEEE754", tag = "v0.11.0" }`), exactly like its existing `poseidon` git dep. Two consequences for agents: (1) any `nargo compile` of `zk/compose` (the forge suite, `bench/zk-compose/scripts/gate_counts.sh`, the `sparq-zk-compose` test estate) now **fetches that git dep from GitHub** — a cold `~/.nargo` cache needs network access; a network-restricted runner must warm `~/.nargo` first. (2) **Toolchain-pin drift:** the `NARGO_VERSION`/`BB_VERSION` pins in `zk-toolchain.yml` and the face repos' pins are now maintained independently — when you bump the Noir toolchain here, confirm the released `sparq_ieee754` tag was cut on a compatible `nargo` (and re-run the forge suite, which compiles the git dep). Their nargo tests + the ieee754 differential oracle now run in the face repos' own CI, not in `zk-toolchain.yml`.
+**Externalized Noir dependencies (sq-5reoy / #1599).** The former in-tree `zk/ieee754` and `zk/xpath` trees were split out to the [`sparq-org/noir_IEEE754`](https://github.com/sparq-org/noir_IEEE754) and [`sparq-org/noir_XPath`](https://github.com/sparq-org/noir_XPath) face repos and removed from this repo. Their latest releases are **`v0.11.0`** (noir_IEEE754) and **`v0.3.0`** (noir_XPath, cut 2026-07-06 — see `research/zk-audit-readiness-dossier.md` §1.3). Those are the face repos' own release trains and are NOT automatically what this repo consumes: `zk/compose` pins `sparq_ieee754 @ v0.11.0`, and the XPath differential harness pins `XPATH_TAG: "v0.3.0"` (`.github/workflows/xpath-differential.yml`, `zk/xpath/scripts/run_differential_harness.sh` — bumped off v0.2.0 by #5456, so that lane's evidence is now about the current release) — read the pin, not this note, when you need to know what a lane actually verifies. `zk/compose` is the only in-tree Noir tree that PROVES anything (the one other in-tree Noir package, `zk/dual-leaf-v2`, is a dependency-free constants + assertions library mirroring the `DualLeafV2` host sentinel, run by `nargo test` in the same lane and imported by no member); `zk/compose/compose_core/Nargo.toml` now consumes `sparq_ieee754` as a **pinned Nargo git dependency** (`{ git = "…/noir_IEEE754", tag = "v0.11.0" }`), exactly like its existing `poseidon` git dep. Two consequences for agents: (1) any `nargo compile` of `zk/compose` (the forge suite, `bench/zk-compose/scripts/gate_counts.sh`, the `sparq-zk-compose` test estate) now **fetches that git dep from GitHub** — a cold `~/.nargo` cache needs network access; a network-restricted runner must warm `~/.nargo` first. (2) **Toolchain-pin drift:** the `NARGO_VERSION`/`BB_VERSION` pins in `zk-toolchain.yml` and the face repos' pins are now maintained independently — when you bump the Noir toolchain here, confirm the released `sparq_ieee754` tag was cut on a compatible `nargo` (and re-run the forge suite, which compiles the git dep). Their nargo tests + the ieee754 differential oracle now run in the face repos' own CI, not in `zk-toolchain.yml`.
 
 ### New-parser correctness checklist — shipping a hand-written parser
 A hand-written parser (replacing or bypassing a reference implementation) ships only with **ALL** of (design record: [`research/testing-strategy-assessment-2026-07.md`](research/testing-strategy-assessment-2026-07.md), section 8):
 
@@ -115,8 +115,9 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   left in the plain mode, and a `value_none()` re-derived until it falls outside the reachable
   value-handle band, which `is_in_handle_band` decides and a test asserts — the checkable invariant
   `research/zk-field-native-encoding.md` §14.1 asks for, discharging that reserved-tag requirement on
-  the HOST side. The in-circuit half stays open: no Noir global or assert names the sentinel, so a
-  member refuses it only because its `u64` range decomposition cannot represent it. V1's constants, vectors and public API are
+  the HOST side. The in-circuit half stays open: the `zk/dual-leaf-v2` Noir library mirrors the
+  sentinel and its band check, but no proving member imports it, so a member refuses the sentinel
+  only because its `u64` range decomposition cannot represent it. V1's constants, vectors and public API are
   unchanged and V1 stays recognised and verifiable, but it is no longer production-selectable. The
   §14.1 `LANG_NONE` separation is asserted on the host side only (see the hardening entry below). Both versions carry the same #769-accepted INV-VL
   downgrade; not externally audited (CR-G8 / sq-qhy4).
 
@@ -192,6 +192,16 @@ crates = ["sparq-reason"]
 pattern = "bench/zk-compose/**"
 crates = ["sparq-zk-compose"]
 
+# The DualLeafV2 sentinel/constants Noir mirror, include_str!'d by sparq-zk's
+# tests/dual_leaf_v2_noir_pin.rs (the host/circuit pin: every `global` in that
+# .nr must equal its dual_leaf_v2 host derivation). A literal edit there is
+# exactly a change that must re-run sparq-zk, so the file is attributed to it.
+# It sits OUTSIDE zk/compose on purpose — every *.nr under zk/compose is
+# sha256-pinned by the bench/zk-compose measurement evidence.
+[[map]]
+pattern = "zk/dual-leaf-v2/**"
+crates = ["sparq-zk"]
+
 # [FABLE-5] sq-0iqzw: the ADJUDICATED cross-engine divergence allowlist, read at
 # runtime by the sparq-bench differential fuzzer (crates/sparq-bench/src/fuzz.rs
 # DivergenceAllowlist, via an env!("CARGO_MANIFEST_DIR")-relative path) AND by its