Issue 25

Issue #25：[优化] 启用 GitHub Wiki，集中维护功能与缺陷设计文档

Issue #25 · PR #30 · 迁移清单与验证

2026-09-16 从 Issue 迁入的需求与方案快照，保留原始验收勾选状态；当前进度以关联 Issue / PR 为准。实现细节、验收证据和未验证项见上方记录。

背景与问题

目前功能和缺陷的设计文档直接保存在代码仓库中，文档及配套图片、附件持续累积会增加主仓库体积。希望启用 GitHub Wiki，集中保存和维护这些设计资料。

目标

将 GitHub Wiki 作为功能与缺陷设计文档的统一入口，减少此类资料对主仓库后续体积增长的影响，并让文档与对应 Issue / PR 保持关联。

需求与范围

• 启用本仓库的 GitHub Wiki，建立首页及功能设计、缺陷修复设计的分类索引。
• 盘点并迁移仓库中已有的相关设计文档及必要图片、附件，核对内容完整性后清理主仓库中的重复文件。
• 在 README、贡献指南及相关 Issue / PR 中补充或更新文档链接，约定后续设计文档统一维护在 Wiki。
• 项目运行、开发所需的基础说明继续保留在代码仓库；具体迁移清单在实施时确认。

方案建议与代码线索

建议按功能或缺陷对应的 Issue 编号组织 Wiki 页面，记录背景、目标、方案、验收标准及关联 PR。文档迁移时同步处理相对链接、图片引用和原文档入口。

验收标准

• GitHub Wiki 已启用，首页能访问功能与缺陷设计文档索引。
• 迁移清单中的文档内容、图片及附件完整，页面和关联链接可正常访问。
• 主仓库中已迁移的重复资料完成清理，README 和贡献指南提供 Wiki 入口及维护约定。
• 新增功能或缺陷设计文档可按约定在 Wiki 维护，并与对应 Issue / PR 关联。

验证方案

按迁移清单逐项核对原文与 Wiki 内容；检查分类索引、图片、附件和 Issue / PR 链接；检查仓库内是否仍引用已移除的文档路径。

风险与待确认

迁移或删除当前版本中的文件不会自动缩小已有 Git 历史体积。本项先控制后续增长；若需要回收历史占用，应另行评估历史清理及协作影响。具体文档与附件迁移清单待实施时确认。

实施方案与结果（2026-09-16）

• 已启用独立 Wiki 仓库，以 Issue-<编号> 组织设计、Issue-<编号>-Validation 组织历史验收，建立首页、两类索引、历史规划、维护约定与模板。
• 迁移范围为 10 份文档和 40 个附件：项目开发计划、UI 重构计划、早期 GitHub 更新验收，以及 Issue #5、#6、#12、#13、#18、#19、#21 的验收资料。逐文件对应关系和 SHA-256 见迁移清单。
• 原文保留历史环境、测试失败及未验证项；只改链接并补充归档说明。项目外内容不进入 Wiki，运行/配置/发布说明与测试 fixtures 留在主仓库。
• 先发布 Wiki 并核验线上内容，再清理主仓库重复文件。README、贡献指南及 Issue / PR 模板引导后续资料统一进入 Wiki；既有相关 Issue / PR 的活动链接同步更新。
• Wiki 已上线，主仓库清理与模板更新提交于 PR #30，待合并到 development 后生效。Issue 的当前验收状态以原 Issue 为准。

验证与回退

25 个页面、40 个迁移附件及校验清单的线上访问通过；附件下载后的 SHA-256 与源文件一致。正文完整性、删除路径残留检查、表单 YAML 与格式检查通过。详细证据见迁移验证记录。

若需回退主仓库清理，回退对应代码提交并核对入口；Wiki 可通过独立 Git 历史恢复修订。未重写主仓库历史，不宣称回收历史占用。