Sync: add automation governance notes

wiki/sources/automation-governance-architect.md

@@ -0,0 +1,49 @@
+---
+title: "Automation Governance Architect"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[raw/Agent/agency-agents/specialized/automation-governance-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：企业自动化治理架构师，负责在实施前评估业务自动化的价值、风险和可维护性
+- 问题域：企业级工作流自动化决策、可靠性保障、审计追溯
+- 方法/机制：基于 n8n 的编排标准 + 四维决策框架（时间节省、数据关键性、外部依赖风险、可扩展性）
+- 结论/价值：通过治理优先的方式防止低价值或高风险自动化，推动高价值自动化的标准化落地
+
+## Key Claims（用中文描述）
+- 自动化决策必须基于价值而非技术可行性
+- 每个推荐必须包含降级方案和责任人
+- 生产级工作流必须包含显式错误分支、幂等性保护、安全重试和人工降级路径
+- 命名规范必须包含环境标识和版本号，避免模糊命名
+- 集成治理需明确数据来源权威（Source of Truth），未经明确不得接入
+
+## Key Quotes
+> "Do not approve automation only because it is technically possible." — 核心原则：技术可行不等于值得自动化
+> "No 'done' status without documentation and test evidence." — 完成标准：必须有文档和测试证据
+> "No integration is approved without source-of-truth clarity." — 集成前提：必须明确数据权威来源
+> "Prefer simple and robust over clever and fragile." — 架构偏好：简单健壮优于精巧脆弱
+
+## Key Concepts
+- [[AutomationGovernance]]：自动化治理 — 通过决策框架和标准对业务流程自动化进行事前评估、事中监控和事后审计的完整体系
+- [[N8nWorkflowStandard]]：n8n 工作流标准 — 包含触发、验证、规范化、业务逻辑、外部操作、结果验证、日志、错误分支、降级、状态回写10个强制步骤
+- [[DecisionFramework]]：决策框架 — 四维评估体系（时间节省、数据关键性、外部依赖风险、可扩展性），用于对自动化请求给出 APPROVE / APPROVE AS PILOT / PARTIAL AUTOMATION ONLY / DEFER / REJECT 五种裁决
+- [[ReliabilityBaseline]]：可靠性基线 — 每个重要工作流必须包含：错误分支、幂等性/重复保护、安全重试（带停止条件）、超时处理、告警/通知、人工降级路径
+- [[IntegrationGovernance]]：集成治理 — 每个接入系统需定义：角色与数据权威、认证方式、触发模型、字段映射、写回权限、速率限制、失败模式、负责人
+- [[ReAuditTriggers]]：重审计触发条件 — 当 API/Schema 变更、错误率上升、容量大幅增长、合规要求变更、反复出现人工修复时触发自动化重审计
+
+## Key Entities
+- [[N8n]]：n8n — 自动化治理架构师的首选编排工具，但治理规则本身是平台无关的
+
+## Connections
+- [[WorkflowArchitect]] ← relates_to ← [[AutomationGovernanceArchitect]]：两者都关注工作流设计与标准化，但 Workflow Architect 偏实现层面，Automation Governance Architect 偏治理决策层面
+- [[ComplianceAuditor]] ← overlaps ← [[AutomationGovernanceArchitect]]：合规审计与自动化治理在数据关键性和合规风险维度存在重叠
+
+## Contradictions
+- 与 [[WorkflowArchitect]] 可能的冲突：
+  - 冲突点：对于同一自动化请求，Workflow Architect 可能倾向快速实现，而 Automation Governance Architect 要求充分评估后方可实施
+  - 当前观点：治理优先，防止低价值/高风险自动化进入生产
+  - 对方观点：快速交付价值，通过迭代完善

wiki/sources/product-feedback-synthesizer.md

@@ -0,0 +1,50 @@
+---
+title: "Product Feedback Synthesizer Agent"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/product/product-feedback-synthesizer.md]]
+
+## Summary（用中文描述）
+- **核心主题**：产品反馈综合分析 Agent，专精于从多渠道收集、分析和综合用户反馈，提取可操作的产品洞察，并将定性反馈转化为定量优先级和战略建议。
+- **问题域**：用户反馈分散（调查/访谈/工单/评论/社交媒体）、情感分析、主题归类、优先级排序、产品路线图决策支持。
+- **方法/机制**：多渠道收集（主动+反应+被动+社区+竞争渠道）→ 数据清洗标准化 → NLP 情感分析 → 主题标签与优先级分类 → 质量保证审查 → 洞察综合（主题分析/统计相关/用户旅程/优先级评分/影响评估）。
+- **结论/价值**：将海量用户声音蒸馏为可量化的产品决策依据，通过 RICE/MoSCoW/Kano 等框架实现数据驱动的路线图优先级排序，目标 85% 综合反馈产生可衡量决策。
+
+## Key Claims（用中文描述）
+- **多 Agent 反馈处理**：通过多渠道收集策略（主动/反应/被动/社区/竞争渠道）实现反馈全覆盖，系统化处理从原始数据到可操作洞察的完整流水线。
+- **情感与满意度建模**：NLP 情感分析 + NPS/CSAT/CES 评分关联 + 预测建模，实现满意度趋势早期预警（90% 精度检测满意度下降）。
+- **优先级量化框架**：使用 RICE/MoSCoW/Kano 等多标准决策分析框架，将定性反馈转化为可排序的量化优先级。
+- **洞察驱动的商业价值**：目标 85% 综合反馈产生可衡量决策，NPS 提升 10+ 分，80% 反馈驱动功能成功率。
+
+## Key Quotes
+> "Distills a thousand user voices into the five things you need to build next." — Agent 核心价值主张
+
+## Key Concepts
+- [[NPS]]：Net Promoter Score，用户推荐意愿度量，与反馈洞察强相关
+- [[RICE]]：Feature request prioritization framework（Reach × Impact × Confidence / Effort）
+- [[MoSCoW]]：Must-have / Should-have / Could-have / Won't-have 优先级分类法
+- [[Kano]]：Kano Model，功能满意度与用户愉悦度关系模型
+- [[SentimentAnalysis]]：NLP 情感分析 + 情绪检测 + 满意度评分
+- [[UserJourneyMapping]]：用户旅程映射与痛点识别
+- [[ChurnPrediction]]：基于反馈模式的流失预测与满意度建模
+- [[VoC]]：Voice of Customer，原声客户，verbatim 分析与引语提取
+- [[FeedbackLoop]]：反馈闭环设计与持续改进流程
+
+## Key Entities
+- [[The-Agency]]：本 Agent 所属的多智能体框架，Product 部门专注于产品驱动的分析与管理 Agent
+
+## Connections
+- [[product-sprint-prioritizer]] ← extends ← [[product-feedback-synthesizer]]
+- [[product-trend-researcher]] ← depends_on ← [[product-feedback-synthesizer]]
+- [[product-manager]] ← uses ← [[product-feedback-synthesizer]]
+
+## Contradictions
+- 与 [[product-sprint-prioritizer]] 可能存在优先级框架差异：
+  - 冲突点：Sprint Prioritizer 可能侧重开发资源约束下的短期迭代优先级，Feedback Synthesizer 侧重基于用户价值的长期路线图优先级。
+  - 当前观点：Feedback Synthesizer 强调 RICE/Kano 等多维度价值评估应优先于开发约束。
+  - 对方观点：Sprint Prioritizer 强调实际开发资源和 Sprint 容量约束才是优先级决策的最终边界。
+  - 建议协调：在 Sprint Planning 层面优先使用 Sprint Prioritizer，在产品路线图规划层面优先使用 Feedback Synthesizer，两者互补而非替代。

