# 文档与追溯规范

## 1. 追溯主键

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

## 2. 功能档案必备内容

```text
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 中均可阅读。