@shoalrun/cli 0.1.0-alpha.17 → 0.1.0-alpha.19

package/agent-docs/publish/evals.sections/check-the-report.md

@@ -17,13 +17,13 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Evaluate agent tasks against your docs
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/evals.md)
 
-Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun does not launch agents, choose a model, or grade prose.
+Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun doesn't launch agents, choose a model, or grade prose.
 
-You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build does not execute evaluations or call a model. Evaluations are opt-in audit checks.
+You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build doesn't execute evaluations or call a model. Evaluations are opt-in audit checks.
 
 ## Check the report
 
@@ -33,4 +33,4 @@ shoalrun eval check site-dist --tasks evals/tasks.yaml --report evals/results.js
 
 The command prints JSON and exits 1 on failure. It checks schema versions and fields, unique task and criterion IDs, the two digests, timestamps, runner and review details, declared tool access, criterion coverage, and whether each citation identifies a published page in the selected publication. Required tasks must pass. Missing or failed optional tasks appear in the outcomes without blocking, but malformed results, bad citations, or unsupported passing claims still fail validation.
 
-Shoalrun verifies that cited pages exist; it does not verify that their text supports an answer. Reported tool use and grades are assertions supplied by the runner and reviewer. A passing report does not establish broad agent reliability or factual correctness.
+Shoalrun verifies that cited pages exist; it doesn't verify that their text supports an answer. Reported tool use and grades are assertions supplied by the runner and reviewer. A passing report doesn't establish broad agent reliability or factual correctness.

package/agent-docs/publish/evals.sections/define-a-task-file.md

@@ -17,17 +17,17 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Evaluate agent tasks against your docs
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/evals.md)
 
-Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun does not launch agents, choose a model, or grade prose.
+Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun doesn't launch agents, choose a model, or grade prose.
 
-You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build does not execute evaluations or call a model. Evaluations are opt-in audit checks.
+You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build doesn't execute evaluations or call a model. Evaluations are opt-in audit checks.
 
 ## Define a task file
 
-Save YAML or JSON with `schemaVersion: 1` and a nonempty `tasks` list. Each task needs a unique lowercase ID, a prompt, an `allowedTools` list, and criteria with unique IDs and descriptions. Tasks are required by default; set `required: false` for an exploratory task that should not block an audit.
+Save YAML or JSON with `schemaVersion: 1` and a nonempty `tasks` list. Each task needs a unique lowercase ID, a prompt, an `allowedTools` list, and criteria with unique IDs and descriptions. Tasks are required by default; set `required: false` for an exploratory task that shouldn't block an audit.
 
 ```yaml title="evals/tasks.yaml"
 schemaVersion: 1
@@ -42,6 +42,6 @@ tasks:
         description: Explain that published Markdown retains reader-marked content.
 ```
 
-Use the same tool names in your task file and runner report, such as `search`, `fetch`, `docs.search`, or `mcp.get_page`. Shoalrun validates the recorded runner tools against each executed task's allowed list. It cannot observe or enforce what tools an external agent actually used. Use a shared allowed tool set within a report; prepare separate suites for runs with different tool permissions.
+Use the same tool names in your task file and runner report, such as `search`, `fetch`, `docs.search`, or `mcp.get_page`. Shoalrun validates the recorded runner tools against each executed task's allowed list. It can't observe or enforce what tools an external agent actually used. Use a shared allowed tool set within a report; prepare separate suites for runs with different tool permissions.
 
 Write criteria that an expert can assess. Valid citations and complete report fields are mechanical checks. Whether the answer correctly explains your product remains a review judgment.

package/agent-docs/publish/evals.sections/diagnose-a-different-build.md

@@ -17,13 +17,13 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Evaluate agent tasks against your docs
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/evals.md)
 
-Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun does not launch agents, choose a model, or grade prose.
+Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun doesn't launch agents, choose a model, or grade prose.
 
-You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build does not execute evaluations or call a model. Evaluations are opt-in audit checks.
+You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build doesn't execute evaluations or call a model. Evaluations are opt-in audit checks.
 
 ## Diagnose a different build
 
@@ -37,6 +37,6 @@ shoalrun eval compare current-build.json --since evaluated-build.json
 
 The comparison lists added, changed, and removed file paths. It exits 0 for identical snapshots and 1 for differences or invalid input. Each inventory binds relative file paths and SHA-256 byte digests to the same build digest used by evaluation reports. It contains no answers or grades.
 
-New report templates include this inventory in `buildFiles`. When a report is stale, `eval check` includes the file comparison in `details.buildChanges`. Older reports still receive the exact-build check, but cannot identify which earlier files differ. Editing the stored digest or deleting changed files is not a new evaluation.
+New report templates include this inventory in `buildFiles`. When a report is stale, `eval check` includes the file comparison in `details.buildChanges`. Older reports still receive the exact-build check, but can't identify which earlier files differ. Editing the stored digest or deleting changed files isn't a new evaluation.
 
-For local review of a hosted build, download and retain that exact output, task file, and report template. Run the tasks against the downloaded site and check the completed report against it. Rebuilding the source on another operating system can change rendered assets; a report about the downloaded build does not automatically cover that rebuild. Archive the source revision and build inventory with the run. A successful build capture records no evaluation pass.
+For local review of a hosted build, download and retain that exact output, task file, and report template. Run the tasks against the downloaded site and check the completed report against it. Rebuilding the source on another operating system can change rendered assets; a report about the downloaded build doesn't automatically cover that rebuild. Archive the source revision and build inventory with the run. A successful build capture records no evaluation pass.

