28 KiB
28 KiB
纯软件项目自举工作流详细设计
状态：设计完成，待评审与实施
日期：2026-09-14
适用范围：非医疗纯软件项目；既有项目梳理、绿地立项、遗留系统现代化，以及使用 Agent-System 梳理 Agent-System 自身
实现状态：本文件是目标方案，不代表功能已经上线
1. 执行摘要
建议给 Agent-System 增加一套领域原生的“软件项目自举套件”，而不是继续复用医疗器械 main 工作流：
software_bootstrap：一次性建立项目事实、现状、需求、架构、风险、路线图与验收基线；software_delivery：按里程碑或发布重复实例化，管理变更计划、实现证据、测试、发布和复盘；- 首期只做文档与决策自举，可读取用户上传或授权的仓库快照，但不直接修改业务仓库；
- 后续增加受控工程执行器：仅在隔离 feature worktree 生成补丁，测试和人工确认后才允许合并，永不直接改
dev/test/main； - 最大限度复用现有工作流版本、冻结快照、三权、阶段门禁、文档版本账本、上下文快照、小队工作区、预算和 SSE；
- 不复用会造成语义污染的医疗模板、法规默认步骤、CDMO 负责人提示词和硬编码阶段。
推荐当前用户项目的初始选择：
| 选项 | 推荐值 | 理由 |
|---|---|---|
| 产品域 | non_medical_software |
明确与医疗器械域隔离 |
| 项目形态 | existing_self_bootstrap |
已有项目，希望梳理并用系统反向建设自身 |
| 工作流 | software_bootstrap@v1 |
先建立可信基线，再进入迭代 |
| 治理强度 | standard |
保留评审、版本和风险门禁，不引入医疗合规负担 |
| 合规配置 | internal_control + security_baseline |
无外部法规假设，但保留安全、权限、审计和发布证据 |
| 仓库接入 | read_only_snapshot |
首轮只读，避免智能体越权改码 |
| 工程执行 | docs_only |
先产出可评审路线图；受控补丁执行另行开启 |
| 小队 | 通用角色 + 软件 profile | 复用现有能力，排除默认 regulatory |
2. 设计原则
2.1 领域与合规分离
product_domain=non_medical_software 只说明产品不是医疗器械，不代表没有安全、隐私、审计或行业约束。项目还要独立选择 compliance_profile。
2.2 一个权威运行链
沿用现有 ADR：
服务端登录主体
→ 项目成员关系
→ 已发布工作流版本
→ 项目冻结快照
→ 阶段与文档任务实例
→ executor / template / quality gate / 文档三权
→ 真实 PI 小队
→ 文档版本、审批、血缘和审计
不得新增从前端 task_key、本地模板或自由对话直接绕过冻结实例的旁路。
2.3 自举不等于自治接管
智能体可以盘点、分析、提出变更、生成候选补丁和运行获准测试，但不能自行：
- 改写工作流定义或权限策略；
- 修改受保护分支；
- 合并、push、发布或删除数据；
- 读取未授权 secret；
- 把推断写成已验证事实；
- 以智能体意见代替用户的阶段推进、风险接受或发布批准。
2.4 事实分层
所有产出必须标记：
confirmed：有源码、文档、运行证据或用户确认；inferred：基于证据推导；unverified：尚未实测；decision_required：必须由用户拍板。
2.5 工作流串联而非循环定义
当前引擎是线性阶段、单项目单活动实例。初期不在 manifest 中增加回环：
software_bootstrap（一次）
→ 创建者确认完成
→ software_delivery（版本/里程碑 1）
→ 完成
→ software_delivery（版本/里程碑 2）
→ ...
每个 delivery 实例冻结自己的目标、输入、模板、责任人和验收基线，历史可审计。
3. 项目创建向导
项目创建改为七步服务端驱动向导。创建前可保存草稿，最终通过一次幂等事务建立项目、成员、规划实例和模板账本。
3.1 第一步：基本身份
| 字段 | 示例/枚举 | 必填 | 说明 |
|---|---|---|---|
name |
Agent-System 自举项目 | 是 | 项目展示名 |
code |
AS-BOOTSTRAP | 否 | 空时服务端生成 |
product_domain |
non_medical_software |
是 | 权威产品域 |
project_type |
existing_self_bootstrap |
是 | 见下表 |
product_shape |
web / SaaS / service / desktop / mobile / CLI / library / platform | 是 | 可多选 |
problem_statement |
当前问题与希望达到的状态 | 是 | 替代“临床预期用途” |
target_users |
内部团队、企业客户等 | 是 | 可多组 |
target_outcome |
可验证结果 | 是 | 例如“建立可执行发布路线” |
项目类型：
| key | 用途 | 默认输入 |
|---|---|---|
greenfield |
从零规划新软件 | 构想、用户、约束 |
existing_product |
梳理已有产品 | 文档、仓库快照、问题列表 |
legacy_modernization |
遗留系统改造 | 现状架构、痛点、迁移约束 |
existing_self_bootstrap |
系统用自身梳理和建设自身 | 当前仓库、运行说明、历史审计、目标 |
3.2 第二步：范围与成功标准
- 本轮必须解决的问题；
- 明确不做的范围；
- 目标里程碑和期望时间窗；
- 已知用户场景和业务约束；
- 性能、可用性、安全、隐私、兼容性、成本约束；
- 可量化成功标准；
- 允许智能体提出但不得替用户决定的事项。
系统生成 TaskBrief 预览，用户确认后作为工作流输入基线，不让小队自行漂移目标。
3.3 第三步：治理与合规
| 选项 | 值 | 默认 |
|---|---|---|
governance_profile |
lean / standard / controlled | standard |
team_mode |
solo / collaborative | 根据有效成员数提示，不自动猜 |
compliance_profile |
none / internal_control / security_baseline / privacy / custom | internal_control + security_baseline |
data_sensitivity |
public / internal / confidential / restricted | internal |
network_policy |
deny / allowlist / project-approved | project-approved |
execution_mode |
docs_only / read_only_repo / controlled_patch | docs_only |
budget_class |
light / medium / heavy | medium |
规则：
none只代表没有预设外部合规步骤，不关闭鉴权、审计和安全基线；controlled_patch必须在仓库绑定、分支策略、测试命令和批准人都有效后才能选择；restricted数据默认禁止外部联网检索；- 合规 profile 只能增加约束，不可通过对话临时关闭。
3.4 第四步：资料与仓库来源
首期支持：
- 页面上传 Markdown、PDF、DOCX、JSON、CSV 和代码清单；
- 浏览器上传经过用户筛选的仓库快照；
- 服务端登记只读 Git URL 或本地允许列表路径；
- 录入现有文档、Issue/PR 导出、测试报告和部署清单；
- 配置明确排除目录，如
.git、依赖缓存、构建产物、secret 和生产数据。
每个来源记录 source_type/source_ref/revision/hash/permission_scope/ingested_at。凭证只保存 secret 引用，不进入项目文档、prompt 或审计正文。
3.5 第五步：选择工作流和强度
目录只展示与 product_domain、project_type、compliance_profile 兼容的已发布版本，并标明：
- 版本号与发布日期；
- 默认阶段和文档；
- 各 profile 会启用/关闭的任务；
- 预计小队步骤、时间和预算；
- 需要几名独立责任人；
- 激活后冻结的项目配置。
首个推荐为 software_bootstrap@v1。不在创建时直接激活，先进入 planning。
3.6 第六步：成员与责任
项目角色和文档职责继续分离：
| 项目关系 | 主要能力 |
|---|---|
| creator | 配置、激活、阶段推进、受控终止、选择下一工作流 |
| product_owner | 范围和验收业务意见 |
| maintainer | 技术输入、实现证据和变更建议 |
| reviewer | 对指定文档审核 |
| approver | 对指定文档批准 |
| viewer | 只读参与 |
文档仍逐份绑定 author/reviewer/approver。
collaborative 默认三权分离。solo 不伪造三名用户，采用：
- author=创建者；
- review/approve 改为
creator_acknowledgement； - 页面持续显示“未经过独立评审”；
- controlled 或任何要求独立审查的 compliance profile 禁止 solo；
- 后续邀请 reviewer 后可通过受控变更升级，但不能回写历史签署。
3.7 第七步：创建预览与确认
确认页展示：项目类型、工作流版本、启用文档、责任人、数据来源、网络策略、小队、预算、预计耗时、冻结项和风险。服务端返回：
creation_token + plan_hash + source_hash + expected_catalog_version + expires_at
最终提交必须匹配这些值；目录、成员或来源变化返回 409 和差异，要求重新确认。
创建完成后：
- 服务端事务创建项目、owner/member、planning instance 和文档模板记录；
- 前端不再本地克隆固定 7 份医疗模板；
- 页面打开项目总览和《项目章程》；
- 初始化消息使用软件领域话术，不出现医疗、临床、注册或 CDO 默认文字。
4. 工作流 A：software_bootstrap
4.1 定位
把一个模糊或历史复杂的软件项目转成可追溯、可决策、可交付的工程基线。默认只运行一次；终止后可重建新实例，但必须保留旧证据。
4.2 阶段与交付物
| 阶段 | 文档任务 | 默认 | 门禁 |
|---|---|---|---|
| S0 项目边界 | software_charter 项目章程 |
必需 | 目标、范围外、用户、成功标准、约束均非空 |
source_inventory 资料与仓库清单 |
existing/self 必需，greenfield 可选 | 来源 hash、权限、时效和排除项完整 | |
| S1 现状基线 | current_state_audit 现状审计 |
existing/self 必需 | confirmed/inferred/unverified 分层；每个 high 问题有证据 |
architecture_baseline 当前架构与依赖图 |
existing/self 必需 | 边界、组件、数据流、部署、外部依赖可追溯 | |
software_risk_register 风险登记册 |
必需 | severity、触发条件、影响、owner、处置和状态齐全 | |
| S2 产品基线 | product_requirements 产品与系统需求基线 |
必需 | REQ ID 唯一、来源和验收标准齐全 |
scope_backlog 范围化 backlog |
必需 | 优先级、依赖、验收、非目标和决策项齐全 | |
| S3 目标方案 | target_architecture 目标架构方案 |
必需 | 对应需求、ADR、迁移路径、失效条件和回滚 |
decision_log 架构决策记录 |
standard/controlled | 每个决策含选项、理由、后果和批准状态 | |
| S4 自举路线 | bootstrap_roadmap 分阶段建设路线 |
必需 | 每个 wave 有输入、输出、依赖、完成定义和风险 |
verification_strategy 验证策略与测试矩阵 |
必需 | 单元/集成/UI/安全/恢复与真实 Agent 分开 | |
operations_baseline 部署运维与恢复基线 |
standard/controlled | 环境、发布、备份、观测、RPO/RTO 责任明确 | |
bootstrap_readiness 自举就绪评审 |
必需 | 汇总未关闭 blocker，不能把 partial 写成 ready |
4.3 profile 裁剪
| profile | 默认文档 |
|---|---|
| lean | charter、requirements、backlog、target architecture、roadmap、verification |
| standard | 全部，decision_log 和 operations_baseline 启用 |
| controlled | 全部，且独立三权、安全审查、审计导出和恢复验证强制 |
项目类型策略在生成 default plan 时应用，不改 published manifest：例如 greenfield 可关闭 current-state audit，existing/self 不可关闭。
4.4 阶段推进
阶段满足门禁后进入 awaiting_stage_confirmation，只发送一次去重通知。创建者可：
- 查看文档、风险和下一阶段影响；
- 确认推进；
- 留在当前阶段补材料；
- 对无法继续的实例执行受控终止。
系统不得自动进入下一阶段。bootstrap_readiness 批准并不意味着全系统生产可用，只意味着已具备进入 software_delivery 的可信输入。
5. 工作流 B：software_delivery
5.1 定位
每个里程碑、迭代或发布创建一个新实例。它消费已批准的 bootstrap 产物和上一次 delivery 的复盘，不修改历史基线。
5.2 阶段与交付物
| 阶段 | 文档任务 | 说明 |
|---|---|---|
| D0 变更定义 | change_brief |
目标、范围外、来源需求、风险、成功标准、预算 |
implementation_plan |
受影响组件、步骤、测试、回滚、文件范围 | |
| D1 实施证据 | change_manifest |
commit/patch、文件 hash、工具、执行者、实际偏差 |
adr_delta |
仅架构决策变化时启用 | |
| D2 验证 | test_report |
单元、集成、UI、真实 Agent、失败项和未验证项 |
security_review |
security/privacy/controlled profile 强制 | |
| D3 发布 | release_plan |
环境、迁移、备份、回滚、观察窗和批准条件 |
release_notes |
用户可见变化、兼容性、已知限制 | |
| D4 学习 | retrospective |
目标达成、偏差、事故、经验和行动项 |
backlog_delta |
新增、关闭、延期及优先级变化 |
D1 首期允许用户从外部开发流程上传 change manifest；受控工程执行器上线后可自动生成候选证据，但仍须用户批准。
5.3 交付门禁
- change brief 已批准且没有未确认的高影响范围变化；
- implementation plan 的文件范围、测试和回滚明确；
- change manifest 与实际 commit/patch/hash 一致；
- 必需测试通过，失败和跳过项不能隐藏；
- high/critical 风险已关闭或由有权用户明确接受；
- release plan 有回滚和观察窗；
- 发布动作由用户或外部 CI/CD 完成，智能体只提供候选计划和证据。
6. 智能体小队设计
6.1 复用策略
将“能力角色”和“领域 profile”组合，不复制八套相似角色：
| 基础角色 | 软件项目用法 | 处理 |
|---|---|---|
| organizer | 材料、源码清单、事实与缺口 | 直接复用，扩充软件字段 |
| searcher | 官方文档、依赖、漏洞和技术资料核验 | 复用，按 network policy 约束 |
| engineer | 架构、代码、数据、部署分析 | 复用内核，加载 software_engineering profile |
| writer | 受控技术文档成文 | 复用，移除水木东方/医疗措辞 |
| leader | 任务拆解、终审、待决策汇总 | 改为领域中立 delivery_lead profile |
| market | 用户与竞品研究 | 商业产品可选 |
| finance | 成本、云资源、团队工时 | 有预算需求时可选 |
| regulatory | 医疗法规 | 非医疗默认禁用；仅自定义合规 profile 显式启用 |
新增最小 profile，而不是新增重复的完整角色：
software_product：产品目标、用户场景、范围和验收；software_architecture：组件、接口、数据、NFR、ADR 和迁移；software_quality：测试策略、追溯、缺陷和发布门禁；software_security：威胁、依赖、权限、数据与 secret；software_operations：部署、观测、备份、恢复和容量。
6.2 预设小队
基线审计小队：organizer → engineer(software_architecture) + searcher → writer → leader。
产品与架构小队：organizer → software_product + software_architecture（并行）→ writer → leader。
风险与验证小队：software_quality + software_security（按 profile 条件启用）→ writer → leader。
交付小队：software_architecture/implementation → software_quality + software_security → operations → leader。
6.3 任务契约
每个步骤必须有结构化契约：
objective
inputs[]（含 authority/hash）
outputs[]
must_cover[]
acceptance[]
forbidden_actions[]
budget
timeout
evidence_required[]
规划器可建议加步，但新增步骤必须通过角色、工具、预算、目录边界和输出 schema 守卫；不得由模型自由扩大授权。
7. 软件文档模板与质量门禁
7.1 模板共同结构
所有软件模板至少包含：
- 结论与决策请求；
- 目标、范围和非目标；
- 输入证据及版本；
- 正文分析或方案；
- 风险、影响与依赖；
- 已确认、推断、未验证清单；
- 验收标准；
- 开放问题和责任人；
- 版本、作者、审核、批准和生成 manifest。
7.2 确定性门禁
| 文档 | 机器门禁示例 |
|---|---|
| charter | objective/non-goals/success criteria 非空 |
| source_inventory | 每个来源有类型、revision/hash、权限和排除项 |
| audit | high 问题必须有 evidence、impact、recommendation；未验证不能写 confirmed |
| requirements | ID 唯一；每条有来源、优先级、验收方式 |
| architecture | 组件和接口唯一；每个关键 NFR 有设计响应；Mermaid 安全解析 |
| risk_register | severity/likelihood/impact/owner/mitigation/status 齐全 |
| roadmap | 每个 wave 有依赖、完成定义、验证和回滚 |
| test_report | Input/Expected/Actual/Verdict/Duration；真实与 stub 分开 |
| readiness | 所有 blocker 汇总一致，不得把 partial/fallback 写成 PASS |
LLM 可以解释事实，但不能降低确定性风险等级、伪造测试结果或把失败改写成成功。
8. 自举 Agent-System 自身的实战路径
推荐按以下顺序使用：
- 创建
existing_self_bootstrap项目； - 上传/授权读取
AGENTS.md、PROJECT.md、.doc索引、依赖清单、源码树和当前测试报告； - 对话确认本轮目标，例如“建立下一发布周期的可信路线，而不是直接改码”；
- 真实小队生成项目章程、来源清单、现状审计、架构基线和风险登记册；
- 用户在页面审核、修改、批准；高风险差异必须确认；
- 生成目标架构、backlog、自举路线和验证策略；
- readiness 门禁列出仍开放的 CHAT-INTENT、CI、PI 叙事等问题，不得沿用旧结论冒充当前；
- 创建者确认 bootstrap 完成；
- 系统建议创建第一个
software_delivery实例，但不自动创建； - 首轮 delivery 仍采用 docs-only：输出 change brief 与 implementation plan，由外部 feature 分支实现；
- 未来 controlled patch 上线后，再把候选补丁和真实测试证据接回 D1/D2。
9. 数据模型调整
9.1 项目与目录
建议新增：
| 对象/字段 | 用途 |
|---|---|
projects.product_domain |
权威产品域 |
projects.project_type_key |
greenfield/existing/legacy/self-bootstrap |
projects.compliance_profile_key |
合规配置引用 |
projects.governance_profile |
lean/standard/controlled |
projects.team_mode |
solo/collaborative |
projects.execution_mode |
docs_only/read_only_repo/controlled_patch |
project_types |
字段 schema、默认 profile、推荐工作流 |
compliance_profiles |
版本化约束和必需任务 |
project_type_workflows |
允许/推荐工作流及 profile overrides |
project_source_bindings |
资料/仓库来源、revision/hash、权限、secret_ref |
agent_profile_versions |
软件领域角色 overlay 的不可变版本 |
device_type/intended_use/target_market 暂保留兼容读取，但非医疗项目不再以它们作为权威字段。迁移只回填明确数据，不能把所有旧项目自动标记为医疗或软件。
9.2 工作流适用性
统一 workflow_definitions 和 manifest 的领域表达：
applicability = {
product_domains[],
project_types[],
allowed_compliance_profiles[],
governance_profiles[]
}
删除“仅三正式 key”和固定文档数量的代码硬编码，改为：published + project_selectable + manifest validation + catalog policy。医疗现有三工作流仍保留为正式种子。
9.3 单人治理
在冻结 plan 中加入 approval_policy：
independent_three_duties；creator_acknowledgement。
后者只能用于允许 solo 的项目类型/profile，并在文档与审计中持续显示无独立评审，不复用虚拟用户。
10. API 设计
复用现有 settings/plan/activation/stage API，并新增或扩展：
GET /api/v1/project-types/catalog
GET /api/v1/compliance-profiles/catalog
POST /api/v1/projects/creation-preview
POST /api/v1/projects # 幂等事务创建
GET /api/v1/workflows/catalog?product_domain=&project_type=&profile=
POST /api/v1/projects/{id}/sources
GET /api/v1/projects/{id}/sources
POST /api/v1/projects/{id}/sources/{source}/refresh-preview
POST /api/v1/projects/{id}/sources/{source}/refresh
GET /api/v1/projects/{id}/settings
GET /api/v1/projects/{id}/workflow-plan/default
PUT /api/v1/projects/{id}/workflow-plan
POST /api/v1/projects/{id}/activation-preview
POST /api/v1/projects/{id}/workflow-instances/activate
POST /api/v1/workflow-instances/{id}/stages/{stage}/advance
后续受控工程执行：
POST /api/v1/projects/{id}/change-requests
POST /api/v1/change-requests/{id}/execution-preview
POST /api/v1/change-requests/{id}/approve-execution
POST /api/v1/change-requests/{id}/execute
POST /api/v1/change-requests/{id}/verify
POST /api/v1/change-requests/{id}/merge-preview
执行、合并和发布分别授权；批准执行不等于批准合并，更不等于批准发布。
11. UI 融入方案
11.1 项目创建
将现有单页医疗表单改成七步向导，标题改为“创建项目”。根据 product domain 切换字段和帮助文本。右侧固定显示：推荐工作流、预计文档、小队、预算和冻结影响。
11.2 项目主页
新增：
- 项目类型、治理强度、当前 workflow instance 和 active stage；
- 事实/推断/未验证数量；
- 风险和待决策角标；
- 来源 freshness；
- “建议下一工作流”卡片，仅创建者可确认；
- 当前阶段成员与每份文档职责。
11.3 文档与对话
- 对话输入可触发已冻结的软件 task key；
- 简单问题继续单轮回复，复杂自由任务先给初答并征求是否升级小队；
- 小队名称、角色、步骤、预算和进度在页面可见；
- 右栏复用版本账本、人工修订、变更报告、确认/拒绝和版本比较；
- change report 必须展示项目影响、文档影响、风险、开放问题和分析来源；fallback 继续明确标识。
11.4 软件领域去污染
纯软件项目页面和文档默认不得出现：临床、NMPA、注册检验、GB 9706、器械分类、CDMO、疗效等词。只有用户材料或所选合规 profile 明确要求时才允许出现，并标注来源。
12. 受控代码执行层（后续）
12.1 安全边界
- 仓库路径必须在管理员 allowlist；
- 每次执行创建独立
feature/<slug>worktree； - 允许文件范围来自已批准 implementation plan；
- 禁止读取
.env、secret、生产 dump； - 命令来自管理员登记的测试/build allowlist；
- 超时、预算、进程和输出大小有硬上限；
- 失败保留证据并停止，不自动反复重试；
- 任何 merge/push/deploy 都需要新的显式确认。
12.2 产物
- patch/commit 候选；
- 文件变更清单与 hash；
- 命令、退出码、耗时和截断说明；
- 单元/集成/UI 测试报告；
- 风险与回滚；
- 未验证项；
- 与 change brief 和 requirement ID 的追溯。
13. 实施路线
| Wave | 内容 | 主要改动 | 退出标准 |
|---|---|---|---|
| W0 契约冻结 | key、profile、阶段、文档、角色、API 与迁移决策 | ADR/manifest schema/错误码 | 评审通过，无双权威 |
| W1 项目域与目录 | 项目类型、合规、治理、catalog filter、迁移 | DB + workflowdef/projectinstance | 医疗旧项目无回归；软件只见兼容工作流 |
| W2 软件工作流与模板 | bootstrap/delivery manifests、模板、executor、quality gate | workflow/squad/template | 校验、模板、任务注册一致 |
| W3 创建事务与向导 | creation preview、幂等创建、成员、模板账本、七步 UI | server + web | 刷新/跨设备一致；不再本地克隆固定 7 文档 |
| W4 对话与小队 | 软件意图词典、domain context、角色 profile、禁医疗污染 | intent/coordinator/bizdev/squad | 简单对话不误启小队，正式任务走冻结实例 |
| W5 门禁与交接 | 软件 readiness、风险、下一 workflow 建议与确认 | projectinstance/notification | 完成后只建议、不自动启动 delivery |
| W6 真实验收 | PG、真实 PI、Ubuntu 无头 UI、重启和权限负例 | tests/reports | 黄金项目全部页面可见且证据落盘 |
| W7 受控工程执行 | repo binding、worktree、patch/test/merge approvals | 独立 Epic | 不直接改保护分支，不泄露 secret |
建议 W0–W6 作为首个交付，单人全职约 4–6 周；W7 单独估算 2–4 周。实际工期应在 W0 基于代码量和测试环境重新估算。
14. 验收策略
必须分别报告：
- 纯函数和 manifest/quality gate 单元测试；
- PostgreSQL 空库迁移与旧库升级；
- API 鉴权、并发、幂等、冻结和重启；
- 前端组件和构建；
- stub 小队工程回归；
- 真实 PI Agent Runner 文档生成；
- Ubuntu Server 官方 Playwright 容器真实 UI；
- 未来受控代码执行的隔离 worktree 和负例。
真实 UI 黄金场景至少包括：
- 绿地协作项目；
- 既有仓库单人自举项目；
- Agent-System 自身作为项目；
- 无权限成员、错误域工作流、伪造 task key、过期确认令牌；
- 首轮生成、人工修改、审核批准、阶段推进；
- 第二轮差异、风险/影响、确认与拒绝；
- 刷新、重登、应用重启后恢复；
- 纯软件默认无医疗语义污染；
- bootstrap 完成后只出现 delivery 建议，必须由创建者确认。
详细用例见 验收清单。任何未真实运行的用例必须写 NOT RUN，不得用 stub 或静态 JSON 冒充。
15. 风险与对策
| 风险 | 等级 | 对策 |
|---|---|---|
| 医疗模板/提示词污染软件结论 | high | 新 task/template/profile；黄金负例扫描 |
| 工作流 key 和 executor 继续硬编码 | high | 统一 catalog policy 和 registry，发布时完整校验 |
| 单人模式伪造三权 | high | creator acknowledgement + 明示未独立评审 |
| 自举 Agent 越权改自身治理 | critical | 首期只读；后续 worktree + 多段批准 |
| 仓库和 secret 泄露到 prompt | critical | allowlist、排除、secret_ref、输出扫描 |
| 文档很多但不能指导执行 | medium | requirement/backlog/roadmap/test trace；delivery 实例承接 |
| 自由任务绕过正式工作流 | high | 正式交付只认 doc_task_instance；ad-hoc 只能辅助 |
| 旧医疗项目回归 | high | 新 key/新版本；兼容迁移；医疗/软件双黄金 E2E |
| 真实 PI 产出幻觉 | high | 证据层级、确定性门禁、用户审批、不得伪造测试 |
| 大型仓库上下文爆炸 | medium | 清单→相关文件→摘要的分层采集；预算和 hash |
16. 决策请求
实施前只需要用户确认两项产品决策：
- 首期是否按推荐的
docs_only/read_only_repo交付，把自动生成代码补丁放到 W7； - 当前实际使用是
solo还是collaborative，以冻结真实的审批策略。
其余字段可采用本文件推荐默认值并在创建向导中调整。