@magnusekdahl/parallix 1.5.289 → 1.5.317

package/NOTICES

@@ -1,4 +1,4 @@
-THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.289
+THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.317
 
 @magnusekdahl/parallix itself is licensed under AGPL-3.0-or-later; see LICENSE.
 
@@ -7,7 +7,7 @@ third-party packages listed below are statically inlined into that payload by
 the build, so their notices are reproduced here. This file is generated by
 scripts/release-metadata.ts from package-lock.json; do not edit it by hand.
 
-Bundled third-party packages: 82
+Bundled third-party packages: 83
 
 ==============================================================================
 INDEX
@@ -57,6 +57,7 @@ ink@6.8.0 — MIT — vadimdemedes/ink
 ipaddr.js@2.5.0 — MIT — git+https://github.com/whitequark/ipaddr.js.git
 is-fullwidth-code-point@5.1.0 — MIT — sindresorhus/is-fullwidth-code-point
 is-in-ci@2.0.0 — MIT — sindresorhus/is-in-ci
+jevtok-ts@0.2.0 — MIT — https://github.com/aarzhaev/jevtok-ts#readme
 json-schema-ref-resolver@3.0.0 — MIT — https://github.com/fastify/json-schema-ref-resolver#readme
 json-schema-traverse@1.0.0 — MIT — https://github.com/epoberezkin/json-schema-traverse#readme
 light-my-request@6.6.0 — BSD-3-Clause — https://github.com/fastify/light-my-request#readme
@@ -830,6 +831,138 @@ LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 THE SOFTWARE.
 
