fujian_water_biz_doc/specs/001-rev004-accounting/spec.md

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: 审阅者可依据规格直接列出后续实施计划应覆盖的边界、任务拆解与验收入口，并能独立确认本轮是否已满足文档一致性、计划可拆解性和台账可回写性三项验收条件。