[LivXue]

Summary

Fresh installs never searched the Skill Hub from a conversation. Onboarding
used to seed skillForge.router.hub.endpoint, but the wizard rewrite retired
init_extension_block_defaults and took the seed with it; the schema default
stayed None so programmatic loads remain Hub-disabled. The Skill Hub page
kept working on its own default URL, which made the gap easy to miss.

This restores the seed as a narrow writer instead of the retired defaults
block: onboarding writes the shared endpoint, keeps an endpoint the config
already names, leaves apiKey to the user, and does not re-enable a source a
config turned off.

It also adds skillForge.router.hub.enabled (default true) and a Skills-page
switch, so the source can be turned off without discarding a custom endpoint.
Both readers -- the router source and the shared client behind read_skill,
use_skill and find_skill -- require endpoint and enabled. The default
keeps endpoint-only configs working after an upgrade. The agent's self-config
surface lists the same key, and the row reads "Use 110k+ skills from EverMind
Skill Hub".

Review of the switch found that the settings page read only the camelCase
spelling of a top-level config block, while the loader accepts both spellings
and the writer keeps the one the file already carries. The switch is fixed in
this PR, and so are two same-class defects that predate it: the Skills page's
blocklist and the gate and title model-role slots read hard-coded camelCase
paths. Under a snake_case block the switch showed off and sent true on every
click (so the page could not turn the source off), every skill counted as on,
and those two roles drew as following the chat model. The blocklist and role
defects are folded into this PR at the maintainer's request because one
resolver covers all three. A top-level segment now takes the camel spelling
unless it is null, then the snake one, matching the loader's first non-null
rule and the writer's spelling-preserving update.

The second review round found the switch was not live: it wrote the file while
the serving loop kept its Hub client and router source, so a person who
switched remote retrieval off saw it off while turns kept sending their text
to the Hub. Both readers and the Hub tools now ask the live config before
each call, and the client is built whenever an endpoint exists, so both
directions apply without a rebuild. The web wizard also seeds the endpoint at
finish now -- the installer's default entrance used to leave the source off --
without re-enabling a config that switched it off. The setting is marked
sensitive.

An independent review round found the on/off state decided in four places
that could disagree, and this PR now answers it from one predicate,
skill_hub_on, which reads the file the way the loader does:

• The loader migrates two legacy shapes in memory only (a top-level
  skillRouter, the retired hub.prefetchBodies), so a file keeps them for
  good. The live reader skipped those migrations and switched off a Hub the
  runtime had built; it now runs them on a copy, once per change of the file.
  The switch writer updates a legacy router in place, instead of creating
  skillForge.router beside it and hiding its endpoint and key on the next
  load.
• The settings page draws the switch from settings.get (skill_hub_on,
  skill_hub_awaiting_reload) instead of re-deriving it from the raw file; a
  page-side copy of the boolean rules disagreed with pydantic on "y" / "t".
• find_skill renders its description per call, so the 110k-library
  sentence appears only while the Hub is searched; the client alone no longer
  decides it.
• raven_config reads show what the switch runs on (in_effect) beside the
  stored flag, which defaults to true and alone reported a Hub with no
  endpoint as on.
• The reload notice follows the serving loop (it holds no Hub client), not
  whether the write seeded the endpoint, so a second switch-on before the
  reload still says so, and the Skills row keeps saying it after the toast.
• Both wizards say what turning the source on sends and how to stop it, the
  Skills row says it, and the docs page describes it in both languages.
• A read that fails (a file the migration cannot walk, a loop that failed to
  build) answers off and no wait instead of raising.

A later independent review found two accounting defects in the same
surface. The web picker and the onboarding wizard persist the language
through config.set, which wrote the file but never moved the process
language the sentences Raven composes itself are rendered in, so a
reader who picked Chinese in the wizard could still be shown the new
Skill Hub notice in English; config.set and config.unset now move it
like settings.set already did. And the switch was still declared a
reload-only setting after it had become live: the self-config surface
told the model a reload was owed for a switch-off that stops the next
search, while a switch-on whose write had seeded the endpoint could be
reported as already serving. The setting is now declared live, and
raven_config relays the settings service's own warning instead of
dropping it, so the one write that waits still says so.

