Sync: add workflow registry and review notes

2026-04-25 08:02:41 +08:00
parent aa980f8da2
commit 3b6697df35
10 changed files with 741 additions and 1 deletions
--- a/wiki/concepts/Handoff-Contract.md
+++ b/wiki/concepts/Handoff-Contract.md
@@ -0,0 +1,39 @@
+---
+title: "Handoff Contract"
+type: concept
+tags: [workflow, system-integration, contract, reliability]
+last_updated: 2026-04-25
+---
+
+## Definition
+交接合同——两个系统、服务或 Agent 之间每次交接时必须明确定义的接口规范，确保交接的每个环节都有明确的成功/失败/超时约定，防止隐式假设导致级联故障。
+
+## Contract Elements（合同要素）
+
+```
+HANDOFF: [From] -> [To]
+  PAYLOAD:     { field: type, field: type, ... }
+  SUCCESS:     { field: type, ... }
+  FAILURE:     { error: string, code: string, retryable: bool }
+  TIMEOUT:     Xs — treated as FAILURE
+  ON FAILURE:  [recovery action]
+```
+
+### 字段说明
+
+| 字段 | 说明 |
+|------|------|
+| `PAYLOAD` | 交接时传递的数据结构，必须包含类型注解 |
+| `SUCCESS` | 成功时的返回数据结构 |
+| `FAILURE` | 失败时的标准错误格式（含错误码和可重试标识）|
+| `TIMEOUT` | 超时阈值，超时视为失败 |
+| `ON FAILURE` | 失败后的恢复动作（重试、清理、escalation）|
+
+## Why It Matters
+没有显式交接合同的工作流边界是最常见的故障来源：
+- 服务 A 假设服务 B 总是返回某个字段，但 B 偶尔不返回 → 静默故障
+- 超时值未约定，一方认为 5s 合理，另一方认为 30s 才够 → 不匹配
+- 失败后未约定恢复动作，部分场景重试有效，部分场景重试造成数据重复
+
+## Source
+- [[specialized-workflow-architect]]（Workflow Architect Agent）
--- a/wiki/concepts/Observable-States.md
+++ b/wiki/concepts/Observable-States.md
@@ -0,0 +1,30 @@
+---
+title: "Observable States"
+type: concept
+tags: [workflow, observability, system-modeling]
+last_updated: 2026-04-25
+---
+
+## Definition
+可观察状态——每个工作流状态（快乐路径中的每一步 + 每个失败模式）必须同时从四个视角描述系统当前状态，确保客户、运维、数据库和日志各方都能准确感知系统发生了什么。
+
+## Four Dimensions（四维度）
+
+| 维度 | 描述 | 示例 |
+|------|------|------|
+| **Customer View** | 当前客户在 UI 上看到什么 | 加载中 / "处理中..." / 空白 / 错误提示 |
+| **Operator View** | 运维/管理员在管理面板看到什么 | 实体处于"处理中"状态 / 任务步骤显示 "step_3_running" |
+| **Database View** | 数据库中数据当前状态 | `job.status = "running"`, `job.current_step = "step_1"` |
+| **Log View** | 系统日志当前记录了什么 | `[order-service] step 1 started entity_id=abc123` |
+
+## Why Four Dimensions?
+单一视角不足以支撑调试和运维：
+- **只有 Customer View**：运维无法知道后台发生了什么
+- **只有 Database View**：客户不知道自己看到了什么
+- **只有 Log View**：没有结构化数据支撑告警和审计
+- **只有 Operator View**：缺乏原始数据记录
+
+四个维度必须同步更新、互相印证，构成完整的可观测性闭环。
+
+## Source
+- [[specialized-workflow-architect]]（Workflow Architect Agent）
--- a/wiki/concepts/Workflow-Registry.md
+++ b/wiki/concepts/Workflow-Registry.md
@@ -0,0 +1,44 @@
+---
+title: "Workflow Registry"
+type: concept
+tags: [workflow, documentation, system-modeling]
+last_updated: 2026-04-25
+---
+
+## Definition
+工作流注册表——系统所有工作流的权威参考指南，以四个交叉索引视角组织，确保任何角色（工程师、运维、产品负责人、AI Agent）都能从任意角度快速查找所需工作流。
+
+## Four Views（四视角）
+
+### View 1: By Workflow（按工作流，主列表）
+| 字段 | 说明 |
+|------|------|
+| Workflow | 工作流名称 |
+| Spec file | 规范文件名 |
+| Status | Approved / Review / Draft / **Missing** / Deprecated |
+| Trigger | 触发条件 |
+| Primary actor | 主要执行者 |
+| Last reviewed | 最近审查日期 |
+
+> **Missing** = 代码中存在但无规范，红色警报，立即暴露。
+
+### View 2: By Component（按组件）
+每个代码组件映射到其参与的所有工作流。工程师查看任意文件时，可立即知道哪些工作流涉及该文件。
+
+### View 3: By User Journey（按用户旅程）
+每条用户旅程映射到其背后的底层工作流，含客户旅程/运营旅程/系统间旅程。
+
+### View 4: By State（按状态）
+每个实体状态映射到能转入或转出的工作流。
+
+## Maintenance Rules
+- 每发现或规范一个新工作流必须更新注册表（强制）
+- Missing 状态的工作流视为红色警报，需在下一轮审查中处理
+- 四个视角必须交叉引用一致
+- Draft 升为 Approved 时必须同步更新注册表
+- 永不删除行——使用 Deprecated 而非删除以保留历史
+
+## Related
+- [[Workflow-Tree-Spec]]（规范格式）
+- [[Discovery-Audit]]（发现隐式工作流的方法）
+- [[Observable-States]]（每个工作流状态的可见性）
--- a/wiki/concepts/Workflow-Tree-Spec.md
+++ b/wiki/concepts/Workflow-Tree-Spec.md
@@ -0,0 +1,45 @@
+---
+title: "Workflow Tree Spec"
+type: concept
+tags: [workflow, specification, documentation, quality-assurance]
+last_updated: 2026-04-25
+---
+
+## Definition
+工作流树规范格式——为每个工作流生成的结构化规范文档，工程师可直接依据实现，QA 可直接导出测试用例，运维可理解系统行为，产品负责人可验证需求是否满足。
+
+## Required Sections（必须章节）
+
+1. **Overview**：2-3 句话描述工作流目标、触发者和产出
+2. **Actors**：参与此工作流的所有角色（人/系统/Agent）
+3. **Prerequisites**：工作流启动前必须满足的条件
+4. **Trigger**：触发来源（用户操作/API调用/定时任务/事件）
+5. **Workflow Tree**：每步的 Actor/Action/Timeout/Input/Output on SUCCESS/Output on FAILURE + Observable States
+6. **ABORT_CLEANUP**：失败清理流程（含触发条件、清理动作顺序、客户视图、运维视图）
+7. **State Transitions**：状态机转换图
+8. **Handoff Contracts**：每个系统边界的交接合同
+9. **Cleanup Inventory**：工作流创建的所有资源及其销毁方法
+10. **Reality Checker Findings**：规范与代码对照验证结果
+11. **Test Cases**：每个分支对应一个测试用例
+12. **Assumptions**：所有未经代码验证的假设
+13. **Open Questions**：待确认事项
+
+## Branch Coverage（分支覆盖要求）
+每个工作流规范必须覆盖 **7 类分支**：
+1. 快乐路径（所有步骤成功，所有输入有效）
+2. 输入验证失败（具体错误信息 + 客户看到什么）
+3. 超时失败（每个步骤的超时值 + 超时后行为）
+4. 瞬态失败（网络抖动/限流，可重试并退避）
+5. 永久失败（无效输入/配额超限，立即失败并清理）
+6. 部分失败（步骤7/12失败，已创建资源必须销毁）
+7. 并发冲突（同一资源同时被创建/修改）
+
+## Status Lifecycle
+```
+Draft → Review → Approved
+           ↑
+    Reality Checker 验证（必须，不可跳过）
+```
+
+## Source
+- [[specialized-workflow-architect]]（Workflow Architect Agent）
--- a/wiki/index.md
+++ b/wiki/index.md
@@ -4,6 +4,7 @@
 - [Overview](overview.md) — living synthesis

 ## Sources
