Sync: expand ui system components notes

wiki/sources/compliance-auditor.md

@@ -0,0 +1,60 @@
+---
+title: "Compliance Auditor Agent"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/compliance-auditor.md]]
+
+## Summary（用中文描述）
+- 核心主题：专业 AI Agent，专注于 SOC 2、ISO 27001、HIPAA、PCI-DSS 等安全隐私认证审计的全流程指导——从准备评估到证据收集直至认证通过。
+- 问题域：组织如何系统性地通过合规认证，避免"打勾式合规"（checkbox compliance），确保控制措施真正落地而非仅存在于文档中。
+- 方法/机制：五步工作流（Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance）；强调自动化证据收集、右置控制项设计、以审计员视角反向思考。
+- 结论/价值：合规项目应与公司规模和实际风险匹配；技术控制优于管理控制；证据必须证明控制在整个审计周期内持续有效，而非仅存在于当下。
+
+## Key Claims（用中文描述）
+- 不被遵守的政策比没有政策更危险——它制造虚假信心，增加审计风险。
+- 自动化证据收集从第一天就应建立——手动流程无法扩展。
+- 使用通用控制框架（common control framework）可一个控制集满足多个认证标准。
+- 技术控制优于管理控制——代码比培训更可靠。
+- 审计边界（scope）必须清晰定义，明确包含和排除的范围。
+- 例外情况（exceptions）需要完整文档：谁批准、为什么、有何时效、有何补偿控制。
+
+## Key Quotes
+> "A policy nobody follows is worse than no policy — it creates false confidence and audit risk."
+> — 核心原则：不follow的政策比没政策更危险
+
+> "Evidence must prove the control operated effectively over the audit period, not just that it exists today."
+> — 证据的核心要求：证明整个审计周期内持续有效
+
+> "Think like the auditor: what would you test? what evidence would you request?"
+> — 审计员心态：反向思考，模拟审计师会问什么
+
+## Key Concepts
+- [[Checkbox-Compliance]]：仅在文档层面满足合规要求，控制实际未落地或未被测试——文档中的反面案例。
+- [[Continuous-Compliance]]：持续合规——在两次年度审计之间建立自动化证据收集管道和季度控制测试机制，而非年度突击准备。
+- [[Common-Control-Framework]]：通用控制框架——设计一组控制项同时满足多个认证标准（如 SOC 2 + ISO 27001），避免重复工作。
+- [[Technical-Controls-Vs-Administrative-Controls]]：技术控制（如 IAM 策略、代码审计）优于管理控制（如培训、签到表），因为代码比人的行为更可靠。
+- [[Compensating-Control]]：补偿控制——当某项控制无法直接满足时，用于降低风险的替代措施；需完整记录批准人、原因和有效期。
+- [[Evidence-Collection-Matrix]]：证据收集矩阵——以控制目标（而非内部团队结构）组织证据的结构化文档，列出控制ID、证据类型、来源、收集方式和频率。
+
+## Key Entities
+- [[SOC-2]]：安全、可用性、处理完整性、机密性、隐私五大信任服务标准（Trust Service Criteria），最常见的云服务安全认证。
+- [[ISO-27001]]：国际信息安全管理标准，提供系统化的风险管理方法。
+- [[HIPAA]]：美国医疗信息隐私法规，涵盖 PHI（受保护健康信息）的保护要求。
+- [[PCI-DSS]]：支付卡行业数据安全标准，适用于处理信用卡信息的组织。
+
+## Connections
+- [[specialized-model-qa]] ← extends ← [[compliance-auditor]]：Model QA 关注 ML 模型质量，Compliance Auditor 关注整体安全控制——两者在模型部署合规证据收集上存在交叉。
+- [[automation-governance-architect]] ← depends_on ← [[compliance-auditor]]：合规审计所需的自动化证据收集需依托 Governance Architect 设计的 AI 系统治理框架。
+- [[CTP-Topic-52-3-Lines-of-Defence]] ← extends ← [[compliance-auditor]]：三道防线模型（业务管理 / 风险职能 / 内部审计）与合规审计的职责划分高度对应。
+- [[DevSecOps]] ← extends ← [[compliance-auditor]]：DevSecOps 将安全控制集成到 CI/CD 流水线中，是合规 Auditor 推荐的技术控制实现方式。
+
+## Contradictions
+- 与 [[specialized-model-qa]] 的侧重点差异：
+  - 冲突点：Compliance Auditor 关注组织级控制（access control, incident response），Model QA 关注模型本身的质量与统计特性，两者对"证据"的定义不同。
+  - 当前观点：合规证据以控制操作日志、策略文档、访问审查记录为主。
+  - 对方观点：模型证据以 PSI、校准曲线、SHAP 值等统计指标为主。
+  - 协调建议：两者可互补——Compliance Auditor 负责整体安全框架，Model QA 负责嵌入其中的 AI/ML 模型专项审计。

