chore(deps): upgrade everos 1.2.1 to 1.2.3

[gloryfromca]

Summary

Upgrades the pinned EverOS from 1.2.1 to 1.2.3, per the SOP in
docs/memory-plugin-architecture.md section 7.2. Four packages move:
everos, everalgo-agent-memory 0.3.1 to 0.4.0,
everalgo-user-memory 0.3.2 to 0.4.0, and lancedb 0.33.0 to 0.34.0.

The adapter needs no change. Every EverOS symbol it imports still exists
with an identical signature (12 call sites checked), and memory/search/dto.py
plus the search / memorize / get route modules are byte-identical between
the two releases, so the HTTP contract is untouched.

No data migration. No LanceDB table schema changed: user_profile and
knowledge_topic are byte-identical between the two releases, and the five
files that differ at all (episode, atomic_fact, agent_case,
agent_skill, foresight) differ only in docstrings. So the column-type
startup check that 1.2.2 added does not fire on an index this upgrade
produces. lancedb 0.33 and 0.34 were verified interchangeable in both
directions - each writes Lance file format v2.1, and a table written by
either opens, searches over the other's IVF and FTS indexes, upserts and
prunes under the other - so reverting the pin can still read the index.

Three things reviewers should know, all recorded in the new SOP section 7.3
rather than only here:

1. extract_foresight now ships disabled. The default moved in code, not
   in default_ome.toml, so an existing ~/.everos/ome.toml does not opt out
   of the change. Any deployment relying on foresight entries must set
   enabled = true per install.
2. Agent-skill extraction works for the first time. Before 1.2.3 a
   cascade race meant it produced zero SKILL.md files, so
   EverosSkillSource has been contributing nothing; it now contributes real
   skills to the prompt.
3. The Linux install floor moves to glibc 2.28. lancedb 0.34.0 ships no
   manylinux_2_17 wheel and no sdist, and install.sh hands the exported
   lockfile to the user's uv as constraints, so CentOS or RHEL 7,
   Ubuntu 18.04 and Amazon Linux 2 fail at install time rather than falling
   back to a source build.

Two smaller changes are consequences, not choices. 1.2.3 gives
extract_agent_skill a module-level _reader singleton beside _writer, and
the integration conftest reset only the writers it knew about. And the bundled
plugin manifest version moves to 1.2.0, which two tests assert as a literal;
SOP step 5 now names both so the next bump does not rediscover them.

Type

• Fix
• Feature
• Docs
• CI / tooling
• Refactor
• Other

Dependency upgrade. chore has no box of its own.

Verification

uv run pytest tests/test_everos_plugin_discovery.py tests/test_everos_backend.py \
  tests/test_everos_http_adapter.py tests/test_memory_backend_protocol.py \
  tests/test_memory_backend_contract.py -q
=> 158 passed

uv run pytest <all unit files that mention everos> \
  tests/test_memory_backend_protocol.py tests/test_memory_backend_contract.py \
  -q -p no:randomly
=> 1336 passed, 30 skipped

uv run ruff check <the four changed .py files>          => All checks passed
uv run ruff format --check <the four changed .py files> => 4 files already formatted
make check-large-files                                  => pass

make lint-python on this branch only covers the nine CI-tooling files in
PYTHON_LINT_TARGETS, so ruff was run directly against the files this change
touches instead of relying on that target.

The 30 skips are parametrized cases in
test_provider_resolution_invariants.py ("not a gateway" and similar); they
are structural, unrelated to EverOS, and skip identically on the baseline.

Beyond the suites above, the upgrade was exercised end to end through Raven's
own entrypoints on an isolated RAVEN_HOME: raven plugins reports the new
manifest version, raven doctor still parses the capability matrix from a
/health that 1.2.3 extended with a cascade block, and a real
raven agent -m turn recalls memories that 1.2.1 wrote - including after
rolling the pin back, with the index having been written by lancedb 0.34 in
between. The extract_foresight change is visible in the OME run_record
table: every other strategy advances by one dispatch per turn while
extract_foresight stops being dispatched at all.

The real_llm layer of SOP step 3 could not be validated, and this PR does
not claim it passes. All three tests in
tests/integration/test_everos_backend_e2e.py fail with
no such table: md_change_state, and they fail identically on the baseline,
checked by re-syncing to the old pin and running the same command. The cause is
pre-existing and independent of the upgrade: everos_env isolates the test by
monkeypatching EVEROS_ROOT to a tmp dir (conftest.py:126), but the
backend's start path calls configure_everos_env(), which deliberately assigns
rather than defaults that variable (update_everos.py:228), so the spawned
server serves the recorded root while the test's drain helper reads the tmp
root's sqlite. Worth fixing, but not here.

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

Risk

Two user-visible behaviour changes, both upstream defaults rather than choices
made here: foresight extraction stops running unless an install opts in, and
agent-skill extraction starts running for the first time, which changes prompt
content and token usage. The ome.db run_record ring buffer for
skill_cluster_updated also grows from roughly 0.8 KB to 14 KB per row because
SkillClusterUpdated now carries a 1024-dim embedding, about 14 MB instead of
0.8 MB at the default 1000-record cap.

Rollback is git revert of this commit plus uv sync. The index does not need
restoring: the schemas are unchanged and lancedb 0.33 reads what 0.34
wrote, both verified. Installs on glibc below 2.28 are the one case a revert is
required rather than optional.

• Security impact considered
• Backward compatibility considered
• Rollback path is clear for risky changes

Related Issues

N/A

[claude]

Claude encountered an error after 1s —— View job

---

I'll analyze this and get back to you.

[gloryfromca]

No blockers; this can merge as far as I am concerned. Two nonblocking notes inline.

I re-derived the claims in the PR body and the new SOP section against the unpacked 1.2.1 and 1.2.3 trees rather than taking them on trust, and they hold:

• Adapter surface. Every EverOS symbol raven imports (load_settings, resolve_root, MultimodalNotEnabledError, UnsupportedModalityError, md_change_state_repo, require_multimodal, SearchRequest, memorize, search, _get_engine) resolves under 1.2.3 with the same signature, and SearchRequest's field set is unchanged.
• The comment edit in backend.py:906 is accurate, not just renumbered. 1.2.3's routers are exactly get / health / knowledge / memorize / metrics / ome / search, and no route module mentions confidence or skill_usage, so the "no endpoint to consume them" reasoning still stands rather than being a stale claim carried forward.
• No data migration. diff -rq over infra/persistence/lancedb/tables/ gives precisely the five files named, and each diff is a docstring line (a dropped 17_lancedb_tables_design.md cross-reference); user_profile and knowledge_topic are byte-identical. The claim is verifiable, not asserted.
• The foresight claim is subtler than it reads and still correct. enabled=False is on the @offline_strategy decorator, while default_ome.toml has [strategies.extract_foresight] commented out in both releases -- so an existing ~/.everos/ome.toml copied from the 1.2.1 template carries no override and does inherit the new default.
• The conftest delta is exactly right and complete. Comparing module-level _-prefixed names across all seven strategy modules plus service/memorize.py and component/llm/client.py, extract_agent_skill._reader is the only addition in 1.2.3. Worth stating plainly: nothing exercises that line (the real_llm suite fails on md_change_state on the baseline too, as the PR body says), so its correctness rests on inspection -- I did that inspection and it is right.
• Both known gaps reproduce as described and I agree with shipping them as recorded: _SPAWNABLE_STATES is {UNKNOWN} so a self-SIGTERMed server is not respawned, and cascade rebuild refuses under the OME lock. The SIGTERM path needs four supervised-loop crashes inside the stability window, _should_report still surfaces one warning for the new state, and the upstream alternative (serving searches from a frozen index) is worse. Accepted risk rather than a defect.

Tests. uv run pytest tests -q -x -p no:randomly => 6477 passed, 43 skipped, 138s. I read every skip: optional channel SDKs absent from this env (lark_oapi, nio, botpy, slack_sdk, telegram, wecom_aibot_sdk) and structural parametrizations in test_provider_resolution_invariants.py / test_provider_catalog.py. None are EverOS-related and nothing was weakened to get green -- the three version literals this PR touches are still real equality assertions against the shipped manifest. make check-large-files passes.

Covered: AGENTS.md rules (commit grammar, uv-only lockfile provenance, test file naming -- no new files, existing ones edited in place as 5.4 requires), the diff itself, callers and git log history of the two version literals, backward compatibility (rollback path, lockfile, glibc floor), and whether tests were weakened. The remaining 1.2.1 mentions across raven/ and tests/ are correctly left alone -- they date behaviour ("from everos 1.2.1 a server ..."), they do not name the pin.

[gloryfromca]

The manifest bump has a third site, and this list is where the next bump will lose it again.

raven/plugin/memory/everos/__init__.py:14 still says __version__ = "1.1.0" while raven-plugin.toml now says 1.2.0, and tests/test_everos_plugin_discovery.py:51 (TestPackageSurface::test_imports_clean) pins that stale literal -- which is why the suite stays green on the divergence instead of catching it.

That these two are meant to move in lockstep is not my inference: #264 (5b26c833) bumped the manifest 1.0.0 -> 1.1.0 and __version__ in the same commit. This is the first release where they disagree, so raven plugins prints 1.2.0 for a package whose own dunder reports 1.1.0.

No runtime consumer reads __version__ today (I grepped -- the test is the only reader), so nothing breaks now; that is why this is a note and not a blocker. But the drift is silent and permanent, and the SOP text right here says "Two tests" when there are three literals to move.

Two ways out, and it is your call which:

• Keep it as the package version: set __version__ = "1.2.0", update test_imports_clean, and make this sentence name all three sites (__init__.py, test_imports_clean, test_bundled_shadows_lower_priority_source, test_lists_everos_memory).
• Treat it as dead metadata: delete __version__ and its assertion, leaving the manifest as the single source of truth, and say so in this step so nobody re-adds it. Cheaper long-term -- one literal cannot drift from itself.

Either way the SOP sentence needs to change with it, since its whole purpose is that the next bump does not rediscover this.

[gloryfromca]

This paragraph is correct -- and it is the only place the new install floor is written down, which is my concern rather than the analysis.

The lockfile confirms it: 1.2.1 carried manylinux_2_17_{x86_64,aarch64} wheels for lancedb, 0.34.0 ships only manylinux_2_28 (plus macOS arm64 and win_amd64) and no sdist. So on glibc 2.17-2.27, on both x86_64 and aarch64, install.sh fails at resolution with a bare uv error naming a transitive dependency the user has never heard of. README's install section says "Linux, macOS, or WSL2" with no libc floor, and CI is ubuntu-latest (glibc 2.35+), so nothing in the project will ever tell that user why -- and the explanation lives in an internal architecture doc they would have no reason to open.

Not a blocker: the affected distros (CentOS/RHEL 7, Ubuntu 18.04, Amazon Linux 2) are all past end of life and the project never promised them. But "recorded in the plugin architecture doc" is not the same as "the affected user can find out", and a dependency upgrade is the moment the floor moves.

Cheapest fix, your pick: a one-line prerequisite in README's install section (Linux: glibc 2.28 or newer), or a preflight in install.sh that checks ldd --version before handing constraints to uv and prints the reason. The preflight is the kinder failure -- an explanatory message beats a resolver traceback -- but the README line costs almost nothing and covers the common case.