feat(btw): move the dual-loop config into AI capabilities

[YUZHEthefool]

Summary

Moves the BTW dual-loop configuration group from the plugin page to AI → Capabilities, so the ten btw.* settings are reachable where the other agent capabilities live. The root-level btw config shape is untouched.

Related issue

Fixes #183

Behavior

• AI → Capabilities (built-in Agent) now lists a BTW dual loops card after Knowledge Base, Web Search, Computer Use, and Proactive Agent. Enabling btw.enabled reveals all ten field controls.
• Plugin Config no longer renders the group; that page keeps only the plugin selector.
• btw.work_loop.computer_use_runtime now ships labels, so the select shows translated options instead of the raw inherit / none / local / sandbox values.
• Titles, hints, and option labels resolve through ai_group.btw.* in both locales; no key falls back to raw text.

Non-goals

• No built-in plugin or Star named btw.
• No new top-level configuration tab.
• No change to BTW runtime semantics, the default-off policy, or loop assignment rules.
• No relocation into Advanced or Ext.
• No generic renderer for non-plugin plugin_group metadata. The group now holds only plugin, so the hard-coded plugin section is still exact; a catch-all renderer stays a separate change.

Implementation notes

• CONFIG_METADATA_3["plugin_group"]["metadata"]["btw"] becomes CONFIG_METADATA_3["ai_group"]["metadata"]["btw"]. This is the placement that 7630c7c76 worked around: a top-level btw tab entry has no metadata key, so ConfigMetadataI18n.convert_to_i18n_keys emptied its controls.
• Item keys stay the absolute btw.* paths, so AstrBotConfigV4 keeps reading and writing the root-level btw object. DEFAULT_CONFIG is unchanged and no profile migration is needed.
• AiConfigPanel.vue adds btw to the capabilities group list, which is the only place the tab's contents are enumerated.
• Bilingual config-metadata entries move from plugin_group.btw.* to ai_group.btw.* (the section key is btw and the item keys are btw.*, so the converted keys read ai_group.btw.btw.*). ai_group. is already in CONFIG_METADATA_I18N_PREFIXES, so a future missing translation warns at runtime instead of silently rendering the key — plugin_group. was not in that list.
• Docs navigation paths in docs/zh|en/dev/astrbot-config.md now read Config → AI → Capabilities → BTW dual loops → ….

Validation

python -m pytest tests/unit -q                          # 5237 passed, 6 skipped
python -m pytest tests/unit/test_config_metadata_i18n.py -q   # 8 passed
cd dashboard && pnpm exec vitest run --config vitest.config.ts  # 86 files passed, 278 tests
python -m ruff format --check . ; python -m ruff check .        # clean for changed files
cd dashboard && pnpm run i18n:check                     # 2005 static keys, 4044 catalog keys
prettier --check (locales, AiConfigPanel.vue, new test)  # clean
markdownlint-cli2 docs/zh/dev/astrbot-config.md docs/en/dev/astrbot-config.md  # 0 issues
cd docs && ASTRBOT_DOCS_BASE=/help/ pnpm run docs:build  # build complete

Notes on the above:

• uv run is unusable in this environment (No interpreter found for Python 3.14.6), so make check and uv run pytest --test-profile blocking were not run as written; the underlying python -m pytest, ruff, and node checks were run directly against the checked-out venv.
• Four dashboard suites (marketPluginKey, pluginPageHost, extensionRuntimeSmokes, coverageMounts) fail to collect with TypeError: ... Received 'file:///favicon.svg'. Reproduced on a clean tree via git stash -u, so it is pre-existing and unrelated to this change.
• docs:build only passes after moving the untracked local scratch directories docs/backend-architecture/ and docs/btw-architecture-design/ aside; they carry dead .drawio links and are not part of this change set.
• The new dashboard/tests/aiConfigCapabilities.vitest.ts was verified to fail when the AiConfigPanel.vue line is reverted.

Compatibility and risk

• Config profiles: unchanged. btw stays at the config root with the same JSON shape; reading and saving an existing profile neither migrates nor drops fields.
• Dashboard protocol: the metadata payload for plugin_group loses one key and ai_group gains one. No route or schema changes, so the OpenAPI document and generated client are untouched.
• The only user-visible risk is placement: an operator looking for BTW under Plugin Config will now find it under AI → Capabilities, which is the intent of the issue. Docs are updated in the same change.

Checklist

• A Feature request Issue exists for large work, or this is a small, obvious addition.
• The change is focused and does not include unrelated refactoring.
• I added or updated tests, or explained why tests are not practical.
• User-visible behavior updates both docs/zh/ and docs/en/.
• OpenAPI, generated client, docs/public/openapi.json, and tests change together when routes or schemas change.
• No secrets committed. Runtime Python deps update pyproject.toml, requirements.txt, and uv.lock together.
• I did not restore legacy shims, Python <3.14 fallbacks, or upstream publish/docs URLs as fork artifacts.
• Breaking API or behavior changes use ! and a BREAKING CHANGE: footer.
• I will not merge this PR myself. Merge needs a human maintainer review plus a separate AI-assisted review (AI_POLICY.md).
• AI use follows AI_POLICY.md. Keep exactly one author note below. Do not fabricate the other.