+- [2026-04-24] [Workflow Architect Agent Personality](sources/specialized-workflow-architect.md)
 - [2026-04-24] [Government Digital Presales Consultant](sources/government-digital-presales-consultant.md)
 - [2026-04-24] [Agentic Identity & Trust Architect](sources/agentic-identity-trust.md)
 - [2026-04-24] [Document Generator Agent](sources/specialized-document-generator.md)
@@ -412,7 +413,6 @@
 - [2026-04-20] [specialized-cultural-intelligence-strategist](sources/specialized-cultural-intelligence-strategist.md) — (expected: wiki/sources/specialized-cultural-intelligence-strategist.md — source missing)
 - [2026-04-20] [healthcare-marketing-compliance](sources/healthcare-marketing-compliance.md) — (expected: wiki/sources/healthcare-marketing-compliance.md — source missing)
 - [2026-04-20] [llm-wiki](sources/llm-wiki.md) — (expected: wiki/sources/llm-wiki.md — source missing)
- [2026-04-20] [specialized-workflow-architect](sources/specialized-workflow-architect.md) — (expected: wiki/sources/specialized-workflow-architect.md — source missing)
 - [2026-04-20] [baoyu-skills](sources/baoyu-skills.md) — (expected: wiki/sources/baoyu-skills.md — source missing)
 - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing)
 - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing)
