第三方库编写指南
为言序生态设计、实现、验证并发布一个可长期维护的第三方库。
一个可发布的言序库不只是若干能运行的文卷。它还要有可复现的依赖图、明确的权限与安全 边界、稳定的公开 API、跨执行器测试、独立消费者，以及能从公开标签重新得到相同结果的 发布流程。
本指南把现有 21 个稳定库的共同发布门禁整理为社区作者可执行的规范。这些库最终在言序 1.1.12 上共同完成锁定、检查、源码执行和 Release 构建；当前言包仍通过言序的版本化工程 协议读写格式 2 清单。你可以声明更低的最低言序版本，但必须用那个版本单独通过同一组门禁。
开始前确认工具
yanbao 版
yanxu 版本 --json
yanbao 诊yanbao --help列出的当前命令负责工程工作流；yanxu --help列出的命令是核心检查、VM、
包协议和 API 文档入口。发布文档只应使用这两份帮助中真实存在的命令。当前言包没有
publish或发布命令：源码包以 Git 标签分发，发布说明与额外制品由 GitHub Release 承载。
先判断是否值得成为库
适合独立发布的选题通常满足至少一项：提供可复用协议或数据结构、封装清晰的外部系统、 把安全策略固化为 API，或解决多个项目都需要的工程问题。只服务一个应用、没有稳定公共 边界的代码，先留在应用内部通常更合适。
立项前检查已有包，记录你的差异：支持范围、资源限制、错误协议、权限成本和维护承诺。 不要只换一个名字重复已有能力，也不要使用会让社区误以为官方维护的名称或说明。
名称分三层
| 层级 | 示例 | 约定 |
|---|---|---|
| 仓库 | yanxu-example | GitHub 上使用小写英文和连字符，便于发现 |
| 包名 | 言例 | 言序.toml中的稳定身份，也是默认导入名 |
| 依赖别名 | 言例 | 由消费者清单决定，可与实际包名不同 |
包名只能包含文字、数字、_、-和.，且不能以.或-开头。发布后改包名相当于更换
包身份，应按破坏性迁移处理。仓库名、包名和导出模块的对应关系要在 README 第一段说清楚。
从想法到稳定版
- 在项目结构与清单中创建格式 2 工程， 收紧依赖和权限。
- 按API 与错误设计固定中文公开面、结构化错误 和资源预算。
- 用测试与持续集成覆盖规格、示例、基准、 最低工具链、独立消费者和声称支持的平台。
- 按版本与发布准备 SemVer、更新记录、普通 merge PR、附注标签和 GitHub Release。
- 发布前逐项满足硬性要求。
先做窄而完整的 0.x，再承诺 1.0 稳定面。版本号不是成熟度装饰：一旦发布 1.0，同一主版本 内的函数名、参数顺序、返回形状、数据字段和稳定错误代码都成为兼容承诺。