The fleet-pinned pv is 0.65.2 and has no 'extract' subcommand and no '--gate' flag — every SHACL gate measured on the fleet binary is unrunnable, not merely unmeasured

[noahgift]

Hard prerequisite for the 0.69 ontology goal (#3559) and the docs-SHACL goal (#3560). Measured 2026-09-20.

The 30-day plan v2 calls this "row zero" and states the fleet pv pin predates the shapes gate. Measured here, it is sharper than that — the subcommands do not exist:

$ pv --version                                  # /home/noah/.cargo/bin/pv, the installed binary
pv 0.65.2 (aprender provable-contracts verifier)

$ pv lint contracts --gate shapes --format json
error: unexpected argument '--gate' found

$ pv extract contracts --check
error: unrecognized subcommand 'extract'
  tip: a similar subcommand exists: 'extract-pytorch'

Fleet state:

host	pv
lambda (this box)	0.65.2
gx10	0.65.2
yoga	not installed (pv: command not found)
declared in forjar	pv 0.65.2 on mini and gx10 (machines/*/forjar.yaml)

So a gate that shells out to pv extract … --check or pv lint --gate shapes on any fleet host errors; it does not report UNMEASURED, and depending on how the caller reads the exit status it may not report anything at all.

Correction to receipts I produced earlier today

The 0.68.2 bump's contract receipts — pv extract contracts --check rc 0 and pv lint contracts --gate shapes Pass with armed_shapes: [ont-shapes-v1, ladder-measured, ladder-green] — were produced with /mnt/nvme-raid0/targets/aprender/release/pv, a HEAD-built 0.68.2, not the fleet-pinned binary. For the bump that is the correct tool (it is the version being released) and those receipts stand as what they say. But they say nothing about the fleet, and #3559's target is explicitly "≥80% of a frozen capability ledger passes on the installed, fleet-pinned pv" — which today cannot run the commands at all. Anyone reading "shapes gate green" as a fleet property would be wrong.

This is the same discipline the train has been applying all day: pin the binary, and say which one produced the number ([. scripts/apr_bin.sh] exists for apr for exactly this reason; pv has no equivalent).

Asks

1. Bump the fleet pv pin through all four layers to a version that carries extract and --gate (0.68.2 is on crates.io as of today), and install it on yoga, which has none.
2. A pv resolver with the same contract as scripts/apr_bin.sh — prove the binary that ran is the one intended, and refuse a bare pv on PATH. Four apr binaries once coexisted on this box and a bare apr resolved to a 26-day-old copy; pv is now in the same position with no guard.
3. A capability probe, not a version string. The gate asserts pv extract --help and pv lint --gate shapes --help both succeed before it trusts a verdict — a version comparison would have passed 0.65.2 on any >= 0.6x rule. Falsifier: point it at 0.65.2 and require RED.

Until (1) lands, #3559's percentage cannot be measured on the fleet and #3560's docs corpus cannot be extracted there.

Refs #3080, #3559, #3560

[noahgift]

done_when gains a first line (review, 2026-09-20): the consumer-resolution check comes before the bump is called done.

command -v -a pv        # every resolution, in PATH order

and each resolved path's version, asserting that the one a consumer actually gets is the one the pin owns. This is ARB-APR-6's PATH inventory applied early to the single binary this row bumps, and it belongs in the row rather than as a one-off — a pin bump that lands behind a shadow is a bump that did nothing and reports success. That is not hypothetical: a hand-installed apr 0.64.0 at ~/.local/bin/apr was shadowing the forjar-managed 0.68.2 on lambda-labs today, and 0.64.0 refuses qwen35 outright — the pin read as converged while a consumer would have got the binary that cannot run the model. Both halves were individually correct; only PATH order made them disagree. See infra#798 for the fleet-wide form.

Positive control: plant a shadowing copy earlier in PATH and the check must fail naming both paths and both versions — otherwise "0 shadowed binaries" is also what a broken check reports.

Disclosure: I attempted this check earlier with type -aP pv and it returned nothing usable in this shell, so I have not verified whether a shadowed pv exists here. It is unverified, not clean.

[noahgift]

Moved to 0.69 as the enabling row. Operator ruling 2026-09-20.

#3567 moves to 0.69 as the enabling row (SHACL on ≥1 fleet host is what lets parity-receipt-v1 render a verdict, and 0.69's "verbs that are true" needs receipts under contract); the other three ontology rows stay 0.70; no percentage target typed — the 0.69 floor is shapes gate renders a verdict on one fleet host, and the 80% is the 0.70 target with its probe (census.json derived, per decision 8).

The 0.69 floor, stated so it cannot inflate: the shapes gate renders a verdict on one fleet host. Not a percentage, not a row count, not "SHACL armed everywhere". One host, one verdict, non-vacuous.

That is deliberately the smallest thing that unblocks the rest: parity-receipt-v1 cannot render a verdict without pv extract and pv lint --gate shapes, and 0.69's claim — every verb is receipted or refuses by name — is not satisfiable while the receipts themselves are uncontracted.

Why it is the enabling row and not a nice-to-have: the fleet pin is 0.65.2, which has no extract subcommand and no --gate flag. Measured on the runner denominator, not the host set:

host	pv
lambda, gx10	0.65.2
yoga	not installed
forjar declares (mini, gx10)	0.65.2

So today SHACL cannot run anywhere on the fleet, which makes #3559 and #3560 unstartable rather than merely unscheduled.

Scope that did NOT move. #3559 (ONT-001 to 80%), #3560 (docs / 1037 examples / cookbook SHACL-validated) and #3577 (receipts under contract) stay on 0.70. Ontology is 7 of 17 rows ≈ 41% on origin/main; 80% is the 0.70 target and it carries its own probe (census.json derived, decision 8). Nothing here commits 0.69 to a percentage.

The §11 cadence conflict #3559 raises is therefore deferred, not resolved — one row per train versus seven rows in one train. It becomes a 0.70 question, and #3559 still owes the choice between amending §11 with a dated exception, accepting 80% across 0.70–0.71, or re-scoping the 17.

Holder and sequencing: the fleet pv roll is held by the infra lane, deliberately, pending paiml-implement-73's PMAT-299 gate and forjar-95's live fixture for forjar#591. They have committed to rolling the same day both land rather than batching it, and to jumping it ahead of infra#755 and infra#807. That hold is correct — two independent go-signals beat a fast roll — but it is now on the 0.69 critical path, so its cost is no longer hypothetical.

done_when

1. pv on ≥1 fleet host is a version carrying both extract and lint --gate shapes. Measured inside the runner, not on the host — yoga's host and its runners have disagreed on a tool version today (jq 1.8.1 vs 1.6), and pv resolves through /opt/fleet-bin on intel while cargo writes ~/.cargo/bin.
2. pv extract contracts --check exit 0 and pv lint contracts --gate shapes --format json renders a verdict on that host.
3. The verdict is non-vacuous: it is over a stated corpus with a stated count, and a planted violating fixture turns it RED. A gate green because it looked at a subset is the recurring defect class here.
4. Which host, which pv version, and the corpus size recorded in the issue — so 0.70's expansion has a baseline rather than a memory.

Refs #3559, #3560, #3577, #3080, infra#781.

[noahgift]

Correction: this is not blocked on forjar-95's fixture. It is blocked on PMAT-299 only.

I recorded the hold as "pending paiml-implement-73's PMAT-299 gate and forjar-95's live fixture for forjar#591." The second half is stale and was already stale when I wrote it.

forjar-95 released the fixture hours ago — forjar#591 comment 5750734969 captures the lock entry (stack-tool-pv, status: converged, applied_at: 2026-09-10T06:59:10Z, both blake3 digests) and the declaration (provider: cargo, version: "0.67.0", packages: [aprender-contracts-cli]) into the issue, and they told the infra lane in writing to roll lambda-labs, intel and gx10 whenever their own gate is ready. Their acceptance test needs a lock plus a config, not a host — it fits in a comment.

The real and only blocker: paiml-implement's PMAT-299 has not landed. Rolling before it turns those boxes' verify.sh pv-gate rows red against a constant nobody changed. The infra lane's own words to forjar-95: "the remaining gate is mine, not yours."

Why the distinction matters more than the bookkeeping: "blocked on a fixture" and "blocked on PMAT-299" route to completely different people. For as long as the first was recorded here, anyone reading this row would have chased the wrong session — and this is a 0.69 must-carry enabling row whose floor is the shapes gate renders a verdict on one fleet host. A wrong blocker on the critical path costs whoever acts on it.

Corrected holder chain: #3567 → fleet pv roll (infra lane) → PMAT-299 (paiml-implement). Nothing upstream of that is aprender's and nothing is forjar's.

Recorded by the cop; the correction is forjar-95's, unprompted.

---

This comment was posted mangled and repaired: backticks inside a double-quoted gh issue comment --body were command-substituted, executing verify.sh and pv and pasting pv --help into the text. Second occurrence today. The practice is now --body-file with a quoted heredoc, always — the earlier repair fixed the text and not the habit.

[noahgift]

Blocker chain cleared 22:0xZ — host side done; the runner-side measurement is the remaining row

• paiml-implement#307 (PMAT-299: the pv-gate reads ~/.config/fleet/pv.pin from the box) merged 21:14Z.
• infra#818 un-drafted; roll applied through forjar (infra-45, 22:00Z): gx10 / lambda-labs / intel all pv 0.68.2, pin 0.68.2; intel also /opt/fleet-bin/bin/pv — the path every runner resolves. pv-pin-check: matched=4 drifted=0 capability_missing=0.
• Host-side, with aprender main e6f77c98c on each box: pv lint contracts/ --gate shapes --format json → rc 0, verdict=Pass, by_entity_type identical on all three (code 270, gguf 8, lean 410, pv-contract 1735).

What is still false at origin/main (done_when 1–3): no aprender workflow runs the fleet-pinned pv inside a runner — ci.yml resolves pv through scripts/pv_bin.sh (HEAD-built from the tree), and no job anywhere invokes --gate shapes (measured: grep -nE "gate shapes|pv lint" .github/workflows/* → comments only). So the floor "a shapes gate renders a verdict on one fleet host, measured inside the runner" needs one job: /opt/fleet-bin/bin/pv --version + pv lint contracts/ --gate shapes --format json inside an intel runner, verdict parsed (not grepped), corpus count stated, and a planted violating fixture turning it RED as the positive control — additive workflow edit, inside the standing rule (no secrets/permissions; mutation RED + control GREEN in the body).

Side fact for paiml-implement's pin reader: intel's ~/.config/fleet/pv.pin read 0.65.2 at 21:25Z, written by something other than forjar; forjar owns it at 0.68.2 now and forjar drift on intel will name a second writer if one returns.

[noahgift]

Not closeable yet — the evidence #3567 asks for is not observable in any CI log (cop, 05:30Z)

#3633 landed (main 82c64c6be) and check_fleet_pv_shapes_gate.sh runs in guard-tree: main's run 35561048727, runner gx10-build, prints only

PASS  scripts/check_fleet_pv_shapes_gate.sh [self-test]
PASS  scripts/check_fleet_pv_shapes_gate.sh [run]

guard_tree.sh records a passing guard as its label alone (printf 'PASS %s\n' "$label", line 256) and drops its output. The guard's three outcomes are PASS / FAIL / UNMEASURED-as-exit-0 (by design, so a runner without the fleet pv does not red every PR) — so a guard-tree PASS is indistinguishable between "verdict=Pass on the fleet-pinned pv" and "UNMEASURED: no fleet pv on this runner". done_when 1–3 ask for the verdict measured inside a runner with corpus count and control; that row exists only in the guard's stdout, which no log keeps. And the one run so far landed on a gx10 container, where the fleet pv may not be mounted at all.

To close: guard_tree must surface a passing guard's one-line summary when the guard emits one (e.g. any line starting PASS verdict= / UNMEASURED), so the log carries runner=… pv=… version=… verdict=… corpus=… planted=… pc_shape=…; then one guard-tree run on an intel runner shows it. Until then #3567 stays open on its own criterion — the gate exists; its verdict has not been observed.

[noahgift]

Measured on lambda while building #3653 (#3651): the fleet pv (~/.cargo/bin/pv 0.68.2, pin 0.68.2) returns rc=2 with no JSON for lint contracts --gate shapes --format json on main's tree — it refuses 7 tracked evidence/parity/l0-1{,b}/*.json records as "UNMIGRATED logit-parity record … migrated by #3577". The pv built from HEAD on the same tree returns verdict=Pass, focus_nodes_n=2320, pc_shape=fired, plant_violations=3. So on a converged runner (pin + fleet pv) check_fleet_pv_shapes_gate.sh reports ENV, not Pass, until the fleet pv moves past 0.68.2 or those records are migrated. Intel's guard-tree today shows a bare PASS (run 35563537942, intel-clean-room-5) — almost certainly UNMEASURED (no pin in the job), which #3653 will make visible.

[noahgift]

#3600 unblocks this row — measured on lambda with the fleet-pinned pv (cop, 05:45Z)

~/.cargo/bin/pv = pv 0.68.2, ~/.config/fleet/pv.pin = 0.68.2, command pv lint contracts --gate shapes --format json:

tree	rc	verdict	focus nodes	pc_shape
origin/main (c0ab699)	2	— (no JSON)	—	—
PR #3600's head (242bdc3)	0	Pass	2329	fired

On main the fleet pv refuses the 7 un-migrated evidence/parity/l0-1{,b}/*.json records ("an UNMIGRATED logit-parity record: schema absent is not apr-parity-receipt…"), found by b3. #3600 migrates exactly those 7 to parity-receipt-v2, and on its tree the same binary renders a verdict. So #3600 is on this row's critical path: until it merges, check_fleet_pv_shapes_gate.sh can only report ENV on any converged runner, and this row's floor ("a shapes gate renders a verdict on one fleet host") cannot be met. The other dependency is #3653, which makes guard-tree show the verdict row. Once both are on main, one guard-tree run on an intel runner closes this.

Aside, not blocking: b3 reports that HEAD's pv on main's tree returns Pass while the published 0.68.2 refuses. Two builds of pv read the same tree differently. That is worth one ticket once 0.69 is cut.