@magnusekdahl/parallix 1.5.317 → 1.5.435

package/NOTICES

@@ -1,4 +1,4 @@
-THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.317
+THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.435
 
 @magnusekdahl/parallix itself is licensed under AGPL-3.0-or-later; see LICENSE.
 
@@ -80,7 +80,7 @@ safe-regex2@5.1.1 — MIT — https://github.com/fastify/safe-regex2
 safe-stable-stringify@2.5.0 — MIT — https://github.com/BridgeAR/safe-stable-stringify#readme
 scheduler@0.27.0 — MIT — https://react.dev/
 secure-json-parse@4.1.0 — BSD-3-Clause — https://github.com/fastify/secure-json-parse#readme
-semver@7.7.4 — ISC — git+https://github.com/npm/node-semver.git
+semver@7.8.5 — ISC — git+https://github.com/npm/node-semver.git
 set-cookie-parser@2.7.2 — MIT — https://github.com/nfriedly/set-cookie-parser
 signal-exit@3.0.7 — ISC — https://github.com/tapjs/signal-exit
 slice-ansi@8.0.0 — MIT — chalk/slice-ansi
@@ -1360,7 +1360,7 @@ Redistribution and use in source and binary forms, with or without modification,
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 ------------------------------------------------------------------------------
-semver@7.7.4 (ISC)
+semver@7.8.5 (ISC)
 ------------------------------------------------------------------------------
 
 The ISC License

package/README.md

@@ -47,7 +47,7 @@ Observed one-maintainer dogfooding throughput. The [methodology and evidence](do
 - **Resume a long mission deterministically**. The execution agent records completed checkpoints with evidence and a concrete next action, and commits them locally, so a later session or a different agent can resume from the recorded progress.
 - **Force a second, preferentially-different coding agent review before merge**. Review is a separate step whose reviewer selection excludes the implementer to prefer a different agent family, and a self-approval is code-blocked at the provider. It falls back to the same family when no other agent is runnable, so this forces a second review *attempt* — it only guarantees a different reviewer when one is available.
 - **Publish work to a Forgejo reviewer surface without making Forgejo your branch authority**. When the review provider is enabled, Parallix syncs the local baseline to a dedicated `review` remote running locally and opens or updates the PR there; if Forgejo is disabled, the branch/worktree flow still runs without it.
-- **Use a repo-local Graphify knowledge graph for smaller codebase context pulls**. In repositories where the operator has already installed the Graphify skill, the workflow keeps `graphify-out/` isolated per worktree and refreshes it during review/integration, while the installed agent guidance steers codebase questions toward `graphify query` / `path` / `explain` before full reports or raw grep. That reduces token-usage.
+- **Use a repo-local Graphify knowledge graph for smaller codebase context pulls**. In repositories where the operator has already installed the Graphify skill, the workflow keeps `graphify-out/` isolated per worktree and updates an existing graph after squash integration on the receiving base worktree, while the installed agent guidance steers codebase questions toward `graphify query` / `path` / `explain` before full reports or raw grep. That reduces token-usage.
 - **Keep your existing verification gate instead of agent self-reporting**. The gate is a configured shell command with a no-op default: declare your existing `make` / `npm` / script command in `workflow.config.json` and it runs verbatim; declare nothing and verification is a documented no-op pass, not an invented gate.
 - **Confine supported agent processes with Bubblewrap on Linux**. When Bubblewrap is available, Parallix mounts the host filesystem read-only and selectively grants write access required by the current mission. Implementation gets its mission worktree and required Git state writable; review keeps the worktree read-only. If Bubblewrap is unavailable, Parallix falls back to the agent's own native sandbox where the family exposes one (e.g. Codex `--sandbox`, Qwen `-s`), otherwise it blocks the mutating launch until the operator explicitly consents to run unsandboxed — no silent fallback.
 - **Evaluate which agent family actually pays off across every repo one runtime drives**. A single operator-owned measurement database (`<PARALLIX_HOME>/parallix.db`) accumulates per-agent usage telemetry across repositories.
@@ -73,7 +73,7 @@ backlog → draft → active → review → approved → done
 
 In practice: a human drafts a mission, Parallix creates the branch and worktree, an agent runs and writes checkpoints, a configured verification gate runs, a second agent reviews the diff, and only then is the work integrated back to your primary branch by squash-merge. Each mission lands as one squash commit whose subject is the recorded mission title and whose body records the mission's task reference, so the primary branch history names what was delivered at a glance. Review uses a different agent family when one is available; when none is runnable, it falls back to the same family as a second review attempt. An operator can opt into a no-output deadline for silent reviewers with `WORKFLOW_REVIEW_AGENT_NO_OUTPUT_MAX_MS`, after which the next eligible reviewer is tried. Blocking review findings loop back to `active` on the same branch and PR.
 
-The mission enters `review` before each review round and `integration` when approval succeeds. Review gate repairs return it to `active` before repair work and back to `review` after verification. Commit and rebase repairs needed to finish integration stay in `integration`. Integration gate failures return the mission to `active` and require a fresh review before integration resumes. The mission reaches `done` only after integration and cleanup succeed. A failed lifecycle write stops dependent work and is reported as a failure. Once activation commits, a failed agent run leaves the mission and its Backlog mirror active for retry. Agents use the launching CLI for their workflow commands so an older global installation cannot bypass these boundaries.
+The mission enters `review` before each review round and `integration` when approval succeeds. Review gate repairs return it to `active` before repair work and back to `review` after verification. Commit and rebase repairs needed to finish integration stay in `integration`. Integration gate failures return the mission to `active`. A fresh round either reviews the repair or mechanically restores prior approval when the mission patch is unchanged and the failed gate has recorded green validation. Both paths stop for human integration. The mission reaches `done` only after integration and cleanup succeed. A failed lifecycle write stops dependent work and is reported as a failure. Once activation commits, a failed agent run leaves the mission and its Backlog mirror active for retry. Agents use the launching CLI for their workflow commands so an older global installation cannot bypass these boundaries.
 
 ## Defence in depth
 
@@ -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. 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).
+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, whether an integration repair weakened the check its recorded green gate re-ran 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.
@@ -168,8 +168,8 @@ Both are optional integrations, and each one is wired independently of the other
 ## Use cases
 
 The durable capability guide and confidence boundaries are in [`docs/use-cases.md`](docs/use-cases.md).
