# Feature Specification: REV-004 账务处理一期 **Feature Branch**: `001-rev004-accounting` **Created**: 2026-03-13 **Status**: Draft **Input**: User description: "我想先做的 REV-004" ## Document Scope & Sources *(mandatory)* - **Target documents**: - `docs/design/02_Detailed_Design/12_REV_Detailed.md` - `docs/design/03_Technical_Design/03_Interface_Design.md` - `docs/design/03_Technical_Design/01_Database_Design.md` - `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` - `docs/design/00_Management/01_Project_Progress.md` - `docs/design/00_Management/03_Task_Checklist.md` - **Primary source of truth**: - `docs/design/01_Overview/03_Summary_Design.md` - `docs/design/02_Detailed_Design/12_REV_Detailed.md` - `docs/design/03_Technical_Design/03_Interface_Design.md` - `docs/design/03_Technical_Design/01_Database_Design.md` - `.specify/memory/constitution.md` - **Reference sources**: - `docs/guides/REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md` - `docs/design/00_Management/15_Legacy_Migration_Gap_Analysis.md` - `docs/design/04_Appendix/Archive/03_Design_Docs/营业收费管理系统-概要设计说明书20250912.md` - **Scope decision**: In scope。该需求属于既有 `REV-004` 模块范围内的账务处理一期收敛任务，允许在现有正式文档体系内补齐范围、接口、数据口径和执行约束，并输出后续实施计划所需的边界、任务拆解与验收依据；本轮不直接进入 backend 代码修改，不包含超出一期边界的新业务域扩展。 ## User Scenarios & Testing *(mandatory)* ### User Story 1 - 收敛一期范围 (Priority: P1) 作为项目负责人，我需要先把 `REV-004` 一期的业务边界、纳入场景和排除项写清楚，以便团队在启动后续工作时不会把退款、冲正、坏账等事项扩展成超范围的账务重构任务。 **Why this priority**: 范围不收敛会直接导致后续计划、任务和实施偏离宪法规定的“范围交集优先”。 **Independent Test**: 审阅者仅通过 `12_REV_Detailed.md` 与 `REV004_ACCOUNTING_EXECUTION_PLAYBOOK.md`，即可确认一期纳入范围、排除范围和关键对象是否一致。 **Acceptance Scenarios**: 1. **Given** 当前 `REV-004` 在多个文档中仅有摘要性描述，**When** 完成本次规格修订，**Then** 审阅者能够明确识别一期纳入场景、排除项和边界依据。 2. **Given** 团队准备启动后续计划或执行，**When** 查阅本次规格，**Then** 不会把非一期内容误判为当前必须推进的范围。 --- ### User Story 2 - 对齐接口与数据口径 (Priority: P2) 作为方案设计与评审人员，我需要让 `REV-004` 的详细设计、接口设计和数据库设计在同一口径下表达账务处理对象、处理结果和留痕要求，以便评审时可以追溯并核对。 **Why this priority**: `REV-004` 当前涉及详细设计、接口定义和数据库承接说明，若三者不一致，会直接影响后续任务分解与验收。 **Independent Test**: 审阅者仅通过对照 `12_REV_Detailed.md`、`03_Interface_Design.md`、`01_Database_Design.md`，即可确认账务处理场景、核心对象和留痕要求是否一致。 **Acceptance Scenarios**: 1. **Given** 账务处理涉及详细设计、接口和数据库三个正式文档，**When** 完成本次规格定义，**Then** 审阅者能够在三份文档之间建立稳定的追溯关系。 --- ### User Story 3 - 形成可执行交付闭环 (Priority: P3) 作为项目维护人员，我需要把 `REV-004` 的执行手册与项目管理台账同步起来，并明确后续实施计划按“共性能力先统一、场景能力再分批”的方式组织，以便后续进入 clarify、plan、tasks 阶段时，能够先统一留痕、原始依据、结果状态以及接口/数据库口径，再按账务调整、退款、冲正、坏账申请等场景拆解任务并留存过程记录，而不在本轮直接进入 backend 代码修改；本轮验收入口应以文档一致性、计划可拆解性和台账可回写性为准。 **Why this priority**: 没有交付闭环，`REV-004` 容易停留在文档存在但不可执行、已推进但未回写台账的状态。 **Independent Test**: 审阅者仅通过检查执行手册和管理台账，即可确认 `REV-004` 的目标、完成条件、实施计划边界、共性能力优先顺序、验收入口和后续动作已被记录。 **Acceptance Scenarios**: 1. **Given** 当前仓库已有 `REV-004` 执行手册和相关任务记录，**When** 完成本次规格，**Then** 审阅者能够判断哪些台账需要同步、何时视为一期范围收口完成，以及后续实施计划应先覆盖哪些共性能力、再拆解哪些业务场景。 2. **Given** 当前阶段仍以文档收敛和计划准备为主，**When** 审阅者据此验收本轮规格，**Then** 其可直接依据规格确认文档口径是否一致、后续计划是否可拆解、台账更新点是否明确，而无需以代码完成度作为前提。 --- ### Edge Cases - 当历史资料中出现比当前主文档更细的账务场景时，必须仅作为参考来源，不得直接提升为当前一期必做范围。 - 当接口、详细设计与数据库文档对同一账务对象使用不同名称或粒度时，必须先统一正式口径，再进入后续计划或实施。 - 当一期范围内存在“需要审批”类表述时，本轮仅保留能力位和边界说明，不展开完整审批流程、节点或流转规则。 - 当执行手册与项目进度台账状态不一致时，必须明确以当前主文档与本次规格确认后的口径回写台账。 ## Requirements *(mandatory)* ### Functional Requirements - **FR-001**: Specification MUST 明确 `REV-004` 一期的目标文档清单，并说明每份文档承担的职责。 - **FR-002**: Specification MUST 明确 `REV-004` 一期的主口径来源，包括概要、详细、接口、数据库与项目宪法。 - **FR-003**: Specification MUST 明确 `REV-004` 一期纳入范围，包括账务调整、退款、冲正、坏账申请等当前主文档已覆盖的核心场景。 - **FR-004**: Specification MUST 明确后续实施计划按“共性能力先统一、场景能力再分批”的方式组织：先统一留痕、原始依据、结果状态以及接口/数据库口径，再按账务调整、退款、冲正、坏账申请等场景拆解实施。 - **FR-005**: Specification MUST 明确 `REV-004` 一期不纳入范围，避免将非一期台账细化、跨模块重构或未确认能力带入本轮工作。 - **FR-006**: Specification MUST 明确 `REV-004` 在详细设计、接口设计和数据库设计之间的追溯关系，确保核心对象和处理结果表达一致。 - **FR-007**: Specification MUST 明确账务处理留痕、原始依据和结果回写属于本次范围内必须说明的内容。 - **FR-008**: Specification MUST 明确执行手册、项目进度和任务清单是否需要同步更新，以及更新触发条件。 - **FR-009**: Specification MUST 明确后续实施计划需要覆盖的边界、任务拆解和验收入口；本轮验收入口应限定为文档一致性、计划可拆解性和台账可回写性，不得把 backend 代码修改写成本轮已执行内容。 - **FR-010**: Specification MUST 明确审批相关表述在本轮仅保留能力位和边界说明，不展开完整审批流程、节点或流转规则。 - **FR-011**: Specification MUST 明确后续进入 clarify、plan、tasks 前必须完成的最小校验动作。 - **FR-012**: Specification MUST 保持用户视角和业务视角表述，不将具体实现语言、接口路径、代码结构或脚本命令写成本规格的验收前提。 ### Key Entities *(include if feature involves data)* - **REV-004 一期范围**: 本轮允许推进的账务处理业务集合，用于约束纳入内容与排除内容。 - **共性能力**: 在分场景实施前需要统一规划的留痕、原始依据、结果状态以及接口/数据库口径要求。 - **账务处理场景**: 账务调整、退款、冲正、坏账申请等业务事项，是本次规格的核心业务对象。 - **正式目标文档**: 承载 `REV-004` 设计口径的正式 Markdown 文档，用于落地单一真源。 - **参考来源**: 用于核对历史边界、迁移差距或执行建议的辅助文档，不直接替代正式结论。 - **留痕要求**: 对账务处理前后变化、处理依据、结果状态和责任归属的记录要求。 - **台账更新**: 项目进度与任务清单中的记录动作，用于形成阶段性交付闭环。 ## Assumptions - 本次“先做 REV-004”默认指向 `REV-004` 账务处理一期的文档范围收敛，并在同一轮明确后续实施计划所需的边界、任务拆解与验收入口，而不是直接启动跨模块代码开发。 - 后续实施计划默认采用“共性能力先统一、场景能力再分批”的组织方式：先统一留痕、原始依据、结果状态以及接口/数据库口径，再按账务调整、退款、冲正、坏账申请等场景拆解。 - 当前一期默认聚焦既有主文档已覆盖的账务处理核心场景，不额外扩大到新的独立台账体系或跨模块能力改造。 - 若资料中出现审批相关描述，本轮默认仅保留能力位和边界说明，不细化为完整审批流程定义。 - 若后续 clarify 阶段确认需要进一步收缩到单一子场景，本规格仍可作为 `REV-004` 一期总范围基线。 - 本规格已完成 clarify 收敛；后续阶段应基于已确认边界继续推进 `/speckit.plan`、`/speckit.tasks`、`/speckit.analyze` 与正式文档修订。 ## Clarifications ### Session 2026-03-13 - Q: 本轮 `REV-004` 目标深度是仅做文档收敛，还是同时产出后续实施计划，或直接进入文档加 backend 一期闭环？ → A: 本轮完成文档收敛，并生成后续实施计划所需的边界、任务拆解与验收要求，但先不改 backend 代码。 - Q: 后续实施计划应整体覆盖一期全部场景，还是按不同场景分批组织？ → A: 按“共性能力先统一、场景能力再分批”的方式组织，先统一留痕、原始依据、结果状态以及接口/数据库口径，再按账务调整、退款、冲正、坏账申请等场景拆解。 - Q: 本轮规格的验收入口应收敛到哪一层？ → A: 以文档一致性、计划可拆解性和台账可回写性作为本轮验收入口，不以代码完成度作为前提。 - Q: 审批相关场景在本轮应细化到什么程度？ → A: 本轮仅保留能力位和边界说明，不展开完整审批流程、节点或流转规则。 ## Success Criteria *(mandatory)* ### Measurable Outcomes - **SC-001**: 规格中明确列出至少 4 份 `REV-004` 相关目标文档，且每份文档的职责可被审阅者独立理解。 - **SC-002**: 审阅者在阅读规格后，可在 5 分钟内判断 `REV-004` 一期哪些场景纳入、哪些内容排除，无需再查找额外上下文才能做出范围判断。 - **SC-003**: 审阅者可依据规格明确识别详细设计、接口设计、数据库设计与执行手册之间的追溯关系，且不存在职责重叠或空缺。 - **SC-004**: 审阅者可依据规格直接列出后续实施计划应覆盖的边界、任务拆解与验收入口，并能独立确认本轮是否已满足文档一致性、计划可拆解性和台账可回写性三项验收条件。