维护规范

写作原则

先写结论，再给依据。每页只维护一个主题；事实、建议、决策分开。不要因版式统一重写已核实内容，不把目录改名当成重构完成。

源码依据与状态

每次更新受影响文档时，在页首或相关章节记录：

source_repo: maodo
source_ref: feature/yufan
verified_commit: 完整提交号
verified_at: YYYY-MM-DD
verification: static

以上是示例，不能把占位值写成已核实结果。static 表示静态核对；tested 必须附执行命令、环境和结果；pending 表示未核实。设计建议标明“建议”，只有确认后才进入决策记录。

旧文档已在总览记录本轮基线；本次不批量插入元数据。src/.wiki/source-map.json 记录文档与源码范围的关联及基线，后续按实际审阅结果更新。

依据至少写出仓库、提交、文件路径和符号名；行号可补充，但不能作为唯一定位方式。不记录密钥、真实短信内容或生产个人信息。

更新与关联

受影响章节末尾可追加简短更新记录：日期、源码提交、变化结论、验证方式。网站显示的 Git 更新时间只是文档最近提交时间，不等于源码核实时间。

模块页关联实施路线、架构决策和其他模块时使用相对 Markdown 链接。共享结论只保留一处正文，其他页面引用它。

新增页面需要加入导航；改变路径前先查找所有引用并准备重定向，获得确认后再移动。已有正文不因网站建设而覆盖。

提交检查

执行 npm run docs:check 和 npm run docs:build；确认没有新增无效链接。评估源码关联是否需要更新；将文档变更与核实基线一起审阅。构建通过不能证明架构描述正确。