package/agent-docs/publish/evals.sections/prepare-a-report-for-the-built-site.md

@@ -17,13 +17,13 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Evaluate agent tasks against your docs
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/evals.md)
 
-Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun does not launch agents, choose a model, or grade prose.
+Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun doesn't launch agents, choose a model, or grade prose.
 
-You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build does not execute evaluations or call a model. Evaluations are opt-in audit checks.
+You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build doesn't execute evaluations or call a model. Evaluations are opt-in audit checks.
 
 ## Prepare a report for the built site
 
@@ -34,6 +34,6 @@ shoalrun eval prepare site-dist --tasks evals/tasks.yaml --out evals/results.jso
 
 Create the `evals` directory first. Preparation refuses to overwrite an existing report; use a new output filename for another run.
 
-The template contains a task-file digest, a documentation-build digest, a per-file `buildFiles` inventory, a timestamp, empty runner details, and each task marked `skipped`. It records no passing results and does not run the tasks. A template with skipped required tasks fails the check until you complete the run and review.
+The template contains a task-file digest, a documentation-build digest, a per-file `buildFiles` inventory, a timestamp, empty runner details, and each task marked `skipped`. It records no passing results and doesn't run the tasks. A template with skipped required tasks fails the check until you complete the run and review.
 
-The task digest uses normalized definitions, so whitespace-only changes do not invalidate a run. Prompt, criteria, tools, or required-status changes do. The build digest covers published output files, including HTML, Markdown, indexes, discovery, and assets. It excludes `build-info.json`, private `ai/` artifacts, and `.shoalrun/` state. File touches do not invalidate otherwise identical output; changed published bytes do. Other published metadata, including build IDs embedded in manifests, remains covered even when it reflects deployment provenance.
+The task digest uses normalized definitions, so whitespace-only changes don't invalidate a run. Prompt, criteria, tools, or required-status changes do. The build digest covers published output files, including HTML, Markdown, indexes, discovery, and assets. It excludes `build-info.json`, private `ai/` artifacts, and `.shoalrun/` state. File touches don't invalidate otherwise identical output; changed published bytes do. Other published metadata, including build IDs embedded in manifests, remains covered even when it reflects deployment provenance.

package/agent-docs/publish/evals.sections/related-reading.md

@@ -17,13 +17,13 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Evaluate agent tasks against your docs
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/evals.md)
 
-Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun does not launch agents, choose a model, or grade prose.
+Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun doesn't launch agents, choose a model, or grade prose.
 
-You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build does not execute evaluations or call a model. Evaluations are opt-in audit checks.
+You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build doesn't execute evaluations or call a model. Evaluations are opt-in audit checks.
 
 ## Related reading
 

package/agent-docs/publish/evals.sections/run-and-review-the-tasks.md

@@ -17,19 +17,19 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Evaluate agent tasks against your docs
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/evals.md)
 
-Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun does not launch agents, choose a model, or grade prose.
+Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun doesn't launch agents, choose a model, or grade prose.
 
-You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build does not execute evaluations or call a model. Evaluations are opt-in audit checks.
+You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build doesn't execute evaluations or call a model. Evaluations are opt-in audit checks.
 
 ## Run and review the tasks
 
 Use your own agent with the declared tool access. Record the actual runner name, optional model, available tools, and any limitations in `runner`. Replace `recordedAt` with the run's UTC ISO timestamp.
 
-For each task, record its status (`pass`, `fail`, or `skipped`), answer, citations, and criterion judgments. A passing result needs a nonempty answer, at least one citation, and a passing judgment with a reason for every defined criterion. Identify citations by stable page ID and publication, so editions and languages cannot be confused:
+For each task, record its status (`pass`, `fail`, or `skipped`), answer, citations, and criterion judgments. A passing result needs a nonempty answer, at least one citation, and a passing judgment with a reason for every defined criterion. Identify citations by stable page ID and publication, so editions and languages can't be confused:
 
 ```json
 {

package/agent-docs/publish/evals.sections/shoalrun-s-own-example.md

@@ -17,21 +17,21 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Evaluate agent tasks against your docs
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/evals.md)
 
-Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun does not launch agents, choose a model, or grade prose.
+Use evaluation tasks to check whether an agent can accomplish important work using your documentation. Shoalrun defines task and result formats, prepares report templates, and checks those reports during an audit. You run your own agent and arrange human or external review of its answers. Shoalrun doesn't launch agents, choose a model, or grade prose.
 
-You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build does not execute evaluations or call a model. Evaluations are opt-in audit checks.
+You need a built docs site, a few realistic tasks, and an agent or manual workflow for running them. The ordinary build doesn't execute evaluations or call a model. Evaluations are opt-in audit checks.
 
 ## Shoalrun's own example
 
-This repository retains `docs/evals/tasks.yaml` and `docs/evals/results.json` as an example of a small agent self-assessment. Its five questions cover custom search providers, search off, bounded lexical coverage, reader choices, and freshness. This narrow, familiar task set is not a general quality gate. The site's routine audit does not import the report, and ordinary documentation changes do not require rerunning it.
+This repository retains `docs/evals/tasks.yaml` and `docs/evals/results.json` as an example of a small agent self-assessment. Its five questions cover custom search providers, search off, bounded lexical coverage, reader choices, and freshness. This narrow, familiar task set isn't a general quality gate. The site's routine audit doesn't import the report, and ordinary documentation changes don't require rerunning it.
 
 The original October 1 report is preserved unchanged in `docs/evals/history/results-2026-10-01.json`. The October 15 local run retains its actual tool responses, new answers, self-review judgments, and exact-build inventory under `docs/evals/runs/2026-10-15-local/`. The evaluator knew the project and had seen the earlier report; tasks shared retrieved pages. These are historical observations, not blind or independent evidence of general agent reliability. Earlier exploratory results remain in `plans/documentation/agent-docs-eval.json`.
 
-Run a new evaluation when it answers a concrete product question, with relevant tasks and a clearly described runner and reviewer. Preserve older reports rather than changing their dates, digests, or grades. An exact-build report can legitimately fail freshness against a later build; that does not make its original evidence invalid or require routine refreshes.
+Run a new evaluation when it answers a concrete product question, with relevant tasks and a clearly described runner and reviewer. Preserve older reports rather than changing their dates, digests, or grades. An exact-build report can legitimately fail freshness against a later build; that doesn't make its original evidence invalid or require routine refreshes.
 
 Shoalrun's evaluation commands and optional audit hook remain available for projects that choose them. This site's normal validation still covers the build, links, schemas, output consistency, relevant behavior tests, and browser checks. To inspect the archived October 15 evidence without requiring the current site to match its old build, run from the repository root after compiling the framework:
 
@@ -39,4 +39,4 @@ Shoalrun's evaluation commands and optional audit hook remain available for proj
 node docs/evals/runs/2026-10-15-local/verify.mjs
 ```
 