wiki/sources/specialized-mcp-builder.md

@@ -0,0 +1,55 @@
+---
+title: "MCP Builder Agent"
+type: source
+tags: ["agent-personality", "mcp", "tool-design", "ai-integration"]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/specialized-mcp-builder.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 的 MCP（Model Context Protocol）服务器开发专家——设计、构建、测试和部署 MCP 服务器，为 AI Agent 提供自定义工具、资源和提示词能力
+- 问题域：如何让 AI Agent 能够可靠地调用外部工具和 API，同时保持开发者体验（Developer Experience）
+- 方法/机制：遵循 MCP SDK 规范（TypeScript/Zod、Python/Pydantic），设计 Agent 友好的工具接口，提供 Resources（资源）、Tools（工具）、Prompts（提示词模板）三种扩展方式，通过真实 Agent 测试验证可用性
+- 结论/价值：工具命名和描述是 Agent 能否正确选用的关键；每个工具调用必须独立无状态；错误必须返回结构化消息而非堆栈跟踪
+
+## Key Claims（用中文描述）
+- **描述性工具命名** → Agent 能从名称推断用途，正确选用率 >90%
+- **类型化参数验证（Zod/Pydantic）** → 边界层拦截非法输入，防止外部 API 污染
+- **结构化错误返回（isError: true）** → Agent 知道何时重试或请求用户，而非虚构响应
+- **无状态工具设计** → 每次调用独立，不依赖调用顺序，确保分布式环境稳定
+- **真实 Agent 测试循环** → 通过完整调用链路验证，而非仅靠单元测试
+- **环境变量密钥管理** → API Key 和 Token 从环境变量读取，绝不硬编码
+
+## Key Quotes
+> "If an agent can't figure out how to use your tool from the name and description alone, it's not ready to ship." — MCP Builder 核心理念
+> "A tool that passes unit tests but confuses the agent is broken." — 测试理念，强调必须验证 Agent 的完整调用路径
+> "We return `isError: true` here so the agent knows to retry or ask the user, instead of hallucinating a response." — 错误处理设计哲学
+
+## Key Concepts
+- [[Model Context Protocol (MCP)]]：Anthropic 提出的 AI Agent 与外部工具/数据源交互的标准化协议
+- [[MCP Server]]：基于 MCP 协议的服务端实现，暴露 Tools/Resources/Prompts 给 Agent
+- [[Tool Interface Design]]：为 Agent 设计友好工具接口的实践，关注命名、描述、参数类型和返回结构
+- [[Zod Validation]]：TypeScript 端的参数模式定义和验证库，用于 MCP TypeScript 服务器
+- [[Pydantic Validation]]：Python 端的参数模式定义和验证库，用于 MCP Python (FastMCP) 服务器
+- [[Stdio Transport]]：MCP 标准传输方式，适用于本地 CLI 集成和桌面 Agent
+- [[SSE Transport]]：Server-Sent Events 传输方式，适用于基于 Web 的 Agent 接口和远程访问
+- [[Streamable HTTP]]：可扩展云部署的 HTTP 流式传输，支持无状态请求处理
+- [[Stateless Tool Design]]：无状态工具设计原则，确保每次调用独立、幂等、可分布式运行
+- [[Structured Error Response]]：返回 `isError: true` 结构化错误消息，而非堆栈跟踪
+
+## Key Entities
+- [[@modelcontextprotocol/sdk]]：Anthropic 官方 MCP TypeScript SDK，提供 McpServer、StdioServerTransport 等核心类
+- [[FastMCP]]：Python MCP 服务器框架，基于 Pydantic 的类型验证
+- [[Zod]]：TypeScript schema 声明和验证库，MCP TypeScript SDK 内置支持
+- [[Pydantic]]：Python 数据验证库，FastMCP 的核心依赖
+
+## Connections
+- [[MCP Builder Agent]] ← implements ← [[Model Context Protocol (MCP)]]
+- [[MCP Builder Agent]] ← uses ← [[@modelcontextprotocol/sdk]]
+- [[MCP Builder Agent]] ← uses ← [[FastMCP]]
+- [[LSP/Index Engineer Agent Personality]] ← shares_tool_design_philosophy_with ← [[MCP Builder Agent]]
+
+## Contradictions
+- 暂无发现与其他 Wiki 页面的冲突

wiki/sources/specialized-salesforce-architect.md

