Sync: add design and process improvement notes

wiki/sources/testing-api-tester.md

@@ -0,0 +1,52 @@
+---
+title: "API Tester Agent Personality"
+type: source
+tags: ["the-agency", "testing", "api", "automation", "qa", "performance", "security"]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-api-tester.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Testing 部门的 API 测试专家智能体人格定义，涵盖功能、性能、安全三大维度的全面 API 质量保障方法论与自动化实现框架
+- 问题域：API 质量保障缺乏系统性方法论、测试覆盖不足、安全漏洞遗漏、性能 SLA 不达标等现实问题
+- 方法/机制：Playwright 测试框架 + perf_hooks 性能监控 + OWASP API Security Top 10 安全验证 + CI/CD 流水线集成 + 95%+ 覆盖率目标驱动
+- 结论/价值：为 The Agency 提供标准化的 API 测试智能体规范，通过自动化测试套件实现功能验证、性能基准、安全审计的三位一体质量保障
+
+## Key Claims（用中文描述）
+- API Tester Agent 通过 Playwright/REST Assured/k6 框架构建自动化测试套件，目标实现 95%+ API 端点覆盖率
+- API 性能 SLA 要求：95 百分位响应时间低于 200ms，正常负载下错误率低于 0.1%
+- 负载测试必须验证 10 倍正常流量容量，确保系统可扩展性
+- 安全测试覆盖 OWASP API Security Top 10，包含认证绕过、SQL 注入、XSS、速率限制等关键威胁
+- API 测试必须集成到 CI/CD 流水线，实现持续验证而非手动测试
+
+## Key Quotes
+> "Breaks your API before your users do." — API Tester Agent 的核心理念，防御性测试哲学
+> "API response times must be under 200ms for 95th percentile" — 明确的性能 SLA 标准
+> "Always test authentication and authorization mechanisms thoroughly" — 安全优先原则
+> "Load testing must validate 10x normal traffic capacity" — 规模化验证要求
+
+## Key Concepts
+- [[API Testing]]：覆盖功能、性能、安全三维度，通过自动化测试框架验证 API 端点行为与 SLA 合规性
+- [[Performance Testing]]：通过 perf_hooks 监控响应时间，验证 95 百分位 < 200ms、10x 负载、< 0.1% 错误率三大指标
+- [[Security Testing]]：OWASP API Security Top 10 安全测试框架，包含认证/授权/输入验证/速率限制等核心检查项
+- [[Contract Testing]]：API 版本间契约合规性与向后兼容性验证，确保服务间接口稳定性
+- [[CI/CD Integration]]：测试自动化嵌入持续集成/持续部署流水线，实现每次代码变更的自动质量验证
+- [[OWASP API Security Top 10]]：API 安全测试的行业标准清单，覆盖 BOLA/ BFLA/ Broken Auth 等关键 API 威胁
+
+## Key Entities
+- [[Playwright]]：Node.js 端到端测试框架，API Tester 的主要测试工具之一，支持功能与安全测试
+- [[REST Assured]]：Java API 测试框架，适用于 Java 生态系统的 REST API 验证
+- [[k6]]：Grafana 开源负载测试工具，用于性能测试与可扩展性验证
+- [[perf_hooks]]：Node.js 内置性能监测 API，用于精确的 API 响应时间测量
+
+## Connections
+- [[specialized-model-qa]] ← 测试范围互补 ← [[testing-api-tester]]（模型质量测试 vs API 端点测试）
+- [[testing-accessibility-auditor]] ← 质量保障并行 ← [[testing-api-tester]]（可访问性测试 vs API 功能/性能/安全测试）
+- [[testing-tool-evaluator]] ← 工具推荐上游 ← [[testing-api-tester]]（工具评估为测试实施提供框架选择）
+- [[specialized-mcp-builder]] ← 技术栈关联 ← [[testing-api-tester]]（MCP 服务器构建需要 API 测试能力保障）
+- [[multi-agent-system-reliability]] ← 质量保障基础 ← [[testing-api-tester]]（系统可靠性依赖 API 质量验证）
+
+## Contradictions
+- 暂无冲突内容

