@magnusekdahl/parallix 1.5.262 → 1.5.317

package/NOTICES

@@ -1,4 +1,4 @@
-THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.262
+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
@@ -69,7 +70,7 @@ pino-std-serializers@7.1.0 — MIT — https://github.com/pinojs/pino-std-serial
 process-warning@4.0.1 — MIT — https://github.com/fastify/fastify-warning#readme
 process-warning@5.1.0 — MIT — https://github.com/fastify/fastify-warning#readme
 quick-format-unescaped@4.0.4 — MIT — https://github.com/davidmarkclements/quick-format#readme
-react@19.2.8 — MIT — https://react.dev/
+react@19.3.0 — MIT — https://react.dev/
 react-reconciler@0.33.0 — MIT — https://react.dev/
 restore-cursor@4.0.0 — MIT — sindresorhus/restore-cursor
 ret@0.5.0 — MIT — git://github.com/fent/ret.js.git
@@ -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)
 ------------------------------------------------------------------------------
@@ -1051,7 +1184,7 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 
 ------------------------------------------------------------------------------
-react@19.2.8 (MIT)
+react@19.3.0 (MIT)
 react-reconciler@0.33.0 (MIT)
 scheduler@0.27.0 (MIT)
 ------------------------------------------------------------------------------

package/README.md

@@ -1,13 +1,13 @@
 # Parallix
 
