@magnusekdahl/parallix 1.5.126 → 1.5.180

package/NOTICES

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

package/README.md

@@ -105,7 +105,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 that dispatcher is `./scripts/verify-local.sh {{area}}`: earlier phases use the fast general suite, while `px integrate` calls `verify-local.sh integrate`, which resolves repo-side integration gates from `config/integration-pipelines.json` and runs the stricter pre-merge checks there.
+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).
 
 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
@@ -116,6 +116,34 @@ The same action sits behind a confirmation on the TUI board (`Shift+X`) and on
 the web board (the `cancel ✕` button). See the [board guide](docs/tui-board.md)
 for the details.
 
+`px lead` works down the board's "needs your attention" queue — the same list
+the board shows you. For each item it presses the action the board already
+advertises (`px active`, `px review`, …), the same command you would, and when
+that does not clear the item it starts a fresh agent in that mission's worktree
+with what the board reported, asking it to work out why progress stopped and
+restore a state the normal workflow can continue from. An item only counts as
+cleared when the board stops asking about it, never because an agent said so.
+
+Attempts are counted per failure, like every other retry budget here: the same
+attention reason surviving `--budget` agents (2 by default) is escalated with
+what was observed, while a genuinely different failure gets its own attempts. An
+item that clears and comes back is stuck again and is worked afresh. Liveness is
+rechecked before anything is dispatched, so a mission whose agent is running is
+left alone even when the board ranks its failed gate above that; the recovery
+agent starts a new session rather than resuming the stuck one, and its token
+usage is recorded against the mission like any other launch. One mission's
+running agent never stops the rest of the queue from being worked.
+
+One exception, always: an item asking for integration is left for you. The
+supervisor never integrates anything, and there is no path from it to
+`px integrate`; a recovery agent may not weaken a gate, manufacture a review, or
+absorb a defect that belongs to your primary branch either.
+
+Without `--once` it keeps going until the queue drains, polling every `--poll`
+seconds (60 by default), so it holds the terminal the way a watch command does;
+`--once` takes a single pass and exits. `--dry-run` prints the queue without
+acting, and naming missions narrows the run to those.
+
 ## Optional integrations
 
 Both are optional integrations, and each one is wired independently of the other.
@@ -156,6 +184,14 @@ This is a tool for a local-first developer workflow on one machine, driven by an
 - [`AGENTS.md`](AGENTS.md) — hard rules, restricted actions, and verification entrypoints.
 - `docs/adr/` — architecture decision records, including ADR 0044 (distribution model) and ADR 0048 (the fail-closed harness defence inventory cited above).
 
