@kontextmind/kxm 0.7.53 → 0.7.55

package/.claude-plugin/marketplace.json

@@ -11,7 +11,7 @@
       "name": "kxm",
       "source": "./plugins/kxm",
       "description": "Durable workflows, peer agents, and kxm tui",
-      "version": "0.7.53",
+      "version": "0.7.55",
       "category": "development",
       "tags": ["kxm", "multi-agent", "workflows", "mcp"]
     }

package/CHANGELOG.md

@@ -35,6 +35,47 @@ All notable user-facing changes are documented here. The project follows [Semant
 
 ### Changed
 
+- **A Pi producer reply can no longer mint its own success.** `determineOutcome` scanned the
+  reply for any declared outcome *word* and, failing that, returned `passed`. So
+  `"the gate did not pass, so I would not call this passed"` settled the step as passed — the
+  word was all it took — and an empty or prose-only reply was passed by default. Only a declared
+  result counts now: a reply that is one JSON object, or prose carrying an explicit
+  `{"outcome": "…"}` block, and only when the step declares that outcome. Anything else is
+  `failed`; an undeclared value still lands in `outcome_unknown` and terminates as `failed`, so a
+  step without a `failed` transition cannot pass on a bad reply either. This matches the rule the
+  one-shot producer already enforced, and `docs/contracts/lifecycles.md` now states it where
+  `result_recorded` is defined. Three usage-capture fixtures that had been replying in prose now
+  declare their result, which is what they were always supposed to do; the new test in
+  `test/core/pi-producer.test.ts` covers prose, empty, out-of-vocabulary, and both accepted
+  structured shapes. Review of that first cut found two more ways to mint success, both now
+  closed: a result block was matched **anywhere** in the reply, so
+  `Example: {"outcome": "passed"}. Actual result: {"outcome": "failed"}` returned `passed`;
+  a declaration is now a standalone JSON object — the whole reply, or one object on its own
+  line, with the **last** such object winning so an illustration cannot outrank the answer, and
+  the whole reply settling `failed` when anything after that line still looks like an outcome
+  key, because at that point the producer cannot tell which declaration was meant.
+  And cancellation fell through to `allowedOutcomes[0]` when a step declared neither
+  `cancelled` nor `failed`, so aborting a `passed`-only step reported `passed`; a cancel now
+  reports `cancelled` unconditionally and the engine terminates it `failed` when the step
+  does not declare that outcome.
+
+- **`kxm migrate` is gone, and so is the state that only it could unlock.** Deleting the
+  migration lanes left a converter with nothing to convert into: `plugins/kxm/src/migrate.ts`
+  (1,848 lines), its 1,598-line suite, the `migrate plan|apply|verify` commands, the
+  `kxm.migration-plan.v1` / `-decision.v1` / `-receipt.v1` schemas and their registry
+  validators, the receipt reader / self-hash / byte-record helpers, and the
+  `.kxm/migration-receipt.yaml` path are all removed. A tree that still holds legacy
+  `.kxm/config` JSON now fails closed at load with `legacy_state_unsupported`, one issue per
+  legacy file, and no receipt, plan, or option unlocks it — previously a verified receipt made
+  a mixed tree loadable, which is exactly the dual-read surface this decision retires.
+  `kxm init` classifies such a tree as `mode: "legacy"` (was `"migrate"`), reports
+  `legacyInputs`, and writes nothing. `docs/contracts/migration.md` is rewritten as a
+  supported/refused matrix instead of a conversion spec, and the packed-install suite now
+  builds its trust and run-lifecycle fixture by initialising a project directly, so that
+  coverage survived rather than being deleted with the command. A new test asserts
+  `kxm migrate` is rejected as an unknown command: a retired verb must fail loudly, not
+  resolve to nothing.
+
 - **No schema migration lanes, no legacy stamp tolerance (single-operator tool).** Stepwise
   schema migration lanes are removed from the hub store and the per-project event store, and
   the external-effects store no longer runs an in-place `ALTER TABLE ... ADD COLUMN` whose
@@ -42,7 +83,7 @@ All notable user-facing changes are documented here. The project follows [Semant
   ever fire on an older store; the store has no production caller yet, so this closes the
   lane rather than fixing a live upgrade).
   A database stamped behind this build now fails closed with `runtime_schema_outdated` and
-  a message that says to delete the state file or re-run `kxm init` — and the refusal never
+  a message naming the process that recreates the store (`kxm hub start` for hub state, the Runtime for registry/event stores; `kxm init` is project-only) — and the refusal never
   advances `user_version`, so the store stays identifiably old (WAL sidecars may still be
   checkpointed by opening the file, so the whole state set remains the backup unit — see
   [`docs/operations.md`](docs/operations.md)). Relabelling a store it refused to open would

package/docs/agent-skills.md

@@ -10,7 +10,7 @@ authority, admit new writers, or replace trusted `.kxm/roster.yaml` policy.
 | Feature Area | Skill | Commands Covered | Purpose |
 |---|---|---|---|
 | Core Routing | `kxm` | — | Select the right suite skill; state universal safety rules and portable CLI convention |
-| Project Setup | `kxm-project-setup` | `init`, `migrate`, `trust`, `config`, `completion` | Initialize, migrate, review permission changes, configure, and install shell completion |
+| Project Setup | `kxm-project-setup` | `init`, `trust`, `config`, `completion` | Initialize, review permission changes, configure, and install shell completion |
 | Harness & Auth | `kxm-harness-auth` | `harness`, `auth`, `update`, `runtime`, `agent` | Inspect authenticated harness capability and operate supported runtimes/workers |
 | Hub Operations | `kxm-hub-ops` | `hub`, `backup`, `restore` | Run and protect the local hub and its durable SQLite state |
 | Session Management | `kxm-session` | `session`, `dash`, `studio` | Resume/inspect operator work and use UI capabilities each harness supports |

package/docs/configuration.md

@@ -273,9 +273,6 @@ The current hub command groups are `agent`, `session`, `workflow`, `gate`, `hub`
 | Command | Purpose |
 |---|---|
 | `kxm init` | Atomically create a provenance-tracked minimal KXM project, validate it without rewriting, resume a pinned interrupted create/repair, apply conflict-free non-authority template updates, or join an existing clone with repeatable `--repository <id=absolute-path>` member bindings stored outside Git. `--dry-run` performs no writes. Provenance-free/ambiguous repair and permission-expanding changes remain planning-only. These configuration slices do **not** activate a KXM Runtime. `kxm init` is project-only; bind a running hub with `kxm hub bind <url>` |
-| `kxm migrate plan` | Convert legacy `.kxm/config` JSON (agents, gates, workflow definitions) into a deterministic, secret-free `kxm.migration-plan.v1` report: source/target hashes, decision-requiring ambiguities (terminal status, transition budgets, evidence-policy strengthening, secret drops, narrowed ceilings, foreign producers), hashed unmapped fields, and explicit identity renames. Performs no writes, locks, or staging |
-| `kxm migrate apply [--decisions <file>]` | Install a reviewed migration: re-checks the decision binding against current sources, validates the complete target bundle, refuses to overwrite existing paths, installs durably, and writes a self-hashed `kxm.migration-receipt.v1` that keeps legacy inputs read-only. Re-applying is an idempotent no-op. `--dry-run` performs no writes |
-| `kxm migrate verify` | Re-check the migration receipt against current legacy sources and the target bundle (self-hash, source hashes, configuration revision, resource bytes). Performs no writes |
 | `kxm trust diff [--base <rev>]` | Print the structured `kxm.permission-diff.v1` report between a base Git revision (default `HEAD`, materialized into a temporary shadow with a sanitized environment) and the working tree: every authority-bearing field change classified as expansion, narrowing, or neutral with per-field hashes. Performs no project writes |
 | `kxm trust check [--base <rev>]` | Exit non-zero when any expansion exists, so an authority-bearing change cannot merge without a reviewed Git change. Formatting/description-only changes never require review |
 | `kxm run <workflow> [prompt]` | Auto-start the KXM Runtime supervisor if needed, then create an immutable run offline: pins `homeRuntimeId` plus config/executor/tool policy revisions and stores only the prompt hash. `--dry-run` prints the plan without creating anything |

package/docs/contracts/lifecycles.md

@@ -105,6 +105,22 @@ created → accepted → dispatched → executing → result_recorded → termin
 | `blocked_uncertain` | A dependent effect cannot be reconciled safely |
 | `terminal` | The logical assignment outcome is final and immutable: passed, failed, or cancelled |
 
+A producer reply becomes a terminal outcome **only** through a declared result: the reply is
+one JSON object, or it carries a `{"outcome": "…"}` object **on a line of its own**. With more
+than one such line the last one is the answer; if anything after it still looks like an outcome
+key — an inline `Actual result: {"outcome": "failed"}`, a pretty-printed object, a second
+mention — the reply is **ambiguous and settles `failed`**, because guessing which declaration
+was meant is the behaviour this rule removes. Ordinary trailing prose (a sign-off, a token
+count) does not disturb a declared result.
+
+Naming an outcome *word* anywhere in a reply is not a result — `"the gate did not pass, so I
+would not call this passed"` must not advance a step — and an empty or unstructured reply is
+never treated as success. A declared outcome outside the step's declared set is not accepted
+either:
+the assignment is recorded `outcome_unknown` and terminates as `failed`, which is also what
+happens when a step declares no `failed` transition. Producers do not guess on the model's
+behalf, and no fallback path mints `passed`.
+
 `assignmentId` remains stable. A retry moves the nonterminal assignment through
 `retry_pending` to `accepted`, creates a new `attemptId`, and never rewrites or
 exits the previous attempt's terminal state. The effective

package/docs/contracts/migration.md

@@ -1,258 +1,50 @@
-# Migration and compatibility matrix
-
-KXM is introduced beside the current v0.5 transport/workflow surfaces.
-Presence of KXM documents does not activate new behavior.
-
-## Surface matrix
-
-| Current surface | KXM target | Migration rule |
-|---|---|---|
-| `.kxm/config/agents.json` aggregate roster | `.kxm/agents/<id>.yaml` individual definitions | Split records, infer ID from filename, preserve unrecognized fields in a migration report rather than silently dropping them |
-| `gates.json` descriptive records | Workflow step/gate references plus registered deterministic adapters | Map only implemented gates; report names with no runner |
-| `KXM_WEBHOOK_WORKFLOWS` inline JSON | `.kxm/workflows/<id>.yaml` | Materialize secret-free behavior; convert secret fields to references |
-| `KXM_WEBHOOK_WORKFLOWS_FILE` JSON array | Individual workflow YAML files | Split definitions and validate typed transitions |
-| `.kxm/config/workflows/*.json` including `/fix` | `.kxm/workflows/<id>.yaml` | Preserve typed transitions, immutable reproduction oracle, approved-plan hash, plan-hash requirements, producer policies, and attempt/transition budgets |
-| Hub-selected project from environment | Git project identity plus Runtime-local binding | Detect and ask on ambiguity; do not derive durable identity from directory basename |
-| Long-lived manually started Pi workers | Runtime-managed run-scoped sessions | Existing worker mode remains available during compatibility release |
-| Shared/off workflow Pi history | `{run, agent, instance, scopeEpoch}` sessions | Never import shared conversation history into a narrower run scope |
-| Hub-owned workflow state | Home Runtime event log with hub projection | Import completed history as legacy records; active-run cutover requires quiescence |
-| SQLite schema v3 `kxm.db` | Runtime registry, per-project event stores, hub registry/project stores | **No in-place schema migration.** A store stamped behind the current build fails closed with `runtime_schema_outdated` and the refusal never advances `user_version` (opening the file may still checkpoint WAL sidecars, so the whole state set is the backup unit); re-init instead. Stepwise lanes were removed 2026-09-20 under the single-operator decision from the hub store, the per-project event store, and the external-effects `ALTER TABLE` add-column; the Runtime registry never carried a stepwise lane (see [implementation-plan.md](../../plans/implementation-plan.md) → Decided) |
-| Full peer message bodies in hub DB | Summary-first sync events | Existing bodies remain protected legacy data and are not re-emitted automatically |
-| Project tokens/manual environment auth | Runtime enrollment and scoped credentials | Preserve current mode until enrollment is confirmed; never copy tokens into Git |
-| `.kxm/config/env.example` | Built-in defaults plus optional scoped env YAML | Import only explicit portable differences; secrets become references |
-| Retired product-prefixed init (empty directories) | Unified `kxm init` create/join/migrate/repair | Removed; `kxm init` is the only entry and the old init command fails closed |
-| `kxm session start` manifest only | `kxm run` executable run | Do not reinterpret old session manifests as completed or active runs |
-| Existing context items and journal | Pinned memory revisions and candidates | Preserve provenance/authority floors; no automatic executable promotion |
-
-## Compatibility releases and activation
-
-> **Scope note (2026-09-20).** This matrix documents the Mesh/v0.5 → KXM cutover. KXM has
-> one operator and no external installs, so **schema migration and old-state tolerance are
-> out of scope** and the lanes that existed are gone: stores refuse an older stamp rather
-> than upgrading, the external-effects store no longer adds a column in place, and the
-> coordinator fingerprint no longer recomputes to forgive pre-canonicalisation rows. What
-> remains here describes the **project/content** cutover, which the follow-up cut removes
-> along with `kxm migrate`. Nothing here promises that the runtime will read an old
-> database.
-
-Local Runtime support may ship publicly before hub KXM, but it remains beside
-existing hub contracts and stores. Old command names are not preserved. A project
-activates `kxm.*.v1` only by an explicit successful `kxm init`/migration receipt;
-file presence alone never activates it. Legacy hub runs continue on the legacy
-engine.
-
-> **Superseded (2026-09-20).** The single-operator decision removes legacy readers
-> **without** a compatibility release, so this transition-release list is no longer a plan of
-> record. It stays here to name what was given up: no dual-read window, no `mesh_*` shim, and
-> no period where legacy JSON stays loadable while KXM writes YAML. Anything still holding
-> legacy state is refused rather than served from both shapes.
-
-When Phase 8 activates hub KXM, at least one hub transition release provides:
-
-- current `mesh_*` peer tools;
-- current hub APIs behind a compatibility adapter;
-- legacy JSON configuration read support while KXM writes only YAML;
-- current completed workflow history read/export support;
-- Runtime-managed KXM runs in new event stores with new identities;
-- CLI labels for legacy versus KXM state;
-- no implicit movement of active runs between engines.
-
-Before activation, a repository MUST NOT use legacy and KXM definitions with
-the same normalized identity. Validation reports the conflict and requires an
-explicit migration choice. After a migration receipt activates the KXM copy,
-the matching legacy definition is read-only compatibility input and cannot be
-selected for a new KXM run.
-
-## Migration commands
-
-```text
-kxm migrate plan
-kxm migrate apply [--decisions <file>] [--project-id <id>] [--name <name>]
-kxm migrate verify
-```
-
-`kxm init` invokes the planning flow when it detects legacy state.
-
-> **Superseded (2026-09-20).** The single-operator decision removed every schema
-> migration lane, so "database/WAL migration … remain later-phase work" below is
-> no longer the plan: there will be none. The `kxm migrate` commands described on
-> this page are deleted in the follow-up cut, and a tree still holding legacy JSON
-> fails closed at load instead of being converted.
-
-**Implementation status (Phase 1 slice):** the commands above are implemented
-for **configuration migration only** — legacy `agents.json`, `gates.json`, and
-workflow-definition JSON under `.kxm/config/`. Database/WAL migration,
-active-run cutover, session migration, and rollback orchestration remain
-later-phase work and are not performed by these commands.
-
-### Plan
-
-Produces a secret-free `kxm.migration-plan.v1` report containing:
-
-- detected source files with sha256 and byte counts plus a combined
-  `sourceDigest`;
-- target resource paths with their rendered content hashes;
-- deterministic ambiguities, each with a stable decision key and the allowed
-  values: terminal status for legacy `$terminal` edges, per-edge budgets for
-  unbounded back-edges, missing global transition budgets, evidence-policy
-  strengthening (`replied` → `passed`), foreign producer identities, secret
-  field drops, narrowed permission ceilings, and identity normalization;
-- unrecognized or unmappable fields preserved as hashed `unmapped` entries
-  (sensitive values are hashed, never copied);
-- old-to-new identity renames;
-- the resulting permission changes tied to their decision keys.
-
-It changes nothing: no writes, no locks, no staging, no local state.
-
-### Decisions
-
-`kxm migrate apply` requires every ambiguity to be resolved. Decisions are
-supplied either as a reviewed `kxm.migration-decision.v1` YAML file
-(`--decisions <file>`) binding the exact `projectId`, `projectName`, and
-`sourceDigest` of the plan, or programmatically. Unknown decision keys and
-values outside the plan's allowed set fail closed before any write.
-
-### Apply
-
-1. Acquire the project mutation lock.
-2. Recompute the plan and re-check the decision binding (project, source
-   digest, key set, allowed values).
-3. Validate every converted resource against its exact schema and the whole
-   bundle against semantic rules.
-4. Refuse to overwrite any existing target path.
-5. Install resources with durable writes (fsync + rename).
-6. Load and validate the complete installed bundle.
-7. Write a hash-linked `kxm.migration-receipt.v1` binding source hashes,
-   decision digest, target configuration revision, and installed resource
-   hashes; the receipt is self-hashed.
-8. Re-load the mixed tree: legacy inputs remain intact but receipt-pinned
-   read-only; `loadKxmProject` accepts coexistence only through the
-   verified receipt.
-
-Re-applying with the receipt present is an idempotent no-op
-(`already-migrated`). Editing a legacy source after the receipt makes both
-`loadKxmProject` and `kxm migrate verify` fail closed.
-
-### Verify
-
-`kxm migrate verify` reopens the target, re-checks the receipt self-hash,
-re-hashes legacy sources, and compares the target configuration revision and
-installed resource bytes against the receipt. It performs no writes.
-
-## Database migration
-
-> **Superseded in part (2026-09-20).** What the code guarantees today is narrower than the
-> checklist below and belongs to two different moments:
->
-> - **Opening a store** verifies `user_version`, refuses a newer-than-known version, and
->   enables WAL. That is implemented.
-> - **Backing a store up** is where checkpointing, `-wal` handling, integrity verification,
->   and hash recording happen — see the whole-state-set recipe in
->   [`docs/operations.md`](../operations.md). Those are **not** properties of an ordinary open.
->
-> The legacy-record import paragraphs describe a cutover that will not happen: this build
-> migrates no database, and an older stamp is refused outright.
-
-Before any database operation:
-
-- verify SQLite `user_version`;
-- refuse a newer unknown version;
-- checkpoint WAL or copy using the SQLite backup API;
-- include `-wal` state correctly rather than copying only the main file;
-- verify backup integrity;
-- record source and target hashes.
-
-Current agents, messages, workflow runs, journal entries, and context items are
-imported as typed **legacy records**. They are not fabricated into fine-grained
-KXM run events whose original ordering was never observed.
-
-Completed legacy runs remain queryable. A legacy active run must either finish
-on the old engine or be explicitly cancelled/exported; it is not resumed as a
-KXM run.
-
-## Configuration migration
-
-The implemented converter:
-
-- reads legacy JSON with byte/depth/node bounds and token-level duplicate-key
-  rejection; linked files and linked `workflows/` directories are never
-  traversed for authoritative bytes;
-- normalizes case-insensitive identities, records explicit old-to-new renames,
-  and rejects case-fold collisions and destination-invalid names;
-- splits `agents.json` into `.kxm/agents/<id>.yaml` resources and emits one
-  `.kxm/models/<id>-primary.yaml` profile per agent whose legacy record pinned
-  a provider/model pair with a thinking level;
-- maps roster-only concepts (`ownership`, `host`, top-level `project`) into
-  hashed `unmapped` report entries rather than dropping them silently;
-- maps workflow stages to agent steps, preserves `reproOracle`, `planHash`,
-  `requirePlanHash`, typed transitions, immutable oracles, and global
-  transition budgets, and widens evidence-carrying steps into an explicit
-  assignment pool containing their producers;
-- converts legacy peer-reply evidence policies (`acceptedStatuses:
-  ["replied"]`) into KXM producer policies requiring `passed` only through
-  an explicit operator decision;
-- requires decisions for: every legacy `$terminal` edge's terminal status
-  (legacy completed the run even on failure outcomes), every unbounded
-  back-edge's per-edge budget, missing global budgets, foreign producer
-  identities, secret-field drops, unimplemented gates, and each narrowed
-  permission ceiling;
-- never copies secret values or environment indirections; webhook secret
-  fields are hashed into the report and dropped by explicit decision;
-- records template provenance only for files whose exact generated baseline is
-  known; migrated files carry no template provenance and are never
-  retroactively adopted;
-- validates the entire target project (exact schemas plus semantic rules)
-  before installation and shows the Git diff through normal review.
-
-Unknown data is preserved in the migration report, not placed into a generic
-runtime extension map.
-
-Legacy typed workflows have a global transition budget but may lack KXM
-per-back-edge caps. The migrator MUST NOT invent those caps silently. `migrate
-plan` lists every affected edge and a proposed bounded value; `migrate apply`
-requires the values in an operator-approved migration decision. The committed
-KXM `/fix` fixture is one reviewed resolution, not a generic automatic rule.
-
-Stage IDs, outcome keys, evidence keys, oracle references, plan-hash references,
-and eligible producer identities are preserved by default. Any unavoidable
-normalization appears as an explicit old-to-new mapping and rewrites all bound
-references atomically.
-
-## Session migration
-
-Old shared Pi histories may contain content from broader scopes. They remain
-archived under the old worker binding and are never selected for a KXM run.
-The first KXM physical session starts clean. Durable facts must come from Git,
-workflow evidence, artifacts, or promoted context rather than conversation
-history.
-
-## Rollback
-
-Rollback is supported until the operator accepts the migration receipt and
-starts a permission-expanding KXM-only run.
-
-Rollback:
-
-1. stop KXM writers;
-2. preserve KXM stores as diagnostic artifacts;
-3. restore the recorded legacy configuration selection and database path;
-4. restart only compatible legacy processes;
-5. verify legacy health and record rollback evidence.
-
-Events created only by KXM are not reverse-translated into fabricated legacy
-workflow history.
-
-## Removal gate
-
-> **Superseded (2026-09-20).** The operator decided removal happens **without** a
-> compatibility release, so the list below no longer gates removal — it is kept only
-> to record why the gate existed. Legacy readers are being deleted now, and old names
-> fail closed by brake rather than alias.
-
-Legacy readers and command aliases are removed only after:
-
-- at least one compatibility release;
-- migration telemetry shows no material unmapped cases;
-- package/install/Windows tests cover KXM;
-- operator documentation and rollback paths are proven;
-- removal is announced in the changelog.
+# Migration and compatibility
+
+**KXM carries no migration path.** The product ships for a single operator, and
+the operator decision (recorded in
+[`plans/implementation-plan.md`](../../plans/implementation-plan.md)) is that
+older state is replaced, not converted. Old names are not accepted; old state
+is refused loudly. This page documents what that means at each boundary so no
+one re-adds a compatibility lane by inference.
+
+## What happens to older input
+
+| Boundary | Behaviour |
+|---|---|
+| Project tree with legacy `.kxm/config` JSON | `loadKxmProject` fails closed with `legacy_state_unsupported`, one issue per legacy file. No receipt, plan, flag, or environment variable unlocks it. |
+| `kxm init` on such a tree | Reports `mode: "legacy"`, lists `legacyInputs`, performs **no writes**. Recovery is a fresh project directory plus the YAML definitions worth keeping. |
+| `kxm migrate` | Unknown command. It existed as `plan` / `apply` / `verify` for pre-KXM JSON and was deleted with this decision. |
+| SQLite store stamped with an older `user_version` | Refused with `runtime_schema_outdated`; the refusal never advances `user_version`, so the store stays identifiably old. Delete the state file and let the process that owns it recreate the store (`kxm hub start` for hub state, the Runtime for registry/event stores). `kxm init` is **project-only** and rebuilds no database. Forward-only stamping is prohibited — it turns a clean failure into a later query against a column that does not exist. |
+| Retired product and command names | Rejected by fail-closed brakes (lint + readiness tests), not aliased. |
+| Shared/off-scope Pi history | Never imported into a narrower run scope. A new physical session starts clean; durable facts come from Git, workflow evidence, artifacts, or promoted context. |
+| Historical run records | Never fabricated. Events whose real ordering was not observed stay absent rather than reconstructed into a finer-grained model. |
+
+## What is *not* relaxed by this
+
+Deleting conversion code does not soften the guarantees around the state that
+does exist:
+
+- **Fresh installs must be complete.** Every table, index, and default that a
+  store needs is declared in its current schema definition, so an empty store is
+  valid without any upgrade step.
+- **Backups stay whole.** The hub state set is copied as documented in
+  [`docs/operations.md`](../operations.md); a single `kxm.db` copy is not a
+  backup.
+- **Out-of-range versions refuse without touching the file.** The stamp is read
+  before anything that can modify the store, so a database this build refuses —
+  older or newer — comes back byte-identical: neither its schema nor its
+  `user_version` changes, and it is not converted to WAL as a side effect of being
+  rejected. A store ahead of this build is refused without downgrade.
+- **Schema changes are additive-and-replace, not in-place.** Land the new
+  definition, delete the local state, and let the process that owns each store
+  recreate it — `kxm hub start` for hub state, the Runtime for registry and
+  event stores. `kxm init` is project-only and rebuilds no database.
+  Nothing in the runtime may rewrite an existing store's shape.
+
+## If this ever changes
+
+Re-introducing migration needs a written decision first, because the cost is
+not the converter — it is the permanent dual-read surface (legacy names staying
+loadable, receipts that unlock state, and a test matrix that must keep proving
+both sides). Any such proposal has to name the state it protects and who owns
+it; "someone might have an old directory" is not a reason on its own.

package/docs/contracts/validation.md

@@ -107,39 +107,21 @@ hard-link support fails safely. Create keeps its same-volume directory rename.
 A newer process must finish the pinned transaction before planning another
 template revision.
 
-#### Legacy configuration migration
-
-`kxm migrate plan|apply|verify` converts legacy `.kxm/config` JSON into
-validated KXM resources with an exact receipt:
-
-- Legacy files are read with byte/depth/node bounds and token-level
-  duplicate-key rejection. Symbolic links and linked `workflows/` directories
-  are never traversed for authoritative bytes.
-- The deterministic `kxm.migration-plan.v1` binds every source file by
-  sha256/bytes plus a combined `sourceDigest`, lists target resources with
-  rendered content hashes, and enumerates every ambiguity as a stable decision
-  key with its allowed values: terminal status for each legacy `$terminal`
-  edge (legacy semantics completed the run even on failure outcomes), per-edge
-  budgets for unbounded back-edges, missing global transition budgets,
-  evidence-policy strengthening from `replied` to `passed`, foreign producer
-  identities, secret-field drops, unimplemented gates, and each narrowed
-  permission ceiling. Unrecognized or unmappable fields are preserved as
-  hashed `unmapped` entries; sensitive values are hashed, never copied.
-  Identity normalization that changes a name is an explicit `renames` entry
-  applied to all bound references; case-fold collisions fail closed.
-- Apply requires a reviewed `kxm.migration-decision.v1` (or programmatic
-  resolutions) binding the exact plan: project ID, project name, and source
-  digest. Unknown keys and values outside the allowed set fail closed before
-  any write. The complete target bundle must pass exact-schema and semantic
-  validation before installation; existing target paths are never overwritten.
-- Installation uses durable writes under the project mutation lock and finishes
-  with a self-hashed `kxm.migration-receipt.v1` binding source hashes, decision
-  digest, target configuration revision, and installed resource hashes. The
-  receipt keeps the legacy inputs read-only: `loadKxmProject` accepts mixed
-  trees only through a verified receipt, and any later legacy-source edit makes
-  loading and `migrate verify` fail closed. Re-apply is an idempotent no-op.
-- `plan`, `verify`, and every `--dry-run` path perform no writes, locks,
-  staging, backups, or Runtime-local state creation.
+#### Legacy configuration is refused, not migrated
+
+This build carries **no** legacy conversion path. A tree that still holds
+`.kxm/config` JSON fails closed:
+
+- `loadKxmProject` rejects it with `legacy_state_unsupported` per legacy file, and
+  no receipt, plan, or option unlocks it any more.
+- `kxm init` classifies the tree as `mode: "legacy"`, reports the discovered
+  `legacyInputs`, and performs **no writes** — it never converts on the side.
+- `kxm migrate` is not a command; invoking it is an unknown-command error.
+
+The operator decision behind this is recorded in
+[`plans/implementation-plan.md`](../../plans/implementation-plan.md): single
+operator, no backwards compatibility. Recover by initialising a fresh project
+directory and copying the YAML definitions worth keeping.
 
 `--dry-run` may parse and classify a transaction but MUST NOT create the writer
 mutex, state directories, staging, backups, temporary files, or cleanup. Live

package/docs/test-matrix.md

@@ -13,6 +13,7 @@ npm run verify
 
 | Feature | Automated evidence |
 |---|---|
+| Structured-result settlement only: outcome words in prose, empty replies, and outcomes outside the step's declared set all fail closed; a declared JSON object and a JSON result block inside prose both settle, and the engine records `outcome_unknown` and terminates `failed` | `test/core/pi-producer.test.ts`, `test/core/engine.test.ts` |
 | Health, readiness, metrics, request IDs, security headers | `test/core/hub-api.test.ts` |
 | Shared and per-project authentication, project isolation | `test/core/hub-api.test.ts` |
 | Registration, discovery, presence, stale detection, identity resumption | `test/core/hub-api.test.ts`, `test/core/hub.test.ts` |
@@ -56,7 +57,7 @@ npm run verify
 | Package and marketplace version consistency | `scripts/check-versions.mjs` |
 | Planned KXM schemas, restricted YAML fixtures, cross-resource semantics, and sync-safe rejection | `test/core/contracts.test.ts` |
 | Production KXM restricted loader, deterministic bundle hashing, Git discovery, fail-closed semantics, init classification, provenance-tracked atomic creation, exact three-way repair, authority-change blocking, pinned crash resumption, shadow validation, explicit join, Runtime-local bindings, CLI isolation, and idempotence | `test/core/project-config.test.ts`, `test/core/cli.test.ts`, `test/core/package-install.test.ts` |
-| Bounded legacy JSON migration: exact duplicate-key rejection, deterministic plans, decision binding (project/source/values), schema+semantic target validation, durable install, self-hashed receipts, tamper/drift detection, link refusal, CLI and packed-consumer round trips | `test/core/migrate.test.ts`, `test/core/cli.test.ts`, `test/core/contracts.test.ts`, `test/core/package-install.test.ts` |
+| Legacy state is refused, never converted: a tree with `.kxm/config` JSON fails project load with `legacy_state_unsupported`, `kxm init` classifies it `mode: "legacy"` without writing, `kxm migrate` is an unknown command, and an older stamped store is refused without advancing `user_version` | `test/core/project-config.test.ts`, `test/core/cli.test.ts`, `test/core/e6-backup-restore-migrations.test.ts` |
 | Permission-diff trust workflow: structured authority projections, conservative lattice classification (access, network, budgets, quorums, snapshots, secrets, transitions, shapes), prose neutrality, Git base shadowing, CLI diff/check gating, and packed-consumer round trips | `test/core/permission.test.ts`, `test/core/cli.test.ts`, `test/core/contracts.test.ts`, `test/core/package-install.test.ts` |
 | Event-sourced local Runtime: supervisor singleton with stable logical identity, immutable home bindings, append-only per-project event stores, idempotent acceptance/cancel, projection rebuild equivalence, token-authenticated local API, auto-start, SIGKILL crash recovery, offline CLI, packed consumer | `test/core/runtime.test.ts`, `test/core/cli.test.ts`, `test/core/package-install.test.ts` |
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kontextmind/kxm",
-  "version": "0.7.53",
+  "version": "0.7.55",
   "description": "KXM local-first multi-agent orchestration and operator dashboard",
   "type": "module",
   "author": "KontextMind",

package/plugins/kxm/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "kxm",
   "displayName": "KXM",
-  "version": "0.7.53",
+  "version": "0.7.55",
   "description": "Headless multi-agent orchestration, durable workflows, and a live operator dashboard for Pi and Claude Code",
   "author": {
     "name": "KontextMind",