@@ -0,0 +1,56 @@
+---
+title: "Specialized Salesforce Architect"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/specialized-salesforce-architect.md]]
+
+## Summary（用中文描述）
+- 核心主题：Salesforce 平台企业级解决方案架构师 Agent — 多云架构设计、企业集成模式、技术治理
+- 问题域：Salesforce 组织从试点到企业规模扩展过程中的架构设计、技术债务规避、governor limits 规划
+- 方法/机制：ADR（架构决策记录）、Governor Limit Budget 追踪、Integration Pattern Template、数据模型审查清单
+- 结论/价值：提供从发现评估 → 架构设计 → 实施指导 → 审查治理的完整工作流，强调 declarative-first 原则和 bulkification 强制性要求
+
+## Key Claims（用中文描述）
+- Governor limits 是不可协商的铁律，每项设计必须提前计入 SOQL(100)、DML(150)、CPU(同步10s/异步60s)、堆(同步6MB/异步12MB) 等限制
+- 业务逻辑必须放在 Handler 类中，Trigger 只负责委托分发，且每个对象只允许一个 Trigger
+- Bulkification 是强制要求 — 若代码在 200 条记录下失败，则该代码就是错误的
+- Declarative first，代码第二：优先使用 Flows、公式字段和验证规则，只在 declarative 方案变得不可维护时才考虑 Apex
+- 集成模式必须处理失败场景：每次外部调用都需要重试逻辑、断路器和死信队列
+- 数据模型是基础：在生产上线后再改数据模型，成本是设计阶段的 10 倍
+- PII 数据必须加密存储，使用 Shield Platform Encryption 或自定义加密方案
+
+## Key Quotes
+> "Governor limits are non-negotiable. Every design must account for SOQL (100), DML (150), CPU (10s sync/60s async), heap (6MB sync/12MB async). No exceptions, no 'we'll optimize later.'" — 核心设计原则
+> "If the code would fail on 200 records, it's wrong." — Bulkification 强制性标准
+> "Data model is the foundation. Changing the data model after go-live is 10x more expensive." — 数据模型优先级
+> "Be direct about technical debt. If someone built a trigger that should be a flow, say so." — 沟通风格示例
+
+## Key Concepts
+- [[GovernorLimits]]：Salesforce 平台执行上下文的硬性资源限制，包括 SOQL 查询数(100)、DML 语句数(150)、CPU 时间(同步10s)、堆大小(同步6MB)等
+- [[Bulkification]]：批量处理模式 — 要求所有触发器和 Apex 代码必须能在单次交易中处理多条记录（通常按 200 条/批次测试）
+- [[PlatformEvents]]：Salesforce 平台事件 — 用于跨系统集成的异步事件驱动机制，支持 72 小时重放窗口和高容量标准（10万/天）
+- [[ChangeDataCapture]]（CDC）：变更数据捕获 — 自动追踪 sObject 字段级变更，适合 Salesforce 原生事件同步场景
+- [[ADR]]（Architecture Decision Record）：架构决策记录 — 文档化记录重要技术决策的上下文、备选方案、后果和复审日期
+- [[SalesforceDX]]：Salesforce 开发者体验框架 — 基于 Scratch Org 的源代码驱动部署方式，与 DevOps Center 并行
+- [[Agentforce]]：Salesforce AI Agent 框架 — Agent 在 Salesforce governor limits 内运行，需设计在 CPU/SOQL 预算内完成的动作，使用 Einstein Trust Layer 进行 PII 脱敏
+
+## Key Entities
+- [[MuleSoft]]：Salesforce 收购的企业级集成中间件，用于跨系统集成模式中的中间转换层（DataWeave 转换、3x 指数退避重试、死信队列）
+- [[ShieldPlatformEncryption]]：Salesforce 原生 PII 加密方案，与自定义加密并列作为敏感数据保护选项
+- [[DevOpsCenter]]：Salesforce 原生 CI/CD 平台，与 Salesforce DX 并行的另一种部署方式
+
+## Connections
+- [[SalesforceDX]] ← supports ← [[ADR]]
+- [[PlatformEvents]] ← extends ← [[ChangeDataCapture]]
+- [[Bulkification]] ← enforces ← [[GovernorLimits]]
+- [[Agentforce]] ← bounded_by ← [[GovernorLimits]]
+
+## Contradictions
+- 与 [[DevOpsCenter]] 关系：
+  - 冲突点：Salesforce DX 与 DevOps Center 是两种并行的部署策略，文档将两者并列但未明确优先选用哪个
+  - 当前观点：Salesforce DX 基于 Scratch Org 源码驱动是现代标准实践
+  - 对方观点：DevOps Center 作为 Salesforce 原生工具对非技术用户更友好