feat(*): upgrade everos to 1.4.1, lift the windows gate, guard the embedding width (#791)

## Summary

EverOS 1.4.0 runs natively on Windows and 1.4.1 pins `openai` below 3,
so the memory plugin's exact pin moves from `everos[multimodal]==1.2.3`
to `==1.4.1`. The lock follows: `pyarrow` 24.0.0 -> 25.0.1 (EverOS's new
floor), `everalgo-boundary` 0.2.0 -> 0.2.1, `everalgo-core` 0.4.0 ->
0.3.0 (EverOS now pins its everalgo layer with `==`), and `msvc-runtime`
on `win32` only. `lancedb` stays at 0.34.0. Every internal everos symbol
the adapter reaches is present in 1.4.1 with the same signature, so the
adapter itself is unchanged. The plugin manifest and package version
move to 1.4.0.

**The Windows gate is gone.** `everos_platform_note` (#737) and its five
call sites, `ServiceState.UNSUPPORTED`, the import.scan refusal (#750),
the wizard's WSL notice and its zh catalogue line are removed;
`_everos_executable` looks for `everos.exe` on `win32`. Spawning,
probing and reusing the server were already portable. Identifying and
stopping a stale server was not: `_cmdline_of` asked `ps`, and the
marker `everos server start` never matched a Windows command line
(`...\Scripts\everos.exe server start`). The command line now comes from
WMI through PowerShell on `win32` and the marker accepts both shapes;
`_listening_port` asks the TCP table through PowerShell there, walking
the launcher's descendants: the socket belongs to the base interpreter
two launchers below `everos.exe`. The server is spawned in a process
group of its own (the Windows counterpart of `start_new_session`, which
also keeps a Ctrl-C at the gateway off it) and stopped with Ctrl-Break,
which uvicorn takes as a shutdown; one that ignores it for ten seconds,
or one no group can be addressed to, gets `TerminateProcess` as before.
And because Windows cannot replace a running executable, the upgrade
helper stops whatever still runs from under the tool environment before
it installs (the server outlives the gateway by design); without that,
`uv` failed on `Scripts\everos.exe` with os error 32. Recorded in
`docs/memory-plugin-architecture.md` section 7.4.

**Two guards, found while verifying against a copy of a real 1.2.x
store:**

- `set_embedding_endpoint` measures the model's vector width before
writing the pin and refuses anything narrower than the 1024-wide memory
index (`REQUIRED_EMBEDDING_DIMENSIONS`), but only where an EverOS
backend will read the pin: the `everos-memory` distribution is installed
and the config names `everos` as the memory backend (an absent key is
the schema default; an explicit `null` or another backend is not gated,
and a knowledge base sizes itself to whatever width the model returns).
The wizard's own check imports the same constant and probe. A
768-dimension model pinned through the settings page had left every
memory store and search answering 500 about a mismatched width, with
nothing on the page saying why. A probe that cannot reach the provider
is not a verdict: the pin is written and a warning logged. The two RPC
writers run the (now network-touching) writer in a thread.
- `ensure_everos_server` reads the running server's `/health` version
and, for a root raven owns, sends a mismatch with the installed everos
through the same precheck / stop / spawn chain a rotated credential
takes (`stale_reason`). Raven used to reuse whatever answered on the
port, so an upgrade left the old server serving until something
unrelated restarted it. A root the user manages is never touched.

**The wire contract is pinned.** Every request body the plugin and the
memory page send (`/add` with a tool exchange, `/flush`, the four
`/search` shapes, the four `/get` kinds) is validated against everos
1.4.1's own request models in `TestRequestBodiesMatchEverosModels`, so a
schema move on the next upgrade fails in the suite rather than as a 422
in a gateway log.

**A six-angle review then hardened the degraded paths** (turn survival
under every EverOS failure, Windows lifecycle, upgrade paths, the
embedding guard, the wire contract, concurrency). The rule: memory
degrades with a notice and never blocks a turn, a start or an upgrade.

- A gateway starts the server again when it finds nothing listening (or
a probe that timed out) and nothing holding the OME lock: only for a
root raven owns, never over a child of its own, at most once per thirty
seconds. The only spawn used to be in `start()`, so a server that went
away left a running gateway without memory until restarted by hand. A
stop that was sent and did not finish is not adopted (uvicorn closes the
port at once and finishes what it had), so the version-mismatch restart
after an upgrade cannot leave the gateway on a dying server.
- A command-line lookup that failed (no `ps`, PowerShell blocked, WMI
wedged, timeout) is distinct from a process that is gone: the stop keeps
waiting, the lock names nothing, and a settings save over a server that
answers but cannot be identified is reported as not applied. A losing
spawn no longer overwrites the live server's pidfile. `stop_pid` counts
wall time and takes a grace; on Windows a backend drains the server it
started at `stop()`.
- The upgrade helper asks again after `Stop-Process` and refuses to run
`uv` while anything from the environment survives (an elevated or
another user's process): `--force` removes the environment before
writing and would have left every file but the one that could not go.
- An embedding pin narrower than the index is measured at backend start
(once per pin per process) and withheld from the spawn: EverOS runs
keyword recall and keeps storing, and the notice names the model and
width. This covers a pin written around the write-time check (before
memory was on, unreachable at save time, edited by hand). The probe no
longer raises on an odd response, times out at ten seconds, honours
`plugins.disabled`; `migrate_roles` runs off the event loop it had put a
provider round-trip onto.
- The memory page uses the `/api/v2` routes (v1 is EverOS's legacy
alias), asks `/health` before a search the way the chat adapter does,
and shows the server's own sentence on a refusal. The recalled profile
is rendered as lines rather than a `namespace(...)` repr with its
evidence fields; a tool-call-only row stores empty content, not
`"None"`; `top_k` stays within 1..100; an empty query asks nothing; a
failed capability probe is not cached. The wizard accepts a model wider
than 1024 (EverOS keeps the first 1024, as the settings page already
allowed) and re-prompts on the host's refusal instead of a traceback.

`docs/memory-plugin-architecture.md` section 7 records the upgrade (7.4)
the way 7.3 recorded 1.2.1 -> 1.2.3.

## Type

- [ ] Fix
- [x] Feature
- [ ] Docs
- [ ] CI / tooling
- [ ] Refactor
- [ ] Other

## Verification

Unit and RPC tests over every touched area:

```
env -u SERPER_API_KEY uv run --frozen --python 3.12 --extra dev pytest -q tests/test_everos_server.py tests/test_everos_backend.py tests/test_cli_onboard_commands.py tests/test_everos_discover.py tests/test_rpc_settings.py tests/test_everos_config.py tests/test_everos_plugin_discovery.py tests/test_cli_plugin_commands.py tests/test_core_plugin_stack.py tests/test_rpc_memory.py tests/test_rpc_import_sync.py tests/test_everos_http_adapter.py tests/test_memory_backend_protocol.py tests/test_memory_backend_contract.py tests/test_plugin_boundary.py tests/test_i18n_boundary.py tests/test_config_update*.py
# 1312 passed, 1 skipped (inotify is Linux-only) on the first commit; 960 passed after the review round; full suite 26214 passed, 2 failed, 120 skipped, the 2 failing on an untouched github/main checkout too (LibreOffice path, background child env)
uv run --frozen --python 3.12 --extra dev ruff check <changed files>   # All checks passed!
uv run --frozen --python 3.12 --extra dev ruff format --check <changed files>   # 20 files already formatted
```

Against a 46 MB copy of a store written by everos 1.2.x (568 episodes,
5528 atomic facts, seven LanceDB tables), never touching the live one:

- `everos server start` on 1.4.1 opens it with no schema complaint;
`/health` reports `version 1.4.1`, `cascade.healthy true`.
- The same four `/api/v2/memory/search` requests on 1.2.3 and 1.4.1
return the same ids in the same order; BM25 scores drift in the third
decimal place.
- `raven agent -m` on this branch spawns everos 1.4.1, a "remember this"
turn lands in `episodes/episode-2026-09-24.md` and `.atomic_facts/`, a
fresh one-shot session recalls it, and a third session recalls episodes
written under 1.2.x months earlier.
- With a 1.2.3 server left on the port, the next `raven agent -m` logs
`runs everos 1.2.3 while this raven installs 1.4.1; restarting`, the old
pid exits and `/health` reports 1.4.1. The 1.2.3 server had opened the
index 1.4.1 wrote with no complaint.
- Windows 11 box, this branch checked out and synced: `raven serve`
spawns `everos.exe` natively, the Memory page shows its four tabs
instead of the platform sentence, a chat turn lands as an episode
(`/add` 200, `/flush` 200, cascade `upserted=1`), and after a memory
role change the next start logs `holds credentials raven has since
changed; restarting`, the old everos pid exits and the new one answers
`/health` 1.4.1.
- The settings page refuses `BAAI/bge-base-en-v1.5` on deepinfra with
`returns 768-dimension vectors and the memory index is 1024 wide` (real
probe), and the pin stays unchanged.
- Adapter import smoke against 1.4.1: all 13 internal symbols present,
signatures unchanged.
- Windows 11 box, second round: with the server up, `uv pip install
--reinstall --no-deps everos==1.4.1` fails on `Scripts\everos.exe` (os
error 32, exit 2); after the helper's sweep (`Stopped what was still
running from the old install (pid ...)`) the same command succeeds and
the relaunched gateway spawns a fresh 1.4.1. A stop from the spawning
console runs the full uvicorn shutdown (`Shutting down` ... `Finished
server process`) in 3 s; a stop from another console falls back and the
process is gone in 2 s. `lock_holder(root).port` reads 18997 (launcher
-> venv python -> base python).
- `tests/test_everos_server.py tests/test_updates_upgrade.py`: 261
passed, 1 skipped; `tests/test_everos_backend.py -k RequestBodies`: 7
passed.
- Review round (`env -u SERPER_API_KEY uv run --frozen --python 3.12
--extra dev pytest` over the everos, config, settings, memory page,
import, onboard, plugin-stack, boundary, cycle-budget and contract
files): 1225 passed, 1 skipped; `test_everos_server.py` 124,
`test_everos_backend.py` 188.
- Windows 11 box, review round: with the gateway serving, the everos
launcher was terminated by hand (`Stop-Process`, nothing on 18997); the
next turn answered without memory (`recall failed ...
state=unresponsive`), and six seconds after it began the gateway logged
`started everos server` / `everos server ready`, the pidfile named the
new pid and `/health` answered 1.4.1. The first attempt did not fire
because a dead port there takes 2-4 s to be refused, longer than the 1 s
probe; the respawn now fires on a timed-out probe as well, guarded by
the lock holder. The memory page's four counts and a search on the Cases
tab went through the v2 routes.

- [x] Relevant tests pass locally
- [x] Relevant lint / type checks pass locally
- [x] User-facing docs or screenshots are updated when needed

## Risk

- Windows installs that used to read "long-term memory is not available
on Windows yet" now spawn EverOS, and a stale server is identified and
replaced there too. The stop there is Ctrl-Break with a ten-second
fallback to `TerminateProcess`. An upgrade on Windows first stops every
process whose executable lives under the tool environment: raven's own
gateway, sub-agents and server, nothing outside that directory.
- An embedding pin narrower than 1024 dimensions is refused at the
settings page and the wizard, with the width in the message, only for an
install whose memory runs on EverOS (plugin installed, backend `everos`
or the default). Knowledge-only installs, memory off, and other backends
keep any width. Existing pins are not touched.
- An owned EverOS server whose version differs from the installed
package is restarted on the next session start. A root the user manages
is never restarted.
- A gateway may now start an EverOS server on its own when its probe
finds nothing listening and nothing holding the lock (owned roots only,
at most every thirty seconds). On Windows a backend stops the server it
started when it shuts down (Ctrl-Break, sixty seconds to drain), so a
settings change or an upgrade there restarts the server rather than
leaving it. An upgrade on Windows refuses to proceed while a process
from the tool environment cannot be stopped, and says which pid.
- An embedding pin narrower than 1024 that reached the config around the
settings check is no longer handed to EverOS: recall runs on keywords
with a notice naming the model, until a 1024-dimension model is pinned.
- Rollback: revert the commit and `uv sync`. `lancedb` did not move, so
an index written by 1.4.1 opens under 1.2.3 (exercised on the copy).

- [x] Security impact considered
- [x] Backward compatibility considered
- [x] Rollback path is clear for risky changes

## Related Issues

N/A

---------

Co-authored-by: gloryfromca <23442919+gloryfromca@users.noreply.github.com>
Co-authored-by: Claude (claude-fable-5-1) <noreply@anthropic.com>

Author: gloryfromca

docs/memory-plugin-architecture.md

@@ -315,7 +315,7 @@ imported.
 
 ## 7. EverOS version pinning & upgrade SOP
 
-### 7.1 Exact pin is mandatory **[DONE: `everos[multimodal]==1.2.3`]**
+### 7.1 Exact pin is mandatory **[DONE: `everos[multimodal]==1.4.1`]**
 
 The adapter is written against EverOS **internal** APIs, not a stable
 public surface:
@@ -333,8 +333,8 @@ is pinned to an exact version (`==X.Y.Z`), not a range: upgrades are
 deliberate, re-validated events, never something `uv lock --upgrade`
 can do silently.
 
-Single pin: with `raven_everos` removed, EverOS is pinned in **one**
-place (raven's `pyproject.toml`). The upgrade surface is one line.
+Single pin: EverOS is pinned in **one** place, the plugin's own
+`plugins-dist/everos-memory/pyproject.toml`. The upgrade surface is one line.
 
 ### 7.2 Upgrade procedure
 
@@ -343,7 +343,7 @@ place (raven's `pyproject.toml`). The upgrade surface is one line.
    (`~/.everos/.index/` sqlite + lancedb) changed.
 1. **Bump the pin (uv only — never hand-edit pyproject/lock)**:
    ```bash
-   uv add 'everos[multimodal]==1.2.3' && uv sync
+   uv add --package everos-memory 'everos[multimodal]==1.4.1' && uv sync
    ```
    Always keep the `[multimodal]` extra. Skip `1.2.0`: it shipped a
    path-traversal regression fixed in `1.2.1`.
@@ -418,6 +418,138 @@ until the session restarts. And `everos cascade rebuild`, now the
 supported index recovery, refuses to run while a server holds the OME
 lock — while raven exposes no way to stop the server it started.
 
+### 7.4 Record: `1.2.3` -> `1.4.1`
+
+Five packages moved: `everos` `1.2.3` -> `1.4.1`, `pyarrow` `24.0.0` ->
+`25.0.1` (EverOS's new floor), `everalgo-boundary` `0.2.0` -> `0.2.1` and
+`everalgo-core` `0.4.0` -> `0.3.0` (EverOS now pins its everalgo transitive
+layer with `==`, so the resolver follows it down), and `msvc-runtime` joins
+on `win32` only. `lancedb` stays at `0.34.0`.
+
+**No adapter change.** Every internal symbol the adapter reaches
+(`MemoryRoot`, `episode_repo` / `agent_skill_repo`, `EpisodeWriter` /
+`AgentSkillWriter`, the `init_cmd` templates, the multimodal parser and
+client, the two error classes) is present in `1.4.1` with the same
+signature.
+
+**No data migration.** A copy of a 46 MB store written by `1.2.x` (568
+episodes, 5528 atomic facts, seven LanceDB tables at table schema version 2)
+started under `1.4.1` with no schema complaint and a healthy cascade. The same
+keyword searches returned the same ids in the same order on both versions;
+BM25 scores drift in the third decimal place. First start builds an IVF_FLAT
+index on any vector column past 2000 rows (`atomic_fact` here) -- seconds, and
+searches keep working meanwhile. A real turn through raven then wrote a new
+episode into that store and a fresh session recalled it, alongside episodes
+written months earlier under `1.2.x`. Rollback was not exercised this time;
+`lancedb` did not move, so the file format is the one `1.2.3` already reads.
+
+**A running server from before the upgrade is replaced.** raven used to
+reuse whatever answered on the configured port, so an EverOS `1.2.3` left
+running kept serving after the pin moved, with every surface green.
+`ensure_everos_server` now reads the running server's `/health` version and,
+for a root raven owns, sends a mismatch through the same precheck / stop /
+spawn chain a rotated credential takes (`stale_reason`). A root the user
+manages is theirs to restart. `everos cascade sync`, `cascade fix --apply` and
+`cascade rebuild` refuse to run beside a running server (exit code 3).
+
+**Windows.** `1.4.0` runs natively on Windows, so the platform gate raven
+carried (`everos_platform_note`, `ServiceState.UNSUPPORTED`, the wizard's
+WSL notice) is gone and `_everos_executable` looks for `everos.exe` there.
+Spawning, probing and reusing the server were already portable. Identifying
+and stopping a stale server was not: `_cmdline_of` asked `ps`, and the marker
+`everos server start` never matched a Windows command line, which prints the
+executable as `...\Scripts\everos.exe server start`. The command line now
+comes from WMI through PowerShell on `win32` and the marker accepts both
+shapes; the pidfile raven writes at spawn already named the pid. Verified on
+a Windows 11 box: a changed memory role sent the running server through
+"holds credentials raven has since changed; restarting", the old pid exited
+and the new one answered `/health`. `_listening_port` asks the TCP table
+through PowerShell there (no `lsof`, no `/proc`), walking the launcher's
+descendants because the socket belongs to the base interpreter two launchers
+below `everos.exe`. The stop is Ctrl-Break: the child is spawned in a process
+group of its own (`CREATE_NEW_PROCESS_GROUP`, the Windows counterpart of
+`start_new_session`, and what keeps a Ctrl-C at the gateway off the server),
+uvicorn takes the event as a shutdown, and a server that has not acted on it
+in ten seconds -- one another console started, which the event cannot reach
+-- gets `TerminateProcess`, the stop every server there had before. Verified
+on the same box: a stop from the spawning console runs the full uvicorn
+shutdown (`Shutting down` ... `Finished server process`) in three seconds; a
+stop from another console falls back and the process is gone in two.
+
+**The upgrade helper sweeps the environment on Windows.** Windows cannot
+replace an executable that is running, and the server outlives the gateway
+by design, on the environment's own python: with it up, `uv` failed to
+replace `Scripts\everos.exe` (`os error 32`). After waiting for the parent,
+the helper now stops every process whose executable lives under the tool
+environment -- that directory and nothing wider -- and only then installs.
+Verified on the box: the same reinstall that failed with the server up
+succeeds after the sweep, and the relaunched gateway spawns a fresh server.
+
+**What a six-angle review of the branch then changed.** Each item is a
+scenario a real install can reach; the rule behind them is that memory
+degrades with a notice and never blocks a turn, a start or an upgrade.
+
+- A gateway starts the server again when it finds nothing listening
+  (`EverosBackend._may_respawn` / `_respawn`): only for a root raven owns, only
+  when no child of its own still runs, only when nothing holds the OME lock,
+  at most once per thirty seconds. Before, the only spawn was in `start()`,
+  which a running gateway never passes through again, so a server that went
+  away -- an upgrade's sweep, a crash, a stop another process sent -- left the
+  gateway without memory until it was restarted by hand.
+- A stop that was sent and did not finish (`STILL_DRAINING`: uvicorn closes
+  the port at once and finishes the requests it had, an extraction included)
+  is no longer adopted by `ensure_everos_server`; it raises, the backend keeps
+  probing, and the probe above starts a replacement once the lock is free.
+  Adopting it reported memory over a process that no longer answered.
+- A command-line lookup that failed (`_cmdline_of` -> `None`: no `ps`,
+  PowerShell blocked, WMI wedged, the timeout hit) is distinct from a process
+  that is gone. A stop keeps waiting on it; `lock_holder` identifies nothing;
+  `restart_for_config_change` reports "could not be identified" instead of
+  applied when something still answers on the address.
+- A spawn that loses the boot race no longer overwrites the pidfile of the
+  live server (`_start_server_if_unlocked`): on Windows the pidfile is the
+  only way back to it.
+- `stop_pid` counts wall time (each Windows poll launches PowerShell) and takes
+  a `grace`; on Windows a backend drains the server it started itself at
+  `stop()` (Ctrl-Break, sixty seconds), so an upgrade finds nothing to
+  terminate mid-write and a settings change restarts it cleanly.
+- The helper's sweep asks again after `Stop-Process` and refuses to run `uv`
+  while anything from the environment survives (elevated or another user's
+  process): `uv tool install --force` removes the environment before it
+  writes, and would have left every file but the one that could not go.
+- An embedding pin narrower than the index is measured at backend start
+  (`configured_embedding_width`, once per pin per process) and withheld from
+  the spawn (`withhold_role`): EverOS runs keyword recall and keeps storing,
+  and the notice names the model and the width. The write-time check covers a
+  pin written through raven; this covers one written around it. The probe no
+  longer raises on an odd response, times out at ten seconds, and an install
+  with the plugin on `plugins.disabled` is not gated. `migrate_roles` runs off
+  the event loop, which the probe had put a provider round-trip onto.
+- The memory page calls the `/api/v2` routes (v1 is EverOS's legacy alias),
+  asks `/health` before a search the way the chat adapter does (keyword
+  without embedding, the LLM rerank on the agent track without a
+  cross-encoder, the profile opted in), and shows the server's own sentence
+  on a refusal instead of "unreachable".
+- The recalled profile is rendered as lines again: the search response
+  arrives as namespaces, and the renderer, handed one, had put
+  `namespace(explicit_info=[namespace(...)])` -- evidence fields included --
+  into every prompt. A tool-call-only assistant row is stored with empty
+  content, not `"None"`; `top_k` is clamped to the server's 1..100; an empty
+  query asks nothing; a `/health` probe that failed is not cached as "no
+  capabilities" for the life of the adapter.
+- The wizard accepts a model wider than 1024 (EverOS keeps the first 1024,
+  the settings page already accepted it) and turns the host's refusal into a
+  re-prompt rather than a traceback.
+
+**One guard added alongside.** The live install was found pinned to a
+768-dimension embedding model against this 1024-wide index, with every store
+and search answering 500. `set_embedding_endpoint` now measures the model's
+width before writing the pin and refuses anything narrower than
+`REQUIRED_EMBEDDING_DIMENSIONS`, but only where the config names EverOS as
+the memory backend: a knowledge base sizes itself to whatever width the
+model returns, so an install with memory off or on another backend keeps
+any width. The wizard's own check reads the same constant and probe.
+
 ---
 
 ## 8. Validation (this change)

plugins-dist/everos-memory/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "everos-memory"
-version = "1.2.0"
+version = "1.4.0"
 description = "EverOS memory backend for Raven: dual-track semantic recall and the understand_media tool"
 requires-python = ">=3.12"
 license = "Apache-2.0"
@@ -20,7 +20,7 @@ dependencies = [
     # The substrate this adapter binds. Exact pin, not a range: the adapter
     # reaches internal (non-public) everos APIs, so an upgrade is a deliberate
     # act. Same pin the host carried while the plugin lived inside it.
-    "everos[multimodal]==1.2.3",
+    "everos[multimodal]==1.4.1",
     "httpx>=0.28.0,<1.0.0",
     "loguru>=0.7.3,<1.0.0",
     "tomli-w>=1.2.0",

plugins-dist/everos-memory/raven_everos/__init__.py

@@ -32,4 +32,4 @@
 Anything else in the package is the plugin's own.
 """
 
-__version__ = "1.1.0"
+__version__ = "1.4.0"