+------------------------------------------------------------------------------
+jevtok-ts@0.2.0 (MIT)
+------------------------------------------------------------------------------
+
+MIT License
+
+Copyright (c) 2026 Alexander Arzhaev
+Copyright (c) 2026 LabGuy94
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+# Third-party notices
+
+## jevtok (MIT)
+
+The tokenizer and request accounting are a TypeScript port of [LabGuy94/jevtok](https://github.com/LabGuy94/jevtok), pinned to commit `698c53b778ce901be82c166d809e4b1f7948a465`.
+The Jev lookup/merge bitmaps and test fixtures are copied without modification from that revision. Fixture `source` labels are retained; the public fixture corpus is a subset of the upstream author's reported research corpus. Fixtures are not shipped in the npm artifact.
+
+```text
+MIT License
+
+Copyright (c) 2026 LabGuy94
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```
+
+## o200k_base vocabulary / tiktoken (MIT)
+
+Vocabulary from [OpenAI tiktoken](https://github.com/openai/tiktoken), downloaded from the URL and verified against the SHA-256 recorded in `data/manifest.json`. No tiktoken runtime is shipped.
+
+```text
+MIT License
+
+Copyright (c) 2022 OpenAI, Shantanu Jain
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+```
+
+## Unicode character data
+
+Character-class ranges are generated from Python regex 2026.9.10 Unicode properties; no regex package implementation code is included.
+
+```text
+UNICODE LICENSE V3
+
+COPYRIGHT AND PERMISSION NOTICE
+
+Copyright © 1991-2026 Unicode, Inc.
+
+NOTICE TO USER: Carefully read the following legal agreement. BY
+DOWNLOADING, INSTALLING, COPYING OR OTHERWISE USING DATA FILES, AND/OR
+SOFTWARE, YOU UNEQUIVOCALLY ACCEPT, AND AGREE TO BE BOUND BY, ALL OF THE
+TERMS AND CONDITIONS OF THIS AGREEMENT. IF YOU DO NOT AGREE, DO NOT
+DOWNLOAD, INSTALL, COPY, DISTRIBUTE OR USE THE DATA FILES OR SOFTWARE.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of data files and any associated documentation (the "Data Files") or
+software and any associated documentation (the "Software") to deal in the
+Data Files or Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, and/or sell
+copies of the Data Files or Software, and to permit persons to whom the
+Data Files or Software are furnished to do so, provided that either (a)
+this copyright and permission notice appear with all copies of the Data
+Files or Software, or (b) this copyright and permission notice appear in
+associated Documentation.
+
+THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
+KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF
+THIRD PARTY RIGHTS.
+
+IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE
+BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES,
+OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
+WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE DATA
+FILES OR SOFTWARE.
+
+Except as contained in this notice, the name of a copyright holder shall
+not be used in advertising or otherwise to promote the sale, use or other
+dealings in these Data Files or Software without prior written
+authorization of the copyright holder.
+```
+
 ------------------------------------------------------------------------------
 json-schema-ref-resolver@3.0.0 (MIT)
 ------------------------------------------------------------------------------

package/README.md

@@ -84,7 +84,7 @@ Running several agents in parallel is only worth doing if you can trust what com
 3. **Your existing checks at lifecycle transitions.** Connect your test pyramid by assigning existing test commands to the stages where you want them to run. For example, run fast unit tests and static analysis before a mission moves from `active` to `review`, and reserve expensive integration and end-to-end suites for the final merge. Parallix runs the selected commands and blocks progress when they fail. The [lifecycle check configuration](docs/config.md#lifecycle-gates) shows how to connect those commands to each stage.
 4. **Defences tailored to the mission.** Parallix instructs the drafting agent to investigate the codebase and mission, define concrete success criteria, and select suitable verification commands. For bug fixes, it calls for a failing reproduction test before implementation. The mission's declared checks run before it moves from `active` to `review`, turning the plan into checks on the delivery.
 5. **Evidence for review.** Before a mission moves from `active` to `review`, Parallix checks that the final checkpoint connects success criteria to concrete references, such as tests or runnable repository commands. Missing mission or checkpoint documents block that transition. Reviewers get a stated goal and supporting evidence to examine; generic claims such as “verified” are insufficient.
-6. **Separate review.** A second agent reviews the delivery, using a different agent family when one is available. The pull request author cannot formally approve their own work. For eligible repeat findings, Jev can classify the repair from revision-pinned evidence and clear the finding set or return it to the implementer. This runs by default when Jev and its review identity are available; uncertain evidence and broader changes go to the general reviewer. Operators can [opt out](docs/config.md#repeat-review-classification).
+6. **Separate review.** A second agent reviews the delivery, using a different agent family when one is available. The pull request author cannot formally approve their own work. On any review round, Jev can judge the prior findings, a repaired integration failure or, on a first review, the mission success criteria from revision-pinned evidence, then clear them or return them to the implementer. This runs by default when Jev and its review identity are available; uncertain evidence and broader changes go to the general reviewer. Operators can [opt out](docs/config.md#review-classification).
 7. **Automatic, focused repair.** When checks detect a repairable delivery failure, Parallix sends the agent back with a tight prompt containing the specific failure, captured output, and the repair required. It reruns the failing check to confirm the fix. Retries are bounded, and unresolved failures are surfaced to the operator.
 8. **Validate the final tree before merge.** When you choose to integrate an approved mission, Parallix runs the checks you assigned to integration against the exact tree about to land. This is where the broader tests from your pyramid check that the change works with the rest of the system. A failing check stops the merge.
 9. **Operator decision.** Nothing merges itself. A human reads the diff and decides whether to integrate at all.

package/build/asset-manifest.json

@@ -3,7 +3,7 @@
   "assets": [
     {
       "key": "config/agents.json",
-      "sha256": "c380d909ddf757f9bbe5136d79652a19396ae69068d144e2b6031ed4b7fb4b78"
+      "sha256": "ec3ec505e42adc8cddc17651d7a1a85b6359a433e1e62f3c6c22a4896150187f"
     },
     {
       "key": "config/state-map.json",
@@ -11,7 +11,7 @@
     },
     {
       "key": "prompts/act-on-review-core.md",
-      "sha256": "677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f"
+      "sha256": "6efbfc58fba6d4224ac05d23c3b08ca2ce33b11e67cae63adef07ceda9fa5125"
     },
     {
       "key": "prompts/act-on-review.md",
@@ -27,7 +27,7 @@
     },
     {
       "key": "prompts/execute-core.md",
-      "sha256": "e571826c71ad14cf0156ef7fc99bf273fa6af2752c01e627238f3c6b5bdb63e1"
+      "sha256": "1db19f3697c6e27baf87dc984b8b03e846359d63b495dc19e1ac78c97982cc8a"
     },
     {
       "key": "prompts/execute.md",
@@ -35,7 +35,7 @@
     },
     {
       "key": "prompts/review-core.md",
-      "sha256": "e6c0aa4683fac33f41b79fb27407cd3c9de384239d2b1067e2b30acb5e7fecb0"
+      "sha256": "607d968e782bd9647e15a6aea3eb7705f0d83b61eb39c220eeb6f3fc00fa6098"
     },
     {
       "key": "prompts/review.md",
@@ -168,6 +168,18 @@
     {
       "key": "migrations/0030-review-classification.sql",
       "sha256": "746f8bf0b0edb91367dd426fc926264e803c7d17ede8689ad2a8457757002a7c"
+    },
+    {
+      "key": "migrations/0031-goal-check-recorded-round.sql",
+      "sha256": "d0ab23bc2a56e89e4521bf70fc907d6f2bacae3aa21e055ebe8481e79ac5e637"
+    },
+    {
+      "key": "migrations/0032-goal-check-repaired-gate.sql",
+      "sha256": "ce4a14e002907e5f4d20cf902140dd220b18dcf5128960d771491aabcb26f85f"
+    },
+    {
+      "key": "migrations/0033-goal-check-repaired-gates.sql",
+      "sha256": "e6303934e715b0bf7ac1078abb7f2bd6e488a4b1e299d69c7612cc4ba2d1a578"
     }
   ]
 }

package/build/config/agents.json

@@ -3,15 +3,15 @@
   "_weights_comment": "Weights are relative integers (not percentages). Agent is selected by weighted random draw from eligible-and-supported set. Omit weights to use equal probability.",
   "steps": {
     "draft": {
-      "eligible": ["codex", "custom", "qwen", "vibe"],
+      "eligible": ["codex", "custom"],
       "selection": "random"
     },
     "active": {
-      "eligible": ["codex", "claude", "custom", "qwen", "vibe"],
+      "eligible": ["codex", "claude", "custom"],
       "selection": "random"
     },
     "review": {
-      "eligible": ["codex", "claude", "custom", "qwen", "vibe"],
+      "eligible": ["codex", "claude", "custom"],
       "selection": "random"
     }
   },

package/build/manifest.sha256

@@ -1,5 +1,5 @@
-08e99fe1707dd9d807cfc906dbc2ea87887085bf1231b9775ab8e5865ae4eb01  asset-manifest.json
-c380d909ddf757f9bbe5136d79652a19396ae69068d144e2b6031ed4b7fb4b78  config/agents.json
+7b2d18017dfdbb1ace49e7a99a073bf7d1d3f72e56776e72689a36d61636a615  asset-manifest.json
+ec3ec505e42adc8cddc17651d7a1a85b6359a433e1e62f3c6c22a4896150187f  config/agents.json
 6a4ec47387d1240e32967dc8e4ce54a15d69df2676b7a96ff72baafe996fef7d  config/state-map.json
 30a76fa3839753ddbfe312428dd1b7285ac1b8d0bd678fc79c79018ec6154f69  migrations/0001-initial-schema.sql
 a8a0febfb4e448a11a5a16b2227d5cc1959bf4594aadd6fd65ea764283020edd  migrations/0002-import-history.sql
@@ -32,20 +32,23 @@ a0c669ba6c6883bb498c59eb8a8a1688dc445de56520a22d7c0302b4a2fbf8b0  migrations/002
 0196b4d563b829467680704349e591085597cb59e34052df0d72b4b78892f51a  migrations/0028-review-revocation-cause.sql
 b4091b8c3d770f8ac5072745a234de10d6e02cc3c4f0e6497888629041b54e7e  migrations/0029-mission-success-criterion-completion.sql
 746f8bf0b0edb91367dd426fc926264e803c7d17ede8689ad2a8457757002a7c  migrations/0030-review-classification.sql
-5db10eda2b526f83090baf0f02ca31d7dfff1d22823f71bbeab0fa5f1101b599  package.json
-677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f  prompts/act-on-review-core.md
+d0ab23bc2a56e89e4521bf70fc907d6f2bacae3aa21e055ebe8481e79ac5e637  migrations/0031-goal-check-recorded-round.sql
+ce4a14e002907e5f4d20cf902140dd220b18dcf5128960d771491aabcb26f85f  migrations/0032-goal-check-repaired-gate.sql
+e6303934e715b0bf7ac1078abb7f2bd6e488a4b1e299d69c7612cc4ba2d1a578  migrations/0033-goal-check-repaired-gates.sql
+38510d5b9ca091b89dac8c374f47f2116694c07faebbdb9be0856eb935d752a2  package.json
+6efbfc58fba6d4224ac05d23c3b08ca2ce33b11e67cae63adef07ceda9fa5125  prompts/act-on-review-core.md
 412facaee4a56f6436317d6b228ff57cb0605aca88ca143056ab50895ef62eee  prompts/act-on-review.md
 794bc41c7ce01d3f5ec06aa4ae37c75dfc54079c1ca62062f231c45d91d9637b  prompts/draft-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/draft.md
-e571826c71ad14cf0156ef7fc99bf273fa6af2752c01e627238f3c6b5bdb63e1  prompts/execute-core.md
+1db19f3697c6e27baf87dc984b8b03e846359d63b495dc19e1ac78c97982cc8a  prompts/execute-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/execute.md
-e6c0aa4683fac33f41b79fb27407cd3c9de384239d2b1067e2b30acb5e7fecb0  prompts/review-core.md
+607d968e782bd9647e15a6aea3eb7705f0d83b61eb39c220eeb6f3fc00fa6098  prompts/review-core.md
 06431c3f965935db27b254164d3bfa66aa7cc2a5602031f181dcc5e32f3e5739  prompts/review.md
-103733eb66f5596c3be417ce2f48fa2dd0c7a6f98199a017090288b0fd0058b8  px.mjs
-420c601237630102601f28a9243148af35569cbe3e2df24be82c2d2c4ea06806  px.mjs.map
-e4f4497b62b0a329d019ce3633734461eba55e5a4be67640352f892187e9d65b  sbom.json
+fc37ee4be11716e2f2f4bfd6e8d36977df8710c119535d864b2db84151eb3202  px.mjs
+7d64339dfa0e7465f525f81e636a9bf04f90482e22fa135b55fd3d5d9b82177b  px.mjs.map
+2fcab12164ffe2b979404d112c09614fe80c266add18e43eb77d71880aa61b09  sbom.json
 64ceff9f8a45d1769c8e70b0545a554065ffd285aa33b862447cb2ac70d28093  templates/mission-scaffold.md
-3cd549801655754fd23632c7cda05fbc3bf3a7108965ad8ed7cd99244e292b71  web/assets/index-HfrsWWLp.css
-105c3e33c65a58dbf7d79cb030c4f4a3aeedecaac14e9e5515303bbcd88ce0f8  web/assets/index-Q1kufqqY.js
-67cce8af16fb67e1e84174298ad61ec960281fbe84a5d6292146211e9b66c75b  web/index.html
-214574cd1f7e48e8f8729079f7cb9f47c6555ace31f34cd13a9e87d2071779ba  web/manifest.json
+220047b42a8c93f13c7835807c7c513e2af7042a900a2ec0374f2b6d1a9085bc  web/assets/index-BaiqKjqn.js
+94c3956301ced21ddf9270a745d884db8c49a7492feb490b747f33d35f5df6d2  web/assets/index-Be2y914M.css
+d51f86730961c8b0cd89cc0cd59fe927588f51c3d31514b5ece04fe93ff75622  web/index.html
+9153516a01e27c96a26356c449072f5f40610cb2c430e55ac35e48541ab07646  web/manifest.json

package/build/migrations/0031-goal-check-recorded-round.sql

@@ -0,0 +1,4 @@
+-- TASK-2665: a Goal Check row records the review round it was written in, so a
+-- repair round can tell its fresh fix evidence from rows kept from earlier
+-- rounds. Existing rows carry no round: nothing recorded when they were written.
+ALTER TABLE mission_checkpoint_goal_checks ADD COLUMN recorded_round INTEGER CHECK (recorded_round IS NULL OR recorded_round >= 1);

package/build/migrations/0032-goal-check-repaired-gate.sql

@@ -0,0 +1,4 @@
+-- TASK-2665: a Goal Check row written to repair an integration gate failure
+-- remembers that gate, so a later failure of the same gate still owes this
+-- criterion fresh proof after the repair replaced the gate-citing reference.
+ALTER TABLE mission_checkpoint_goal_checks ADD COLUMN repaired_gate TEXT;

package/build/migrations/0033-goal-check-repaired-gates.sql

@@ -0,0 +1,2 @@
+-- Preserve gate-specific criterion obligations across interleaved repairs.
+ALTER TABLE mission_checkpoint_goal_checks ADD COLUMN repaired_gates TEXT;

package/build/package.json

@@ -1,5 +1,5 @@
 {
   "name": "@magnusekdahl/parallix",
-  "version": "1.5.289",
+  "version": "1.5.317",
   "type": "module"
 }

package/build/prompts/act-on-review-core.md

@@ -15,7 +15,7 @@ Minimum loop contract:
 - Read the review outcome and findings from `px status {{slug}}`; its review history is projected from the operator database.
 - For each finding: fix it, or push back with a clear reason why it does not hold. There is no third option. "Tracked as a follow-up" is not a resolution — if the finding is right, deliver it.
 - If a finding is a rebasing artifact caused by branch stale-ness rather than this mission's diff, push back with the rationale: `Not a mission change - will be resolved by parallix rebase.`
-- Record corrected checkpoint evidence with `px checkpoint record` if needed, run the relevant gate, and commit before handoff.
+- Record corrected checkpoint evidence with `px checkpoint record` if needed, run the relevant gate, and commit before handoff. A repair records only the bounced checkpoint's affected criteria: prior checkpoints' valid rows are retained, and handoff measures coverage across every recorded checkpoint by criterion identity, so a repair row for one criterion never counts as evidence for another. Rows are stamped with the review round they were recorded in, and a repair must record at least one fresh row in the current round (each criterion a finding names needs its own), because rows kept from earlier rounds are stale as fix evidence.
 - After committing fixes, submit every finding with `px resolve --slug {{slug}} --actor {{implementer}} --expected-version <n> --finding <finding-id> --fixed "<evidence>" [--finding <finding-id> --disputed "<rationale>"] ...`. This persists the resolution and publishes through the established workflow; do not post to Forgejo directly.
 - `--disputed` records a pushback. Resolve every outstanding finding; the command rejects partial resolutions rather than inventing answers. Review feedback, missing context, and conflicting stale records are repair work, not a block: re-query `px status {{slug}}` and the current PR decisions, then act on the latest decision.
 - Use `px resolve --slug {{slug}} --actor {{implementer}} --expected-version <n> --blocked "<reason>"` only for a genuine external dependency that prevents any resolution and names the required human action. Never use it to avoid investigating or delivering requested changes.

package/build/prompts/execute-core.md

@@ -25,21 +25,19 @@ Harness preflight already confirmed:
 
 Execution requirements:
 - execute checkpoint-by-checkpoint per the checkpoint plan reported by `px status {{slug}}`, starting with the first planned checkpoint that has no recorded evidence. That is also where you resume after a relaunch.
-- after each completed checkpoint, record its evidence with `px checkpoint record --name <its planned CP-N>`, one `--criterion`/`--evidence` pair per Goal Check row, and a non-generic `--next`. Use the exact text of the success criterion a row evidences as its `--criterion`; handoff matches the final checkpoint's rows against the recorded success criteria and refuses a criterion with no row. That is the durable write; read it back with `px status {{slug}}`. Do not write a checkpoint document.
+- after each completed checkpoint, record its evidence with `px checkpoint record --name <its planned CP-N>`, one `--criterion`/`--evidence` pair per Goal Check row, and a non-generic `--next`. Use the exact text of the success criterion a row evidences as its `--criterion` so a reviewer can map rows to criteria. Handoff checks every recorded checkpoint, not just the final one: every criterion must be marked complete, and the recorded checkpoints taken together must carry a row naming each completed criterion, each citing a verifiable reference; handoff matches each row to the success criterion its `criterion` text names and refuses when the recorded checkpoints leave any completed criterion without a matching row. A repair checkpoint that carries only its affected criteria is not a shortfall while earlier evidence covers the others. That is the durable write; read it back with `px status {{slug}}`. Do not write a checkpoint document.
 - never create, edit, or commit files under the mission dir or anywhere under `missions/`: it is a retired legacy location, the tree must contain no files there, and handoff fails if it does. Measurements, timings, and populations belong inline in `px checkpoint record --evidence` text, citing runnable commands and test paths.
 - Immediately after recording a checkpoint's evidence, compact your working context: reload only the mission goal, scope, success criteria and checkpoint plan with `px status {{slug}}`, then continue.
 - Completing a checkpoint is **non-terminal**: after recording its evidence, immediately continue to the next planned checkpoint without recorded evidence. Do not send a final response or exit merely because one checkpoint is complete; break large checkpoints into safe slices and keep progressing.
 - You may terminate this execution only when exactly one of these conditions applies: (a) every success criterion is marked complete, every planned checkpoint has recorded evidence, the final one covers every success criterion, and every mission-declared gate passes, (b) a mission stop rule applies, or (c) a genuine external dependency blocks progress. Checkpoint size, uncertainty, or needing further investigation are not terminal conditions.
 - Keep Goal Check evidence durable: prefer stable file references and commands that can be rerun against the committed tree. Do not claim that `git diff HEAD` proves a committed change—its expected output is empty after committing. If historical diff evidence is needed, state the exact non-HEAD baseline or describe the observed change without implying that an empty post-commit diff will reproduce it.
-- the final checkpoint MUST record one Goal Check row per success criterion, citing real, durable references such as runnable project commands, test names, decision-record references, or test paths
 - **One row per criterion:** each `--criterion` is paired with the `--evidence` that follows it, in order. Pass the flags as many times as you have criteria; the counts must match or the write is rejected.
-- **Accepted evidence forms** (each `--evidence` value must cite at least one verifiable reference from this list):
-  1. **Runnable project commands or stable paths** — e.g., `` `make test` ``, `` `go test ./...` ``, or `` `tests/integration/` ``
-  2. **Test names** — e.g., `"saving a record preserves its identifier"` (must match a test name found in the project)
-  3. **Decision-record references** — e.g., `ADR 0048` (when the project uses ADRs or an equivalent decision record)
-  4. **Test paths** — e.g., `tests/integration/` (must be an existing test path)
-  5. **File:line references** — accepted when needed, but line numbers eventually rot; prefer the forms above
-- **Not sufficient by themselves:** raw `stat`/`ls` output or generic prose claims. You may include them as supporting context, but the same `--evidence` value must also cite at least one accepted reference from the list above.
+- **Evidence references:** `px checkpoint record` and handoff apply the same check, and recording refuses a row that cites none of these, naming the offending row:
+  1. an existing repository-relative path such as `test/store.test.ts`; a bare basename such as `store.test.ts` does not resolve
+  2. an exact test name in quotes, as written in `test(...)` or `it(...)` in a `.test`, `.spec` or `.cases` module under `test/`
+  3. a backticked command: `npm`, `npx`, `node`, `git` or `px`, a `./` script that exists, or a shell reader such as `grep` or `cat` with an existing file argument
+  4. an ADR reference such as `ADR 0012` whose file exists in `docs/adr/`
+  Raw `stat`/`ls` output and prose claims are context only. Example: `px checkpoint record --name CP-2 --expected-version 7 --criterion "<exact success criterion text>" --evidence "\"rejects a stale write\" in test/store.test.ts passes: \`npm test -- test/store.test.ts\`" --next "CP-3: update the operator guidance"`
 - run targeted checks needed to develop and validate the change; handoff owns the authoritative execution of mission-declared Gates, so do not rerun a complete declared gate solely as lifecycle ritual (run one when diagnosing a concrete issue)
 - Immediately after **each successful mission-declared Gate**, compact your working context before starting the next gate, checkpoint work, or handoff work. Reload only the locked mission goal and scope plus committed checkpoint or successful-gate evidence that is present, re-reading them with `px status {{slug}}` rather than from repository files. Do not compact for a failed gate: retain its failure diagnostic while repairing it.
 - preserve `{{taskPath}}`: update mission-relevant content as needed but do not delete, rename, or move the file

package/build/prompts/review-core.md

@@ -52,6 +52,7 @@ Check:
   - `px verdict approve --slug {{slug}} --actor {{reviewer}} --expected-version <n> --comment "<review summary>"`
   - `px verdict request-changes --slug {{slug}} --actor {{reviewer}} --expected-version <n> --finding <finding-id> --summary "<issue>" [--location "<path>"] ... --comment "<review summary>"`
 - Every request-change finding needs a distinct stable `F<number>` id and non-empty summary. `px verdict` persists the decision and publishes through the established workflow; do not post to Forgejo directly.
+- When a finding concerns specific success criteria, name them in its summary as `Success criterion N` (or `criteria N, M`, 1-based as `px status` lists them). Checkpoint recording and handoff read these references to require fresh fix evidence for exactly those criteria in the repair round.
 - Do not edit repo files; do not switch into implementer behavior.
 - Graphify-first: before reviewing, check if `graphify-out/graph.json` exists. If it does, run `graphify query "review {{slug}} for correctness and completeness"` to get a graph-based view of the mission scope before examining the diff.