+## Built with Parallix
+
+Parallix is developed using Parallix itself. Changes are broken into bounded missions, implemented in isolated worktrees, checked by repository-owned verification, reviewed in a separate agent pass — preferentially by a different agent family — and integrated only after human inspection. This repository is therefore both the product and a continuously exercised test case for the workflow it provides.
+
+The maintainer owns product direction, architecture, acceptance criteria, release/review decisions, and the final integration decision. Coding agents are implementation and review tools: they may investigate the codebase, draft plans, implement bounded changes, run checks, and review diffs, but they do not autonomously decide what the product should become or merge their own work.
+
+Because the workflow uses task-scoped execution identities, agent-created intermediate commits may carry mission-specific authorship. Responsibility for the architecture and for what ultimately lands in main remains with the maintainer. Architectural decisions are recorded in docs/adr/, while AGENTS.md and the repository verification configuration define the constraints and gates agents work within.
+
 ## Development
 
 ```sh

package/build/asset-manifest.json

@@ -11,7 +11,7 @@
     },
     {
       "key": "prompts/act-on-review-core.md",
-      "sha256": "c7931a2b30343eb509e6d06c8c71d6f0591fbe9bca9029ae8f88781858c8e26c"
+      "sha256": "677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f"
     },
     {
       "key": "prompts/act-on-review.md",
@@ -19,7 +19,7 @@
     },
     {
       "key": "prompts/draft-core.md",
-      "sha256": "f5565ff259a2c830e8853573f7a774fb2ce21e1631d457a025d63ebcf9f4ea6a"
+      "sha256": "4f53057f8bef0343d163c9b8a6539601ecc34462cb20195bf93acaf09e355a35"
     },
     {
       "key": "prompts/draft.md",
@@ -27,7 +27,7 @@
     },
     {
       "key": "prompts/execute-core.md",
-      "sha256": "51b16691ee421a55c5a2da30e62fb8e41c910a5e1e3a16ea45ed6f67aa5e031f"
+      "sha256": "28b39c53c6af6930e6fb21f734c64f24aac033e863e1eb2fc3f10a3023465198"
     },
     {
       "key": "prompts/execute.md",
@@ -35,7 +35,7 @@
     },
     {
       "key": "prompts/review-core.md",
-      "sha256": "7be9123246e77e669d0bbd7c1f6c6f436f58af0c216cb4ee43fd82824b344bbf"
+      "sha256": "3559ac4927931b1869c892626b68ca72d3dcb43eee15f335ac456f404244172d"
     },
     {
       "key": "prompts/review.md",
@@ -75,7 +75,7 @@
     },
     {
       "key": "migrations/0007-usage-statistics-identity.sql",
-      "sha256": "0bba52d7101501a2a2bc95d20abed97f52bae10670bdf15e55c5d09c391315b3"
+      "sha256": "1f251890704f1decbc6732f64fddabe89a98231d4a2b7eae443f0a1f847f5fb4"
     },
     {
       "key": "migrations/0008-review-workflow-state.sql",
@@ -124,6 +124,30 @@
     {
       "key": "migrations/0019-custom-agent-leases.sql",
       "sha256": "07559cd5363f01a309d028673e6dcb9e222a848fae79c57d2fee9001589da19d"
+    },
+    {
+      "key": "migrations/0020-mission-execution-context.sql",
+      "sha256": "39f48ffde5a766f82b4c59725a6bf49750496e6f2efa92b983b2c4756a3cf314"
+    },
+    {
+      "key": "migrations/0021-mission-brief-and-declared-gates.sql",
+      "sha256": "6e8112f6674086f47403172e3a5f3506d1e1ed6defb0e05b2bd00dea66f84858"
+    },
+    {
+      "key": "migrations/0022-mission-reproduction-test.sql",
+      "sha256": "3e8eea659412485b30b9417f0b1894ade89ad83f0bf905964e5908e3d03ca89f"
+    },
+    {
+      "key": "migrations/0023-rename-mission-brief-constraints.sql",
+      "sha256": "a0c669ba6c6883bb498c59eb8a8a1688dc445de56520a22d7c0302b4a2fbf8b0"
+    },
+    {
+      "key": "migrations/0024-mission-success-criteria-and-predicted-nel.sql",
+      "sha256": "811f8d5856a66b2daf88f5a586b6ce03eae7e9acf95aa9c6c733399dd2679057"
+    },
+    {
+      "key": "migrations/0025-mission-dependencies.sql",
+      "sha256": "90b784413abbe8643d02ea84103a15909def367fb80f1eedbac4ba50abc90535"
     }
   ]
 }

package/build/manifest.sha256

@@ -1,4 +1,4 @@
-2e6369b99697e6aaebc09838469bc8a4e546739bc39b05df7818a593a1ff320c  asset-manifest.json
+b0b6ab0500e01db2536461e509d8a2af1f6ce74b22d9d167ebe6f05ce4bff494  asset-manifest.json
 c380d909ddf757f9bbe5136d79652a19396ae69068d144e2b6031ed4b7fb4b78  config/agents.json
 6a4ec47387d1240e32967dc8e4ce54a15d69df2676b7a96ff72baafe996fef7d  config/state-map.json
 30a76fa3839753ddbfe312428dd1b7285ac1b8d0bd678fc79c79018ec6154f69  migrations/0001-initial-schema.sql
@@ -8,7 +8,7 @@ d4080e33cb1a77e504188dbdafa0765ddf3391d99e1d81a76ab3a5ce3b9b40f2  migrations/000
 c92e3addb896b7f93221e70bf69c7eed70e94832921ef0177e28abf283639458  migrations/0005-mission-external-task-ref.sql
 2c6318e475a40ecac6489bbd6b4bafc3fb5af80cfc8760dbff88b073fd694673  migrations/0005-repository-scoped-session-markers.sql
 f06bf2ae50ba8e1ed51b1cb643b5f6dc739f107bb8b7cabc7d511b5f42087433  migrations/0006-session-markers.sql
-0bba52d7101501a2a2bc95d20abed97f52bae10670bdf15e55c5d09c391315b3  migrations/0007-usage-statistics-identity.sql
+1f251890704f1decbc6732f64fddabe89a98231d4a2b7eae443f0a1f847f5fb4  migrations/0007-usage-statistics-identity.sql
 02d772850468eb5b064080ca1fcb35100cfaf21cbeed4fe6a877278ab3b87148  migrations/0008-review-workflow-state.sql
 905cbf1fdfbd357cc705ceb4762170ad6d649424bfc977dd4b241a31fa9e642d  migrations/0009-review-gate-retries.sql
 c8f9327fe161bfdea6a7e56ad3fab2c1bc97a30989da3cb1236c35d9d672d07a  migrations/0010-review-events-and-implementer-response.sql
@@ -21,20 +21,26 @@ a08063b188a91e901d462f73f4f154c98d85068324cef45eb144250e5000051a  migrations/001
 f46823014782c22a9e40b486958770d2b5f7e7180fc9fe6be961a791cca97b50  migrations/0017-retire-mission-import-provenance.sql
 3560376d8e31e0b8fc527509211378a839ba24ef5e5e5fac9ee6dadc06c172c2  migrations/0018-adhoc-mission-counter.sql
 07559cd5363f01a309d028673e6dcb9e222a848fae79c57d2fee9001589da19d  migrations/0019-custom-agent-leases.sql
-0b5d1cd2c31f63f18d543abd23de8efae08ed0692bd1335c9664329e73743d56  package.json
-c7931a2b30343eb509e6d06c8c71d6f0591fbe9bca9029ae8f88781858c8e26c  prompts/act-on-review-core.md
+39f48ffde5a766f82b4c59725a6bf49750496e6f2efa92b983b2c4756a3cf314  migrations/0020-mission-execution-context.sql
+6e8112f6674086f47403172e3a5f3506d1e1ed6defb0e05b2bd00dea66f84858  migrations/0021-mission-brief-and-declared-gates.sql
+3e8eea659412485b30b9417f0b1894ade89ad83f0bf905964e5908e3d03ca89f  migrations/0022-mission-reproduction-test.sql
+a0c669ba6c6883bb498c59eb8a8a1688dc445de56520a22d7c0302b4a2fbf8b0  migrations/0023-rename-mission-brief-constraints.sql
+811f8d5856a66b2daf88f5a586b6ce03eae7e9acf95aa9c6c733399dd2679057  migrations/0024-mission-success-criteria-and-predicted-nel.sql
+90b784413abbe8643d02ea84103a15909def367fb80f1eedbac4ba50abc90535  migrations/0025-mission-dependencies.sql
+b11431f344b14677288d4f37ead38cb32b5667b5053966b82f36b4ca4df7205f  package.json
+677c3ead4d810656bd0993ee8a1db2170b42bd94505d52620c0dcdc4e9f5ca4f  prompts/act-on-review-core.md
 8f06b68b92c8cfc6f3ee0ff7a1e258258c1a1c2220bdfe5b1a3d5fbaab6befeb  prompts/act-on-review.md
-f5565ff259a2c830e8853573f7a774fb2ce21e1631d457a025d63ebcf9f4ea6a  prompts/draft-core.md
+4f53057f8bef0343d163c9b8a6539601ecc34462cb20195bf93acaf09e355a35  prompts/draft-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/draft.md
-51b16691ee421a55c5a2da30e62fb8e41c910a5e1e3a16ea45ed6f67aa5e031f  prompts/execute-core.md
+28b39c53c6af6930e6fb21f734c64f24aac033e863e1eb2fc3f10a3023465198  prompts/execute-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/execute.md
-7be9123246e77e669d0bbd7c1f6c6f436f58af0c216cb4ee43fd82824b344bbf  prompts/review-core.md
+3559ac4927931b1869c892626b68ca72d3dcb43eee15f335ac456f404244172d  prompts/review-core.md
 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  prompts/review.md
-73d251f710121157b0e0cdabe1919551359f3b3658d8bf59ba6111e9272dfb7d  px.mjs
-f3f642e1a3ac8c624ca8894e9eac29a1eed18073a91b1cd871615263dc364631  px.mjs.map
-fbf9b7bd1d7cf095d0533f064b6aa0bac6b1606268765915a61ae3a7c918089e  sbom.json
+820d3e5ff4ca03b04052bbe99c24c9fca62c92470bad611d60468f2e926ae35d  px.mjs
+e8271c96dedd0a622d060f6c1b2d285d8a54b2d55d1992bb2935f4d2b8e24daa  px.mjs.map
+a93ab3414098f9749bea884bb885f2675abbe2cb3f00fd723cc682908520f891  sbom.json
 ce7f4aa6eb9e684434f243a64018d4dfa9962348bfdb5d59881783326cc0ec90  templates/mission-scaffold.md
-99784eaf9444cd3b2531bc71976751ffe78f8305f6affe78b8a258e4c9509dd2  web/assets/index-B8Hv3ORh.js
+b9d3f5bc33c36bbc0e8694e27c8c9feb2275c3191a5ab964e328156915c6754b  web/assets/index-C5mdMEcG.js
 807f92b40d54c1112d284e7c491702aa90e25edfc32ff5af9f4889beec5583a8  web/assets/index-DYY4ROtr.css
-9464b53a502745042971e980f4b89d1e37300d4eca96e8ab6e0591fb561c5562  web/index.html
-3f454a7af0f992df9a8da22f5a75768d4a4c4fca91d8bc5c5e8a5617882fa7bf  web/manifest.json
+7d805cab2863f498c124cbb780dea89592d92cce4a6ace48d08aa34e4d5ef998  web/index.html
+1701eddd03853d39fc5f1ac2382b96b08ed871f53b78ef6ae66fbaf8dadc665f  web/manifest.json

package/build/migrations/0007-usage-statistics-identity.sql

@@ -42,11 +42,14 @@ SET actor_key = lower(
         ELSE COALESCE(NULLIF(trim(implementer_agent), ''), NULLIF(trim(implementer), ''), '')
       END
   END
-);
+)
+WHERE length(actor_key) = 0;
 
 -- Normalize `stage` so the identity key cannot split on '' vs 'default'.
 UPDATE usage_statistics
-SET stage = lower(trim(COALESCE(NULLIF(trim(stage), ''), 'default')));
+SET stage = lower(trim(COALESCE(NULLIF(trim(stage), ''), 'default')))
+WHERE stage <> lower(trim(COALESCE(NULLIF(trim(stage), ''), 'default')))
+   OR stage IS NULL;
 
 -- Collapse duplicates the file authority permitted, keeping the newest row
 -- (highest rowid) for each identity.

package/build/migrations/0020-mission-execution-context.sql

@@ -0,0 +1,19 @@
+-- Typed, bounded launch context. Detailed artifacts remain references (ADR 0053).
+CREATE TABLE mission_execution_contexts (
+  mission_id TEXT PRIMARY KEY REFERENCES missions(id) ON DELETE CASCADE,
+  goal TEXT NOT NULL CHECK (length(goal) BETWEEN 1 AND 4000),
+  why_text TEXT NOT NULL CHECK (length(why_text) BETWEEN 1 AND 4000),
+  scope_text TEXT NOT NULL CHECK (length(scope_text) BETWEEN 1 AND 4000),
+  predicted_nel_bucket TEXT NOT NULL CHECK (predicted_nel_bucket IN ('small', 'medium', 'large')),
+  confidence TEXT NOT NULL CHECK (confidence IN ('low', 'medium', 'high')),
+  selection_note TEXT NOT NULL CHECK (length(selection_note) BETWEEN 1 AND 4000)
+);
+CREATE TABLE mission_execution_context_items (
+  mission_id TEXT NOT NULL REFERENCES mission_execution_contexts(mission_id) ON DELETE CASCADE,
+  kind TEXT NOT NULL CHECK (kind IN ('constraint', 'driver', 'gate', 'dependency')),
+  position INTEGER NOT NULL CHECK (position >= 0),
+  value TEXT NOT NULL CHECK (length(value) BETWEEN 1 AND 512),
+  outcome TEXT CHECK (outcome IS NULL OR length(outcome) BETWEEN 1 AND 512),
+  PRIMARY KEY (mission_id, kind, position),
+  CHECK ((kind = 'dependency') OR outcome IS NULL)
+);

package/build/migrations/0021-mission-brief-and-declared-gates.sql

@@ -0,0 +1,42 @@
+-- TASK-2521.03: replace the execution-context blob with the concepts it held.
+--
+-- 0020 stored constraints, refinement drivers, declared gates and predecessor
+-- references in one `mission_execution_context_items` table discriminated by a
+-- `kind` string. ADR 0053 asks the model to represent these concepts directly,
+-- so each surviving one gets its own table and the rest are dropped:
+--
+--   * brief (goal, why, scope, constraints) -> mission_briefs (+ constraints)
+--   * declared gates                        -> mission_declared_gates
+--   * predicted NEL bucket                  -> dropped; missions.net_engineering_lines
+--                                              plus classifyNelBucket() already model this
+--   * confidence, selection note, drivers   -> dropped; no consumer, no rule
+--   * dependencies                          -> dropped; the task source owns them
+--
+-- No data migration: 0020 shipped with no production writer, and the only row
+-- ever written was a manual test of the command surface.
+DROP TABLE IF EXISTS mission_execution_context_items;
+DROP TABLE IF EXISTS mission_execution_contexts;
+
+CREATE TABLE mission_briefs (
+  mission_id TEXT PRIMARY KEY REFERENCES missions(id) ON DELETE CASCADE,
+  goal TEXT NOT NULL CHECK (length(goal) BETWEEN 1 AND 4000),
+  why_text TEXT NOT NULL CHECK (length(why_text) BETWEEN 1 AND 4000),
+  scope_text TEXT CHECK (scope_text IS NULL OR length(scope_text) BETWEEN 1 AND 4000)
+);
+
+CREATE TABLE mission_brief_constraints (
+  mission_id TEXT NOT NULL REFERENCES mission_briefs(mission_id) ON DELETE CASCADE,
+  position INTEGER NOT NULL CHECK (position >= 0),
+  constraint_text TEXT NOT NULL CHECK (length(constraint_text) BETWEEN 1 AND 512),
+  PRIMARY KEY (mission_id, position)
+);
+
+-- Gates are a Mission attribute, not part of the brief: handoff runs exactly
+-- these commands, and they change during execution while the brief does not.
+CREATE TABLE mission_declared_gates (
+  mission_id TEXT NOT NULL REFERENCES missions(id) ON DELETE CASCADE,
+  position INTEGER NOT NULL CHECK (position >= 0),
+  command TEXT NOT NULL CHECK (length(command) BETWEEN 1 AND 512),
+  PRIMARY KEY (mission_id, position),
+  UNIQUE (mission_id, command)
+);

package/build/migrations/0022-mission-reproduction-test.sql

@@ -0,0 +1,6 @@
+-- TASK-2521.03: the red-to-green reproduction test becomes Mission state.
+--
+-- `redgreen.ts` located the test by reading a `Reproduction-Test:` line out of
+-- MISSION.md or a checkpoint document, so the draft prompt had to tell agents to
+-- write that file. The gate is a live consumer; the file was only its transport.
+ALTER TABLE missions ADD COLUMN reproduction_test TEXT;

package/build/migrations/0023-rename-mission-brief-constraints.sql

@@ -0,0 +1,7 @@
+-- TASK-2521.03: rename the persisted brief boundary from constraints to out-of-scope.
+--
+-- 0021 is immutable and shipped with the original names, so this forward
+-- migration preserves existing rows while bringing those databases to the
+-- schema consumed by MissionBrief.outOfScope.
+ALTER TABLE mission_brief_constraints RENAME TO mission_brief_out_of_scope;
+ALTER TABLE mission_brief_out_of_scope RENAME COLUMN constraint_text TO entry;

package/build/migrations/0024-mission-success-criteria-and-predicted-nel.sql

@@ -0,0 +1,24 @@
+-- TASK-2521.03: record success criteria and the predicted NEL bucket as Mission state.
+--
+-- Corrects two claims in 0021, which is immutable:
+--
+--   * The predicted NEL bucket was dropped there as modelled by
+--     classifyNelBucket(). That classifier buckets the *measured* NEL and cannot
+--     express a prediction; handoff compares the two for the calibration ADR 0047
+--     describes, so the prediction is Mission state again.
+--   * Dependencies were said to be owned by "the task source". There is no task
+--     source: the Mission aggregate is the only task record, and Mission-to-Mission
+--     references are TASK-2521.04's to model.
+--
+-- Success criteria were a section of the retired mission document with no
+-- recorded replacement. Checkpoint Goal Check rows and review verify against them.
+ALTER TABLE missions ADD COLUMN predicted_nel_bucket TEXT
+  CHECK (predicted_nel_bucket IS NULL OR predicted_nel_bucket IN ('Small', 'Medium', 'Large'));
+
+CREATE TABLE mission_success_criteria (
+  mission_id TEXT NOT NULL REFERENCES missions(id) ON DELETE CASCADE,
+  position INTEGER NOT NULL CHECK (position >= 0),
+  criterion TEXT NOT NULL CHECK (length(criterion) BETWEEN 1 AND 512),
+  PRIMARY KEY (mission_id, position),
+  UNIQUE (mission_id, criterion)
+);

package/build/migrations/0025-mission-dependencies.sql

@@ -0,0 +1,21 @@
+-- TASK-2521.04: Mission-to-Mission dependencies.
+--
+-- 0021 dropped the predecessor references it had stored in the execution-context
+-- table, saying "the task source owns them". There is no task source: the
+-- Mission aggregate is the only self-hosted task record, so a dependency is a
+-- reference from one Mission to another and belongs here.
+--
+-- Nothing enforces it. No lifecycle, activation or scheduling rule reads this
+-- table; it records what an operator or agent needs to know about order.
+--
+-- No data migration: the rows 0021 dropped were never written in production.
+CREATE TABLE mission_dependencies (
+  mission_id TEXT NOT NULL REFERENCES missions(id) ON DELETE CASCADE,
+  position INTEGER NOT NULL CHECK (position >= 0),
+  depends_on_mission_id TEXT NOT NULL CHECK (
+    length(depends_on_mission_id) BETWEEN 1 AND 128
+    AND depends_on_mission_id <> mission_id
+  ),
+  PRIMARY KEY (mission_id, position),
+  UNIQUE (mission_id, depends_on_mission_id)
+);

package/build/package.json

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

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

@@ -1,6 +1,6 @@
 # Act-on-review core
 Mode: act-on-review. Branch: {{branch}}.
-Mission: {{missionPath}}
+Mission: {{slug}}
 
 You are the implementer agent family: `{{implementer}}`.
 Attempt: {{attempt}}.
@@ -9,16 +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 requirement applies even when `MISSION.md` declares no gates.
-- Load the locked mission at `{{missionPath}}` and `AGENTS.md` before acting.
-- Read the review outcome and findings from `missions/{{slug}}/review-events/` — the latest `reviewer_outcome-*` file has the verdict and `reviewer_findings-*` has the findings.
-- Get the current round, phase, and disposition from `px status {{slug}}`, which reports them on its `Review:` line. That line is projected from the operator database, which is the authority for review-loop state. Do not read `review-state.json` to learn the round or phase; it is a compatibility artifact, not the source of truth, and it may lag the database.
-- For each finding: fix, push back (with a clear reason), or park (record in a tracked follow-up such as a Backlog task).
+- 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.
+- 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.`
-- Update the checkpoint document if needed, run the relevant gate, and commit before handoff.
-- Write `{{artifactDir}}/{{slug}}-round-resolution.md` with `fixed_items`, `pushed_back_items`, `parked_items`, and `blocked_reason` (when blocked).
-- Write `{{artifactDir}}/{{slug}}-review-disposition.txt` with one of `CHANGES_MADE|PUSHBACK_ALL|PARKED|BLOCKED`. `PUSHBACK_ALL` records your response to every remaining finding and sends the mission back to the active reviewer for the next formal decision; it is not an approval.
-- Do not post to Forgejo directly; the workflow loop consumes the artifacts.
-- In standalone mode (no Forgejo), the review loop reads your artifacts directly — no CLI commands needed.
+- Record corrected checkpoint evidence with `px checkpoint record` if needed, run the relevant gate, and commit before handoff.
+- 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.
 