@@ -1017,6 +1017,7 @@
 - [GPG-密钥验证](concepts/GPG-密钥验证.md)
 - [Green-Computing](concepts/Green-Computing.md)
 - [Hand-Tracking](concepts/Hand-Tracking.md)
+- [Handoff-Contract](concepts/Handoff-Contract.md)
 - [HCX](concepts/HCX.md)
 - [Headless-服务器](concepts/Headless-服务器.md)
 - [Heartbeat-Monitoring](concepts/Heartbeat-Monitoring.md)
@@ -1117,6 +1118,7 @@
 - [Nitro-System](concepts/Nitro-System.md)
 - [Normal-Change](concepts/Normal-Change.md)
 - [NVMe硬盘分区](concepts/NVMe硬盘分区.md)
+- [Observable-States](concepts/Observable-States.md)
 - [Obsidian-Agent-Client](concepts/Obsidian-Agent-Client.md)
 - [Obsidian-Bases](concepts/Obsidian-Bases.md)
 - [Obsidian-CLI](concepts/Obsidian-CLI.md)
@@ -1320,6 +1322,8 @@
 - [What-If-Simulation](concepts/What-If-Simulation.md)
 - [WinThemes](concepts/WinThemes.md)
 - [Workflow-Engineering](concepts/Workflow-Engineering.md)
+- [Workflow-Registry](concepts/Workflow-Registry.md)
+- [Workflow-Tree-Spec](concepts/Workflow-Tree-Spec.md)
 - [Workspace](concepts/Workspace.md)
 - [X11](concepts/X11.md)
 - [Xinchuang](concepts/Xinchuang.md)
