Changelog

Edition 0.1.13 — 2026-09-05

· Runtime references updated for the 0.9.46 evaluation release, and the Developer Quick Start rewritten from a fresh install of that published package: install, `xmesh` in the project directory, reopen Claude Code — no provider variable, no wiring command, no seat to set. The bridge derives the seat from the Claude Code session; the ask carries the project directory; the first mission ('review this repository') wrote its deliverable into the repository, 2/2 checks, 203 s.

· The critic-model lever is now the room policy (criticMind / criticModel), not an environment variable.

· A second project joins the running runtime: `xmesh` there wires that project and exits.

Edition 0.1.12 — 2026-09-05

· Runtime references updated for the 0.9.45 evaluation release. 0.9.45 is the version to install: through 0.9.44 the environment handed to a spawned worker mind could carry credentials the mind had no business holding; 0.9.45 removes them, and the package README carries the security note with the remediation order.

· The Developer Quick Start gains an optional step for running missions on a model behind an API key: a lane (protocol, transport, base URL, key file, model), the provider probe that confirms the model is one the endpoint serves, the room policy that routes a room to the lane, and a proof mission — every command run as written on 2026-09-05 against 0.9.45, with the runtime's own spawn record quoted as the evidence of which model ran. The step opens by noting the reader's coding agent can run it.

· The landing page no longer says a person is what accepts a consequential outcome; it says acceptance is a separate recorded act, which is what the runtime records.

· The container commands on the Deploy page keep their 0.9.40 pin until that run is repeated.

Edition 0.1.11 — 2026-09-02

· Runtime references updated for the 0.9.42 evaluation release. 0.9.42 is the version to install: on 0.9.40 and 0.9.41 the independent review of a mission could fail to land on the mission row — a critic was stopped as idle before a long mission delivered, and a doer's own mid-run narration could be reviewed in place of its delivery. From 0.9.42 a critic reviews only a worker's completion of a commission its room requested, and stays until the window a completed mission is held open for its verdict has passed.

· The Developer Quick Start now states what independent review records rather than promising it: every mission starts a critic, and its verdict lands on the mission row separately from the completion — approved, objected, or absent when none arrived in the window. The earlier sentence said every completion was reviewed before it reached you; a measured run of two missions on one topic found the verdict absent on the second, which is what 0.9.42 fixes.

· The container commands on the Deploy page keep their 0.9.40 pin until that run is repeated.

Edition 0.1.10 — 2026-09-02

· Runtime references updated for the 0.9.40 evaluation release. 0.9.40 is the version to install. Since 0.9.39 the older /api/worlds and /api/commissions spellings answer 410 with the /api/missions path to use, and each mission row carries an outcome.

· The Deploy recipe is now "Where xMesh runs" and was re-run in full against the published symbotdocker/xmesh:0.9.40 image: it leads with the sandbox the reader already has (npm, no proxy, no volume, no licence), then one container and one volume for a team host, then the public-boundary settings and the team root. Corrected since the 0.9.23 run: the image carries its own worker mind (a pinned codex CLI), it has a shell rather than being distroless, it starts as root only to own the volume paths and drops to uid 1000 before any login or server code, and a fresh deployment runs under a default daily workload cap (chosen:false on /api/health) instead of refusing its first mission.

· Correction, same day: on 0.9.40 a team root named with XMESH_TEAM_ROOT does not place the mesh node stores — what the mesh has learned — inside it; they land under the container user's home, off the volume, and the next mission is briefed from nothing. On 0.9.40 the team-root step needs SYM_STATE_DIR set to the team root's sym directory. 0.9.41, released the same day, derives it from the team root — verified on the published image — and is the version to install; the container commands on the Deploy page keep their 0.9.40 pin until that run is repeated.

Edition 0.1.9 — 2026-08-31

· Runtime references updated for the 0.9.35 evaluation release (0.9.25 through 0.9.35 since the last sync). 0.9.35 is the version to install.