Type

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

Verification

• Relevant tests pass locally

• Relevant lint / type checks pass locally

• User-facing docs or screenshots are updated when needed

• This round, in the PR worktree (its own uv sync --frozen --all-extras
  venv): the 19 affected Python test files with -n 4, 1954 passed
  (repeated). One ordering fails at origin/main too and is not this PR's:
  run serially with tests/test_rpc_settings.py first, three env-mirror
  tests in tests/test_cli_onboard_commands.py fail identically at
  6298840e0, at the previous head and here; CI deals files to shards, and
  this round adds no test file.

• ui-web vitest run: 261 files, 4490 tests, no errors; tsc --noEmit and
  eslint over the changed files exit 0; gen-rpc-client.mjs --check,
  ui-tui gen-rpc-types.mjs --check and gen-i18n.mjs --check in sync.

• Mutations, each restored and byte-compared, 20 of 20 reddened a test:
  skipping the migration in the reader, the writer ignoring the legacy
  router, previous from the raw block, dropping the per-file cache, either
  read-failure guard, settings.get answering off, the page ignoring it,
  find_skill ignoring the switch or keeping the registered schema, the
  wiring dropping its reader, in_effect hidden from get or describe, the
  wait ignoring the loop, the wizard notice dropped or untranslated, the CLI
  line dropped or printed when nothing turned on, the row's disclosure
  dropped, the snapshot dropping the wait.

• ruff check, ruff format --check and lint-imports (10 kept): pass.
  check_source_language.py and check_large_files.py over
  origin/main...<worktree snapshot>: exit 0; a snapshot with one CJK line
  added to raven/config/live.py is reported, as a control.

• After rebasing onto 11ca10d84 (a ui-web shell change, no file in
  common): ui-web src/features/settings, src/features/onboard, src/rpc,
  src/chrome and src/state (84 files, 1243 tests), tsc --noEmit, and
  seven of the Python files (687 passed) re-run: pass.
  scripts/check_commit_messages.py origin/main..HEAD: exit 0.

• The two fixes above, in the PR worktree: the four touched test files,
  743 passed; each new test was watched failing at the previous tree
  first. The full unit suite with -n 4: 37080 passed, 8 failed -- the
  same 8 IDs on the merge base 11ca10d8 in this box's own checkout
  (five provider proxy cases, the LibreOffice xls conversion, npm on
  PATH, and the root-readable file), so none is this PR's.