-For automatic interactive mission terminals and bounded retained agent-run output,
-see [agent-run history](docs/agent-run-history.md).
+For automatic interactive mission terminals and bounded retained mission history
+(also shown on the `px web` board), see [agent-run history](docs/agent-run-history.md).
 
 ## What Parallix is not
 
@@ -220,7 +220,10 @@ The test suite is the verification gate this repo declares in `workflow.config.j
 
 Four Node floors are distinct here: the shipped runtime floor is `>=22.23.1` (`package.json` `engines.node`, also the bundle target); the ordinary development and unit-test floor is Node `24.15.0` or newer, which the unit-test module mock helper needs; the coverage-tooling floor is Node `26.7` or newer for `--test-coverage-include-all`; and GitHub CI selects Node `26` for the coverage run and Node `24` for the release path. The local verifier accepts any Node `20` or newer so `node --test` runs, but coverage still needs the `26.7` floor. Contributions follow the same mission lifecycle the tool itself runs: branch, worktree, checkpoints, a second review, and a passing gate before integration. To exercise the packaged artifact the way a user receives it: `npm pack && npm install -g ./magnusekdahl-parallix-*.tgz`.
 
-If you are developing Parallix itself from a checkout, use the built runtime
+If you are developing Parallix itself from a checkout, install dependencies with
+the pinned pnpm (`pnpm install --frozen-lockfile`; `package.json` `packageManager`
+names the version, and `pnpm-lock.yaml` is the only lockfile). Packaging and
+publication still use npm. Then use the built runtime
 after `npm run build`, or run the TypeScript entry directly with the development
 script:
 

package/build/asset-manifest.json

@@ -11,15 +11,15 @@
     },
     {
       "key": "prompts/act-on-review-core.md",
-      "sha256": "6efbfc58fba6d4224ac05d23c3b08ca2ce33b11e67cae63adef07ceda9fa5125"
+      "sha256": "e0f14f5d559391eccebd1a85da0c709c90ff74f04a5cb8809303f0d372a3bc86"
     },
     {
       "key": "prompts/act-on-review.md",
-      "sha256": "412facaee4a56f6436317d6b228ff57cb0605aca88ca143056ab50895ef62eee"
+      "sha256": "c3e7caaaaa110fd7da1b055a593d8f56a66cb8bb7bb70ccdb3f43250fba7e9d2"
     },
     {
       "key": "prompts/draft-core.md",
-      "sha256": "794bc41c7ce01d3f5ec06aa4ae37c75dfc54079c1ca62062f231c45d91d9637b"
+      "sha256": "352006d7edd95c47dd405d98b7ec1103b1705e9232e153e89637ddb4bf389655"
     },
     {
       "key": "prompts/draft.md",
@@ -27,7 +27,7 @@
     },
     {
       "key": "prompts/execute-core.md",
-      "sha256": "1db19f3697c6e27baf87dc984b8b03e846359d63b495dc19e1ac78c97982cc8a"
+      "sha256": "de5ad6f1eef4b856e912865667cb738fc0716b707dd62068ef176f89f0bf3032"
     },
     {
       "key": "prompts/execute.md",
@@ -35,7 +35,7 @@
     },
     {
       "key": "prompts/review-core.md",
-      "sha256": "607d968e782bd9647e15a6aea3eb7705f0d83b61eb39c220eeb6f3fc00fa6098"
+      "sha256": "f0c58cd3d9853de4e2715f85d6e43a99c2820e84b86bc0f8f1c54d82618c457b"
     },
     {
       "key": "prompts/review.md",
@@ -119,7 +119,7 @@
     },
     {
       "key": "migrations/0018-adhoc-mission-counter.sql",
-      "sha256": "3560376d8e31e0b8fc527509211378a839ba24ef5e5e5fac9ee6dadc06c172c2"
+      "sha256": "f73067a9a12a99ea5193b9d477eb23f069c2fb88c7227f4c5b88d84498f651a0"
     },
     {
       "key": "migrations/0019-custom-agent-leases.sql",
@@ -180,6 +180,50 @@
     {
       "key": "migrations/0033-goal-check-repaired-gates.sql",
       "sha256": "e6303934e715b0bf7ac1078abb7f2bd6e488a4b1e299d69c7612cc4ba2d1a578"
+    },
+    {
+      "key": "migrations/0034-checkpoint-repair.sql",
+      "sha256": "c899f9b25fe86e454b99d9db28feb89573fc7d0b40b0b50328a619a92d90e556"
+    },
+    {
+      "key": "migrations/0034-mission-description.sql",
+      "sha256": "16ccaf2fe41cd1e578bfbedd0675c854d3ce9daa3ac51f205d6766250775cf13"
+    },
+    {
+      "key": "migrations/0035-review-round-baseline.sql",
+      "sha256": "7a8f2aacf87ff92fc9c3270ed719a433fcd6dff2496347f66d5180fadf6e7d28"
+    },
+    {
+      "key": "migrations/0036-integration-repair-assessment.sql",
+      "sha256": "f723967c48b0c9be7a018730167467901a9de22516bad7ac13679254003d19d8"
+    },
+    {
+      "key": "migrations/0037-checkpoint-evidence-history.sql",
+      "sha256": "7b0bf1d87073edea601e68dd14d4e323f3fc3be740adadb7a8b7bbae55947e4c"
+    },
+    {
+      "key": "migrations/0038-success-criterion-identity.sql",
+      "sha256": "d59c6e91e82e9cdd93fb2735209a396cfd9d68c73dbee18b55b4db68b00d44f1"
+    },
+    {
+      "key": "migrations/0039-review-decided-revision.sql",
+      "sha256": "5cb00acc4e4924adcc082d750871db65d2e4f2075e8e81b61fe9663ff3786b12"
+    },
+    {
+      "key": "migrations/0039-workflow-operations.sql",
+      "sha256": "899d9d535e079ef2bd04cc1a52b24ab8fdb82195f1d6257218f0dc4827c20562"
+    },
+    {
+      "key": "migrations/0040-goal-check-carried-from.sql",
+      "sha256": "f600df1684fe3a7e8423090759a6578378e44a306a6498457e69eb72c858d902"
+    },
+    {
+      "key": "migrations/0041-admission-resources.sql",
+      "sha256": "eb04fe7a9e4c295f3b751c65b915580e897d22d4f771dd75e531295c92973ed0"
+    },
+    {
+      "key": "decision/tokenizer-data.gz",
+      "sha256": "c83abf9a2ab7966fbeec566cacb00c1aa48f6ac0ca66054fa7999d000c020012"
     }
   ]
 }

package/build/manifest.sha256

@@ -1,6 +1,7 @@
-7b2d18017dfdbb1ace49e7a99a073bf7d1d3f72e56776e72689a36d61636a615  asset-manifest.json
+1ecb336caae5bbb1a2ad1a61b467ea1ca058d1b7ad2f5b200aa8d00d76dae1c0  asset-manifest.json
 ec3ec505e42adc8cddc17651d7a1a85b6359a433e1e62f3c6c22a4896150187f  config/agents.json
 6a4ec47387d1240e32967dc8e4ce54a15d69df2676b7a96ff72baafe996fef7d  config/state-map.json
+c83abf9a2ab7966fbeec566cacb00c1aa48f6ac0ca66054fa7999d000c020012  decision/tokenizer-data.gz
 30a76fa3839753ddbfe312428dd1b7285ac1b8d0bd678fc79c79018ec6154f69  migrations/0001-initial-schema.sql
 a8a0febfb4e448a11a5a16b2227d5cc1959bf4594aadd6fd65ea764283020edd  migrations/0002-import-history.sql
 d4080e33cb1a77e504188dbdafa0765ddf3391d99e1d81a76ab3a5ce3b9b40f2  migrations/0003-board-lane-events.sql
@@ -19,7 +20,7 @@ b3b9c80e6372eeb3b2bf3b12813dc6fbc4c5d20f601a5abbb6ac0a7605467eb7  migrations/001
 a08063b188a91e901d462f73f4f154c98d85068324cef45eb144250e5000051a  migrations/0015-current-work-latest-per-mission.sql
 0acd31e661e720b563b92b3f75f99218dd99011b787ee8aad76b9a3bc1e363c4  migrations/0016-review-drop-retry-counters.sql
 f46823014782c22a9e40b486958770d2b5f7e7180fc9fe6be961a791cca97b50  migrations/0017-retire-mission-import-provenance.sql
-3560376d8e31e0b8fc527509211378a839ba24ef5e5e5fac9ee6dadc06c172c2  migrations/0018-adhoc-mission-counter.sql
+f73067a9a12a99ea5193b9d477eb23f069c2fb88c7227f4c5b88d84498f651a0  migrations/0018-adhoc-mission-counter.sql
 07559cd5363f01a309d028673e6dcb9e222a848fae79c57d2fee9001589da19d  migrations/0019-custom-agent-leases.sql
 39f48ffde5a766f82b4c59725a6bf49750496e6f2efa92b983b2c4756a3cf314  migrations/0020-mission-execution-context.sql
 6e8112f6674086f47403172e3a5f3506d1e1ed6defb0e05b2bd00dea66f84858  migrations/0021-mission-brief-and-declared-gates.sql
@@ -35,20 +36,38 @@ b4091b8c3d770f8ac5072745a234de10d6e02cc3c4f0e6497888629041b54e7e  migrations/002
 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
+c899f9b25fe86e454b99d9db28feb89573fc7d0b40b0b50328a619a92d90e556  migrations/0034-checkpoint-repair.sql
+16ccaf2fe41cd1e578bfbedd0675c854d3ce9daa3ac51f205d6766250775cf13  migrations/0034-mission-description.sql
+7a8f2aacf87ff92fc9c3270ed719a433fcd6dff2496347f66d5180fadf6e7d28  migrations/0035-review-round-baseline.sql
+f723967c48b0c9be7a018730167467901a9de22516bad7ac13679254003d19d8  migrations/0036-integration-repair-assessment.sql
+7b0bf1d87073edea601e68dd14d4e323f3fc3be740adadb7a8b7bbae55947e4c  migrations/0037-checkpoint-evidence-history.sql
+d59c6e91e82e9cdd93fb2735209a396cfd9d68c73dbee18b55b4db68b00d44f1  migrations/0038-success-criterion-identity.sql
+5cb00acc4e4924adcc082d750871db65d2e4f2075e8e81b61fe9663ff3786b12  migrations/0039-review-decided-revision.sql
+899d9d535e079ef2bd04cc1a52b24ab8fdb82195f1d6257218f0dc4827c20562  migrations/0039-workflow-operations.sql
+f600df1684fe3a7e8423090759a6578378e44a306a6498457e69eb72c858d902  migrations/0040-goal-check-carried-from.sql
+eb04fe7a9e4c295f3b751c65b915580e897d22d4f771dd75e531295c92973ed0  migrations/0041-admission-resources.sql
+bd32d667fba73d794e00286be74b5eecfbb77344c063315a6616b7bbec34e1d9  package.json
+e0f14f5d559391eccebd1a85da0c709c90ff74f04a5cb8809303f0d372a3bc86  prompts/act-on-review-core.md
+c3e7caaaaa110fd7da1b055a593d8f56a66cb8bb7bb70ccdb3f43250fba7e9d2  prompts/act-on-review.md
+352006d7edd95c47dd405d98b7ec1103b1705e9232e153e89637ddb4bf389655  prompts/draft-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/draft.md
-1db19f3697c6e27baf87dc984b8b03e846359d63b495dc19e1ac78c97982cc8a  prompts/execute-core.md
+de5ad6f1eef4b856e912865667cb738fc0716b707dd62068ef176f89f0bf3032  prompts/execute-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/execute.md
-607d968e782bd9647e15a6aea3eb7705f0d83b61eb39c220eeb6f3fc00fa6098  prompts/review-core.md
+f0c58cd3d9853de4e2715f85d6e43a99c2820e84b86bc0f8f1c54d82618c457b  prompts/review-core.md
 06431c3f965935db27b254164d3bfa66aa7cc2a5602031f181dcc5e32f3e5739  prompts/review.md
-fc37ee4be11716e2f2f4bfd6e8d36977df8710c119535d864b2db84151eb3202  px.mjs
-7d64339dfa0e7465f525f81e636a9bf04f90482e22fa135b55fd3d5d9b82177b  px.mjs.map
-2fcab12164ffe2b979404d112c09614fe80c266add18e43eb77d71880aa61b09  sbom.json
+c7d68565de8344420db3d9de00fb8ad60b8d2eef7c106bf97fb53331b9e116a9  px.mjs
+3482eb0f8970bcf7d2fc8ce25c339a0d445c6bfc20ff1c7911ba536da154b31b  px.mjs.map
+4623dc4e25709cd345e2706c28aa1d0037e977e85bd798b8537fcfcaed82edfc  sbom.json
 64ceff9f8a45d1769c8e70b0545a554065ffd285aa33b862447cb2ac70d28093  templates/mission-scaffold.md
-220047b42a8c93f13c7835807c7c513e2af7042a900a2ec0374f2b6d1a9085bc  web/assets/index-BaiqKjqn.js
-94c3956301ced21ddf9270a745d884db8c49a7492feb490b747f33d35f5df6d2  web/assets/index-Be2y914M.css
-d51f86730961c8b0cd89cc0cd59fe927588f51c3d31514b5ece04fe93ff75622  web/index.html
-9153516a01e27c96a26356c449072f5f40610cb2c430e55ac35e48541ab07646  web/manifest.json
+35a828a2a248c396af77c4b3090d2cb1ec37858128a591df62398457f909618d  web/assets/index-BLNC0e_y.css
+c3e2a89f1cc14245e7882ccc7542355aea5f5e13f95880a9106883ffd776a1f4  web/assets/index-CAQBs60C.js
+844d5ef0608e16d8234ded7a0dd60eedeb2fe404ed62932df8ff26f03bbf6279  web/fonts/FONTS.txt
+ad3a6fb70cbc6264692395e7ed71de8bc8919f63e7fd194c6a5eb047d0f248ea  web/fonts/OFL-Barlow-Condensed.txt
+a76abf002c49097d146e86740a3105a5d00450b1592e820a1109a8c5680cd697  web/fonts/OFL-JetBrains-Mono.txt
+7fff1bb22e5773f0d1a55d3093068b6dac4539e8bb3ac23fb9f0a729df2c7bb4  web/fonts/barlow-condensed-latin-400.woff2
+3787a5a419171630e6890cfa47c4da067474d005cd0ff8dc11ec090fdc3ee2b8  web/fonts/barlow-condensed-latin-700.woff2
+14425ba9c695763c1547f48a206b7aa60350a33ae23de09f0407877f3fcd89eb  web/fonts/jetbrains-mono-latin-400.woff2
+cb182feeed4d798ff6961d3c79f7026279448fca0676438aaecb21f3fc39553a  web/fonts/jetbrains-mono-latin-500.woff2
+d0d4e818808f2a0ba39b2b09d1989366f63494e295f003c7ef436697378507e8  web/fonts/jetbrains-mono-latin-700.woff2
+477dd8d0d23781c6d9ec57fd8c39750e854e15e91af0bcab145edd34d0e3e6eb  web/index.html
+3d9ecd6169e35f7545953dfe22bb587fc93997ebffe694033ecc024d6a1ab8c8  web/manifest.json

package/build/migrations/0018-adhoc-mission-counter.sql

@@ -4,7 +4,7 @@
 -- Backlog-backed missions keep their identity in a Backlog task file. Adhoc
 -- missions have no such file in an adhoc-only repository, so their identity is
 -- minted here instead: a monotonic counter owned per repository, allocated
--- atomically, so `parallix-adhoc-<NNNN>` can never collide with, or be confused
+-- atomically, so `px-<NNNN>` can never collide with, or be confused
 -- for, Backlog.md task numbering. No content hash in the identity: slug,
 -- mission id, branch, and worktree suffix all derive from this counter.
 --

package/build/migrations/0034-checkpoint-repair.sql

@@ -0,0 +1,2 @@
+-- Incident-associated repair state is nested Mission checkpoint authority.
+ALTER TABLE mission_checkpoints ADD COLUMN repair_json TEXT;

package/build/migrations/0034-mission-description.sql

@@ -0,0 +1,4 @@
+-- TASK-2693: a mission captured on the board may carry a description with no
+-- reason attached. A brief needs both goal and why, so the description lives on
+-- the mission until a refining agent records the brief with `px goal set`.
+ALTER TABLE missions ADD COLUMN description TEXT;

package/build/migrations/0035-review-round-baseline.sql

@@ -0,0 +1,3 @@
+-- TASK-2704: the primary-branch revision a round's mission diff is measured from, so a repair
+-- compares baseline-relative mission diffs rather than diffs polluted by main.
+ALTER TABLE mission_review_rounds ADD COLUMN review_baseline TEXT;

package/build/migrations/0036-integration-repair-assessment.sql

@@ -0,0 +1,2 @@
+ALTER TABLE mission_review_rounds ADD COLUMN integration_repair_assessment TEXT;
+ALTER TABLE mission_review_rounds ADD COLUMN mechanical_source TEXT;

package/build/migrations/0037-checkpoint-evidence-history.sql

@@ -0,0 +1,39 @@
+-- Preserve existing evidence verbatim. Recording metadata was never stored;
+-- row-level recorded_round is known, but no checkpoint-level round is inferred.
+ALTER TABLE mission_checkpoints ADD COLUMN recording_json TEXT;
+CREATE TABLE mission_checkpoint_versions (
+  mission_id TEXT NOT NULL REFERENCES missions(id) ON DELETE CASCADE,
+  version INTEGER NOT NULL CHECK (version >= 1),
+  name TEXT NOT NULL,
+  checkpoint_json TEXT NOT NULL,
+  recorded_at TEXT,
+  recorded_round INTEGER,
+  mission_revision INTEGER,
+  PRIMARY KEY (mission_id, version)
+);
+INSERT INTO mission_checkpoint_versions
+SELECT c.mission_id, ROW_NUMBER() OVER (PARTITION BY c.mission_id ORDER BY c.position), c.name,
+  json_patch(json_object('missionId', c.checkpoint_mission_id, 'name', c.name,
+    'rawFilename', c.raw_filename, 'firstLine', c.first_line,
+    'nextActionText', c.next_action_text, 'repair', json(c.repair_json)),
+    json_object('goalCheck', json(COALESCE((
+      SELECT json_group_array(json(row_json)) FROM (
+        SELECT json_patch(json_object('criterion', g.criterion, 'evidence', g.evidence,
+          'recordedRound', g.recorded_round, 'repairedGate', g.repaired_gate,
+          'repairedGates', json(g.repaired_gates)), '{}') AS row_json
+        FROM mission_checkpoint_goal_checks g
+        WHERE g.mission_id = c.mission_id AND g.checkpoint_position = c.position
+        ORDER BY g.position
+      )
+    ), '[]')))), NULL, NULL, NULL
+FROM mission_checkpoints c;
+
+-- Null means the boundary predates capture; never reconstruct it from today's evidence.
+CREATE TABLE mission_review_checkpoint_states (
+  mission_id TEXT NOT NULL REFERENCES missions(id) ON DELETE CASCADE,
+  round_number INTEGER NOT NULL CHECK (round_number >= 1),
+  state_json TEXT,
+  PRIMARY KEY (mission_id, round_number)
+);
+INSERT INTO mission_review_checkpoint_states (mission_id, round_number, state_json)
+SELECT mission_id, round_number, NULL FROM mission_review_rounds;

package/build/migrations/0038-success-criterion-identity.sql

@@ -0,0 +1,30 @@
+-- Existing criteria acquire mission-scoped IDs. Only exact current text matches
+-- can identify legacy evidence; never infer an identity from position or wording.
+ALTER TABLE missions ADD COLUMN next_success_criterion_id INTEGER NOT NULL DEFAULT 1;
+ALTER TABLE mission_success_criteria ADD COLUMN criterion_id TEXT;
+UPDATE mission_success_criteria SET criterion_id = 'sc-' || (position + 1)
+WHERE criterion_id IS NULL;
+UPDATE missions SET next_success_criterion_id = COALESCE((
+  SELECT MAX(position) + 2 FROM mission_success_criteria WHERE mission_id = missions.id
+), 1)
+WHERE EXISTS (SELECT 1 FROM mission_success_criteria WHERE mission_id = missions.id);
+ALTER TABLE mission_checkpoint_goal_checks ADD COLUMN criterion_id TEXT;
+UPDATE mission_checkpoint_goal_checks AS g SET criterion_id = (
+  SELECT c.criterion_id FROM mission_success_criteria c
+  WHERE c.mission_id = g.mission_id AND c.criterion = g.criterion
+);
+
+-- Retained versions may predate this forward migration. Preserve all evidence
+-- and metadata while annotating only exact matches, including explicit nulls.
+UPDATE mission_checkpoint_versions AS v SET checkpoint_json = json_set(checkpoint_json, '$.goalCheck', json(COALESCE((
+  SELECT json_group_array(json(identified)) FROM (
+    SELECT json_set(g.value, '$.criterionId', (
+      SELECT c.criterion_id FROM mission_success_criteria c
+      WHERE c.mission_id = v.mission_id AND c.criterion = json_extract(g.value, '$.criterion')
+    )) AS identified FROM json_each(v.checkpoint_json, '$.goalCheck') g ORDER BY CAST(g.key AS INTEGER)
+  )
+), '[]')));
+-- Earlier boundaries have no reliable round-time criteria contract. Do not
+-- substitute today's criteria into a historical snapshot.
+UPDATE mission_review_checkpoint_states SET state_json = json_set(state_json, '$.successCriteria', NULL, '$.uncoveredCriterionIds', NULL)
+WHERE state_json IS NOT NULL;

package/build/migrations/0039-review-decided-revision.sql

@@ -0,0 +1,2 @@
+-- Legacy decisions deliberately retain NULL: their reviewed head is unknown.
+ALTER TABLE mission_review_rounds ADD COLUMN decided_revision TEXT;

package/build/migrations/0039-workflow-operations.sql

@@ -0,0 +1,12 @@
+CREATE TABLE workflow_operations (
+  id TEXT PRIMARY KEY,
+  repository_id TEXT NOT NULL,
+  mission_id TEXT NOT NULL,
+  request_key TEXT NOT NULL,
+  generation INTEGER NOT NULL,
+  phase TEXT NOT NULL,
+  record_json TEXT NOT NULL,
+  UNIQUE(repository_id, mission_id, request_key)
+);
+CREATE UNIQUE INDEX workflow_exclusive_mission ON workflow_operations(repository_id, mission_id)
+WHERE phase IN ('accepted', 'preparing', 'waiting', 'running', 'checking', 'stopping');

package/build/migrations/0040-goal-check-carried-from.sql

@@ -0,0 +1,2 @@
+-- Provenance of Goal Check rows carried into a repair checkpoint; NULL for recorded rows.
+ALTER TABLE mission_checkpoint_goal_checks ADD COLUMN carried_from TEXT;

package/build/migrations/0041-admission-resources.sql

@@ -0,0 +1,8 @@
+-- Separate verification exclusion from agent admission capacity.
+ALTER TABLE custom_agent_leases ADD COLUMN resource TEXT NOT NULL DEFAULT 'agents';
+CREATE TABLE IF NOT EXISTS admission_process_groups (
+  lease_id TEXT NOT NULL REFERENCES custom_agent_leases(lease_id) ON DELETE CASCADE,
+  pid INTEGER NOT NULL,
+  start_id TEXT NOT NULL,
+  PRIMARY KEY (lease_id, pid)
+);

package/build/package.json

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

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

@@ -9,15 +9,15 @@ Latest reviewer outcome was: {{review_outcome}}
 Entrypoint: {{act_on_review_entrypoint}}
 
 Minimum loop contract:
-- Before acting on findings, compact the implementation context and reload the locked mission goal and scope; committed checkpoint or gate evidence when present; current review round and disposition; unresolved findings and implementer resolutions; and the exact revision under review. This applies even when the mission declares no gates.
+- Before acting on findings, {{actOnReviewContextAction}} the locked mission goal and scope; committed checkpoint or gate evidence when present; current review round and disposition; unresolved findings and implementer resolutions; and the exact revision under review. This applies even when the mission declares no gates.
 - Load the Mission context with `px status {{slug}}` and read `AGENTS.md` before acting. That command reports the recorded brief, declared gates, the latest recorded checkpoint evidence, the reviewed revision, the outstanding findings, and your prior resolutions.
 - Get the current round, phase, and disposition from `px status {{slug}}`, which reports them on its `Review:` line. `px status` is the authority for review-loop state; take it from there and nowhere else.
 - 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. 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.
+- After committing fixes, submit every finding with `px resolve --slug {{slug}} --actor {{implementer}} --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.
+- Use `px resolve --slug {{slug}} --actor {{implementer}} --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.
 
-Safety: if the review outcome is not approved and you cannot read it, do not guess and do not push back on findings you have not seen. Record `px resolve --slug {{slug}} --actor {{implementer}} --expected-version <n> --blocked "<reason>"` instead, naming what you could not read. Silence is not a resolution.
+Safety: if the review outcome is not approved and you cannot read it, do not guess and do not push back on findings you have not seen. Record `px resolve --slug {{slug}} --actor {{implementer}} --blocked "<reason>"` instead, naming what you could not read. Silence is not a resolution.

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

@@ -1 +1 @@
-Graphify-first: before acting on findings, check if `graphify-out/graph.json` exists. If it does, use `graphify query` and `graphify path` to understand affected code areas before making changes. Do not refresh Graphify after ordinary edits: the next autonomous-review boundary refreshes the final verified tree immediately before reviewer launch.
+Graphify-first: before acting on findings, check if `graphify-out/graph.json` exists. If it does, use `graphify query` and `graphify path` to understand affected code areas before making changes. Parallix updates existing Graphify graphs after successful squash integration on the receiving base worktree; review, edits and checkpoints do not trigger updates.

package/build/prompts/draft-core.md

@@ -18,9 +18,19 @@ Forbidden actions:
 
 Mission state authority: `px status {{slug}}` is the authority for recorded Mission facts.
 
-Record the mission contract with typed commands. The slug is inferred from this worktree, and every write takes `--expected-version <n>`. Each write prints the new `version`; pass it to the next write instead of re-reading `px status`.
+Prefer one foreground px mission author invocation to record the complete contract atomically, then read it back once with px status {{slug}}. Run px mission --help for the typed flags. The slug is inferred from this worktree. Each write resolves its own current version automatically; --expected-version is optional when you want to pin an earlier read. Validation or a version conflict rejects the whole batch without partial writes.
 
-The contract, and what the harness requires before this draft can finish:
+For example, a small greeting fix can use plain criterion text:
+
+```sh
+px mission author --goal 'Fix the greeting' --why 'The greeting contains a typo' --scope 'Correct hello.sh greeting text' --out-of-scope 'Other behavior' --criterion 'hello.sh prints Hello, World! and exits successfully' --checkpoint CP-1 --checkpoint-text 'Correct the greeting and verify public execution' --gate './scripts/verify-local.sh all' --predicted Small --classification ai_sdlc
+```
+
+Supply every required part: goal and why, scope, at least one success criterion, an ordered checkpoint plan, exact runnable verification gates, a predicted NEL bucket, and classification. Repeat list flags within the same invocation; the lists replace recorded lists. Out-of-scope entries are optional; record them whenever review should check a deliberate boundary. Checkpoint descriptions are at most 512 characters. Gates contain only runnable commands, without prose, comments or expected outcomes. Expected outcomes belong in criteria.
+
+Use plain text in criteria and evidence values, without literal backticks or embedded double quotes. Quote shell arguments with single quotes as in the example. Execution can cite a repository-relative path such as hello.sh or test/unit/example.test.ts as its evidence reference; formatting characters are unnecessary.
+
+The required parts and their existing single-concept commands are listed below. The batch above records the same parts together; reproduction and dependencies use their own commands.
 
 | Part | Command | Required |
 |---|---|---|
@@ -34,13 +44,13 @@ The contract, and what the harness requires before this draft can finish:
 | Reproduction test | `px repro set --test <path>` | required for a `bug` mission only |
 | Dependencies | `px depends add --on <slug>`, one call each | optional; nothing enforces it |
 
-This table is the whole requirement. The draft does not complete while any required part is missing: the harness refuses it, names what is missing, and sends it back to you. Run any command with `--help` for its exact flags.
+Existing single-concept commands remain available for focused edits. Record a reproduction test with px repro set --test <path> for a bug mission; add optional dependencies with px depends add --on <slug>. Neither changes lifecycle state. Run any command with --help for exact flags.
 
-Run each write as its own foreground command and wait for it to finish. Do not chain the whole contract into one long command, do not move a write to the background, and never end your turn while a `px` command is still running: when your turn ends, anything still running is killed and was not recorded.
+Wait for each foreground write to finish; never end your turn while a `px` command is still running: when your turn ends, anything still running is killed and was not recorded.
 
 A write against a stale version is rejected with an explicit conflict and changes nothing; re-read the version with `px status {{slug}}` and retry.
 
-Before you finish, read the contract back with `px status {{slug}}` and check every required part in the table. Anything it does not report was not recorded.
+Before you finish, read the contract back with `px status {{slug}}` and check every required part above. Anything it does not report was not recorded.
 
 Plan the checkpoints; do not record their evidence. `px checkpoint record` is for execution: evidence is what the work produces, and there is nothing to cite yet.
 
@@ -48,18 +58,20 @@ Drafting requirements:
 - every part you record is concrete and specific to this mission; no placeholders or "TBD"
 - plan checkpoints as coherent, independently verifiable slices of the work; together they must cover every success criterion
 - each success criterion must be specific and checkable: execution records one Goal Check row of evidence per criterion
+- Before locking, check that all criteria and scope constraints can hold together. Challenge absolute guarantees with boundary cases; finite budgets must include all mandatory content, metadata and request overhead. Resolve contradictions during drafting.
 - {{classificationInstructions}}
 - preserve `{{taskPath}}`: update content as needed but do not delete, rename, or move the file
 - do not edit the backlog `assignee` field; the workflow records ownership itself
 - predict the size of the change as a net engineering lines (NEL) bucket — Small (0–80), Medium (81–235) or Large (235+)
+- Plan a brief check where the implementer exercises the changed behavior through the running application’s public interface and records the observed result, using existing tools without adding E2E tests unless explicitly asked for in the intent.
 
 Bug-labeled missions (regression-test-first / "lock the bug"):
 - this section applies only when the backlog task at `{{taskPath}}` carries a `bug` label (in addition to its `ai_sdlc` or `user_value` classification). If there is no `bug` label, ignore this section entirely.
-- make the **first planned checkpoint** (`px checkpoint plan --name CP-1`) the authoring of a failing reproduction test that locks the bug before any fix is written. Describe in that checkpoint: the test file location (under `test/`), the reproduction scenario, and the assertion that fails at the mission's parent commit (red) and will pass once the fix lands (green).
+- make the **first planned checkpoint** (--checkpoint CP-1 in the batch) the authoring of a failing reproduction test that locks the bug before any fix is written. Describe in that checkpoint: the test file location (under `test/`), the reproduction scenario, and the assertion that fails at the mission's parent commit (red) and will pass once the fix lands (green).
 - record the reproduction test's path with `px repro set --test <path>` (for example, `px repro set --test test/task-1354-repro.test.ts`); the table above makes it required for a bug mission. `px status {{slug}}` reports it back for the reviewer to check against the diff.
 - do not author the fix during draft — the reproduction test and its recorded path are the only bug-specific drafting outputs.
 
-Graphify-first: before drafting, check if `graphify-out/graph.json` exists. If it does, run `graphify query "{{slug}} mission scope and dependencies"` to understand the codebase context before filling in the mission contract. Do not refresh Graphify after drafting; freshness is maintained at the autonomous-review boundary on the final verified tree.
+Graphify-first: before drafting, check if `graphify-out/graph.json` exists. If it does, run `graphify query "{{slug}} mission scope and dependencies"` to understand the codebase context before filling in the mission contract. Parallix updates existing Graphify graphs after successful squash integration on the receiving base worktree; review, edits and checkpoints do not trigger updates.
 
 Finishing:
 - verify the draft with `{{verifyCmd}}` before stopping

package/build/prompts/execute-core.md

@@ -12,12 +12,12 @@ Mission context is application-owned. Load it with:
 
 Execution supports evidence and completion writes:
 
-- `px mission mark-complete --slug {{slug}} --criterion <index> --expected-version <n>` — mark a verified success criterion complete using its one-based index and the current status Version.
+- `px mission mark-complete --slug {{slug}} --criterion <index>` — mark a verified success criterion complete using its one-based index. The write resolves its own current version; the status Version is diagnostic.
 - `px checkpoint record --name <CP-N> --criterion <text> --evidence <text> --next <text>` — `--criterion` and `--evidence` repeat and pair up in order.
 
 You do not change the mission here. The goal, scope, out-of-scope, success criteria, checkpoint plan and gates were settled at draft and are what your work is judged against; if you believe one of them is wrong, say so in your response and stop rather than editing it to match what you built.
 
-The slug is inferred from this worktree, so you do not pass it. The write takes `--expected-version <n>`, whose value is the `version` field reported by `px status {{slug}}`. A write against a stale version is rejected with an explicit conflict and changes nothing; re-read the status and retry deliberately. Run the command with `--help` for its exact flags.
+The slug is inferred from this worktree, so you do not pass it. Writes resolve their own current version, so you do not pass `--expected-version`; pass it only to pin a version. A competing write still fails with an explicit conflict and changes nothing. Run the command with `--help` for its exact flags.
 
 Harness preflight already confirmed:
 - branch/worktree shape
@@ -27,7 +27,7 @@ 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` 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.
+- Immediately after recording a checkpoint's evidence, {{checkpointContextAction}} 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.
@@ -37,15 +37,16 @@ Execution requirements:
   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"`
