Host API 文档
application.ist 的 Host API 是密封 guest 跨越 WASM 沙箱边界、访问宿主资源和平台服务的唯一能力层。本目录只记录版本化 API；架构讨论、整改过程和安全审查不作为应用可依赖的契约。
当前版本
v0.1 当前是设计基线。运行时尚未完成独立 apiVersion 的声明、发布校验和启动协商闭环；在该闭环落地前，站点不会把“实现里碰巧存在某个方法”等同于“宿主符合 v0.1”。
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 的可达性和传输绑定明确；
- 有边界校验 schema、兼容性测试和至少一个端到端用例。
缺任一项即不进入 v0.1。0.x 表示尚未承诺 1.0 级长期稳定，但不允许无版本地改变兼容性：不兼容变化必须形成新的明确版本，例如 0.2。
文档规则
v*.zh.md是中文版本规范；未来其他语言使用同版本号的语言后缀。- 正式版本只列入该版本真实承诺的接口，不占未来名字。
- 非正式提议不冻结名字，不进入 manifest、运行时能力表、策略表或分档计算。
- 现有实现与正式规范冲突时，文档必须明确标出；不得用实现现状悄悄改写版本契约。