@mostra/protocol 0.0.0-stage → 0.1.0

package/src/diagnostics/codes/env.ts

@@ -0,0 +1,149 @@
+/**
+ * Diagnostic codes of the ENV area.
+ */
+import type { AreaCatalog } from "../spec.ts";
+
+/** The codes of the ENV area, in the order they were added. */
+export const envDiagnosticCodes = [
+  "MOSTRA_ENV_WARM_MISSING",
+  "MOSTRA_ENV_PORT_TAKEN",
+  "MOSTRA_ENV_BIND_FAILED",
+  "MOSTRA_ENV_SHELL_MISSING",
+  "MOSTRA_ENV_SERVICE_FAILED",
+  "MOSTRA_ENV_BROWSER_MISSING",
+  "MOSTRA_ENV_RUNTIME_MISSING",
+  "MOSTRA_ENV_BUNDLE_INVALID",
+  "MOSTRA_ENV_BUNDLE_DOWNLOAD_FAILED",
+  "MOSTRA_ENV_BUNDLE_UNAVAILABLE",
+  "MOSTRA_ENV_NODE_UNSUPPORTED",
+  // gen:codes
+] as const;
+
+/** The codes of the ENV area. */
+export type EnvDiagnosticCode = (typeof envDiagnosticCodes)[number];
+
+/** The ENV area's catalog entries. */
+export const envDiagnostics: AreaCatalog<EnvDiagnosticCode> = {
+  MOSTRA_ENV_WARM_MISSING: {
+    severity: "error",
+    phase: "host",
+    title: "Warm package set missing",
+    hint: "Reinstall the Mostra runtime, or set `MOSTRA_WARM_DIR` to its warm package set.",
+    docs: {
+      explanation:
+        "Builds resolve React, Tailwind and Mostra's own client packages from the warm package set that ships with the runtime. The runtime couldn't find it, which means the runtime installation is incomplete.",
+      fix: "Reinstall Mostra so the runtime bundle is complete. A custom layout can point the runtime at the warm set's directory with `MOSTRA_WARM_DIR`.",
+    },
+  },
+  MOSTRA_ENV_PORT_TAKEN: {
+    severity: "warning",
+    phase: "host",
+    title: "Leased port taken",
+    hint: "Open the artifact through a new link: `view/url` or `mostra open` mints one on the new port.",
+    docs: {
+      explanation:
+        "The shell's port or an artifact's port is leased per home and reused across restarts, so links keep working (D62, D99). At start-up another program held the leased port, so Mostra leased a new one. Links that named the old port stop working; the shell's port changing affects every link of the home.",
+      fix: "Mint new links with `view/url` (the publish receipt of the next publish carries the new default link too). Stop the program that took the port if you want the old links back; `mostra doctor` names it where it can.",
+    },
+  },
+  MOSTRA_ENV_BIND_FAILED: {
+    severity: "error",
+    phase: "host",
+    title: "Gateway can't bind",
+    hint: "Start Mostra with an address this machine has, or without `--bind` to use the loopback address.",
+    docs: {
+      explanation:
+        "The gateway couldn't listen on the address it was given: `--bind` named an address no interface has, a wildcard bind came without `--url-host`, or the operating system refused the address. Mostra doesn't start rather than serve on an address nobody asked for.",
+      fix: "Omit `--bind` to serve on `127.0.0.1` only (the default). For a wider bind, pass an address of one of this machine's interfaces, and with `0.0.0.0` or `::` also `--url-host <name>`, the name viewers use to reach it.",
+    },
+  },
+  MOSTRA_ENV_SHELL_MISSING: {
+    severity: "error",
+    phase: "host",
+    title: "Shell app missing",
+    hint: "Reinstall the Mostra runtime, or set `MOSTRA_SHELL_DIR` to its built shell.",
+    docs: {
+      explanation:
+        "Viewers open artifacts inside the shell, Mostra's trusted page, which ships with the runtime as built files. The runtime couldn't find them, which means the runtime installation is incomplete. Artifact frames are still served.",
+      fix: "Reinstall Mostra so the runtime bundle is complete. A custom layout can point the runtime at the shell's built directory with `MOSTRA_SHELL_DIR`.",
+    },
+  },
+  MOSTRA_ENV_SERVICE_FAILED: {
+    severity: "error",
+    phase: "host",
+    title: "Login service could not be installed",
+    hint: "Read the message, fix what it names, and run the install again.",
+    docs: {
+      explanation:
+        "`mostra daemon install` couldn't register the home's daemon as a login service: writing the launchd agent or systemd user unit failed, or `launchctl` or `systemctl --user` refused to load it.",
+      fix: "Check the named file's directory permissions, and on Linux that a systemd user session is running (`systemctl --user status`). On a machine without one, start the daemon from your own login scripts with `mostra daemon start`.",
+    },
+  },
+  MOSTRA_ENV_BROWSER_MISSING: {
+    severity: "error",
+    phase: "host",
+    title: "Browser for verify missing",
+    hint: "Run the runtime bundle's `bin/mostra-setup` (with network access) to fetch the browser verify uses, then verify again.",
+    docs: {
+      explanation:
+        "Verify renders pages in the Chromium headless shell its Playwright release pins. The runtime bundle fetches that browser when it is set up and checks every file of it (D142). It wasn't there, so verify ran only the stages that need no browser (type check, build and the field-ID scan) and reported this error. Publishing needs `--force` until it is installed.",
+      fix: "Run `bin/mostra-setup` in the runtime bundle's directory (the message names it) with network access; it fetches and checks the pinned browser. Outside a bundle, in a development checkout, run `npx playwright-core install chromium-headless-shell`. Then verify again.",
+    },
+  },
+  MOSTRA_ENV_RUNTIME_MISSING: {
+    severity: "error",
+    phase: "host",
+    title: "Runtime not found",
+    hint: "Reinstall Mostra, or set `MOSTRA_RUNTIME_BIN` to the runtime's `mostra-runtime` entry.",
+    docs: {
+      explanation:
+        "The CLI starts and attaches to the home's instance through the runtime binary (`mostra-runtime`, D85). It looked, in order, for `MOSTRA_BUNDLE`, `MOSTRA_RUNTIME_BIN`, the runtime bundle it runs from, its release's pinned bundle and a development checkout's built runtime (D142), and found nothing it could run: here, `MOSTRA_RUNTIME_BIN` names a file that doesn't exist, or the runtime couldn't be started.",
+      fix: "Unset `MOSTRA_RUNTIME_BIN` or point it at a `mostra-runtime` entry (its `dist/bin.js`), or reinstall Mostra so the CLI and its runtime are complete.",
+    },
+  },
+  MOSTRA_ENV_BUNDLE_INVALID: {
+    severity: "error",
+    phase: "platform",
+    title: "Runtime bundle failed verification",
+    hint: "Nothing was installed; install Mostra again, and if it fails the same way, report it with the message.",
+    docs: {
+      explanation:
+        "Mostra checks every runtime bundle before it runs anything from it: the archive against the SHA-256 the installing package pins, then each extracted file against the bundle's own file list, and the verify browser against the bundle's browser pin. One of them differed, so the download was corrupted, changed on the way or replaced, and Mostra refused it. A bundle already installed that fails a later check (`mostra doctor --deep`) is refused the same way.",
+      fix: "Run the install again (`npm create mostra`, or the command that started it), which downloads a fresh copy. When a mirror is configured (`MOSTRA_BUNDLE_MIRROR`), check that it serves the release's files unchanged. Check a file you downloaded yourself against the release's `SHA256SUMS`, or with `gh attestation verify <file> --repo mostra-dev/mostra`.",
+    },
+  },
+  MOSTRA_ENV_BUNDLE_DOWNLOAD_FAILED: {
+    severity: "error",
+    phase: "platform",
+    title: "Runtime bundle download failed",
+    hint: "Check the network or proxy (`HTTPS_PROXY`), then run the command again: a retry starts the download over.",
+    docs: {
+      explanation:
+        "The runtime bundle for this release and platform isn't in the local cache yet, and fetching it failed: the network or a proxy refused it, the server answered with an error, the connection stalled for 60 seconds, or the disk ran out of space while it was written. Nothing partial is kept.",
+      fix: "Check the connection, and set `HTTPS_PROXY` (and `NO_PROXY`) when the network needs a proxy. Behind a firewall that blocks GitHub, host the release's files on a reachable server and set `MOSTRA_BUNDLE_MIRROR` to its base URL (a `file:` URL works for a local directory). Free space in the cache directory (`MOSTRA_CACHE_DIR`) if the message says the disk is full.",
+    },
+  },
+  MOSTRA_ENV_BUNDLE_UNAVAILABLE: {
+    severity: "error",
+    phase: "platform",
+    title: "No runtime bundle available",
+    hint: "Run this once with network access, or point `MOSTRA_BUNDLE` at an extracted bundle.",
+    docs: {
+      explanation:
+        "Mostra runs on its own runtime bundle, found in the local cache, beside the installed package or at `MOSTRA_BUNDLE`. None was there, and no download could start: Mostra is offline (`MOSTRA_OFFLINE`), this build of the package pins no bundle for this platform, or the platform has none.",
+      fix: "Run the command once with network access and without `MOSTRA_OFFLINE`, so the pinned bundle is fetched and cached; later runs work offline. On a machine without network access, extract the release's archive for the platform and set `MOSTRA_BUNDLE` to its directory. A development checkout uses its own built runtime instead.",
+    },
+  },
+  MOSTRA_ENV_NODE_UNSUPPORTED: {
+    severity: "error",
+    phase: "platform",
+    title: "Node.js too old to start Mostra",
+    hint: "Run `mostra` with Node.js 22.19 or later, or run the runtime bundle's own `bin/mostra`, which needs no Node.js.",
+    docs: {
+      explanation:
+        "A `mostra` (or `npm create mostra`) installed from npm starts on the machine's Node.js only long enough to find its runtime bundle, then every Mostra process runs on the bundle's own Node.js (RT-01, D142). That start needs Node.js 22.19 or later, and this one is older, so Mostra stopped before loading anything.",
+      fix: "Upgrade the machine's Node.js to 22.19 or later, or run Mostra without npm: download the runtime bundle for your platform from the GitHub release, check it against `SHA256SUMS`, extract it, run its `bin/mostra-setup` once, then use its `bin/mostra`.",
+    },
+  },
+  // gen:entries
+};

