# OpenSpec Project

## Purpose

普瑞互联网医院小程序 V2.0 使用 OpenSpec 管理功能模块开发过程中的规格变更、任务追踪和最终归档。

## Conventions

1. 一个主要功能模块的首次开发对应一个 OpenSpec change；归档后的整改、跨模块补丁和 UI 补丁允许创建 corrective change，但必须登记关联模块，不得自动扩充正式执行模块数量。
2. change ID 应绑定功能编码。
3. 后续默认按 `新版设计校准后最终功能模块清单.md` 的 28 个正式模块创建 change；`功能模块划分评审表.md` 第 7 节 37 个候选模块仅作为边界参考和必要时二次拆分依据。
4. OpenSpec change 由开发者或开发者 AI 在领取模块后、正式开发前创建，项目管理侧不提前批量创建。
5. 开发前需要 proposal、tasks 和 spec delta。
6. 开发完成且项目管理复核通过后执行 archive。若剩余项仅为最终人工、真机、真实数据或高风险链路验证，项目负责人可裁定将其保留在全量验收治理中并执行 archive；不得反向勾选未实际完成的历史任务，归档总结必须明确遗留验证边界。
7. archive 后的变更需要提交 git。
8. 正式 spec 表达当前业务与实现约束；历史分支、旧基线 commit、开发者自检和集成过程只作追溯信息，不得作为现行业务 MUST 或测试预期。
9. change 未 archive 前，其 spec delta 是对应变更范围内的临时有效规格来源；与正式 spec 冲突时必须由项目负责人裁定并在归档前消除，不得长期保留两套相反口径。
10. 当前执行范围固定为 28 个基线模块加 `PRI-MP-HOME-002`，共 29 个执行模块。`PRI-MP-UI-001` 等横向 UI 整改只作为受影响模块的补丁来源，不新增第 30 个模块。

## Change Naming

```text
pri-mp-{domain}-{seq}-{english-name}
```

Example:

```text
pri-mp-reg-001-registration-flow
```