主题
软件交付文档
本项目 modules/<module>/ 下的模块使用六类核心文档作为从讨论到验收的同一套资料结构，随设计、实现和验收逐步完善；建档条件见下文模块级资料。普通局部开发任务只维护受影响的正文和证据，不为一次修改重写整个模块。
交付资料分层
模块级资料
新业务模块在 modules/<module>/ 按阶段建立以下六类核心文档；已确认并纳入模块基线的讨论结论按职责记入对应文件，独立讨论、需求对焦和前期方案稿按文稿与过程产物放在项目根 reports/；平台部署与公共资料按下文单独归档：
| 文件 | 交付名称 | 主要内容 |
|---|---|---|
requirements.md | 需求分析文档 | 背景、目标、范围、角色、场景、业务规则、功能/非功能需求、验收标准 |
overview-design.md | 概要设计文档 | 架构位置、模块边界、核心流程、状态模型、依赖、权限方案和关键技术决策 |
detailed-design.md | 详细设计文档 | 页面与路由、接口契约、状态流转、权限数据范围、异常、事务、关键类与调用链 |
database-design.md | 数据库设计文档 | ER 关系、按本次范围维护的字段矩阵或差异、主外键、唯一约束、索引、字典、数据库基线和变更说明；全量矩阵的适用条件见数据库设计特别检查 |
test-report.md | 测试与验收文档 | 范围、环境、用例、自动化结果、适用风险的验证、缺陷、证据和验收结论；并发是否纳入遵循根规则 |
user-manual.md | 操作手册 | 前置条件、菜单路径、角色、逐步操作、字段说明、提示、常见异常和权限边界 |
用户仅要求讨论或审阅时只交付结论，不据此建档；用户要求记录新模块业务基线，或已授权实施新模块时，先建立 requirements.md，文档编写无需另等“开始实施”口令。后续在设计、数据库、验证或用户操作进入相应阶段且确有内容时，建立对应的概要/详细设计、数据库设计、测试与验收或操作手册文件。六类文档类型和职责不变，但不创建尚未进入阶段的空文件，也不为不适用内容占位；正式对外交付或版本验收时补齐适用资料，不适用项说明原因。未核实事实标为待核对；文档版本按版本与证据填写，实现与验收结论分别由 test-report.md 和交付回报记录。已有不足六类文件的旧模块（包括平台模块）在后续资料迁移中补齐；普通局部变更仍只更新本次受影响的资料，不因旧结构未迁移而扩大任务或暂停开发。
平台级资料
平台部署方案统一维护在项目手册末尾，不再建立独立的“平台级资料”分组或平台/版本交付模板目录。通用工程、运维和安全规则只在项目手册对应章节维护，不复制到业务模块。
公共持久化表按实际归属维护在模块 database-design.md：系统基础表归系统设置数据库设计，Warm-Flow 运行时表归流程引擎底座数据库设计，业务表归所属模块。各业务模块的正式测试与验收文档保留；跨模块独立测试汇总和专题报告统一放项目根 reports/。
版本级资料
正式对外交付或正式版本验收需要的独立版本资料放项目根 reports/版本交付/<version>/，不纳入文档站；普通修复验证和内部反馈不因此新建版本资料包：
text
reports/版本交付/<version>/
├─ release-notes.md # 发布说明和变更范围
├─ trial-operation.md # 试运行计划、记录和结论
├─ rectification.md # 问题整改、责任和复验
└─ acceptance-report.md # 最终验收范围、证据和签署信息事实源规则
- 跨模块规则只写在项目手册；模块文档通过链接引用，不复制整套规则。
- 根
AGENTS.md保留任务路由、授权边界和交付闸门的短要求；执行细则只在对应 handbook 维护，Skill 引用正文并提供本类任务的步骤和自检。新增规则优先合并已有条目，不通过重复强调扩大入口；迁移正文时同步检查链接和按章节名引用，避免循环引用或冲突口径。 - 文档站只维护六类业务模块资料、项目手册和六类文档模板。需求规则以
requirements.md为单一正文，设计、数据库、正式测试与验收和操作内容分别进入对应文件；独立讨论、对焦、前期方案及专项报告按文稿与过程产物放在项目根reports/，不在文档站建立历史稿归档区、其他交付资料或第二份业务基线。数据库字段及历史核验日期由对应模块database-design.md维护，当前结构以项目 MCP 回读为准。 - 文件清单、类名和普通实现细节以代码为准；文档解释代码无法表达的业务原因、约束和验收口径。
- 原型作为来源附件或链接保存；原型驱动的需求与设计记录可定位来源（图/页/区域标识），仅记录歧义或有意改动的短对照，不逐字段抄录，也不建立独立巨型矩阵。使用方式与证据分级见原型与证据。
- 需求范围必须能追溯到用户指令、原型表达的业务要求或适用业务基线。新增页面、Tab、业务动作/状态和录入项没有需求来源时不得纳入；本次适用的鉴权、校验、错误处理和失败恢复按根规则落实在责任边界，不重复实现，也不能因此扩建产品能力。
- 交付文稿与过程产物按下文文稿与过程产物分别存放，不能将临时分析输出默认归入
reports/。普通任务的验证结论可以引用本次可复核的工具记录和原始产物，无需先转写正式文档；引用内容须能对应受测范围与实际结果，且不含凭据等敏感信息。正式交付时，在modules/<module>/test-report.md归档结论并记录证据来源，原始产物作为支撑材料，不替代正式交付记录。 - Git 承担变更历史，不手工维护流水式代码改动日志。
- 已采用六类结构的模块只维护这六类文件，不再保留旧版兼容正文；入口和导航直接指向六类文件。旧模块迁移时先核对现有正文、代码与证据，再按职责归入六类文件，不把历史计划改写为当前事实。
原型与证据
原型用于理解业务场景、角色、数据、操作、流程、附件和验收要求，不是 UI 还原稿；布局、弹窗、表格、按钮摆放、表单分区和审批意见展示方式按界面规范与成熟页面重新设计，不机械复制。原型驱动记录只定位来源和歧义或有意改动的短对照，不逐字段抄录。
需求、设计和验收记录来源时，按可靠性区分以下证据：
- 用户明确业务决定：可直接作为业务规则。
- 原型表达的业务要求：记录为业务要求并定位图/页/区域；涉及必填、禁止或状态限制时，确认其属于业务表达而非界面示意。
- 项目已有稳定契约：沿用项目接口、权限、状态和同级先例，注明依据。
- 原型中的示例、占位、重复和界面缺陷：不得写成业务规则，不作为必填、只读、禁止或隐藏的依据。
- 实施者自行作出的假设：标注为“实施者假设”或“待确认”，不得写成已确认需求。
不得因截图缺按钮、草稿行没有操作，或某个字段只出现在列表，直接推导业务限制、必填规则或禁止操作；原型缺项按既有契约判断，仍无法确定时列为待确认。原型中的 UI 不合理时按平台设计体系重新设计，但重新设计不得删减已确认的业务能力；已有资料、调用链或同级先例能够确定的，按根 AGENTS.md 沿用并注明依据，不因原型缺项重新要求用户确认。
文档位置与职责
| 位置 | 职责 |
|---|---|
| 用户级指令 | 跨项目语言、沟通和协作偏好，不在项目内重复维护 |
根 AGENTS.md | 项目授权、任务路由、关键底线与交付口径 |
.agents/skills/<技能>/SKILL.md | 调查与影响分析、执行分支、工具和专属验证；不重复通用授权 |
handbook/ | 全项目通用工程、环境、契约、流程与交付规范 |
modules/<module>/ | 模块当前需求、设计、接口、数据库、测试及操作事实 |
templates-module/ | 六类模块资料模板，按阶段使用，不创建空文件 |
项目根 reports/ | 讨论、需求对焦、前期方案、专项测试/评估和汇报等独立文稿及必要附件，不属于文档站 |
私有根 README.md | 私有环境凭据台账，禁止复制凭据到文档站 |
文稿与过程产物
用户要求编写或保存的讨论稿、需求对焦稿、前期方案稿、技术选型与可行性评估、开源库试用、服务器专项测试、独立整改/修复记录及汇报材料等文稿，统一归入项目根 reports/，无需重复指定。Agent 先查看已有分类，能够归入时直接沿用，缺少时按用途或主题建立目录，避免重复或过细分类；文稿及其必要附件集中保存，不进入文档站或其导航。前期稿件中的结论只有经确认并纳入模块基线后，才按职责更新六类模块文档，不直接把稿件搬入文档站。
六类业务交付文档中的 modules/<module>/test-report.md 仍在文档站维护；上述专项报告指任务性试用、测试、评估、跨模块独立汇总和过程记录，不因标题含“测试报告”而移动正式业务模块文档。正式测试与验收需要引用专项结果时，在对应模块资料记录适用结论、范围和证据来源，避免依赖文档站之外的本地相对链接。
普通对话不自动落盘；用户已要求创建或修改文稿时直接执行，无需“开始实施”口令，只读或先审阅限制仍须遵守。
reports/ 不存放临时脚本、中间转换、渲染预览、缓存、测试截图或日志。过程证据使用根 test-artifacts/，临时脚本和转换/预览使用系统临时目录或 test-artifacts/ 下任务目录，日志使用 logs/。交付前检查本任务产物归属，只清理可确认属于本任务的临时文件，不擅自迁移删除已有材料。模块工程资料仍放 modules/，不另建第二份业务基线。
代码变更与文档同步矩阵
先判断本次变化是否让现有文档失真，或产生尚未记录的必要规则、契约、数据设计及操作说明，再按下表定位正文。需要同步的内容与代码同次交付；原文仍准确时不制造无意义改动。仅维护本次受影响章节，不补无关历史资料；新规则、新接口、新表等不能以“没有旧文档”为由免更。本表涉及的模块文档按版本与证据的文档版本规则递增；仅格式、错别字或纯排版变更不升版。本表路径相对文档站。
| 实际语义变化 | 对应正文 | 同步条件与内容 |
|---|---|---|
| 业务规则、状态流转、公式、核心校验、角色权限 | modules/<module>/requirements.md | 新增或改变规则时更新唯一正文，记录适用范围、异常和验收例子；恢复已记录规则的缺陷修复不重写需求 |
| 架构、模块边界、主流程或关键设计决策 | modules/<module>/overview-design.md | 仅当设计含义变化时更新；不因需求正文变化自动复制规则 |
| API、请求响应契约、事务语义或已记录的关键调用关系 | modules/<module>/detailed-design.md | 更新变化的路径、入参、返回体、边界和调用说明；Controller/DTO 内部实现变化但原契约仍准确时免更 |
| 流程定义节点、办理人、流转条件 | 按含义定位需求、概要或详细设计 | 更新实际变化的规则与设计，不机械要求三份同时修改；布局修复按操作说明是否失真判断 |
| 持久化字段、表结构、索引、约束、字典或映射含义 | modules/<module>/database-design.md | 记录本次数据设计差异；新表全部实际列及既有表受影响字段仍按数据库设计特别检查核验。仅修复代码以符合已记录实际结构时可说明免更依据 |
| 菜单路径、操作步骤、字段含义、权限边界或提示语义 | modules/<module>/user-manual.md | 原操作说明失真或新增操作时更新；纯间距、颜色、普通重排且操作方法不变时免更，已有截图/说明因此误导时更新相关部分 |
| 稳定用例/验收标准、已知限制或已归档结论变化，正式交付 | modules/<module>/test-report.md | 更新失真的用例和结论；普通修复或回归结果按最新验证证据保留工具记录即可，不按每次运行追加报告；缺陷推翻既有结论时须纠正 |
| 公共使用契约、工程规范、部署步骤与配置要求 | handbook/ 对应正文 | 新增或改变公共使用方式时同步；公共组件内部实现调整不自动改手册 |
最终回报按根规则包含【文档同步核对】，列路径及章节，或说明“原文仍准确”的具体依据，如恢复已记录契约、操作步骤未变，不以“改动小”代替判断。用户限定只改指定文件时遵从限制，确实需要更新的文档列待办，只声明授权文件范围成果；纯审阅不修改文档。此矩阵不要求为了留下修改痕迹而重复记录，也不改变新模块按阶段建档及正式交付要求。
版本与证据
模块六类文档各自独立编号，不再维护 文档状态、实现状态 和 业务验收状态 字段。文档版本只表示该文档内容的成熟度，不表示代码已实现或业务已验收；实现与验收结论由 test-report.md 的检查记录、下文交付状态定义和交付回报承载。历史资料中的旧状态字段不为改格式批量追溯，下次实质更新时移除；其中记录的实际进展移入正文，不直接删除。
统一字段如下：
| 字段 | 填写要求 |
|---|---|
| 文档版本 | 按下方规则递增，固定两位小数 |
| 最近核对日期 | 本次事实或证据最后核对日期 |
| 受测代码状态 | 提交号；有未提交改动时记录受测文件范围和必要摘要 |
文档头部统一写成一行：
text
> 文档版本：1.21 ｜ 最近核对日期：2026-11-03文档版本规则
文档版本按内容变更幅度递增，固定两位小数（1.00、1.01、1.10、1.21、2.00），不能写成 1.1 或 v1.21。
| 阶段或变更 | 版本动作 | 示例 |
|---|---|---|
| 讨论稿起算 | 0.01 | 0.01 |
| 讨论稿小改 | +0.01 | 0.01 → 0.02 |
| 讨论稿中改 | +0.10 | 0.02 → 0.12 |
| 原型确认、开发第一版 | 固定 1.00 | 0.12 → 1.00 |
| 小功能 | +0.01 | 1.21 → 1.22 |
| 中等功能 | +0.10 | 1.22 → 1.32 |
| 大功能 | 进入下一大版本 | 1.21 → 2.00 |
| 格式、错别字、纯排版 | 不升版 | 1.21 → 1.21 |
- 小功能：单点规则、字段或文案调整，不改变流程和数据结构。
- 中等功能：新增或改变页面能力、接口契约或一类业务规则。
- 大功能：新增模块能力、重构主流程或改变数据模型。
- 版本只增不减；同一版本内多次修订不重复升版；1.x 最大
1.99，达到后下一次实质变更进入2.00。 0.x只用于尚未确认原型的讨论稿，不自动跨进 1.x；1.00在原型确认时人工落点。- 升版与文档修改在同一任务内完成，交付回报写明升版结果和所属档位。
- 不把代码提交号、实现进度或验收结论冒充文档版本。
docs:check校验模块六类文档头部的版本行：必须存在且为两位小数；缺失、重复或格式不符时报告问题。
验收结论使用下文交付状态定义：Agent 的自动化、接口、数据库和页面检查只支持相应范围的“验证通过”；用户或业务方确认后才可记录“业务验收通过”，并注明反馈来源。技术验证结果不因缺少用户业务验收而失效，普通任务不要求用户业务验收后才交付。业务方附条件确认时记录确认人、日期、条件和责任范围，条件关闭后依据业务方结论更新。
模块资料按以下维度保留证据，作为正文内容维护，不作为文档头部字段：
| 维度 | 说明 | 主要证据 |
|---|---|---|
| 业务/设计 | 目标、范围、规则和验收口径是否已有可追溯依据 | requirements.md、overview-design.md、用户指令、既有决策、核实事实或有依据的合理假设 |
| 实现 | 页面、接口和代码当前做到什么程度 | 当前代码、接口调用和运行结果 |
| 数据库 | 设计字段与实际表结构是否一致 | database-design.md、项目 MCP 回读、交付数据库基线 |
| 环境发布 | 本次表结构或流程定义变更的开发结果、生产待发布或发布结果 | 开发证据、待发布清单；生产纳入本次范围时记录其执行与回读结果。未访问生产不得推断其当前状态 |
| 验收 | 哪些路径已验证，哪些检查失败或受阻，哪些由用户待验收 | 正式交付使用 test-report.md 的最新结果和证据；普通任务可引用本次可复核的工具记录和原始产物 |
| 操作 | 用户如何进入、操作和处理异常 | user-manual.md 与当前页面 |
计划、归档讨论稿和历史实施方案只能说明意图或讨论过程，不能作为完成证据。实现进度依据当前代码和配置判断；运行证据用于判断本次代码是否已加载及行为是否得到验证，若证明实现不符合目标则按事实修正结论。数据库现状以 MCP/交付基线回读为准；验收结论以对应受测范围的最新、可复核证据为准；普通任务可直接引用工具记录和原始产物，正式交付时归档到 test-report.md。发现冲突时保留“设计目标”和“当前事实”的差异，按下文的差异分类处理，不一律标为待裁决，也不静默覆盖。
交付状态定义
| 状态 | 判定与交付含义 |
|---|---|
| 实现完成 | 本任务授权范围内的代码、配置和按同步矩阵判定的必要文档已完成；验证结果独立报告，不据此宣称验证或发布完成。 |
| 开发完成 | 实现完成，且本任务适用、未被用户明确豁免的必要验证已通过。用户指定的待验收及豁免检查分别说明，豁免范围仍标未验证、不称通过。表结构等普通开发备齐待发布内容后可报告“开发完成、生产待发布”；流程定义按根规则默认双库同步，prod 不可达时明确生产待同步。 |
| 生产待发布 | 生产执行不在本次开发交付范围，或本次发布尚未完成；明确是否属于本次承诺，列待发布清单，不等于生产可用。 |
| 发布完成 | 用户要求的目标环境变更已执行并回读验证；要求双环境时两库均须通过。发布范围未完成时不能用开发完成代替。 |
| 验证通过 | 列明的自动化、接口、数据库或页面检查在实际覆盖范围内通过。 |
| 业务验收通过 | 用户或业务方确认相应业务路径；Agent 技术检查不单独构成业务验收。 |
| 待验收 | 用户指定的检查或用户业务验收；不因未选浏览器自动产生，也不能用来替代 Agent 验证受阻。 |
| 验证失败 | 检查已执行，但结果不符合预期。 |
| 验证受阻 | 适用且应由 Agent 执行的必要检查因工具、环境、账号或授权问题未取得有效结果，继续独立检查并报告缺口。 |
| 用户豁免的未验证 | 用户明确跳过的检查范围；不得称通过或受阻。 |
失败、受阻或未执行的范围不能表述为已通过或问题已修复。验证受阻不自动否定已完成的实现；完成可独立执行的已授权工作并说明缺口后，可交付当前成果，但必要验证未完成不得宣称整体开发完成。按根 AGENTS.md 完成开发修改、必要文档和检查后即可交付，用户待验收及范围外的生产待发布不延迟开发交付；流程定义默认双库同步，prod 内网不可达时按根规则记录待同步并交付，不等待恢复。用户已要求本次发布或双环境同步时，缺少授权、入口或执行条件的发布部分仍属本次未完成，须明确报告。小任务可用简短文字区分改动、验证和剩余事项，不逐项列不适用状态。
编写顺序与协作方式
- 新模块按模块级资料的条件和阶段建档：用户要求记录业务基线或已授权实施时建立
requirements.md，后续按实际进入的设计、数据、验证和操作阶段建立适用文件；同一规则只维护一处正文，其他文件链接引用。已有模块只更新本次受影响的章节，旧模块六类结构迁移作为后续资料工作单独安排；单次局部变更可在交付回报记录要点，不因此建立第二份业务基线。 - 记录本次规则差异、依据、重要假设和少数“角色—操作—预期结果”验收例子；已有基线直接引用。验证范围与证据依赖按根“业务规则与验证”执行，不因规则变化要求固定实施流程。
- 设计、代码或数据库发生有意义的变化时，按代码变更与文档同步矩阵维护受影响章节；业务含义缺项、授权和等待条件统一按根“基本协作规则”执行。
- 正式对外交付或正式版本验收前形成需求—设计—接口—测试追踪矩阵，并核对适用的截图、日志、接口响应和数据库结构等证据；普通任务和内部验证仅更新受影响记录。
- 验收后补正式版本、编制/审核信息和交付清单，不以草稿复制件建立第二事实源。
发现代码与设计差异时，先区分实现缺陷、文档滞后和业务基线冲突。存在明确、适用的既有契约时，按受影响范围修复缺陷，其中前后端代码修改遵循根规则的实施开关；能依据当前用户指令、已记录决策或其他适用且可核实的业务契约证明文档滞后时，更新受影响资料，无需实施口令。基线冲突先根据当前用户指令和适用上下文判断，仍无法确定时才列为待裁决并按根规则处理必要澄清，不把所有差异都变成用户批准事项。交付前按原型及已记录来源检查漏做、改义和多做；反馈先提炼实际改变的规则，再同步直接受影响的页面、接口或文档。不得仅以当前代码为依据改写业务设计；未验证内容标记为待核对。
最新验证证据
普通任务最终回报写检查名称、实际结果及必要限制，详细命令、时间和受测范围可引用本次可复核的工具记录和原始产物，不要求先转写正式文档或逐项重复展示；核心行为变化仍说明对应代码与验证范围。正式交付模块更新 test-report.md 的受影响条目，不另建流水日志，证据最少包含：
- 验证时间与环境（不含凭据或私有地址）。
- 对应代码状态：提交号；存在未提交改动时注明受测文件范围，必要时记录文件摘要，不能只写 HEAD。
- 命令，或页面入口、角色及操作路径。
- 实际结果：目标测试及执行/失败/跳过数量，或操作的预期与实际结果。
- 未通过或尚未取得有效证据的范围及原因，按根规则区分“验证失败”“验证受阻”、用户豁免的“未验证”和用户“待验收”；用户验证页面时记录用户反馈的时间和覆盖范围。
证据必须对应最后一次相关行为修改，并仅支持实际覆盖的结论。测试复用、执行范围和重跑条件统一见验证范围。已选定或用户显式要求的真实链路及页面检查按根规则执行，不能以构建或单元测试冒充页面或整链路通过。
结论分类见交付状态定义；页面证据、依赖范围、授权及交付闸门见根 AGENTS.md。本节只规定证据记录，不另设批准、等待或提交推送条件。
数据库设计特别检查
- 新表设计、结构重构和正式数据库设计交付必须为范围内每张实际持久化表提供完整字段矩阵，字段一行一项并填写中文业务含义；至少包含字段名、业务含义、逻辑类型、物理类型、长度/精度、可空性、默认值、主键/外键/唯一性、索引、来源/生成规则、核验状态。字段注释和业务来源不一致或缺失且无法确认时标记待核对，不得猜测。
- 普通局部变更更新本次涉及字段、约束及关联差异，并通过项目 MCP 核对实际对象；已有完整矩阵时在原文维护。历史矩阵缺失记录为交付资料待补项，不自动扩展本次开发范围，正式交付前仍须补齐；普通开发任务新增表的全部实际列（含主键、审计及继承字段）均属本次范围，按上一条要素用紧凑矩阵记录在受影响模块
database-design.md的对应章节。旧模块尚无该文件且本次不是资料迁移任务时，可先在本次交付报告记录紧凑矩阵并标明待归档，不因此扩大为全模块文档迁移。本节的全量字段、关系追溯和多来源核对要求用于上述完整设计范围；局部变更按受影响范围执行，不免除适用的实际列及真实读写链路验证。 - 主键、审计字段、租户/组织字段、流程关联字段、逻辑删除、版本、快照和派生字段都不能省略；用户明确要求兼容旧数据时，才保留兼容历史字段。页面未展示不等于可以省略。
- “核心字段”只能作为全量矩阵中的阅读摘要或标记，不能代替全量数据库设计。
- 完整设计用实体代码、项目 MCP 结构查询和交付数据库基线反向核对表名、字段类型、空值、默认值、索引和约束。记录核验时间及本次实际使用的来源；局部修改不要求同时取得全部来源，未核对内容不得标为已核对。
- 必须同时记录“设计字段”和“实际字段”的差异。新增、缺失、类型/长度不一致、默认值不一致都列为待处理项；未核对字段标记为“待核对”，不得用猜测补齐。
- 业务设计写逻辑类型与约束，厂商专属 DDL 通过 MCP 执行并在交付数据库变更记录中说明。当前 DM8 只是运行环境，须标明人大金仓、openGauss 等目标数据库的兼容风险，不能把 DM8 方言写成业务规则。
- 所有表关系必须能追溯到业务需求和接口；孤立字段、重复字典和无法解释的索引列入遗留问题。
正式对外交付与正式版本验收的完成定义
本节用于正式对外交付或正式版本验收，不作为普通开发任务、内部验证或本轮工作回报的统一完成门槛。普通任务按最新验证证据分别报告实现、验证通过或失败、验证受阻、用户豁免的未验证及用户待验收的范围；后续实现依赖尚无有效证据的结论时仍遵循根 AGENTS.md 的依赖规则。适用的文档维护和发布前检查要求不因此免除。
- 模块、平台和版本文档的版本与本次发布版本一致。
- 所有图、表、接口、页面路径和字段来自已核对事实；未实现、未验证和待确认内容明确标注。
- 需求、设计、数据库、测试、操作步骤和发布范围之间可追踪。
- 文档中没有真实凭据、个人敏感信息或仅供开发环境使用的内部地址。开发账号资料以私有仓库根 README 为维护来源，既有运行配置的位置和授权边界遵循根
AGENTS.md；凭据不得进入公开文档站、Issue、截图、日志、外部材料或其他仓库；私有仓库根 README 的账号章节与已被 Git 忽略的本机配置是凭据的既定存放位置，维护这些文件不视为凭据外泄。 - 发布前通过文档检查与发布入口完成严格 UTF-8 解码、引用检查、敏感信息扫描和文档构建；扫描源码及最终文本产物，任一发布检查失败即停止发布脚本，不继续脚本内的提交推送或上传。用户已有明确授权的普通提交推送按根
AGENTS.md执行，非安全类的检查失败可如实记录后提交推送；不得因此豁免凭据保护、提交钩子或已授权推送范围检查，也不得继续上传。附件和图片另行人工核对，不把文本扫描描述成全媒体审查。