-That command checks the recorded responses and report provenance; it does not rerun tasks, grade answers, or certify the current site.
+That command checks the recorded responses and report provenance; it doesn't rerun tasks, grade answers, or certify the current site.

package/agent-docs/publish/host-adapters.md

@@ -16,9 +16,9 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Add Shoalrun to another build or host
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
-Shoalrun builds a complete static site without a host framework. To include its pages in another build system, run Shoalrun's CLI as a build step. Then copy the generated files into the host's output. The host does not need to parse Shoalrun's MDX or OpenAPI sources.
+Shoalrun builds a complete static site without a host framework. To include its pages in another build system, run Shoalrun's CLI as a build step. Then copy the generated files into the host's output. The host doesn't need to parse Shoalrun's MDX or OpenAPI sources.
 
 ```sh
 shoalrun build docs.config.yaml ./shoalrun-dist
@@ -35,17 +35,17 @@ With the command above, the public subtree for `/docs` is `shoalrun-dist/docs/`.
 An adapter for Astro, another site builder, or a deployment platform can follow these steps:
 
 1. Run `shoalrun build <config> <temporary-output>` after the host has generated its own files.
-2. Enumerate both output trees and fail if a Shoalrun file would replace a host file. Also fail if a file occupies a directory the other tree needs. Compare paths without regard to case so a build that works on one filesystem does not overwrite files on another.
-3. Copy the Shoalrun files into the host output, keeping their paths. Do not modify the generated HTML or Markdown: both came from the same content build.
+2. Enumerate both output trees and fail if a Shoalrun file would replace a host file. Also fail if a file occupies a directory the other tree needs. Compare paths without regard to case so a build that works on one filesystem doesn't overwrite files on another.
+3. Copy the Shoalrun files into the host output, keeping their paths. Don't modify the generated HTML or Markdown: both came from the same content build.
 4. Configure the host's routing and response headers as described below. Run the [post-deploy checker](https://www.shoalrun.com/publish/deployment-check.md) against the published URL.
 
 The generated `documents.json` lists every page's HTML and Markdown URLs. `redirects.json` records redirects, and `resource-headers.json` records content types for Markdown and discovery resources. It also records `Content-Security-Policy: sandbox` and `X-Content-Type-Options: nosniff` for generated and local SVG files. Apply those headers when hosting SVGs; the Node server and Vercel adapter do this automatically. `/llms.txt`, `search-index.json`, API contracts, images, styles, and scripts are ordinary output files. The [output guide](https://www.shoalrun.com/publish/output.md) lists their paths.
 
 ## Supply HTTP behavior
 
-Copying files does not make a static host negotiate Markdown at an HTML URL or apply redirects and special content types. Use the [content negotiation contract](https://www.shoalrun.com/publish/content-negotiation.md) to configure those rules. A host that cannot inspect request headers can still serve the direct `.md` URLs, but cannot provide the negotiated response. Shoalrun's [Node server](https://www.shoalrun.com/cli.md) handles these rules; the [Vercel build](https://www.shoalrun.com/publish/vercel.md) generates a deployable configuration for that host.
+Copying files doesn't make a static host negotiate Markdown at an HTML URL or apply redirects and special content types. Use the [content negotiation contract](https://www.shoalrun.com/publish/content-negotiation.md) to configure those rules. A host that can't inspect request headers can still serve the direct `.md` URLs, but can't provide the negotiated response. Shoalrun's [Node server](https://www.shoalrun.com/cli.md) handles these rules; the [Vercel build](https://www.shoalrun.com/publish/vercel.md) generates a deployable configuration for that host.
 
-Keep the adapter small: Shoalrun owns content compilation and the generated files, while the host owns request handling. A JavaScript plugin API is not required to call the CLI or publish its output.
+Keep the adapter small: Shoalrun owns content compilation and the generated files, while the host owns request handling. A JavaScript plugin API isn't required to call the CLI or publish its output.
 
 ## Related reading
 

package/agent-docs/publish/manni.md

@@ -16,7 +16,7 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Use Manni with Shoalrun
 
-**Updated: 2026-10-25.**
+**Updated: 2026-11-05.**
 
 [Manni](https://hawkeyexl.github.io/manni/) is a toolkit for managing and checking documentation. It can validate, query, and help fill page information; manage terminology; track connections between explanations and source code; and build knowledge graphs. It also provides tools for testing documentation and running evaluations.
 
@@ -31,7 +31,7 @@ Shoalrun builds and delivers your docs. Here, we use Manni to add checks before
 
 This guide shows how to run Manni in a Shoalrun project and add a check to `shoalrun audit`. That command runs the checks you configure and reports whether they passed. Start with one useful rule, then add more when you need them. For a working example, see [how we use Manni on this site](#how-this-site-uses-manni).
 
-Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you do not need a separate Shoalrun setting for each Manni feature.
+Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you don't need a separate Shoalrun setting for each Manni feature.
 
 ## Prerequisites
 
@@ -93,7 +93,7 @@ Start in a Shoalrun project's root, with its package manifest and a `docs/` dire
 
    Arguments, standard input, output, and exit status pass through to Manni. Every command runs from `docs/`, so input paths and explicit config paths are relative to that directory. Manni's normal config discovery and `--config` option remain available. The launcher adds no default command, target, or flags.
 
-   The script also works when Shoalrun validates a temporary copy of your docs. Missing tools produce an error and an installation message. The launcher itself does not install tools.
+   The script also works when Shoalrun validates a temporary copy of your docs. Missing tools produce an error and an installation message. The launcher itself doesn't install tools.
 
 3. ## Choose your documents and schemas
 
@@ -110,13 +110,13 @@ Start in a Shoalrun project's root, with its package manifest and a `docs/` dire
 
    The collection identifies your source pages, including drafts. `meta.defaults: false` applies only the schemas you select. Choose schemas using `meta schemas` and inspect their requirements with `meta schemas show` before enabling them. Each schema retains its own rules; schemas for another site generator may not fit Shoalrun content.
 
-   The core schema requires nonempty `title` and `description` fields. Shoalrun's required `summary` does not substitute for `description`. If you choose this vocabulary, add a meaningful `description` to each page's existing frontmatter:
+   The core schema requires nonempty `title` and `description` fields. Shoalrun's required `summary` doesn't substitute for `description`. If you choose this vocabulary, add a meaningful `description` to each page's existing frontmatter:
 
    ```yaml
    description: Create an API key and choose the permissions your application needs.
    ```
 
-   These metadata checks read the YAML header at the top of each Markdown or MDX source file. Put required values there: Manni does not see values Shoalrun adds later from defaults or a metadata provider. See [metadata customization](https://www.shoalrun.com/author/custom-metadata.md) for how Shoalrun combines those values.
+   These metadata checks read the YAML header at the top of each Markdown or MDX source file. Put required values there: Manni doesn't see values Shoalrun adds later from defaults or a metadata provider. See [metadata customization](https://www.shoalrun.com/author/custom-metadata.md) for how Shoalrun combines those values.
 
 4. ## Run Manni's native tools
 
@@ -130,7 +130,7 @@ Start in a Shoalrun project's root, with its package manifest and a `docs/` dire
 
    `meta validate` checks your selected metadata schemas. `status` explains which tools are configured. `check` runs Manni's configured checks; adding configuration or relevant page metadata can expand that set.
 
-   The launcher accepts any native command provided by the installed Manni version. Configure terminology, citations, structural checks, and other tools using [Manni's documentation](https://hawkeyexl.github.io/manni/). Each tool retains its native installation, metadata, and execution requirements. Access to the CLI does not activate those tools automatically.
+   The launcher accepts any native command provided by the installed Manni version. Configure terminology, citations, structural checks, and other tools using [Manni's documentation](https://hawkeyexl.github.io/manni/). Each tool retains its native installation, metadata, and execution requirements. Access to the CLI doesn't activate those tools automatically.
 
 5. ## Connect a selected check to Shoalrun
 
@@ -148,7 +148,7 @@ Start in a Shoalrun project's root, with its package manifest and a `docs/` dire
            - ../package-lock.json
    ```
 
