Files
a-share-analysis/docs/governance/documentation-traceability.md

1.8 KiB

文档与追溯规范

1. 追溯主键

每个业务变化必须有唯一功能编号。功能编号贯穿需求、设计、ADR、代码提交、测试、截图、GitNexus 报告、发布和回退。

2. 功能档案必备内容

docs/features/<编号>-<短名称>/
├── manifest.yaml
├── prd.md
├── requirements.md
├── design.md
├── implementation-plan.md
├── test-plan.md
├── gitnexus/
│   ├── before.md
│   ├── impact-plan.md
│   ├── detected-changes.md
│   ├── after.md
│   └── comparison.md
├── screenshots/
│   ├── reference/
│   ├── iterations/
│   └── released/
├── qa/
│   ├── test-results.md
│   └── visual-qa.md
├── review/
│   ├── code-review.md
│   └── standards-review.md
├── release-notes.md
└── rollback.md

3. 历史保留

  • 已发布文档不删除、不覆盖历史结论;修订通过 Git 历史和文档版本说明保留。
  • PRD 是产品目标和验收口径的正式来源;requirements.md 是从 PRD 派生的工程约束,二者不能相互替代。
  • Review 文件必须记录审查范围、基线提交、审查提交、发现、处置和最终结论,禁止只写“看过了”。
  • 重大方案变化新增 ADR,旧 ADR 标记被替代。
  • 规则、提示词、API 和事件契约使用明确版本。
  • 截图文件名包含页面、状态、视口和版本,例如 market-overview-trading-1440x1200-v0.1.0.png
  • .gitnexus/ 不提交;可读的 GitNexus 摘要和比较报告必须提交。

4. 可阅读性

文档先写结论,再写背景、方案和证据。禁止使用“见聊天记录”“以后再说”“大概如此”作为正式设计依据。链接使用仓库相对路径,保证在本地与 Gitea 中均可阅读。