package/src/diagnostics/codes/field.ts

@@ -0,0 +1,113 @@
+/**
+ * Diagnostic codes of the FIELD area.
+ */
+import type { AreaCatalog } from "../spec.ts";
+
+/** The codes of the FIELD area, in the order they were added. */
+export const fieldDiagnosticCodes = [
+  "MOSTRA_FIELD_TOO_LARGE",
+  "MOSTRA_FIELD_ID_INVALID",
+  "MOSTRA_FIELD_MUTATION_ID_REUSED",
+  "MOSTRA_FIELD_CONFLICT",
+  "MOSTRA_FIELD_DUPLICATE_ID",
+  "MOSTRA_FIELD_ID_UNSTABLE",
+  "MOSTRA_FIELD_SHARED",
+  "MOSTRA_FIELD_UNBOUND",
+  // gen:codes
+] as const;
+
+/** The codes of the FIELD area. */
+export type FieldDiagnosticCode = (typeof fieldDiagnosticCodes)[number];
+
+/** The FIELD area's catalog entries. */
+export const fieldDiagnostics: AreaCatalog<FieldDiagnosticCode> = {
+  MOSTRA_FIELD_TOO_LARGE: {
+    severity: "error",
+    phase: "runtime",
+    title: "Field value too large",
+    hint: "Split large data across fields, keeping each value under 1 MiB and the whole document under 16 MiB.",
+    docs: {
+      explanation:
+        "A field value is at most 1 MiB of JSON and a draft or artifact state at most 16 MiB in all (DATA_MODEL §5). This write would pass one of those limits, so Mostra refused it whole: nothing was truncated, and the page keeps the value locally.",
+      fix: "Split the value across several fields under one dotted prefix (`report.part1`, `report.part2`); they nest again in results.",
+    },
+  },
+  MOSTRA_FIELD_ID_INVALID: {
+    severity: "error",
+    phase: "runtime",
+    title: "Invalid field ID",
+    hint: "Use a stable field ID of 1 to 256 characters: dot-separated parts, none empty.",
+    docs: {
+      explanation:
+        "Every persisted value has an explicit, stable field ID (D52). An ID is 1 to 256 characters with no control characters; dots separate the parts that nest in results (`reply.m1`), so it can't start or end with a dot or hold two in a row.",
+      fix: "Give the field a fixed ID such as `layout` or `reply.m1` (one per message, from its ID), and keep it the same across renders and versions so drafts carry over.",
+    },
+  },
+  MOSTRA_FIELD_MUTATION_ID_REUSED: {
+    severity: "error",
+    phase: "runtime",
+    title: "Mutation ID reused",
+    hint: "Generate a new mutation ID for every new change.",
+    docs: {
+      explanation:
+        "A mutation ID identifies one change, so a retry after a timeout replays its recorded result (IN-01). This ID was already used for a change with other contents or another target. Mostra refuses it rather than answer with the result of a change nobody sent now.",
+      fix: "Create a fresh `mut_` ID for each change and reuse an ID only to retry exactly the same change.",
+    },
+  },
+  MOSTRA_FIELD_CONFLICT: {
+    severity: "error",
+    phase: "runtime",
+    title: "Field changed by another writer",
+    hint: "Read the value again, then write it; for a value several writers change often, give each writer a field of its own.",
+    docs: {
+      explanation:
+        "Every write names the revision it was based on, and a field changed after it is a conflict, never overwritten silently (D22). `window.storage` writes end with the last write: on a conflict it writes again over the newer value, a few times. When another writer kept changing the field each time, the write is refused with this code, and the field keeps the other writer's value.",
+      fix: "Read the key again and write the new value. For a counter or a list that many viewers change at once, store each viewer's part under its own key (`votes.<viewer>`) and combine them when reading.",
+    },
+  },
+  MOSTRA_FIELD_DUPLICATE_ID: {
+    severity: "error",
+    phase: "lint",
+    title: "Field ID used for two different fields",
+    hint: "Give each of these fields its own ID.",
+    docs: {
+      explanation:
+        "One field ID is used for two different fields: with two hook kinds (`useField` and `useChoice`, say), two scopes (`viewer` and `artifact`), or initial values of two types. The two would overwrite each other's saved value. The same ID used the same way twice is a deliberately shared value and isn't reported here.",
+      fix: "Rename one of them, for example `notes` and `notes.summary`, so each persisted value has its own ID.",
+    },
+  },
+  MOSTRA_FIELD_ID_UNSTABLE: {
+    severity: "error",
+    phase: "lint",
+    title: "Field ID changes between renders",
+    hint: "Build the field's ID from stable data, such as a record's ID, never from random numbers or the time.",
+    docs: {
+      explanation:
+        "Verify loaded the page twice with identical inputs and a fixed clock, and a field ID differed between the two loads. A viewer's saved answer would then be lost on every reload. IDs an interaction creates, such as a new list row's, are new fields and aren't reported.",
+      fix: "Derive the ID from something stable, for example a template with the record's ID instead of one with `Math.random()`.",
+    },
+  },
+  MOSTRA_FIELD_SHARED: {
+    severity: "hint",
+    phase: "lint",
+    title: "Field ID shared by several controls",
+    hint: "Nothing to fix if these controls are meant to edit one value; give each its own ID if not.",
+    docs: {
+      explanation:
+        "Several mounted components use one field ID in the same way, so they all edit one saved value. That is how a value is shared deliberately; in a list, it can also mean every row edits the same answer.",
+      fix: "If each row should keep its own answer, include the row's identity in the ID, such as a template that adds the task's ID after `done.`.",
+    },
+  },
+  MOSTRA_FIELD_UNBOUND: {
+    severity: "hint",
+    phase: "smoke",
+    title: "Input not bound to a field",
+    hint: "Bind the input with `useField` (or a kit input with an `id`) if its value should be saved and submitted.",
+    docs: {
+      explanation:
+        "Verify's smoke test typed into an input and the page saved nothing: the input isn't bound to a field, so what a viewer types there is lost on reload and isn't part of a submission. A search box or a filter may be meant that way.",
+      fix: 'Use `const [value, setValue] = useField("<id>", "")` for the input\'s value, or leave it if it isn\'t meant to persist.',
+    },
+  },
+  // gen:entries
+};