+  Raw stat/ls output and prose claims are context only. Prefer a repository-relative path reference and plain evidence text with no literal backticks or embedded double quotes. Example: px checkpoint record --name CP-2 --criterion '<exact success criterion text>' --evidence 'test/unit/example.test.ts passes under npm test -- test/unit/example.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.
+- Immediately after **each successful mission-declared Gate**, {{gateContextAction}} 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. Retain a failed gate's failure diagnostic while repairing it.
 - preserve `{{taskPath}}`: update mission-relevant content as needed but do not delete, rename, or move the file
-- do not change the Backlog task's status, assignee, labels, or lifecycle metadata, and do not run `px active`, `px review`, `px integrate`, `px assign` or `px unassign`; Parallix performs lifecycle transitions and review decisions itself. `px status {{slug}}` and `px history` are the supported reads in this phase, and `px checkpoint record` and `px mission mark-complete` are the supported writes.
+- do not change the Backlog task's status, assignee, labels, or lifecycle metadata, and do not run `px active`, `px review`, `px integrate`, `px assign` or `px unassign`; Parallix performs lifecycle transitions and review decisions itself. `px status {{slug}}`, `px checkpoint check --json` and `px history` are the supported reads in this phase, and `px checkpoint record` and `px mission mark-complete` are the supported writes.
 - earlier agent runs of this Mission (before a relaunch, a fallback family or a fresh context) are retained: `px history search <pattern>` and `px history show <ref>` return bounded slices with `run:` references and coverage notes. Cite those references instead of pasting transcripts into your context.