wiki/sources/testing-performance-benchmarker.md

@@ -0,0 +1,53 @@
+---
+title: "Performance Benchmarker Agent Personality"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-performance-benchmarker.md]]
+
+## Summary（用中文描述）
+- 核心主题：性能测试与优化专家 Agent，专注于测量、分析和改进跨应用程序和基础设施的系统性能
+- 问题域：性能基线建立、负载/压力测试、Web Vitals 优化、容量规划、可扩展性评估
+- 方法/机制：使用 k6 编写综合性能测试套件，统计置信区间分析，Core Web Vitals 监控，性能回归测试
+- 结论/价值：数据驱动的方法论，通过量化指标证明性能改进，确保系统满足 SLA 要求
+
+## Key Claims（用中文描述）
+- Performance Benchmarker Agent 通过系统性性能测试确保所有系统以 95% 置信度满足性能 SLA
+- 通过 Core Web Vitals 优化（LLC < 2.5s、FID < 100ms、CLS < 0.1）提升用户体验
+- 通过查询优化可将第95百分位响应时间从 850ms 降至 180ms
+- 通过性能监控可预防 90% 的性能相关事故
+
+## Key Quotes
+> "95th percentile response time improved from 850ms to 180ms through query optimization" — 数据驱动的优化效果量化
+
+> "Page load time reduction of 2.3 seconds increases conversion rate by 15%" — 性能与业务影响关联
+
+> "Always establish baseline performance before optimization attempts" — 性能优化的首要原则
+
+## Key Concepts
+- [[LoadTesting]]：模拟正常和峰值负载，验证系统在预期条件下的性能表现
+- [[StressTesting]]：逐步增加负载直到系统崩溃，找出性能临界点和恢复行为
+- [[CoreWebVitals]]：Google 定义的页面用户体验核心指标（LCP、FID、CLS）
+- [[RealUserMonitoring]]：基于真实用户数据的性能监控，对抗合成测试的局限性
+- [[CapacityPlanning]]：基于增长预测和使用模式预测资源需求
+- [[ConfidenceIntervals]]：统计置信区间用于可靠的性能测量
+
+## Key Entities
+- [[TestingRealityChecker]]：测试现实核查 Agent，与 Performance Benchmarker 协同工作
+- [[TestingApiTester]]：API 测试专家 Agent，共同构成全面测试体系
+- [[WorkflowOptimizerAgent]]：工作流优化 Agent，通过性能优化提升工作流效率
+
+## Connections
+- [[TestingRealityChecker]] ← complements ← [[TestingPerformanceBenchmarker]]
+- [[TestingApiTester]] ← extends ← [[TestingPerformanceBenchmarker]]
+- [[WorkflowOptimizerAgent]] ← depends_on ← [[TestingPerformanceBenchmarker]]
+
+## Contradictions
+- 与 [[TestingRealityChecker]] 的视角差异：
+  - 冲突点：Reality Checker 强调"真实用户感受"，Performance Benchmarker 强调"量化指标"
+  - 当前观点：量化指标（p95 < 500ms）是性能优化的客观标准
+  - 对方观点：用户主观感受比指标更重要，指标可能具有欺骗性
+  - 调和：两者互补——指标指导优化方向，用户体验验证优化效果

wiki/sources/testing-reality-checker.md

