DataOps-platform/docs/phase3/P3_WP00_SCOPE_BASELINE.md

P3-WP00 第三阶段范围、责任与企业依赖基线

1. 基线结论

P3-WP00 的工程基线已建立，状态为 工程基线完成待企业输入确认。这不是已进入或 已通过企业 UAT。P3-WP00 没有实现 SSO、企业连接器、边缘网关、Kubernetes、Agent、多租户、 BI/AI、计量或插件功能。

本基线冻结以下事实：

• 当前分支 codex/dataops-phase3-enterprise-readiness 的捕获提交为 487b57d， 其与 v0.3.0-phase2 的共同基线是 95023e5；本地远端跟踪分支 origin/codex/dataops-phase2-platformization 也解析到该提交。
• 第 12 章 264 个唯一模块编号已逐项进入机器追踪清单，成熟度逐字保留，未因 P3-WP00 建档而升级。
• 12 项原始第三阶段待办全部映射到 P3-WP01～P3-WP13；P3-WP00 负责基线， P3-WP14 负责已启动范围的验收与台账收口。
• 9 个 P0 工作包都有责任角色、必需输入、验收角色和退出条件；企业人员姓名均为 null，企业输入均为 TBD_EXTERNAL。
• 19 项默认指标已冻结；企业分母、窗口、阈值覆盖和批准人姓名在证据到位前保持 TBD_EXTERNAL 或 null。

机器事实分别见：

• docs/phase3/P3_WP00_REQUIREMENTS.json
• docs/phase3/P3_WP00_BASELINE_MANIFEST.json
• docs/phase3/P3_WP00_EXECUTION_REGISTERS.json

2. 范围冻结

2.1 第三阶段交付线

交付线	工作包	P3-WP00 决定
企业试点必达主线	P3-WP00～06、P3-WP08、P3-WP14	固定 P0 范围；企业输入不足时保持外部门禁
生产强化线	P3-WP07、P3-WP09	仅按批准的基础设施和 AI 方案、团队容量启动
条件扩展线	P3-WP10～P3-WP13	多租户、BI/AI、成本和插件条件及容量同时满足后启动；否则书面顺延

固定边界仍是数据运营与治理产品。不建设 NL2SQL、在线分析、BI 报表开发、通用 ETL IDE、无人值守高风险业务决策、独立移动 App 或未经批准的财务结算； 不得用 Mock、本地测试或本地数据库计数替代企业验收。

2.2 原待办与增补

P3-01～P3-12 均有显式工作包映射。实施计划相对原始待办新增的模块仅用于补齐必要 执行边界：

• P3-01 增补 IAM-05，保证 Claims 映射落到资源授权执行面；
• P3-02 增补 IAM-13、CON-22、SEC-05～07，覆盖机器身份、健康兼容与边缘安全；
• P3-03 增补 DFY-22，覆盖任务运行、失败、SLA、资源和成本信号；
• P3-08 增补 PLT-13～14，覆盖多环境隔离和不可变晋级。

完整的 original_backlog_id、added_module_ids、split_work_packages 与 change_reason 见需求 JSON；没有将其他模块暗示为第三阶段完成。

3. 264 项模块追踪

机器清单与功能台账第 12 章的模块编号、模块分级/功能项、描述和成熟度四列逐项 一一对应。每条同时保存 module_name、description、maturity_source_text，使用 normalized_maturity 支持确定性聚合，并把 implementation_owner_wp、dependent_wps 和 closure_wp 分开：

disposition	数量	含义
P3_WORK_PACKAGE	181	由第三阶段明确工作包实施或验证；P3-WP14 收口，不表示当前已完成
MAINTAIN	74	不增加第三阶段范围，保持已有能力和兼容性
FUTURE_PHASE	6	未列入本阶段工作包，保留后续阶段
PRODUCT_BOUNDARY	2	KAI-10、PLT-32 明确不扩展
RETIREMENT	1	DFY-13 只按兼容、迁移和退役门禁处理
合计	264	唯一编号与当前成熟度均由契约测试核对

P3_WORK_PACKAGE 只表示存在实施或验证责任，绝不等于完成。P3-WP08 对 CAT、SEM、 DQA、GOV、WFC 家族的目标是第三业务域复用验证与缺口追踪， 不代表该家族所有规划项都必须新建，也不把未通过企业验收的模块标记完成。

4. 企业输入

企业输入分成 17 个独立门禁：试点目标、身份、企业来源一、企业来源二、网络、监控、 SMTP、协作、ITSM、安全法务、基础设施、第三业务域、AI、多租户、BI/AI、成本和 插件。每项均记录 owner role、影响工作包、证据和阻断效果。

当前 17 项状态全部为 TBD_EXTERNAL，企业名称为 null，证据为 TBD_EXTERNAL。这意味着 P3-WP01～06、P3-WP08 和 P3-WP14 虽已有可执行进入契约， 但不能把后续企业功能或验收标记完成；P3-WP10～13 仍是条件触发范围。

5. 责任与退出条件

P0 工作包 P3-WP00～06、P3-WP08、P3-WP14 均在需求 JSON 中固化：

• owner_role 与 acceptance_owner_role；
• required_inputs；
• 可被证据验证的 exit_criteria；
• owner_person_name 和 acceptance_owner_person_name 均为 null。

P3-WP00 另行区分已满足的 engineering_baseline_inputs 与仍待确认的 enterprise_gate_inputs；后者不否定建档工程完成，但阻止把试点范围和后续功能标记 完成。所有 P0 required_inputs 与企业输入的 required_by_wp 均做双向契约校验。