• Not re-run this round: native Windows (the two fixes are
  platform-neutral: process-language state and a tool's reply string),
  ty check, vite build / ui-web/build.py, the docs build.

Risk

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

New network behavior: an onboarded config now queries skillhub.evermind.ai on
qualifying turns. Existing configs without the endpoint stay off until they
onboard or flip the switch. No key is written, the endpoint remains
operator-configurable, and switching off keeps the URL.

The new field defaults to true, so endpoint-only configs behave as before
after an upgrade. Configs written by the switch carry hub.enabled; a
downgrade to a binary that predates the field would refuse it (the config
models forbid unknown keys), so roll back by reverting the release rather
than downgrading. Reverting the commit is otherwise safe.

The settings page now reads a snake_case top-level block as well as the
camelCase one, matching what the loader already accepted; no config file
needs a migration. settings.get gains two required result fields
(skill_hub_on, skill_hub_awaiting_reload); the page and the server ship
together.

The switch now applies live in both directions while an endpoint is present.
A first enable on a config that had no endpoint at loop start waits for a
reload and says so. The web wizard's finish seeds the shared endpoint unless
the config already has one, does not re-enable a config that switched the
source off, and says what turning it on sends. A legacy top-level
skillRouter endpoint now counts as on, as it already did for the runtime.

Related Issues

N/A

[gloryfromca]

Blocking: the settings switch misreports supported snake-case configs and must read the active alias.

I reviewed the full diff and the surrounding onboarding, raw-config writer, runtime construction, settings RPC/source, and web rendering paths. I found one concrete backward-compatibility defect inline.

Verification:

• uv run pytest tests/test_config_update.py tests/test_rpc_settings.py tests/test_cli_onboard_commands.py tests/test_context_engine_factory.py tests/test_agent_loop_skill_tools.py tests/test_config_raven_sections.py -k 'not test_the_login_shell_capture_actually_sees_the_keys' - 730 passed, 1 deselected.
• The non-deselected run failed only at that unrelated login-shell environment test after 620 passes because the spawned shell did not expose its generated keys.
• Focused Hub selection - 41 passed.
• npm test -- --run src/features/settings/pages/Skills.test.tsx - 8 passed.
• npm run type-check - passed.

Coverage included AGENTS.md and the runtime/web context rules, the diff, callers, relevant alias-preservation history, backward compatibility, test-strength review, and the RPC boundary architecture. I found no CLAUDE.md in scope.

[LivXue]

Windows compatibility review — PR #1141 @ cebc1dc678019a37944a3acd04f990c84bc7cab7

Scope: the full base-to-head diff at this head (19 files, +501/−37) — the onboarding seed, the new skillForge.router.hub.enabled field and its writers, both runtime readers, the settings RPC, and the Skills-page switch — reviewed for Windows behaviour and exercised on native Windows.

Result: no Windows-specific defect found. The two new writers (initialize_skill_hub_endpoint, set_skill_hub_enabled) go through the existing atomic_update path, which is the repo's Windows-hardened primitive (portalocker LockFileEx sidecar, UTF-8 reads and writes, mode/DACL carry-over onto the replacement, read-only tmp cleanup); they inherit that handling instead of re-implementing it. Reads go through read_raw_or_raise (UTF-8); the JSON round-trip keeps non-ASCII values (ensure_ascii=False) and writes CRLF on Windows exactly as every other config writer already does, which stays valid JSON. _skill_hub_block honours the existing skill_forge/skillForge spelling in place, so a config keeps a single loadable block. No path, subprocess, signal, socket, permission, or line-ending assumption is introduced beyond what the shared primitive already covers.

Windows verification on native Windows 11, detached worktree D:\tmp\rv-1141 at the reviewed head, offline venv (uv sync --frozen --offline --all-extras --no-extra segmenter --dev), scratch HOME/USERPROFILE, PYTHONUTF8=1, PYTHONPATH pinned to the worktree:

• uv run --no-sync pytest tests/test_config_update.py tests/test_rpc_settings.py tests/test_context_engine_factory.py tests/test_agent_loop_skill_tools.py tests/test_config_raven_sections.py -q → 5 failed, 368 passed; the same five files at base 06509f8e → 5 failed, 327 passed; failing-ID sets are identical (the a2a chmod/mode cases and the /somewhere/theirs POSIX-path refusal). All 41 tests added by this PR pass on Windows.
• uv run --no-sync pytest tests/test_cli_onboard_commands.py -q → 3 failed, 355 passed; base → 3 failed, 353 passed; the same three inherited login-shell/environment IDs on both.
• npx --no-install vitest run src/features/settings/pages/Skills.test.tsx → 8 passed.
• End-to-end onboarding probe on a path with a space and CJK characters (D:\tmp\rv-1141 home 目录): _bootstrap_empty_config() created ...\.raven\config.json, wrote hub = {'endpoint': 'https://skillhub.evermind.ai'}, and the file parsed back as valid UTF-8 JSON (with the CRLF endings other config writers produce on Windows).

Coverage gaps: the full suite, the settings page's other flows, and the PR's Playwright/Chromium checks were not rerun here; ESLint is unavailable in this environment. The blocking snake-case finding already raised inline by gloryfromca (ui-web/src/features/settings/pages/Skills.tsx:32 — settings.get may return skill_forge) is a cross-platform backward-compatibility issue and is outside this Windows review's scope.

[gloryfromca]

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

The revision fixes the supported skill_forge config case by resolving the active top-level spelling before reading Hub state. Its alias precedence matches the loader and config writers, and the regression test covers both displayed state and the value sent when the active switch is clicked. The extracted helper does not regress its other settings callers. My prior thread is replied to and resolved.

Verification:

• npm test -- --run src/features/settings/pages/Skills.test.tsx src/features/settings/providers/Roles.test.tsx src/features/settings/source.test.ts - 68 passed.
• npm run type-check - passed.

Coverage included AGENTS.md and the runtime/web context rules, the full current diff and revision delta, affected callers, relevant alias-preservation history, backward compatibility, test-strength review, and the settings RPC architecture boundary. No CLAUDE.md is present in scope.

[LivXue]

Windows compatibility re-review — PR #1141 @ 984455024448f1c7584575017c4208b94ad489e3

Scope: the delta since the previously reviewed head cebc1dc6 — one UI commit (6 files, +106/−16): dig now resolves a top-level config block under either spelling (skillForge/skill_forge), Skills.tsx and Roles.tsx read the block through it, and the two settings tests gain snake-case cases. The rest of the PR (config writers, onboarding seed, settings RPC, runtime readers) is unchanged from the head reviewed in the previous round.

Result: no Windows-specific defect. The change is pure TypeScript object-shape logic with no path, filesystem, subprocess, permission, or encoding surface. toSnake maps camelCase JSON keys to their snake_case aliases; that is object-key matching, not filesystem naming, so there is no case-sensitivity difference between Windows and POSIX. This commit also closes the cross-platform snake-case finding gloryfromca raised inline on Skills.tsx:32, and its new tests cover both spellings; the Python side of that issue is unaffected.

Verification on native Windows 11, detached worktree D:\tmp\rv-1141b at the reviewed head, ui-web/node_modules junctioned read-only from the main checkout:

• npx --no-install vitest run src/features/settings/pages/Skills.test.tsx src/features/settings/providers/Roles.test.tsx → 2 passed files, 47 passed tests
• npx --no-install vitest run src/features/settings → 18 passed files, 244 passed tests
• No failures, so no base comparison was needed. The Python suites were last exercised at the previous head; this commit touches only ui-web.

Coverage gaps: the full ui-web suite, tsc --noEmit, and the PR's Playwright/Chromium check were not rerun here.

[0xKT]

Not a blocker - non-blocking items from acceptance on 98445502 (onto 959cd0a9).

Severity of this one finding, not a verdict on the pull request. Any blocking findings from this pass are review threads on the changed files; GitHub renders those collapsed, as a file name with no text.

1. The seed reaches only the CLI wizard. initialize_skill_hub_endpoint has one production caller, _bootstrap_empty_config (raven/cli/onboard_commands.py:361). Both installers end on raven web --foreground, and the page's own onboarding (model.save_key, config.set model) never reaches the seed. Once setup.status reports configured, the TUI gate skips the CLI wizard. Measured: a config onboarded through the web wizard's RPCs ends with no skillForge block and the Hub effectively off, while the CLI bootstrap on the same tree seeds https://skillhub.evermind.ai. So the default differs by entrance, and the installer's default entrance is the one that stays off. The switch can turn it on, and set_skill_hub_enabled seeds. CONTEXT.md's new "Onboarding seeds the shared catalog URL" holds for one of the two wizards.
2. The new self-config entry is not marked sensitive. skillForge.router.hub.enabled (raven/config/self_surface.py:549-555) carries no sensitive=. So in an attended smart-mode turn the reviewer may approve the agent turning remote retrieval back on after the user switched it off. With the default skillForge.autoInstall='auto', that also re-opens hub skill installs. The neighbouring skillForge.autoInstall entry is marked sensitive for that reason.
3. Disclosure. For installs onboarded through the CLI or TUI, the default now sends the turn's message text to skillhub.evermind.ai. That is a deliberate posture change; please state it where onboarding and the Skills page describe the Hub.
4. Smaller:
   • "Is the Hub source on" is decided at more than one site. The factory copy and set_skill_hub_enabled read lax booleans (0, "false") differently from the loader, so the switch can show ON for a value the loader reads as false.
   • The PR's guarantee that "a repeat onboard does not re-enable a config that turned the source off" has no test that fails when it is broken.

Tests here on the merged tree: the 6 changed Python test files via the board runner gave 731 passed. ui-web Skills.test.tsx + Roles.test.tsx: 47 passed. lint-imports: 10 kept.

[gloryfromca]

Blocking: the Skill Hub switch must update the live runtime or require and surface a reload before displaying the source as disabled.

The newly reported runtime-effect thread changes my prior clean stance. I independently verified its mechanism: this key is declared reload-only, settings.set only persists it, the existing loop retains both the Hub client and router source, and the RPC returns no warning even though the web settings source already displays one when supplied. I am not opening a duplicate finding or resolving another reviewer's thread.

Verification:

• uv run pytest tests/test_rpc_settings.py -k 'hub_switch' - 4 passed; these cover persisted config state, not live-loop recomposition.
• npm test -- --run src/features/settings/pages/Skills.test.tsx src/features/settings/source.test.ts - 31 passed; the current UI tests confirm the saved state is redrawn immediately.

[gloryfromca]

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

The live switch fix closes the previously reproduced privacy failure: an already-built router checks the current config before every Hub search, Hub-only read/install calls do the same, and retaining the client whenever an endpoint exists makes both off and re-enable live. The existing blocking thread belongs to its author to close; I have not resolved or re-graded it.

Named nonblocking follow-up: the new web-wizard skillForge.router.hub.init path seeds an endpoint after the first-run stack has already been assembled without a Hub client, but returns no reload warning. The wizard can therefore finish with the switch visually on while Hub retrieval remains inactive until a gateway restart. A restart is a working escape hatch, so at this late review round I am not holding the change for it; the init path should eventually surface the same reload cost as an endpoint-seeding switch write or arrange recomposition.

Verification:

• Focused backend Hub/config/onboarding selection - 141 passed.
• Focused web onboarding/settings selection - 61 passed.
• npm run type-check - passed.

Coverage included AGENTS.md and the runtime/web context rules, the rebased full diff via range-diff, the new commit, affected callers and lifecycle, backward compatibility, test-strength review, and the settings RPC/source boundary. No CLAUDE.md is present in scope.

[gloryfromca]

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

The new revision only adds the missing localized sensitive-confirmation sentence. Its key matches skillForge.router.hub.enabled, both locales are present, and the checked-in generated catalogue matches the source. It introduces no new issue.

The previously named nonblocking web-wizard endpoint-seed reload follow-up is unchanged. The other reviewer's blocking thread remains theirs to close; I have not resolved or re-graded it.

Verification:

• npm run lint:i18n --prefix ui-tui - passed; generated catalogue is up to date.
• npm test -- --run src/features/composer/approve.test.ts - 52 passed.
• make check-source-language could not run because make is unavailable; invoking uv run python scripts/check_source_language.py directly exited successfully but reported no commit range to check.

[LivXue]

Windows compatibility re-review — PR #1141 @ 89a964fcea6038fa1d98b982cf5e409e8e250053

Scope: the branch is rebased onto current main (which now includes #1102); the PR's own diff at this head is 855a412fa..89a964fc (35 files, +1079/−56). The two commits since the previously reviewed head 98445502 change the feature materially: the switch now applies live (the router source and the read_skill/use_skill tools ask the live config on every call, and the client is built whenever an endpoint exists, so off stops the next query; only a write that had to seed the endpoint returns a reload warning), the web wizard seeds the endpoint through settings.set like the CLI bootstrap, the setting is marked sensitive with both locale notes, and the page reads a hand-written enabled the way the loader does.

Result: no Windows-specific defect. Both new config writers still go through atomic_update (portalocker LockFileEx sidecar, UTF-8, DACL/mode carry onto the replacement), which is the platform-hardened path reviewed in this PR's earlier heads; the live readers re-parse the config on byte change only and involve no path, subprocess, signal, socket, permission, or encoding logic. hub_source_on answers "off" for a block the loader would refuse, which is the safe direction for a switch that stops text leaving the machine.

Verification on native Windows 11, detached worktree D:\tmp\rv-1141c at the reviewed head, offline venv (uv sync --frozen --offline --all-extras --no-extra segmenter --dev), scratch HOME/USERPROFILE, PYTHONUTF8=1, PYTHONPATH pinned:

• uv run --no-sync pytest tests/test_agent_loop_skill_tools.py tests/test_cli_onboard_commands.py tests/test_config_live.py tests/test_config_raven_sections.py tests/test_config_update.py tests/test_context_engine_factory.py tests/test_rpc_settings.py tests/test_skill_hub_source.py tests/test_skill_hub_tools.py -q → 8 failed, 926 passed
• the same nine files at base 855a412fa → 8 failed, 855 passed
• failing-ID sets are identical in both directions (the inherited Windows login-shell/path cases); the 71 added tests pass
• node ui-tui/scripts/gen-i18n.mjs --check → i18n: generated catalogue is up to date (exit 0), and gui.confirm.cfg.why.skillForge.router.hub.enabled is present with both en and zh in i18n/messages.json

Coverage gaps: the ui-web test files this PR changes (Skills.test.tsx, Roles.test.tsx, the onboard source/store/page tests) could not be executed. The shared D:/projects/Raven/ui-web/node_modules is currently empty (0 entries; it held 196 at the end of an earlier review run today), no intact copy exists elsewhere on this box, and I did not run an install. That leaves the UI half — the live switch rendering, the wizard's seeding call, and the sensitive-note catalogue gate — verified by code reading only. The full suite was not rerun either.

[LivXue]

Follow-up fixed at 521b0fcb6 (rebased onto 6298840e0).

settings.set skillForge.router.hub.init now returns the same reload warning the endpoint-seeding switch write returns, and only when it actually had to seed the endpoint; the wizard's finish shows it as a toast. So the first-run loop that was assembled without a Hub client no longer leaves the switch reading on with no notice. Tests pin the RPC reply (warning when seeding, none when the endpoint already exists) and the toast; mutating either construct reddens one test.

[gloryfromca]

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

The new commit resolves the remaining web-wizard follow-up: skillForge.router.hub.init now returns the reload warning only when it actually seeds a missing endpoint, and onboarding surfaces that warning through the persistent toast host before closing. The four previously reviewed PR commits are unchanged across the rebase.

Verification: uv run pytest tests/test_rpc_settings.py -k 'hub_init or hub_switch' -x (8 passed); the three focused onboarding suites (30 passed); and npm run type-check (passed). I covered the repository rules and relevant context, the delta and range-diff/history, the RPC-to-onboarding callers, compatibility with already-configured/custom endpoints, test-strength changes, and the live-config/reload architecture. My earlier thread remains resolved; the other reviewer's blocker is also resolved by its author.

[LivXue]

Windows compatibility re-review — PR #1141 @ 521b0fcb65ee647e3c6797e03d12b0984ad353eb

Scope: the branch is rebased onto current main; the PR's own diff at this head is 6298840e..521b0fcb (35 files, +1128/−56). The delta since the previously reviewed head 89a964fc is the rebase plus one commit (521b0fcb): the web wizard's finish seeds the Hub endpoint after the first-run stack may already exist, so settings.set's init path now returns the same reload warning the switch write returns when it actually seeds, and the wizard shows it as a toast. Reviewed and run on native Windows.

Result: no Windows-specific issue. The two config writers still go through atomic_update (portalocker LockFileEx sidecar, UTF-8, DACL/mode carry), and the new commit is RPC/UI text plus one shared constant; the live readers are in-memory/file-reparse logic with no path, subprocess, signal, or encoding surface beyond the already-reviewed writers.

Verification on native Windows 11, detached worktree D:\tmp\rv-1141d at the reviewed head, offline venv (uv sync --frozen --offline --all-extras --no-extra segmenter --dev), scratch HOME/USERPROFILE, PYTHONUTF8=1, PYTHONPATH pinned:

• uv run --no-sync pytest tests/test_agent_loop_skill_tools.py tests/test_cli_onboard_commands.py tests/test_config_live.py tests/test_config_raven_sections.py tests/test_config_update.py tests/test_context_engine_factory.py tests/test_rpc_settings.py tests/test_skill_hub_source.py tests/test_skill_hub_tools.py -q → 8 failed, 930 passed
• the same nine files at base 6298840e → 8 failed, 859 passed
• failing-ID sets are identical in both directions (the inherited Windows login-shell/path cases); the 71 added tests pass.

Coverage gaps: the ui-web tests this PR changes (Skills.test.tsx, Roles.test.tsx, the onboard source/store/page tests) still cannot run — the shared D:/projects/Raven/ui-web/node_modules is empty (0 entries) — so the switch UI, the wizard seeding call and the new toast are checked by reading only. The full suite was not rerun.

[LivXue]

@0xKT re the non-blocking notes on 98445502:

• Item 3 (disclosure): addressed at 9beb8d7ce. Both wizards now say what turning Skill Hub search on sends and how to stop it: the CLI bootstrap prints it when its seed turns the source on, and the web wizard's finish shows it as its notice, in the reply language. Nothing is said when the seed turns nothing on (an explicit off, a null endpoint, an endpoint already configured). The Skills page row carries the same sentence, and docs-site/docs/skills-and-extensions.md and its zh page describe the data flow and the switch.
• Item 4a (lax booleans): the page-side copy of the boolean rules added for this note still disagreed with pydantic on "y", "t" and padded strings. Since 39ab2162f the page draws skill_hub_on from settings.get, computed by the predicate the runtime reads, so no second copy is left to drift.

The same push answers the on/off state from that one predicate everywhere; it also runs the loader's in-memory migrations, so a legacy top-level skillRouter reads as on, as it does for the runtime. The description lists the round with its verification.

[gloryfromca]

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

The five previously reviewed commits are patch-equivalent after the rebase. The seven new follow-ups consistently derive Hub state through the loader migrations, return the serving loop's reload state over RPC, render that server answer in Settings, keep the tool description live, and disclose the outbound conversation text in both onboarding paths and documentation. I found no concrete regression or remaining plain error.

Verification: focused Python behavior tests (80 passed), RPC contract-shape tests (51 passed), affected web tests (79 passed), npm run type-check (passed), and the TUI i18n catalogue check (passed). I covered AGENTS.md and the relevant CONTEXT.md update (no repository CLAUDE.md), the delta and range-diff/history, runtime/RPC/UI callers, legacy-config and older-client compatibility, whether tests were weakened, and the live-preference/control-plane boundary. Both review threads are resolved, including mine.

[LivXue]

Windows compatibility re-review — PR #1141 @ 916e7ed7f6425b51e192cf07ce4d86c9e47ee13e

Scope: the branch is rebased onto current main; the delta since the previously reviewed head 521b0fcb is seven commits: the switch is now read through the loader's own migrations (on a deep copy, cached per parsed file), raven_config shows the stored value and what is in effect, the skill-hub tools describe and gate on the live switch, the reload notice is keyed on the serving loop, and a switch state that cannot be read answers off; docs and i18n are updated. Reviewed and run on native Windows.

Result: no Windows-specific issue. The new read path is pure dict handling (_migrate_config(copy.deepcopy(raw)), no file I/O); the only writes remain initialize_skill_hub_endpoint and set_skill_hub_enabled, both still going through atomic_update (portalocker LockFileEx sidecar, UTF-8, DACL/mode carry onto the replacement). _skill_hub_block now prefers a legacy top-level skillRouter over creating a new skillForge.router, which keeps an existing endpoint and key visible to the next load — again pure mapping work. The per-file answer cache is keyed on the LiveConfig and its raw dict via weakrefs, platform-neutral.

Verification on native Windows 11, detached worktree D:\tmp\rv-1141e at the reviewed head, offline venv (uv sync --frozen --offline --all-extras --no-extra segmenter --dev), scratch HOME/USERPROFILE, PYTHONUTF8=1, PYTHONPATH pinned:

• uv run --no-sync pytest tests/test_agent_loop_skill_tools.py tests/test_cli_onboard_commands.py tests/test_config_live.py tests/test_config_update.py tests/test_context_scent.py tests/test_raven_config_tool.py tests/test_rpc_settings.py tests/test_skill_hub_source.py tests/test_skill_hub_tools.py tests/test_config_raven_sections.py tests/test_context_engine_factory.py -q → 8 failed, 1142 passed
• the same eleven files at base 11ca10d8 → 8 failed, 1030 passed
• failing-ID sets are identical in both directions; the 112 added tests pass. The inherited failures are the known Windows login-shell/path cases.

Coverage gaps: the ui-web tests this PR changes still cannot run — the shared D:/projects/Raven/ui-web/node_modules is empty (0 entries) — so the switch UI, the wizard seeding call and the notices are checked by reading only. The full suite was not rerun.

[gloryfromca]

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

This head has the exact same Git tree as the previously reviewed clean revision (14c034766822cd88f7d3c83578e0009c70a2f035); the range-diff contains commit-metadata changes only. uv run python scripts/check_commit_messages.py github/main..HEAD passed, and both review threads remain resolved. With no code or test delta, the prior coverage of repository rules/context, callers and history, backward compatibility, test strength, and architecture still applies.

[LivXue]

Windows compatibility re-review — PR #1141 @ 1a00cbeb2aa68d47090c1b44fa25268cbeeba164

Scope: the delta since the previously reviewed head 916e7ed7. git range-diff 11ca10d8..916e7ed7 11ca10d8..1a00cbeb shows that only commits 1, 3 and 4 differ, and only by dropping Co-Authored-By trailers from their messages; the trees are otherwise identical, and the branch's base is unchanged at 11ca10d8. No code changed since the last review.

Result: no Windows-specific issue; the conclusions of the previous review stand — both config writers go through atomic_update (portalocker LockFileEx, UTF-8, DACL/mode carry), the live read goes through the loader's migrations on a deep copy, and the per-file answer cache is keyed on the LiveConfig and its raw dict via weakrefs.

Verification on native Windows 11, fresh detached worktree D:\tmp\rv-1141f at this exact head, offline venv (uv sync --frozen --offline --all-extras --no-extra segmenter --dev), scratch HOME/USERPROFILE, PYTHONUTF8=1, PYTHONPATH pinned:

• uv run --no-sync pytest tests/test_agent_loop_skill_tools.py tests/test_cli_onboard_commands.py tests/test_config_live.py tests/test_config_update.py tests/test_context_scent.py tests/test_raven_config_tool.py tests/test_rpc_settings.py tests/test_skill_hub_source.py tests/test_skill_hub_tools.py tests/test_config_raven_sections.py tests/test_context_engine_factory.py -q → 8 failed, 1142 passed, matching the previous head exactly.
• The failing IDs are the inherited Windows set seen throughout this PR: three test_cli_onboard_commands.py login-shell/TTY cases, four test_config_update.py a2a chmod/mode cases, and one test_rpc_settings.py POSIX-path case; at base 11ca10d8 the same files give 8 failed, 1030 passed with identical IDs, and the 112 added tests pass.

Coverage gaps: the ui-web tests remain unrunnable here — the shared D:/projects/Raven/ui-web/node_modules is empty (0 entries) — unchanged from the previous review.

[gloryfromca]

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

Reviewed the two-commit delta from 1a00cbeb2aa6 to b85965e3262b: config.set / config.unset now keep process i18n state aligned with the validated file write, and raven_config reports the Skill Hub switch as live while preserving the settings RPC's conditional reload warning. I checked the changed callers, the settings RPC contract, the self-configuration catalog, history, backward compatibility, and the Runtime rules for Live preferences, Generations, RPC ownership, and process-scoped i18n. Existing tests were not weakened.

Verification:

• uv run pytest tests/test_rpc_config.py tests/test_raven_config_tool.py tests/test_config_self_surface.py -q — 343 passed
• uv run pytest tests/test_rpc_contract_shapes.py -q — 51 passed
• uv run pytest tests/test_i18n_boundary.py -q — 2 passed
• Source-language checker, commit-message checker, and git diff --check passed. (make is unavailable in this environment, so I ran the underlying source-language script directly with github/main..HEAD.)

Both existing review threads are resolved.