fix(G-10, PR-A): the shipped-path ratchet runs under ONE pinned analyser — stamped baseline, differential HEAD vs base under the same binary, never the tree against itself (PMAT-1059) by noahgift · Pull Request #3011 · paiml/aprender

noahgift · 2026-09-06T11:13:03Z

PP-066 DAG row G-10 · ticket PMAT-1059 · Refs #2999 · epic #2873 · PR-A of three (G-10b pin guard, G-10c sweep follow). Receipt: docs/audits/impl-PMAT-1059-receipt.md (status: partial until merged).

Root cause, cited from the job logs (not inferred)

run	shape	analyser line in the log	ratchet step
`34011762858` main @ `027ed88`, 04:35Z	push	`pmat: /home/noah/.cargo/bin/pmat (pmat 3.31.0)`	`SKIPPED (proven): pmat 3.31.0 cannot run this analysis.` → success
`34018449576` #3008, 07:53Z	pull_request	`pmat: /home/noah/.cargo/bin/pmat (pmat 3.37.0)`	`pmat is capable (pmat 3.37.0) -- the ratchet is ARMED and blocking.` → `FAIL: shipped machine-specific paths grew 277 -> 317.`

The runner's analyser moved between those two runs (paiml/infra machines/intel/forjar.yaml pins 3.37.0, PMAT-231). The baseline 277 named no instrument; 3.37.0 and 3.38.0 both count 317 on the unchanged tree. Main was vacuously green; every PR since is red for a defect none introduced. The instrument is part of the number.

What this PR does

