[Kendrick-Song]

Summary

Moves EverOS onto the everalgo 2026-11 contract line and lands four changes built on it. CHANGELOG.md [Unreleased] has the full list and the upgrade steps; in short:

• everalgo 2026-11 line (exact pins): everalgo-core 0.7.0, everalgo-boundary 0.5.0, everalgo-user-memory 0.9.0rc8, everalgo-agent-memory 0.6.0rc4, everalgo-rank 0.5.0rc5. Boundary detection runs on everalgo's BoundaryDetector ([boundary_detection] strategy = batch | step, batch the default); episode summaries come from a second model call made alongside the episode call (falling back to the first 200 characters); [memory] timezone also sets the zone the model sees message times in; [tokenizer] name = jieba | nltk; language detection covers Chinese, Japanese and English.
• Per-task LLM sections, [llm.<task>]: twelve tasks (boundary ... decider) can override any [llm] field, inherited field by field (extra replaced whole). [llm] gains temperature, max_tokens and sdk_max_retries, and rejects unknown keys. The decider's LLM is [llm.decider] (the old [decider] LLM keys still work, with a warning); it no longer has its own 512-token output cap. everos config show and the startup log print each task's resolution.
• The user profile is built from episodes (ProfileExtractor.aextract_from_episodes): every item quotes the conversation, no new implicit_traits, and user.md keeps the extractor's do_not_record / pending lists. [profile] max_episodes_per_call (default 10); the profile's LLM is [llm.profile]. A sender keeps the name it was last given (sender_name table).
• Benchmarks: LoCoMo is published on this release, re-judged against the gold audit — 94.61%* (locomo-step, agentic), with every retrieval method under step and batch boundary detection in benchmarks/README.md. New locomo-step config (step + prompt-only replies). Runs started together no longer share servers (GET /health reports pid); the decider is resolved and probed exactly as the servers resolve it, and an llm_multiround conversation stops before ANSWER if any decider round fell back. The guide is rewritten as a step-by-step user guide (English and Chinese).

* Re-judged: the 99 questions whose gold answer the LoCoMo audit disputes are graded against its corrected answers.

Area

• Architecture method
• Benchmark
• Use case
• Documentation
• Developer experience
• CI, build, or release

Verification

On b4c48220:

make lint                     # pass; 14 import-linter contracts kept
make test (hermetic: no provider keys, temporary EVEROS_ROOT)
                              # 3829 passed, 2 skipped
GitHub CI                     # 11 / 11 checks pass (unit 3.14 / 3.13 / Windows,
                              #  integration incl. Milvus 2.6, lint, package, ...)
Upgrade from 1.6.0            # a 1.6.0 store started on this branch with a fake LLM:
                              #  no migration or rebuild; add / flush / search / get /
                              #  profile / delete / cascade status all work
LoCoMo (paid, OpenRouter)     # 3 full runs per config + every retrieval method,
                              #  1540 questions each, 0 failed calls, 0 decider fallbacks

Not run: make acceptance (real LLM / embedding).

Checklist

• I kept the change scoped to the relevant area. (No: four related changes on one contract line, by choice; see Summary.)
• I am opening this from a separate branch, not pushing directly to main.
• I updated docs, examples, or setup notes when behavior changed.
• I added or updated tests when the change affects behavior.
• I did not commit secrets, .env files, dependency folders, or generated output.
• Active relative links in Markdown files resolve.

Notes for Reviewers

• Breaking (hence feat!; steps in the CHANGELOG ### Upgrade table): unknown keys under [llm] / [llm.<task>] (or an EVEROS_LLM__* variable naming none) fail startup; MemoryDeps.llm / Providers.llm / Providers.decider -> .llms; resolve_llm_config, resolve_decider_config, DeciderClientConfig, ProfileClusterUpdated and EpisodeIndex.count removed. HTTP and CLI are unchanged apart from pid added to /health.
• Upgrade: stop the old server normally so queued profile runs drain; with uv, install with --prerelease=allow (exact rc pins).
• Cost: each memcell makes two extraction calls (episode + summary).
• Known follow-ups (non-blocking, from review): after the upgrade, an owner's first profile run folds at most max_episodes_per_call - 1 older episodes; a deletion/writer race seen on one reviewer host, no longer reproducible, with diagnostics kept in the property test.
• CI gains an NLTK data download step for the nltk tokenizer tests.

🤖 Generated with Claude Code

[gloryfromca]

Blocking: Preserve persisted profile-job recovery and make the deletion/writer property pass.

I reviewed the repository guidance, the full origin/main...HEAD diff, affected callers and composition wiring, commit history, persisted-event compatibility, test changes (including removed tests), and the architecture contracts. The per-task LLM, profile-from-episodes, boundary/sender, persistence, and benchmark paths otherwise look coherent.

Validation:

• All lint, formatting, import-architecture, repository-policy, datetime/singleton, and OpenAPI gates passed.
• Unit: 3,708 passed, 4 skipped, 1 failed (test_memory_delete_jitter), and the minimized failure reproduces directly.
• Integration: 213 passed, 9 skipped, 7 deselected; 7 allocator-probe tests could not run because the host system /tmp is full and their glibc tmpfile() setup therefore produces no probe log.

Two blocking findings are inline.

[gloryfromca]

Blocking: Preserve old profile-job recovery, fix the deletion/writer race, and reject legacy smoke stores during full benchmark resume.

The two previous blockers still reproduce on this head: resolve_topic("everos.memory.events:ProfileClusterUpdated") raises TypeError, and the standard unit suite still minimizes the deletion/writer property to the same cross-owner episode loss.

I also found one new backward-compatibility blocker inline: the new message_cap identity does not protect full runs from smoke stores created by the pre-change harness, because missing legacy identity keys are discarded as unknown.

Coverage this round: the delta from the previously reviewed head, the current complete branch diff, CLAUDE.md (no AGENTS.md or CONTEXT files are present), affected callers and resume markers, relevant history, upgrade/backward compatibility, test additions/removals, and the architecture contracts.

Checks: pytest -q tests/unit finished with 3,817 passed, 4 skipped, 1 failed in 10:59 (the deletion/writer property above); 229 focused changed benchmark tests passed; 4 new session-cluster cleanup integration tests passed; Ruff formatting passed; all 14 import-linter contracts passed. Ruff check also reports one pre-existing RUF006 in untouched use-cases/openher/integration/evermemos_mixin.py.

[gloryfromca]

Blocking: Preserve persisted profile-job recovery and make the deletion/writer unit property pass.

Both remaining blockers meet the fourth-round bar:

• Persisted-event recovery is introduced by this change deleting ProfileClusterUpdated; it is reached during an ordinary upgrade with a queued or running profile job; and an owner with no later episode has no recovery path after topic resolution fails.
• The deletion/writer failure is introduced on this branch and reached by every standard unit/CI run through Hypothesis’s saved minimized example; it deterministically leaves another owner’s episode missing, and there is no permitted test bypass or working green gate.

No new blocker survived review of the new fleet PID identity, retry-state reset, decider fallback gate, LoCoMo step configuration, dependency releases, health API addition, callers, and history.

Nonblocking follow-up: legacy pre-change smoke stores can still be mistaken for full stores when message_cap was not recorded. The defect remains reproducible, but it is legacy-only and operators can use a fresh RUN/store, so I withdrew and resolved that thread under the round-four convergence bar.

Coverage: the delta from the prior reviewed head, the current complete branch diff, CLAUDE.md (no AGENTS.md or CONTEXT files are present), affected callers and history, backward compatibility, test additions/removals and weakening checks, and all architecture contracts.

Checks: pytest -q tests/unit finished with 3,826 passed, 4 skipped, 1 failed in 11:09 (the deletion/writer property); the 77 focused new benchmark/health tests finished with 76 passed and 1 skipped; Ruff formatting passed; all 14 import-linter contracts passed. Ruff check reports the same pre-existing RUF006 in untouched use-cases/openher/integration/evermemos_mixin.py.

[gloryfromca]

Blocking: Make the pinned deletion/writer example pass on Linux/ext4.

The author’s new @example reproduces the open cross-owner loss twice on this head, including in the focused changed-code run. TMPDIR was explicitly placed on the workspace ext4 filesystem with about 91 GiB free, so the earlier full system /tmp does not explain it; full host and assertion details are posted in the thread.

This remains the sole blocker and meets the later-round bar: the branch introduces the failing behavior, an ordinary unit run executes the pinned example and models normal multi-owner background concurrency, and an unrelated episode lost without a matching deletion has no recovery path.

I accepted the author’s documented normal-stop/drain-log procedure as the upgrade-scope decision for old ProfileClusterUpdated jobs and resolved that thread. Named nonblocking constraints remain: a crash/kill -9/drain-timeout during upgrade can drop an old queued profile run, and pre-change smoke stores need a fresh RUN/store to avoid ambiguous reuse.

No new finding survived review of the decider output-cap change, its resolution callers and tests, the benchmark configuration/docs delta, the pinned property change, or relevant history.

Coverage: the delta from the prior reviewed head, the current complete branch diff, CLAUDE.md (no AGENTS.md or CONTEXT files are present), affected callers and history, backward compatibility and upgrade behavior, test changes/weakening, and architecture contracts.

Checks: the focused 92-test changed-code run finished with 90 passed, 1 skipped, 1 failed (the pinned deletion/writer example); Ruff formatting passed; all 14 import-linter contracts passed. Ruff check reports the same pre-existing RUF006 in untouched use-cases/openher/integration/evermemos_mixin.py.

[gloryfromca]

No blockers; suggestions only, and they are marked inline.

This revision clears my remaining block. The new property-test instrumentation preserves both I4 and the pinned example while adding failure evidence; the README edits only reorganize the published LoCoMo result. On this host the property passed its pytest run and 20 additional direct runs of the exact action lists. ruff format --check, ruff check, and git diff --check also pass.

I covered the repository's CLAUDE.md rules, the new delta in the context of the full PR diff, relevant production callers and history, backward-compatibility items already on the record, test weakening, and architecture boundaries. No new defect survived refutation.

Named nonblocking follow-ups remain: the rare deletion/writer race observed on the prior revision but no longer reproducible here; persisted profile jobs after abnormal old-server shutdown, handled by the documented upgrade/drain procedure; and legacy smoke stores, for which operators must use a fresh run/store before a full ingest.

[gloryfromca]

No blockers; suggestions only, and they are marked inline.

The new upgrade notes and default_ome.toml comment agree with the implementation: startup creates the new SQLite table, legacy decider settings remain bridged with a warning, profile catch-up uses the documented cap and ordering, and an unresolved persisted legacy event fails its recovered job without stopping the engine. The delta changes no runtime behavior or test assertions.

I covered CLAUDE.md, this delta in the context of the full change, the relevant configuration/schema/profile/OME callers and history, backward compatibility, test weakening, and architecture boundaries. Targeted CLI-init, profile-strategy, and OME-engine tests pass: 76 passed. git diff --check also passes.

The previously named nonblocking follow-ups remain: the rare deletion/writer race, abnormal-shutdown profile-job recovery handled by the upgrade procedure, and pre-change smoke-store reuse requiring a fresh run/store. All review threads I opened are resolved.

[gloryfromca]

Blocking: Include sender_name in scoped purge.

The merge combines the new persisted sender-name table with main's scoped-purge path, but the purge repository does not count or delete that table. I reviewed the project rules, the merge diff and conflict resolutions, callers and history, backward compatibility, test changes, and the affected persistence architecture. The full unit suite passed (4,033 passed, 4 skipped), and all repository lint/architecture/documentation gates passed; a direct SQLite reproduction nevertheless shows project purge reporting success while the sender name remains.

This meets the post-fourth-round blocker bar: this merge introduces the interaction, it is reached in ordinary use by persisting a named sender and purging its project/app/space, and there is no supported purge path left after the successful job to remove the retained identity. The previously named upgrade recovery, legacy smoke-store, and deletion/writer items remain nonblocking under the earlier conclusions.

[gloryfromca]

Blocking: Include sender_name in scoped purge.

The new table is exported here, but ScopePurgeRepo._SCOPED does not include it. I reproduced this with a temporary SQLite database: after storing a1/p1/u1 -> Alice, a project purge returned zero remaining/deleted rows and reported success, while SqliteSenderNameStore.get_many() still returned {"u1": "Alice"}. A later unnamed message can therefore reuse identity data that the project/app/space purge promised to remove.

This satisfies all three late-round blocker conditions: the merge introduces the combination of this table and scoped purge, named-sender storage followed by a purge is ordinary use, and after the purge job succeeds there is no supported project/app/space cleanup path for the retained row. Register this table in scoped purge counting/deletion and cover it in the purge tests.