Sync: add workflow registry and review notes

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 专注垂直领域规则差异

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 的概率性和不确定性