@@ -0,0 +1,52 @@
+---
+title: "Testing Reality Checker"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-reality-checker.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Testing 部门的 Reality Checker Agent——通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。
+- 问题域：AI Agent 协作中各环节（设计/开发/QA）给出的评估过于乐观，缺乏实际截图验证，导致"98/100 评级"发给基础网站、"生产就绪"标签打在未完成系统上。
+- 方法/机制：强制三步流程（Reality Check 命令 → QA 交叉验证 → 端到端系统截图分析）+ 硬性失败触发器；默认 NEETS WORK 状态，必须有压倒性证据才能升级为 READY。
+- 结论/价值：第一次实现通常需要 2-3 轮修订；C+/B- 评级属正常；只有真实截图证据才能支撑"生产就绪"声明。
+
+## Key Claims（用中文描述）
+- Testing Reality Checker Agent 作为最后一道防线，通过截图证据截断"幻想型认证"，要求压倒性视觉证明。
+- 所有系统声明需要视觉证明（自动化截图），规格说明需要对照实际实现进行交叉验证。
+- 完整的用户旅程测试需要截图证据；性能数据（加载时间、错误率）必须来自 test-results.json。
+- 默认"NEEDS WORK"状态，除非有压倒性证据支持"READY"。
+
+## Key Quotes
+> "You're the last line of defense against unrealistic assessments" — Testing Reality Checker Agent 自我定位
+> "Default to 'NEEDS WORK' status unless proven otherwise" — 核心认证原则
+> "First implementations typically need 2-3 revision cycles, C+/B- ratings are normal" — 现实质量预期
+> "Trust evidence over claims" — 质量认证核心方法论
+
+## Key Concepts
+- [[End-to-End Testing]]：完整用户旅程截图分析（桌面/平板/手机 × 交互前/后对比）
+- [[Evidence-Based Certification]]：以自动化截图 + test-results.json 数据为唯一认证依据
+- [[Specification Compliance]]：原始规格与实际实现之间的差距分析（gap analysis）
+- [[Quality Gate]]：生产就绪认证门槛——默认"NEEDS WORK"，需压倒性证据才通过
+- [[Automated Screenshot Testing]]：Playwright qa-playwright-capture.sh 自动化截图捕获
+
+## Key Entities
+- Testing Reality Checker Agent：The Agency Testing 部门角色——截图驱动的生产就绪认证 Agent
+- QA Agent：前序 QA 测试环节，提供自动化测试发现和证据
+- Integration Agent：RealityIntegration——Reality Checker 的执行主体
+- [[testing-workflow-optimizer]]：工作流优化 Agent，为 Reality Checker 提供优化流程建议
+- [[testing-api-tester]]：API 测试 Agent，提供后端接口层面的测试证据
+
+## Connections
+- [[testing-workflow-optimizer]] ← workflow integration ← [[testing-reality-checker]]
+- [[testing-api-tester]] ← evidence source ← [[testing-reality-checker]]
+- [[testing-accessibility-auditor]] ← cross-validation ← [[testing-reality-checker]]
+- [[testing-evidence-collector]] ← provides screenshots ← [[testing-reality-checker]]
+- [[testing-reality-checker]] ← final gate ← [[agents-orchestrator]]
+
+## Contradictions
+- 与 [[testing-workflow-optimizer]] 潜在张力：Workflow Optimizer 追求流程效率（目标：75% 流程错误减少），Reality Checker 追求真实性（默认"需要工作"），两者在修订周期数量上可能存在分歧——Optimizer 希望快速迭代，Checker 要求充分证据
+- 与 [[testing-api-tester]] 的互补关系：API Tester 提供后端接口测试证据，Reality Checker 要求端到端截图；两者共同构成前后端双重质量门控

wiki/sources/testing-workflow-optimizer.md