-   Commands run from the directory containing `docs.config.yaml`. The declared inputs are captured for isolated validation; changes to configuration or package pins make earlier validation evidence stale. Include local schema files in `inputs` if you add them. The command does not depend on generated `.shoalrun` files or a previous website build.
+   Commands run from the directory containing `docs.config.yaml`. The declared inputs are captured for isolated validation; changes to configuration or package pins make earlier validation evidence stale. Include local schema files in `inputs` if you add them. The command doesn't depend on generated `.shoalrun` files or a previous website build.
 
    Run the project audit from the project root:
 
@@ -165,19 +165,19 @@ Start in a Shoalrun project's root, with its package manifest and a `docs/` dire
      --baseline .shoalrun/manni-baseline.json --run-checks
    ```
 
-   Inspect the report's `test:manni-meta` result. A skipped, unavailable, or failed check is not a pass. This explicit audit command stays on metadata validation when you configure additional Manni tools. You can choose `check` as a broader project gate after reviewing its scope.
+   Inspect the report's `test:manni-meta` result. A skipped, unavailable, or failed check isn't a pass. This explicit audit command stays on metadata validation when you configure additional Manni tools. You can choose `check` as a broader project gate after reviewing its scope.
 
-   Isolated validation captures source and declared inputs. It does not provide full Git history, a running application, a browser, or a model execution setup. Run tools needing those resources in a project workflow with that context. Source-writing commands are explicit author actions; review their changes before accepting them.
+   Isolated validation captures source and declared inputs. It doesn't provide full Git history, a running application, a browser, or a model execution setup. Run tools needing those resources in a project workflow with that context. Source-writing commands are explicit author actions; review their changes before accepting them.
 
 ## Check the result
 
-With the core schema selected, a page with `title` and `description` passes those required-field checks. A temporary draft missing `description` should fail with a diagnostic naming the field. Restore the description or remove the fixture after checking the failure path. Metadata validation does not rewrite source files.
+With the core schema selected, a page with `title` and `description` passes those required-field checks. A temporary draft missing `description` should fail with a diagnostic naming the field. Restore the description or remove the fixture after checking the failure path. Metadata validation doesn't rewrite source files.
 
 ## How this site uses Manni
 
-Here are some ways we use Manni to check the docs you are reading. You can adopt the examples that suit your project.
+Here are some ways we use Manni to check the docs you're reading. You can adopt the examples that suit your project.
 
-**Catch broken glossary references.** Some pages list the glossary terms they discuss, such as “facet” or “reader view.” If an author types “reader veiw” in that list, the check fails because no such term exists. We check those lists against the [glossary](https://www.shoalrun.com/glossary.md), using its existing definitions. This does not check every word in the prose.
+**Catch broken glossary references.** Some pages list the glossary terms they discuss, such as “facet” or “reader view.” If an author types “reader veiw” in that list, the check fails because no such term exists. We check those lists against the [glossary](https://www.shoalrun.com/glossary.md), using its existing definitions. This doesn't check every word in the prose.
 
 **Keep instructions complete.** On this page and the [content export guide](https://www.shoalrun.com/publish/content-export.md), we require prerequisites, named steps with instructions, and a final result check. The [getting-started tutorial](https://www.shoalrun.com/start.md) must cover setup, creating a page, navigation, and checking both outputs. Two common problems in [troubleshooting](https://www.shoalrun.com/publish/troubleshooting.md) must explain their cause and what to do. Removing one of those required sections makes the check fail.
 
@@ -210,7 +210,7 @@ npm run docs:build
 npm run docs:a11y
 ```
 