wiki/sources/report-distribution-agent.md

@@ -0,0 +1,46 @@
+---
+title: "Report Distribution Agent"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[raw/Agent/agency-agents/specialized/report-distribution-agent.md]]
+
+## Summary（用中文描述）
+- 核心主题：销售报告自动分发 AI Agent，专为 STGCRM 系统设计
+- 问题域：企业销售团队需要按时、按区域将合并报告精准送达对应业务员和管理层
+- 方法/机制：基于区域参数路由 + SMTP 邮件发送 + 全程分发日志审计
+- 结论/价值：实现 99%+ 定时送达率，零错误区域分发，完全可追溯的分发历史
+
+## Key Claims（用中文描述）
+- Report Distribution Agent 通过区域路由确保每个业务员仅接收其负责区域的数据
+- 管理员和经理接收公司级汇总报告，而非区域明细
+- 每次分发尝试均记录状态（sent/failed）和时间戳，支撑合规审计
+- 每日报告于工作日 8:00 AM 发送，每周汇总于周一 7:00 AM 发送
+- 发送失败时记录错误并继续分发，不中断其他接收者
+
+## Key Quotes
+> "You are the Report Distribution Agent — a reliable communications coordinator who ensures the right reports reach the right people at the right time." — Agent 身份定义
+> "Territory-based routing: reps only receive reports for their assigned territory" — 核心路由规则
+> "Graceful failures: log errors per recipient, continue distributing to others" — 容错设计
+
+## Key Concepts
+- [[Territory Routing]]：基于销售区域参数进行路由分发，每个业务员仅接收其分配区域的数据报告
+- [[SMTP Transport]]：通过 SMTP 协议传输 HTML 格式邮件报告的底层技术机制
+- [[Audit Trail]]：分发日志记录，含接收人、区域、状态、时间戳，支持合规查询
+- [[Scheduled Distribution]]：定时任务触发机制（工作日 8:00 AM / 周一 7:00 AM），支持手动按需分发
+
+## Key Entities
+- [[Data Consolidation Agent]]：为 Report Distribution Agent 提供区域报告和公司汇总报告的数据来源
+- [[STGCRM]]：该 Agent 所服务的企业 CRM 系统品牌，提供区域分配数据和邮件路由规则
+
+## Connections
+- [[Data Consolidation Agent]] ← feeds_data ← [[Report Distribution Agent]]
+- [[Report Distribution Agent]] ← distributes_to ← [[Sales Representative]]
+- [[Report Distribution Agent]] ← audit_trail ← [[Compliance System]]
+
+## Contradictions
+- 与 [[Sales Data Extraction Agent]]：Sales Data Extraction Agent 负责原始销售数据提取，Report Distribution Agent 负责报告分发；两者在数据管道中为上下游关系，不存在冲突
+

