@iowarp/clio-coder 0.4.7 → 0.4.9

package/docs/guide/exit-codes-and-output.md

@@ -1,8 +1,5 @@
 # Exit Codes & Machine-Readable Output Contracts
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Exit Codes & Machine-Readable Output Contracts visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/exit_codes_blueprint.html).
-
 This document specifies the process exit codes, machine-readable JSON streaming formats, standard I/O separation rules, and `--help` conventions across all Clio Coder CLI commands in the current source tree.
 
 Source implementations: `src/cli/` and `src/entry/`.

package/docs/guide/extensions-and-sharing.md

@@ -1,8 +1,5 @@
 # Extensions, Resources, and Share Archives
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Extensions, Resources, and Share Archives visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/extensions_blueprint.html).
-
 Clio Coder has two package kinds. A plugin is a domain bundle: prompts, skills, agent recipes, fleet contracts, scripts, and reference files, installed with `clio-coder library install <path>`. A harness extension is executable runtime capability: command tools and hook declarations, installed with `clio-coder extensions install <path>`. Only plugins contribute resources; see [plugins.md](plugins.md) and [harness-extensions.md](harness-extensions.md) for each contract.
 
 Share archives are portable JSON files for moving project and user Clio resources between machines or collaborators.

package/docs/guide/fleet-dispatch.md

@@ -1,8 +1,5 @@
 # Fleet Dispatch
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Fleet Dispatch visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/fleet_dispatch_blueprint.html).
-
 Clio Coder dispatches bounded worker agents. With a fleet configured, those
 workers run on remote machines over SSH while the orchestrator keeps every
 guarantee it makes locally: one admission path, one autonomy matrix, one
@@ -131,10 +128,11 @@ the node's real SSH channel:
 Run it with `clio-coder doctor`. Plain doctor is diagnostic and read-only: it
 reports the live probe rows but does not create or refresh
 `fleet-preflight.json`, and therefore does not change dispatch eligibility.
+Run `clio-coder doctor --fix` to record passing preflight results into
+`fleet-preflight.json` and make verified nodes dispatch-eligible.
 Placement still reads a pre-existing record under the state directory, keyed by
 node and project root; a changed host, changed project root, or local
-`clio-coder` upgrade invalidates that record and admission fails closed. The
-current CLI exposes no mutating doctor preflight that refreshes it. Failing
+`clio-coder` upgrade invalidates that record and admission fails closed. Failing
 nodes are doctor warnings rather than a failure of the local installation.
 
 ## Placement and process-safe admission

package/docs/guide/glossary.md

@@ -1,8 +1,5 @@
 # Clio Coder Glossary
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Clio Coder Glossary visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/glossary_blueprint.html).
-
 This document defines the 50 core architectural concepts and terminology used throughout Clio Coder, mapped to their authoritative TypeScript type definitions in `src/`.
 
 ---
@@ -31,7 +28,7 @@ This document defines the 50 core architectural concepts and terminology used th
 
 ### 6. Receipt
 - **Definition**: An immutable, cryptographically sealed record of a completed run containing full execution facts, tool telemetry, token accounting, validation grounding, and outcome codes.
-- **Owning Type**: `RunReceipt` in `src/domains/dispatch/types.ts` (`RUN_RECEIPT_INTEGRITY_VERSION = 20`).
+- **Owning Type**: `RunReceipt` in `src/domains/dispatch/types.ts` (`RUN_RECEIPT_INTEGRITY_VERSION = 20` in `src/domains/dispatch/receipt-integrity.ts`).
 
 ### 7. Envelope
 - **Definition**: A bounded container enforcing byte-length limits and truncation indicators on a dynamic payload. Tool output carries shown and total byte counts plus a continuation fragment; a parent briefing carries byte count and SHA-256 content hash instead.

package/docs/guide/harness-extensions.md

@@ -1,7 +1,5 @@
 # Harness extensions
 
-> **Visual blueprint:** See the [visual reference](../html/harness_extensions_blueprint.html) in the source checkout.
-
 Harness extensions add executable capabilities to Clio. Library recipes may also carry explicitly invoked workflow or evaluation scripts. Installing or browsing a recipe never registers harness tools, hooks, operator commands, or UI. A domain workflow that combines prompts, agents, skills, fleets, and reference files is a plugin, installed with `clio-coder library install <path>`.
 
 An extension declares command tools in `clio-coder-extension.yaml`, `.yml`, or `.json`. Clio discovers and validates declarations without importing or executing package code. Tools become available in a new session after installation. Native workers can use a tool when their admitted recipe includes its qualified name; narrower profiles such as `minimal-local` exclude extension commands.