-- After verifying a success criterion, record completion with `px mission mark-complete --slug {{slug}} --criterion <index> --expected-version <n>`, using its one-based index and the current Version from `px status {{slug}}`. Reload status after each write. Use `--all` only when every criterion is verified. Recording checkpoint evidence does not mark criteria complete.
+- After verifying a success criterion, record completion with `px mission mark-complete --slug {{slug}} --criterion <index>`, using its one-based index. The write resolves its own current version; the status Version is diagnostic. Reload status after each write. Use `--all` only when every criterion is verified. Recording checkpoint evidence does not mark criteria complete.
+- Before declaring completion, run `px checkpoint check --slug {{slug}} --json`. Inspect `ready`, `version`, `findings`, `primaryStopReason` and `nextCommands`; a successful read is not evidence readiness. A recorded unresolved human-only contract blocker is the primary stop reason even when evidence is incomplete: stop for the operator, without fabricated evidence or repeated evidence-only repair. Do not use `record --force` or treat prose as resolution; only an explicit operator decision can clear the recorded blocker.
 - do not hand off to review until every success criterion is marked complete, or with uncommitted implementation work, or before the final checkpoint's evidence is recorded
 
-Graphify-first: before executing, check if `graphify-out/graph.json` exists. If it does, use `graphify query "<question>"` for codebase questions, `graphify path "<A>" "<B>"` for relationships, and `graphify explain "<concept>"` for focused concepts. Read `graphify-out/GRAPH_REPORT.md` only for broad architecture review. Graph freshness is handled at the autonomous-review boundary, after its final verification and immediately before reviewer launch; do not refresh after ordinary edits. If `graphify-out/wiki/index.md` exists, use it for broad navigation.
+Graphify-first: before executing, check if `graphify-out/graph.json` exists. If it does, use `graphify query "<question>"` for codebase questions, `graphify path "<A>" "<B>"` for relationships, and `graphify explain "<concept>"` for focused concepts. Read `graphify-out/GRAPH_REPORT.md` only for broad architecture review. Parallix updates existing Graphify graphs after successful squash integration on the receiving base worktree; review, edits and checkpoints do not trigger updates. If `graphify-out/wiki/index.md` exists, use it for broad navigation.
 
 {{checkpoint_context}}

