docs: fix three guide inaccuracies found in post-merge review

content/docs/guides/connect-a-harness.mdx

@@ -73,7 +73,7 @@ coven doctor
 
 ```text
 Harnesses:
-  [OK] Codex              `codex` is ready (built-in)
+  [OK] Codex              `codex` is ready (built-in adapter)
 ```
 
 If it still shows `[!!] … missing`, open a new terminal so `PATH` changes apply, then rerun `coven doctor`. Doctor's install hint under the failing line tells you the exact missing step.

content/docs/guides/install-and-first-run.mdx

@@ -47,7 +47,7 @@ Daemon:
   Not running
 
 Harnesses:
-  [!!] Codex              `codex` is missing (built-in)
+  [!!] Codex              `codex` is missing (built-in adapter)
        npm install -g @openai/codex && codex login
   ...
 
@@ -79,7 +79,7 @@ Provider credentials belong to the harness, not to Coven — Coven never reads t
 
 ```text
 Harnesses:
-  [OK] Codex              `codex` is ready (built-in)
+  [OK] Codex              `codex` is ready (built-in adapter)
 ```
 
 If the harness still shows missing, open a new terminal (so `PATH` changes apply) and run `coven doctor` again.

content/docs/guides/set-up-memory.mdx

@@ -11,7 +11,7 @@ Coven's memory has two local surfaces: **persistent notes** — plain Markdown f
 
 ## Prerequisites
 
-- The Coven CLI installed and the daemon running — `coven memory` reads through the daemon API; see [Set up the daemon](/docs/guides/set-up-the-daemon).
+- The Coven CLI installed — `coven memory` reads `~/.coven` directly and works without a running daemon; see [Install and first run](/docs/guides/install-and-first-run).
 - For the semantic index steps: a Rust toolchain and a checkout of the [Coven repo](https://github.com/OpenCoven/coven) — the `coven-memory` binary builds from the workspace and is not part of the npm wrapper.
 - About 300 MB of disk for the embedding model, downloaded once on first ingest.
 
@@ -76,7 +76,7 @@ Everything in this guide ran locally: embeddings are computed on your machine an
 ## Troubleshooting
 
 - **`coven memory` prints `No memory files.`** — the notes are not `.md` files directly under `~/.coven/memory/<familiar>/`; nested folders and other extensions are ignored.
-- **`coven memory` fails with a connection error** — the daemon is down; see [Set up the daemon](/docs/guides/set-up-the-daemon) and [Daemon unavailable](/docs/reference/troubleshooting#daemon-unavailable).
+- **`coven memory` shows nothing even though notes exist** — you are pointed at a different `COVEN_HOME`; run `coven doctor` and confirm the store path it reports.
 - **First ingest stalls** — it is downloading the embedding model; give it bandwidth once, subsequent runs are offline.
 - **Search returns another familiar's content** — you searched without `--familiar`; scope the query.
 - **Anything else** — [Memory search](/docs/memory-models/memory-search) and [Troubleshooting](/docs/reference/troubleshooting).

content/docs/guides/upgrade-coven.mdx

@@ -64,7 +64,7 @@ curl --unix-socket "$HOME/.coven/coven.sock" \
   http://localhost/api/v1/health
 ```
 
-**Expected output:** `"ok": true`, the new `covenVersion`, and — critically — `"apiVersion": "coven.daemon.v1"`, the contract your clients support. Scripts that use optional features should also check `GET /api/v1/capabilities` before relying on them. If a future release ever changes the contract, clients should fail closed with an update message rather than guess at response shapes — see [Recovery and upgrades](/docs/daemon/recovery-upgrades).
+**Expected output:** `"ok": true` and — critically — `"apiVersion": "coven.daemon.v1"`, the contract your clients support. Do not verify the upgrade against the health body's `covenVersion` (released builds report the crate version, not the release tag — Step 2's `coven --version` is the version check). Scripts that use optional features should also check `GET /api/v1/capabilities` before relying on them. If a future release ever changes the contract, clients should fail closed with an update message rather than guess at response shapes — see [Recovery and upgrades](/docs/daemon/recovery-upgrades).
 
 ## Step 5 — Confirm your sessions survived