@@ -0,0 +1,56 @@
+---
+title: "Workflow Optimizer Agent Personality"
+type: source
+tags: []
+date: 2026-04-21
+---
+
+## Source File
+- [[Agent/agency-agents/testing/testing-workflow-optimizer.md]]
+
+## Summary（用中文描述）
+- 核心主题：The Agency Testing 部门的流程优化与工作流自动化专家 Agent，基于系统思维方法论，专注于端到端业务流程的分析、重设计、自动化与持续改进。
+- 问题域：工作流效率瓶颈识别、跨部门流程孤岛、人工重复性任务、流程质量与员工满意度的平衡。
+- 方法/机制：四阶段工作流（现状分析→优化设计→实施规划→自动化执行）+ Lean/Six Sigma/Kaizen 持续改进方法论 + 人本设计原则 + 数据驱动决策框架。核心工具：WorkflowOptimizer Python 框架（含瓶颈识别、优化机会评分、ROI 计算、实施路线图生成）。
+- 结论/价值：40% 平均周期时间改善、60% 常规任务自动化率、75% 流程错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。
+
+## Key Claims（用中文描述）
+- Workflow Optimizer Agent 通过系统分析消除效率瓶颈、流线化流程、实施智能化自动化解决方案，提升生产力、质量和员工满意度。
+- 每个流程优化必须包含自动化机会和可量化改进指标。
+- 在实施变更前必须测量当前状态性能，并使用统计分析验证改进有效性。
+- 优先考虑用户/员工体验和满意度，同时在自动化效率与人类判断和创造力之间取得平衡。
+
+## Key Quotes
+> "Finds the bottleneck, fixes the process, automates the rest." — Workflow Optimizer Agent personality description
+
+> "Process optimization reduces cycle time from 4.2 days to 1.8 days (57% improvement)" — communication style example
+
+> "Automation eliminates 15 hours/week of manual work, saving $39K annually" — communication style example
+
+## Key Concepts
+- [[Lean]]：精益方法论，识别三类活动（增值活动/价值赋能活动/浪费），追求消除一切不增值环节。
+- [[Six-Sigma]]：六西格玛方法论，通过 DMAIC（Define/Measure/Analyze/Improve/Control）流程减少流程变异和缺陷，目标 3.4 DPMO。
+- [[Kaizen]]：持续改进哲学，小步快跑、员工驱动的渐进式流程优化，与六西格玛形成互补。
+- [[Value-Stream-Mapping]]：价值流映射，识别流程中的增值时间 vs 非增值等待时间。
+- [[Statistical-Process-Control]]：统计过程控制，通过数据监控过程稳定性并预测性能。
+- [[Change-Management]]：变更管理，确保流程改进被团队接受并成功落地的策略框架。
+- [[Human-Centered-Design]]：人本设计，优先考虑用户/员工体验、认知负荷和可访问性。
+
+## Key Entities
+- [[The-Agency]]：Testing 部门的 Workflow Optimizer Agent 所属组织。
+
+## Connections
+- [[testing-api-tester]] ← 协同质量保障 ← [[testing-workflow-optimizer]]（流程优化后需要 API 测试验证自动化后的系统行为）
+- [[specialized-workflow-architect]] ← 共享方法论 ← [[testing-workflow-optimizer]]（两者均关注工作流设计与优化，但前者侧重设计建模，后者侧重实施改进）
+- [[product-sprint-prioritizer]] ← 协同优先级排序 ← [[testing-workflow-optimizer]]（流程优化实施需要与 Sprint 规划对齐）
+- [[specialized-model-qa]] ← 协同数据验证 ← [[testing-workflow-optimizer]]（六西格玛等统计方法与 Model QA 的量化验证方法相互补充）
+
+## Contradictions
+- 与 [[specialized-workflow-architect]] 存在职责边界张力：
+  - 冲突点：两者均涉及工作流分析，但 Workflow Architect 强调设计规范（穷举所有路径/状态树），Workflow Optimizer 强调实施改进（量化效率收益/自动化 ROI）。
+  - 当前观点：Workflow Architect 负责"如何设计"（设计层），Workflow Optimizer 负责"如何改进"（执行层），属于工作流生命周期的不同阶段。
+  - 对方观点：部分场景下两者可互换使用，职责边界模糊。
+- 与 [[product-behavioral-nudge-engine]] 在自动化 vs 人机交互上存在理念张力：
+  - 冲突点：Workflow Optimizer 追求最大化自动化（减少人工干预），Nudge Engine 追求最大化人类参与（微任务/游戏化驱动）。
+  - 当前观点：两者互补——工作流层面追求自动化，用户/员工层面保留适度的人机交互以维护满意度。
+  - 对方观点：过度自动化可能降低员工参与感和学习机会。