-Safety: If {{review_outcome}} is not approved AND you cannot read the review outcome, DO NOT post PUSHBACK_ALL. Post BLOCKED instead.
+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.

package/build/prompts/draft-core.md

@@ -1,43 +1,63 @@
 # Draft core
-Mode: draft. Do not implement the mission — produce the mission contract document only.
+Mode: draft. Do not implement the mission — record the mission contract.
 Mission slug: {{slug}}
-Mission path: {{missionPath}}
 Backlog task: {{taskPath}}
 
-The harness has already created the mission branch, worktree, scaffolded `{{missionPath}}`, and ensured the backlog task exists. Your job is to read the user's intent from `{{taskPath}}` and fill `{{missionPath}}` with a real mission contract.
+The harness has already created the mission branch, worktree, mission record, and backlog task. Your job is to turn the user's intent from `{{taskPath}}` into a complete mission record. There is no mission document to write; every fact below is recorded with a command.
 
 Allowed actions:
-- read files (backlog task, MISSION.md scaffold, graphify index if present)
-- write/edit files (MISSION.md, backlog task labels)
+- read files and graphify index if present
 - run graphify queries and updates
 - run `{{verifyCmd}}` to verify the draft
 
 Forbidden actions:
 - implement any feature or fix described in the mission
-- modify source code outside MISSION.md and the backlog task file
+- modify source code
 - run tests beyond the single `{{verifyCmd}}` gate
 - start a review, execute, or integrate phase
 