package/build/prompts/review-core.md

@@ -20,7 +20,7 @@ Review history is not optional context:
 - Treat a `PUSHBACK_ALL` in the history as a response awaiting your decision, not as an approval and not as a fresh set of findings.
 
 Minimum loop contract:
-- When `{{attempt}}` is 2 or later, before beginning this review round compact the prior-round working context. Reload the locked mission goal and scope; committed checkpoint or gate evidence when present; current round and disposition; unresolved findings and implementer resolutions; and the exact post-rebase revision and review baseline shown by `git diff {{reviewBaseline}}..HEAD`. This compaction is independent of the mission's declared gates.
+- When `{{attempt}}` is 2 or later, before beginning this review round {{reviewContextAction}} the locked mission goal and scope; committed checkpoint or gate evidence when present; current round and disposition; unresolved findings and implementer resolutions; and the exact post-rebase revision and review baseline shown by `git diff {{reviewBaseline}}..HEAD`. This compaction is independent of the mission's declared gates.
 - Load the Mission context with `px status {{slug}}` and read `AGENTS.md` before reviewing.
 - The block below reports which controls the workflow has already executed for this mission and which it has not, derived from machine records rather than from anyone's prose. Do not re-run a listed command whose recorded status is `passed`; cite the recorded result from this block instead. Re-running is permitted only when the block reports no recorded gate result, reports a `failed` status, reports a control as not yet run, or the command you need is not listed here.
 {{completedControls}}
@@ -49,8 +49,8 @@ Check:
 - maintainability issues that materially affect future work
 
 - Decision submission is mandatory: your final chat response does **not** submit a review. Before stopping, run exactly one of:
-  - `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>"`
+  - `px verdict approve --slug {{slug}} --actor {{reviewer}} --comment "<review summary>"`
+  - `px verdict request-changes --slug {{slug}} --actor {{reviewer}} --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.