Agent note

Goal: implement issue #183 so the BTW dual-loop group is configured from AI → Capabilities instead of the plugin page.

Paths touched: astrbot/core/config/default.py (group relocation plus computer_use_runtime labels), dashboard/src/components/config/AiConfigPanel.vue (capabilities list), dashboard/src/i18n/locales/{zh-CN,en-US}/features/config-metadata.json (entry migration and labels), tests/unit/test_config_metadata_i18n.py, dashboard/tests/aiConfigCapabilities.vitest.ts (new), docs/{zh,en}/dev/astrbot-config.md.

Checks run: the commands listed under Validation, all executed locally. Full tests/unit suite, i18n:check, prettier, markdownlint, ruff, and docs:build pass; the four dashboard collection failures are pre-existing and were reproduced on a clean tree. The new frontend test was confirmed to fail without the panel change.

Residual risk: the capability-tab ordering is asserted only through the new Vitest, which stubs AstrBotConfigV4; the ten field controls themselves are covered at the metadata level by test_every_btw_profile_field_reaches_dashboard_controls rather than by a rendered-page test. make check / uv run pytest --test-profile blocking were not run because uv cannot resolve Python 3.14.6 here, so CI remains the authority on those targets.

Tools used: Claude Code (Opus 5) with file edits and local test execution; issue text authored by OpenCode per the issue's Agent note.

[BegoniaHe]

AI-assisted review

This is the separate AI-assisted review required by AI_POLICY.md. It is not a maintainer approval and does not authorize merge.

Checked against issue #183, origin/master...HEAD (da2b0d2fa), CONFIG_METADATA_3 / AiConfigPanel.vue / plugin-page rendering, i18n conversion, and GitHub Checks for this PR (all required jobs green as of this review).

Verdict

The placement change itself matches #183 and should land. One pre-existing Dashboard regression becomes user-visible the moment this group is shown; restore that wiring before merge, or land this PR only with an immediately following fix.

What is correct

• CONFIG_METADATA_3["ai_group"]["metadata"]["btw"] is the right host. Item keys stay absolute btw.*, so DEFAULT_CONFIG["btw"] and existing profiles are untouched. convert_to_i18n_keys now emits ai_group.btw.*, which is covered by CONFIG_METADATA_I18N_PREFIXES.
• AiConfigPanel.vue only enumerates capabilities for the local Agent tab. Adding 'btw' after proactive_capability is the only list that needed to change.
• Plugin Config still hard-codes PluginSetSelector. test_btw_section_stays_out_of_the_plugin_group now also keeps plugin_group.metadata to {plugin}.
• btw.work_loop.computer_use_runtime labels align with options inherit / none / local / sandbox (Computer Use itself has no inherit, which is correct).
• Locale trees were moved, not duplicated. Docs breadcrumbs now match the UI: 配置文件 → AI 配置 → 能力 / Config → AI → Capabilities.
• Tests cover the metadata contract and the capabilities-tab membership. Commit message and Agent note follow policy.

Required follow-up (pre-existing, now user-visible)

PluginLoopSelector and CapabilityLoopSelector exist, and the three _special values are still on the BTW items:

• select_plugin_loop_routes
• select_mcp_loop_routes
• select_skill_loop_routes

They are not handled in dashboard/src/components/shared/ConfigItemRenderer.vue. Those branches were present after b70e3ee7c / 656969a47 / e7b698e32 and were dropped by the upstream cherry-pick c2ef5d968 (feat: enhance slider robustness (#10037)), which rewrote the special-handler block.

Until that wiring is restored, enabling BTW on AI → Capabilities will render the three route fields through generic ListConfigItem (string chips / a single text field). route_is_available_in_loop ignores non-dict entries, so a typed-in plugin name is silently dropped. The docs this PR updates tell operators they can assign conversation / work / both from that screen.

This is not introduced by the diff, but this PR is what makes those controls appear. Restoring the three _special branches (and their imports) is a small, in-scope companion change. A Vitest that mounts ConfigItemRenderer for those _special values would have caught the drop.

Nits (non-blocking)

• tests/unit/test_config_metadata_i18n.py drops from __future__ import annotations with no related need. Harmless on 3.14; keep the file focused.
• dashboard/tests/aiConfigCapabilities.vitest.ts stubs AstrBotConfigV4, so it asserts tab membership, not the ten field widgets. That is acceptable if the ConfigItemRenderer wiring test above is added.
• btw.work_loop.max_concurrent still requires btw.work_loop.enabled, so “all ten fields after enabling BTW” is 9 until the work loop is also on. Pre-existing metadata.
• MCP / Skill sections in astrbot-config.md still name the controls without the new breadcrumb. Only the plugin-assignment sentence had the old path; updating the other two would keep the page consistent.

I will not merge this PR.