package/docs/guide/installation-and-lifecycle.md

@@ -1,8 +1,5 @@
 # Installation and Lifecycle Operations
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Installation and Lifecycle Operations visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/lifecycle_blueprint.html).
-
 Clio Coder installs from the npm registry as `@iowarp/clio-coder` using npm,
 pnpm, or Bun, or from a source checkout using the pinned pnpm workflow. The
 [README installation guide](../../README.md#install) covers global installs,
@@ -22,7 +19,7 @@ lifecycle operations.
 | Set up a new installation | `clio-coder configure` | Quick Connect: endpoint, key if needed, model, Connect; then start `clio-coder`. |
 | Change a connection | `clio-coder configure --section targets` | Add or edit endpoints, credentials, and models; choose role defaults. |
 | Change any setting or repair YAML | `clio-coder configure --edit` | Edit a draft, validate, and save with a backup. |
-| Diagnose the installation | `clio-coder doctor` | Read-only diagnosis. `clio-coder doctor --fix` repairs structure and permissions. |
+| Diagnose the installation | `clio-coder doctor` | Read-only diagnosis. `clio-coder doctor --fix` repairs structure and permissions, and records fleet preflight results. |
 | Finish a package-manager update | `clio-coder upgrade --post-install` | Apply local migrations and installation checks. |
 | Start configuration over | `clio-coder reset --config` | Reset settings, preserve credentials and history, then run `clio-coder configure`. |
 | Emulate a fresh user | `clio-coder reset --all` | Remove all four user roots, recreate defaults, then run `clio-coder configure`. |
@@ -48,7 +45,7 @@ npm install -g @iowarp/clio-coder --omit=optional
 # Or: bun add -g @iowarp/clio-coder --omit=optional
 ```
 
-Measured on Linux x64 with a production install (`--omit=dev`): 387MB across 118 packages with the SDK, 143MB across 109 packages without it. That is 244MB and nine packages saved, a 63% smaller tree, and what remains is fully open-licensed.
+Historical Linux x64 measurement before the web package integration (`--omit=dev`): 387 MB across 118 packages with the SDK, 143 MB across 109 packages without it. Treat those numbers as a comparison, not the current install size: the platform, dependency versions and optional packages change the total. The release tarball size excludes separately installed npm dependencies.
 
 Everything except the `claude-sdk` runtime works on the smaller install: boot, `clio-coder doctor`, every other target and worker runtime. Dispatching a `claude-sdk` target on an install that omitted the package fails that run with a diagnostic naming the package and the command that fixes it (`npm install @anthropic-ai/claude-agent-sdk@0.3.186`); nothing else degrades, and nothing fails at startup.
 
@@ -224,7 +221,7 @@ Runs a series of health sweeps across the environment:
 *   Asserts owner-only permissions on credentials (`0o600`).
 *   Reports the installed Clio, Node, platform, and engine package readiness.
 *   Checks config, data, state, cache, and state metadata freshness. It also warns when an OpenAI-compatible or Anthropic-compatible target appears to be a native LM Studio or Ollama server that should be converted.
-*   *Recovery:* Run `clio-coder doctor --fix` to create missing directories and templates, repair credential permissions, and refresh install metadata. Settings are always validated against the current schema; `--fix` does not rewrite removed keys or migrate an older settings file. Run `clio-coder upgrade` for registered lifecycle migrations, including removal of the retired `panes.agents` and `panes.keepFailed` keys; paths with no registered migration still require deliberate editing.
+*   *Recovery:* Run `clio-coder doctor --fix` to create missing directories and templates, repair credential permissions, refresh install metadata, and record fleet preflight results. Settings are always validated against the current schema; `--fix` does not rewrite removed keys or migrate an older settings file. Run `clio-coder upgrade` for registered lifecycle migrations, including removal of the retired `panes.agents` and `panes.keepFailed` keys; paths with no registered migration still require deliberate editing.
 
 ### B. Upgrades (`clio-coder upgrade`)
 Refreshes state metadata and applies pending lifecycle migrations, which may update settings, state, or extension data.

package/docs/guide/interop.md

@@ -1,7 +1,5 @@
 # Coding agent interoperability
 
-> **Visual blueprint:** See the [visual reference](../html/interop_blueprint.html) in the source checkout.
-
 Interoperability runs both ways. Inbound, Clio can discover resources held by
 Claude Code, Codex, Antigravity CLI, GitHub Copilot CLI, and OpenCode, then adopt
 safe text resources into the library after approval. Outbound, the same canonical

package/docs/guide/panes-and-files.md

@@ -1,8 +1,5 @@
 # Panes and the Files Pane
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Panes and the Files Pane visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/panes_files_blueprint.html).
-
 This page is the operator's path from a clean machine to a working files pane
 beside a Clio Coder session: what to install, how a session joins its pane
 host, the commands and keys, the settings that govern them, what `doctor`

package/docs/guide/plugins.md

@@ -1,8 +1,5 @@
 # Portable plugins and the library
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Plugins visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/plugins_blueprint.html).
-
 A plugin is a complete, versioned bundle of skills and supporting files. The portable root `plugin.json` follows [Agent Plugins 1.0.0](https://agent-plugins.org/). Clio reads native prompts, agent recipes, and fleets from its namespaced manifest extension. Installing a bundle keeps those resources and their references together.
 
 Browse the bundled catalog, preview a complete installation, then install it:

package/docs/guide/proactive-memory.md

@@ -1,8 +1,5 @@
 # Proactive task memory
 
-> **Visual blueprint:** The source checkout includes the complete
-> [Proactive task memory visual reference](https://github.com/iowarp/clio-coder/blob/main/docs/html/proactive_memory_blueprint.html).
-
 Clio's proactive task memory protects long-running work from behavioral state
 decay: a requirement, environment fact, failed attempt, or diagnosis can still
 exist in the transcript while no longer influencing the next action. The design

package/docs/guide/resource-library.md

@@ -1,7 +1,5 @@
 # Library packages
 
-> **Visual blueprint:** See the [Library visual reference](../html/resource_library_blueprint.html) in the source checkout.
-
 The **library** is Clio's collection of installable **packages**. Each package has one kind: `plugin`, `skill`, `agent`, `prompt`, or `fleet`. Every kind uses a root `plugin.json`, an explicit Semantic Version, a full-tree SHA-256 pin, and the same installation state. A plugin bundles several resources; each other kind exposes one public resource and may include supporting files.
 
 ## Browse and install
@@ -122,7 +120,7 @@ clio-coder library recipes --source core --all
 
 `library recipes` is the versioned, body-free read of the recipes actually discovered here, across every source: bundled core recipes, loose user and project files, installed package members, and foreign files in interop compatibility roots. Each row carries its actual runtime name, its owning package or source class, its scope, its origin evidence, its availability and, where it is usable, its invocation. It never fetches a remote source and never writes. `library list` and `library search` stay package-oriented and answer with install targets; `--kind agent` there also matches packages whose generated `provides` hints include an agent, so a kind query finds the owning bundle before installation. `library inventory --json` is unchanged: it remains the fixed skills wire contract that GUI hosts read.
 
-Clio reads the same inventory through `context(scope="library")`. That scope is a read: bounded `kind`, `query` and `ref` selection with `limit`/`offset` pages, tagged rows for loaded resources, catalog hints and install targets, and no activation, installation, registration or pin write anywhere in it. Skill activation stays under `context(scope="skills")` and `/skill <name>`. A hint row names its installable owner and that member's honest state and never carries an invocation, because nothing has loaded it. Internal and shadow agents, untrusted resources and instruction bodies are not in the model's view at all, and a worker run has no library projection of its own. See [tool usage](tool-usage.md) for the argument surface and the row shapes.
+Clio reads the same inventory through `gateway(op="call", capability="clio_library", args={})`. That capability is a read: bounded `kind`, `query` and `ref` selection with `limit`/`offset` pages, tagged rows for loaded resources, catalog hints and install targets, and no activation, installation, registration or pin write anywhere in it. Skill activation stays under `context(scope="skills")` and `/skill <name>`. A hint row names its installable owner and that member's honest state and never carries an invocation, because nothing has loaded it. Internal and shadow agents, untrusted resources and instruction bodies are not in the model's view at all, and a worker run has no library projection of its own. See [tool usage](tool-usage.md) for the argument surface and the row shapes.
 
 A package declares named suite paths in `extensions["ai.iowarp.clio"].evals`. Run the same eval interface for every kind:
 

package/docs/guide/skills-marketplace.md

@@ -1,7 +1,5 @@
 # Skills in the library
 
-> **Visual blueprint:** See the [Skills visual reference](../html/skills_blueprint.html) in the source checkout.
-
 Skills are one kind of [library package](resource-library.md). `/skills` opens the Library overlay's skill tab directly, while `/library` opens the full overlay (covering skills, plugins, agents, prompts, and fleets). `/skill <name>` invokes a skill, and `/skill off` clears the session's active tool surface; bare `/skill` returns usage guidance pointing to `/skills`. Skill packages use the same manifest, version, full-tree digest, origins, scope and lifecycle as every other package.
 
 ```bash