Repository navigation
fix(tools): pin pmat 3.40.1 and CB-200 back to 602 — the fleet converged 2026-09-14; re-measuring under 3.40.1 read 603 (PMAT-3300) - #3301
Conversation
…he aprender half of the contract was never done; CB-200 back to 602
tools.toml's own header: "Bump this file in the SAME commit as the infra
forjar.yaml version bump." infra#591 (ba369f9, 2026-09-14 17:53Z) moved
intel's stack-tool-pmat to 3.40.1; this file stayed at 3.40.0. Measured on
one PR ten minutes apart: main on yoga-build (not yet converged) green,
PR 3093 on intel-clean-room-5 `FAIL pmat pinned 3.40.0 found 3.40.1`. The
verdict of an aprender PR was a function of which box picked it up.
CHANGING THE INSTRUMENT RE-RECORDS THE BASELINES, so both pmat-measured
baselines were re-measured under 3.40.1 rather than relabelled:
complexity_baseline.txt 679 rows under 3.40.0 -> 679 under 3.40.1
(check_complexity_ratchet.sh --update)
cb200_baseline.txt 602 -> 602, but only after the fix below
CB-200 was 603 on main. `pmat comply check` under 3.40.1 reads 602 at
a0634f7 (the commit that banked 602) and 603 at origin/main — same
instrument, so the tree moved. Bisected to ad8f987 (#3004). Roster diff
of sub-B definitions between the two trees is one line:
crates/aprender-compute/src/registry/wgpu_probe.rs entry B- (72.7)
It merged because no required job runs `pmat comply`. `entry` inlined
three lookup tables (vendor id, wgpu backend -> transport, device type ->
status) plus the unified-memory rule into one constructor. Each is now a
named pure function with its own unit test; `entry` is assembly only.
Fresh index: entry A+ 98.5, classify A 91.0, transport_name A- 89.5,
vendor_name / mem_kind A+; CB-200 `Warn 602 … at the recorded baseline`.
Two measurement traps, on the record because both cost a wrong reading:
* `pmat comply` reads ~/.cache/paiml-mcp-agent-toolkit/comply/index/<wt>/
context.db and did NOT refresh it after the edit; `pmat query "x"`
(dogfood.sh's "index first" step) refreshes .pmat/context.db, a
different file. comply reported the OLD `entry` (B-, cx 19) on a tree
that no longer contained it. Only moving the comply index aside made it
re-measure. Filed against pmat.
* min_grade "B" counts B- as below B. 603 reproduces from the index as
grade in (B-,C+,C,C-,D+,D,D-,F) minus the [tdg] excludes.
Local bashrs on this workstation is 7.3.0, so check_tool_versions.sh and
the shell_lint header row FAIL here on bashrs; CI runners carry 7.4.1 and
main is green on both. Not this PR's fact.
Closes #3300.
ont-delta: none — a fleet pin bump and one complexity refactor; no entity type, shape, resolves rule or reason id.
Pmat-Ticket: PMAT-3300
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
§13.11 rung 1 — quorum shadow verdict Shadow mode: this records a verdict and merges nothing. A refusal |
|
Holding this rather than fixing it — it asserts a state that does not exist, and Measured
So the split is three-way, not two:
That is also why the failure appears in both directions: this PR fails Why hold rather than repairMaking this PR pass needs the container image rebuilt to 3.40.1 and the infra The pin moves directly 3.40.0 → 3.41.0 after publish, in one PR with the baseline Order of truth, for the recordThe repo pin is asserted last because it is the only one of the four with no measurement Landing independently (not blocked on the release)
No |
|
quorum-review (AD-04): NOT agreed (auto_merge: checked=true was_armed=false disarmed=false) {
"ticket": "PMAT-3300",
"head": "1a5da828be17b9e9f1f2cc0d0ce941ecd2580e78",
"width": 3,
"executor": "agy",
"agreed": false,
"auto_merge": {
"checked": true,
"was_armed": false,
"disarmed": false,
"note": "auto-merge not armed"
},
"lanes": [
{
"lane": 1,
"verdict": "PASS",
"findings": 0
},
{
"lane": 2,
"verdict": "NO-VERDICT",
"findings": 0
},
{
"lane": 3,
"verdict": "PASS",
"findings": 0
}
]
} |
|
Reopening. I closed this on a false premise and the measurement says the opposite. What I got wrongI closed it arguing "
The evidenceRun 34944505814 — this PR's
And it is not theoretical: #3295 was ejected from the merge queue on Why "hosts uniform" and "runners disagree" are both true
It measures the login user over SSH. Jobs run as the runner service user under Direction: up, never downHosts are already 3.40.1. Downgrading runners to match a stale repo pin would invert the Sequence before this merges
Rebasing on |
|
quorum-review (AD-04): NOT agreed (auto_merge: checked=true was_armed=false disarmed=false) {
"ticket": "PMAT-3300",
"head": "1a5da828be17b9e9f1f2cc0d0ce941ecd2580e78",
"width": 3,
"executor": "agy",
"agreed": false,
"auto_merge": {
"checked": true,
"was_armed": false,
"disarmed": false,
"note": "auto-merge not armed"
},
"lanes": [
{
"lane": 1,
"verdict": "PASS",
"findings": 0
},
{
"lane": 2,
"verdict": "NO-VERDICT",
"findings": 0
},
{
"lane": 3,
"verdict": "PASS",
"findings": 0
}
]
} |
2 similar comments
|
quorum-review (AD-04): NOT agreed (auto_merge: checked=true was_armed=false disarmed=false) {
"ticket": "PMAT-3300",
"head": "1a5da828be17b9e9f1f2cc0d0ce941ecd2580e78",
"width": 3,
"executor": "agy",
"agreed": false,
"auto_merge": {
"checked": true,
"was_armed": false,
"disarmed": false,
"note": "auto-merge not armed"
},
"lanes": [
{
"lane": 1,
"verdict": "PASS",
"findings": 0
},
{
"lane": 2,
"verdict": "NO-VERDICT",
"findings": 0
},
{
"lane": 3,
"verdict": "PASS",
"findings": 0
}
]
} |
|
quorum-review (AD-04): NOT agreed (auto_merge: checked=true was_armed=false disarmed=false) {
"ticket": "PMAT-3300",
"head": "1a5da828be17b9e9f1f2cc0d0ce941ecd2580e78",
"width": 3,
"executor": "agy",
"agreed": false,
"auto_merge": {
"checked": true,
"was_armed": false,
"disarmed": false,
"note": "auto-merge not armed"
},
"lanes": [
{
"lane": 1,
"verdict": "PASS",
"findings": 0
},
{
"lane": 2,
"verdict": "NO-VERDICT",
"findings": 0
},
{
"lane": 3,
"verdict": "PASS",
"findings": 0
}
]
} |
|
quorum-review (AD-04): NOT agreed (auto_merge: checked=true was_armed=false disarmed=false) {
"ticket": "PMAT-3300",
"head": "1a5da828be17b9e9f1f2cc0d0ce941ecd2580e78",
"width": 3,
"executor": "agy",
"agreed": false,
"auto_merge": {
"checked": true,
"was_armed": false,
"disarmed": false,
"note": "auto-merge not armed"
},
"lanes": [
{
"lane": 1,
"verdict": "PASS",
"findings": 0
},
{
"lane": 2,
"verdict": "FAIL",
"findings": 2
},
{
"lane": 3,
"verdict": "PASS",
"findings": 0
}
]
} |
….41.1 — the pin itself landed in paiml#3484 (paiml#3491) * fix(tools): pin pmat 3.41.1 — the fleet converged 2026-09-18 (infra#692); CB-200 599, complexity 670 rows, both re-measured not relabelled tools.toml's own header: "Bump this file in the SAME commit as the infra forjar.yaml version bump." infra#692 (9c411f4) moved stack-tool-pmat to 3.41.1 on all five boxes and converged them — including /opt/ci-tools/pmat, the file every container runner on gx10 and yoga mounts as /usr/local/bin/pmat, which nothing had declared and which was still 3.40.1 after the login user's pmat moved. Measured in a fresh clone at 3409b29 with the converged pmat on PATH, before this change: FAIL pmat pinned 3.40.1 found 3.41.1 which is the verdict every aprender PR gets on every converged runner until this lands — paiml#3301's split (`pinned 3.40.0 found 3.40.1`) again. After: ok pmat pinned 3.41.1 found 3.41.1 ok bashrs pinned 7.4.1 found 7.4.1 4/4 checks, 0 failed CHANGING THE INSTRUMENT RE-RECORDS THE BASELINES (paiml#3301), and this time the instrument and the tree are separated by measurement, not assumed: complexity_baseline.txt 676 rows -> 670 (check_complexity_ratchet.sh --update, "10345 file(s), 179788 function(s), 670 over"). The six dropped rows (inference_result.rs::validate_gpu_first_token, llm.rs::execute_llm_{experiment,load,score,sweep}, ggplot.rs::compute_data_ranges) all still exist. Their files were each changed on 2026-09-16, the day AFTER paiml#3301's re-measurement. pmat 3.41.1 run on llm.rs AS OF 4bad830 reads 36/61, 40/91, 20/40, 16/36 — the exact numbers 3.40.1 recorded. Same binary, old tree, same reading: the instrument did not move on complexity; the 09-16 commits did. cb200_baseline.txt / .pmat-gates.toml [tdg] 601 -> 599, lowered. `pmat comply check --checks CB-200` from a cold index at 3409b29: "599 definition(s) below minimum grade B across 478 file(s) ... The tree is 2 under the recorded baseline: lower to 599". The same binary on 5d95ed5, the tree that banked 601 under 3.40.2, reads 602 — so 3.41.1 grades ONE more definition below B on that tree than 3.40.2 did (not identified to the definition here), and the current tree is three definitions better than 09-17 under the one instrument. Written as 599 because that is what the pin reads on this tree, and the ratchet refuses anything above it from here. Not changed: scripts/pmat_bin.sh PMAT_PIN="3.37.0" and the fleet's pmat-337-pin — a different contract with its own reason (run 34639757080). Also measured while here, for the follow-up that replaces `make roadmap-aggregate` with pmat: `pmat roadmap aggregate` (3.41.1) on the same 919 base + 32 fragments writes docs/roadmaps/roadmap.yaml BYTE-IDENTICAL to scripts/lib/roadmap_fragments.py aggregate — 642,905 bytes, sha256 fb345c44cb18ef0a… both ways, `--check` ok and idempotent from either side. Not acted on in this PR. Closes paiml#3490. ont-delta: none — a fleet pin bump and two re-measured baselines; no entity type, shape, resolves rule or reason id. Pmat-Ticket: PMAT-3490 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * quorum: PMAT-3490 — 3/3 PASS on 41c9765, partial=false Pmat-Ticket: PMAT-3490 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * review(3491): pr-review v2 receipt for 0fd8deb Reviewer: a separate session in ~/src/aprender-review, per .claude/skills/pr-review/SKILL.md v2.1.0. Verdict FINDINGS (none blocking, none DEGRADED): four measured, advisory findings — a competing open PR (paiml#3492) for the same ticket from the same merge base, a tools.toml provenance SHA (infra 9c411f4) that does not exist in paiml/infra after a rebase, pmat 3.41.1's MCP pmat_index_stats deleting a CLI-built index (reproduced 2/2, an upstream defect in the instrument this PR pins), and workspace-test red on this head because yoga-build2 killed the container (exit 143), not because a test failed. The PR's own claims were re-measured under pmat 3.41.1 and all hold: check_tool_versions 4/4; CB-200 599 across 478 files at HEAD and 602 on 5d95ed5; 670 complexity rows on both sides of the merge base; the six dropped functions still exist and read under threshold; llm.rs as of 4bad830 reads the 3.40.1 numbers; forjar.yaml line 779 pins 3.41.1. Receipt ACCEPTED by scripts/check_pr_review_receipt.sh under a throwaway key (all four positive controls fired first); the throwaway signature was removed and the repository signer (ci.yml pr-review-sign) signs it. Pmat-Ticket: PMAT-3490 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(tools): the header cited infra 9c411f4, a pre-rebase SHA that exists nowhere — the pin commit is 2734069 via f92ed2d (paiml#692) Found by this PR's own Arm 4 review (finding 2, measured): infra#692 was rebased over infra#691 before it merged, so the commit I wrote into tools.toml:7 was rewritten to 2734069e and merged as f92ed2d0. A reader following the citation would have found nothing. One comment line; the pin, the baselines and the quorum-judged diff are unchanged in substance. Pmat-Ticket: PMAT-3490 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * chore(pr-review): sign this PR's receipt (PR-REVIEW-SKILL-002 v2 §4.3 CI signer) * roadmap: PMAT-3490 described a pin bump that landed elsewhere two days ago Quorum lane 1 refused, correctly: the fragment still said "update the pmat pin to 3.41.1 in tools.toml" while `[pmat] version = "3.41.1"` has been on main since `f4c0daa37` (09-18 17:07), inside paiml#3484. The ticket authorizes and the issue defines done, so a lane refusing a diff that does not do what its ticket says is the gate working. I had retitled the PR and prepended a correction to its body; the fragment was the last place the old story lived. Rewritten to what the row actually lands: CB-200 601 -> 599, the complexity shrink, and the stale comment on tools.toml:7. With the verification that matters -- 599 re-checked on the MERGED tree, not carried -- and the note that 3.41.1 was re-confirmed converged on the runner denominator before the rebase. The same lane also wrote "the diff only updates a comment in tools.toml while leaving the actual version unchanged at 3.40.1" -- reading line 7, a COMMENT, as the pin. Two humans and now a review lane, three readers of three different kinds, same wrong line. That is paiml/infra#816 and the lane's sentence is the best evidence in it. The pr-review receipt under evidence/pr-review/3491/0fd8deb79.../ is deliberately NOT regenerated: it is scoped to the sha it names and correct for it, and pr_review_quorum_arm.sh:612 already refuses this case with the true reason. Regenerating a signed receipt for a head it never reviewed would be the actual defect. Pmat-Ticket: PMAT-3490 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * roadmap: the complexity shrink ALSO landed in paiml#3484 — this PR is cb200 601→599 and one comment Quorum r3 refused on two true findings. Lane 1: scripts/complexity_baseline.txt is absent from the diff against origin/main. The "8 functions removed" that r2's ratchet printed was measured against the MERGE-BASE, and the merge then auto-resolved the file to main's version because main already carried the same shrink, via paiml#3484 -- the same PR that carried the pin. So the criterion's "complexity-baseline shrink" claim was a claim about the merge-base, not about this PR. Dropped. What this PR lands is now stated exactly: cb200 601 -> 599, and the stale comment on tools.toml:7. Nothing else. Lane 2: the committed docs/audits/quorum-PMAT-3490.json was the artifact from the ORIGINAL round on 0fd8deb, and it asserts that tools.toml:56 and complexity_baseline.txt were modified. Both were true of that tree and are false of this one. A lane reading it as a receipt claim about the current diff is right to refuse. Removed; the artifact from the round that passes on this head is what gets committed. Third time on this PR that a claim went stale because the tree moved under it: the pin (landed in paiml#3484), the complexity shrink (landed in paiml#3484), and the receipt (described 0fd8deb). Same lesson each time -- every number in a criterion has to be re-derived from the diff against main at the moment the criterion is written, and a diff against the merge-base is a different diff. Pmat-Ticket: PMAT-3490 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * audit: quorum PMAT-3490 round 4 — 3/3 PASS on PR paiml#3491 at b940bf4 Rounds 1-3: quota-voided; two lanes refusing the fragment that still described a pin bump; two lanes refusing the merge-base-measured "complexity shrink" claim and the stale receipt from 0fd8deb. Round 4 judges what the PR actually is: cb200 601 -> 599 and one comment. Pmat-Ticket: PMAT-3490 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Noah Gift <noah@paiml.com>
fix(tools): pin pmat 3.40.1 — the fleet converged on 2026-09-14 and the aprender half of the contract was never done; CB-200 back to 602
tools.toml's own header: "Bump this file in the SAME commit as the infra
forjar.yaml version bump." infra#591 (ba369f9, 2026-09-14 17:53Z) moved
intel's stack-tool-pmat to 3.40.1; this file stayed at 3.40.0. Measured on
one PR ten minutes apart: main on yoga-build (not yet converged) green,
PR 3093 on intel-clean-room-5
FAIL pmat pinned 3.40.0 found 3.40.1. Theverdict of an aprender PR was a function of which box picked it up.
CHANGING THE INSTRUMENT RE-RECORDS THE BASELINES, so both pmat-measured
baselines were re-measured under 3.40.1 rather than relabelled:
complexity_baseline.txt 679 rows under 3.40.0 -> 679 under 3.40.1
(check_complexity_ratchet.sh --update)
cb200_baseline.txt 602 -> 602, but only after the fix below
CB-200 was 603 on main.
pmat comply checkunder 3.40.1 reads 602 ata0634f7 (the commit that banked 602) and 603 at origin/main — same
instrument, so the tree moved. Bisected to ad8f987 (#3004). Roster diff
of sub-B definitions between the two trees is one line:
crates/aprender-compute/src/registry/wgpu_probe.rs entry B- (72.7)
It merged because no required job runs
pmat comply.entryinlinedthree lookup tables (vendor id, wgpu backend -> transport, device type ->
status) plus the unified-memory rule into one constructor. Each is now a
named pure function with its own unit test;
entryis assembly only.Fresh index: entry A+ 98.5, classify A 91.0, transport_name A- 89.5,
vendor_name / mem_kind A+; CB-200
Warn 602 … at the recorded baseline.Two measurement traps, on the record because both cost a wrong reading:
pmat complyreads ~/.cache/paiml-mcp-agent-toolkit/comply/index//context.db and did NOT refresh it after the edit;
pmat query "x"(dogfood.sh's "index first" step) refreshes .pmat/context.db, a
different file. comply reported the OLD
entry(B-, cx 19) on a treethat no longer contained it. Only moving the comply index aside made it
re-measure. Filed against pmat.
grade in (B-,C+,C,C-,D+,D,D-,F) minus the [tdg] excludes.
Local bashrs on this workstation is 7.3.0, so check_tool_versions.sh and
the shell_lint header row FAIL here on bashrs; CI runners carry 7.4.1 and
main is green on both. Not this PR's fact.
Closes #3300.
ont-delta: none — a fleet pin bump and one complexity refactor; no entity type, shape, resolves rule or reason id.
🤖 Generated with Claude Code