[gloryfromca]

Summary

Make MemoryBackend the only seam between the host and the memory subsystem, so a second memory plugin can be installed without editing host code.

The abstraction is the goal; no second backend is being added.

What the branch does:

• health() joins the Protocol. raven doctor and raven import read a BackendHealth(ready, checks) the backend fills in with its own vocabulary, instead of reaching into EverOS internals. Doctor prints the checks verbatim and never interprets a label.
• A new [[plugin.contributes.onboard]] kind, with raven/contracts/onboard.py as its paper. The host lends the wizard shell as one OnboardUI and records the result; the screen returns a StepOutcome. The plugin never writes memory.backend -- that key stays the host's. EverOS's step-4 screen and its everos.toml management move into the plugin.
• The skill source and the after-turn feedback prefix are named from memory.backend rather than the literal everos.
• enabled_by_default is gone from the manifest: an installed plugin the user has not disabled is active.
• tests/test_plugin_boundary.py pins the dependency direction in both directions, with an equality assertion so the remaining exceptions cannot grow.

That guard's allowlist started at five host files still speaking EverOS's wire protocol. The follow-ups below close three of them.

Two things this branch itself introduced were found in manual acceptance on an install without the plugin and fixed here: a turn printed which backends were installed -- empty on exactly the install that needs the sentence -- and settings.everos / settings.everosSet let ModuleNotFoundError reach the dispatcher as an internal error carrying a traceback. Both now carry the note doctor and the wizard already use, naming the distribution to install.

Review on this PR found four blockers, all fixed and covered. A fifth defect came out of manual acceptance rather than review, and four more out of the rounds that followed it -- every one of those in the embedding endpoint's own plumbing, each found by the round after the fix that introduced it. They are listed under Risk; the blockers are:

1. onboard is an optional contribution, but the wizard equated "no matching screen" with "not configured", so one raven onboard --skip-memory wrote memory.backend back to null for a third-party backend configured by hand. A backend with no screen now answers on the strength of having been selected; only one whose own screen says it is unconfigured is cleared, which is the case that rule exists for.
2. The record a sub-agent call leaves behind ran through a backend nobody had started. The shipped adapter begins in an unknown state, so the first flushing write only scheduled a readiness probe and answered false -- the record said "unavailable" while the service was up the whole time, and each per-record HTTP client was left open. One context manager now owns start and stop around a record, in both the manager and the DAG runner.
3. That record's write and the recall after it addressed different owners: a real config spells its keys in camelCase and the block reaches the backend as written, while the adapter read only the contract's snake_case, so a sub-agent's memories were filed under the host identity. The adapter reads both spellings.
4. Legacy embedding discovery had narrowed to the recorded plugin root, so an install predating root recording lost its knowledge-base endpoint with a valid file still on disk.

The five follow-ups the seam left behind are in this PR too, rather than in three stacked ones, because they are one goal and the branch protection dismisses an approval on every push:

• The embedding endpoint is raven's. A knowledge base indexes inside the gateway process and never speaks to the memory service, yet it read its endpoint out of everos.toml, so selecting another backend left it with no vectors and no message naming the cause. Raven holds the block now and hands it to the backend at start -- as a shared default, not an override: a plugin that was given an endpoint of its own keeps it, and only one that has none takes raven's. Discovery of an existing everos.toml still checks all three places the plugin itself looks, read with plain tomllib so it works where the plugin is not installed. No data migrates: a base is keyed on its model and measured width, not on the base url.
• delete() joins the Protocol. The browser used to delete a row out of EverOS's index, in the host process, through the plugin's repository layer -- while the markdown EverOS treats as the source of truth kept the text, so the memory came back on the next rebuild, after the user was told it was gone. The adapter now uses only operations EverOS already performs, for the kinds it performs them for.
• Sub-agent memory goes through the contract. The read half is a new optional recall_session; the write half needed no new surface, only two metadata conventions written down. agents.<name>.config.everos becomes config.memory, opaque to the host except the two keys the host reads; the old spelling still loads.
• The memory and settings pages say why they are empty -- no plugin, or a backend this page does not read -- instead of four zeros and a retry button that cannot help.
• The everos package leaves the host's dependencies for the plugin's own, at the same exact pin; the host reaches the tree through the plugin. This is the package layer only: the installers already deliver everos-memory as a sibling wheel from the same release, so an ordinary install still has long-term memory.

The boundary guard's allowlist falls from five entries to two, both GUI surfaces still shaped around EverOS's own store. Generalising their wire is a frontend change and is deliberately not in scope.

This branch was reviewed on GitLab as merge request 639 over three rounds, including a post-rebase range-diff check. It is being moved here because GitHub is now the source of truth.

Type

• Refactor

Verification

• uv run pytest on this branch, rebased onto main: 22146 passed, 4 failed, 45 skipped. Three of the four (test_agents_oncall_launcher, test_agent_loop_token_budget, test_agents_code_launcher) were re-run on a detached checkout of that same main commit in this environment and fail there identically. The fourth (test_ppt_engine_image_search) could not run in that checkout, whose environment lacks the deck engine's extras; this branch's only change anywhere under plugins-dist/ppt-engine is the removal of the enabled_by_default manifest key, which that test does not reach. So this branch adds no regression.

• npx vitest run in ui-web: 1680 passed across 103 files. npm run type-check and npm run gen:check clean, so the generated client matches the contract.

• Every fix in the follow-up commits was mutated away and its test confirmed red, then restored and confirmed green. For the record path that is three separate mutations: dropping start(), dropping stop(), and narrowing the owner lookup back to one spelling.

• uv run ruff check . and uv run ruff format --check on the changed files: clean.

• uv lock --check: consistent.

• scripts/check_commit_messages.py, scripts/check_large_files.py, scripts/check_source_language.py over the branch range: clean.

• Manual acceptance against a real isolated install (temporary RAVEN_HOME, isolated EverOS root and port), 34 cases: raven plugins, raven doctor across four backend states, raven onboard interactive and non-interactive including all three step-4 lanes, raven import refusing and importing, an end-to-end write and recall, the web UI's memory and settings pages driven through a real browser, a sub-agent trace record, and an install with no memory plugin at all. 31 passed; 1 failed and was fixed; 1 partial; 1 carried over from the earlier round.

• The failure is the one worth reading. On a fresh managed install the wizard reported embedding configured and the service it started the next moment ran keyword-only: the spawned process carried no EVEROS_EMBEDDING__ values, and EverOS logged that the embedding key was not configured. The rule deciding whether everos.toml already held an operator's own endpoint asked whether its model name was a "<...>" placeholder; the shipped template seeds every section with a real model name and an empty key, so every fresh install read as a deliberate choice and the host's endpoint was never bound. It now asks the criterion the module already had -- model and key. The unit tests missed it because each built its "operator's own" section with a key in it; the regression copies the shipped template itself.

• The partial: the memory page's search returned relevant results without error, but every memory in the test corpus was on one subject, so narrowing could not be observed. The carried-over case is the skill-source prefix, whose path this branch does not touch.

• Findings recorded and not fixed here, none introduced by this branch: a progress spinner is still drawn after import reports it imported nothing; an unsupported delete surfaces as a generic internal error; the TUI log and doctor word "no memory plugin" differently; a turn that did reach disk still prints that it was not written.

• The partial case: an induced agent skill is discovered through find_skill with the backend's prefix, but read_skill / use_skill on that id fail. Nothing writes the on-disk layer those tools look in, on this branch or on main, and no test covers it. Pre-existing; filed as a follow-up.

• Relevant tests pass locally

• Relevant lint / type checks pass locally

• User-facing docs or screenshots are updated when needed

Risk

User-visible changes:

1. User-track recall is now strictly bounded by top_k. A profile row used to ride outside that bound.
2. raven doctor builds the plugin factory, so a managed EverOS setup writes its env var and config templates during a doctor run. It used to be read-only. The --json memory section is reshaped around health.checks.
3. A third-party drop-in plugin without enabled_by_default = true used to be skipped and now loads.
4. The loader no longer back-fills the EverOS config slice's root / owned, nor strips a legacy mode key; a leftover mode now draws an unknown-key warning.
5. The wizard's recap shows the contribution name everos rather than EverOS.
6. use_skill with an unknown prefix reports "not found" after a disk lookup instead of "unknown source".

From the follow-ups:

7. Config gains an optional top-level embedding block. Absent, the knowledge base reads the EverOS file as before and says so once. An operator who moves the values across changes nothing else; one who names a different model there gets the existing StaleBaseError telling them to rebuild that base. The block is a default for the memory plugin rather than an override, so an install that had configured the plugin separately keeps what it had. Note that a config carrying this block does not load on an older Raven, which rejects unknown top-level keys.
8. agents.<name>.everos is written back as agents.<name>.memory. The old spelling still loads; a per-agent baseUrl is ignored with a warning, having never had a user.
9. Deleting a memory now changes what EverOS treats as the source of truth, so it stays deleted. Profiles and cases report that they cannot be deleted rather than appearing to succeed.
10. pip install raven no longer pulls the memory engine in. install.sh and install.ps1 are unaffected: both already resolve everos_memory-*.whl from the release they install and pass it as --with everos-memory, and the source path installs it editable, so those installs keep long-term memory. An install that reaches neither -- a release predating the sibling wheel, or a bare pip install -- now boots without memory and says which distribution to install rather than failing on an import.

Found after the acceptance run, in review, all fixed here. They share one cause worth stating once: the endpoint acquired a second home, and each fix taught one more reader about it while leaving the next one behind.

11. The endpoint the wizard saved never reached the EverOS process it then started. The rule for "does everos.toml already hold an operator's own endpoint" asked whether its model name was a "<...>" placeholder; the shipped template seeds every section with a real model name and an empty key, so every fresh managed install read as a deliberate choice and the host's endpoint was never bound. The service came out of the wizard running keyword-only while the wizard said embedding was configured. The rule now asks the criterion the module already had: model and key.
12. The exported EVEROS_EMBEDDING__* variables are a third home, documented by EverOS and ranked above its file. They were being overwritten. A complete triple is now an operator's choice; an incomplete one is not an endpoint and is replaced whole rather than topped up from the host.
13. Raven writes those same variables itself at startup, so a reader that asked only whether all three were set called raven's own binding an operator's export -- a blank settings card and a save refused by naming variables nobody had set. The module now records which of them it set.
14. That record lived in a module-level set, and raven gateway --restart re-launches through os.execv: the values survive, module state does not. The record now travels in a variable beside them, and is stripped from the environment handed to EverOS.
15. A settings save the environment would outrank is refused with the variable names, rather than written and silently ignored.

Four of the five arrived one per review round, each in the fix for the one before it. The tests that missed them all shared a shape: each built its "an operator configured this" fixture with a key in it, or cleared the environment before the case, so the states the product actually produces -- a template with no key, a live process that has just bound its own endpoint -- were never the input. The regressions now copy the shipped template, and run the startup sequence and a second interpreter rather than a prepared state.

Rollback is a revert of the branch: the seam is additive, and memory.backend keeps its shipped default.

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

Related Issues

N/A

[gloryfromca]

Blocking: onboarding can erase a selected backend when its optional onboarding contribution is absent.

Reviewed github/main...07836b5bbbc3, the affected callers, relevant history, and the plugin/onboarding contracts. Coverage included AGENTS.md and CONTEXT terminology, the full diff, callers and compatibility behavior, test changes for weakening, and the memory-plugin architecture constraints. One concrete blocker is marked inline.

Verification: git diff --check github/main...HEAD passed. After syncing the documented Python 3.12 dev environment with uv sync --frozen --python 3.12 --extra dev --dev, the 38 changed Python test modules passed: 1,611 passed and 34 skipped in 46.75s. An initial run in the unsynced Python 3.13 environment failed because the dev/plugin packages were absent; that was an environment setup result, not treated as a branch failure. The focused reproduction described inline also confirmed the config-clearing path.

[gloryfromca]

Blocking: the new sub-agent memory path and legacy embedding fallback need correction.

Reviewed f114e08 against github/main and the seven-commit delta from the prior revision. Coverage included the repository rules (AGENTS.md/CLAUDE.md and the relevant CONTEXT material), the full diff, new callers and lifecycle ownership, history, compatibility for existing installs, dependency boundaries, tests and whether their mocks hid production behavior, and the plugin-seam architecture. The earlier onboarding blocker is fixed and its thread is resolved.

The three concrete regressions are marked inline. The per-record backend lifecycle also appears in dag_runner.py; the manager anchor names the shared defect.

Nonblocking follow-up, within the explicitly deferred EverOS-shaped GUI surface: settings.everos does not check memory.backend, so an installed but unselected EverOS plugin still returns available=true despite the response contract saying this state gets a note.

Verification: git diff --check github/main...HEAD, uv lock --check, and focused Ruff checks passed. Local uv run --frozen --python 3.12 pytest -q finished with 21,838 passed, 65 skipped, and one failure in untouched test_cli_theme.py::test_bold_accent_renders_styled_not_bare; CI's Python run had 22,096 passed and 52 skipped, then failed the changed-line coverage gate at 88.16% versus 90%. The TUI job failed because generated RPC types are out of sync with openrpc.json; a local TUI type-check could not start because JavaScript dependencies are not installed (tsc: not found). Page, RPC-contract, lint, bridge, wheel-smoke, repository, title, and commit-message checks passed.

[gloryfromca]

Blocking: fresh managed onboarding must launch EverOS with the embedding endpoint it just saved.

The three findings from f114e08 are fixed, replied to, and resolved. A range-diff confirmed the earlier 25 PR commits are patch-identical after the base update; review therefore covered the complete github/main...HEAD diff and the new 7416ee980 delta, its callers and process lifecycle, history, backward compatibility, dependency and plugin boundaries, the repository rules (AGENTS.md/CLAUDE.md and relevant CONTEXT material), and whether tests were weakened. The replacement lifecycle and config-shaped tests are materially stronger.

One regression introduced by the fix commit remains inline. It meets the round-four blocker bar: the new host-owned write introduces it, choosing embedding during ordinary fresh managed onboarding reaches it, and the normal product paths leave the already-running service on the placeholder config with no way for the operator to apply the saved endpoint.

The previously named nonblocking GUI follow-up remains: settings.everos still reports available=true when EverOS is installed but another memory.backend is selected, despite its response contract describing that state as unavailable with a note. This stays deferred with the EverOS-shaped GUI surface.

Verification: the focused seven-file suite passed (1,037 tests), including all three fixed paths. git diff --check github/main...HEAD, uv lock --check, and focused Ruff checks passed. All four CI Python shards passed; the aggregate coverage gate is red at 88.97% versus 90%, and the TUI job is red because its generated RPC types are out of sync with openrpc.json. The remaining listed CI checks passed.

[gloryfromca]

Blocking: onboarding still launches EverOS without the embedding endpoint it just saved.

The 7416ee9..1d4add1 delta adds sub-agent regression tests and regenerates TUI RPC types; it does not change the production onboarding path identified in the open thread at plugins-dist/everos-memory/raven_everos/onboard.py. A range-diff confirms the previously reviewed production commits are otherwise unchanged, so that blocker remains open and is not duplicated inline here.

Review coverage: repository rules (AGENTS.md, CLAUDE.md, and the applicable CONTEXT files), the full prior diff plus this exact range-diff, affected callers and history, backward compatibility, test-strengthening versus weakening, and the plugin/host seam constraints. The added tests strengthen failure and lifecycle coverage; no tests were weakened.

Verification: uv run --frozen --python 3.12 pytest -q tests/test_subagent_memory.py tests/test_subagent_manager.py tests/test_subagent_dag_runner.py passed (443 tests); focused Ruff, uv lock --check, and git diff --check github/main...HEAD passed. GitHub CI is fully green, including all four unit shards and the coverage gates.

[gloryfromca]

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

The fresh-configuration launch failure is fixed, and its thread is resolved. One narrower rerun case remains as a nonblocking follow-up: keeping an existing host embedding does not bind it before the wizard restarts EverOS. Reconfiguring the same endpoint is a working recovery, so this does not meet the late-round blocker bar.

Review coverage: repository rules (AGENTS.md, CLAUDE.md, and applicable CONTEXT files), the full prior diff plus the exact revision range-diff, affected callers and launch history, backward compatibility, test-strengthening versus weakening, and the plugin/host seam constraints. No tests were weakened.

Verification: the focused onboarding/config suite passed (380 tests), the EverOS backend suite passed (167 tests), focused Ruff, uv lock --check, and diff checks passed. Both pytest runs reported only warning-level wall-clock ceiling notices (four each). GitHub CI is fully green, including all unit shards and coverage gates.

[gloryfromca]

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

The new commit only documents the existing host/plugin ownership asymmetry. Its range-diff leaves every previously reviewed behavior unchanged, introduces no new defect, and does not alter the already named nonblocking onboarding follow-up. All threads opened by this review are resolved.

Review coverage: repository comment/documentation rules (AGENTS.md), the applicable CLAUDE.md and CONTEXT guidance, the exact delta and full range-diff, affected callers and history, backward compatibility, test weakening, and the plugin/host seam constraints. The added explanation records a non-obvious ownership constraint; no tests or production behavior changed.

Verification: the corrected focused command covering onboarding and both Raven config modules passed (381 tests), with four warning-only wall-clock ceiling notices. An initial command named nonexistent tests/test_config.py, collected zero tests, and was not counted. Focused Ruff, uv lock --check, and git diff --check github/main...HEAD passed. GitHub CI is fully green, including all four unit shards and coverage gates.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

The 2078f0cd8773..2f3363826728 delta settles the remaining nonblocking follow-up. The child-environment builder is the spawn's sole production caller, now fills Raven's saved embedding endpoint for both fresh and keep-current onboarding, preserves any deliberate backend binding with setdefault, and shares the TOML-precedence rule through embedding_env. The write-site special case is removed, and existing production commits are otherwise unchanged by range-diff. All threads opened by this review are resolved.

Review coverage: repository rules (AGENTS.md, CLAUDE.md, and applicable CONTEXT files), the full prior diff plus this exact delta and range-diff, affected spawn/runtime callers and history, backward compatibility and precedence, test-strengthening versus weakening, and the plugin/host seam constraints. No tests were weakened.

Verification against a detached checkout of the live PR head: uv run ... python -m pytest -n0 over onboarding, EverOS config, server, and backend passed (623 tests), with two warning-only wall-clock ceiling notices. Preliminary detached-environment invocations collected no tests because their pytest process lacked the transient plugin import; they were corrected rather than counted. Focused Ruff, uv lock --check, and diff checks passed. GitHub CI is fully green, including all unit shards and coverage gates.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

Reviewed the new settings-routing commit against the unchanged previously reviewed range. The card now reads and writes the same endpoint home as the runtime: an operator-authored EverOS embedding section keeps precedence, while the ordinary host-owned lane uses Raven's embedding block. The web caller's partial update and redacted-key behavior remain safe because the host writer merges non-empty fields, and the extracted precedence helper preserves the prior binding behavior.

Coverage included the repository rules in AGENTS.md/CLAUDE.md and the relevant CONTEXT terms, the base diff plus range history, RPC and web callers, the OpenRPC shape, backward-compatible merge/secret behavior, the plugin/runtime ownership boundary, and the changed tests for weakening. No test was skipped or weakened to obtain a pass.

Verification: uv run --frozen --python 3.12 pytest -q tests/test_rpc_settings.py tests/test_rpc_contract_shapes.py tests/test_config_update_everos.py tests/test_everos_server.py tests/test_everos_backend.py passed 370 tests; focused Ruff and git diff --check passed. The local UI test command could not start because this reviewer worktree has no installed Vitest binary, while GitHub's page checks, UI RPC contract, all four Python unit shards, coverage, lint, and every other reported check are green. The PR is mergeable.

[gloryfromca]

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

The rebased series is patch-equivalent to the previously reviewed revision through the settings-page fix. The two new commits correctly stop treating the shipped EverOS template as an operator-authored embedding endpoint: the real template supplies a model and base URL but no key, and EverOS's provider factory requires all three. The production-shaped template test preserves that distinction, and the accompanying RPC edit only corrects its explanation.

Named follow-up (nonblocking, no open thread): preserve a complete endpoint supplied through the documented EVEROS_EMBEDDING__* environment variables. everos_has_own_embedding() now examines only TOML, and configure_embedding_env() applies the host fallback with os.environ.update(). On this head, starting from the shipped template with all three operator environment values set caused the helper to return True and replace all three with Raven's host endpoint. Treating a complete existing environment endpoint as an explicit EverOS choice, or otherwise sharing the non-overwriting rule used by _child_env(), would preserve the documented override. This revision introduces the behavior, but an operator can recover by recording the endpoint in everos.toml, so it does not meet the late-round blocker bar.

Coverage included AGENTS.md/CLAUDE.md and the relevant CONTEXT terms, the full base range plus rebase history, backend startup and server callers, RPC behavior, backward compatibility, the memory-plugin ownership seam, and the changed tests for weakening. Verification on the live head: uv run --frozen --python 3.12 pytest -q tests/test_config_update_everos.py tests/test_rpc_settings.py tests/test_everos_server.py tests/test_everos_backend.py tests/test_cli_onboard_commands.py passed 653 tests; focused Ruff and git diff --check passed. GitHub's four unit shards and all other completed checks passed; the coverage aggregation was still pending when checked.

[gloryfromca]

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

The documented environment override is now preserved: a complete EVEROS_EMBEDDING__* endpoint wins over Raven's host block, while an incomplete fragment falls back to the complete host endpoint instead of producing a mixed triple. This settles the previous follow-up.

Named follow-up (nonblocking): everos_has_own_embedding() now selects the EverOS side of the settings read/write path for a complete environment override, but settings_everos() reads values only from everos.toml and settings_everos_set() writes them there. With the documented override exported and the shipped template on disk, the service uses the environment endpoint while the settings card displays the template as unconfigured; saves target TOML and remain outranked by the environment. Managing the exported variables is a working recovery, so this does not meet the late-round blocker bar, but the settings surface should eventually represent this third, externally managed home explicitly.

Verification: the changed config/server suites passed (129 tests) and Ruff passed. The broader focused run was not green: 3 failed, 653 passed; all three failures were the settings endpoint-home assertions encountering a complete environment endpoint. An isolated run with the complete documented override reproduced the card mismatch (1 failed). GitHub CI is fully green, and git diff --check github/main...HEAD passed.

Covered in this round: the repository rules and canonical terminology, the full base diff with emphasis on the new delta, affected callers and commit history, backward compatibility for TOML and environment precedence, test changes (none weakened), and the plugin/host seam constraints. No additional merge blockers survived refutation.

[gloryfromca]

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

The new predicate and refusal fix the silent-save behavior for a genuine operator-exported endpoint, and the ambient-environment fixtures make the unit assumptions deterministic.

Named follow-up (nonblocking): the predicate cannot distinguish an operator's exported endpoint from the identical variables Raven writes itself. In the ordinary runtime sequence, configure_embedding_env(host_endpoint) first copies Raven's host block into os.environ; a subsequent settings.everos call then renders the template as an empty embedding card, and settings.everosSet rejects the edit as shell-managed. The reproduction returned bound_by_raven=True, an empty card, and the new “change them instead” error. A manual config edit plus restart remains a working recovery, so this introduced and ordinarily reachable defect does not satisfy the late-round requirement that an operator have no working way out. The eventual fix needs provenance for the environment triple, rather than treating every complete live-process triple as external.

Verification: uv run --frozen --python 3.12 pytest -q tests/test_config_update_everos.py tests/test_everos_server.py tests/test_everos_backend.py tests/test_rpc_settings.py tests/test_cli_onboard_commands.py passed all 657 tests; Ruff and git diff --check github/main...HEAD passed; GitHub CI is fully green. The focused tests do not catch the lifecycle sequence because the new autouse fixtures deliberately clear the process variables before each RPC test.

Covered in this round: repository rules and canonical terms, the full branch diff with emphasis on the dff7410adf68..8a707009c1f6 delta, callers and startup/settings lifecycle, commit history, environment/TOML backward compatibility, whether tests were weakened, and the plugin/host seam constraints. No merge blocker survived refutation, and all previously opened threads remain resolved.

[gloryfromca]

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

The new _BOUND_HERE provenance closes the ordinary in-process startup/settings failure: Raven's first binding is no longer mistaken for an operator export, repeated backend starts keep using the host endpoint, and a genuine pre-existing environment endpoint is still preserved and protected from ineffective settings saves.

Named follow-up (nonblocking): the provenance is module-local while Raven's /restart uses os.execv. That restart preserves the Raven-written EVEROS_EMBEDDING__* values but reloads the module with an empty _BOUND_HERE, so the restarted gateway again classifies its own binding as external, declines the second bind, and returns to the blank/refused settings behavior. The exec-shaped reproduction produced first_bind=True, managed_before_exec=False, then managed_after_module_reset=True and second_bind=False. This is introduced and /restart is an ordinary path, but stopping and launching Raven from a clean shell or supervisor remains a working recovery, so it does not meet the late-round blocker requirement. Provenance needs to survive the exec boundary (or the binding must avoid surviving without it).

Verification: the focused onboarding/config/server/backend/RPC suites passed all 659 tests; Ruff and git diff --check github/main...HEAD passed; GitHub CI is fully green. The added tests correctly cover the in-process sequence but do not exercise environment survival across a module/process reset.

Covered in this round: repository rules and canonical terms, the full branch diff with emphasis on 8a707009c1f6..24df741f197a, affected callers and restart history, backward compatibility for operator exports and TOML precedence, whether tests were weakened, and the plugin/host seam constraints. No merge blocker survived refutation, and all previously opened threads remain resolved.

[gloryfromca]

No blockers; this can merge as far as I am concerned.

The restart provenance follow-up is fixed. Raven now carries the binding marker through its os.execv restart alongside the values it describes, reloads that provenance in the replacement interpreter, and strips the private marker from the environment handed to EverOS. The two-interpreter regression test covers the actual preservation/reset boundary; genuine operator exports still remain external, while Raven's binding remains editable and can be refreshed after restart.

Verification: the focused onboarding/config/server/backend/RPC suites passed all 660 tests; Ruff and git diff --check github/main...HEAD passed; GitHub CI is fully green.

Covered in this round: repository rules and canonical terms, the full branch diff with emphasis on 24df741f197a..72b056d4e0fd, affected startup, spawn, settings, and restart callers plus history, backward compatibility for operator exports and TOML precedence, whether tests were weakened, and the plugin/host seam constraints. No candidate finding survived a concrete-failure check, and every previously opened thread remains resolved.

[gloryfromca]

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

The model/provider embedding pin is coherent through schema migration, provider resolution, onboarding, RPC, knowledge resolution, and the EverOS launch handoff. Three bounded follow-ups remain; they are named here rather than left as open threads:

• Clearing the embedding picker through its Inherit option is a no-op. PinRow sends {model: "", provider: ""}, but set_embedding_endpoint filters both values and returns before writing. A direct reproduction left the old pair unchanged. Editing the config is a working recovery, so this does not meet the late-round blocker bar.
• A legacy-only endpoint in everos.toml is no longer a runtime fallback. An upgraded knowledge base remains unavailable until the operator migrates the endpoint; moreover, doctor --fix records the fix as applied even when adopt_legacy_endpoint returns False because no configured provider matches a custom legacy URL. Provider setup plus settings/doctor is a recovery, so this is also nonblocking.
• The canonical SkillForge entry in CONTEXT.md still says the local extraction pipeline is skillForge.everos and belongs to embedded EverOS. The code and migration now call it skillForge.extraction and explicitly make it plugin-independent.

At review round 17, none of these meets all three required conditions for a blocker: the first two have working recovery paths, and the documentation mismatch causes no runtime failure.

Coverage: I read AGENTS.md / the identical CLAUDE.md, CONTEXT-MAP.md, and the relevant Runtime terminology; reviewed git diff github/main...HEAD, the range-diff from the previously clean revision across the rebase, the ten-commit embedding redesign, and the final half-pin commit; traced callers and history; checked backward compatibility, test changes, and the plugin-seam constraints. git diff --check and Ruff pass. The focused config/onboarding/doctor/RPC/knowledge/contract run passes (910 tests). The changed real-LLM integration test was also attempted; it failed before exercising the scenario because this environment has no EverOS LLM key/base URL. The local web test could not start because vitest is not installed here; GitHub's page check is green. At posting time all completed GitHub checks are green, with the four unit shards still running.