--- a/wiki/log.md
+++ b/wiki/log.md
@@ -1,3 +1,12 @@
+## [2026-04-25] ingest | Workflow Architect Agent Personality
+- Source file: Agent/agency-agents/specialized/specialized-workflow-architect.md
+- Status: ✅ 成功摄入
+- Summary: Workflow Architect——The Agency Specialized 部门的工作流设计专家 Agent，负责在代码编写前穷举建模系统所有路径。核心交付物：四视角工作流注册表（按工作流/按组件/按用户旅程/按状态）+ 工作流树规范格式（覆盖快乐路径+七类失败分支）+ 交接合同（Handoff Contract）+ 清理清单（Cleanup Inventory）。关键原则：不只为快乐路径设计，每个系统边界定义显式交接合同，Reality Checker 验证是 Draft 升为 Approved 的前置条件。Agent 协作协议：Reality Checker 验证→Backend Architect 实现→API Tester 生成测试用例→DevOps Automator 验证清理顺序。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（确定性要求 vs LLM 概率性），已在 Contradictions 中记录。
+- Concepts created: [[Workflow-Registry]]（四视角工作流注册表）、[[Observable-States]]（四维度可观察状态）、[[Handoff-Contract]]（系统边界交接合同）、[[Workflow-Tree-Spec]]（结构化工作流树规范格式）
+- Entities created: （Backend Architect/Reality Checker/API Tester/DevOps Automator/Security Engineer 在当前 sources 中出现次数均 < 2，暂不创建 Entity 页面）
+- Source page: wiki/sources/specialized-workflow-architect.md
+- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目并修正日期。overview.md Specialized 部门新增 Workflow Architect 条目。Concept 页面创建前已做去重检查，Workflow-Engineering（已存在，定义侧重 AI 执行流程 vs 本文档侧重工作流规范格式）保留原页面，新增页面侧重建模规范维度。
+
 ## [2026-04-25] ingest | Agentic Identity & Trust Architect（补充摄入）
 - Source file: Agent/agency-agents/specialized/agentic-identity-trust.md
 - Status: ✅ 补充摄入（source page 已存在，本次补充 Concept 页面）
--- a/wiki/overview.md
+++ b/wiki/overview.md
@@ -687,6 +687,7 @@ Key concepts: [[Django ORM]], [[Django REST Framework]], [[Django Admin 定制]]

 **[[government-digital-presales-consultant]]**（Government Digital Presales Consultant）：The Agency Specialized 部门的政府数字化售前专家——面向中国ToG（政府）市场，专注于数字政府、智慧城市、一网统管、城市大脑等主流方向的全生命周期售前支持。核心能力：政策解读（数字中国/国家数据局政策信号提取：区分"鼓励探索"与"全面实施"的政策成熟度判断）、合规架构（等保2.0三级/商用密码评估/信创适配）、招投标全流程（需求调研→方案设计→POC验证→标书撰写→述标答辩→中标交接）。五步工作流配合技术方案模板、等保合规矩阵、投标检查清单、机会评估模板等交付物。关键原则：**技术方案必须以业务场景驱动**（"市民服务处理速度提升80%"而非"微服务架构"）；**等保/密评/信创是强制项而非加分项**；方案至少经过三轮迭代打磨。成功指标：中标率>40%、零废标、售前到交付偏差<10%。与 [[sales-engineer]]（通用售前）互补——后者覆盖企业级B2B市场，前者专精中国政府ToG市场特有的政策合规与采购流程；与 [[Digital-Government]]（数字政府）和 [[Smart-City]]（智慧城市）构成完整的政府信息化知识体系。属 The Agency Specialized 部门的垂直行业方向。

+|**[[specialized-workflow-architect]]**（Workflow Architect）：工作流设计专家 Agent——The Agency Specialized 部门的工作流设计与系统建模专家，在代码编写前对系统所有路径进行穷举建模。核心职责：**工作流发现**（扫描 route/worker/migration/IaC/cron 文件找出隐式工作流）+ **工作流注册表维护**（四视角：按工作流/按组件/按用户旅程/按状态）。核心交付物：**工作流树规范格式**（含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions），覆盖快乐路径+七类失败分支（输入验证/超时/瞬态/永久/部分失败/并发冲突）。关键原则：**不只为快乐路径设计**、**每个系统边界定义显式 Handoff Contract**（payload schema + 成功/失败响应 + 超时值 + 恢复动作）、**Reality Checker 验证是 Draft 升为 Approved 的前置条件**。Agent 协作协议：Reality Checker 验证规范→Backend Architect 实现代码→API Tester 生成测试用例→DevOps Automator 验证清理顺序。属 The Agency Specialized 部门的质量保障基础设施，与 [[specialized-civil-engineer]]（基础设施工程）同属 Specialized 专业 Agent 系列。
 ## Conflict Areas

 1. **Kanban vs Event Sourcing**: Kanban emphasizes visual team collaboration; Event Sourcing emphasizes auto-tracking and context preservation. **[[Project State Management]]**（事件驱动看板替代方案）vs 传统 PM 工具。核心差异：手动拖拽 vs 自然语言输入；静态快照 vs 全历史保留；无上下文 vs 完整决策链。**[[Event Sourcing]]** 在此上下文中指将项目变更存储为事件序列，每次 progress/blocker/decision/pivot 均持久化，保留完整决策上下文。