· Connecting a coding agent is one command: `xmesh mcp install --url … --seat …` from the project directory writes .mcp.json with the bridge from the install that ran it, and any xmesh command run from a project directory does the same. The seat must be the exact node name the mesh shows; the runtime matches it exactly and a near-miss delivers nowhere.

· The HTTP surface uses one word for the work you hand the mesh: /api/missions. The older /api/worlds and /api/commissions spellings still answer for one more release. GET /api lists every route without a credential; an unmatched path answers JSON naming the nearest real route; /api/version answers a loopback caller without a credential.

· Mission confirms now reach the requesting seat on a deployment that runs with its own state directory; before 0.9.35 such a deployment read an empty peer registry and delivered nothing while recording the right requester.

· The Deploy to Your Cloud recipe still pins symbotdocker/xmesh:0.9.23 until its commands are re-run against a newer image; every command and response on that page was transcribed from a real run, and the pin moves only when the run is repeated.

Edition 0.1.8 — 2026-08-26

· Runtime references updated for the 0.9.24 evaluation release. 0.9.24 is a fix release and is the version to install: on a team deployment, 0.9.23's scoped rooms pushed the room operator's internal name past the mesh's 64-byte identity limit and review-recipe missions failed to start. Operator names are now bounded for any room name length and kept verbatim whenever they already fit.

· From 0.9.23: recipe rooms are scoped to your team by default (a name that already carries a team suffix is kept as written, which is how a room is deliberately shared), and a deliverable worked by another team's volunteer returns over the mesh for your own runtime to write into your tree — the target path comes from the mission criteria rather than the network, must sit inside your workspace, and cannot overwrite anything that already exists.

· The Deploy to Your Cloud recipe continues to pin symbotdocker/xmesh:0.9.23 deliberately: every command and response on that page was transcribed from a run of that exact image, so an evaluator can name what they ran.

Edition 0.1.7 — 2026-08-26

· Deploy to Your Cloud is published (founder ruling): the container deployment guide returns to the published surface, re-verified the same day against the published symbotdocker/xmesh:0.9.23 image — every command, response body and status code transcribed from that run.

· What changed since the guide was first drafted: the image is pulled from Docker Hub rather than built from a repository, tenant state lives on one volume at /state, the image is distroless (the passcode is read from the container log), and a fresh tenant refuses its first paid mission with a structured 402 until a person makes the one-time spend choice — presented as the step an enterprise evaluator should want to see.

· Runtime references updated for the 0.9.23 evaluation release: recipe rooms are scoped to their team by default, and deliverables from cross-team volunteers return over the mesh to be written home by the commissioning runtime.

Edition 0.1.6 — 2026-08-26

· Runtime references updated for the 0.9.22 evaluation release (0.9.20 through 0.9.22 since the last sync).

· Recall now surfaces the whole cluster: mission briefs bring bounded same-mission siblings alongside ranked memories, labeled [via … room] rather than carrying a score they never earned — built because measurement showed the ranker finds the right mission far more often than the right memory, and verified to roughly triple target-in-brief at the same brief size.

· Board integrity from 0.9.20: disclosed findings become cards immediately, nothing is deleted (superseded cards move aside on the record), and spend refusals render on the card with their options.

· From 0.9.21: review crews work in the deployment's own workspace, never inside a reviewed repository; and MCP tool answers carry a version-skew banner after a runtime upgrade until the client reconnects.

· The Developer Quick Start is five steps: the one-time spend choice stands as its own step, independent mission review is on by default (opt out with XMESH_MISSION_CRITIC=0), and the two unrelated 402 refusals are disambiguated where a reader would first meet them.

Edition 0.1.5 — 2026-08-25

· Runtime references updated for the 0.9.19 evaluation release and its gated npm and multi-architecture container artifacts.

· The Developer Quick Start now walks the required first-install spend choice before the first LLM-backed mission, using the measured 40-work-unit starting cap without presenting it as a hard USD ceiling.

