@cerefox/memory 1.17.1 → 1.17.3

package/docs/guides/connect-agents.md

@@ -53,7 +53,7 @@ Three top-level paths plus a few special cases:
 > ChatGPT becomes possible on the same server but is not yet documented.)
 
 > **Perplexity** supports stdio-only MCP on macOS Desktop (via Helper App). Remote MCP is
-> "coming soon." Perplexity's CTO has signalled a strategic shift away from MCP (March 2026),
+> "coming soon." Perplexity's CTO has signaled a strategic shift away from MCP (March 2026),
 > so API-based integration may be the long-term path. Not a priority.
 >
 > **Gemini web** (gemini.google.com) does not support custom MCP servers. No integration path.
@@ -174,7 +174,7 @@ set — as it is for a [staging environment](staging-env.md) — the name become
 entry rather than replacing it, and an agent can hold both at once (v1.4.0, #168).
 The command prints the name it used.
 
-A labelled entry additionally carries `CEREFOX_CONFIG_DIR` and `CEREFOX_ENV_LABEL`
+A labeled entry additionally carries `CEREFOX_CONFIG_DIR` and `CEREFOX_ENV_LABEL`
 in its `env` block. That is what makes it actually reach the environment it is named
 after: MCP clients spawn a stdio server with the **client's** environment, not the
 shell you ran `configure-agent` in, and a desktop client launched from the dock has
@@ -344,7 +344,7 @@ https://<your-project-ref>.supabase.co/functions/v1/cerefox-mcp
 |----------|--------|
 | Default local agent (Claude Code, Cursor, Codex, Gemini, Claude Desktop) | Path A-Local -- preferred; `cerefox configure-agent`, zero Edge Function cost, no token to distribute |
 | Multiple machines / cloud dev environments | Path A-Remote -- one hosted URL works everywhere (needs a Cerefox token) |
-| Minimise Supabase Edge Function usage (free tier limits) | Path A-Local -- zero Edge Function invocations |
+| Minimize Supabase Edge Function usage (free tier limits) | Path A-Local -- zero Edge Function invocations |
 | Offline use or development on the cerefox codebase | Path A-Local -- no network dependency |
 | Lowest latency (same machine, no HTTPS round-trip) | Path A-Local -- slightly faster |
 

package/docs/guides/ops-scripts.md

@@ -277,7 +277,7 @@ it is off the field is absent from every other surface, and an export is not the
 place to resurrect it.
 
 Markdown rather than JSON so the sidecars are readable in the same editor as the
-documents. Pass `--no-metadata` for the older content-only behaviour.
+documents. Pass `--no-metadata` for the older content-only behavior.
 
 Two naming details worth knowing:
 
@@ -320,7 +320,7 @@ Two things worth knowing about what it does *not* claim:
 
 - **Coverage is stated, not implied.** `x-cerefox-coverage` in the document lists
   how many routes carry a response schema, which routes legitimately return
-  something other than JSON, and which are unmodelled. An unmodelled route gets
+  something other than JSON, and which are unmodeled. An unmodeled route gets
   **no** schema rather than a guessed one.
 - **`info.version` is the API's, not the release's.** It moves when `/api/v1`
   changes. Binding it to the package version made the committed artifact stale at
@@ -329,7 +329,7 @@ Two things worth knowing about what it does *not* claim:
 
 ## search_benchmark.ts — Search-calibration benchmark
 
-Measures how search ranks against a labelled query vocabulary
+Measures how search ranks against a labeled query vocabulary
 (`_shared/search-benchmark/vocabulary/`: a synthetic corpus, about 150 queries
 in 13 categories, variant groups, no-answer queries) and compares alternative
 scoring formulas and settings. It is how the v1.17.0 defaults were chosen. Design

package/docs/guides/response-limits.md

@@ -19,13 +19,13 @@ raises or lowers it per call with `--max-bytes`.
 > **Changed in v0.10.2.** The CLI originally returned everything, like the web UI. It now
 > honours `CEREFOX_MAX_RESPONSE_BYTES` (200 000 default) and prints
 > `(results truncated at N bytes; use --max-bytes to raise)` when results are dropped.
-> This guide described the pre-v0.10.2 behaviour until v1.14.4.
+> This guide described the pre-v0.10.2 behavior until v1.14.4.
 
 ---
 
 ## How each access path handles response size
 
-| Path | Limit behaviour |
+| Path | Limit behavior |
 |------|----------------|
 | Web UI (`/search`) | **No limit** — all results returned |
 | CLI (`cerefox search`) | Defaults to `CEREFOX_MAX_RESPONSE_BYTES` (200 000); raise or lower per call with `--max-bytes`. Announces truncation. |
@@ -203,4 +203,4 @@ threshold (it is a SQL DEFAULT in `rpcs.sql`, changed via `cerefox server deploy
 | Can an agent exceed the server ceiling? | No — always capped |
 | Where is the ceiling configured? | `.env` for local MCP; TypeScript constant in Edge Functions |
 | How are limits applied? | Whole-document drop; never mid-content truncation |
-| Is truncation signalled? | Yes — `truncated: true` in responses |
+| Is truncation signaled? | Yes — `truncated: true` in responses |

package/docs/guides/staging-env.md

@@ -30,7 +30,7 @@ Three things, and the third turned out to matter most:
   every legacy document (real spend, rewrites chunks). Proving it on a copy
   first turns an act of faith into a measurement.
 - **Development.** A store you are willing to break is the cheapest way to turn
-  a claim about runtime behaviour into a measurement. During the 1.1.0 cycle this
+  a claim about runtime behavior into a measurement. During the 1.1.0 cycle this
   found a retry loop executing 68,825 times per request, a `migrate-format` that
   reported success while converting nothing, and a `backup create` that failed
   against older servers — none visible from the code or the test suite. Keep it
@@ -276,7 +276,7 @@ read but nothing acts on it.
 
 | Area | Problem |
 |---|---|
-| **Agent (MCP) config** | Safe since v1.4.0 ([#168](https://github.com/fstamatelopoulos/cerefox/issues/168)). `configure-agent` names the server after `CEREFOX_ENV_LABEL`, so a staging environment registers as **`cerefox-staging`** alongside your production `cerefox` entry rather than replacing it, and an agent can hold both. The labelled entry also carries its own `CEREFOX_CONFIG_DIR` and `CEREFOX_ENV_LABEL` in the config it writes — without that the client would spawn the server with *its own* environment (a GUI client launched from the dock has none), `CEREFOX_CONFIG_DIR` would be absent, and an entry named `cerefox-staging` would quietly serve production. Before v1.4.0 it registered every environment as `cerefox` and running it from staging silently repointed all your agents. |
+| **Agent (MCP) config** | Safe since v1.4.0 ([#168](https://github.com/fstamatelopoulos/cerefox/issues/168)). `configure-agent` names the server after `CEREFOX_ENV_LABEL`, so a staging environment registers as **`cerefox-staging`** alongside your production `cerefox` entry rather than replacing it, and an agent can hold both. The labeled entry also carries its own `CEREFOX_CONFIG_DIR` and `CEREFOX_ENV_LABEL` in the config it writes — without that the client would spawn the server with *its own* environment (a GUI client launched from the dock has none), `CEREFOX_CONFIG_DIR` would be absent, and an entry named `cerefox-staging` would quietly serve production. Before v1.4.0 it registered every environment as `cerefox` and running it from staging silently repointed all your agents. |
 | **`doctor`'s `mcp clients` line** | It inspects your global agent configs, which point at production, and reports them even in staging mode. Informative, but easy to misread as "staging is wired to my agents". |
 | **`doctor` remediation commands** | Environment-aware since v1.8.0: in a staging environment the remediations tell you to prefix `CEREFOX_CONFIG_DIR` (or use the alias). Before that, a staging `doctor` printed bare `cerefox …` remediations that act on production. |
 

package/docs/guides/upgrading.md

@@ -66,7 +66,7 @@ schema-requiring release.
 > `pending_review`" decision out of the clients and into the
 > `cerefox_ingest_document` RPC (#241). A v1.13.0 client no longer decides
 > the status itself, so against an older server every agent write would
-> silently land `approved` — a behaviour change, not a missing feature — and
+> silently land `approved` — a behavior change, not a missing feature — and
 > the new review-status search filter would fail outright. The **minimum
 > supported schema is therefore `0.16.0`**: until you run `cerefox server
 > deploy`, `cerefox web` refuses to start and `doctor` says exactly why.
@@ -84,7 +84,7 @@ schema-requiring release.
 > `pending_review` regardless, so turning the workflow back on shows the
 > statuses the store would have had all along. It is an RPC-only change —
 > `cerefox server deploy` (or `--schema-only`) picks it up; nothing refuses
-> to run until you do, but a 0.16.0 server keeps the v1.13.0 write behaviour.
+> to run until you do, but a 0.16.0 server keeps the v1.13.0 write behavior.
 
 > ### Upgrading to v1.1.0 — `cerefox server deploy` is required
 >

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cerefox/memory",
-  "version": "1.17.1",
+  "version": "1.17.3",
   "description": "Cerefox \u2014 user-owned shared memory for AI agents. CLI + stdio MCP server + web UI + ingestion for a knowledge base on your own Supabase project (or fully self-hosted with Cerefox Local).",
   "license": "Apache-2.0",
   "homepage": "https://github.com/fstamatelopoulos/cerefox",