前端 SDK
提供不绑定框架的调用、事件、就绪状态、功能检测和浏览器式接口。可在公共边界外使用 React、Vue 或原生 JavaScript。
TypeScript SDK 导出 ↗AURORAVIEW / HOW IT WORKS
AuroraView 的工作原理
页面负责界面，显式 API 划定边界，宿主执行场景操作并返回可观察状态。本页沿用 AuroraView 原有架构图，说明主项目 Python / Rust 集成路径。独立原生适配器可以用自己的实现复用桥接契约，具体边界请查看对应宿主记录。
原有的分层模型
从一次点击，到实际场景结果
页面明确要调用的能力
点击处理函数通过 SDK 调用已声明的方法。call() 返回 Promise，on() 订阅宿主事件。页面负责显示和交互反馈。
AuroraViewClient：call / on / emit ↗桥接层传递请求
IPC 将方法名、参数和请求标识送入原生桥。Rust 提供协议与后端边界，PyO3 将 Python 使用层连接到 Rust 实现。
共享 IPC builder 与 Python 绑定 ↗宿主调度器执行操作
用 bind_call() 或 bind_api() 暴露函数，由配置的 set_call_dispatcher() 或已注册的宿主调度器将调用排入允许的线程。DCC 模式会拒绝不安全的回退路径；加锁本身不能获得场景线程访问权。
WebViewApiMixin：bind_call / bind_api / set_call_dispatcher ↗返回结果或发送事件
请求结果完成对应 Promise，宿主变化也可通过事件发送。Python emit() 使用原生命令目标，SDK 再把 window.auroraview.trigger() 事件交给订阅者。
WebViewEventsMixin 与 SDK 事件 ↗
一套桥接，三个明确方向
需要返回结果时使用调用，不需要结果时使用事件。底层 window.auroraview 与 TypeScript SDK 遵循同样的方向模型。
| 方向 | 页面 API | Python 边界 |
|---|---|---|
| 页面 → 宿主，请求 / 响应 | call(method, params, options) → Promise | bind_call(method) / bind_api(...) |
| 页面 → 宿主，即发即忘 | send_event(event, detail)；SDK client.emit(...) | @webview.on(event) |
| 宿主 → 页面，事件通知 | on(event, handler) → 取消订阅函数 | webview.emit(event, payload) → trigger(...) |
trigger() 只在 JavaScript 内投递事件，页面主动调用它不会发送消息到 Python。调用结果通过内部 __auroraview_call_result 事件传递 id、ok，以及 result 或 error。保存 on() 返回的函数，在结束时调用以取消订阅。
当前调用处理器保存请求标识、调度执行、验证 JSON 返回值并报告结构化错误。待处理调用的代际检查防止关闭后旧回调继续完成。事件调度有自己的所有者队列与断开保护；同步 closing 否决回调需要单独的生命周期路径。
阅读双向通信文档 ↗每一层负责什么
Python API 与 PyO3
Python 包绑定宿主操作，并对接宿主事件循环。PyO3 将 Rust 功能暴露给 Python。Qt 集成继续由 Qt 拥有事件循环。
Python API / Rust 绑定 ↗Rust 核心与后端抽象
共享协议和后端接口将通信与原生渲染分开。当前 workspace 使用 Wry 与 wry-builder，Windows DCC 内嵌也有直接 WebView2 路径。
WebViewBackend trait ↗原生引擎与停靠
系统引擎模型对应 Windows WebView2、macOS WKWebView 和 Linux WebKitGTK。实际引擎能力与原生停靠取决于选用后端及宿主适配器。WebView2 对象始终留在创建它的 STA 线程。
Windows DCC WebView 实现 ↗同一套能力，需要明确的 Agent 契约
Agent 入口要声明发现方式、参数、结果、错误和宿主范围。当前 AuroraViewAdapter 提供 eval_js、screenshot、load_url、load_html，以及面板和会话上下文。场景工具与语义需要显式的宿主或 Skill 注册，不会从网页自动产生。
当前适配器的工具声明 ↗渲染生命周期与服务生命周期分别维护
原生面板拥有自己的显示区域、连接、订阅与任务。计划中的共享运行时优先附着已有 DCC-MCP 服务与执行桥。面板关闭后，借用的宿主服务继续运行；创建者负责关闭自己拥有的资源。这个整合仍属计划，还需要兼容性与真实宿主验收。
查看共享运行时整合计划 ↗有边界地扩展与分发
浏览器式 API
SDK 提供标签页、窗口、存储、运行时消息与功能检测。需要按后端和启用功能核对，不能据此假定完整浏览器实现。
SDK 浏览器与功能接口 ↗扩展与插件
独立模块处理 manifest、扩展生命周期、消息与 API 兼容。兼容性需要按实际发布的扩展逐项验证。
auroraview-extensions ↗打包与分发
打包将前端资源、服务、配置与原生启动组织为目标产物。这属于构建时职责，部署仍需检查目标引擎、安装与生命周期。
auroraview-pack ↗先掌握一套小而清楚的契约
先用独立前端与 run_desktop() 开始，绑定一个宿主操作、订阅一个事件并回读结果，再选择原生宿主适配器，遵循对应安装和生命周期要求。