· The public release record now names the actionable Board flow: disclosed findings become cards immediately, validators can advance and start work from a card, and spend refusals remain structured and visible.

Edition 0.1.4 — 2026-08-25

· Chapter II now follows the accepted Station journey: Task, Done when and optional Context; read-back before dispatch; reconciled Needs You; Summary-first results; and raw diagnostics behind an explicit reveal.

· The evaluation-gap record now distinguishes remaining onboarding, mobile-navigation, dispatch-feedback and terminology work from privacy and decision-safety defects closed during the acceptance walk.

· The Developer Quick Start now enables the independent mission critic in its launch command and states the second-model usage trade-off.

Edition 0.1.3 — 2026-08-24

· Chapter I now explains the seven dimensions of cognition, SVAF whole-block admission, receiver-local semantic geometry and MiniLM-supported semantic recall without presenting the transformer as the mission reasoner.

· Chapter II is rewritten as a plain-language evaluation guide for a non-technical Station operator, with current usability gaps and decision boundaries stated explicitly.

· Runtime references updated for the current 0.9.18 evaluation release: identified requesters receive targeted mission confirmations; anonymous requesters are told immediately that follow-up is pull-only; optional room notices disclose only status and mission id.

Edition 0.1.2 — 2026-08-22

· Licensing contract clarified: Developer Runtime is free without a time limit for local development and non-production evaluation; production use is licensed annually per independently governed team mesh with unlimited humans and agents and no seat metering.

· Enterprise claims now remain design-partner scope until the corresponding product capabilities pass their release gates.

Edition 0.1.1 — 2026-08-19

· Chapter I updated for the runtime as it runs: mission completion, independent review and human rulings are retained as separate facts. The old offer → assemble → perform → verify → learn lifecycle, in which every mission waited for human validation, is retired.

· Chapter I opens with the developer path: drive xMesh from your coding agent by mission request over MCP; the API is the reference behind it.

· Chapter II published: Operating xMesh from the Station — the operator surface, distinct from the API. Every control named as the cockpit renders it.

Edition 0.1.0 — 2026-07-17

· Corrected Chapter I's close to remove the personal evaluation-bench instruction and distinguish executable single-mesh evidence from a reader-performable demonstration; enterprise deployment guidance remains with Chapter III.

· Removed the cover-page prerequisites block; deployment requirements remain with Chapter III, and the evaluation path remains in Chapter I.

· Publication scope: the published book is the CHAPTERS — Chapter I today, further chapters added to this edition in place. The migrated recipe set is retired from the published surface (preserved in the repository history; recipes return only if the founder publishes them).

· FIRST FORMAL PUBLICATION: Chapter I · The model — written by the mesh (a real xmesh mission), first-read by the CTO, published by founder ruling. Publication begins with Chapter I; further chapters are added to this edition in place as they are written, reviewed, and ruled.

· The Guidebook is born: the cookbook moves home to xmesh.bot and takes its institutional identity — education and knowledge transfer for IT leaders first, hands-on recipes as the proven executable core.

· Seven-chapter outline published after the mesh's structural review (verdict: AMEND, applied in place — this edition is unpublished and adjusted in situ): I The model · II Authority and trust · III Deployment and configuration · IV Agent permissions, budget, and blast radius · V Operating the mesh · VI Lifecycle: upgrades, recovery, and support · VII Becoming a narrative institution. Claims carry evidence labels; the recursion is honestly marked reasoned-not-yet-anchored.

· Recipe 11 — Deploy to Your Cloud: the deployment guide folds in, extended with the verify-ai-lane step (prove the enterprise AI lane before the first token).

· Recipe 12 — Establish Your Trust Root: the proven manual anchor procedure (mint the owner identity, custody the key, pin the anchor, seat operators), framed by the recursive topology — every mesh mints its owner; no global root.

· Positioning corrected: Team Mesh is licensed at a flat price per production team with unlimited users ("paid edition of the sym.day platform" retired); sym.day is the personal counterpart.