package/src/diagnostics/codes/home.ts

@@ -0,0 +1,150 @@
+/**
+ * Diagnostic codes of the HOME area: the Mostra home, its ledger and the instance that owns it
+ * (DATA_MODEL §1, §6; FAILURE_MODEL §2, §3).
+ */
+import type { AreaCatalog } from "../spec.ts";
+
+/** The codes of the HOME area, in the order they were added. */
+export const homeDiagnosticCodes = [
+  "MOSTRA_HOME_LOCKED",
+  "MOSTRA_HOME_NOT_OWNED",
+  "MOSTRA_HOME_SOCKET_TOO_LONG",
+  "MOSTRA_HOME_TOO_NEW",
+  "MOSTRA_HOME_LEDGER_UNREADABLE",
+  "MOSTRA_HOME_DISK_FULL",
+  "MOSTRA_HOME_GONE",
+  "MOSTRA_HOME_MISMATCH",
+  "MOSTRA_HOME_INTEGRITY",
+  "MOSTRA_HOME_NOT_ALWAYS_ON",
+  "MOSTRA_HOME_GC_INCOMPLETE",
+  // gen:codes
+] as const;
+
+/** The codes of the HOME area. */
+export type HomeDiagnosticCode = (typeof homeDiagnosticCodes)[number];
+
+/** The HOME area's catalog entries. */
+export const homeDiagnostics: AreaCatalog<HomeDiagnosticCode> = {
+  MOSTRA_HOME_LOCKED: {
+    severity: "error",
+    phase: "host",
+    title: "Home in use by another instance",
+    hint: "Use the instance that already owns this home, or stop it (`mostra daemon stop`, or end the process named in the message) and start again.",
+    docs: {
+      explanation:
+        "One Mostra instance owns a home at a time. It holds an exclusive lock on the home's ledger, and the operating system releases that lock when the process exits. Mostra reports this code in two cases: `mostra host` was started for a home another instance already owns, or a starter found the owner but couldn't reach its control socket. The message names the owner's process ID.",
+      fix: "To share the running instance, attach to it: start the client with the same home (`MOSTRA_HOME` or `--home`) instead of starting a second instance. To replace it, stop it with `mostra daemon stop`, or end the process named in the message, and start again. A host that needs its own instance gives it its own home.",
+    },
+  },
+  MOSTRA_HOME_NOT_OWNED: {
+    severity: "error",
+    phase: "host",
+    title: "Directory not owned by you",
+    hint: "Choose a home you own with `--home` or `MOSTRA_HOME`, or give the directory named in the message back to your user with `chown`.",
+    docs: {
+      explanation:
+        "Mostra keeps secrets, answers and its ledger in the home, and its control socket in a runtime directory, so it uses only directories that belong to the user running it. It reports this code when the home or the runtime directory is owned by another user, or when the path exists but isn't a directory. Mostra changes nothing in that case.",
+      fix: "Point Mostra at a directory you own: `--home <dir>` or `MOSTRA_HOME` for the home, `MOSTRA_RUNTIME_DIR` for the runtime directory. If the directory should be yours, change its owner with `chown`. Mostra tightens a directory you own to mode 0700 by itself.",
+    },
+  },
+  MOSTRA_HOME_SOCKET_TOO_LONG: {
+    severity: "error",
+    phase: "host",
+    title: "Control socket path too long",
+    hint: "Set `MOSTRA_RUNTIME_DIR` to a short directory you own, for example `/tmp/mostra-$USER`, and start again.",
+    docs: {
+      explanation:
+        "Clients reach an instance through a Unix socket in a per-user runtime directory. The operating system limits a socket path to 103 bytes on macOS and 107 on Linux, and the path Mostra computed is longer, usually because the home directory's path is long. Mostra stops instead of using a different place that clients couldn't find.",
+      fix: "Set `MOSTRA_RUNTIME_DIR` to a short directory you own, such as `/tmp/mostra-$USER`, in the environment of every Mostra client and host that uses this home. Mostra creates it with mode 0700 and re-creates its socket if a temporary-file cleanup removes it.",
+    },
+  },
+  MOSTRA_HOME_TOO_NEW: {
+    severity: "error",
+    phase: "host",
+    title: "Home written by a newer Mostra",
+    hint: "Run a Mostra release at least as new as the one named in the message, or use another home with `--home`.",
+    docs: {
+      explanation:
+        "A newer Mostra migrated this home's ledger to a schema version this runtime doesn't know. Reading it could misinterpret or lose data, so this runtime refuses to open it. The message names the schema version and the release that wrote it.",
+      fix: "Upgrade the runtime (or the host or CLI that bundles it) to at least the release named in the message. Mostra never migrates a ledger backwards; to keep an older release, give it a separate home with `--home` or `MOSTRA_HOME`.",
+    },
+  },
+  MOSTRA_HOME_LEDGER_UNREADABLE: {
+    severity: "error",
+    phase: "host",
+    title: "Ledger can't be read",
+    hint: "Restore the ledger from the latest `ledger.sqlite.bak-*` backup in the home's `store/` directory, or move the damaged file aside.",
+    docs: {
+      explanation:
+        "The ledger (`store/ledger.sqlite` in the home) holds drafts, submissions, events and the rest of the home's interaction data. Mostra reports this code when the file can't be opened, isn't a SQLite database, isn't a Mostra ledger, or fails SQLite's integrity check. Mostra never replaces an existing ledger with an empty one.",
+      fix: "Stop every Mostra process for this home. Copy `store/ledger.sqlite` somewhere safe, then restore the newest `store/ledger.sqlite.bak-<from>-<to>` in its place, or move the damaged file aside to start an empty ledger. Versions, sources and blobs in the home are untouched either way.",
+    },
+  },
+  MOSTRA_HOME_DISK_FULL: {
+    severity: "error",
+    phase: "host",
+    title: "Disk full",
+    hint: "Free space on the disk that holds the Mostra home, then retry.",
+    docs: {
+      explanation:
+        "A ledger write failed because the disk holding the home is full. The transaction was rolled back, so nothing partial was saved and nothing that was acknowledged earlier is lost. Viewers keep unsaved edits in their browser until a retry succeeds.",
+      fix: "Free space on that disk (`mostra gc` removes unreferenced versions; build caches can be deleted), then retry the operation. Retries with the same request or mutation ID are safe.",
+    },
+  },
+  MOSTRA_HOME_GONE: {
+    severity: "error",
+    phase: "host",
+    title: "Home directory removed",
+    hint: "Restore or recreate the home directory, then start Mostra again.",
+    docs: {
+      explanation:
+        "The instance's home directory disappeared or was replaced while the instance was running. Writing anywhere else could split the home's data, so the instance stops accepting requests, stops its child processes and exits.",
+      fix: "Put the home back (or choose a new one with `--home` or `MOSTRA_HOME`) and start Mostra again. Clients reconnect and retry their requests by ID.",
+    },
+  },
+  MOSTRA_HOME_MISMATCH: {
+    severity: "error",
+    phase: "host",
+    title: "Instance serves a different home",
+    hint: "Connect to the instance for the home you expect, or start it with `--home` set to that home.",
+    docs: {
+      explanation:
+        "A client sent `home.path` in `mostra/initialize`, and it names a different home from the one the instance locked at start-up. The home is chosen when the instance starts (`--home`, then `MOSTRA_HOME`, then the platform default), so `home.path` is a check: it stops a client from writing to a home it didn't mean.",
+      fix: "Start the instance with `--home` set to the home the client expects, or connect to the socket of the instance that serves it. Leave `home.path` out to accept whichever home the instance serves.",
+    },
+  },
+  MOSTRA_HOME_INTEGRITY: {
+    severity: "error",
+    phase: "host",
+    title: "Stored version or file damaged",
+    hint: "Publish the version's source again to rebuild a damaged version in place, and run `mostra doctor` for other damaged objects.",
+    docs: {
+      explanation:
+        "Mostra checks stored versions, source snapshots and blobs against their recorded content digests before using them. This code means a stored object is missing or its content changed after it was written, for example after a disk error or a manual edit inside the home. The message names the object.",
+      fix: "Leave files inside the home unchanged. To repair a version, publish the same source again: Mostra rebuilds the version's directory and puts it back under the same version ID, and the artifact keeps its version number. If the source has changed since, the publish makes a new version and the damaged one stays as it is; its source snapshot in the home holds the original files. `mostra doctor` lists other damaged objects.",
+    },
+  },
+  MOSTRA_HOME_NOT_ALWAYS_ON: {
+    severity: "warning",
+    phase: "host",
+    title: "Long-lived artifacts without an always-on daemon",
+    hint: "Run `mostra daemon install` so the home's daemon runs as a login service and these artifacts answer at any hour.",
+    docs: {
+      explanation:
+        "The home has artifacts with submission policy `none`, which are meant to stay open (dashboards, task managers, D63), but no login service runs its daemon. Without one, the daemon exits after 30 idle minutes and their links stop answering until a command starts it again.",
+      fix: "Run `mostra daemon install`. It registers a launchd or systemd user service that keeps the home's daemon running; `mostra daemon uninstall` removes it.",
+    },
+  },
+  MOSTRA_HOME_GC_INCOMPLETE: {
+    severity: "warning",
+    phase: "host",
+    title: "gc didn't finish a step",
+    hint: "Run `mostra gc` again: what this run removed is in its result, and the next run picks up what it left.",
+    docs: {
+      explanation:
+        "`mostra gc` removes what nothing references in steps: version files, source snapshots, lock layouts, the package store, verify's caches and, when asked, events. One step failed (the message names it and why), so it left that step's files in place. Everything an earlier step removed is listed in the result, and the versions it collected stay collected. The home is consistent: what gc left is still recorded as there.",
+      fix: "Run `mostra gc` again; a failure that repeats names its cause in the message (for example, a file the user can't remove).",
+    },
+  },
+  // gen:entries
+};

