# 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 中提前实现或宣称完成。