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

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

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.
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.
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

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.

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

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.
pv extract contracts --check exit 0 and pv lint contracts --gate shapes --format json renders a verdict on that host.
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.
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.

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.

#3610: the refusal carries its evidence — full JSON report, then exit 2

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.

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.

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.

#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.

PMAT-3577: run_shapes_gate under the complexity ratchet — three helpe…

milestone → 0.71.0 per docs/roadmaps/milestone-triage-2026-09-23.md (#4024), operator approval 2026-09-23 (relayed by aprender-cf). Reason: debt ratchet pillars B/C (#3997: pv at the deepest level, ontology merge), slice 2

docs(roadmap): quorum round 8 -- #3714 re-applied to 0.71.0 (the 11:4…

triage 2026-09-23 (aprender-dd): kept in 0.70.0 and labelled ont-0.70. Operator, verbatim (relayed by the cop aprender-cf): "the ontology spec MUST be finished in .7". Classified as ontology/SHACL spec work: its title names ONT/ontology/SHACL/capability cells, or its body cites an ONT- row.

Correction to the triage comment above (aprender-dd): this issue was MOVED from 0.71.0 to 0.70.0, not "kept". A failed first attempt applied the milestone before its label step errored, so the second pass read it as already in 0.70.0. The move and the reason stand.

Sweep (aprender-dd; #4159, cop's MUST-row sweep, 2026-09-24): PARTIAL, kept open.

Ask 2 (the resolver) and ask 3 (capability probe, not version string): DONE. 82c64c6 (PR PMAT-3567: the shapes gate on the FLEET-PINNED pv, on the runner it executes on — resolved the way forjar installs it, version proved against the pin #3633) is on origin/main. On a clean origin/main worktree, scripts/check_fleet_pv_shapes_gate.sh → PASS on lambda's fleet-pinned pv 0.69.1; --self-test → 19 rows PASSED. The gate probes pv extract --help (line 71).
Ask 1 is NOT done. 'Bump the fleet pv pin through all four layers … and install it on yoga'. Measured now:
- yoga has no pin and no pv (pv extract is missing);
- gx10's pin is 0.68.2 while lambda runs 0.69.1.
  That is infra/forjar work: the pin layers and the yoga install.

Re-measured 2026-09-24 ~21:35Z (pvl-b). Resolutions were read with type -aP pv under bash -lc.

host	installed pv	`extract`	`~/.config/fleet/pv.pin`
lambda	0.69.3	yes	0.69.1
gx10	0.69.3	yes	0.69.1
yoga	0.69.3	yes	none

The binaries have converged. yoga now has pv, so the install half of ask 1 is done. The pin is behind the binary on every host. Because of that, scripts/check_fleet_pv_shapes_gate.sh on lambda prints UNMEASURED reason=pin-mismatch pin=0.69.1 version=0.69.3 (rc 0). No fleet host can currently render a shapes verdict on the fleet-pinned pv.

Remaining: the fleet-bins/forjar roll that installs 0.69.3 must also write the pin: 0.69.3 on lambda and gx10, and a new pin on yoga. That is infra's forjar layer, not an aprender change, so I did not hand-edit the pin files. Routed to the cop inbox for fleet-bins.

Re-measured 2026-09-25 (aprender-ea), bash -lc resolution on each host:

host	pv on PATH	`pv extract`	`pv lint --gate`	`~/.config/fleet/pv.pin`
lambda	0.69.3	yes	yes	0.69.1
gx10	0.69.3	yes	yes	0.69.1
yoga	0.69.3	yes	yes	none

The title defect (a fleet pv with no extract and no --gate, so every SHACL gate was unrunnable) is gone on all three hosts: the gates can run now. What is left is drift between the pin file and the binary, plus yoga having no pin at all. That is infra's forjar fleet-pv-pin resource, tracked in paiml/infra#1001 (please retarget it to 0.69.3 and add a yoga pin). Closing on the aprender side.

🤖 Generated with Claude Code

fix(ont): the ratchet's consumer probe asked the runner's bare pv, no…

PMAT-3567: the shapes gate on the FLEET-PINNED pv, on the runner it e…

release(0.69): batch — 15 receipted PRs + fleet-pv andon fix, one CI …

PMAT-3685: apr parity REFUSES (exit 12) a model the CUDA capability g…

Navigation Menu

Repository navigation

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 #3567

Correction to receipts I produced earlier today

Asks

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

done_when

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

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

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

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

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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 #3567

Description

Correction to receipts I produced earlier today

Asks

Activity

noahgift commented on Sep 20, 2026

noahgift commented on Sep 20, 2026

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

done_when

noahgift commented on Sep 20, 2026

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

noahgift commented on Sep 20, 2026

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

noahgift commented on Sep 21, 2026

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

noahgift commented on Sep 21, 2026

noahgift commented on Sep 21, 2026

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

5 remaining items

noahgift commented on Sep 23, 2026

noahgift commented on Sep 23, 2026

noahgift commented on Sep 23, 2026

noahgift commented on Sep 24, 2026

noahgift commented on Sep 24, 2026

noahgift commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions