@magnusekdahl/parallix 1.5.187 → 1.5.233

package/NOTICES

@@ -1,4 +1,4 @@
-THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.187
+THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.233
 
 @magnusekdahl/parallix itself is licensed under AGPL-3.0-or-later; see LICENSE.
 
@@ -46,9 +46,9 @@ fast-decode-uri-component@1.0.1 — MIT — https://github.com/delvedor/fast-dec
 fast-deep-equal@3.1.3 — MIT — https://github.com/epoberezkin/fast-deep-equal#readme
 fast-json-stringify@7.0.1 — MIT — https://github.com/fastify/fast-json-stringify#readme
 fast-querystring@1.1.2 — MIT — git+https://github.com/anonrig/fast-querystring.git
-fast-uri@3.1.6 — BSD-3-Clause — https://github.com/fastify/fast-uri
-fast-uri@4.1.3 — BSD-3-Clause — https://github.com/fastify/fast-uri
-fastify@5.12.1 — MIT — https://fastify.dev/
+fast-uri@3.1.8 — BSD-3-Clause — https://github.com/fastify/fast-uri
+fast-uri@4.2.1 — BSD-3-Clause — https://github.com/fastify/fast-uri
+fastify@5.12.5 — MIT — https://fastify.dev/
 fastq@1.20.2 — ISC — https://github.com/mcollina/fastq#readme
 find-my-way@9.9.0 — MIT — https://github.com/delvedor/find-my-way#readme
 get-east-asian-width@1.6.0 — MIT — sindresorhus/get-east-asian-width
@@ -686,8 +686,8 @@ IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
 DEALINGS IN THE SOFTWARE.
 
 ------------------------------------------------------------------------------
-fast-uri@3.1.6 (BSD-3-Clause)
-fast-uri@4.1.3 (BSD-3-Clause)
+fast-uri@3.1.8 (BSD-3-Clause)
+fast-uri@4.2.1 (BSD-3-Clause)
 ------------------------------------------------------------------------------
 
 Copyright (c) 2011-2021, Gary Court until https://github.com/garycourt/uri-js/commit/a1acf730b4bba3f1097c9f52e7d9d3aba8cdcaae
@@ -722,7 +722,7 @@ The complete list of contributors can be found at:
 - https://github.com/garycourt/uri-js/graphs/contributors
 
 ------------------------------------------------------------------------------
-fastify@5.12.1 (MIT)
+fastify@5.12.5 (MIT)
 ------------------------------------------------------------------------------
 
 MIT License

package/README.md

@@ -60,7 +60,9 @@ backlog → draft → active → review → approved → done
                   checkpoints  gates   cleanup
 ```
 
-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. 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. Blocking review findings loop back to `active` on the same branch and PR.
+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.
 
 ## Defence in depth
 
@@ -105,7 +107,7 @@ px active task-042
 px integrate task-042
 ```
 
-Parallix runs on built-in defaults with no config file; `px setup` writes one when you want to declare your own verification gate or mission layout. See the [configuration reference](docs/config.md) for the supported overrides and their defaults. The verification gate that runs at each phase is whatever you declare in `workflow.config.json`. In this repo, earlier phases use the fast general suite; `px integrate` runs the stricter pre-integration gates declared in `workflow.config.json`. Independent gates can run concurrently, while a gate that consumes an artifact waits for its producer. In a terminal, integration shows one row per configured gate and lets you inspect its isolated output; failures expand their output automatically. Local SonarQube Cloud analysis waits for fresh coverage from the same mission checkout; the service decision and reconsideration triggers are in [ADR 0060](docs/adr/0060-per-worktree-sonarqube-analysis-identity.md). The Cloud scan entrypoint shared with GitHub is `npm run sonar` (config in `sonar-project.properties`; the operator token is exported, never committed).
+Parallix runs on built-in defaults with no config file; `px setup` writes one when you want to declare your own verification gate or mission layout. See the [configuration reference](docs/config.md) for the supported overrides and their defaults. The verification gate that runs at each phase is whatever you declare in `workflow.config.json`. In this repo, earlier phases use the fast general suite; `px integrate` runs the stricter pre-integration gates declared in `workflow.config.json`. Independent gates can run concurrently, while a gate that consumes an artifact waits for its producer. In a terminal, integration shows one row per configured gate and lets you inspect its isolated output; failures expand their output automatically. When a repair attempt exhausts its budget, integration exits with a failure status and returns control to the shell for the stated manual action. Local SonarQube Cloud analysis waits for fresh coverage from the same mission checkout; the service decision and reconsideration triggers are in [ADR 0060](docs/adr/0060-per-worktree-sonarqube-analysis-identity.md). The Cloud scan entrypoint shared with GitHub is `npm run sonar` (config in `sonar-project.properties`; the operator token is exported, never committed).
 
 When a mission goes wrong and you want to start it over, `px cancel <slug> --yes`
 retires it: it deletes that one mission's lifecycle rows from the operator