package/src/diagnostics/codes/host.ts

@@ -0,0 +1,197 @@
+/**
+ * Diagnostic codes of the HOST area: the host protocol between clients and an instance.
+ */
+import type { AreaCatalog } from "../spec.ts";
+
+/** The codes of the HOST area, in the order they were added. */
+export const hostDiagnosticCodes = [
+  "MOSTRA_HOST_REVISION_UNSUPPORTED",
+  "MOSTRA_HOST_MALFORMED",
+  "MOSTRA_HOST_METHOD_UNKNOWN",
+  "MOSTRA_HOST_INVALID_PARAMS",
+  "MOSTRA_HOST_INTERNAL_ERROR",
+  "MOSTRA_HOST_INITIALIZE_ORDER",
+  "MOSTRA_HOST_PORT_UNSUPPORTED",
+  "MOSTRA_HOST_CONNECTION_CLOSED",
+  "MOSTRA_HOST_TIMEOUT",
+  "MOSTRA_HOST_SHUTDOWN_REFUSED",
+  "MOSTRA_HOST_REQUEST_ID_REUSED",
+  "MOSTRA_HOST_CURSOR_COMPACTED",
+  "MOSTRA_HOST_SUBSCRIPTION_UNKNOWN",
+  "MOSTRA_HOST_NOTIFICATION_UNSUPPORTED",
+  "MOSTRA_HOST_MESSAGE_TOO_LARGE",
+  // gen:codes
+] as const;
+
+/** The codes of the HOST area. */
+export type HostDiagnosticCode = (typeof hostDiagnosticCodes)[number];
+
+/** The HOST area's catalog entries. */
+export const hostDiagnostics: AreaCatalog<HostDiagnosticCode> = {
+  MOSTRA_HOST_REVISION_UNSUPPORTED: {
+    severity: "error",
+    phase: "host",
+    title: "No common host protocol revision",
+    hint: "Run the client and the instance from the same Mostra release, for example with `mostra daemon restart`.",
+    docs: {
+      explanation:
+        "A client and a Mostra instance agree on a host protocol revision when they connect (`mostra/initialize`). The client offers the revisions it speaks, and the instance picks the newest one it also supports. This code means the two lists have nothing in common, usually because the client and the running daemon come from Mostra releases far apart.",
+      fix: "Restart the daemon so it runs the same release as the client: `mostra daemon restart`. Durable state survives the restart, and open views reconnect. A host that embeds Mostra updates its pinned Mostra runtime or its host library until both support a common revision.",
+    },
+  },
+  MOSTRA_HOST_MALFORMED: {
+    severity: "error",
+    phase: "host",
+    title: "Malformed protocol message",
+    hint: "Send each message as one line of JSON holding a single JSON-RPC 2.0 request or notification.",
+    docs: {
+      explanation:
+        "Every message on a Mostra connection is one line of JSON with one JSON-RPC 2.0 object. This code means a line wasn't valid JSON, wasn't a JSON-RPC 2.0 request or response, or was a batch (a JSON array), which revision `2026-10-10` doesn't accept. A client also reports it when a response doesn't match the method's result schema.",
+      fix: 'Encode one request per line with `"jsonrpc": "2.0"`, a `method`, an `id` for requests, and `params` as an object. Send several requests as separate lines instead of a batch.',
+    },
+  },
+  MOSTRA_HOST_METHOD_UNKNOWN: {
+    severity: "error",
+    phase: "host",
+    title: "Unknown protocol method",
+    hint: "Call only the methods listed in `capabilities.methods` of the `mostra/initialize` result.",
+    docs: {
+      explanation:
+        "The instance doesn't serve the method that was called. Either the name is misspelled, or the client is newer than the instance and calls a method the instance's release doesn't have.",
+      fix: "Check the method name against INTERFACES \u00a76, and against `capabilities.methods` in the `mostra/initialize` result, which lists every method this instance serves. Upgrade the instance if the client needs a newer method.",
+    },
+  },
+  MOSTRA_HOST_INVALID_PARAMS: {
+    severity: "error",
+    phase: "host",
+    title: "Invalid method params",
+    hint: "Fix the params named in the message so they match the method's schema.",
+    docs: {
+      explanation:
+        "The request's `params` don't match the method's published schema: a required field is missing, a value has the wrong type, or a value is outside its allowed range. The message names the first problem found.",
+      fix: "Compare the request with the method's schema in `@mostra/protocol` (or the published JSON Schema) and correct the field named in the message.",
+    },
+  },
+  MOSTRA_HOST_INTERNAL_ERROR: {
+    severity: "error",
+    phase: "host",
+    title: "Unexpected failure in the instance",
+    hint: "Retry the request with the same request ID; if it fails again, report it with the instance's log.",
+    docs: {
+      explanation:
+        "The instance failed while handling the request, for a reason that isn't one of its known conditions. Durable state is unaffected: a request is acknowledged only after its ledger transaction commits. The details are in the instance's log (`logs/supervisor.log` in the home), not in the response.",
+      fix: "Retry the request with the same request ID; retries are idempotent. If the failure repeats, report it with the relevant lines of `logs/supervisor.log`.",
+    },
+  },
+  MOSTRA_HOST_INITIALIZE_ORDER: {
+    severity: "error",
+    phase: "host",
+    title: "Initialize first, and only once",
+    hint: "Send `mostra/initialize` as the first request on the connection, and only once.",
+    docs: {
+      explanation:
+        "Every connection starts with `mostra/initialize`, which agrees the protocol revision and registers the client's ports. The instance received another request before it, or a second `mostra/initialize` on the same connection.",
+      fix: "Send `mostra/initialize` first and wait for its result before any other request. To renegotiate, open a new connection.",
+    },
+  },
+  MOSTRA_HOST_PORT_UNSUPPORTED: {
+    severity: "warning",
+    phase: "host",
+    title: "Port not supported by this instance",
+    hint: "Leave the port out of `mostra/initialize`, or run a Mostra release that lists it in `capabilities.ports`.",
+    docs: {
+      explanation:
+        "The client registered a port this instance doesn't call, so registering it has no effect. The port may be reserved for a later release (such as `ai`), or the client may be newer than the instance. The session continues without the port, and Mostra uses its standalone behavior instead.",
+      fix: "Register only the ports listed in `capabilities.ports` of the `mostra/initialize` result. If the host needs the port, upgrade the instance to a release that supports it.",
+    },
+  },
+  MOSTRA_HOST_CONNECTION_CLOSED: {
+    severity: "error",
+    phase: "host",
+    title: "Connection closed",
+    hint: "Reconnect, then retry the request with the same request ID.",
+    docs: {
+      explanation:
+        "The connection to the other side closed before a response arrived, for example because the instance exited or restarted. The request may or may not have taken effect.",
+      fix: "Reconnect and send `mostra/initialize` again, then retry the request with the same request ID. Mutating methods are idempotent by request ID, so a retry never applies twice.",
+    },
+  },
+  MOSTRA_HOST_TIMEOUT: {
+    severity: "error",
+    phase: "host",
+    title: "Request timed out",
+    hint: "Retry the request with the same request ID, or allow it more time.",
+    docs: {
+      explanation:
+        "No response arrived within the time the caller allowed. The other side may still be working on the request, and it may still take effect.",
+      fix: "Retry with the same request ID, which returns the recorded result if the first attempt completed. Allow a longer timeout for slow operations.",
+    },
+  },
+  MOSTRA_HOST_SHUTDOWN_REFUSED: {
+    severity: "error",
+    phase: "host",
+    title: "Only the spawning host can stop this instance",
+    hint: "Ask the host that started this instance to stop it, or end the connection you opened instead.",
+    docs: {
+      explanation:
+        "An instance started by a host over stdio (`mostra host`) lives as long as that host's connection, so only the host may stop it with `mostra/shutdown`. A client that attached through the home's socket asked it to stop. A daemon (`mostra daemon`) accepts `mostra/shutdown` from every attached client (D87).",
+      fix: "Close your own connection when you are done. To stop the instance, stop the host that spawned it, or have the host send `mostra/shutdown` or close its stdio.",
+    },
+  },
+  MOSTRA_HOST_REQUEST_ID_REUSED: {
+    severity: "error",
+    phase: "host",
+    title: "A requestId was reused with other parameters",
+    hint: "Send a new `requestId` for a new request; repeat the exact parameters only to retry one.",
+    docs: {
+      explanation:
+        "A mutating method recorded its result under this `requestId` for different parameters. Replaying that result would answer a request nobody made (a link for another artifact or with other scopes, another source's publish), so the instance refuses (H-03). Retries with the same parameters still return the recorded result.",
+      fix: "Generate a fresh `requestId` for every new request, and reuse one only to retry the same request after a timeout or a lost connection.",
+    },
+  },
+  MOSTRA_HOST_CURSOR_COMPACTED: {
+    severity: "error",
+    phase: "host",
+    title: "Events compacted",
+    hint: "Read from the cursor in the message to receive the compaction summary, then continue from there.",
+    docs: {
+      explanation:
+        "Events before a cursor were compacted on request (`mostra gc --compact-events`, DATA_MODEL §4): an artifact's old events were replaced by one `artifact.compacted` event that summarizes them. A reader asking for events after an earlier cursor would miss some, and Mostra never leaves a silent gap.",
+      fix: "Read again with `after` set to the cursor the message names: the next event is the `artifact.compacted` summary. Rebuild what you track from it and continue as usual.",
+    },
+  },
+  MOSTRA_HOST_SUBSCRIPTION_UNKNOWN: {
+    severity: "error",
+    phase: "host",
+    title: "Unknown subscription",
+    hint: "Subscribe again with `events/subscribe`, then use the ID it returns.",
+    docs: {
+      explanation:
+        "The subscription ID belongs to no subscription on this connection: it was never created here, was ended with `events/unsubscribe`, or belonged to a connection that closed. Subscriptions live as long as their connection; a named subscriber's acknowledged cursor outlives it.",
+      fix: "Call `events/subscribe` again on this connection. With the same `name`, delivery resumes after the last acknowledged cursor.",
+    },
+  },
+  MOSTRA_HOST_NOTIFICATION_UNSUPPORTED: {
+    severity: "error",
+    phase: "host",
+    title: "Notification not accepted",
+    hint: "List the notification in `capabilities.notifications` when you initialize.",
+    docs: {
+      explanation:
+        "Mostra sends a client only the notifications it listed in `mostra/initialize` (D84). This method would send one the client didn't list, such as `events/notify` for `events/subscribe`.",
+      fix: 'Reconnect and initialize with `capabilities: { notifications: ["events/notify"] }`, or poll with `events/read` instead.',
+    },
+  },
+  MOSTRA_HOST_MESSAGE_TOO_LARGE: {
+    severity: "error",
+    phase: "host",
+    title: "Message too large for the protocol",
+    hint: "Ask for less at once: a specific submission, fewer events, or smaller values.",
+    docs: {
+      explanation:
+        "One host-protocol message is one line of JSON, and a line holds at most 64 Mi characters (`MAX_LINE_LENGTH`), so neither side buffers without bound. Mostra checks every message before it writes it: an answer that would be longer is replaced by this error, and a delivery whose envelope would be longer is recorded as undeliverable instead of being sent and retried forever.",
+      fix: "Read less per request (`events/read` with a smaller `limit`, `results/get` for one submission), and keep artifacts' values within the field and document limits.",
+    },
+  },
+  // gen:entries
+};