--- a/wiki/sources/healthcare-marketing-compliance.md
+++ b/wiki/sources/healthcare-marketing-compliance.md
@@ -0,0 +1,69 @@
+---
+title: "Healthcare Marketing Compliance Specialist"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/healthcare-marketing-compliance.md]]
+
+## Summary（用中文描述）
+- 核心主题：医疗营销合规专家 Agent，覆盖中国医疗健康领域（药品/医疗器械/医美/保健食品/互联网医疗）全品类营销合规
+- 问题域：医疗健康企业在品牌推广、内容营销、学术推广中的合规边界；平台内容审核规则；患者隐私保护
+- 方法/机制：以《广告法》《医疗广告管理办法》《互联网广告管理办法》为核心监管框架，建立"三级审查机制"（法务初审→合规复审→终审发布）；风险分级矩阵（Critical/High/Medium/Low）；违规应急响应流程（2小时下架→24小时报告→72小时审计）
+- 结论/价值：合规不是"堵营销"，而是"保护品牌"——一次违规处罚的代价远高于合规投入
+
+## Key Claims（用中文描述）
+- 医疗广告必须经省级卫生行政部门审查并取得《医疗广告审查证明》，否则不得发布——这是行政出发乃至刑事追责的底线
+- 处方药严禁在大众媒体（电视/广播/报纸/互联网）发布广告——任何隐性推广均面临严厉处罚
+- 保健食品不得声称具有治疗功能——这是行业内处罚最高频的违规原因
+- 医美广告不得制造"容貌焦虑"——2021年起市场监管总局执法力度显著加强
+- 患者健康数据属于《个人信息保护法》认定的"敏感个人信息"——违规最高罚款5000万元或上年度营收5%
+
+## Key Quotes
+> "医疗广告必须审查后方可发布——这是行政处罚乃至刑事追责的底线。" — 广告法第46条核心要求
+> "保健食品不得声称治病功能，必须标注'保健食品不是药物，不能替代药物治疗疾病'。" — 蓝帽子标识管理制度核心声明
+> "合规不是'堵营销'，而是'保护品牌'。一次违规处罚的代价远高于合规投入。" — Agent 核心合规文化理念
+> "医美日记类内容无论是否由用户'自愿'分享，平台和诊所均可被追究连带责任。" — 小红书医美合规红线
+
+## Key Concepts
+- [[Healthcare-Marketing-Compliance]]：医疗健康营销全品类（药品/器械/医美/保健食品/互联网医疗）合规框架
+- [[Medical-Advertisement-Review]]：《医疗广告审查证明》制度——广告发布前必须获得省级卫生行政部门审查
+- [[Three-Tier-Review-Mechanism]]：企业内部三级审查机制（法务初审→合规复审→终审发布）
+- [[OTC-Drug-Marketing]]：非处方药大众媒体广告规则——必须包含"请按照药品说明书或药师指导下使用"等咨询语句
+- [[Prescription-Drug-Restrictions]]：处方药大众媒体广告禁令——仅限在医药专业期刊发布
+- [[Medical-Device-Classification]]：医疗器械三类分级管理制度（I类备案/II类注册/III类严格审批）
+- [[Blue-Hat-Logo]]：保健食品"蓝帽子"注册标志——合法保健食品必须取得并展示
+- [[Appearance-Anxiety]]：容貌焦虑——医美广告2021年起明确禁止制造焦虑情绪的表述
+- [[Internet-Diagnosis-Treatment]]：互联网诊疗规范——初诊必须线下面诊，复诊限常见病/慢性病
+- [[Patient-Privacy-PIPL]]：《个人信息保护法》将个人健康医疗信息认定为敏感信息，须单独授权
+- [[Academic-Detailing]]：学术推广合规——医疗代表备案、会议赞助标准、医师讲课费规范
+- [[Platform-Content-Review]]：平台内容审核机制——抖音/小红书/微信各有行业准入标准和内容红线
+- [[Compliance-Risk-Matrix]]：医疗营销合规风险分级矩阵（Critical/High/Medium/Low + 处置建议）
+
+## Key Entities
+- [[NMPA]]（国家药品监督管理局）：负责药品/医疗器械注册审批及广告批准文号管理
+- [[SAMR]]（国家市场监督管理总局）：2021年发布《医疗美容广告执法指南》，主导医美合规整治
+- [[Haodf]]（好大夫在线）：互联网医疗平台——医师入驻资质审核、患者评价管理、图文/视频问诊标准
+- [[DXY]]（丁香园）：医师专业社区——健康科普内容专业审核机制、医师认证体系、商业合作与编辑独立性分离
+- [[WeDoctor]]（微医）：互联网医院牌照、在线处方流转、医保接入合规
+- [[JD-Health]]（京东健康）：在线售药资质、处方药审核流程、物流配送合规
+- [[Douyin]]（抖音）：医疗行业准入（须提交医疗机构执业许可证或药械资质）、认证医师标识、直播带货限制
+- [[Xiaohongshu]]（小红书）：2021年起大规模清理医美内容、白名单管理制度、蒲公英品牌合作平台合规要求
+- [[WeChat]]（视频号）：医疗机构公众号认证、朋友圈广告投放规范、小程序在线问诊/售药资质要求
+
+## Connections
+- [[Healthcare-Marketing-Compliance]] ← extends ← [[The-Agency]]（Specialized 部门）
+- [[Healthcare-Marketing-Compliance]] ← depends_on ← [[NMPA]]（监管机构）
+- [[Healthcare-Marketing-Compliance]] ← depends_on ← [[SAMR]]（执法机构）
+- [[Platform-Content-Review]] ← extends ← [[Healthcare-Marketing-Compliance]]
+- [[Patient-Privacy-PIPL]] ← depends_on ← [[Healthcare-Marketing-Compliance]]
+- [[Academic-Detailing]] ← extends ← [[Healthcare-Marketing-Compliance]]
+
+## Contradictions
+- 与 [[legal-compliance-checker]] 潜在冲突：
+  - 冲突点：通用法律合规 Agent 与医疗专项合规 Agent 的职责边界
+  - 当前观点：医疗营销合规具有高度专业化特征（广告法/药械注册/平台规则），通用法律合规工具无法覆盖
+  - 对方观点：合规 Agent 应具备跨行业通用合规框架，无需细分至医疗领域
+  - 解决方向：通用合规 Agent 负责数据隐私/合同合规等横向能力，医疗营销合规 Agent 专注垂直领域规则差异
--- a/wiki/sources/specialized-workflow-architect.md
+++ b/wiki/sources/specialized-workflow-architect.md
@@ -0,0 +1,58 @@
+---
+title: "Workflow Architect Agent Personality"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/specialized-workflow-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：Workflow Architect——工作流设计专家 Agent，负责在代码编写前对系统所有路径进行穷举建模与规范输出。
+- 问题域：隐式工作流（代码中存在但无规范）、分支缺失、故障恢复路径未定义、系统边界交接合同模糊、代码与规范漂移。
+- 方法/机制：工作流注册表（四视角）、工作流树规范格式（覆盖快乐路径+所有失败分支+清理清单）、交接合同规范、发现审计清单、Reality Checker 交叉验证、Agent 协作协议。
+- 结论/价值：工程师可依据规范实现、QA 可直接生成测试用例、运维可理解系统行为、成功指标为零孤岛资源/假设表持续缩减。
+
+## Key Claims（用中文描述）
+- 代码中存在但无规范的工作流是隐患——它会在无人了解其全貌时被修改并导致故障。
+- 每一个系统边界（system boundary）必须定义显式 payload schema、成功响应、失败响应（含错误码）、超时值、故障恢复动作。
+- 每个工作流必须覆盖七类分支：快乐路径、输入验证失败、超时失败、瞬态失败、永久失败、部分失败、并发冲突。
+- 工作流状态必须同时回答四个维度：客户看到什么、运维看到什么、数据库中有什么、日志中有什么。
+- Reality Checker 验证是规范从 Draft 升为 Approved 的前置条件，不可跳过。
+
+## Key Quotes
+> "I do not design for the happy path only." — Workflow Architect 核心原则
+
+> "A workflow that exists in code but not in a spec is a liability. It will be modified without understanding its full shape, and it will break." — 发现即记录，不问是否被要求
+
+> "Every step that depends on something else being already done is a potential race condition." — 命名时序假设
+
+## Key Concepts
+- [[Workflow-Registry]]：四视角交叉索引工作流注册表（按工作流/按组件/按用户旅程/按状态），维护所有工作流状态（Approved/Review/Draft/Missing/Deprecated）
+- [[Observable-States]]：每个工作流状态必须同时描述客户视图、运维视图、数据库视图、日志视图
+- [[Handoff-Contract]]：系统边界交接合同——定义显式 payload schema、成功/失败响应、超时值、恢复动作
+- [[Workflow-Tree-Spec]]：结构化工序树规范格式，含 Actor/Prerequisites/Trigger/Step 树/ABORT_CLEANUP/State Transitions/Cleanup Inventory/Test Cases/Assumptions
+- [[Cleanup-Inventory]]：完整资源销毁清单，每项资源必须有对应清理动作
+- [[Discovery-Audit]]：发现审计清单——扫描所有 route/worker/migration/IaC/cron/event-listener/webhook 文件找出隐式工作流
+- [[Reality-Checker]]：规范验证流程，由 Reality Checker Agent 将规范与实际代码对照，报告差距
+
+## Key Entities
+- [[Backend-Architect]]：工作流规范依赖 Backend Architect 实现具体代码；工作流揭示实现缺陷时向其发起修复协作
+- [[Reality-Checker]]：每次 draft 完成后、标记 Review 前必须执行的代码验证 Agent；报告 Reality Checker Findings
+- [[API-Tester]]：规范 Approved 后接收工作流规范，生成全部测试用例
+- [[DevOps-Automator]]：工作流揭示基础设施销毁顺序需求时协作；验证 IaC 销毁顺序是否符合规范
+- [[Security-Engineer]]：工作流涉及凭证/密钥/认证/外部 API 调用时必须发起安全审查
+
+## Connections
+- [[Reality-Checker]] ← verifies ← [[Workflow-Tree-Spec]]（规范 vs 代码差距验证）
+- [[Backend-Architect]] ← implements ← [[Workflow-Tree-Spec]]（实现具体代码）
+- [[API-Tester]] ← generates test cases from ← [[Workflow-Tree-Spec]]（从规范导出测试用例）
+- [[DevOps-Automator]] ← maintains ← [[Cleanup-Inventory]]（验证销毁顺序）
+- [[Security-Engineer]] ← reviews ← [[Handoff-Contract]]（凭证传递安全性审查）
+
+## Contradictions
+- 与 [[Designing-for-Agentic-AI]] 潜在冲突：
+  - 冲突点：工作流规范要求确定性（每个分支必须精确描述），而 LLM 本质为概率性模型
+  - 当前观点：LLM 相关行为（如自然语言理解）通过概率模型处理；工作流规范聚焦于确定性的业务流程与系统边界，而非 LLM 推理过程
+  - 对方观点：[[Designing-for-Agentic-AI]] 强调 LLM 的概率性和不确定性