-The scan starts a temporary local server and checks every HTML page named in `documents.json`, including pages without navigation links. It fails on detected violations, skipped pages, or incomplete coverage. It reuses the built files and does not run another build. You can select another built directory with `SHOALRUN_BUILT_SITE`.
+The scan starts a temporary local server and checks every HTML page named in `documents.json`, including pages without navigation links. It fails on detected violations, skipped pages, or incomplete coverage. It reuses the built files and doesn't run another build. You can select another built directory with `SHOALRUN_BUILT_SITE`.
 
 To check the connection between our metadata guide and its implementation, provide a framework source checkout. Replace `/path/to/shoalrun` with its location:
 
@@ -218,10 +218,10 @@ To check the connection between our metadata guide and its implementation, provi
 npm run docs:citations -- --repo framework=/path/to/shoalrun
 ```
 
-The citation record is kept outside the published page. Review changes to the explanation and code before updating that record. It identifies the source version reviewed; it does not replace testing the installed Shoalrun package.
+The citation record is kept outside the published page. Review changes to the explanation and code before updating that record. It identifies the source version reviewed; it doesn't replace testing the installed Shoalrun package.
 
 ## Optional custom policies
 
-You can add your own rules as a local JSON Schema in `meta.schemas`. For example, if a page records a review date, you might require a note explaining what was reviewed. Those fields and rules belong to your project; Manni does not require them.
+You can add your own rules as a local JSON Schema in `meta.schemas`. For example, if a page records a review date, you might require a note explaining what was reviewed. Those fields and rules belong to your project; Manni doesn't require them.
 
-Keep simple required-field, type, and enum rules in [Shoalrun's field declarations](https://www.shoalrun.com/author/custom-metadata.md). Add a custom Manni schema when you need conditional rules, and include that schema in the audit's captured inputs. A recorded verification date and note establish a metadata contract; they do not prove accuracy or freshness.
+Keep simple required-field, type, and enum rules in [Shoalrun's field declarations](https://www.shoalrun.com/author/custom-metadata.md). Add a custom Manni schema when you need conditional rules, and include that schema in the audit's captured inputs. A recorded verification date and note establish a metadata contract; they don't prove accuracy or freshness.

package/agent-docs/publish/manni.sections/check-the-result.md

@@ -16,7 +16,7 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Use Manni with Shoalrun
 
-**Updated: 2026-10-25.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/manni.md)
 
@@ -33,8 +33,8 @@ Shoalrun builds and delivers your docs. Here, we use Manni to add checks before
 
 This guide shows how to run Manni in a Shoalrun project and add a check to `shoalrun audit`. That command runs the checks you configure and reports whether they passed. Start with one useful rule, then add more when you need them. For a working example, see [how we use Manni on this site](https://www.shoalrun.com/publish/manni.md#how-this-site-uses-manni).
 
-Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you do not need a separate Shoalrun setting for each Manni feature.
+Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you don't need a separate Shoalrun setting for each Manni feature.
 
 ## Check the result
 
-With the core schema selected, a page with `title` and `description` passes those required-field checks. A temporary draft missing `description` should fail with a diagnostic naming the field. Restore the description or remove the fixture after checking the failure path. Metadata validation does not rewrite source files.
+With the core schema selected, a page with `title` and `description` passes those required-field checks. A temporary draft missing `description` should fail with a diagnostic naming the field. Restore the description or remove the fixture after checking the failure path. Metadata validation doesn't rewrite source files.

package/agent-docs/publish/manni.sections/how-this-site-uses-manni.md

@@ -16,7 +16,7 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Use Manni with Shoalrun
 
-**Updated: 2026-10-25.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/manni.md)
 
@@ -33,13 +33,13 @@ Shoalrun builds and delivers your docs. Here, we use Manni to add checks before
 
 This guide shows how to run Manni in a Shoalrun project and add a check to `shoalrun audit`. That command runs the checks you configure and reports whether they passed. Start with one useful rule, then add more when you need them. For a working example, see [how we use Manni on this site](https://www.shoalrun.com/publish/manni.md#how-this-site-uses-manni).
 
-Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you do not need a separate Shoalrun setting for each Manni feature.
+Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you don't need a separate Shoalrun setting for each Manni feature.
 
 ## How this site uses Manni
 
-Here are some ways we use Manni to check the docs you are reading. You can adopt the examples that suit your project.
+Here are some ways we use Manni to check the docs you're reading. You can adopt the examples that suit your project.
 
-**Catch broken glossary references.** Some pages list the glossary terms they discuss, such as “facet” or “reader view.” If an author types “reader veiw” in that list, the check fails because no such term exists. We check those lists against the [glossary](https://www.shoalrun.com/glossary.md), using its existing definitions. This does not check every word in the prose.
+**Catch broken glossary references.** Some pages list the glossary terms they discuss, such as “facet” or “reader view.” If an author types “reader veiw” in that list, the check fails because no such term exists. We check those lists against the [glossary](https://www.shoalrun.com/glossary.md), using its existing definitions. This doesn't check every word in the prose.
 
 **Keep instructions complete.** On this page and the [content export guide](https://www.shoalrun.com/publish/content-export.md), we require prerequisites, named steps with instructions, and a final result check. The [getting-started tutorial](https://www.shoalrun.com/start.md) must cover setup, creating a page, navigation, and checking both outputs. Two common problems in [troubleshooting](https://www.shoalrun.com/publish/troubleshooting.md) must explain their cause and what to do. Removing one of those required sections makes the check fail.
 
@@ -72,7 +72,7 @@ npm run docs:build
 npm run docs:a11y
 ```
 
