官方交付文档格式与验收清单

应用交付不仅是一份manifest或一个压缩文件。开发者需要明确当前用途、运行条件、权限、数据处理、更新方式与实际验收结果。所有材料应对应同一源码提交、版本和构建产物；引用上游实现时保留项目来源、许可证及必要声明。

1. README：当前功能、安装运行、配置/接口、依赖和已知限制；不堆叠逐版本历史。
2. CHANGELOG.md：每版新增、修改/修复、验证范围和部署状态，按版本顺序记录。
3. Manifest：严格匹配Schema，不放密钥、任意命令或无法执行的权限承诺。
4. API说明：方法与路径、认证/能力、参数类型与单位、必填和默认值、响应示例、错误码、状态、幂等/重试和过期规则。
5. 运维说明：服务身份、配置与数据目录、日志脱敏、健康检查、停止、升级、备份、卸载保留策略和失败恢复。
6. 验证报告：准确版本、源码提交、构建架构、包/载荷摘要、签名指纹、环境与可复现步骤，区分静态/便携测试与真实硬件验收。

社区帖子可用Markdown；官网手册原文采用DokuWiki标题、内部链接、表格与代码块格式，不能把Markdown的#标题直接当Wiki正文。下载的.md规范保持原格式；JSON必须可解析、无注释、无重复键，Schema声明对应版本。

确认根manifest、实际架构入口、图片引用、唯一依赖、固定权限、路径/大小/模式限制及工具校验。正式包需外部受信任公钥验签，不提交签名私钥。记录整包和压缩载荷摘要的不同用途，不能把文件后缀、作者名称或截图当作信任证明。 说明数据库/文件迁移是否可逆，升级失败可恢复哪些内容；不要把代码版本回退当作数据库和外部副作用也已回滚。卸载默认保留业务数据，破坏性清理另需明确确认和独立权限。

在“套件开发与封装”分享目录、Manifest、构建步骤和脱敏错误；在“官方规范与模板”讨论字段、兼容和文档修订。建议附操作系统/CPU架构、NAS版本、工具版本、最小复现和预期结果。涉及Schema或权限的不兼容变化应先讨论格式演进，不自行扩充已锁定格式。不要在帖子中放用户数据、可用令牌、服务器账号或私钥。 全部规范与模板ZIP提供按来源提交保存的材料。历史复核中的33项是历史范围，当前清单35项，发布时仍需重新核对自己的准确宿主版本及全量清单。