@magnusekdahl/parallix 1.5.233 → 1.5.254

package/NOTICES

@@ -1,4 +1,4 @@
-THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.233
+THIRD-PARTY NOTICES for @magnusekdahl/parallix 1.5.254
 
 @magnusekdahl/parallix itself is licensed under AGPL-3.0-or-later; see LICENSE.
 

package/README.md

@@ -35,6 +35,10 @@ 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. The [methodology](docs/metrics/velocity/README.md) defines the mission population, historical manual reference, and limitations.
+
 ## What it does
 
 - **Run several AI coding agents on one repo without clobbering each other**. Every mission gets its own `mission/<slug>` branch and its own sibling git worktree (`../<repo>-<slug>`) automatically, so N agents make progress independently and each lands by squash-merge.
@@ -158,8 +162,6 @@ Both are optional integrations, and each one is wired independently of the other
 
 The durable capability guide and confidence boundaries are in [`docs/use-cases.md`](docs/use-cases.md).
 
-An **internal retrospective, not external evidence,** measured the isolated worktree-per-mission model as the only configuration to beat a human baseline. Depending on whether you frame output as direct user-value missions or total completed missions in an already-productized setup, the observed gain ranges from roughly **+57%** to about **an order of magnitude**.
-
 ## What Parallix is not
 
 - **Not a model and not an AI coding agent.** It does not generate code itself. It is agent-agnostic infrastructure around the agents and models you already use, including hosted and local AI.
@@ -171,7 +173,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. 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.
+- **Distribution:** Published to the public npm registry as @magnusekdahl/parallix. Verified main commits are continuously 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.
@@ -205,7 +207,9 @@ 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. 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`.
+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).
+
+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
 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": "244e0318da95767c5a0221d4a403ecbe7f20f639362989682d3fb299097d4013"
+      "sha256": "24d5c4f86d55c47eaa32b040c5b551ba665da7503fefcf0a3d8328767003918f"
     },
     {
       "key": "prompts/execute.md",
@@ -160,6 +160,10 @@
     {
       "key": "migrations/0028-review-revocation-cause.sql",
       "sha256": "0196b4d563b829467680704349e591085597cb59e34052df0d72b4b78892f51a"
+    },
+    {
+      "key": "migrations/0029-mission-success-criterion-completion.sql",
+      "sha256": "b4091b8c3d770f8ac5072745a234de10d6e02cc3c4f0e6497888629041b54e7e"
     }
   ]
 }

package/build/manifest.sha256

@@ -1,4 +1,4 @@
-233b8f80acc95f6374b81ba7a608a9a9c3b5b12283d996e4d43fff87b761db96  asset-manifest.json
+4707e0bf64a791c6e0f03a69d0d6058967de0e3c5b09c7df6c80d641ccddb1a1  asset-manifest.json
 c380d909ddf757f9bbe5136d79652a19396ae69068d144e2b6031ed4b7fb4b78  config/agents.json
 6a4ec47387d1240e32967dc8e4ce54a15d69df2676b7a96ff72baafe996fef7d  config/state-map.json
 30a76fa3839753ddbfe312428dd1b7285ac1b8d0bd678fc79c79018ec6154f69  migrations/0001-initial-schema.sql
@@ -30,18 +30,19 @@ a0c669ba6c6883bb498c59eb8a8a1688dc445de56520a22d7c0302b4a2fbf8b0  migrations/002
 2f1495264f516fa06d10434f03dd9765261198e709dc571763469f4b7c7e8513  migrations/0026-review-decision-revocations.sql
 785f9c292ebb9ba9c72acfad03eff6c45387f44459604bd07ba17a676c605775  migrations/0027-review-decision-supersessions.sql
 0196b4d563b829467680704349e591085597cb59e34052df0d72b4b78892f51a  migrations/0028-review-revocation-cause.sql
-ad0361e447ca6886a613013b69fe63d302af807eb1c8f3cb336cb0a28f776aa7  package.json
+b4091b8c3d770f8ac5072745a234de10d6e02cc3c4f0e6497888629041b54e7e  migrations/0029-mission-success-criterion-completion.sql
+ae6f41102ed6835a80f386b1fc784a4e47eebb664e3c45bbc1f6b10aed920a55  package.json
 677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f  prompts/act-on-review-core.md
 8f06b68b92c8cfc6f3ee0ff7a1e258258c1a1c2220bdfe5b1a3d5fbaab6befeb  prompts/act-on-review.md
 4f53057f8bef0343d163c9b8a6539601ecc34462cb20195bf93acaf09e355a35  prompts/draft-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/draft.md
-244e0318da95767c5a0221d4a403ecbe7f20f639362989682d3fb299097d4013  prompts/execute-core.md
+24d5c4f86d55c47eaa32b040c5b551ba665da7503fefcf0a3d8328767003918f  prompts/execute-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/execute.md
 e6c0aa4683fac33f41b79fb27407cd3c9de384239d2b1067e2b30acb5e7fecb0  prompts/review-core.md
 06431c3f965935db27b254164d3bfa66aa7cc2a5602031f181dcc5e32f3e5739  prompts/review.md
-1000fc056ac9d4484355b2bbcd1d709e0bc8e33541f0333b5c81f67c17a2556b  px.mjs
-7b785274d313863e97502b8f91a61b6061648c1ddaab7f8c047af2551e9ea364  px.mjs.map
-ec6b57964a08397493d303b97ae65d117addb7018d5cad939863036919a288b5  sbom.json
+8581c47c714a133efc350e64de1ce59d5b60650089ad8d303ebe176e66d3edb2  px.mjs
+21587a43d9bb5bbcd84a9f7f0f5f100fb2df48cfdafc4aff931f7dc5a0affbdf  px.mjs.map
+3b2a6d0533b9d535086478d14b09fb797c4504c85163d78f205f7680d171b733  sbom.json
 ce7f4aa6eb9e684434f243a64018d4dfa9962348bfdb5d59881783326cc0ec90  templates/mission-scaffold.md
 6cc2fe0fd98e18b5c8024cf84d4384b9f82c561a42e55336ac683cc4884e1a01  web/assets/index-BmXLD5QW.js
 807f92b40d54c1112d284e7c491702aa90e25edfc32ff5af9f4889beec5583a8  web/assets/index-DYY4ROtr.css

package/build/migrations/0029-mission-success-criterion-completion.sql

@@ -0,0 +1,4 @@
+-- TASK-2631: success criteria carry a completion state, addressed by position.
+-- Existing rows migrate as incomplete: nothing recorded them as done, so none
+-- may be inferred to be.
+ALTER TABLE mission_success_criteria ADD COLUMN completed INTEGER NOT NULL DEFAULT 0 CHECK (completed IN (0, 1));

package/build/package.json

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

package/build/prompts/execute-core.md

@@ -10,8 +10,9 @@ Mission context is application-owned. Load it with:
 
 `px status` is the authority for Mission state, and it is the only one. Run `px --help` to see the supported commands.
 
-Execution has exactly one write:
+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 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.
@@ -28,7 +29,7 @@ Execution requirements:
 - 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.
+- 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.
@@ -42,8 +43,9 @@ Execution requirements:
 - 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` is the only supported write.
-- do not hand off to review with uncommitted implementation work, or before the final checkpoint's evidence is recorded
+- 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.
+- 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.