软件项目治理 — 总工作流入口

本文件是 software-project-governance 工作流的唯一总入口。无论是全流程推进还是单独使用某个子工作流，agent 都必须先读取本文件确认基础目的和匹配规则。

两个基础目的

本工作流存在的根本原因只有两个。所有子工作流和工具都服务于这两个目的，无一例外：

目的一：看护过程目标，避免偏离

项目从立项到交付，目标漂移是最大的过程风险。本工作流通过以下机制防止偏离：

• 目标锚定：立项时定义的量化成功标准（OKR / PR/FAQ）在后续每个阶段都会被重新检查
• 决策留痕：任何可能改变项目方向的决策，必须记录到 .governance/decision-log.md
• 风险前置：发现偏离信号立即记录到 .governance/risk-log.md，不等到 Gate 检查时才暴露
• Gate 阻断：每个阶段退出前检查目标一致性，偏离未经决策批准则阻断

目的二：看护过程质量，避免低质交付

"做完了"不等于"做好了"。本工作流通过以下机制防止低质交付：

• 进入条件：每个阶段有明确的准入标准，不满足条件不开始
• 产出物标准：每个阶段有量化的产出物质量标准，不接受纯定性描述
• 独立评审：关键阶段引入外部评审人（Bar Raiser / 蓝军），不依赖执行者自我评估
• 数据驱动：所有质量判断必须有量化数据支撑（覆盖率、通过率、性能基线对比等）
• 自动化判定：能自动化的检查项不依赖人工判断，减少主观误差

三层内容架构

┌──────────────────────────────────────────────┐
│  第一层：项目整体治理层（本文件 + core/）         │
│  职责：目标看护、阶段推进、Gate 把控、场景匹配  │
├──────────────────────────────────────────────┤
│  第二层：阶段子工作流层（skills/stage-*/）      │
│  职责：进入条件→活动清单→产出物→退出条件→Gate   │
│  每个子工作流可独立使用，但必须锚定总目标        │
├──────────────────────────────────────────────┤
│  第三层：基础工具/SKILL层（skills/*-review/等）  │
│  职责：可复用的审查 SKILL、模板、校验脚本        │
│  工具独立于阶段，多个子工作流可共用同一工具       │
└──────────────────────────────────────────────┘

层级关系

1. 总工作流 → 子工作流：总工作流根据用户场景匹配到对应子工作流，子工作流执行过程中受总工作流的目标和 Gate 约束
2. 子工作流 → 工具：子工作流调用工具层的具体脚本来执行检查、评审、验证等操作
3. 独立使用：用户可以跳过总工作流，直接使用某个子工作流或工具。但独立使用时，子工作流和工具必须执行目标锚定检查

11 阶段总览

阶段推进规则

• 默认顺序：1→2→3→...→11，前一阶段 Gate 通过后进入下一阶段
• 可重叠：相邻阶段在满足条件后可并行（如开发与测试）。受 profile 约束：strict 禁止阶段重叠（见 core/profiles.md），standard/lightweight 允许相邻阶段重叠
• 可回退：后续阶段发现前置阶段遗漏时允许回退补齐
• 可跳转：已在进行中的项目可通过 onboarding 协议中途接入当前阶段

场景 → 子工作流匹配规则

当用户发起请求时，agent 按以下规则匹配到具体子工作流或工具：

全流程场景 → 总工作流

阶段场景 → 子工作流

工具场景 → 具体工具

完整工具目录见 TOOLS.md。

跨层调用协议

总工作流调用子工作流

当总工作流匹配到子工作流后：

1. 传递目标上下文：从 plan-tracker 中提取当前项目的量化成功标准，传递给子工作流
2. 传递 Gate 状态：告知子工作流前置 Gate 的状态（passed / passed-on-entry / passed-with-conditions）
3. 执行子工作流：按子工作流的进入条件→活动清单→产出物→退出条件执行
4. 回写治理记录：子工作流完成后，将产出物和 Gate 结论回写到 .governance/

子工作流调用工具

当子工作流需要执行具体检查时：

1. 从 infra/TOOLS.md 查找匹配工具
2. 按工具的触发条件和输入要求执行
3. 工具输出作为子工作流产出的组成部分

独立使用子工作流（不经总工作流）

当用户直接触发子工作流时：

1. 强制读取 plan-tracker：确认项目当前阶段和目标
2. 执行目标锚定检查：对照立项成功标准，确认当前工作不偏离
3. 执行质量底线检查：对照 profile 的质量标准
4. 执行子工作流本身
5. 回写治理记录

独立使用工具（不经子工作流）

当用户直接触发工具时：

1. 执行目标锚定检查（轻量版）：快速确认当前操作仍在项目目标范围内
2. 执行工具本身
3. 如工具产出影响项目状态，回写到 .governance/

Agent 加载顺序

当 agent 被触发且需要加载本工作流时，按以下顺序读取：

完整加载（全流程治理）

1. 本文件（main-workflow.md）— 确认两个基础目的和匹配规则
2. .governance/plan-tracker.md — 确认项目当前状态
3. core/lifecycle.md — 确认阶段模型和触发模式
4. core/stage-gates.md — 确认 Gate 规则
5. core/profiles.md — 确认项目 profile 配置
6. 匹配到的子工作流 — 执行具体阶段活动
7. TOOLS.md — 按需查找工具

按需加载（单个子工作流或工具）

1. 本文件（main-workflow.md）— 确认两个基础目的（不可跳过）
2. .governance/plan-tracker.md — 确认项目目标
3. 目标子工作流或工具
4. TOOLS.md — 按需查找工具

治理记录写回约定

所有治理记录统一写入项目根目录的 .governance/ 目录：

与其他规则文件的关系

• core/lifecycle.md：阶段模型、触发模式、治理规则的详细定义
• core/stage-gates.md：每个 Gate 的检查项、判定标准、通过条件
• core/profiles.md：lightweight/standard/strict 三种 profile 的阶段范围和 Gate 强度
• core/onboarding.md：项目中途接入的协议和最小路径
• references/interaction-boundary.md：agent 自主决策 vs 需用户确认的边界规则
• TOOLS.md：所有可复用工具的目录和触发条件