@@ -148,7 +150,7 @@ acting, and naming missions narrows the run to those.
 
 Both are optional integrations, and each one is wired independently of the other.
 
-**Backlog.md.** Point `px draft` at a task key and Parallix adopts the existing record instead of creating one: it reads the ID, title, labels, and classification from `backlog/tasks/<slug> - <title>.md` and carries them through the mission. As the mission moves, Parallix writes the task's `status` frontmatter and, by default, moves the file into `backlog/completed/`, so the board reflects mission state without a second bookkeeping step. A self-hosting repository can explicitly opt out of retaining that completed-task mirror. Drafting from free text instead produces an equivalent synthetic record, so nothing downstream depends on you keeping task files.
+**Backlog.md.** Point `px draft` at a task key and Parallix adopts the existing record instead of creating one: it reads the ID, title, labels, and classification from `backlog/tasks/<slug> - <title>.md` and carries them through the mission. The key must name an existing task: `px draft task-12.04` stops with a missing-task error when only `task-12` exists, before any branch, worktree, or Mission state is created, while a suffixed slug such as `task-12-followup` still adopts `task-12`. From then on the Mission owns its classification: `px classification set` changes it, and startup preflight and stage statistics read the stored value, so a later empty or conflicting task label neither blocks nor overrides it. Classification-dependent commands require a readable stored Mission; import legacy missions before recording statistics. A task label cannot replace missing or unreadable Mission state. As the mission moves, Parallix writes the task's `status` frontmatter and, on completion, moves the file into `backlog/completed/`, so the board reflects mission state without a second bookkeeping step. Drafting from free text instead produces an equivalent synthetic record, so nothing downstream depends on you keeping task files.
 
 **Forgejo.** Review publication is off until you opt in. If you want its reviewer surface, `px setup` can bootstrap the review repository, agent tokens, and the `review` git remote; otherwise the branch/worktree workflow runs without Forgejo. Forgejo user accounts must already exist before that optional setup; see [`docs/forgejo-setup.md`](docs/forgejo-setup.md) for account creation, token layout, and running a local instance.
 
@@ -169,7 +171,7 @@ An **internal retrospective, not external evidence,** measured the isolated work
 
 **Alpha, local-first, and best suited to operators comfortable with Git and CLI workflows.**
 
-- **Distribution:** Published to the public npm registry as `@magnusekdahl/parallix`. Local tarball install (`npm pack`) is also supported. No Homebrew, no Docker image, no standalone binary, and no CI/release automation today.
+- **Distribution:** Published to the public npm registry as @magnusekdahl/parallix. Verified main commits are continuously delivered/ published through GitHub Actions using npm Trusted Publishing with provenance, with a matching Git tag and GitHub Release. Local tarball installation (npm pack) is also supported.
 - **Review surface:** Forgejo is supported as the hosted PR viewer/publication surface, but the workflow remains local-first and can run without Forgejo when that provider is disabled.
 - **Telemetry:** structured token/usage telemetry exists for the codex and claude families; the local-custom and mistral paths record honest zeros by design rather than fabricated numbers.
 - **Graphify:** the knowledge-graph path is supported for codex, claude, and custom/opencode after one-time operator setup. It is optional, not a workflow prerequisite. The credible claim today is better-scoped context retrieval, not a proven token-savings benchmark.
@@ -203,7 +205,7 @@ npm run test:codeql       # CodeQL SAST scan (javascript-typescript security/cod
 LCOV reports omit TypeScript modules that compile to no runtime code. Modules
 with runtime declarations or imports remain subject to coverage requirements.
 