scripts/pmat_bin.sh — the ONE pin (PMAT_PIN=3.37.0). Resolves PMAT_BIN_OVERRIDE, ~/.local/pmat/<pin>/bin/pmat, then PATH — and accepts a binary only if it reports the pin; otherwise returns 1 naming every version tried. Option-neutral (sourced), zsh-safe (array candidates).
scripts/hardcoded_path_shipped_baseline.txt gains pmat_version: and basis:. Both are INVALID/UNMEASURED by design: the 277 was never measured under a named binary. No baseline raise. The re-baseline is PMAT-1061, stamped, its own PR.
scripts/check_hardcoded_paths.sh --full-if-capable — an absolute compare only under a matching stamp. Otherwise REPORT BASELINE-STALE{old,new} / BASELINE-INVALID and the verdict is the differential: HEAD and merge-base scanned under the same binary, delta ≤ 0 PASS, a positive delta FAILS naming the added paths. A stamp bumped without a re-measurement is refused. No base → RED. No analyser at the pin → FAIL (ENV), never PASS.
Never the tree against itself (the review quorum's blocking finding, confirmed from the main run's own log where G-6's guard printed base=027ed889d … head=HEAD — the base was the pushed commit): on the push shape scripts/lib/resolve_base.sh names HEAD's first parent and refuses when it is not fetched; ci.yml deepens the depth-1 checkout by one on push. The resolver is G-6's, extracted verbatim and now shared, so both differential guards judge against one base.
Contract contracts/apr-pinned-analyser-ratchet-v1.yaml (kind: pattern; PIN-OB-001..004 ↔ PIN-F-001..004, 1:1). pv validate: valid.
ci.yml: the ratchet step reads the pin; the fetch step deepens on push. No new jobs, no required-check change.

Mutations — RED then GREEN, each observed

mutation	RED (observed)	GREEN (observed)
live: append `pub const MUTATION_PROBE: &str = "/home/probe/models/x.gguf";` to `crates/apr-cli/src/main.rs`, run `--full-if-capable` under the pin	`differential: base 027ed889d = 317 shipped; HEAD = 318 shipped; delta +1` → `FAIL … crates/apr-cli/src/main.rs\|/home/probe/models/x.gguf` rc=1	reverted → `delta +0` → `PASS (differential, delta +0)` rc=0
R2 / R4 (+1 path under a matching / stale stamp)	RED by the absolute compare / by the differential naming `src/f8.rs\|fixture://p8`	R1 / R3 PASS at delta 0
R5 INVALID stamp compared as a number · R6 stamp bumped while `count:` stands	REPORT + differential (never compared) · `A stamp is not a measurement` rc=1	—
R7 no base nameable · R8 no analyser at the pin	RED by name (`cannot resolve the comparand ref`) · `FAIL (ENV)` rc=1	—
R9–R11 push shape (HEAD is the origin/main tip): delta 0 · +1 vs the first parent · parent not fetched (depth-1 clone)	R10 RED naming the path · R11 RED `never the tree against itself`	R9 PASS against the first parent
G-6 resolver rows 16–17 (push shape → first parent; parent not fetched → refused by name)	row 17 refused	row 16 first parent
my own finding: R7 had passed by an unbound-variable death (`PROG=x . file` does not outlive the `.` builtin; `$PROG` unset under `set -u` inside `resolve_base`)	reproduced with a two-line fixture	plain assignment + defaulted PROG; R7 now asserts the refusal text
`comm: input is not in sorted order` on the first live mutation (sort under `LC_ALL=C`, comm under the user locale)	observed	`LC_ALL=C comm` → the path is named

Case tables: bash scripts/check_hardcoded_paths.sh --self-test → 16/16 (5 contract rows + R1–R11) · bash scripts/check_roadmap_diff_additive.sh --self-test → 17/17.

Acceptance, re-run by the orchestrator (the quorum lanes ran no commands; every lane claim was re-verified)

bash scripts/check_hardcoded_paths.sh --self-test          # SELF-TEST PASSED, rc 0
bash scripts/check_roadmap_diff_additive.sh --self-test    # 17/17 rows, rc 0
bash scripts/check_guards_are_wired.sh                     # PASS (ratcheted), rc 0
bash -c '. scripts/pmat_bin.sh && echo $PMAT $PMAT_VERSION' # /home/noah/.local/pmat/3.37.0/bin/pmat 3.37.0 (same under zsh)
bash scripts/check_hardcoded_paths.sh --full-if-capable    # REPORT BASELINE-INVALID → differential delta +0 → PASS, rc 0
pv validate contracts/apr-pinned-analyser-ratchet-v1.yaml  # valid (via scripts/pv_bin.sh)
check_baseline_ratchets · check_sourced_libs_option_neutral · check_shell_lint_ratchet (9→8) · check_readme_claims · check_no_claim_literals  # PASS

Review quorum

3 agy lanes, review-only, verdict 3/3 do-not-implement-as-written on the pre-fold diff; the blocking finding (vacuous HEAD-vs-HEAD on the push shape) is confirmed and fixed above; the 1:1 obligation mapping applied; lane 1's dissent (the stored-count shrink-only ratchet blocks a rising re-baseline) is recorded as PMAT-1061's precondition. Full disposition table in the receipt.

Deployment precondition (why this is green on the runner)

The runner's PATH pmat is 3.37.0 (the log line above) and ~/.local/pmat/ does not exist there → the resolver's third candidate takes it. The baseline is INVALID → the differential runs: HEAD vs merge-base (pull_request / merge_group) or vs the first parent (push, deepened). Expected on this PR: REPORT BASELINE-INVALID + delta +0 + PASS.

Not in this PR

G-10b (check_pmat_pinned.sh, 281 shrink-only) · G-10c (the sweep to 0) · PMAT-1061 (stamped re-baseline; needs a "stamped series" rule in the baseline kind table). All preserved on agent/G-10-full.

…ser — scripts/pmat_bin.sh (PMAT_PIN=3.37.0, refuses absent/off-pin, option-neutral); the baseline is stamped (count/pmat_version/basis; INVALID is not a number, a stamp bump without a measurement is refused); a count is compared only under a matching stamp, otherwise REPORT BASELINE-STALE/INVALID and decide HEAD vs merge-base under the same binary; resolve_base.sh shared with G-6; 8 fixture rows; contract apr-pinned-analyser-ratchet-v1; CI step reads the pin (PMAT-1059, #2999) Pmat-Ticket: PMAT-1059

…tself: on the push shape (HEAD is the origin/main tip) resolve_base names the FIRST PARENT and refuses when it is not fetched (ci.yml deepens by one on push); `PROG=x . file` does not outlive the builtin, so R7 had passed by an unbound-variable death — plain assignment + a named refusal; LC_ALL=C comm; env -u GIT_* around the analyser; ratchet rows R9-R11 and G-6 rows 16-17; obligations map 1:1 onto PIN-F-001..004; resolver candidates are an array (zsh-safe, lint-clean) (PMAT-1059, #2999) Pmat-Ticket: PMAT-1059

…ed from the job logs, quorum verdict and per-finding disposition, verification claimed vs re-run, gaps G-10b/G-10c/PMAT-1061 Pmat-Ticket: PMAT-1059

github-actions · 2026-09-06T11:25:09Z

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=3011 head=0c35f8cfb0f7733c5cfe0471c3d8e22f63e24ccc verdict=REFUSE class=Q1 arm_rc=1

Shadow mode: this records a verdict and merges nothing. A refusal
to arm is not a block (§13 adds zero rows to §7) — the pull request is
exactly as green as it was.

…pt marker flipped, roadmap completed with proof, estimates row (turns 15, delegate tokens 64665, wall 2700 s, basis first-run [U]) Pmat-Ticket: PMAT-1059

…endered Pmat-Ticket: PMAT-1059

…ms ratchet, executable criteria), DAG rows/edges/amendments, decision receipts, roadmap mints, rescope quorum record (paiml#3025) * docs(PP-066): PHASE 0 reconcile status 2026-09-06 — main is vacuously green (ratchet SKIPPED under pmat 3.31.0 at 04:35Z, ARMED and RED under 3.37.0 from 07:53Z, cited from job logs); only agent/G-10 unpushed (PR-A); C0 uncredited; D-2..D-11 recorded on paiml#2873 Pmat-Ticket: PMAT-966 * docs(PP-066): orchestrator write-back 2026-09-06 — DAG rows G-11 (paiml#3012, PMAT-1062), G-10b (paiml#3013, PMAT-1063), G-10c (paiml#3014, PMAT-1064), U-1 (paiml#3015, pmat#1200, expiry = C0-3 - 6 d), S-0 (paiml#3016, D-3 speed lane on perf-solo); amendments: P-1.1/P-1.2 -> 0.67 (D-11), C0-3 blocked by U-1 (R4), G-10 expiry 10-03 -> 09-12 (PR-A armed); §5.0 re-rendered (96 rows); roadmap mints PMAT-1061..1064 by hand (pmat#1169) Pmat-Ticket: PMAT-966 * docs(PP-066): decisions D-2/D-3/D-5/D-8/D-9/D-10/D-11 recorded — seven decision receipts (status: complete, each citing its paiml#2873 comment), DEC rows complete, roadmap tickets PMAT-1018..1023 + PMAT-985 completed with proof, §5.0 re-rendered Pmat-Ticket: PMAT-966 * docs(PP-066): roadmap — PMAT-1018..1023 and PMAT-985 (decisions D-2/D-3/D-8/D-9/D-10/D-11/D-5) completed with proof (the paiml#2873 comments and their decision receipts) Pmat-Ticket: PMAT-966 * docs(PP-066): ordering commit (driver v4) — rows L0-1 (paiml#3017, P0), G-11b (paiml#3018), R-8 (paiml#3019); R-0a/R-0b split folded from paiml#3003 (R-0b paiml#3002 PMAT-1060, design-quorum record carried over); edges L0-1/G-11/G-11b <- G-10, every open 0.66 row <- G-11, C0-3 <- U-1, R-0b <- R-0+L0-1, R-2 <- R-0b+D-9, B-G1/R-5 <- R-2, R-6/R-8 <- R-5, R-7 <- R-6, T-0 <- L0-1, TAG-0.66.0 <- every 0.66 row; amendments for the four slack violations the edges exposed (G-10 -> 09-06, R-3 -> 09-19, R-2 -> 10-02, B-G1 -> 10-09); §5.0 re-rendered (100 rows) Pmat-Ticket: PMAT-966 * docs(PP-066): ordering commit fix-up — I-18 expiry (anchor I-15 + 7 d = 10-03) -> 2026-10-09 for the R-2 -> I-18 edge; check_dag_invariants.sh exit 0 at 100 rows Pmat-Ticket: PMAT-966 * docs(PP-066): G-10 (PMAT-1059) complete — paiml#3011 merged b0a0a51; receipt marker flipped, roadmap completed with proof, estimates row (turns 15, delegate tokens 64665, wall 2700 s, basis first-run [U]) Pmat-Ticket: PMAT-1059 * docs(PP-066): DAG row G-10 complete (paiml#3011 merged b0a0a51); §5.0 re-rendered Pmat-Ticket: PMAT-1059 * docs(PP-066): tickets minted by hand for the rows created this session — L0-1 PMAT-1065 (paiml#3017, P0), G-11b PMAT-1066 (paiml#3018), R-8 PMAT-1067 (paiml#3019), S-0 PMAT-1068 (paiml#3016), U-1 PMAT-1069 (paiml#3015); DAG pmat_ids written; §5.0 re-rendered Pmat-Ticket: PMAT-966 * docs(PP-066): SPEC-2.0 rescope in the DAG (driver v5) — 18-row 0.66 scope; 39 rows -> 0.67 each with cut_by and the claim it protected; L0-1 split into L0-1a (bounded) + L0-1b (unbounded); SPEC-2.0 row; C0-2 (pin); B-G1 folded into R-7; v5 edges; TAG-0.66.0 <- every kept row; invariants exit 0 at 102 rows; §5.0 re-rendered Pmat-Ticket: PMAT-966 * docs+scripts(SPEC-2.0): spec v2.0 §4.1 — three claims, the 18-row scope and the 39 cut rows with the claim each protected (generated from the DAG), the claims ratchet, the executable criteria table; scripts/release_criteria.sh (C0 C4 C5 C6 C7 C8 C9 C11 C13 C14 one exit-coded command each, C0 first through the analyser pin, never vacuous, 6-row case table; C1 C2 C3 C10 C12 -> 0.67); scripts/run_clean_room.sh (C8 via ../infra beside the main checkout, ENV exit 2 otherwise) Pmat-Ticket: PMAT-966 * docs(SPEC-2.0): rescope quorum record (scope-holds-with-changes; the scope-fails premise on C3 refuted by the spec: R-0b ships the resolution) — nine claim removals assigned to R-7, C5 -> 0.67 (Q3 unanimous), the ratchet-universe sentence corrected, L0-1a/L0-1b cite paiml#2971 (paiml#3017 closed as duplicate), SPEC-2.0 = paiml#3023; release_criteria.sh credits nine Pmat-Ticket: PMAT-966 * docs(SPEC-2.0): the rescope record cites the hits by file:line without repeating the literals (the claims ratchet covers docs/audits too — it went RED on its own record) Pmat-Ticket: PMAT-966 * docs(PP-066): session docs commit 2026-09-06 — tickets minted/completed from the DAG and the receipts, README counts exact, status doc, kaizen Pmat-Ticket: PMAT-966 * docs(SPEC-2.0): the rescope record cites the spec line its verdict rests on (R-0b ships the resolution) and names C5's residue row (T-0h, 0.67) — driver v5.2 DONE-IF Pmat-Ticket: PMAT-966 * docs(PP-066): renumber R-0b's ticket PMAT-1060 -> PMAT-1073 (PMAT-1060 is minted by paiml#3027, BSE-001 H4); mint PMAT-1072 for the paiml#3028 main-red hotfix (PR paiml#3030) Pmat-Ticket: PMAT-1071 * docs(PP-066): driver kaizen — hotfix DONE-IF re-lists PRs; instrument change vs data defect; pre-commit complexity expansion; arms before instrument; checkout restores the index Pmat-Ticket: PMAT-1071 * docs(PP-066): driver kaizen — three-family quorum mechanics; measure a criterion's distribution before designing a fallback; a PATH tool is not a pin Pmat-Ticket: PMAT-1071 * ci(PP-066): release_criteria.sh --self-test runs in guard-runner-labels — the criteria script is a decision surface and check_guards_are_wired.sh refused it unwired Pmat-Ticket: PMAT-1071 * docs(PP-066): session 2026-09-07 — status doc, kaizen (hook expansion, env arm first, update-branch pull), PMAT-1072 completed (proof:PR#3030) Pmat-Ticket: PMAT-1071 * docs(PP-066): drop two duplicate top-level roadmap entries (title-id twins of [19] and [66]) the 2026-09-06 re-serialisation appended — main's duplicate-id guard refuses them Pmat-Ticket: PMAT-1071 * docs(PP-066): decision rows D-5/D-2/D-3 cite their receipts as proof; the issue-comment URL stays as prose (the completion guard dereferences paths and merged PRs only) Pmat-Ticket: PMAT-1071 * docs(PP-066): every decision row cites its receipt path as proof; issue-comment links stay as prose (the completion guard dereferences paths and merged PRs only) Pmat-Ticket: PMAT-1071 * docs(PP-066): kaizen — never bare git stash (shared stack); the complexity hook charges a file's whole include! expansion, declare modules from a clean included file Pmat-Ticket: PMAT-1071 * docs(PP-066): R-5 delta v6.1 — build != test; x86_64-cuda on lambda only in release-assets.yml at refs/tags/v*; base-owned promotion; derived fail-closed publish cascade; KEY row (paiml#3045, PMAT-1079); spec v2.1 Spec v2.1 (Appendix A 2.1) and DAG (103 rows) record the delta of 2026-09-08: - BUILD != TEST. Assets build under the clean-room recipe (scripts/run_clean_room.sh, the forjar-pinned toolchain, fingerprint recorded); GPU verification is the fleet-verify receipt taken against the asset, never a build log. - The x86_64-cuda asset (= apr-x86_64-unknown-linux-gnu, cli,cuda per D-10) builds on lambda only inside release-assets.yml at a v* tag: runner group gpu-release restricted to that workflow at refs/tags/v*, a JIT ephemeral runner for one job, lambda's queue slot claimed (host_queues.lambda 4; S-1 -> 5, S-2 -> 6). Every other target: the CI clean-room runner. - Promotion is a base-owned workflow_dispatch job over four receipts carrying the asset sha256 with C14 PASS and parity != skipped. No workflow runs cargo publish; scripts/publish_cascade.sh derives its set from cargo metadata in topological order and refuses branch/dirty/prerelease/token. - New row KEY (paiml#3045, PMAT-1079, owner noahgift, expiry 2026-10-02 [U]): until keys/apr-release-minisign.pub is on main the manifest job and the C13 gate refuse and R-5 stays blocked_by KEY; DONE-IF present -> R-6 pins its fingerprint. R-5/R-6/TAG-0.66.0 <- KEY. The gpu-release group stays a blocked_by: RUNNER-GROUP note on R-5, as the delta directs. - R-5 <- G-11b: make fleet-verify is G-11b's deliverable and is absent today [V]. Two corrections this session's verification pass found by measuring rather than reading: - The delta's embedded-SASS premise is false for this binary. apr generates PTX text in Rust (crates/aprender-gpu/src/ptx/) and the driver JIT-compiles it, cubins landing in ~/.cache/trueno/ptx (driver/ptx_cache.rs:3), so nothing SASS-shaped ships. The A now requires cuobjdump --list-elf to list NO ELF and reads the emitted PTX's .target on both hosts. - PMAT-1078 was not free: agent/R-5's contracts/apr-publish-cascade-v1.yaml:4 stamps it. KEY took PMAT-1079. An id is taken the moment a branch writes it, minted or not (pmat#1169 class). Also recorded: the three divergences of agent/R-5 (authored at 19c015f before this delta) that the row PR closes - an aarch64-cuda asset on gx10, .github/release-assets.pub, hosted builders; its promotion gate and cascade already match [V]. G-11's typed status flipped to complete from docs/audits/impl-PMAT-1062-receipt.md (paiml#3020 merged 3792afa) and the §5.0 block re-rendered - D7 and render_dag.py --check were RED on this branch before this commit. Guards on this tree: render_dag.py --check PASS (byte-identical, 103 rows) - check_dag_invariants.sh PASS - check_receipt_complete.sh --dag PASS - check_roadmap_diff_additive.sh PASS (lifecycle only; acceptance_criteria is not a lifecycle field) - check_roadmap_ids_unique.sh PASS (822) - check_no_claim_literals.sh PASS - check_perf_claims_cite_receipts.sh PASS - check_row_pr_write_set.sh ok (orchestrator branch). Pmat-Ticket: PMAT-993 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X1cW8TnmNe3hgjragNjUxr * docs(PP-066): collapse the PMAT-1074/PMAT-1077 roadmap re-serialisation back to base bytes The 2026-09-08 merge re-ordered two planned entries; check_roadmap_diff_additive.sh (PMAT-980) reads that as a re-serialisation and refused, which took `gate` down through guard-tree. scripts/roadmap_trim.py restores the base ordering; no field changed in either entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): the roadmap keeps its SORTED order; PMAT-1077's block bytes differ only by a stray blank line Two guards disagreed on the same file and the first fix satisfied the wrong one. check_roadmap_diff_additive.sh (G-6) called PMAT-1077 re-serialised, so 5e2bd40 ran roadmap_trim.py, which restores base ORDER — and base order puts PMAT-1074/1077 before PMAT-1069..1073, which check_roadmap_sorted.sh (BSE-09a) then refused: "PMAT-1069 at line 16527 sorts before PMAT-1077 earlier in the file". The actual cause is neither ordering. `classify_pair` compares the entry BLOCK text, and a block runs to the next `- id:`; PMAT-1079 had been appended with a blank line before it, so PMAT-1077's block carried a trailing empty line that main's copy (where PMAT-1077 is last in the file) does not have. One blank line, no field changed. Dropping that blank line makes PMAT-1077's block byte-identical to main's AND keeps the sorted insertion 1069 → 1079. Both guards pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * feat(G-11b): track scripts/pp066_state.sh and scripts/session_docs_commit.sh — the STATE and SESSION-END tools Both have been in use for several sessions as working-tree files and were never committed. That is the "free pass while untracked" trap running the other way: check_shell_lint_ratchet.sh's universe is `find scripts -maxdepth 1 -name '*.sh'` (the working tree, not `git ls-files`), so an untracked script already counts against the ratchet while no reviewer can see it. session_docs_commit.sh was contributing one such error line — bashrs 7.0.1 reads the `do` of a `for` nested inside a single-line `if ...; then ...; fi` as the `if`'s body opener (SC2136) — so the kaizen block is expanded onto its own lines. 177 scripts, 8 error lines, baseline 8, PASS (ratcheted). Refs PMAT-1066, paiml#3018 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): paiml#3022 and paiml#3024 join the 0.66 scope as rows F-1 and F-2 (operator ruling 2026-09-08) F-1 (PMAT-1080, paiml#3022, P0): `apr chat` silently loaded its built-in Demo model for a sharded SafeTensors index — exit 0, zero tokens, the real model's path printed in the banner. `Path::extension()` returns the last dot-segment, so on `model.safetensors.index.json` (the exact filename `apr pull` writes and recommends) it is Some("json") and matched no arm. Shipped in PR paiml#3050 as a structural fix, not an added arm: `resolve_chat_format` is one decision — suffix before extension, then magic bytes, then a refusal from error.rs — and Demo is not an outcome for a path that exists. F-2 (PMAT-1081, paiml#3024 ask 3, owner bse): the live matrix runs nightly against real models, and the two axes still uncovered — an `apr serve` column and a sharded-GGUF row (merge_gguf_shards, for which no fixture builder exists) — are named rather than dropped. The rows earn their place in a rescoped 18-row release by claim (1): apr reports truthfully and never silently substitutes what the user named. paiml#3022 is the strongest instance of that failure in the tree — the substitution reported SUCCESS — and paiml#3024 is why it survived: qwen-story-daily was green the same night and structurally could not have caught it (`grep -c "apr chat"` is 0, `grep -c index.json` is 0). DAG 103 -> 105 rows, 0.66 lane 32 -> 34; invariants PASS (violations=0); the spec's §5.0 block re-rendered byte-identical; roadmap 824 -> 826, sorted, unique, additive. Refs paiml#3022, paiml#3024, paiml#2873 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): session 2026-09-08 — tickets minted, PMAT-1062 completed, status doc, six kaizen lines Minted by hand (pmat#1169, `pmat work add` collides): PMAT-1082 for L0-1b (paiml#2971 — the root cause is named: a crushed Q8_K activation block routes that matmul to the f32-activation kernel, and the CPU reference was the inaccurate side, not the GPU) and PMAT-1083 for SPEC-2.0 (paiml#3023). PMAT-1062 (G-11) flipped to completed — its receipt says complete and PR paiml#3038 is merged. Kaizen, all six from defects met today: * two guards disagreed about roadmap.yaml and the first fix satisfied the wrong one; the cause was neither ordering but a blank line inside the previous entry's compared BLOCK * `. scripts/apr_bin.sh` does not honour CARGO_TARGET_DIR (it reads cargo metadata's target_directory); APR_BIN is the documented pin * evidence need not carry a machine path — invoke the tool relatively and compare the two outputs field by field before claiming they are the same measurement * N identical evidence files are one file plus a sha256 * a gate's RED leg is cheap: build the merge base in a second worktree * a second host can refute a hypothesis class before a lane is dispatched DAG 105 rows, invariants PASS; §5.0 re-rendered byte-identical; roadmap 828 entries, sorted, unique, additive; README counts exact. Refs paiml#2873 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): drop docs/specifications/DOCUMENT_TEXT_MAP.md — session scratch, committed by an over-broad `git add -A docs/` It is a flat concatenation of the spec at v1.5, produced by an earlier session as a reading aid and left untracked. Committing it would put a STALE second copy of PP-066-release-spec.md (v1.5 against the tree's v2.1) under docs/specifications/, where the claims ratchet and every doc guard would then have two sources for the same text. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): session 2026-09-08 part 2 — five kaizen lines, status doc refreshed All five from defects met in this segment: two of my own PRs shipped a falsifier no workflow executed; a new test-selection tier surfaced a test that had been RED on clean main and unrun; an anchored grep meant to fix a pass-grep was itself a false green; the release had two candidate signing-key paths; and a textual guard was answered with an allowlist entry and a reason rather than by rewording the file to dodge its regex. Refs paiml#2873, paiml#3051 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): the kaizen file tripped its own lesson, plus two more lines Kaizen line 5 quoted a throughput literal while explaining how a textual guard flags a must-match fixture — and docs/ is exactly the surface the claims ratchet reads, so the line about textual guards was refused by one. De-literalised; the fact is unchanged. Two new lines: the claims ratchet's aperture is the `///` vs `//` boundary and a refactor can cross it (R-0b promoted rationale comments into rustdoc, turning four numbers main already carried into published speed claims; re-baselining a MOVED line is refused by design because the ratchet is set-based); and: run the shared guards across every branch in one pass — three guards over six worktrees took minutes and found four failures CI had not reported yet, each of which would otherwise have cost a serial ~1h cycle. Refs paiml#2873 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): D-13 — 0.66 ships checksummed, UNSIGNED assets; KEY moves to 0.67 Operator, 2026-09-08: "skip it and deprioritize". Signing was the only step on the release path that needed a human, and it was gating a release whose three claims do not include provenance. * KEY (PMAT-1079, paiml#3045) -> lane 0.67, first row of the provenance track * R-5 (PMAT-993) and R-6 (PMAT-994) drop KEY from blockers — both unblocked * C13's command drops "+ minisign signature" * 0.66 lane 34 -> 33 rows; invariants PASS; §5.0 re-rendered byte-identical WHAT THIS COSTS, STATED RATHER THAN ABSORBED. Claim (3) keeps its INTEGRITY reading and loses its AUTHENTICITY one. A sha256 still proves the asset matches the manifest the release job produced, and the four host receipts still prove that sha256 is what was tested. It does not prove WHO produced it: the manifest and the assets live in the same GitHub release, so whoever can replace an asset can replace its checksum. So the release must say so, in the three places a user could otherwise infer otherwise: the notes' install section, R-6's installer output at install time, and the vocabulary — no artefact, script, contract or note may call a 0.66 asset "signed" or "verified". Those four obligations are recorded on the decision (paiml#2873) and are what makes the smaller claim honest rather than merely smaller. Refs paiml#2873, paiml#3045 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): D-14 — 0.66.0 is the CUDA parity fix and nothing else (26 -> 5 open rows) Operator, 2026-09-08: "lets reduce scope as goal is mainly to fix CUDA issue". 0.66.0 now makes ONE of the mission's three claims — (2): every model in the manifest computes the same function on GPU as on CPU, or the GPU refuses it. Claims (1) and (3) move to 0.67 IN FULL, and the notes will say so rather than leave it inferable. KEPT (12 rows, 7 already complete, 5 open): L0-1b (the fix — a crushed Q8_K activation block routes that matmul to the f32 kernel; 1.5B 0.9508 -> 0.999761 on lambda and 0.950611 -> 0.999583 on gx10, first_divergence none on both), L0-1a (what makes it checkable and the failure honest: derived manifest, C14, the >=64-position rule, the measured threshold, REG-15's refusal instead of a silent downgrade), F-1 (the same class one layer up, already measured and armed), SPEC-2.0, TAG-0.66.0. CUT to 0.67, each row now carrying `cut_by` and the `claim_protected` it was defending: R-0/R-0b/R-2 (registry, apr devices, dogfood-reads-registry — claim 1), R-3 (training banner), R-5/R-6/R-7/R-8 (assets, installer, README-first, nightly install — claim 3), C0-1/C0-2/C0-4 (credit gates: they gate CREDIT, not correctness — I9), G-10b/G-11b (tooling), F-2 (the nightly format matrix). TAG-0.66.0's blockers reduce from 19 to the 6 kept rows. NO release assets and NO installer in 0.66 — `cargo install aprender` is the only supported install, which with D-13 (checksummed, not signed) means claim (3) is not made at all rather than made weakly. scripts/publish_cascade.sh is cherry-picked from agent/R-5; the rest stays behind. DAG invariants PASS (105 rows, 0 violations); §5.0 re-rendered byte-identical. Refs paiml#2873, paiml#2971, paiml#3022 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * fix(PP-066): every PP-066 ticket's kind: label is DERIVED from its DAG row — paiml-implement was refused on 80% of the epic `paiml-implement` refuses at Phase 0 (`kind-gate.sh`, AUTO-IMPL-SKILL-001 T-1) unless the ticket's roadmap entry carries `kind:<code|triage|docs|measurement>`. Attempting to run it on R-5/PMAT-993 returned exit 2, and it was not one ticket: PP-066 tickets in docs/roadmaps/roadmap.yaml : 105 carrying a kind: label : 21 NOT carrying one : 84 The label is now DERIVED, not typed, because the DAG already says it: SPEC-/DEC-/TAG- rows are docs; a row with a command-shaped acceptance or a contract is code. 103 entries written, derived=103 missing=0 wrong=0, and `check_kind_labels_derived.sh` refuses drift in either direction (a missing label AND a label that disagrees with its row). TWO rows are UNDECIDABLE and are REPORTED rather than guessed — refusing to guess is not refusing the tree, so they do not fail the guard: G-2 (PMAT-985) "one line in spec §0 with decided_by and date" — correctly prose, a docs row R-8 (PMAT-1067) "the workflow is green once on all four hosts" — a PROSE acceptance on a code row, which is the "a prose test: never runs" defect in another costume MY OWN FIRST DRAFT SHIPPED THE DEFECT THIS GUARD EXISTS TO PREVENT, and it is worth the record: it read the roadmap by line regex in both directions. `--update` then CORRUPTED the file — 284 entries carry the inline `labels: []`, which has no ` - ` block to scan, so the insert landed after a flow sequence and the YAML stopped loading — and `--check` reported `missing=0 wrong=0` on the wreckage, because a regex reader cannot see a parse error. A writer that can break the file its own checker reads is exactly the class this guard is for. Fixed both ends: the verdict now PARSES the roadmap, the writer handles the inline form, and it refuses to write a rewrite that does not parse or that loses an entry. The case-table fixture carries both label forms so the corruption cannot come back. Case table 7/7, both polarities. No ci.yml edit needed: guard_tree.sh's universe is `git ls-files 'scripts/check_*.sh'`, and the guard advertises `--self-test` in its usage, so the dispatcher gives it both rows. check_guards_are_wired PASS, roadmap sorted/unique/additive PASS (828 entries, 0 non-label fields changed). Refs paiml#2873, PMAT-1093 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * docs(PP-066): mint PMAT-1093 and PMAT-1094 by hand PMAT-1093 was cited by the kind-label commit and never existed — a Refs pointing at nothing, which is the small version of the defect pmat#1240 describes. Minted retroactively as `completed` with its acceptance command and `proof:` path. PMAT-1094 (paiml#3055): the `*-lint --json` outcome surface emits three shapes for one field, one of them a Rust `Debug` string in a JSON API. Found sweeping paiml#3051; the tests in paiml#3053 accept all three deliberately and document the table, so this ticket's falsifier is the DELETION of `assert_outcome_ok`'s two string arms. Both by hand: `pmat work add` mints colliding ids (pmat#1169), and now pmat#1240 — two agents minting in parallel branches land on the same id and the merge deletes one, with `work validate` passing because uniqueness is preserved by the loss. roadmap 828 -> 830, sorted, unique; kind labels derived=103 missing=0 wrong=0. Refs paiml#2873, paiml#3055 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * fix(TAG-0.66.0): the release's first step can return a verdict, and its credited set is derived `scripts/release_criteria.sh --all` is step 1 of the release sequence. It could not produce a verdict: measured 2026-09-08, C0, C4, C7 and C8 each hit a 120 s timeout and --all ran past ten minutes with nothing printed. Three defects, one of them mine to have noticed sooner. 1. C0 RE-RAN FOR EVERY CRITERION. `run_one` gated each criterion on `bash "$0" C0` (I9's credited-first rule), and C0 shells out to `pmat comply check` AND a `gh api` call. Nine criteria therefore paid that cost nine times. It is now evaluated ONCE per process and only while C0 is itself in the credited set. C7 alone runs in 57 s; through the old gate it timed out at 120 s. 2. THE CREDITED SET WAS STALE AFTER D-14 and is now DERIVED, not chosen: a criterion is credited iff at least one row the spec's §4 table names as its owner is still lane 0.66. C7 SPEC-2.0 KEEP the claims ratchet — load-bearing for D-13/D-14's vocabulary C8 SPEC-2.0 KEEP clean-room before publish; cargo publish rests on it C9 C0-7 KEEP every credited row has a complete receipt C14 L0-1a KEEP GPU = CPU per manifest model, or the GPU refuses it — 0.66's ONE claim C0 C0-1/2/4 MOVE all 0.67; keeping it made --all both unpassable and unrunnable C4 R-6,R-2 MOVE four host receipts THROUGH the R-6 installer, which 0.66 does not ship C6 G-10a… MOVE two owners are not rows at all; its script does not exist (ENV 2) C11 R-0a/0b MOVE the backend registry is 0.67 C13 KEY,R-5,R-6 MOVE no assets and no installer in 0.66 (D-13, D-14) 3. THE SUCCESS BANNER CARRIED A SECOND, HAND-TYPED COPY of the list, so editing the set would have left it asserting the old one. It prints $CREDITED now. Two new self-test rows, both mutation-proven: hand-editing CREDITED to add C13 turns the derivation row RED (6/7), restoring it returns 7/7; and the banner row greps the source for a literal `ALL CREDITED (C…` and refuses one. CORRECTING MY OWN EARLIER READING: not all of the ten minutes was a defect. C8 is `make -C machines/clean-room clean-room-p1`, a real multi-minute docker build, and it is SUPPOSED to be slow — it is the hard gate before publish. Worth naming separately: the release sequence runs `release_criteria.sh --all` and then `run_clean_room.sh`, so the clean room currently builds twice. Current state on this branch: C7 CREDITED (57 s), C9 CREDITED (0 s), C14 ENV 2 — `scripts/check_model_parity.sh` lives on agent/L0-1, which is in the merge queue — and C8 is the long build. C14's ENV is the correct answer, never a pass. Refs paiml#2873, PMAT-1083 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * evidence(TAG-0.66.0): C14 runs live and PASSES over the manifest — 0.66's single claim, measured L0-1a landed (paiml#3026), so scripts/check_model_parity.sh is on main and C14 stopped being ENV. Run verbatim as the criterion defines it, on lambda, with a cuda apr built from agent/L0-1b (sha256 776cbbdb4306b5d8 — the tree carrying L0-1b's fix): PASS qwen2.5-coder-1.5b-instruct: 78 positions, min cosine 0.9998 at position 36 PASS qwen2.5-coder-0.5b-instruct: 78 positions, min cosine 0.9996 at position 0 PASS qwen2.5-coder-7b-instruct: 78 positions, min cosine 0.9996 at position 22 C14: measured=3 rc=0 The first row is the model paiml#2971 is about. It read 0.950827 on this host before the fix and reads 0.9998 after, against a threshold whose basis is two measured known-good pairs across two GPU architectures. Fourteen models are UNMEASURED because this host does not hold them, and the script REPORTS rather than fails — no single host holds every model the README names, and the fleet-level rule belongs to the release. From the outside, `apr chat --gpu` on the 1.5B now prints `[GGUF CUDA: NVIDIA GeForce RTX 4090 …]` and answers correctly, with no `falling back to CPU` anywhere in the output. ONE GAP, NAMED RATHER THAN GLOSSED: the driver's Resolved criterion asks for `selected: cuda … parity: PASS` on the success path, and that line does not appear — REG-15's admission line is printed by `on_cuda_load_error`, so it is emitted only when something goes wrong. Reporting the selection only on failure is weaker than the criterion asks. That belongs to claim (1), which D-14 moved to 0.67 with R-0b; 0.66 makes claim (2), and claim (2) is what the table above measures. Refs paiml#2971, paiml#2873 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * fix(B3): one parity contract, not two — L0-1a's apr-gpu-cpu-parity-v1 folded into the one with 11 falsifiers Epic paiml#3058 §B3: do not create contracts/apr-gpu-cpu-parity-v1.yaml; extend contracts/apr-cpu-vs-gpu-output-parity-v1.yaml, which already exists with 11 falsification tests. L0-1a shipped the duplicate anyway (paiml#3026, merged), so this removes it. Verified before acting, not taken on faith: the existing contract carries 11 FALSIFY ids and 58 KB of history; mine carried 3 obligations and 3 falsifiers in 10 KB. THE TWO ARE THE SAME ARGUMENT SPLIT IN HALF, which is the real cost B3 names. The existing contract already records the paiml#1864 five-whys whose root cause is "the gate's domain was too narrow (single-step instead of multi-step)" — and L0-1a's >= 64-position horizon rule is the answer to exactly that. Half the reasoning sat in each file. Ported as FALSIFY-CPU-GPU-012/013/014, each with the mutation that turns it RED: 012 the manifest is derived, never typed derive_model_manifest.sh --self-test (6/6) 013 the domain is >= 64 positions, both check_model_parity.sh --self-test (9/9) polarities on BOTH required GPU hosts 014 a forced backend never downgrades cargo test --test reg15_admission (7/7) All three re-run here, green. `pv validate`: 0 errors, 14 falsifiers. THE STALE ANCHOR, AND A SHARPER VERSION OF B3's POINT. B3 is right that the contract cites `mod.rs:268-279` for the SKIP_PARITY_GATE bypass and that :268-279 is something else (a doc comment about qtype resolution). But B3's proposed replacement, `:333`/`:349`, had ALREADY DRIFTED by the time I read it — L0-1a and L0-1b moved the bypass to :390/:406 on this branch. The fix for a drifting line anchor cannot be a different line anchor, so both live citations now anchor on the SYMBOL (`grep for the literal SKIP_PARITY_GATE`) and say why. The 1.1.0 changelog entry keeps its line numbers: it is history, and history is allowed to be stale. References repointed in the DAG (4), the spec table, parity_admission.rs, reg15_admission.rs and .pr/L0-1/accept.sh. DAG invariants PASS; §5.0 re-rendered byte-identical. Refs paiml#3058, paiml#2971, paiml#2873 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * evidence(F1): the model dogfood run BY HAND on both GPU hosts — four cells, and one result stronger than the gate asks for Epic paiml#3058 §F1: run it by hand on lambda-labs and gx10, needing none of the missing automation. Four cells for the 7B — {lambda-labs, gx10} x {cpu, gpu} — as §5.5 receipts under docs/audits/release/v0.66.0-pre/models/. M3 parity over >= 64 positions GREEN on both GPU cells: 78 positions, 283 op rows, first_divergence None; lm_head 0.99958 (lambda) and 0.99978 (gx10); worst op ffn_out@L23 0.994065 and attention@L22 0.996844 M4 determinism GREEN, all four cells M6 7B service smoke GREEN, all four cells — loads, non-empty output, zero OOM THE RESULT WORTH MORE THAN ANY SINGLE CELL: the greedy stream sha256 is 6f38f13e5debd285 in ALL FOUR cells. Same model bytes, two architectures (x86_64 sm_89 and aarch64 sm_121) and both backends produce a byte-identical token stream. M4 only asks for determinism WITHIN a cell; this is determinism across the fleet. MY FIRST M4 RUN REPORTED NO, AND MY INSTRUMENT WAS WRONG. It compared whole stdout, whose last line is `Completed in 12.63s` — a clock, not a nondeterminism. The generated text was byte-identical both times. The comparator now strips that line, which is the same rule this repo already enforces on required gates: no wall-clock assertion inside a correctness check. EXCLUSIONS ARE NAMED, NEVER SKIPPED, because §5.5 says a missing cell is NO-GO: M1 artifact identity 0.66 ships no assets and no manifest (D-13, D-14) — nothing to compare M2 registry readback `apr devices` is R-0a, 0.67 M5 refusal semantics PARTIAL — the FX fixtures are R-0a; the admission level is covered by reg15_admission 7/7, now FALSIFY-CPU-GPU-014 in the parity contract M7 transport parity NOT RUN — needs a port and a client; named, not dropped M8 performance NOT RECORDED DELIBERATELY — the claims ratchet refuses a throughput literal on a documented surface and 0.66 makes no speed claim VERDICT WITHHELD, on purpose. Each receipt says "not GO and not NO-GO": this is a dry run on a pre-tag directory, and a receipt calling itself GO with M1 and M2 structurally excluded would be the theater §1.1 forbids. Refs paiml#3058, paiml#2971, paiml#2873 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018RouwmUL7vFfJyCx9qLEoH * roadmap: PMAT-1062's `completed` cites its proof (BSE-01) check_roadmap_completion_is_cited.sh went RED on this branch: PMAT-1062 said `status: completed` with `github_issue: null` and `notes: null`, so nothing could dereference the claim. Checked before citing rather than after, because the guard's own precedent (PERF-004) is an entry marked completed whose PR was closed unmerged. All three things the title names are on origin/main: guard job runs all, reports all guard_tree.sh + the guard-tree job, paiml#3037 (git log -S' guard-tree:' names ff122fa) aprender timeout-minutes paiml#3037 added timeout-minutes 90/90/22 CARGO_TARGET_DIR per container all six container steps carry -e CARGO_TARGET_DIR=/workspace/target So `completed` is honest and the fix is the citation, not the status. The edit is applied through a YAML load/verify rather than a regex rewrite -- my own kind-label guard corrupted this file once by treating it as text, and reported missing=0 wrong=0 on the wreckage. Entry count asserted unchanged (830) and the citation asserted present after the write. Verified: check_roadmap_completion_is_cited.sh PASS; guard_tree.sh --no-cargo 41 checks, 0 failed. Refs paiml#3025 Pmat-Ticket: PMAT-1083 * docs: README CONTRACT_COUNT states 1816 — this branch removes the duplicate parity contract guard-cargo's "README claims must match measurement" was RED: the README said 1817 (main's count) while this branch's tree carries 1816. The one-file delta is contracts/apr-gpu-cpu-parity-v1.yaml, deleted here per epic paiml#3058 §B3 — the instruction was to extend the contract that already had 11 falsifiers rather than mint a second one over the same property, and the duplicate had already merged on L0-1a. Re-derived with `make readme-sync`, which reads `find contracts/ -name "*.yaml"` and rewrote both CONTRACT_COUNT blocks. Not hand-edited. Refs paiml#3025 Pmat-Ticket: PMAT-1083 --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

noahgift added 3 commits September 6, 2026 12:54

docs(G-10): impl receipt PMAT-1059 (status: partial) — root cause cit…

0c35f8c

…ed from the job logs, quorum verdict and per-finding disposition, verification claimed vs re-run, gaps G-10b/G-10c/PMAT-1061 Pmat-Ticket: PMAT-1059

noahgift enabled auto-merge September 6, 2026 11:13

noahgift added this pull request to the merge queue Sep 6, 2026

Merged via the queue into main with commit b0a0a51 Sep 6, 2026
15 of 17 checks passed

noahgift deleted the agent/G-10 branch September 6, 2026 13:52

noahgift added a commit that referenced this pull request Sep 6, 2026

docs(PP-066): DAG row G-10 complete (#3011 merged b0a0a51); §5.0 re-r…

6230398

…endered Pmat-Ticket: PMAT-1059

noahgift mentioned this pull request Sep 24, 2026

G-10: check_hardcoded_paths.sh --full-if-capable arms at pmat >= 3.32 while the fleet runs 3.31 — under pmat 3.37 main is 317 shipped findings vs baseline 277, so the fleet upgrade turns every PR red #2999

Closed

Navigation Menu

fix(G-10, PR-A): the shipped-path ratchet runs under ONE pinned analyser — stamped baseline, differential HEAD vs base under the same binary, never the tree against itself (PMAT-1059) - #3011

fix(G-10, PR-A): the shipped-path ratchet runs under ONE pinned analyser — stamped baseline, differential HEAD vs base under the same binary, never the tree against itself (PMAT-1059)#3011
noahgift merged 3 commits into
mainfrom
agent/G-10

noahgift commented Sep 6, 2026

Uh oh!

github-actions Bot commented Sep 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

noahgift commented Sep 6, 2026

Root cause, cited from the job logs (not inferred)

What this PR does

Mutations — RED then GREEN, each observed

Acceptance, re-run by the orchestrator (the quorum lanes ran no commands; every lane claim was re-verified)

Review quorum

Deployment precondition (why this is green on the runner)

Not in this PR

Uh oh!

github-actions Bot commented Sep 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant