Repository navigation
Feat/onboard default extension blocks - #11
Merged
Merged
Conversation
EverOS defaulted both its user-level config toml and its data root (sqlite / lancedb / .index / ome.db) to a bare ~/.everos. Scope raven's instance under ~/.everos/raven so config and data stay isolated from any other EverOS consumer on the machine. Add update_everos.configure_everos_env(): it sets EVEROS_CONFIG_FILE and EVEROS_MEMORY__ROOT via setdefault (so an explicit operator override still wins) before EverOS's @cache-d load_settings() first runs. The everos backend factory and the understand_media tool factory call it as the earliest raven-controlled EverOS entry points; _EVEROS_CONFIG now derives from a single _EVEROS_BASE constant. No data migration: existing ~/.everos data is left untouched and a fresh ~/.everos/raven is created lazily on first write/use. Co-authored-by: Claude (claude-opus-4-8) <noreply@anthropic.com>
A fresh onboard now materializes the user-facing subset of the memory / plugins / skillForge extension blocks into ~/.raven/config.json so the knobs are discoverable and editable without reading the source. Seeding is setdefault-based (non-clobbering) and runs on every onboard, so it also backfills a pre-existing config that predates these blocks. - memory.backend defaults to "everos" (schema default); _memory_enabled now gates on an llm model being present, so a fresh modelless seed is treated as "not yet enabled" and the skip / non-interactive guard still resolves it to None when memory is opted out or left unconfigured. - skillForge.everos.enabled is seeded on; router.hub.endpoint is seeded to the shared Skill Hub URL with apiKey left null for the user to fill. - plugins.config["everos-memory"] is seeded with identity wiring that mirrors memory.userId / agentId so recall identities match. - internal-infra fields (embedding / reranker endpoints + their API keys, mass_library_db) are NOT written, so a real Bearer token never lands in a plaintext config; they stay at their schema defaults. Co-authored-by: Claude (claude-opus-4-8) <noreply@anthropic.com>
KevinHuSh
pushed a commit
to KevinHuSh/Raven
that referenced
this pull request
Sep 14, 2026
…lt_extension_blocks Feat/onboard default extension blocks
KevinHuSh
pushed a commit
to KevinHuSh/Raven
that referenced
this pull request
Sep 14, 2026
…as no address for it ## Summary Fixes the key-only regression reported in EverMind-AI#11: 56 curated models on dashscope, moonshot, groq and nvidia_nim stopped constructing a provider after the model-family protocol inference landed, because the family name inferred `responses` and `native_api_base` rightly refused to invent an address for a protocol those providers never declared. Two rules now govern the choice, both in `raven/providers/protocol.py`: - A protocol the user configured (`protocol` / `modelProtocols`) is final. Choosing `responses` for a provider with no address for it is still refused, as before. - A protocol merely inferred from the model family steps aside to `chat` when the provider declares no address for it. `effective_protocol` takes the provider name and the configured address for this; the factory and the model picker pass them. The bare inference (no provider named) is unchanged, so protocol tables and picker labels read as before. - The gateway fallback to a default address now applies only to a gateway that declares no per-protocol address at all (openrouter, custom). volcengine declares a `responses` address only, so an `anthropic` request no longer receives it: `volcengine/glm-4-7-251222` goes over chat instead of posting `/v1/messages` to a responses endpoint, and the picker can warn where a base is genuinely missing. The OpenRouter question from the acceptance note is answered: `POST https://openrouter.ai/api/v1/responses` was exercised live (200, `object: response`), so the 35 openrouter rows that route to Responses are served. ## Type - [x] Fix - [ ] Feature - [ ] Docs - [ ] CI / tooling - [ ] Refactor - [ ] Other ## Verification - Key-only sweep over every (provider, picker model) pair, base `ce2e0b91` vs this head, same script: `compared: 440 WORKED -> REFUSES: 0 REFUSED -> WORKS: 56` (dashscope 33, moonshot 12, groq 6, nvidia_nim 5); the only other change is `volcengine/glm-4-7-251222` moving from `AnthropicMessagesProvider` to `LiteLLMProvider` (chat). The 68 pairs that fail on both trees are OAuth sign-in providers (github_copilot, minimax) and ollama without a running server. - `pytest -q tests/test_provider_protocol.py tests/test_providers_factory.py tests/test_rpc_model.py`: 242 passed (three new tests: the four-provider fallback, the explicit-choice refusal, the partial-declaration gateway). - `pytest -q tests/test_provider*.py tests/test_providers*.py tests/test_rpc_model.py tests/test_cli_doctor_commands.py`: 958 passed, 1 failed (`test_doctor_answers_where_the_memories_are`, environment-dependent on the development box, fails identically on `main`). - `lint-imports`: 9 contracts kept, 0 broken. `ruff format --check` and `ruff check` over `raven` and `tests`: clean. - [x] Relevant tests pass locally - [x] Relevant lint / type checks pass locally - [ ] User-facing docs or screenshots are updated when needed ## Risk - [x] Security impact considered - [x] Backward compatibility considered - [x] Rollback path is clear for risky changes Behaviour change: an inferred native protocol on a provider without an address for it falls back to chat instead of failing; an info log names the fallback. Explicit selections are untouched. Only volcengine is affected by the narrowed gateway fallback (the one gateway declaring a partial protocol map). Rollback is a revert of the squash commit. ## Related Issues Fixes EverMind-AI#11
KevinHuSh
pushed a commit
to KevinHuSh/Raven
that referenced
this pull request
Sep 14, 2026
…as no address for it ## Summary Fixes the key-only regression reported in EverMind-AI#11: 56 curated models on dashscope, moonshot, groq and nvidia_nim stopped constructing a provider after the model-family protocol inference landed, because the family name inferred `responses` and `native_api_base` rightly refused to invent an address for a protocol those providers never declared. Two rules now govern the choice, both in `raven/providers/protocol.py`: - A protocol the user configured (`protocol` / `modelProtocols`) is final. Choosing `responses` for a provider with no address for it is still refused, as before. - A protocol merely inferred from the model family steps aside to `chat` when the provider declares no address for it. `effective_protocol` takes the provider name and the configured address for this; the factory and the model picker pass them. The bare inference (no provider named) is unchanged, so protocol tables and picker labels read as before. - The gateway fallback to a default address now applies only to a gateway that declares no per-protocol address at all (openrouter, custom). volcengine declares a `responses` address only, so an `anthropic` request no longer receives it: `volcengine/glm-4-7-251222` goes over chat instead of posting `/v1/messages` to a responses endpoint, and the picker can warn where a base is genuinely missing. The OpenRouter question from the acceptance note is answered: `POST https://openrouter.ai/api/v1/responses` was exercised live (200, `object: response`), so the 35 openrouter rows that route to Responses are served. ## Type - [x] Fix - [ ] Feature - [ ] Docs - [ ] CI / tooling - [ ] Refactor - [ ] Other ## Verification - Key-only sweep over every (provider, picker model) pair, base `ce2e0b91` vs this head, same script: `compared: 440 WORKED -> REFUSES: 0 REFUSED -> WORKS: 56` (dashscope 33, moonshot 12, groq 6, nvidia_nim 5); the only other change is `volcengine/glm-4-7-251222` moving from `AnthropicMessagesProvider` to `LiteLLMProvider` (chat). The 68 pairs that fail on both trees are OAuth sign-in providers (github_copilot, minimax) and ollama without a running server. - `pytest -q tests/test_provider_protocol.py tests/test_providers_factory.py tests/test_rpc_model.py`: 242 passed (three new tests: the four-provider fallback, the explicit-choice refusal, the partial-declaration gateway). - `pytest -q tests/test_provider*.py tests/test_providers*.py tests/test_rpc_model.py tests/test_cli_doctor_commands.py`: 958 passed, 1 failed (`test_doctor_answers_where_the_memories_are`, environment-dependent on the development box, fails identically on `main`). - `lint-imports`: 9 contracts kept, 0 broken. `ruff format --check` and `ruff check` over `raven` and `tests`: clean. - [x] Relevant tests pass locally - [x] Relevant lint / type checks pass locally - [ ] User-facing docs or screenshots are updated when needed ## Risk - [x] Security impact considered - [x] Backward compatibility considered - [x] Rollback path is clear for risky changes Behaviour change: an inferred native protocol on a provider without an address for it falls back to chat instead of failing; an info log names the fallback. Explicit selections are untouched. Only volcengine is affected by the narrowed gateway fallback (the one gateway declaring a partial protocol map). Rollback is a revert of the squash commit. ## Related Issues Fixes EverMind-AI#11
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Change description
Type of change
Related issues (if there is)
Checklists
Development
Security
Code review