-The scan starts a temporary local server and checks every HTML page named in `documents.json`, including pages without navigation links. It fails on detected violations, skipped pages, or incomplete coverage. It reuses the built files and does not run another build. You can select another built directory with `SHOALRUN_BUILT_SITE`.
+The scan starts a temporary local server and checks every HTML page named in `documents.json`, including pages without navigation links. It fails on detected violations, skipped pages, or incomplete coverage. It reuses the built files and doesn't run another build. You can select another built directory with `SHOALRUN_BUILT_SITE`.
 
 To check the connection between our metadata guide and its implementation, provide a framework source checkout. Replace `/path/to/shoalrun` with its location:
 
@@ -80,4 +80,4 @@ To check the connection between our metadata guide and its implementation, provi
 npm run docs:citations -- --repo framework=/path/to/shoalrun
 ```
 
-The citation record is kept outside the published page. Review changes to the explanation and code before updating that record. It identifies the source version reviewed; it does not replace testing the installed Shoalrun package.
+The citation record is kept outside the published page. Review changes to the explanation and code before updating that record. It identifies the source version reviewed; it doesn't replace testing the installed Shoalrun package.

package/agent-docs/publish/manni.sections/optional-custom-policies.md

@@ -16,7 +16,7 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Use Manni with Shoalrun
 
-**Updated: 2026-10-25.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/manni.md)
 
@@ -33,10 +33,10 @@ Shoalrun builds and delivers your docs. Here, we use Manni to add checks before
 
 This guide shows how to run Manni in a Shoalrun project and add a check to `shoalrun audit`. That command runs the checks you configure and reports whether they passed. Start with one useful rule, then add more when you need them. For a working example, see [how we use Manni on this site](https://www.shoalrun.com/publish/manni.md#how-this-site-uses-manni).
 
-Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you do not need a separate Shoalrun setting for each Manni feature.
+Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you don't need a separate Shoalrun setting for each Manni feature.
 
 ## Optional custom policies
 
-You can add your own rules as a local JSON Schema in `meta.schemas`. For example, if a page records a review date, you might require a note explaining what was reviewed. Those fields and rules belong to your project; Manni does not require them.
+You can add your own rules as a local JSON Schema in `meta.schemas`. For example, if a page records a review date, you might require a note explaining what was reviewed. Those fields and rules belong to your project; Manni doesn't require them.
 
-Keep simple required-field, type, and enum rules in [Shoalrun's field declarations](https://www.shoalrun.com/author/custom-metadata.md). Add a custom Manni schema when you need conditional rules, and include that schema in the audit's captured inputs. A recorded verification date and note establish a metadata contract; they do not prove accuracy or freshness.
+Keep simple required-field, type, and enum rules in [Shoalrun's field declarations](https://www.shoalrun.com/author/custom-metadata.md). Add a custom Manni schema when you need conditional rules, and include that schema in the audit's captured inputs. A recorded verification date and note establish a metadata contract; they don't prove accuracy or freshness.

package/agent-docs/publish/manni.sections/prerequisites.md

@@ -16,7 +16,7 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Publish and maintain > Use Manni with Shoalrun
 
-**Updated: 2026-10-25.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/manni.md)
 
@@ -33,7 +33,7 @@ Shoalrun builds and delivers your docs. Here, we use Manni to add checks before
 
 This guide shows how to run Manni in a Shoalrun project and add a check to `shoalrun audit`. That command runs the checks you configure and reports whether they passed. Start with one useful rule, then add more when you need them. For a working example, see [how we use Manni on this site](https://www.shoalrun.com/publish/manni.md#how-this-site-uses-manni).
 
-Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you do not need a separate Shoalrun setting for each Manni feature.
+Manni's [documentation site](https://hawkeyexl.github.io/manni/) describes its available tools and rules. Your choices go in `manni.config.yaml`; you don't need a separate Shoalrun setting for each Manni feature.
 
 ## Prerequisites
 

package/agent-docs/publish/mcp-analytics.md

@@ -17,15 +17,15 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Search, chat, and agent access > MCP > Measure MCP tool usage
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
-Add a server adapter to measure calls to your [HTTP MCP endpoint](https://www.shoalrun.com/publish/mcp.md). Analytics is off by default. Enabling MCP does not enable tracking, and the browser analytics setting does not count tool calls.
+Add a server adapter to measure calls to your [HTTP MCP endpoint](https://www.shoalrun.com/publish/mcp.md). Analytics is off by default. Enabling MCP doesn't enable tracking, and the browser analytics setting doesn't count tool calls.
 
-Your adapter chooses the service and sends the events. Shoalrun packages it for Node or the generated Vercel function. This setting does not instrument stdio, direct Markdown requests, or browser page views.
+Your adapter chooses the service and sends the events. Shoalrun packages it for Node or the generated Vercel function. This setting doesn't instrument stdio, direct Markdown requests, or browser page views.
 
 ## Enable analytics
 
-Add your server adapter to the MCP configuration. Readers do not need to change their client settings:
+Add your server adapter to the MCP configuration. Readers don't need to change their client settings:
 
 ```yaml title="docs.config.yaml"
 mcp:
@@ -50,7 +50,7 @@ export async function flush() {
 }
 ```
 
-`capture` runs after each tool call, including failures. `flush` sends queued events before the response completes. Both can be asynchronous. Each has a one-second wait limit; analytics failures leave tool results unchanged. Set network timeouts in your adapter because Shoalrun cannot cancel a timed-out operation.
+`capture` runs after each tool call, including failures. `flush` sends queued events before the response completes. Both can be asynchronous. Each has a one-second wait limit; analytics failures leave tool results unchanged. Set network timeouts in your adapter because Shoalrun can't cancel a timed-out operation.
 
 Module paths resolve relative to the config file. Use static imports and install SDK dependencies in your project. Keep credentials in the server environment, since adapter files are copied into the build.
 
@@ -73,7 +73,7 @@ Every event has the following fields. Arguments, search text, returned content,
 
 Map these fields to your service’s event and property names. A service with native MCP analytics may require its SDK or reserved event names. A general event service can receive `mcp_tool_call` with these properties. The PostHog example below uses its native MCP SDK.
 
-Tool counts show usage, not comprehension. This adapter supplies no user or conversation identifier, so do not treat calls as unique people or agent sessions. Basic event capture leaves tool definitions and results unchanged. The optional SDK features below add analytics arguments and conversation handles.
+Tool counts show usage, not comprehension. This adapter supplies no user or conversation identifier, so don't treat calls as unique people or agent sessions. Basic event capture leaves tool definitions and results unchanged. The optional SDK features below add analytics arguments and conversation handles.
 
 ## Optionally identify the client and model
 
@@ -91,11 +91,11 @@ mcp:
 
 This option defaults to `false`. Shoalrun recognizes a fixed set of client names from MCP identity metadata or product tokens in selected headers. It discards raw headers and unrelated metadata. Client versions must match a bounded numeric version format.
 
-Model capture currently recognizes `model` in Codex’s `x-codex-turn-metadata`. It accepts labels from a fixed model-name registry, normalizes supported provider prefixes, and drops other values. A recognized family prefix alone does not qualify; custom deployment names and unknown models are omitted. Other clients may supply no supported model field; missing labels remain absent. The harness name does not establish which model it uses.
+Model capture currently recognizes `model` in Codex’s `x-codex-turn-metadata`. It accepts labels from a fixed model-name registry, normalizes supported provider prefixes, and drops other values. A recognized family prefix alone doesn't qualify; custom deployment names and unknown models are omitted. Other clients may supply no supported model field; missing labels remain absent. The harness name doesn't establish which model it uses.
 
 Both labels are unverified client claims. Use them for usage reports, never authentication, access control, or billing. No user fingerprint or cross-request identity cache is added.
 
-OpenCode can also be recognized by the presence of its documented session metadata marker. Shoalrun discards that identifier; it records only the client label. Client-specific markers do not establish the model.
+OpenCode can also be recognized by the presence of its documented session metadata marker. Shoalrun discards that identifier; it records only the client label. Client-specific markers don't establish the model.
 
 ## Optionally collect intent and group calls
 
@@ -115,7 +115,7 @@ mcp:
 
 With intent enabled, the SDK adds a `context` argument asking for exactly one category: `discovery`, `setup`, `troubleshooting`, `configuration`, `reference_lookup`, `comparison`, `migration`, or `other`. Only these values can reach analytics. The adapter trims whitespace and normalizes case; it never stores an explanation or extracts a category from arbitrary text.
 
-An empty, invalid, or free-text value falls back to `discovery` for `search_docs` or `reference_lookup` for reading tools. PostHog marks the fallback as `inferred`. It describes the tool action, not a verified user goal, and does not invoke a model. Accepted client categories are also unverified claims.
+An empty, invalid, or free-text value falls back to `discovery` for `search_docs` or `reference_lookup` for reading tools. PostHog marks the fallback as `inferred`. It describes the tool action, not a verified user goal, and doesn't invoke a model. Accepted client categories are also unverified claims.
 
 The SDK still accepts a string argument, so an agent might send private text despite the instruction. The outbound allowlist replaces that text before delivery. Raw queries, complete arguments, and returned documentation remain excluded.
 
@@ -135,11 +135,11 @@ The PostHog example builds each outbound event from allowed fields. It includes
 
 The adapter drops raw arguments, search text, responses, headers, IP properties, error messages, and arbitrary event fields. It disables exception autocapture, requests no person profiles, and disables GeoIP enrichment. These controls apply to analytics delivery, not the documentation response or infrastructure access logs.
 
-Conversation and session IDs support grouping when enabled. They are pseudonymous identifiers, not proof that data is anonymous or that a particular person made the call. Leave grouping off when aggregate tool counts are enough. Never use client labels or intent categories for authentication or billing.
+Conversation and session IDs support grouping when enabled. They're pseudonymous identifiers, not proof that data is anonymous or that a particular person made the call. Leave grouping off when aggregate tool counts are enough. Never use client labels or intent categories for authentication or billing.
 
 Check PostHog’s **Settings → Project → IP data capture configuration → Discard client IP data** setting as an additional storage control. A network service still receives the source IP of its connection; this server adapter must not forward the caller’s IP. Hosting logs and other services need their own review. See [PostHog storage controls](https://posthog.com/docs/privacy/data-storage).
 
-Test the final delivered payload with a local receiver before changing the adapter or upgrading its SDK. Include names, emails, credentials, URLs, and private text in test arguments and metadata; verify they are absent from captured events. Public page IDs remain useful for usage analysis without recording the agent’s search or explanation. These safeguards do not establish a legal basis for collection or guarantee that all infrastructure stores no personal data.
+Test the final delivered payload with a local receiver before changing the adapter or upgrading its SDK. Include names, emails, credentials, URLs, and private text in test arguments and metadata; verify they're absent from captured events. Public page IDs remain useful for usage analysis without recording the agent’s search or explanation. These safeguards don't establish a legal basis for collection or guarantee that all infrastructure stores no personal data.
 
 ## Example: PostHog MCP analytics
 
@@ -341,7 +341,7 @@ This example sends native `$mcp_tool_call` events through [PostHog’s MCP analy
 
    Rebuild and serve the site, or generate its Vercel output as described in the [MCP guide](https://www.shoalrun.com/publish/mcp.md). Connect a client and call `get_page` for a known ID. In PostHog’s activity feed, filter for `$mcp_tool_call`; inspect the tool name, duration, outcome, and `page_id`.
 
-   You can test on localhost with a development project or a local ingestion receiver. Without identity or conversation tracking, this example does not correlate requests into agent sessions. With basic capture, no prompts or tools are added. When client metadata is available, inspect `$mcp_client_name` and `$mcp_llm_model`; their source and verification properties identify them as claims.
+   You can test on localhost with a development project or a local ingestion receiver. Without identity or conversation tracking, this example doesn't correlate requests into agent sessions. With basic capture, no prompts or tools are added. When client metadata is available, inspect `$mcp_client_name` and `$mcp_llm_model`; their source and verification properties identify them as claims.
 
    To stop collection, remove `mcp.analytics` or set it to `false`, rebuild, and restart the serving process or redeploy.
 

package/agent-docs/publish/mcp-analytics.sections/adapter-exports.md

@@ -17,7 +17,7 @@ Navigation section: [Docs](https://www.shoalrun.com/.well-known/shoalrun/navigat
 
 Breadcrumbs: [Docs](https://www.shoalrun.com/what-is-shoalrun.md) > Search, chat, and agent access > MCP > Measure MCP tool usage
 
-**Updated: 2026-10-26.**
+**Updated: 2026-11-05.**
 
 Parent page: [Full Markdown page](/publish/mcp-analytics.md)
 
@@ -27,9 +27,9 @@ Parent page: [Full Markdown page](/publish/mcp-analytics.md)
 
 - [Connect an MCP client](https://www.shoalrun.com/publish/mcp.md) — Enable and verify the HTTP endpoint before adding analytics.
 
-Add a server adapter to measure calls to your [HTTP MCP endpoint](https://www.shoalrun.com/publish/mcp.md). Analytics is off by default. Enabling MCP does not enable tracking, and the browser analytics setting does not count tool calls.
+Add a server adapter to measure calls to your [HTTP MCP endpoint](https://www.shoalrun.com/publish/mcp.md). Analytics is off by default. Enabling MCP doesn't enable tracking, and the browser analytics setting doesn't count tool calls.
 
-Your adapter chooses the service and sends the events. Shoalrun packages it for Node or the generated Vercel function. This setting does not instrument stdio, direct Markdown requests, or browser page views.
+Your adapter chooses the service and sends the events. Shoalrun packages it for Node or the generated Vercel function. This setting doesn't instrument stdio, direct Markdown requests, or browser page views.
 
 ## Adapter exports
 
@@ -45,6 +45,6 @@ export async function flush() {
 }
 ```
 
-`capture` runs after each tool call, including failures. `flush` sends queued events before the response completes. Both can be asynchronous. Each has a one-second wait limit; analytics failures leave tool results unchanged. Set network timeouts in your adapter because Shoalrun cannot cancel a timed-out operation.
+`capture` runs after each tool call, including failures. `flush` sends queued events before the response completes. Both can be asynchronous. Each has a one-second wait limit; analytics failures leave tool results unchanged. Set network timeouts in your adapter because Shoalrun can't cancel a timed-out operation.
 
 Module paths resolve relative to the config file. Use static imports and install SDK dependencies in your project. Keep credentials in the server environment, since adapter files are copied into the build.