-**Parallix is an agent-agnostic, local-first workflow that puts a trust ladder around AI coding work: separate review that prefers a different agent family when one is available, repository-owned verification where you configure a gate, Linux Bubblewrap confinement when available (falling back to an agent's native sandbox, or blocking until explicit consent when neither exists), and a human-owned squash merge.**
+**Parallix is a local-first workflow and trust layer for AI coding agents: it runs each piece of work as an isolated mission in its own Git worktree, sends the result to a separate code review that prefers a different agent family when one is available, runs repository-owned verification where you configure a gate, confines agents with Linux Bubblewrap when available (falling back to an agent's native sandbox, or blocking until explicit consent when neither exists), and leaves the squash merge to a human.**
+
+It works with Codex CLI, Claude Code, Qwen Code, and Mistral Vibe, and runs OpenCode or Pi through its configurable custom runner, so drafting, implementation, and review can use different agent families, including locally hosted AI.
 
 Coding agents become much more useful when you can run several pieces of work at once. But simply starting more agents quickly creates a new bottleneck: they compete for the same working tree, lose context across long runs, hit provider limits, and produce more changes than one engineer can safely supervise and integrate.
 
 Parallix is the delivery layer around those agents. It gives every piece of work an isolated mission, lets multiple missions progress concurrently, preserves execution across sessions, separates implementation from review, runs repository-owned verification, and leaves the final integration decision with the human operator. Parallel Git isolation is how that trust ladder can operate across concurrent missions instead of one shared checkout.
 
-Parallix is deliberately not tied to one agent vendor or model family. The same mission workflow can use different agent families for drafting, implementation, and review, including commercially hosted agents, locally hosted AI, and custom runtimes.
-
 ## Install
 
 For Bash, install Parallix and load its bundled worktree-switching integration
@@ -35,9 +35,9 @@ The main reason to use coding agents is leverage: while one agent is working, an
 
 Parallix is a mission-based development workflow that addresses each of these directly so parallel agents can translate into actual delivery throughput. The mechanics live in tested code rather than in prompts. It is not another agent or model — it is the operator-owned layer around the agents you already use.
 
-![Observed one-maintainer dogfooding throughput: all completed Parallix missions per full UTC ISO week, with a manual proxy of 2 missions/week.](https://raw.githubusercontent.com/oxtan-maker/parallix/main/docs/assets/velocity-throughput.svg)
+![Observed one-maintainer dogfooding throughput: all completed Parallix missions per full UTC ISO week, with a historical baseline of approximately 2 delivery units/week.](https://raw.githubusercontent.com/oxtan-maker/parallix/main/docs/assets/velocity-throughput.svg)
 
-Observed one-maintainer dogfooding throughput. The [methodology](docs/metrics/velocity/README.md) defines the mission population, historical manual reference, and limitations.
+Observed one-maintainer dogfooding throughput. The [methodology and evidence](docs/metrics/velocity/README.md) define the mission population, historical reference, and limitations.
 
 ## What it does
 
@@ -52,6 +52,13 @@ Observed one-maintainer dogfooding throughput. The [methodology](docs/metrics/ve
 - **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.
 
+## Supported coding agents
+
+- **Built-in families:** Codex CLI (`codex`), Claude Code (`claude`), Qwen Code (`qwen`), and Mistral Vibe (`vibe`). Install and sign in to each agent CLI you want Parallix to use.
+- **Custom runner:** OpenCode (`opencode`) or Pi (`pi`) run as the `custom` family. Select one with `adapters.agents.runners.custom` in `workflow.config.json`; OpenCode is the default. Pi needs the optional `@earendil-works/pi-coding-agent` package.
+
+Which families may draft, implement, and review is set per step in `config/agents.json`; Parallix chooses among the eligible families that are installed and not blocked by a usage limit. Mistral Vibe runs do not resume an earlier session; an interrupted Vibe run starts fresh from the recorded checkpoints. See the [agent configuration](docs/config.md#agents) for model and runner options.
+
 ## The core workflow
 
 A mission moves through a fixed lifecycle, one branch and one worktree at a time:
@@ -77,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.
+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.
@@ -161,6 +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).
 
 ## What Parallix is not
 

package/build/asset-manifest.json

@@ -3,7 +3,7 @@
   "assets": [
     {
       "key": "config/agents.json",
-      "sha256": "c380d909ddf757f9bbe5136d79652a19396ae69068d144e2b6031ed4b7fb4b78"
+      "sha256": "ec3ec505e42adc8cddc17651d7a1a85b6359a433e1e62f3c6c22a4896150187f"
     },
     {
       "key": "config/state-map.json",
@@ -11,15 +11,15 @@
     },
     {
       "key": "prompts/act-on-review-core.md",
-      "sha256": "677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f"
+      "sha256": "6efbfc58fba6d4224ac05d23c3b08ca2ce33b11e67cae63adef07ceda9fa5125"
     },
     {
       "key": "prompts/act-on-review.md",
-      "sha256": "8f06b68b92c8cfc6f3ee0ff7a1e258258c1a1c2220bdfe5b1a3d5fbaab6befeb"
+      "sha256": "412facaee4a56f6436317d6b228ff57cb0605aca88ca143056ab50895ef62eee"
     },
     {
       "key": "prompts/draft-core.md",
-      "sha256": "4f53057f8bef0343d163c9b8a6539601ecc34462cb20195bf93acaf09e355a35"
+      "sha256": "794bc41c7ce01d3f5ec06aa4ae37c75dfc54079c1ca62062f231c45d91d9637b"
     },
     {
       "key": "prompts/draft.md",
@@ -27,7 +27,7 @@
     },
     {
       "key": "prompts/execute-core.md",
-      "sha256": "24d5c4f86d55c47eaa32b040c5b551ba665da7503fefcf0a3d8328767003918f"
+      "sha256": "1db19f3697c6e27baf87dc984b8b03e846359d63b495dc19e1ac78c97982cc8a"
     },
     {
       "key": "prompts/execute.md",
@@ -35,7 +35,7 @@
     },
     {
       "key": "prompts/review-core.md",
-      "sha256": "e6c0aa4683fac33f41b79fb27407cd3c9de384239d2b1067e2b30acb5e7fecb0"
+      "sha256": "607d968e782bd9647e15a6aea3eb7705f0d83b61eb39c220eeb6f3fc00fa6098"
     },
     {
       "key": "prompts/review.md",
@@ -164,6 +164,22 @@
     {
       "key": "migrations/0029-mission-success-criterion-completion.sql",
       "sha256": "b4091b8c3d770f8ac5072745a234de10d6e02cc3c4f0e6497888629041b54e7e"
+    },
+    {
+      "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 @@
-f9c7d0e0d69bdbaf1536c74d95710d234e2dce66f1692cc4846805d85ad704df  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
@@ -31,20 +31,24 @@ a0c669ba6c6883bb498c59eb8a8a1688dc445de56520a22d7c0302b4a2fbf8b0  migrations/002
 785f9c292ebb9ba9c72acfad03eff6c45387f44459604bd07ba17a676c605775  migrations/0027-review-decision-supersessions.sql
 0196b4d563b829467680704349e591085597cb59e34052df0d72b4b78892f51a  migrations/0028-review-revocation-cause.sql
 b4091b8c3d770f8ac5072745a234de10d6e02cc3c4f0e6497888629041b54e7e  migrations/0029-mission-success-criterion-completion.sql
-a995c524c742061f10a3d6358617eeefa8a0337c6e67325bb443816c7bf79879  package.json
-677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f  prompts/act-on-review-core.md
-8f06b68b92c8cfc6f3ee0ff7a1e258258c1a1c2220bdfe5b1a3d5fbaab6befeb  prompts/act-on-review.md
-4f53057f8bef0343d163c9b8a6539601ecc34462cb20195bf93acaf09e355a35  prompts/draft-core.md
+746f8bf0b0edb91367dd426fc926264e803c7d17ede8689ad2a8457757002a7c  migrations/0030-review-classification.sql
+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
-24d5c4f86d55c47eaa32b040c5b551ba665da7503fefcf0a3d8328767003918f  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
-3dc02d5fdfae82022a19035448963779f94ec9a954adb8511113f68002b12bdb  px.mjs
-5af8222dddac8cbc94306fc0442fc6dfa57613af43056fa79537c686fcc74eb6  px.mjs.map
-acee4497d1c75d1307af8907f4f0e4a9b9aae3531ff8d8cca55abbc3ee3d8485  sbom.json
+fc37ee4be11716e2f2f4bfd6e8d36977df8710c119535d864b2db84151eb3202  px.mjs
+7d64339dfa0e7465f525f81e636a9bf04f90482e22fa135b55fd3d5d9b82177b  px.mjs.map
+2fcab12164ffe2b979404d112c09614fe80c266add18e43eb77d71880aa61b09  sbom.json
 64ceff9f8a45d1769c8e70b0545a554065ffd285aa33b862447cb2ac70d28093  templates/mission-scaffold.md
-6cc2fe0fd98e18b5c8024cf84d4384b9f82c561a42e55336ac683cc4884e1a01  web/assets/index-BmXLD5QW.js
-807f92b40d54c1112d284e7c491702aa90e25edfc32ff5af9f4889beec5583a8  web/assets/index-DYY4ROtr.css
-fb5b6086654ffa9bd657332bb3ce0023511aa821fe7feafd84ae969f3165d092  web/index.html
-d53784041bd6482762d67ec0736b376808bbc597b56d285d270596eb6a7dcb79  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/0030-review-classification.sql

@@ -0,0 +1,12 @@
+-- Classifier provenance belongs to Review; bounded measurements own no attempt lifecycle.
+ALTER TABLE mission_review_rounds ADD COLUMN classifier_source TEXT;
+CREATE TABLE review_classifier_measurements (
+  decision_id TEXT PRIMARY KEY NOT NULL,
+  repository_id TEXT NOT NULL,
+  samples TEXT NOT NULL CHECK(length(samples) <= 131072)
+);
+CREATE INDEX review_classifier_measurements_repository ON review_classifier_measurements(repository_id);
+CREATE TABLE review_classifier_observations (
+  decision_id TEXT PRIMARY KEY NOT NULL,
+  payload TEXT NOT NULL CHECK(length(payload) <= 16384)
+);

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.262",
+  "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/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. Run `graphify update .` after modifying code.
+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.

package/build/prompts/draft-core.md

@@ -59,7 +59,7 @@ Bug-labeled missions (regression-test-first / "lock the bug"):
 - 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. After drafting, run `graphify update .` if you modified any code files.
+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.
 
 Finishing:
 - verify the draft with `{{verifyCmd}}` before stopping

package/build/prompts/execute-core.md

@@ -25,28 +25,27 @@ 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
-- 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}}` is the supported read 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}}` 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.
 - 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. Run `graphify update .` after modifying code. 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. 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.
 
 {{checkpoint_context}}

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.