Host API 文档
application.ist 的 Host API 是密封 guest 跨越 WASM 沙箱边界、访问宿主资源和平台服务的唯一能力层。本目录只记录版本化 API；架构讨论、整改过程和安全审查不作为应用可依赖的契约。
当前版本
v0.1 当前是 Supported。独立 apiVersion 声明、发布校验、启动协商、JS SDK、原生绑定、完整事件源与发布端到端门禁均已实现；生产 discovery 以封闭的 27 方法、15 事件和 38 项预算整体公布支持，不提供部分版本。
版本文档依次经历 proposal → draft → release-candidate → supported。只有 supported 才是应用可以依赖的平台承诺；同一版本的成熟度只能向前推进，任何不兼容契约变化都必须使用新版本号。
API 分层
先判断一项设计应处在哪一层，再讨论 host 模块。能成为库的，不因“放在宿主更方便”而进入能力层。
| 层级 | 内容 |
|---|---|
| L0 | log、now、random、host_call、统一事件传输等运行时原语 |
| L1 | 跨越 WASM 边界的宿主能力：真实资源、系统服务、外部权限、受控平台服务 |
| L2 | guest SDK / 库：场景树、数据库、会话管理、重连、编解码、工作流 |
| L3 | 应用领域模型 |
判断一项接口能否进入 L1，先问：
删除这个 host API 后，guest 是否会失去一种真实资源、权限、系统集成或受控服务，而不只是实现起来更麻烦？
若 guest 只靠自身内存、计算与已有 L1 能力即可等价实现，默认放入 L2。仅有“宿主可以保存这份状态”“宿主实现可能更方便或更快”都不足以证明它属于 L1。
四种版本不要混用
| 版本 | 含义 |
|---|---|
| Host API 版本 | guest 可调用的 L1 能力集合及其语义；首个基线为 0.1 |
| 应用契约版本 | 单个应用的 host capability 与 guest export 契约版本，构建产物中记为 contractVersion |
| 线协议版本 | KBS1、canvas 命令缓冲等具体二进制格式版本 |
| 运行时构建版本 | 实际部署的内容哈希 bundle，用于定位实现，不构成兼容性承诺 |
应用版本也与上述四者独立。应用从 1.2.0 升到 1.3.0，不意味着 Host API 随之升级。
v0.1 准入与发布规则
能力进入 v0.1 必须同时满足：
- 有具体应用，或属于平台不可缺少的基本职责；
- 宿主独占的资源、权限、系统效果或受控服务明确；
- 不能只靠 guest 库与已有 v0.1 能力等价实现；
- 模块边界、方法语义、句柄和生命周期明确；
- 失败、取消、事件、预算、授权与固定信任档位明确；
- JS guest 与原生 WASM guest 的逻辑可达性和传输约束明确。
缺任一项就留在非正式提议。版本进入 supported 还必须完成独立版本握手、两类绑定的边界校验 schema、策略表生成、兼容性测试和每个模块至少一个端到端用例；发布构建会再次执行这些门禁，失败时不得生成 supported discovery。
0.x 表示尚未承诺 1.0 级长期稳定，但不允许无版本地改变兼容性：不兼容变化必须形成新的明确版本，例如 0.2。
文档规则
v*.zh.md是中文版本规范；未来其他语言使用同版本号的语言后缀。- 正式版本只列入该版本真实承诺的接口，不占未来名字。
- 非正式提议不冻结名字，不进入 manifest、运行时能力表、策略表或分档计算。
- 现有实现与正式规范冲突时，文档必须明确标出；不得用实现现状悄悄改写版本契约。