feat(extensions): add agent-authored Tool and UI packages

apps/desktop/src/renderer/locales/settings-subagents-copy.ts

@@ -150,6 +150,7 @@ const SETTINGS_SUBAGENTS_COPY_BY_LOCALE = {
       local_read: { label: '代码阅读', description: '只读访问当前工作区，适合搜索、理解和总结代码。' },
       web_research: { label: '网络研究', description: '只使用联网搜索，适合查找外部资料和最新信息。' },
       implementation: { label: '实现代码', description: '可以读写文件并执行命令，在隔离 worktree 中完成改动。' },
+      tool_author: { label: '工具作者', description: '通过正式接口创建、安装并在沙箱中测试候选 Tool，不修改工作区源码。' },
     },
     thinking: {
       off: '关闭',
@@ -231,6 +232,7 @@ const SETTINGS_SUBAGENTS_COPY_BY_LOCALE = {
       local_read: { label: 'Code reading', description: 'Read-only access to the current workspace for search, understanding, and summaries.' },
       web_research: { label: 'Web research', description: 'Web search only, for external sources and current information.' },
       implementation: { label: 'Implementation', description: 'Read and write files and run commands in an isolated worktree.' },
+      tool_author: { label: 'Tool author', description: 'Create, install, and sandbox-test Tool candidates through the formal authoring interface without editing workspace source.' },
     },
     thinking: {
       off: 'Off',

docs/architecture/extension-lifecycle-kernel.md

@@ -0,0 +1,68 @@
+# Extension Lifecycle Kernel (Phase 1)
+
+This module implements the product-independent lifecycle and revision semantics from issue #2973. It deliberately does not register Tools, UI, hooks, or execute dynamic scripts.
+
+## Authority and objects
+
+- An **Extension** is a stable identity.
+- A **Revision** is immutable after `install`. Installing a revision never executes extension code.
+- A **Binding** selects one exact revision for one scope. Only one binding for an extension may exist in a scope.
+- A **Candidate** owns everything allocated by `prepare`, `healthCheck`, and `activate` until it either becomes current or is rolled back.
+- A **Current Activation** owns its exposed dependency value and every registered effect.
+- A **Composition Snapshot** is an immutable, deterministic view of the active revisions and contribution descriptors in a scope.
+
+## Lifecycle
+
+```text
+install revision (no effects)
+  -> enable binding
+  -> wait for same-scope dependencies
+  -> prepare candidate
+  -> health check
+  -> activate
+  -> commit current
+  -> stop / remove binding / uninstall revision
+```
+
+Updates use current/candidate semantics:
+
+```text
+current remains active
+  -> prepare + health-check candidate
+  -> stop active dependents
+  -> activate candidate
+  -> commit candidate as current
+  -> dispose old current
+  -> reactivate dependents against the new dependency value
+```
+
+If preparation, health checking, or activation fails, the candidate is disposed in reverse effect-registration order and current remains committed. If candidate activation had already stopped dependents, they are reconciled back against the old current.
+
+## Invariants
+
+- All mutations are serialized by the kernel.
+- Dependencies resolve only inside the binding's scope.
+- Missing dependencies produce `waiting`; activating the provider reconciles waiting consumers.
+- Stopping a provider stops transitive dependents before the provider.
+- Dependency cycles fail without executing extension code.
+- Effects are disposed in reverse registration order; failed disposers remain inspectable and retryable.
+- A revision cannot be uninstalled while any binding, current activation, or candidate references it.
+- Previously returned composition snapshots never mutate.
+
+## Adapter boundary
+
+Future contribution adapters register their reversible work through `ExtensionActivationContext.ownEffect`. A Tool adapter, for example, will own the Tool registry entry's disposer. The kernel does not bypass Maka's existing Runtime, permission, sandbox, or Run-composition authorities; those integrations belong to later phases.
+
+## System verification
+
+`extension-lifecycle-kernel.system.test.ts` treats the exported kernel as the test boundary. It does not replace lifecycle methods or assert mock call counts. The scenarios exercise:
+
+- a real TCP server and persistent client through health check, dependency injection, provider stop, automatic consumer restart, scope disposal, and port release;
+- real `EventEmitter` listeners and timers to detect resource leaks across stop, restart, and binding removal;
+- a diamond dependency graph moving from one provider revision to another, including transitive stop and reactivation order;
+- candidate, dependent, binding-removal, and scope-disposal cleanup failures with retained ownership and retry;
+- invalid definitions, candidates, effect registration, dependency reads, binding conflicts, and missing objects through public error codes;
+- deterministic revision/composition ordering and stable composition digests across generation changes;
+- 2,000 seeded public lifecycle operations across four scopes, three dependent extensions, and two revisions while continuously checking public-state/composition agreement and exact live-resource counts.
+
+The focused fault-matrix tests remain alongside these system scenarios. Coverage is collected from the compiled JavaScript with Node's test runner so the result measures the implementation that actually executes.

docs/architecture/extension-tool-contributions.md

@@ -0,0 +1,82 @@
+# Extension Tool Contributions (Phase 2)
+
+This vertical slice connects the Extension lifecycle authority to Maka's real Tool execution
+path. It supports trusted static Tool revisions; it does not load arbitrary packages or scripts.
+
+## Completion contract
+
+Phase 2 is complete when all of these statements are true:
+
+- installing a revision remains effect-free;
+- activating a binding publishes its declared Tools into that binding's scope;
+- the next Backend `send()` sees Core and active Extension Tools through one catalog;
+- an Extension Tool call settles through the existing `ToolRuntime` rather than a parallel
+  executor;
+- Tool availability, argument validation, permissions, sandbox boundaries, durable settlement,
+  and product routing remain authoritative;
+- updating a binding switches the complete Tool surface transactionally, and a failed candidate
+  restores the prior surface;
+- stopping, removing, or disposing the binding retracts every Tool registration;
+- Extension Tools cannot shadow Core Tools, Runtime protocol names, other extensions, or claim a
+  provider-native protocol;
+- an empty Extension registry produces the same Core Tool surface as before.
+
+## Registration model
+
+`ExtensionToolContributionRegistry` is a typed resource registry. A trusted Tool revision publishes
+through `contributeExtensionTool`, which immediately hands the matching unregister function to
+`ExtensionActivationContext.ownEffect`.
+
+Candidate replacement is transactional. A candidate from the same binding may temporarily replace
+its current Tool name while activating. Candidate cleanup restores the old entry; after commit, old
+activation cleanup retires the replaced entry so a later stop cannot resurrect it.
+
+Core Tool names should be supplied through `protectedToolNames` so conflicts fail during activation.
+`compose` checks again when producing the execution snapshot, which catches changes in the Core
+catalog between activation and admission.
+
+## Runtime boundary
+
+`AiSdkBackendInput.resolveTools` is an optional trusted reader for the full Core + Extension Tool
+catalog. The Backend snapshots it once at the beginning of each `send()` and then routes that
+snapshot through the same apply-patch projection, `ToolAvailabilityRuntime`, provider schema,
+repair path, and `ToolRuntime` dispatch used by Core Tools.
+
+This phase intentionally chooses the existing `send()`/Turn boundary. Refreshing at every physical
+model request, pinning a larger Run composition, draining in-flight calls, and isolated
+agent-authored code remain later decisions.
+
+## Runtime Host ownership
+
+`HostExtensionRuntime` is the in-process authority owned by the execution Runtime Host. It owns the
+lifecycle kernel and Tool registry together and composes Session-scoped Extension Tools into both
+the model Backend and the Host's available-Tool catalog.
+
+The exact Tool snapshot selected at the beginning of `send()` is also written into the durable Run
+Composition record. During Host drain, new Extension mutations are rejected while read-only Tool
+resolution remains available to admitted work. The Extension authority closes after execution
+domains, disposes every tracked Scope, and only then uninstalls its in-memory revisions.
+
+## Trusted control plane and restart recovery
+
+The Runtime Host composition may register a bounded catalog of trusted static Tool revisions.
+`StaticTrustedToolExtensionLoader` resolves only those definitions; it never imports a workspace
+path or executes user-authored code. The local owner can use `extension.catalog.query` and
+`extension.catalog.mutate` to list, enable, disable, update, and remove bindings. These operations
+are deliberately absent from the remote-owner grant list.
+
+`HostExtensionController` persists desired bindings, enabled state, last-good revision, and the
+latest diagnostic in the root-private Host control directory. Desired state is committed before
+enable, update, and disable convergence so a process crash can resume the command. At startup it:
+
+1. loads every available last-good and desired revision without activating code during install;
+2. restores last-good bindings first;
+3. attempts the desired upgrade through the lifecycle candidate transaction;
+4. retains last-good Tools and records a diagnostic when loading, health check, or activation
+   fails;
+5. leaves the rest of Runtime Host available when Extension state cannot be recovered.
+
+This completes the minimum trusted-static product slice: a Host integrator registers Tool
+revisions, a local administrator controls them through the Runtime Host protocol, and enabled
+bindings survive process restart. Manifest/npm discovery, third-party code isolation, UI, an Agent
+authoring Tools, and model-call-level hot swapping remain outside this trust boundary.

packages/core/src/subagent-settings.ts

@@ -1,6 +1,11 @@
 import { isThinkingLevel, type ThinkingLevel } from './model-thinking.js';
 
-export const SUBAGENT_PROFILES = ['local_read', 'web_research', 'implementation'] as const;
+export const SUBAGENT_PROFILES = [
+  'local_read',
+  'web_research',
+  'implementation',
+  'tool_author',
+] as const;
 export type SubagentProfile = (typeof SUBAGENT_PROFILES)[number];
 
 export const MAX_SUBAGENT_PRESETS = 64;