wiki/sources/specialized-developer-advocate.md

@@ -0,0 +1,58 @@
+---
+title: "Specialized Developer Advocate"
+type: source
+tags: [agent, specialized, developer-relations, community, developer-experience]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/specialized-developer-advocate.md]]
+
+## Summary（用中文描述）
+- 核心主题：Developer Advocate Agent——The Agency Specialized 部门的开发者关系工程师，通过提升开发者体验（DX）、创建高质量技术内容、建立真实社区联系，将产品与外部开发者紧密连接，最终推动平台采用和商业价值增长。
+- 问题域：开发者关系（DevRel）、开发者体验优化、技术内容营销（区别于传统营销）、社区运营、产品反馈闭环。
+- 方法/机制：DX 工程审计（Time-to-First-Success）→ 技术内容创作（教程/演示/演讲提案）→ 社区运营（GitHub/Discord/Slack 响应、Hackathon、大使计划）→ 产品反馈闭环（月度 Voice of Developer 报告）。
+- 结论/价值：Authenticity（不 astroturf）是开发者关系唯一可持续的资产；DX 改善（错误信息/SDK）比内容创作影响更深远、更持久；开发者成功（Developer Success）≠ 营销。
+
+## Key Claims（用中文描述）
+- **开发者体验优先**：DX 改善（更好的错误信息、TypeScript 类型、SDK 修复）复合效应永远优于新内容发布；修复前 3 大 DX 问题再发布任何新教程。
+- **真实性是核心资产**：虚假社区参与（AstroTurf）会永久性摧毁开发者信任；保持技术准确性比发布空内容更重要。
+- **时间度量价值**：新开发者"首次成功调用 API"时间 ≤ 15 分钟；GitHub 问题工作日首响 ≤ 24 小时；教程完成率 ≥ 50%；开发者 NPS ≥ 8/10。
+- **内容先听后创**：先读过去 30 天所有 GitHub Issue（发现高频痛点）、搜索 Stack Overflow 最新提问（识别理解障碍）、审查社交媒体情绪（获取无过滤反馈），再创作有针对性的内容。
+- **产品反馈闭环**：将开发者声音量化（17 个 GitHub Issue + 4 个 Stack Overflow 问题 + 2 场大会 Q&A = 同一功能缺失的证据）带入产品规划会议。
+
+## Key Quotes
+> "You don't do marketing — you do developer success." — 开发者关系工程师的身份定位：Authentic 技术参与，而非商业推销
+> "DX improvements compound forever; a tutorial has a half-life." — DX 改善的持久价值 vs. 内容创作的时间衰减
+> "A tutorial with an active author gets 3x the trust." — 作者持续维护对内容可信度的放大效应
+> "Five people at KubeCon ask the same question — that means thousands more hit it silently." — 大会 Q&A 模式的大规模推断价值
+
+## Key Concepts
+- [[DeveloperExperienceEngineering]]：审计并改善"首次 API 调用时间"，构建示例应用、启动工具包和代码模板，量化 DX 质量。
+- [[TechnicalContentCreation]]：教程/博客/视频脚本/交互式演示（CodePen/CodeSandbox/Jupyter），内容先以最终效果开头而非"本教程将……"。
+- [[CommunityBuilding]]：GitHub/Stack Overflow/Discord/Slack 真诚技术响应；大使计划（Ambassador Program）；Hackathon/Office Hours。
+- [[ProductFeedbackLoop]]：将开发者痛点转化为可操作的产品需求（用户故事）；月度 Voice of Developer 报告。
+- [[DeveloperOnboardingAudit]]：DX 审计框架，分阶段（Discovery/Account Setup/First API Call）计时评分：🟢 <5min | 🟡 5-15min | 🔴 >15min。
+- [[AmbassadorProgram]]：分层次贡献者认可机制，与社区价值观一致的真实激励。
+- [[ContentStrategyAtScale]]：发现层（SEO 教程）→ 激活层（Quick Start）→ 留存层（高级指南）→ 倡导层（案例研究）的漏斗模型。
+- [[DeveloperNPS]]：开发者净推荐值，季度调查，目标 ≥ 8/10。
+
+## Key Entities
+- [[GitHub]]：开源社区核心阵地；Issue 响应质量是开发者信任的关键指标；响应时效目标：工作日 ≤ 24 小时。
+- [[StackOverflow]]：开发者问题解答平台；搜索平台名称按最新排序可发现理解障碍点；回答率目标：≥ 90%。
+- [[DiscordSlashSlack]]：实时社区沟通渠道；无过滤情绪分析来源；Office Hours 和 Hackathon 活动平台。
+- [[OpenTelemetry]]：社区健康指标监控（错误率、文档搜索成功率等）框架。
+- [[KubeCon]]：顶级开发者大会；5 人问同一问题 → 数千人无声遇到同样障碍的推断方法论。
+
+## Connections
+- [[automation-governance-architect]] ← informs ← [[ProductFeedbackLoop]]（产品反馈与治理评审互补）
+- [[specialized-mcp-builder]] ← depends_on ← [[DeveloperExperienceEngineering]]（MCP Builder 的 DX 改善依赖开发者体验工程原则）
+- [[design-ux-researcher]] ← informs ← [[DeveloperOnboardingAudit]]（UX 研究方法论应用于 DX 审计）
+- [[ContentStrategyAtScale]] ← supports ← [[ProductFeedbackLoop]]（内容策略放大产品反馈影响力）
+- [[CommunityBuilding]] ← depends_on ← [[DeveloperExperienceEngineering]]（社区健康依赖底层 DX 质量）
+
+## Contradictions
+- 与 [[specialized-workflow-architect]] 存在设计哲学张力：
+  - 冲突点：快速交付 vs. 质量保障。Developer Advocate 优先修复 DX 问题再发布内容（"修复前 3 大 DX 问题再发布任何新教程"）；Workflow Architect 优先快速交付功能。
+  - 当前观点：DX 改善复合效应优于快速内容发布，内容发布前必须有可运行的代码样本。
+  - 对方观点：快速迭代需要尽早发布并通过真实用户反馈迭代，内容质量可随时间改进。