PLAT-01-002 产品需求驱动文档体系

已废弃（2026-10-16）：文档体系以 ADR-0001 和文档体系说明为准；“代码不能反向定义需求”原则已并入 ADR-0001 第 8 条。本文仅供参考。

文档基线：2026-10-04。根据用户本次要求，平台采用精简的产品需求驱动体系，参考 MagicCat 的产品—设计—开发—验收追踪方法，沿用本项目 PL、T、AC 编号与现有规则源。

所有 UI、交互、接口、实现和测试都应能追溯到核心产品需求 PRD中的用户结果。已有代码、旧页面、上游能力和测试结果用于识别覆盖与缺口，不能自行扩大或缩减产品范围。

主链

产品规定用户结果和边界；设计规定如何看见与操作；开发规定实现方法；测试验证产品预期。测试失败形成缺陷，需求改变回到产品规则与决策。

精简目录与唯一责任

位置	唯一责任	核心入口
`platform/product/`	用户、目标、一期边界、产品行为、验收	总 PRD；scope/journeys/requirements/acceptance 为范围、流程、编号及验收索引
`platform/design/`	页面结构、两端成对流程、全状态交互与设计证据	设计入口、页面规格、管理端规格、交互规则
`platform/development/`	架构、数据、契约、实现与测试方法	开发入口、追踪矩阵
`platform/implementation/`	任务依赖、开放问题、证据及缺口	任务、现状缺口、证据索引
平台仓库 `docs/`	可执行运行说明、OpenAPI、源码基线及脱敏证据	平台 README、`docs/openapi/platform.json`、`docs/verification/`

身份、钱包、中转等现有模块页仍维护业务规则细则。设计 token、组件品牌源继续在 Design 仓库；运行与发布沿用已有 development/operations，不再另建同内容目录。常规任务直接使用 T-01～T-10 与现有证据模板，不增加 Freeze、Atomic、Task Packet 等多套台账。

编号与状态

PL-001～PL-018、PL-N01～PL-N05 保持稳定；总 PRD 用 PL-003.R01 这样的子编号描述可单独验收的行为，不改父需求编号。
J-01～J-12是客户与员工流程；UX-01～UX-12是体验流程，其中UX-06～12为管理端独立主线；UI-C/UI-A 是页面标识；IX 是全局交互规则。
AC-01～AC-13 保持原验收编号；子行为可共享 AC，但各自保留独立输入、预期与判定。
产品状态为已确认、待决策、后续或已撤销；设计覆盖为未映射、部分、完整；实现验收为未审计、部分有证据、具名范围通过。状态不能互相替代。

后续扩展编号保持独立：PL-019/T-11/AC-14为邀请活动，PL-020/T-12/AC-15为多资源权益与旧客户承接，PL-021/T-13/AC-16为全域记录与产品运营。新增子行为不能借既有父任务通过记录结项。产品运营维护其领域细则，产品子站文档只维护接入和页面边界。

本次文档整理只将已有明确决定转成可追踪的产品要求；新增体验细化标为待复核。没有用户确认依据的商业、期限、容量或收费规则保留待决策，不因写入 PRD 自动变为已批准。

如何处理冲突

最新用户决定优先。全局架构和商业决定维护在决策索引，产品结果维护在总 PRD，领域细则维护在对应模块页；发生冲突必须同步受影响正文与追踪行。未解决的语义差异登记到缺口清单，受影响能力不能据其中任一旧描述自行上架。

OpenAPI 是技术接口契约源，不决定产品承诺。历史证据只证明当时版本；产品验收源是 PRD/AC 的预期，不能为了让现有测试通过而改低预期。

每次工作的最小交付

写明 PL 子行为、总 PRD章节、UI/IX、T 与 AC；纯后端行为注明不涉及页面。
先核对产品结果与全状态设计，再审计实际基线代码与正式契约。
实现时同步必要契约、迁移与页面；发现新增业务含义先补产品定义。
按风险选择自动化、真实隔离 PostgreSQL、页面及恢复验证，保存具名范围证据。
更新追踪、任务和缺口；产品、设计、业务验收、生产发布分别判定。

本规则不额外引入逐次审批。已获本会话授权的工作继续执行；可配置商业值由相应后台填写，生产/真实支付/收费模型按会话授权执行。

对既有代码的补文档顺序

先汇总已确认需求，再把当前页面、代码和测试映射进追踪表，最后逐项判定满足、缺失、冲突或待复验。保留已有证据的原时点与含义；未覆盖的新子行为不能靠父需求已有通过记录直接结项。

本轮只建立总 PRD和初始设计/追踪规格，不重跑业务测试，不调整代码，不将一期登记完成。