角色用于明确责任类型，不冒充企业实名任命。企业必须在相关工作包启动前将姓名与 授权证据写入外部门禁登记；平台开发人员不得代替企业业务、安全、运维或验收负责人。

6. 验收指标

第三阶段计划第 10 章的 19 项默认指标已经逐项固化 definition、target、 denominator_or_sample、window、source、approver_role 和 status。默认目标包括第二域 入账率、身份映射与回收、两个连接器、增量/幂等、边缘出域、事故与送达、安全回收、 可用性与恢复、第三域通用化、Agent、安全缺陷和全链追溯。

可直接定义的默认值保留为默认基线；依赖试点对象、企业时限、规模和观测窗口的字段 标为 TBD_EXTERNAL。企业标准更严格时可覆盖；放宽必须按范围变更登记并由对应角色 批准。条件包的附加指标仍在第三阶段计划中，只有对应工作包获准启动后才进入该包验收。

7. 容量与排期

P3_WP00_EXECUTION_REGISTERS.json 冻结 24 周参考顺序和三档容量规则。该排期状态为 UNAPPROVED_REFERENCE_SEQUENCE，不是交付承诺。当前团队人数、 可用人周、并行企业负责人和交付剖面均是 TBD_EXTERNAL，所以 capacity_decision.status 保持 TBD_EXTERNAL，不虚构已批准容量。

执行前必须互斥选择 PROFILE_1_2、PROFILE_3 或 PROFILE_4_5 并形成批准证据。 三档剖面均完整保留 P3-WP00～06、P3-WP08、P3-WP14 九个 P0 包，并将 WP00～14 逐项互斥分类为 committed、eligible 或 deferred；1～2 人容量不足时 只通过 delivery_depth 收窄 P3-WP04/P3-WP06 的交付深度，不创造虚构工作包编号， P3-WP09 只允许“模型网关/预算/沙箱最小闭环”，不遗漏或顺延 P0。无论采用哪一档容量， 都不得裁剪权限默认拒绝、审计、迁移、回滚、 恢复和企业真实 UAT。第 12 周是三人团队最多一个条件包的决定点；第 16 周是 4～5 人团队在 P0 无红色 风险且剩余容量不少于 20% 时的条件包决定点。

8. 工程基线

8.1 API、迁移和发布副本

• OpenAPI：395 个操作；已提交与临时重新生成 SHA-256 均为 fcb9d0e23640fb75e698519622d99466da372f6fefe3152dd84e9855421e9f3a。
• Alembic 源码 head：20260802_460；迁移版本文件 52 个。
• app/ 与 deployment/app/ 的 Git tree 均为 9237562e...，递归对比一致。
• migrations/ 与 deployment/migrations/ 的 Git tree 均为 68755a0e...，递归对比一致。

8.2 第二阶段本地数据库只读快照

alembic current 因没有配置 SQLALCHEMY_DATABASE_URI 或 DATABASE_URL 而无法连接。 本次快照明确记录：

• status = NOT_AVAILABLE；
• error_category = MISSING_DATABASE_CONFIGURATION；
• alembic_current、公共表数和代表性记录计数均为 NOT_AVAILABLE；
• 未尝试写数据库，也未沿用 P2-WP00 的历史计数。

8.3 用户未跟踪文件

基线只通过 Git 枚举路径，未读取 canvas/ 或 docs/architecture 下现有未跟踪图片、 架构文件和画布状态的内容，未修改、暂存或提交这些文件。完整路径清单见 manifest。

9. 登记模板与范围变更

已固化需求、风险、外部门禁、缺陷和验收证据五类模板，并建立 1 条工程需求、3 条 基线风险、17 条外部门禁、1 条测试先行缺陷闭环和 8 条定向验证证据。外部门禁包含 due_week、decision_role、evidence_ref、waivable 与 waiver_policy；P0 企业、 安全、恢复和 UAT 门禁不可豁免。需求模板另约束模块、价值、优先级、依赖、验收标准 和被替换容量。

范围新增只有在阻塞企业试点、安全合规或生产恢复时才能进入 P0。没有真实使用方、 数据、责任人或验收方式的能力不得挤占 P0。所有条件包启动和顺延均须形成证据与批准。

10. 外部门禁与下一步

P3-WP00 的工程门禁已具备，企业剩余门禁仍包括：

1. 指定试点企业、环境、范围、用户、成功指标和日期；
2. 为所有 P0 工作包绑定产品、业务、技术、安全、运维和验收实名责任人；
3. 提供 IdP、两个来源、网络、监控/SMTP/协作/ITSM、安全法务和基础设施证据；
4. 确认第三业务域、AI 方案以及多租户、BI/AI、成本和插件条件包决定；
5. 量化团队容量并由产品负责人、技术负责人批准；
6. 为 19 项指标确认企业分母、样本、窗口、来源和实名批准人。

基础设施输入同时阻断 P3-WP01、P3-WP07 和 P3-WP14；需求清单、企业输入反向索引与 外部门禁登记均保持该三向关系。

P3-WP14 不允许顺延任何 P0 工作包；只有不影响主线的 P1 或条件范围可以书面顺延。 若 P3-WP09～13 任一包启动，P3-WP14 会按 dynamic_required_inputs_by_started_wp 自动纳入 AI、多租户、BI/AI、成本或插件输入。

这些门禁未完成前，P3-WP00 的状态保持“工程基线完成待企业输入确认”，不代表企业 UAT。后续功能必须从对应工作包进入，不能在 P3-WP00 中提前实现或宣称完成。