+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`.
+
+The contract, and what the harness requires before this draft can finish:
+
+| Part | Command | Required |
+|---|---|---|
+| Goal and why | `px goal set --goal <text> --why <text>` | required |
+| Scope | `px scope set --scope <text>` | required |
+| Out of scope | `--out-of-scope <text>` on `px scope set`, repeatable | optional; record it whenever the mission deliberately leaves something alone, because review checks the diff against it |
+| Success criteria | `px criterion add --text <criterion>`, one call each | required, at least one |
+| Checkpoint plan | `px checkpoint plan --name <CP-N> --text <what it delivers>`, one call each in execution order (`CP-1`, `CP-2`, ...), at most 512 characters each | required, at least one |
+| Verification gates | `px gate add --command <command>`, one call each. Handoff runs every gate with `bash -c` and blocks on a non-zero exit, so a gate is one exact runnable repository command and nothing else (for example `./scripts/verify-local.sh all`): no prose, no `#` comment, no expected outcome. `px gate add` refuses such a gate, and handoff also refuses a gate whose script does not exist in the finished tree; an expected outcome belongs in a success criterion | required, at least one |
+| Predicted NEL bucket | `px nel set --predicted <Small\|Medium\|Large>` | required |
+| 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.
+
+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.
+
+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.
+
+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.
+
 Drafting requirements:
-- fill every scaffolded section in `{{missionPath}}` with concrete, non-generic content (no placeholders, no "TBD")
-- include a Goal, Why now, Scope, Out of scope, Success criteria, Risks/assumptions, Checkpoints, Gates, Restricted areas, and Stop rules
-- success criteria must be specific enough to derive a goal-check table during execution
+- 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
 - {{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
-- Refinement Signals section must use net engineering lines (NEL) bucket format (`Predicted NEL bucket: Small (0–80) / Medium (81–235) / Large (235+)`) and must NOT use the old agent-percentage-usage format
-- Every generated `MISSION.md` MUST keep the scaffolded `### Checkpoint Documentation Requirements` block under `## Checkpoints` and fill it with concrete instructions for the implementer.
-- That block must tell the agent to use the exact heading `## Goal Check` and the 3-column table `| Criterion | Evidence | Status |`.
-- That block must lead with durable evidence forms Parallix verifies today: exact test names, ADR references, test file paths, and recognized repo commands/paths such as backticked `npm ...`, `node ...`, `git ...`, `px ...`, or `./...`. It may mention file:line references parenthetically as accepted but discouraged because line numbers rot.
-- That block must make the weak-agent failure mode explicit: raw `stat`/`ls` output or generic prose alone is not enough; pair shell output with one of the accepted references above.
-- Every `## Gates` checklist item must contain only the exact runnable repository command (for example, `- [ ] ./scripts/verify-local.sh all`). Optional Markdown backticks around the whole command are allowed.
-- Never append outcome or explanatory prose to a gate command, including phrases such as "passes on the final tree". Put outcome expectations in Success Criteria or checkpoint documentation instead.
+- predict the size of the change as a net engineering lines (NEL) bucket — Small (0–80), Medium (81–235) or Large (235+)
 
 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 checkpoint** 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 in `{{missionPath}}` on its own line in the exact form `Reproduction-Test: <path>` (e.g. `Reproduction-Test: test/task-1354-repro.test.ts`). The handoff red→green gate reads this line to locate the test, so it must be present and accurate.
-- do not author the fix during draft — the reproduction test and its `Reproduction-Test:` declaration are the only bug-specific drafting outputs.
+- 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).
+- 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.
 

package/build/prompts/execute-core.md

@@ -1,36 +1,48 @@
 # Execute core
 Mode: execute after lock.
-Mission: {{missionPath}}
-Mission dir: {{missionDir}}
 Slug: {{slug}}
+Mission dir: {{missionDir}}
 Backlog task: {{taskPath}}
 
+Mission context is application-owned. Load it with:
+
+- `px status {{slug}}` — lane, the recorded brief (goal, why, scope, out-of-scope), the success criteria, the checkpoint plan with which checkpoints already have recorded evidence, declared gates, the latest recorded checkpoint with its Goal Check rows and next action, review round and disposition, and the write version.
+
+`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:
+
+- `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.
+
 Harness preflight already confirmed:
 - branch/worktree shape
-- mission doc presence
-- Backlog task presence
+- the mission brief is recorded and readable
 
 Execution requirements:
-- execute checkpoint-by-checkpoint per the contract in `{{missionPath}}`
-- after each completed checkpoint, write `CP-N.md` in `{{missionDir}}` containing: a summary of work done, a Goal Check table with durable evidence such as runnable project commands, test names, decision-record references, or test paths, and a non-generic `Next action:` line
-- Completing a checkpoint is **non-terminal**: after committing its `CP-N.md`, immediately continue to the next incomplete checkpoint declared in the mission. 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 declared checkpoint is committed 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.
+- 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.
+- 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.
 - 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 document MUST contain a Goal Check table citing real, durable evidence such as runnable project commands, test names, decision-record references, or test paths
-- **Heading requirement:** Use the exact section header `## Goal Check`.
-- **Goal Check table format:** Use a 3-column pipe-delimited markdown table: `| Criterion | Evidence | Status |` followed by a separator row `|---|---|---|`, then one evidence row per criterion.
-- **Accepted evidence forms** (each row's Evidence column must cite at least one verifiable reference from this list):
+- 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 cell must also cite at least one accepted reference from the list above.
-- verify all mission-declared Gates pass before handoff
-- 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. Do not compact for a failed gate: retain its failure diagnostic while repairing it.
+- **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.
+- 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`, or `px integrate`; Parallix performs lifecycle transitions itself
-- do not hand off to review if `{{missionPath}}` or checkpoint documents are uncommitted
+- 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
 
 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.