diff --git a/.doc/system-design/project-workflow/03-项目多工作流与智能产品经理-测试经理工作流-设计方案.md b/.doc/system-design/project-workflow/03-项目多工作流与智能产品经理-测试经理工作流-设计方案.md
new file mode 100644
index 00000000..b97e44d6
--- /dev/null
+++ b/.doc/system-design/project-workflow/03-项目多工作流与智能产品经理-测试经理工作流-设计方案.md
@@ -0,0 +1,1000 @@
+# 项目多工作流与智能产品经理、智能测试经理工作流设计方案
+
+> 文档性质：系统设计方案
+>
+> 适用系统：Chat-Agent-System
+>
+> 编制日期：2026-09-10
+>
+> 参考实现：`.refs/weichen-agent-system`
+>
+> 本文范围：设计与实施边界，不直接修改业务代码、数据库或前端代码
+
+## 1. 文档目的
+
+本文针对以下产品需求给出可实施的系统设计：
+
+1. 一个项目可以拥有多个工作流；
+2. 项目创建人可以选择项目当前激活的工作流；
+3. 新增“智能产品经理”工作流：接收用户需求文档或项目上下文，生成系统需求规格书，使用 `.refs/weichen-agent-system/templates/docs/system_reqs.md`；
+4. 新增“智能测试经理”工作流：接收项目上下文与产品经理输出文档，生成系统测试方案，使用 `.refs/weichen-agent-system/templates/docs/test_manager.md`；
+5. 两个工作流必须复用现有 Go/SSE、Squad、上下文、文档治理和质量门禁能力，不以参考系统替换当前运行时。
+
+本文重点回答：工作流是什么、如何归属项目、如何激活、谁能切换、两个工作流如何运行、上下游文档如何追溯、失败与并发如何处理、前后端及数据库需要怎样改造。
+
+## 2. 需求澄清与设计结论
+
+### 2.1 核心概念
+
+本方案明确区分四个容易混淆的概念：
+
+- **工作流定义（Workflow Definition）**：系统级、版本化的流程模板，描述工作流名称、阶段、输入、步骤、小队、模板和质量规则。例如 `product_manager`、`test_manager`。
+- **项目工作流实例（Project Workflow）**：某个项目拥有的工作流实例。相同的工作流定义在不同项目中具有独立状态、运行记录和文档。
+- **当前激活工作流（Active Workflow）**：项目当前在界面、对话路由和默认操作中聚焦的工作流。每个项目至多一个。
+- **工作流运行（Workflow Run）**：一次具体执行，有独立输入快照、工作区、状态、输出和审计记录。同一个项目工作流可以多次运行。
+
+`active` 不是 `running` 的同义词。激活是项目的交互与路由焦点，运行是后台任务状态。切换激活工作流不应隐式取消已运行任务，也不应改变文档的编制、审核、批准状态。
+
+### 2.2 关键产品规则
+
+1. 每个项目可拥有多个工作流实例；首期至少支持现有商务研发主线、智能产品经理、智能测试经理。
+2. 每个项目在任一时刻最多有一个 `active_workflow_key`；允许暂时没有激活工作流。
+3. 只有项目创建人可以主动切换当前激活工作流。系统管理员是否代操作应作为单独的应急权限，默认不等同于项目创建人。
+4. 项目创建人必须来自认证会话，不接受客户端请求体伪造 `creator_user_id` 或 `actor_user_id`。
+5. 工作流切换必须原子化并留下审计记录；并发切换采用乐观版本或数据库行锁处理。
+6. 非创建人可以查看当前工作流、查看自己有权访问的工作流及文档，但不能切换；可在后续版本增加“请求创建人切换”的通知能力。
+7. 明确说出其他工作流名称不等于获得切换授权。系统不得在对话中静默切换工作流。
+8. 智能产品经理输出是智能测试经理的上游受控输入。测试经理每次运行必须固定引用上游文档的版本与内容哈希。
+9. 上游系统需求规格书产生新版本后，已生成的测试方案不能被静默重写，应标记 `stale`，由用户决定重新生成或进行受控变更。
+
+### 2.3 “项目创建人”的唯一口径
+
+项目创建人是创建项目时由服务端从登录令牌解析出的用户，持久化到 `projects.creator_user_id`。它不等同于：
+
+- 文档编制人 `document_records.author_id`；
+- 项目负责人或批准人；
+- 当前会话发起人；
+- 前端本地数据中的 `creatorId`；
+- 系统角色中的管理员、总监或项目经理。
+
+如果历史项目没有创建人，应通过迁移策略补齐：能可靠推断时回填最早创建/首位负责人；不能可靠推断时置空并由管理员完成一次显式认领。不得用固定用户 ID 或“当前访问用户”自动填充。
+
+## 3. 当前系统现状与差距
+
+### 3.1 当前已有能力
+
+当前仓库已经具备以下可复用基础：
+
+- `internal/squad/`：`AdaptivePlanner`、`WorkflowDriver`、`WorkspaceEngine`、`StepEvaluator`、`QualityGate` 等任务编排和工作区运行能力；
+- `internal/squad/models.go`：工作流计划、步骤、小队、材料、前序文档、黑板等运行时契约；
+- `internal/bizdev/service.go`：任务执行、法规检索、前序文档注入、文档治理、阶段串行执行；
+- `internal/coordinator/`：意图识别后的 L2 决策、用户项目上下文与对话路由；
+- `internal/ctxmgr/`：项目事实黑板、用户偏好、项目活动、对话历史和混合上下文；
+- `internal/docgov/`：受控文档的编制、审核、批准、锁定、提案和编辑租约；
+- `internal/template/`：从 `templates/docs/<task_key>.md` 加载模板并渲染变量；
+- `internal/storage/`：材料内容寻址、项目隔离和引用能力；
+- `internal/stream/` 与前端 `taskStream`：长任务 SSE 事件；
+- 前端已有项目/会话、工作流文档分类、任务运行与文档生命周期交互原型。
+
+这些能力说明两个新工作流无需重写执行引擎，应以新的定义、步骤、输入装配、质量门禁和项目控制面接入。
+
+### 3.2 当前关键缺口
+
+当前系统尚未形成真正的项目多工作流模型：
+
+1. `projects` 表没有稳定的 `creator_user_id` 和 `active_workflow_key`；
+2. 没有 `project_workflows` 或等价表保存项目拥有的工作流及其状态；
+3. `ProjectInfo.CurrentWorkflow` 主要从最近工作区 `TaskKey` 推断，无法表达由创建人选择的项目级激活状态；
+4. `SupportedTasks` 是 Go 代码中的全局硬编码列表，表达的是“可执行任务”，不是“项目拥有的工作流”；
+5. 当前 `/api/v1/projects` 更接近会话上下文查询，缺少服务端权威的项目创建、工作流清单和切换接口；
+6. 多处任务接口仍接受请求体 `UserID`、`ProjectID`，切换工作流时不能复用这种信任模型；
+7. 前端新建项目主要使用本地状态与 `localStorage`，不能作为项目创建人权限的服务端证据；
+8. 当前模板目录缺少 `system_reqs.md` 和 `test_manager.md`；
+9. 当前固定工作流没有产品经理和测试经理的专用步骤与质量规则；
+10. 当前单任务执行虽然接受 `PriorDocs`，但缺少从受控文档库按项目、工作流、版本自动选择上游文档的稳定服务；
+11. 通用 `QualityGate` 主要检查章节、禁用短语、占位符和 CDO 附件，无法验证 UR→RS、RS→TSYS 等领域约束；
+12. 文档记录以 `task_key` 为主，缺少显式的 `workflow_key/stage_key/upstream_snapshot` 追溯契约。
+
+### 3.3 对参考系统的借鉴边界
+
+参考系统中可直接借鉴的设计模式包括：
+
+- `projects.active_workflow_key` 作为单一激活工作流指针；
+- `workflows` 与 `workflow_stages` 保存项目内工作流实例和阶段状态；
+- 通过事务/行锁实现单项目工作流互斥认领；
+- `configs/workflows/*.yaml` 定义工作流、阶段、字段、别名和文档元数据；
+- `configs/squads/*.yaml` 定义按角色分工的执行步骤；
+- `product_manager`、`test_manager` 专项工作流及专用 overlay/质量规则；
+- 上游文档经 `prior_docs` 注入下游工作区；
+- 上游更新后对下游文档执行 stale 传播。
+
+但当前系统不应整体移植参考系统的运行时、插件内核、飞书接入或管理后台。应保留现有 Go/SSE、Coordinator、Context、Squad、DocGov 和现有业务成熟度治理，只采用其多工作流控制面与专项工作流的模式。
+
+## 4. 目标架构
+
+### 4.1 分层结构
+
+目标架构分为五层：
+
+1. **工作流目录层**：保存系统支持的工作流定义、版本、输入契约、阶段、步骤、模板和质量规则；
+2. **项目控制层**：保存项目创建人、项目拥有的工作流、当前激活工作流及切换审计；
+3. **路由与权限层**：依据登录用户、项目权限、激活工作流和显式目标决定是否允许查看、切换或运行；
+4. **执行层**：复用 Squad 规划、工作区、Agent Backend、SSE、质量门禁和自动修复；
+5. **文档与追溯层**：复用 DocGov，并补充工作流、阶段、输入快照、上游文档版本和 stale 关系。
+
+建议的数据与调用方向如下：
+
+```text
+登录用户
+  │
+  ├─ 创建项目 ──> projects.creator_user_id
+  │                    │
+  │                    ├─ project_workflows: bizdev
+  │                    ├─ project_workflows: product_manager
+  │                    └─ project_workflows: test_manager
+  │
+  ├─ 选择工作流 ──> ProjectWorkflowService.Activate()
+  │                    ├─ 校验创建人
+  │                    ├─ 校验工作流属于项目且可用
+  │                    ├─ 原子更新 active_workflow_key/version
+  │                    └─ 写 activation audit
+  │
+  └─ 启动当前工作流 ──> Coordinator / WorkflowRunService
+                           ├─ 装配项目上下文与材料
+                           ├─ 解析上游文档快照
+                           ├─ Squad 执行与 SSE
+                           ├─ 领域质量门禁
+                           └─ DocGov 保存版本和追溯
+```
+
+### 4.2 领域边界
+
+建议新增 `internal/projectworkflow/` 领域模块，避免把项目多工作流逻辑塞入 `squad` 或 `coordinator`：
+
+- `catalog.go`：工作流定义目录、版本与校验；
+- `types.go`：`Definition`、`ProjectWorkflow`、`Activation`、`RunInputSnapshot`；
+- `store.go`：项目工作流、激活版本、审计和运行记录持久化；
+- `service.go`：列出、初始化、激活、停用、启动前校验；
+- `policy.go`：创建人权限与项目可见性；
+- `dependency.go`：上游文档解析与 stale 传播；
+- `errors.go`：稳定的领域错误码。
+
+原有模块职责保持不变：
+
+- `coordinator` 决定对话意图和是否触发激活/运行；
+- `projectworkflow` 决定项目工作流权限、状态、依赖和路由；
+- `squad` 负责一次工作流运行内部的步骤编排；
+- `ctxmgr` 负责项目事实与用户上下文；
+- `docgov` 负责受控文档生命周期；
+- `template` 负责模板读取和变量渲染。
+
+## 5. 数据模型设计
+
+### 5.1 projects 扩展
+
+建议在权威项目表中新增：
+
+```sql
+ALTER TABLE projects
+    ADD COLUMN IF NOT EXISTS creator_user_id BIGINT REFERENCES users(id) ON DELETE RESTRICT,
+    ADD COLUMN IF NOT EXISTS active_workflow_key TEXT NOT NULL DEFAULT '',
+    ADD COLUMN IF NOT EXISTS workflow_selection_version BIGINT NOT NULL DEFAULT 0,
+    ADD COLUMN IF NOT EXISTS active_workflow_changed_at TIMESTAMPTZ,
+    ADD COLUMN IF NOT EXISTS active_workflow_changed_by BIGINT REFERENCES users(id) ON DELETE SET NULL;
+```
+
+约束说明：
+
+- `creator_user_id` 一经项目创建成功不得通过普通 API 修改；
+- `active_workflow_key=''` 表示未选择，而不是默认某个工作流；
+- `workflow_selection_version` 每次成功切换加一，用于前端乐观并发控制；
+- 删除用户时不应删除项目，因此创建人建议 `ON DELETE RESTRICT`；
+- 如系统存在两套 `projects` 初始化脚本，应统一迁移入口，避免环境结构漂移。
+
+### 5.2 project_workflows
+
+```sql
+CREATE TABLE IF NOT EXISTS project_workflows (
+    id BIGSERIAL PRIMARY KEY,
+    project_id BIGINT NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
+    workflow_key TEXT NOT NULL,
+    definition_version TEXT NOT NULL,
+    current_stage_key TEXT NOT NULL DEFAULT '',
+    status TEXT NOT NULL DEFAULT 'ready',
+    created_by BIGINT NOT NULL REFERENCES users(id) ON DELETE RESTRICT,
+    last_run_id TEXT NOT NULL DEFAULT '',
+    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
+    updated_at TIMESTAMPTZ NOT NULL DEFAULT now(),
+    UNIQUE(project_id, workflow_key),
+    CHECK (status IN ('disabled','ready','running','waiting_review','completed','failed','paused'))
+);
+```
+
+`project_workflows` 表示项目“拥有”某个工作流，不承载每次运行的全部状态。首期可在项目创建时一次性初始化三个工作流，也可延迟初始化；为用户可发现性和权限简化，建议项目创建时初始化。
+
+### 5.3 workflow_runs
+
+```sql
+CREATE TABLE IF NOT EXISTS workflow_runs (
+    id BIGSERIAL PRIMARY KEY,
+    run_id TEXT NOT NULL UNIQUE,
+    project_workflow_id BIGINT NOT NULL REFERENCES project_workflows(id) ON DELETE CASCADE,
+    project_id BIGINT NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
+    workflow_key TEXT NOT NULL,
+    stage_key TEXT NOT NULL,
+    workspace_id TEXT NOT NULL DEFAULT '',
+    triggered_by BIGINT NOT NULL REFERENCES users(id) ON DELETE RESTRICT,
+    status TEXT NOT NULL DEFAULT 'pending',
+    input_snapshot JSONB NOT NULL DEFAULT '{}'::jsonb,
+    output_doc_id TEXT NOT NULL DEFAULT '',
+    error_code TEXT NOT NULL DEFAULT '',
+    error_message TEXT NOT NULL DEFAULT '',
+    started_at TIMESTAMPTZ,
+    finished_at TIMESTAMPTZ,
+    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
+    CHECK (status IN ('pending','running','completed','failed','cancelled'))
+);
+```
+
+`input_snapshot` 至少包含：
+
+```json
+{
+  "snapshot_id": "wfin_...",
+  "project_context_version": 12,
+  "material_refs": [
+    {"reference_id": 101, "sha256": "...", "filename": "用户需求文档.docx"}
+  ],
+  "upstream_documents": [
+    {
+      "doc_id": "doc_proj1_product_manager_system_reqs",
+      "version": 3,
+      "sha256": "...",
+      "lifecycle_state": "approved"
+    }
+  ],
+  "definition_version": "1.0.0",
+  "template_sha256": "..."
+}
+```
+
+### 5.4 workflow_activation_audits
+
+```sql
+CREATE TABLE IF NOT EXISTS workflow_activation_audits (
+    id BIGSERIAL PRIMARY KEY,
+    project_id BIGINT NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
+    from_workflow_key TEXT NOT NULL DEFAULT '',
+    to_workflow_key TEXT NOT NULL,
+    actor_user_id BIGINT NOT NULL REFERENCES users(id) ON DELETE RESTRICT,
+    selection_version BIGINT NOT NULL,
+    reason TEXT NOT NULL DEFAULT '',
+    request_id TEXT NOT NULL DEFAULT '',
+    created_at TIMESTAMPTZ NOT NULL DEFAULT now()
+);
+```
+
+审计日志只追加，不提供普通删除与修改接口。
+
+### 5.5 文档追溯扩展
+
+建议为 `document_records` 或独立关联表补充：
+
+- `workflow_key`；
+- `stage_key`；
+- `source_run_id`；
+- `input_snapshot_id`；
+- `upstream_doc_refs JSONB`；
+- `stale BOOLEAN`；
+- `stale_reason`；
+- `stale_at`。
+
+如果不希望扩展文档主表，可新建 `document_lineage`：
+
+```sql
+CREATE TABLE document_lineage (
+    downstream_doc_id TEXT NOT NULL,
+    upstream_doc_id TEXT NOT NULL,
+    upstream_version INT NOT NULL,
+    upstream_sha256 TEXT NOT NULL,
+    relation TEXT NOT NULL,
+    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
+    PRIMARY KEY (downstream_doc_id, upstream_doc_id, upstream_version)
+);
+```
+
+测试经理输出与产品经理输出的关系为 `verification_derived_from_system_requirements`。
+
+## 6. 工作流定义模型
+
+### 6.1 配置化与代码边界
+
+当前 `SupportedTasks`、`DefaultWorkflowSteps`、`DefaultSquadAgents` 采用代码硬编码。为支持一个项目多个工作流，建议引入配置化定义，但执行仍映射为现有 Go 类型：
+
+```yaml
+key: product_manager
+name: 智能产品经理
+version: 1.0.0
+kind: special
+stages:
+  - key: system_reqs
+    title: 系统需求规格书
+    task_key: system_reqs
+    template: system_reqs.md
+    input_contract: product_manager_input_v1
+    quality_profile: system_reqs_v1
+```
+
+启动时加载并校验配置，转换为：
+
+- `TaskMeta`；
+- `WorkflowPlan`；
+- `StepSpec[]`；
+- `AgentSpec[]`；
+- 输入契约；
+- 质量规则；
+- 模板元数据。
+
+为降低首期风险，也可先用 Go 注册表实现同样接口，后续再迁移 YAML。无论存储形式如何，工作流定义必须有稳定版本和启动校验，不能仅凭前端 `taskKey` 自由拼接。
+
+### 6.2 定义校验
+
+服务启动时至少检查：
+
+1. `workflow_key`、`stage_key`、`task_key` 全局或作用域内唯一；
+2. 模板文件存在且非空；
+3. 所有步骤的角色已注册；
+4. `needs` 依赖指向有效步骤且无环；
+5. 必填字段和输入来源可解析；
+6. 质量配置存在；
+7. 输出文档键不会与现有任务冲突；
+8. 工作流定义版本符合格式；
+9. 模板中的变量都有渲染来源或允许回落到“待确认”。
+
+校验失败应使对应工作流不可用并在健康检查中暴露，不能运行到一半才发现模板缺失。
+
+## 7. 激活工作流设计
+
+### 7.1 激活语义
+
+当前激活工作流影响：
+
+- 项目顶部工作流选择器；
+- 当前工作流详情和文档列表默认筛选；
+- 对话中未显式指定工作流时的路由上下文；
+- “启动当前工作流”“查看当前进度”等省略表达；
+- 工作流相关快捷操作的默认目标。
+
+当前激活工作流不影响：
+
+- 已经开始的 `workflow_run` 是否继续；
+- 已有文档的审核、批准和锁定状态；
+- 项目事实黑板本身；
+- 其他工作流文档的可见性；
+- 工作流实例是否存在或是否完成。
+
+### 7.2 原子切换算法
+
+推荐采用带版本的原子更新：
+
+```text
+Activate(projectID, targetWorkflowKey, actor, expectedVersion):
+  1. 从认证上下文取得 actor.id
+  2. BEGIN
+  3. SELECT creator_user_id, active_workflow_key, workflow_selection_version
+       FROM projects WHERE id=? FOR UPDATE
+  4. 校验 actor.id == creator_user_id
+  5. 查询 project_workflows，确认 target 属于项目且 status != disabled
+  6. 校验 expectedVersion（若请求提供）
+  7. 若 target 已激活，幂等返回当前状态，不重复写审计
+  8. UPDATE projects SET active_workflow_key=?, version=version+1, ...
+  9. INSERT workflow_activation_audits(...)
+ 10. COMMIT
+ 11. 失效 ProjectContext/SessionState 缓存并广播 workflow.changed 事件
+```
+
+并发切换时，后到请求如携带旧 `expected_version`，返回 `409 workflow_selection_conflict` 和最新状态。前端刷新后让用户重新确认。
+
+### 7.3 权限规则
+
+权限矩阵用文字表达如下：
+
+- 项目创建人：查看工作流清单、激活任意启用的项目工作流、运行其有执行权限的工作流；
+- 项目成员：查看有权访问的工作流和文档，不能激活；是否能运行由现有项目/文档角色决定；
+- 非项目成员：不返回工作流存在性，统一按项目不可访问处理；
+- 系统管理员：默认可诊断和查看元数据；若提供代切换能力，必须走专门的 `admin_override`、填写原因并审计，不复用普通激活接口。
+
+### 7.4 对话路由
+
+对话中遇到工作流相关表达时，Coordinator 应采用以下顺序：
+
+1. 用户显式指定工作流：解析目标工作流；
+2. 用户只说“当前工作流”：读取服务端 `active_workflow_key`；
+3. 未激活且意图需要目标：返回工作流选择卡；
+4. 目标不是当前激活工作流：
+   - 创建人：返回“切换并继续”的确认卡；
+   - 非创建人：说明只有创建人可切换，不静默改写目标；
+5. 确认后先调用激活服务，再执行后续动作；
+6. 直接指定 `workflow_key` 的运行 API仍应校验项目归属与权限；是否强制必须为当前激活工作流由动作类型决定。
+
+建议首期：普通“启动/继续/补充”操作只能作用于当前激活工作流；只读查询可以显式指定其他工作流。
+
+## 8. 智能产品经理工作流
+
+### 8.1 标识与输出
+
+- `workflow_key`: `product_manager`
+- `stage_key`: `system_reqs`
+- `task_key`: `system_reqs`
+- 展示名：智能产品经理
+- 产物：系统需求规格书
+- 模板来源：`.refs/weichen-agent-system/templates/docs/system_reqs.md`
+- 目标落地模板：`templates/docs/system_reqs.md`
+- 规划模式：`fixed_adaptive`
+
+参考模板标题为“系统需求规格书（SR）”，文件编号为 `RD-SR`。参考工作流配置中的阶段键是 `user_needs_spec`，但其产物实质是系统需求规格书。为避免“用户需求”和“系统需求”概念混淆，本系统建议使用更准确的 `stage_key=system_reqs`；如需与参考系统数据兼容，可把 `user_needs_spec` 作为只读别名或迁移别名，不作为新数据主键。
+
+### 8.2 输入契约
+
+该工作流接收“用户需求文档或项目上下文”，两种路径均可启动：
+
+**路径 A：用户需求文档驱动**
+
+- 至少一个项目内可访问的用户需求文档或材料引用；
+- 支持 Markdown、文本、JSON、YAML、DOCX，以及现有抽取器支持的其他格式；
+- 每份材料固定 `reference_id/sha256/filename`；
+- 文档中的需求原句按 `UR-nnn` 归一化，不改变其语义；
+- 冲突需求并列呈现，标记来源与待决策项。
+
+**路径 B：项目上下文驱动**
+
+- 项目事实黑板不为空，或存在足以形成产品边界的项目上下文；
+- 最低建议事实：产品类型、预期用途、目标市场；
+- 主要用户角色、使用场景、性能、安全、接口、环境约束缺失时允许生成，但必须进入待确认清单；
+- 上下文版本固定写入运行输入快照。
+
+输入优先级建议：
+
+1. 用户显式选中的用户需求文档；
+2. 已批准的项目用户需求类文档；
+3. 项目原始材料；
+4. 项目事实黑板和里程碑决策；
+5. 明确标记为 inferred 的基准假设。
+
+高优先级来源与低优先级来源冲突时，不自动覆盖，应列入冲突/待确认项。
+
+### 8.3 执行步骤
+
+建议基线步骤：
+
+1. `organizer`：抽取产品信息、用户角色、使用场景、原始需求与冲突，建立 UR 池；
+2. `engineer`：将 UR 拆为原子、可验证的系统需求 SR/RS，给出验证方式；
+3. `regulatory`（条件步骤）：高复杂度、已知标准或医疗器械法规相关输入时，补充法规约束与排除说明；
+4. `writer`：严格按 `system_reqs.md` 生成完整文档；
+5. `leader`：检查需求原子性、可验证性、追溯、编号和待确认项；
+6. 质量失败时由现有自动修复机制追加定向修复步骤。
+
+建议高复杂度任务在写作前增加 `plan` 与 `review_plan`，明确预计 UR/RS 数量、章节和追溯覆盖，再进入正文生成。
+
+### 8.4 输出与质量约束
+
+除通用质量门禁外，新增 `SystemRequirementsQualityProfile`：
+
+- 模板规定章节全部存在；
+- 不存在未渲染 `{{...}}`；
+- 系统需求主表至少一条有效需求；
+- 每个系统需求 ID 唯一且连续；
+- 每条需求是单一、可验证、无歧义的陈述；
+- 每条系统需求至少关联一个上游 UR、材料引用或项目上下文事实；
+- 每条系统需求有验证方式，无法确定时明确“待确认”而非留空；
+- 不允许把多个标准条款或多个独立能力合并成一行；
+- 不允许未经材料支持的疗效或合规宣称；
+- 待确认清单覆盖所有阻塞缺口；
+- 生成文档、输入快照和模板哈希写入 manifest。
+
+模板现有列为“ID、需求陈述、追溯 UN、验证方式”。参考 overlay 中使用 UR。落地时应统一为 `UR`，或明确 `UN` 表示 User Need 并提供映射；建议模板列名调整为“追溯用户需求（UR/UN）”，防止质量规则与模板冲突。
+
+## 9. 智能测试经理工作流
+
+### 9.1 标识与输出
+
+- `workflow_key`: `test_manager`
+- `stage_key`: `system_test_plan`
+- `task_key`: `test_manager`
+- 展示名：智能测试经理
+- 产物：系统验证方案及计划（产品界面可显示“系统测试方案”）
+- 模板来源：`.refs/weichen-agent-system/templates/docs/test_manager.md`
+- 目标落地模板：`templates/docs/test_manager.md`
+- 规划模式：`fixed_adaptive`
+
+模板正文使用“设计验证”“系统验证方案及计划”。如果产品术语要求严格使用“系统测试方案”，应在实施前统一名称；首期建议保留模板正式标题，在 UI 上增加别名“系统测试方案”，避免改动受控模板语义。
+
+### 9.2 输入契约
+
+智能测试经理必须同时具备：
+
+1. 项目上下文快照；
+2. 智能产品经理输出的系统需求规格书固定版本。
+
+默认正式运行规则：
+
+- 上游文档必须属于同一项目；
+- `workflow_key=product_manager`、`stage_key=system_reqs`；
+- 文档不是空模板，正文哈希非空；
+- 优先且默认要求文档处于 `approved`；
+- 如业务确需提前策划，可显式选择“基于草稿生成内部预案”，但输出必须标记 `draft_basis`，不可进入正式批准；
+- 每次运行把上游 `doc_id/version/sha256/lifecycle_state` 写入输入快照；
+- 运行过程中上游文档变化不影响本次快照，但完成时应检测是否已漂移并提示。
+
+不满足上游条件时返回结构化前置条件错误，并提供行动建议：运行产品经理、等待批准、选择合格版本或补充项目上下文。
+
+### 9.3 法规知识库策略
+
+参考工作流要求法规库。当前系统已有 KB 检索，但首期应明确两种模式：
+
+- **严格模式（推荐默认）**：法规库不可用时阻止正式测试方案生成，返回 `knowledge_base_unavailable`；
+- **降级草案模式**：仅生成需求驱动的内部测试策划草案，法规覆盖附录标记不完整，文档不能提交批准。
+
+不得在法规库不可用时生成看似完整的法规覆盖结论。
+
+### 9.4 执行步骤
+
+建议基线步骤：
+
+1. `organizer`：解析项目上下文、产品描述、参考文档及上游系统需求 ID 清单；
+2. `regulatory`：宽召回标准和指导原则，逐项判定适用、条件适用、不适用或不明确，并记录依据；
+3. `engineer`：为每个适用系统需求生成一条或多条可执行测试用例、方法、资源和接受准则；
+4. `writer`：按 `test_manager.md` 输出完整系统验证方案及计划；
+5. `leader`：检查上游覆盖、RS/TSYS 映射、验证方法可操作性、资源完整性和排除日志；
+6. 质量失败时追加定向修复步骤。
+
+高复杂度任务应增加写作计划和计划审查步骤，先声明 4.2 主表目标行数和上游需求覆盖，再生成正文。
+
+### 9.5 输出与质量约束
+
+新增 `SystemTestPlanQualityProfile`：
+
+- 模板章节完整，无占位符泄漏；
+- 上游系统需求 ID 全部被覆盖：进入测试主表或排除日志，禁止静默遗漏；
+- 每个测试项目 ID 唯一且连续；
+- 每个测试用例 ID 唯一且连续；
+- 主表中的 RS/TSYS 映射满足定义规则；如果一个需求需要多个用例，应采用一对多并在质量配置中明确，不能错误强制一一对应；
+- 验证方法至少包含对象/设备、步骤和接受判据，不能只写标准号；
+- 人员、设施环境、样机配置、设备工具均非空或明确待确认；
+- 法规候选均进入适用清单或排除日志；
+- 指导原则不被描述为强制标准；
+- 4.1 声明的测试用例总数与 4.2 实际行数一致；
+- 正文引用的法规/标准在参考文献中存在；
+- 输出文档保留上游文档版本、内容哈希和运行快照。
+
+参考配置要求“唯一 RS 数 = 唯一 TSYS 数”。实际工程中一个系统需求可能需要多个测试用例。建议首期根据模板维持一行一用例，但数据模型允许 `requirement_id -> test_case_ids[]`，质量门禁使用“每个上游需求至少一个处置记录”作为不丢失底线，而不是永久锁死一一对应。
+
+## 10. 两个工作流的依赖与 stale 传播
+
+### 10.1 依赖关系
+
+```text
+用户需求文档 ─┐
+               ├─> 智能产品经理 ─> 系统需求规格书 vN（受控文档）
+项目上下文 ────┘                         │
+                                          ├─ 固定 doc/version/hash
+项目上下文 ───────────────────────────────┘
+                                          │
+                                          v
+                               智能测试经理
+                                          │
+                                          v
+                              系统验证方案及计划 vM
+```
+
+### 10.2 stale 规则
+
+发生以下任一情况时，将相关测试方案标记为 stale：
+
+- 上游系统需求规格书创建了内容不同的新版本；
+- 上游文档从批准状态撤回或作废；
+- 上游文档被替换为另一个 `doc_id`；
+- 关键项目事实发生变化，且事实键属于测试方案输入敏感集合，例如预期用途、目标市场、器械类别、软件/无菌/植入属性；
+- 工作流定义或模板发生破坏性版本升级。
+
+stale 只表示需要影响评估，不自动删除、解锁或覆盖文档。UI 应展示原因、上游旧版本和新版本，并提供：
+
+- 重新运行生成新版本；
+- 创建受控变更提案；
+- 经有权限人员确认“评估后无影响”。
+
+## 11. API 设计
+
+### 11.1 项目创建
+
+```http
+POST /api/v1/projects
+Authorization: Bearer <token>
+Content-Type: application/json
+
+{
+  "name": "项目名称",
+  "device_type": "产品类型",
+  "intended_use": "预期用途",
+  "target_market": "目标市场"
+}
+```
+
+服务端从令牌设置 `creator_user_id`，同一事务初始化项目工作流。响应返回项目及工作流摘要。客户端不得提交创建人 ID。
+
+### 11.2 查询项目工作流
+
+```http
+GET /api/v1/projects/{project_id}/workflows
+Authorization: Bearer <token>
+```
+
+响应示例：
+
+```json
+{
+  "project_id": 101,
+  "creator_user_id": 7,
+  "can_activate": true,
+  "active_workflow_key": "product_manager",
+  "selection_version": 3,
+  "workflows": [
+    {
+      "workflow_key": "product_manager",
+      "name": "智能产品经理",
+      "status": "completed",
+      "current_stage_key": "system_reqs",
+      "last_run_id": "wfr_...",
+      "output_doc_id": "doc_proj101_product_manager_system_reqs"
+    },
+    {
+      "workflow_key": "test_manager",
+      "name": "智能测试经理",
+      "status": "ready",
+      "prerequisites": {"satisfied": true}
+    }
+  ]
+}
+```
+
+### 11.3 激活工作流
+
+```http
+PUT /api/v1/projects/{project_id}/active-workflow
+Authorization: Bearer <token>
+Content-Type: application/json
+
+{
+  "workflow_key": "test_manager",
+  "expected_version": 3,
+  "reason": "开始编制系统测试方案"
+}
+```
+
+成功返回更新后的工作流摘要。错误语义：
+
+- `401 unauthenticated`：未登录；
+- `403 only_project_creator_can_activate`：不是项目创建人；
+- `404 project_not_found`：项目不存在或调用者不可见；
+- `404 workflow_not_in_project`：目标工作流不存在；
+- `409 workflow_selection_conflict`：选择版本已变化；
+- `409 workflow_disabled`：目标工作流禁用；
+- `422 invalid_workflow_key`：键格式非法。
+
+### 11.4 启动运行
+
+```http
+POST /api/v1/projects/{project_id}/workflows/{workflow_key}/runs
+Authorization: Bearer <token>
+Content-Type: application/json
+
+{
+  "stage_key": "system_test_plan",
+  "material_reference_ids": [301, 302],
+  "upstream_document": {
+    "doc_id": "doc_proj101_product_manager_system_reqs",
+    "version": 2
+  },
+  "mode": "formal",
+  "auto_repair": true
+}
+```
+
+服务端自行解析用户、项目、文档权限和内容哈希，不能相信客户端提交的文档正文、项目归属或生命周期状态。
+
+SSE 可使用：
+
+```http
+POST /api/v1/projects/{project_id}/workflows/{workflow_key}/runs/stream
+```
+
+或兼容现有 `/api/v1/tasks/run/stream`，但请求必须增加服务端工作流校验层。
+
+### 11.5 幂等性
+
+项目创建、激活和运行接口建议接受 `Idempotency-Key`：
+
+- 激活相同工作流且版本相同返回当前成功状态；
+- 同一运行幂等键不重复创建工作区和文档版本；
+- 失败重试返回已有 `run_id` 或明确可重试状态。
+
+## 12. 前端交互设计
+
+### 12.1 项目级工作流选择器
+
+在项目顶部而非文档侧栏增加工作流选择器，展示：
+
+- 当前激活工作流；
+- 每个工作流的状态、最后运行时间、输出文档状态；
+- 前置条件是否满足；
+- 当前用户是否可切换；
+- 创建人名称；
+- stale 或失败提示。
+
+项目创建人选择其他工作流时弹出确认：
+
+> 将项目当前工作流从“智能产品经理”切换为“智能测试经理”。切换只改变项目当前操作焦点，不会取消正在运行的任务，也不会修改已有文档状态。
+
+非创建人看到只读选择器，切换控件禁用并显示“仅项目创建人可切换”。
+
+### 12.2 工作流详情
+
+智能产品经理详情页展示：
+
+- 输入来源选择：用户需求文档 / 项目上下文；
+- 输入材料和上下文版本；
+- 缺失的关键字段；
+- 最新系统需求规格书版本与生命周期；
+- 运行、继续、重新生成、查看文档等动作。
+
+智能测试经理详情页展示：
+
+- 当前项目上下文版本；
+- 可选的产品经理输出版本，默认最新已批准版本；
+- 法规库健康状态；
+- 上游是否 stale；
+- 正式运行或降级草案模式；
+- 最新测试方案版本与覆盖摘要。
+
+### 12.3 本地状态迁移
+
+当前前端的项目/会话和模板克隆大量依赖 `localStorage`。多工作流权限上线后：
+
+- 项目、创建人、工作流清单和激活状态必须来自服务端；
+- `localStorage` 仅保留 UI 偏好、最近选择、缓存，不作为权限依据；
+- 前端 `ProjectSession` 应引用服务端 `ProjectSummary`，避免一个项目多个会话时复制出不同激活状态；
+- 同项目在多个浏览器标签切换时，通过重新拉取、SSE 或 BroadcastChannel 更新界面；最终权威仍为服务端。
+
+## 13. Coordinator、上下文与执行集成
+
+### 13.1 ProjectInfo 扩展
+
+建议将 `ProjectInfo.CurrentWorkflow` 从“工作区推断字段”改为服务端项目工作流状态，并新增：
+
+```go
+type ProjectInfo struct {
+    // existing fields...
+    CreatorUserID           int64  `json:"creator_user_id"`
+    ActiveWorkflowKey       string `json:"active_workflow_key"`
+    WorkflowSelectionVersion int64 `json:"workflow_selection_version"`
+}
+```
+
+为兼容旧调用，可在迁移期保留 `CurrentWorkflow`，但其值必须等于 `ActiveWorkflowKey`，不再由最近工作区覆盖。运行中的 `TaskKey` 应进入独立的 `ActiveRun` 或 `LastRun` 字段。
+
+### 13.2 AvailableActions
+
+当前 `ComputeAvailableActions` 主要按成熟度阶段计算。改造后动作集合由三部分合成：
+
+- 项目通用动作：查询、补充、查看；
+- 当前激活工作流定义的动作；
+- 当前用户对项目和文档的权限。
+
+例如：
+
+```text
+VIEW_WORKFLOW:product_manager
+ACTIVATE_WORKFLOW:test_manager
+RUN_WORKFLOW:product_manager/system_reqs
+RUN_WORKFLOW:test_manager/system_test_plan
+```
+
+非创建人不应获得 `ACTIVATE_WORKFLOW:*`。
+
+### 13.3 输入装配
+
+启动运行时新增 `WorkflowInputAssembler`：
+
+1. 读取项目权威记录与项目黑板；
+2. 读取调用者可访问的材料引用；
+3. 根据工作流输入契约解析上游文档；
+4. 固定版本、哈希、模板和定义版本；
+5. 转换为现有 `squad.MaterialItem`、`PriorDocItem`、`Fields`、`UserContext`；
+6. 生成不可变 `RunInputSnapshot`；
+7. 再调用 `bizdev.Service.ExecuteTask` / `squad.Service.ExecuteTask`。
+
+这样可以继续复用工作区中的 `context/materials_text`、`context/prior_docs`、`blackboard.json`、`workflow.json` 和 `manifest.json`。
+
+## 14. 安全、并发与故障边界
+
+### 14.1 身份与越权
+
+- 所有项目工作流写接口必须认证；
+- 用户 ID只从 Bearer token 解析；
+- 路径中的 `project_id` 必须经过成员关系/创建人校验；
+- 不允许请求体中的 `user_id` 覆盖认证身份；
+- 查询无权项目时避免泄露项目、工作流和文档是否存在；
+- 上游文档必须再次校验同项目归属与可见性。
+
+### 14.2 并发
+
+需要分别处理：
+
+- 两个浏览器同时切换工作流：项目行锁 + `expected_version`；
+- 同一工作流重复启动：运行幂等键 + 活动运行唯一约束或服务层互斥；
+- 两个工作流同时运行：激活状态不负责运行互斥，由资源配额和文档租约控制；
+- 同一输出文档并发写：复用 DocGov 编辑租约；
+- 上游文档在测试经理运行中更新：运行继续使用已固定快照，完成后做漂移检测。
+
+### 14.3 失败恢复
+
+- 激活切换失败：事务回滚，原激活工作流保持不变；
+- 工作流运行失败：项目激活状态不变，运行标记 failed，可从工作区恢复；
+- 文档保存失败：运行不能标记 completed；
+- 质量门禁失败且修复耗尽：保留工作区和质量报告，不进入正式文档批准；
+- KB 不可用：正式测试经理模式失败，降级模式需用户显式选择；
+- 上游文档缺失：返回可行动的 prerequisite 错误，不自动选择其他项目或旧缓存文档。
+
+## 15. 可观测性与审计
+
+建议增加指标：
+
+- `workflow_activation_total{workflow_key,result}`；
+- `workflow_activation_conflict_total`；
+- `workflow_run_total{workflow_key,status}`；
+- `workflow_run_duration_seconds{workflow_key}`；
+- `workflow_prerequisite_failure_total{reason}`；
+- `workflow_quality_failure_total{profile,rule}`；
+- `document_stale_total{reason}`；
+- `workflow_input_drift_total`。
+
+结构化日志至少包含：`request_id`、`project_id`、`workflow_key`、`stage_key`、`run_id`、`actor_user_id`、`input_snapshot_id`、`output_doc_id`，不得记录令牌、密码或完整敏感正文。
+
+## 16. 兼容与迁移策略
+
+### 16.1 历史项目
+
+1. 增加可空 `creator_user_id` 并部署兼容代码；
+2. 按可靠来源回填创建人；
+3. 无法推断的项目进入“待认领”清单；
+4. 初始化 `project_workflows`；
+5. 根据历史活动或产品策略设置默认激活工作流；无法可靠判断时保持空；
+6. 确认全部项目补齐后再增加非空约束。
+
+### 16.2 历史任务和文档
+
+- 现有 `task_key` 映射至主线工作流或对应专项工作流；
+- 无法确定的历史文档保留 `workflow_key=legacy`，不自动归错；
+- 文档版本、哈希或输入快照缺失时标记 `lineage_incomplete`；
+- 老接口在过渡期通过兼容层调用新服务，不直接写 `active_workflow_key`。
+
+### 16.3 回滚
+
+- 数据库新增列和表采用向前兼容方式，回滚应用时保留数据；
+- 功能开关 `PROJECT_MULTI_WORKFLOW_ENABLED` 控制新路由和 UI；
+- 两个专项工作流分别有开关，便于分阶段启用；
+- 关闭功能后回退到现有任务入口，但不得清空工作流状态与审计。
+
+## 17. 验收标准
+
+### 17.1 多工作流
+
+- 新建项目自动拥有至少 `product_manager` 与 `test_manager` 工作流；
+- 同一项目能查询多个工作流，不同项目状态隔离；
+- 项目创建人可切换，非创建人返回 403；
+- 每个项目最多一个激活工作流；
+- 并发切换不会出现两个激活状态或丢失更新；
+- 切换不会取消运行任务或改变文档生命周期；
+- 所有切换可审计。
+
+### 17.2 智能产品经理
+
+- 能以用户需求文档为主输入生成文档；
+- 没有需求文档时能以项目上下文生成，并明确待确认项；
+- 输出使用 `system_reqs.md`；
+- 输入、模板、定义版本和输出均可追溯；
+- UR/系统需求覆盖和验证方式通过领域门禁；
+- 输出进入 DocGov 生命周期。
+
+### 17.3 智能测试经理
+
+- 没有产品经理输出时不能正式运行；
+- 能固定选择同项目产品经理文档版本；
+- 输出使用 `test_manager.md`；
+- 上游需求全部进入测试主表或排除日志；
+- 验证方法可执行且资源要求完整；
+- 上游更新后下游文档正确标记 stale；
+- KB 失败时严格模式不伪造完整法规覆盖。
+
+## 18. 主要风险与控制
+
+### 18.1 把任务当成工作流
+
+风险：只向 `SupportedTasks` 增加两个键，会导致项目归属、激活、权限、版本和审计仍然缺失。
+
+控制：建立独立的项目工作流控制面，Squad 只负责一次运行内部编排。
+
+### 18.2 前端本地状态成为权限事实
+
+风险：用户可修改 `localStorage` 冒充创建人或切换工作流。
+
+控制：项目创建人与激活状态均由服务端和认证会话决定。
+
+### 18.3 测试方案追溯漂移
+
+风险：始终读取“最新需求文档”，导致历史测试方案无法复现。
+
+控制：固定 `doc_id/version/sha256`，上游变化只触发 stale。
+
+### 18.4 通用质量门禁误判合格
+
+风险：章节齐全但需求不可验证、测试用例遗漏。
+
+控制：为两个工作流增加结构化领域门禁与覆盖统计。
+
+### 18.5 工作流激活与运行互斥混淆
+
+风险：切换工作流意外取消任务，或运行完成后清空用户选择。
+
+控制：激活、运行、文档状态三套状态机分离，通过明确事件协调。
+
+## 19. 推荐决策摘要
+
+1. 采用“系统级定义 + 项目级实例 + 运行实例”三层模型；
+2. 在项目表持久化创建人和单一激活工作流；
+3. 由新 `projectworkflow` 领域服务处理权限、原子切换、依赖和审计；
+4. 保留现有 Squad 执行引擎，新增两个固定自适应工作流；
+5. 产品经理支持“用户需求文档或项目上下文”二选一输入；
+6. 测试经理要求“项目上下文 + 固定版本的产品经理输出”，正式模式默认要求上游已批准；
+7. 引入文档血缘与 stale 传播；
+8. 项目与工作流权威状态迁移到服务端，前端本地状态只做缓存；
+9. 先完成控制面与权限，再接产品经理，最后接测试经理，避免一次性改造过大。
+
+## 20. 源码与参考材料索引
+
+当前系统重点来源：
+
+- `deploy/postgres/context_init.sql`
+- `deploy/postgres/system_init.sql`
+- `internal/coordinator/context.go`
+- `internal/coordinator/engine.go`
+- `internal/ctxmgr/manager.go`
+- `internal/squad/models.go`
+- `internal/squad/planner.go`
+- `internal/squad/service.go`
+- `internal/squad/workspace.go`
+- `internal/squad/context.go`
+- `internal/squad/quality_gate.go`
+- `internal/bizdev/service.go`
+- `internal/docgov/types.go`
+- `internal/docgov/engine.go`
+- `internal/template/loader.go`
+- `internal/server/handlers.go`
+- `internal/server/server.go`
+- `web/src/App.tsx`
+- `web/src/types/workbench.ts`
+- `web/src/api/taskStream.ts`
+
+参考系统重点来源：
+
+- `.refs/weichen-agent-system/deploy/postgres/system_init.sql`
+- `.refs/weichen-agent-system/internal/store/workflow_active.go`
+- `.refs/weichen-agent-system/internal/workflow/def.go`
+- `.refs/weichen-agent-system/configs/workflows/product_manager.yaml`
+- `.refs/weichen-agent-system/configs/workflows/test_manager.yaml`
+- `.refs/weichen-agent-system/configs/squads/product_manager.yaml`
+- `.refs/weichen-agent-system/configs/squads/test_manager.yaml`
+- `.refs/weichen-agent-system/configs/overlays/product_manager.md`
+- `.refs/weichen-agent-system/configs/overlays/test_manager.md`
+- `.refs/weichen-agent-system/templates/docs/system_reqs.md`
+- `.refs/weichen-agent-system/templates/docs/test_manager.md`
diff --git a/.doc/system-design/project-workflow/04-项目多工作流与智能产品经理-测试经理工作流-实施计划.md b/.doc/system-design/project-workflow/04-项目多工作流与智能产品经理-测试经理工作流-实施计划.md
new file mode 100644
index 00000000..21838541
--- /dev/null
+++ b/.doc/system-design/project-workflow/04-项目多工作流与智能产品经理-测试经理工作流-实施计划.md
@@ -0,0 +1,798 @@
+# 项目多工作流与智能产品经理、智能测试经理工作流实施计划
+
+> 文档性质：分阶段实施计划
+>
+> 依赖方案：`03-项目多工作流与智能产品经理-测试经理工作流-设计方案.md`
+>
+> 编制日期：2026-09-10
+>
+> 本文范围：计划、任务拆分、测试与上线策略，不直接实施代码改造
+
+## 1. 实施目标
+
+在不替换现有 Go/SSE、Coordinator、Context、Squad、DocGov 运行时的前提下，实现：
+
+1. 服务端权威的项目创建人与项目工作流模型；
+2. 一个项目拥有多个工作流、至多一个当前激活工作流；
+3. 仅项目创建人可以原子切换当前激活工作流；
+4. 智能产品经理工作流生成系统需求规格书；
+5. 智能测试经理工作流基于项目上下文和产品经理输出生成系统验证方案及计划；
+6. 上下游文档版本化追溯和 stale 传播；
+7. 完整的权限、并发、失败恢复、质量门禁、前端交互和审计测试。
+
+## 2. 实施原则
+
+- **先控制面，后执行面**：先建立项目—工作流—激活权限，再增加两个工作流；
+- **先产品经理，后测试经理**：测试经理依赖产品经理输出，不能并行盲目接入；
+- **保持领域边界**：项目工作流控制进入新领域模块，不污染 Squad 内部步骤状态；
+- **服务端权威**：创建人、工作流归属、激活状态和上游版本均不信任前端；
+- **兼容迁移**：老任务入口可过渡，但所有新增写操作经过新服务；
+- **可回滚**：数据库变更向前兼容，功能通过开关逐级启用；
+- **测试先行**：每阶段先补契约/失败用例，再实现；
+- **不触碰历史用户改动**：实施时先记录干净基线，逐模块提交，避免混入当前工作区未提交内容。
+
+## 3. 阶段总览
+
+建议分为八个阶段：
+
+1. Phase 0：基线确认与契约冻结；
+2. Phase 1：数据库和项目身份权威化；
+3. Phase 2：项目多工作流控制面；
+4. Phase 3：Coordinator、上下文与 API 集成；
+5. Phase 4：智能产品经理工作流；
+6. Phase 5：智能测试经理工作流与文档血缘；
+7. Phase 6：前端项目工作流体验；
+8. Phase 7：端到端验证、迁移、灰度和上线。
+
+建议不要把八个阶段压成一个大提交。至少拆为数据库/领域服务、产品经理、测试经理、前端四组可独立审阅的变更。
+
+## 4. Phase 0：基线确认与契约冻结
+
+### 4.1 目标
+
+消除当前项目模型、认证模型、文档模型和命名上的歧义，形成后续改造的稳定契约。
+
+### 4.2 任务
+
+1. 确认生产环境权威项目表来自哪个迁移链，统一 `deploy/postgres/system_init.sql` 与 `context_init.sql` 的结构演进方式；
+2. 确认前端“新建项目”是否正式迁移为服务端创建；本方案要求答案为是；
+3. 冻结工作流键：
+   - `product_manager`；
+   - `test_manager`；
+4. 冻结阶段/任务键：
+   - 产品经理：`stage_key=system_reqs`、`task_key=system_reqs`；
+   - 测试经理：`stage_key=system_test_plan`、`task_key=test_manager`；
+5. 明确正式文档名称：
+   - 《系统需求规格书》；
+   - 《系统验证方案及计划》，UI 别名《系统测试方案》；
+6. 明确测试经理正式模式默认要求产品经理文档处于 `approved`；
+7. 明确项目创建人不可通过普通项目编辑 API变更；
+8. 明确激活工作流只改变路由焦点，不取消任务；
+9. 盘点当前未提交改动，建立本功能的独立分支或独立提交边界；
+10. 建立 API 错误码清单与 JSON 契约快照。
+
+### 4.3 输出
+
+- 架构决策记录（ADR）；
+- API 契约草案；
+- 数据迁移说明；
+- 工作流键与文档名称表；
+- 测试矩阵初稿。
+
+### 4.4 完成条件
+
+- 所有关键命名不再冲突；
+- 创建人、激活、运行、文档状态四者语义得到确认；
+- 生产数据库迁移入口明确；
+- 旧接口兼容期限明确。
+
+## 5. Phase 1：数据库和项目身份权威化
+
+### 5.1 数据库迁移
+
+新增迁移文件，完成：
+
+- `projects.creator_user_id`；
+- `projects.active_workflow_key`；
+- `projects.workflow_selection_version`；
+- `projects.active_workflow_changed_at/by`；
+- `project_workflows`；
+- `workflow_runs`；
+- `workflow_activation_audits`；
+- `document_lineage` 或文档表的等价血缘字段；
+- 必要索引、唯一约束和状态 CHECK；
+- 历史项目回填脚本和不可推断项目报告。
+
+迁移必须先允许 `creator_user_id` 为空，在完成历史数据回填后再决定是否增加非空约束。
+
+### 5.2 项目 Store 与 Service
+
+新增或完善：
+
+- `CreateProject(ctx, authenticatedUser, input)`；
+- `GetProjectForUser(ctx, projectID, userID)`；
+- `ListProjectsForUser(ctx, userID)`；
+- `IsProjectCreator(ctx, projectID, userID)`；
+- 项目成员可见性检查；
+- 项目创建事务内初始化工作流实例。
+
+### 5.3 项目 API
+
+实现：
+
+- `POST /api/v1/projects`；
+- `GET /api/v1/projects`；
+- `GET /api/v1/projects/{id}`。
+
+认证要求：
+
+- 从 Bearer token 获取用户；
+- 忽略或拒绝请求体中的创建人 ID；
+- 无权项目不泄露元数据；
+- 日志记录请求 ID与用户 ID，但不记录令牌。
+
+### 5.4 测试
+
+- 创建项目自动记录登录用户为创建人；
+- 客户端伪造创建人无效；
+- 未登录不能创建；
+- 无权用户不能查询项目；
+- 项目创建和工作流初始化事务一致；
+- 初始化中途失败时项目与工作流均回滚；
+- 历史项目回填可重复运行且幂等；
+- PostgreSQL 集成测试验证外键与并发。
+
+### 5.5 完成条件
+
+- 服务端可权威回答“谁创建了项目”；
+- 新项目不再只存在于前端 `localStorage`；
+- 所有新增项目自动得到项目工作流实例。
+
+## 6. Phase 2：项目多工作流控制面
+
+### 6.1 工作流目录
+
+实现统一 `Catalog` 接口：
+
+```go
+type Catalog interface {
+    Get(workflowKey string) (Definition, bool)
+    List() []Definition
+    Validate() error
+}
+```
+
+首期注册现有主线、`product_manager`、`test_manager`。每个定义包含版本、阶段、模板、步骤提供器、输入契约和质量配置。
+
+如果采用 YAML：
+
+- 新增 `configs/workflows/product_manager.yaml`；
+- 新增 `configs/workflows/test_manager.yaml`；
+- 新增加载、schema 校验、重复键、依赖环和模板存在性测试。
+
+如果首期采用 Go 注册表，也必须实现同样抽象，避免继续让 `SupportedTasks` 承担工作流目录职责。
+
+### 6.2 ProjectWorkflowService
+
+实现：
+
+- `InitializeProjectWorkflows`；
+- `ListProjectWorkflows`；
+- `GetProjectWorkflow`；
+- `ActivateWorkflow`；
+- `GetActiveWorkflow`；
+- `ValidateRunTarget`；
+- `RecordRunStarted/Completed/Failed`。
+
+激活必须使用事务与项目行锁，并支持 `expected_version`。
+
+### 6.3 API
+
+实现：
+
+- `GET /api/v1/projects/{id}/workflows`；
+- `PUT /api/v1/projects/{id}/active-workflow`；
+- 可选 `GET /api/v1/projects/{id}/workflow-activation-audits`（创建人或管理员）。
+
+### 6.4 事件
+
+定义内部事件：
+
+- `project.workflow.activated`；
+- `project.workflow.run_started`；
+- `project.workflow.run_completed`；
+- `project.workflow.run_failed`；
+- `project.document.stale`。
+
+事件先可同步写活动流，后续再迁移到 Outbox。不得因为通知失败回滚已经成功的激活事务；审计写入必须与激活同事务。
+
+### 6.5 测试
+
+- 一个项目存在多个工作流；
+- 不同项目同名工作流隔离；
+- 创建人切换成功；
+- 非创建人切换返回 403；
+- 切换到不存在/禁用工作流失败；
+- 重复激活同一工作流幂等；
+- 两个并发切换请求最多一个基于旧版本成功；
+- 审计记录 from/to/actor/version 正确；
+- 切换不修改运行状态与文档状态；
+- 缓存失效后上下文读取到最新激活工作流。
+
+### 6.6 完成条件
+
+- 项目工作流清单和激活状态以数据库为权威；
+- 权限、并发和审计闭环；
+- 尚未接入专项执行时也可独立验收控制面。
+
+## 7. Phase 3：Coordinator、上下文与运行 API 集成
+
+### 7.1 上下文改造
+
+- `ProjectInfo` 增加创建人、激活键和选择版本；
+- `CurrentWorkflow` 兼容字段改为读取激活键，不再由最近工作区覆盖；
+- 新增 `LastRun`/`ActiveRun` 描述运行态；
+- `GetProjectContext` 联查项目工作流摘要；
+- 缓存键包含项目与工作流选择版本；
+- 工作流切换后使 C4 项目上下文与相关会话缓存失效。
+
+### 7.2 动作与路由
+
+- 重构 `ComputeAvailableActions`，组合成熟度、激活工作流和权限；
+- 新增激活工作流意图/槽位或复用现有交互卡机制；
+- 明确“当前工作流”“产品经理”“测试经理”的别名映射；
+- 非创建人请求切换时返回稳定说明；
+- 创建人跨工作流操作时先确认切换；
+- 所有写动作再次经过 `ProjectWorkflowService`，不能只依靠 L1 意图结果。
+
+### 7.3 运行 API
+
+新增项目工作流运行接口，或在现有任务接口前增加适配层：
+
+- 认证用户解析；
+- 项目可见性与运行权限；
+- 工作流归属与激活状态；
+- 输入前置条件；
+- 运行幂等；
+- `workflow_runs` 状态；
+- SSE 事件携带 `project_id/workflow_key/run_id`；
+- 完成事件包含输出文档与质量摘要。
+
+### 7.4 测试
+
+- 未激活时“当前工作流”需要用户选择；
+- 激活后省略表达路由正确；
+- 显式提及非当前工作流不会静默切换；
+- 创建人确认卡可完成切换后继续；
+- 非创建人确认卡无法绕过服务端；
+- 会话重启后仍读取项目激活状态；
+- 两个会话共享同项目时状态一致；
+- SSE 断线重连不重复创建运行。
+
+### 7.5 完成条件
+
+- 对话、REST 和 SSE 使用同一工作流控制服务；
+- `CurrentWorkflow` 不再被最近工作区错误覆盖；
+- 运行记录与项目工作流状态可观察。
+
+## 8. Phase 4：智能产品经理工作流
+
+### 8.1 模板与定义
+
+1. 将 `.refs/weichen-agent-system/templates/docs/system_reqs.md` 复制到 `templates/docs/system_reqs.md`；
+2. 核对模板变量与当前渲染器：`project_name`、`generated_at`、`snapshot_id`、`applicability`、`na_rationale`、`materials`；
+3. 统一 UR/UN 命名；
+4. 注册 `product_manager` 工作流和 `system_reqs` 任务；
+5. 为模板生成 SHA-256 并写入输入快照/manifest。
+
+### 8.2 输入装配
+
+实现 `ProductManagerInputAssembler`：
+
+- 接收显式材料引用；
+- 未提供材料时读取项目上下文；
+- 读取项目黑板、里程碑决策和基础字段；
+- 固定材料哈希与上下文版本；
+- 冲突不自动解决；
+- 生成 `MaterialItem`、`Fields` 和 `UserContext`；
+- 缺失非阻塞字段进入待确认清单。
+
+### 8.3 小队步骤
+
+新增专用基线步骤：
+
+- 整理产品介绍、需求输入和 UR 池；
+- 工程需求分解与验证方式；
+- 条件法规核查；
+- 高复杂度写作计划与计划审核；
+- 模板成文；
+- 追溯与粒度终审。
+
+尽量复用 `organizer/engineer/regulatory/writer/leader`，不需要新增角色类型。
+
+### 8.4 领域质量门禁
+
+实现结构化 Markdown 表格解析或中间 JSON 产物，检查：
+
+- 系统需求表非空；
+- ID 唯一连续；
+- 上游追溯非空；
+- 验证方式非空；
+- 原子需求规则；
+- 待确认项；
+- 模板章节；
+- 无占位符、无敷衍短语。
+
+推荐让工程步骤同时输出 `requirements.json`，writer 根据它写 Markdown，质量门禁校验 JSON 与 Markdown 一致。不要只靠正则解析复杂表格。
+
+### 8.5 DocGov 集成
+
+- 稳定文档 ID：`doc_proj{projectID}_product_manager_system_reqs`；
+- `workflow_key=product_manager`；
+- `stage_key=system_reqs`；
+- 生成完成后标记非模板；
+- 保存输入快照和血缘；
+- 继续使用作者、审核人、批准人和编辑租约；
+- 已认领文档的重生成走变更提案，不直接覆盖。
+
+### 8.6 测试
+
+单元测试：
+
+- 有需求文档的输入装配；
+- 仅项目上下文的输入装配；
+- 冲突来源保留；
+- 缺字段待确认；
+- 模板渲染；
+- UR/需求映射门禁；
+- 未渲染占位符失败。
+
+集成测试：
+
+- Stub backend 生成完整工作区；
+- 材料进入 `context/materials_text`；
+- manifest 含输入和模板哈希；
+- 文档记录进入 drafting；
+- 重复运行遵守租约与提案规则；
+- SSE 阶段事件顺序正确。
+
+端到端测试：
+
+- 创建项目→激活产品经理→上传用户需求→生成→审核→批准；
+- 创建项目→激活产品经理→无上传材料→使用项目上下文生成。
+
+### 8.7 完成条件
+
+- 两种输入路径均可完成；
+- 输出满足模板和领域门禁；
+- 文档版本和输入可追溯；
+- 产品经理输出可被下游服务稳定查询。
+
+## 9. Phase 5：智能测试经理工作流与文档血缘
+
+### 9.1 模板与定义
+
+1. 将 `.refs/weichen-agent-system/templates/docs/test_manager.md` 复制到 `templates/docs/test_manager.md`；
+2. 核对模板变量；
+3. 注册 `test_manager` 工作流和 `system_test_plan` 阶段；
+4. 配置法规库依赖和降级策略；
+5. 注册系统测试质量配置。
+
+### 9.2 前置条件解析
+
+实现 `TestManagerPrerequisiteResolver`：
+
+- 查询同项目产品经理文档；
+- 过滤空模板；
+- 正式模式只选择 `approved`；
+- 默认最新已批准版本，但允许显式固定历史版本；
+- 校验调用者可访问；
+- 读取内容和哈希；
+- 生成 `PriorDocItem` 和 `document_lineage`；
+- 找不到时返回结构化错误与下一步建议。
+
+### 9.3 输入装配与执行
+
+- 合并项目上下文与上游系统需求；
+- 法规检索扩大检索数量并保留候选判定；
+- 组织步骤输出需求清单；
+- 法规步骤输出适用性矩阵；
+- 工程步骤输出 `test_cases.json`；
+- writer 生成模板正文；
+- leader 检查覆盖与可操作性；
+- 质量门禁失败进入定向修复。
+
+### 9.4 领域质量门禁
+
+建议结构化中间产物：
+
+```json
+{
+  "upstream_requirements": ["RS-001", "RF-002"],
+  "test_cases": [
+    {
+      "requirement_id": "RS-001",
+      "test_case_id": "TSYS-0001",
+      "method": "...",
+      "acceptance": "...",
+      "disposition": "tested"
+    }
+  ],
+  "exclusions": [],
+  "regulatory_coverage": []
+}
+```
+
+校验：
+
+- 上游需求全集等于 tested + excluded + unclear 的集合；
+- 禁止静默遗漏；
+- 测试用例 ID 唯一连续；
+- 每个 tested 需求至少一个用例；
+- 方法与接受准则非空；
+- 主表行数与 4.1 的 N 一致；
+- 资源和法规附录完整；
+- JSON 与 Markdown 一致。
+
+### 9.5 stale 传播
+
+在产品经理文档新版本保存/批准后：
+
+1. 查询 `document_lineage` 中引用旧版本的下游文档；
+2. 比较新旧内容哈希；
+3. 内容变化则标记测试方案 stale；
+4. 写入 `stale_reason` 和活动审计；
+5. UI 展示影响；
+6. 不自动覆盖测试方案。
+
+项目关键事实更新也触发影响评估。首期可先对固定敏感键做规则判断，后续再增加语义差异评估。
+
+### 9.6 测试
+
+前置条件：
+
+- 无产品经理文档时正式运行失败；
+- 只有模板时失败；
+- 草稿在正式模式下失败；
+- 已批准版本成功；
+- 跨项目文档被拒绝；
+- 无权文档被拒绝；
+- 显式历史版本被正确固定。
+
+质量：
+
+- 上游需求全部覆盖；
+- 遗漏任一需求失败；
+- 方法只有标准号时失败；
+- 排除没有依据时失败；
+- 用例数与主表不一致时失败；
+- 法规库不可用时严格模式失败、降级模式受限。
+
+血缘：
+
+- 输出记录上游版本和哈希；
+- 上游无内容变化不标 stale；
+- 上游内容变化标 stale；
+- stale 不解锁或删除下游文档；
+- 重新生成新版本后血缘指向新上游版本。
+
+端到端：
+
+- 创建项目→产品经理生成并批准→切换测试经理→生成测试方案；
+- 上游需求更新→测试方案 stale→重新生成/变更提案。
+
+### 9.7 完成条件
+
+- 下游运行前置条件可靠；
+- 上游覆盖无静默遗漏；
+- 文档血缘可查询、可复现；
+- stale 传播不破坏 DocGov 状态机。
+
+## 10. Phase 6：前端项目工作流体验
+
+### 10.1 类型与 API Client
+
+新增类型：
+
+- `ProjectSummary`；
+- `ProjectWorkflowSummary`；
+- `WorkflowPrerequisiteStatus`；
+- `WorkflowSelectionState`；
+- `WorkflowRunSummary`；
+- `DocumentLineageSummary`。
+
+新增 API：
+
+- `projectApi.create/list/get`；
+- `workflowApi.list/activate/run/getRun`；
+- 激活错误码映射；
+- SSE 运行上下文增加 `workflowKey/runId`。
+
+### 10.2 状态模型
+
+- 项目实体与会话实体分离；
+- 多个会话引用同一个 `projectId`；
+- 激活工作流来自服务端，不放在单个会话中独立保存；
+- `localStorage` 只缓存项目最近访问和 UI筛选；
+- 登录用户变化时清理不再有权访问的缓存；
+- 激活成功后更新所有同项目视图。
+
+### 10.3 组件
+
+建议新增：
+
+- `ProjectWorkflowSwitcher`；
+- `WorkflowOverviewPanel`；
+- `WorkflowPrerequisiteBanner`；
+- `WorkflowRunActionBar`；
+- `UpstreamDocumentPicker`；
+- `StaleDocumentNotice`；
+- `WorkflowActivationConfirmDialog`。
+
+### 10.4 交互测试
+
+- 创建人可打开并切换；
+- 非创建人只读；
+- 切换确认文案说明不会取消任务；
+- 409 后刷新状态并提示重新选择；
+- 测试经理缺上游时显示可行动提示；
+- 可选择最新已批准或历史版本；
+- stale 提示展示原因与新旧版本；
+- 两个浏览器标签状态最终一致；
+- 键盘访问、焦点、禁用态、错误提示满足可访问性。
+
+### 10.5 完成条件
+
+- 项目级选择体验清晰，不与文档分类筛选混淆；
+- 权限反馈与服务端一致；
+- 用户能完整完成两个工作流的串联路径。
+
+## 11. Phase 7：端到端验证、迁移与上线
+
+### 11.1 自动化测试门禁
+
+后端：
+
+- `go test ./...`；
+- PostgreSQL 迁移与集成测试；
+- 并发激活 race 测试；
+- 工作流配置启动校验；
+- Stub backend 端到端；
+- 真实 backend 的受控 smoke test；
+- 鉴权和跨项目越权测试；
+- DocGov 状态与 stale 组合测试。
+
+前端：
+
+- 类型检查；
+- 单元测试；
+- 构建；
+- 关键组件交互测试；
+- 项目创建、切换、运行、断线恢复路径测试。
+
+### 11.2 数据验证
+
+- 每个项目的 `creator_user_id` 回填报告；
+- 每个项目的工作流实例数量；
+- `active_workflow_key` 必须属于 `project_workflows`；
+- 同项目工作流键唯一；
+- 运行记录项目 ID 与工作流实例项目 ID一致；
+- 文档血缘上下游同项目；
+- stale 文档具备原因和时间；
+- 无孤立审计或运行记录。
+
+### 11.3 灰度顺序
+
+建议功能开关顺序：
+
+1. 仅开启数据库双写与只读工作流清单；
+2. 对内部测试项目开启创建人切换；
+3. 开启智能产品经理；
+4. 验证产品经理文档质量和 DocGov；
+5. 开启智能测试经理草案模式；
+6. 验证法规库、覆盖门禁与血缘；
+7. 开启正式测试经理模式；
+8. 全量启用新项目；
+9. 历史项目分批迁移。
+
+### 11.4 监控与回滚阈值
+
+重点观察：
+
+- 激活 403/409 比例异常；
+- 项目创建后工作流初始化失败；
+- 工作流运行失败率或时长显著增加；
+- 产品经理质量门禁失败率；
+- 测试经理上游缺失/覆盖失败率；
+- stale 数量异常激增；
+- SSE 断线和重复运行；
+- 文档租约冲突。
+
+出现数据完整性、越权或跨项目引用问题时立即关闭写功能开关；保留新表数据，不执行破坏性回滚。
+
+## 12. 推荐代码变更清单
+
+以下为实施时的建议文件范围，最终以当前分支源码复核为准。
+
+### 12.1 新增
+
+- `internal/projectworkflow/types.go`
+- `internal/projectworkflow/catalog.go`
+- `internal/projectworkflow/store.go`
+- `internal/projectworkflow/service.go`
+- `internal/projectworkflow/policy.go`
+- `internal/projectworkflow/dependency.go`
+- `internal/projectworkflow/errors.go`
+- `internal/projectworkflow/*_test.go`
+- `configs/workflows/product_manager.yaml`（若采用 YAML）
+- `configs/workflows/test_manager.yaml`（若采用 YAML）
+- `templates/docs/system_reqs.md`
+- `templates/docs/test_manager.md`
+- 新数据库迁移文件
+- `internal/server/project_workflow_api.go`
+- `internal/server/project_workflow_api_test.go`
+- `web/src/api/projectWorkflow.ts`
+- `web/src/components/project/ProjectWorkflowSwitcher.tsx`
+- `web/src/components/project/WorkflowOverviewPanel.tsx`
+- `web/src/components/project/WorkflowPrerequisiteBanner.tsx`
+- 对应前端测试。
+
+### 12.2 修改
+
+- `internal/squad/service.go`：注册或适配两个新任务；
+- `internal/squad/workspace.go`：专项步骤与输入快照；
+- `internal/squad/quality_gate.go`：接入可插拔领域规则；
+- `internal/bizdev/service.go`：在保留执行能力的同时接受权威工作流输入；
+- `internal/coordinator/context.go`：项目工作流上下文；
+- `internal/coordinator/engine.go`：激活确认与路由；
+- `internal/ctxmgr/manager.go`：读取权威激活状态与缓存失效；
+- `internal/docgov/types.go` / `engine.go`：工作流血缘和 stale；
+- `internal/server/server.go`：路由注册；
+- `internal/server/handlers.go` / `sse.go`：认证身份和兼容层；
+- `web/src/types/workbench.ts`：项目工作流类型；
+- `web/src/App.tsx`：服务端项目与工作流状态集成；
+- 项目/数据库初始化脚本和测试夹具。
+
+### 12.3 不应修改的边界
+
+- 不以参考系统替换当前 Agent backend；
+- 不删除现有商务研发任务；
+- 不绕过 DocGov 直接覆盖受控文档；
+- 不把创建人权限写死到前端角色；
+- 不让激活切换直接操作 `workflow.json`；
+- 不把项目工作流实例存放在临时工作区文件中作为权威状态。
+
+## 13. 测试矩阵
+
+### 13.1 权限
+
+- 创建人激活：允许；
+- 项目成员激活：拒绝；
+- 非成员激活：不可见/拒绝；
+- 请求体伪造用户：拒绝；
+- 管理员普通接口代切换：拒绝；
+- 管理员专用 override：仅在明确实现且审计时允许。
+
+### 13.2 状态
+
+- ready→active focus；
+- active A→active B；
+- active B→B 幂等；
+- 切换到 disabled 拒绝；
+- 工作流 running 时切换焦点，运行继续；
+- 文档 reviewing/approved 时切换，不改变文档状态；
+- 运行失败，激活状态保持。
+
+### 13.3 输入
+
+- 产品经理：需求文档；
+- 产品经理：项目上下文；
+- 产品经理：两者都有且冲突；
+- 测试经理：项目上下文 + approved 上游；
+- 测试经理：无上游；
+- 测试经理：跨项目上游；
+- 测试经理：草稿上游；
+- 测试经理：历史批准版本；
+- KB 正常、不可用、部分命中。
+
+### 13.4 并发与恢复
+
+- 同项目并发激活；
+- 不同项目并发激活；
+- 同工作流重复启动；
+- SSE 中断后续跑；
+- 同文档人工编辑与 Squad 竞争租约；
+- 上游在下游运行期间更新；
+- 服务重启后恢复项目激活和运行状态。
+
+### 13.5 质量与追溯
+
+- 产品经理缺章节、重复 ID、空追溯、空验证方式；
+- 测试经理遗漏需求、重复用例、无接受判据、排除无依据；
+- 模板变量泄漏；
+- manifest 哈希；
+- 血缘版本；
+- stale 传播与影响确认。
+
+## 14. 建议提交/PR 拆分
+
+为便于审查与回滚，建议拆分：
+
+1. PR-1：项目创建人、项目 API、数据库迁移；
+2. PR-2：项目工作流目录、实例、激活、审计与并发测试；
+3. PR-3：Coordinator/Context/运行接口适配；
+4. PR-4：智能产品经理模板、步骤、输入与质量门禁；
+5. PR-5：智能测试经理、法规模式、血缘与 stale；
+6. PR-6：前端项目工作流选择器和专项页面；
+7. PR-7：历史迁移、E2E、监控与运维文档。
+
+每个 PR 都应包含测试和迁移/回滚说明，不要先合入无校验的模板或无权限的切换接口。
+
+## 15. 工作量与优先级建议
+
+### P0：必须完成
+
+- 项目创建人服务端权威化；
+- 项目工作流实例与唯一激活状态；
+- 创建人权限与原子切换；
+- 产品经理两种输入路径；
+- 测试经理同项目上游版本依赖；
+- 两个模板与专用质量门禁；
+- 文档血缘和上游更新 stale；
+- 关键 API、数据库和 E2E 测试。
+
+### P1：上线质量
+
+- 高复杂度 plan/review_plan；
+- 多标签实时状态同步；
+- 法规库严格/降级模式 UI；
+- 领域指标与告警；
+- 历史项目迁移工具；
+- 上游差异影响摘要。
+
+### P2：后续增强
+
+- 创建人转让流程；
+- 非创建人申请切换；
+- 工作流自定义启用/禁用；
+- 可视化工作流图；
+- 多版本工作流定义迁移；
+- 需求与测试用例的结构化编辑器；
+- 基于差异的增量测试方案更新。
+
+## 16. Definition of Done
+
+只有同时满足以下条件，功能才算完成：
+
+1. 数据库迁移在空库和历史库均验证成功；
+2. 项目创建人来自认证会话且不可伪造；
+3. 同项目多个工作流可查询、状态隔离；
+4. 单一激活约束在并发测试中成立；
+5. 非创建人无法通过 UI、REST、SSE 或对话绕过切换权限；
+6. 产品经理能从两类输入生成符合模板和门禁的文档；
+7. 测试经理只能使用同项目合格的产品经理输出版本；
+8. 上游需求覆盖完整，测试方法可执行；
+9. 文档血缘、输入快照、模板哈希和 manifest 可复现；
+10. 上游更新正确标记下游 stale；
+11. 激活、运行和文档生命周期互不混淆；
+12. `go test ./...`、前端测试、类型检查和构建通过；
+13. 关键真实 backend smoke test 通过；
+14. 监控、审计、功能开关和回滚说明齐全；
+15. 代码变更未混入无关用户改动。
+
+## 17. 首个可交付里程碑
+
+建议第一个可演示里程碑只包含完整但较窄的闭环：
+
+1. 登录用户创建项目；
+2. 项目自动拥有智能产品经理和智能测试经理；
+3. 创建人激活智能产品经理；
+4. 上传用户需求文档或使用项目上下文；
+5. 生成并批准系统需求规格书；
+6. 创建人切换到智能测试经理；
+7. 选择已批准的系统需求规格书版本；
+8. 生成系统验证方案及计划；
+9. 修改上游需求并形成新版本；
+10. 系统将测试方案标记为 stale，并提供重新生成入口。
+
+这个里程碑同时证明：多工作流、创建人权限、激活路由、两个专项工作流、DocGov、输入快照、文档血缘和 stale 传播已经形成真正闭环。
diff --git a/.doc/system-design/project-workflow/05-Phase0-基线确认与契约冻结.md b/.doc/system-design/project-workflow/05-Phase0-基线确认与契约冻结.md
new file mode 100644
index 00000000..d7d04fbf
--- /dev/null
+++ b/.doc/system-design/project-workflow/05-Phase0-基线确认与契约冻结.md
@@ -0,0 +1,51 @@
+# Phase 0 基线确认与契约冻结
+
+> 编制日期：2026-09-10  
+> 归属项目：Chat-Agent-System 项目多工作流与专项工作流体系
+
+---
+
+## 1. 架构决策记录 (ADR)
+
+### ADR-001：三层模型与服务端项目身份权威化
+- **决策**：废除将 Squad 底层任务标识当作项目工作流的做法，确立“工作流定义（Workflow Definition）→ 项目工作流实例（Project Workflow Instance）→ 运行实例（Workflow Run）”三层领域模型。
+- **创建人权威**：项目创建人必须从认证 Token (`auth.UserAccount.ID`) 提取并写入 `projects.creator_user_id`，禁止客户端在 Request Body 中传入或伪造；普通项目更新接口不可修改 `creator_user_id`。
+
+### ADR-002：单一激活焦点与并发版本控制
+- **决策**：每个项目可挂载多个工作流实例，但全局有且仅有一个当前激活焦点 `projects.active_workflow_key`。
+- **并发与审计**：激活切换仅限项目创建人执行，采用数据库行级锁 (`FOR UPDATE`) 与 `workflow_selection_version` 乐观锁防重放/冲突；每次切换均生成只追加记录到 `workflow_activation_audits`。
+- **运行时无损**：激活切换仅更改对话/前端的路由焦点，绝不取消后台进行中的任务运行，也不更改受控文档生命周期状态。
+
+### ADR-003：上下游依赖契约与 Stale 传播
+- **决策**：智能测试经理工作流强依赖同项目下智能产品经理的输出成果，正式模式必须要求产品经理文档处于 `approved` 状态；支持显式锚定历史已批准版本。
+- **血缘与 Stale**：执行时在 `document_lineage` 中记录上游文档 ID、版本与 SHA256；上游产生新版本时，下游自动打上 `stale` 标记并记录原因，绝不盲目覆写已有下游受控文档。
+
+---
+
+## 2. 标识与命名冻结表
+
+| 领域对象 | 标准标识 / Key | 阶段 / 任务 Key | 产出受控文档正式名称 | UI 显示别名 |
+| :--- | :--- | :--- | :--- | :--- |
+| **智能产品经理** | `product_manager` | `stage_key=system_reqs`<br>`task_key=system_reqs` | 《系统需求规格书》 | 系统需求规格书 / 产品需求 |
+| **智能测试经理** | `test_manager` | `stage_key=system_test_plan`<br>`task_key=test_manager` | 《系统验证方案及计划》 | 系统测试方案 / 测试验证方案 |
+
+---
+
+## 3. 标准 API 错误码清单
+
+| HTTP 状态码 | 错误码 (Code) | 说明 | 处理指引 |
+| :--- | :--- | :--- | :--- |
+| `401 Unauthorized` | `ERR_UNAUTHENTICATED` | 会话已过期或未提供 Token | 重新登录并刷新 Token |
+| `403 Forbidden` | `ERR_NOT_PROJECT_CREATOR` | 非项目创建人无权切换工作流 | 提示联系项目创建人进行配置 |
+| `404 Not Found` | `ERR_PROJECT_NOT_FOUND` | 指定项目不存在或无权限查看 | 检查项目 ID 或核查数据权限 |
+| `404 Not Found` | `ERR_WORKFLOW_NOT_FOUND` | 工作流定义不存在或项目未开通 | 校验工作流 Key 是否有效 |
+| `409 Conflict` | `ERR_CONCURRENT_SWITCH` | 乐观版本冲突 (selection_version mismatch) | 前端刷新当前工作流状态后重试 |
+| `412 Precondition Failed`| `ERR_PREREQUISITE_NOT_MET` | 测试经理缺少已批准的产品需求文档 | 引导前往产品经理工作流完成编制与审批 |
+
+---
+
+## 4. 数据库演进与迁移策略
+
+- **权威主库**：以 `context_init.sql` 体系中的 `projects` 为基础基线。
+- **迁移脚本**：在 `deploy/postgres/migrations/2026-09-11-project-workflows-and-lineage.sql` 中统一执行 ALTER 与 CREATE。
+- **历史兼容**：`creator_user_id` 初始设置为允许 NULL，回填脚本优先以项目首个会话创建者或默认管理员 (ID: 1) 回填，确保零破坏。