-The test suite is the verification gate this repo declares in `workflow.config.json`. Run it before integrating any change. 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`.
+The test suite is the verification gate this repo declares in `workflow.config.json`. Run it before integrating any change. Coverage runs (`PARALLIX_TEST_COVERAGE=1`, used by GitHub CI and the local pre-integration gates) use Node's built-in coverage with `--test-coverage-include-all` and need Node 26.7 or newer; the runner picks one from `PATH` or nvm, or from `PARALLIX_TEST_NODE` (ADR 0062). 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
 after `npm run build`, or run the TypeScript entry directly with the development

package/build/asset-manifest.json

@@ -27,7 +27,7 @@
     },
     {
       "key": "prompts/execute-core.md",
-      "sha256": "28b39c53c6af6930e6fb21f734c64f24aac033e863e1eb2fc3f10a3023465198"
+      "sha256": "244e0318da95767c5a0221d4a403ecbe7f20f639362989682d3fb299097d4013"
     },
     {
       "key": "prompts/execute.md",
@@ -35,11 +35,11 @@
     },
     {
       "key": "prompts/review-core.md",
-      "sha256": "3559ac4927931b1869c892626b68ca72d3dcb43eee15f335ac456f404244172d"
+      "sha256": "e6c0aa4683fac33f41b79fb27407cd3c9de384239d2b1067e2b30acb5e7fecb0"
     },
     {
       "key": "prompts/review.md",
-      "sha256": "8355020da213d320d318eac5184863c0c73a5a46ef2495fd37ac1ab8f57cf6fa"
+      "sha256": "06431c3f965935db27b254164d3bfa66aa7cc2a5602031f181dcc5e32f3e5739"
     },
     {
       "key": "templates/mission-scaffold.md",
@@ -152,6 +152,14 @@
     {
       "key": "migrations/0026-review-decision-revocations.sql",
       "sha256": "2f1495264f516fa06d10434f03dd9765261198e709dc571763469f4b7c7e8513"
+    },
+    {
+      "key": "migrations/0027-review-decision-supersessions.sql",
+      "sha256": "785f9c292ebb9ba9c72acfad03eff6c45387f44459604bd07ba17a676c605775"
+    },
+    {
+      "key": "migrations/0028-review-revocation-cause.sql",
+      "sha256": "0196b4d563b829467680704349e591085597cb59e34052df0d72b4b78892f51a"
     }
   ]
 }

package/build/manifest.sha256

@@ -1,4 +1,4 @@
-c1f70b0cae5cf5470ab01ab0c7f856c50d2c50c4a8ca5296ead2b1ca0e0c7995  asset-manifest.json
+233b8f80acc95f6374b81ba7a608a9a9c3b5b12283d996e4d43fff87b761db96  asset-manifest.json
 c380d909ddf757f9bbe5136d79652a19396ae69068d144e2b6031ed4b7fb4b78  config/agents.json
 6a4ec47387d1240e32967dc8e4ce54a15d69df2676b7a96ff72baafe996fef7d  config/state-map.json
 30a76fa3839753ddbfe312428dd1b7285ac1b8d0bd678fc79c79018ec6154f69  migrations/0001-initial-schema.sql
@@ -28,18 +28,20 @@ a0c669ba6c6883bb498c59eb8a8a1688dc445de56520a22d7c0302b4a2fbf8b0  migrations/002
 811f8d5856a66b2daf88f5a586b6ce03eae7e9acf95aa9c6c733399dd2679057  migrations/0024-mission-success-criteria-and-predicted-nel.sql
 90b784413abbe8643d02ea84103a15909def367fb80f1eedbac4ba50abc90535  migrations/0025-mission-dependencies.sql
 2f1495264f516fa06d10434f03dd9765261198e709dc571763469f4b7c7e8513  migrations/0026-review-decision-revocations.sql
-95dd163ac741095e54717142a9b3a3e44e0c64861a0577911a0d5b3c010b5d70  package.json
+785f9c292ebb9ba9c72acfad03eff6c45387f44459604bd07ba17a676c605775  migrations/0027-review-decision-supersessions.sql
+0196b4d563b829467680704349e591085597cb59e34052df0d72b4b78892f51a  migrations/0028-review-revocation-cause.sql
+ad0361e447ca6886a613013b69fe63d302af807eb1c8f3cb336cb0a28f776aa7  package.json
 677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f  prompts/act-on-review-core.md
 8f06b68b92c8cfc6f3ee0ff7a1e258258c1a1c2220bdfe5b1a3d5fbaab6befeb  prompts/act-on-review.md
 4f53057f8bef0343d163c9b8a6539601ecc34462cb20195bf93acaf09e355a35  prompts/draft-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/draft.md
-28b39c53c6af6930e6fb21f734c64f24aac033e863e1eb2fc3f10a3023465198  prompts/execute-core.md
+244e0318da95767c5a0221d4a403ecbe7f20f639362989682d3fb299097d4013  prompts/execute-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/execute.md
-3559ac4927931b1869c892626b68ca72d3dcb43eee15f335ac456f404244172d  prompts/review-core.md
-8355020da213d320d318eac5184863c0c73a5a46ef2495fd37ac1ab8f57cf6fa  prompts/review.md
-fbda69fa78f649e4a1414570cf593a139f282ba102ed8a2934e2c1655f028be3  px.mjs
-e2ca324bc8cf80cc02db0fe1eeb3f9adb401149b1dc67a47ab50f87e448114cb  px.mjs.map
-450361201bcece041378ea21c7d8402d35d48b32e4e2a51702c9e3950e0b13a8  sbom.json
+e6c0aa4683fac33f41b79fb27407cd3c9de384239d2b1067e2b30acb5e7fecb0  prompts/review-core.md
+06431c3f965935db27b254164d3bfa66aa7cc2a5602031f181dcc5e32f3e5739  prompts/review.md
+1000fc056ac9d4484355b2bbcd1d709e0bc8e33541f0333b5c81f67c17a2556b  px.mjs
+7b785274d313863e97502b8f91a61b6061648c1ddaab7f8c047af2551e9ea364  px.mjs.map
+ec6b57964a08397493d303b97ae65d117addb7018d5cad939863036919a288b5  sbom.json
 ce7f4aa6eb9e684434f243a64018d4dfa9962348bfdb5d59881783326cc0ec90  templates/mission-scaffold.md
 6cc2fe0fd98e18b5c8024cf84d4384b9f82c561a42e55336ac683cc4884e1a01  web/assets/index-BmXLD5QW.js
 807f92b40d54c1112d284e7c491702aa90e25edfc32ff5af9f4889beec5583a8  web/assets/index-DYY4ROtr.css

package/build/migrations/0027-review-decision-supersessions.sql

@@ -0,0 +1,6 @@
+-- A branch move recorded against an approval (TASK-2555).  Like a revocation
+-- it is an additive audit fact on the original decision: the approval and its
+-- reviewed revision stay in place, and the superseding revision is named.
+ALTER TABLE mission_review_rounds ADD COLUMN superseded_at TEXT;
+ALTER TABLE mission_review_rounds ADD COLUMN superseding_revision TEXT;
+ALTER TABLE mission_review_rounds ADD COLUMN superseded_by TEXT;

package/build/migrations/0028-review-revocation-cause.sql

@@ -0,0 +1,21 @@
+-- Why an approval was withdrawn, as a typed fact (TASK-2620).  Detection of
+-- an integration repair reads the cause, never the free-text reason.  The
+-- gate, its command and an output tail name the red integration gate so the
+-- repaired mission and its re-review can show what failed.
+ALTER TABLE mission_review_rounds ADD COLUMN revoked_cause TEXT;
+ALTER TABLE mission_review_rounds ADD COLUMN revoked_gate TEXT;
+ALTER TABLE mission_review_rounds ADD COLUMN revoked_gate_command TEXT;
+ALTER TABLE mission_review_rounds ADD COLUMN revoked_gate_log TEXT;
+
+-- Revocations recorded before causes were typed carry their cause only in
+-- the workflow's fixed reason text; classify them once here.
+UPDATE mission_review_rounds
+   SET revoked_cause = 'integration-gate-failure'
+ WHERE revoked_at IS NOT NULL
+   AND revoked_by = 'workflow'
+   AND revoked_reason LIKE 'Integration gates failed;%';
+UPDATE mission_review_rounds
+   SET revoked_cause = 'operator'
+ WHERE revoked_at IS NOT NULL
+   AND revoked_cause IS NULL
+   AND revoked_by <> 'workflow';

package/build/package.json

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

package/build/prompts/execute-core.md

@@ -25,6 +25,7 @@ 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.
+- 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 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.

package/build/prompts/review-core.md

@@ -12,6 +12,8 @@ Load before reviewing:
 
 `px status` is the authority for Mission state. Nothing in the repository records it.
 
+{{integrationRepair}}
+
 Review history is not optional context:
 - You may not be the agent family that reviewed the previous round. When a family is usage-blocked the workflow reroutes the launch, so the round-1 reviewer's context is simply gone. `px status {{slug}}` is how that continuity is preserved.
 - Do not re-raise a finding a previous round already settled. If the implementer fixed it, verify the fix instead of restating the finding. If the implementer pushed back, engage with their rationale — accept it, or explain specifically why it does not hold.

package/build/prompts/review.md

@@ -1 +1 @@
-Do not run any large test gates, thats run automatically by parallix at suitable steps and is not your job. Specific test to validate a code finding is ok.
+Do not run large batched test coverage commands that Parallix has already run or intentionally schedules for a later verification phase. Run a focused test only when it validates a specific review finding.