Sync: add project management and xr notes

wiki/sources/project-management-experiment-tracker.md

@@ -0,0 +1,55 @@
+---
+title: "Experiment Tracker Agent Personality"
+type: source
+tags: ["agent", "project-management", "experimentation", "a-b-testing"]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/project-management/project-management-experiment-tracker.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 角色定义——Experiment Tracker（实验追踪专家），专注于实验设计、执行追踪与数据驱动决策的专家级项目经理
+- 问题域：产品迭代中的实验管理缺乏系统性、数据驱动决策缺乏科学严谨性、实验成功率低
+- 方法/机制：通过 A/B 测试、多变量实验、假设验证、Portfolio Management、统计功效分析实现科学化实验管理
+- 结论/价值：为 AI Agent 系统提供标准化的实验追踪角色定义，支撑数据驱动的产品迭代决策
+
+## Key Claims（用中文描述）
+- Experiment Tracker 通过严格的统计方法论和实验设计，系统管理 A/B 测试、功能实验和假设验证，确保 95% 置信度的数据驱动决策可靠性
+- Experiment Tracker 通过 Portfolio Management 协调多个并发实验，优化资源配置，每季度交付 15+ 实验，实验成功率达 70%
+- Experiment Tracker 提供实验设计文档模板和实验结果交付模板，标准化实验全生命周期管理流程
+- Experiment Tracker 通过多臂老虎机（Multi-armed Bandits）、贝叶斯分析、因果推断等高级统计技术，实现连续学习和最优实验决策
+- Experiment Tracker 通过机器学习模型 A/B 测试、个性化实验设计和预测建模，实现高级数据科学集成
+
+## Key Quotes
+> "Always calculate proper sample sizes before experiment launch" — 确保统计可靠性的基础要求
+> "95% of experiments reach statistical significance with proper sample sizes" — 实验成功标准
+> "Experiment velocity exceeds 15 experiments per quarter" — 实验吞吐量目标
+> "Zero experiment-related production incidents or user experience degradation" — 安全底线
+
+## Key Concepts
+- [[A/B-Testing]]：对照实验，通过控制组与变体组的比较验证假设
+- [[Statistical-Significance]]：统计显著性，95% 置信度为默认要求
+- [[Power-Analysis]]：统计功效分析，确保实验有足够样本量
+- [[Hypothesis-Validation]]：假设验证，通过实验数据验证产品假设
+- [[Experiment-Portfolio-Management]]：实验组合管理，优化多实验资源分配与优先级
+- [[Multi-Armed-Bandits]]：多臂老虎机，高级实验设计实现动态流量分配
+- [[Bayesian-Analysis]]：贝叶斯分析方法，支持连续学习与实时决策
+- [[Causal-Inference]]：因果推断技术，理解实验的真正效果
+
+## Key Entities
+- [[Project-Management-Experiment-Tracker]]：实验追踪专家 Agent 本身
+- [[Project-Management-Studio-Producer]]：受益于 Experiment Tracker 的实验数据，协调内容制作迭代
+- [[LaunchDarkly]]：Feature Flag 平台，支持 Experiment Tracker 的渐进放量与 A/B 测试
+
+## Connections
+- [[Project-Management-Studio-Operations]] ← coordinates_with ← [[Project-Management-Experiment-Tracker]]
+- [[Project-Management-Studio-Producer]] ← depends_on ← [[Project-Management-Experiment-Tracker]]
+- [[Project-Management-Jira-Workflow-Steward]] ← integrates_with ← [[Project-Management-Experiment-Tracker]]
+- [[Project-Management-Project-Shepherd]] ← leverages ← [[Project-Management-Experiment-Tracker]]
+
+## Contradictions
+- 与 [[Project-Management-Studio-Operations]] 潜在冲突：Studio Operations 强调内容制作流程的确定性，Experiment Tracker 依赖实验数据驱动，存在节奏冲突（快速实验 vs 稳定制作）
+  - 冲突点：决策依据（直觉/经验 vs 数据）
+  - 当前观点：数据驱动决策优先，实验验证后再规模化
+  - 对方观点：内容制作需保持节奏稳定，不能因等待实验结果而停滞

wiki/sources/project-management-jira-workflow-steward.md

@@ -0,0 +1,63 @@
+---
+title: "Jira Workflow Steward Agent Personality"
+type: source
+tags: ["project-management", "jira", "git-workflow", "delivery-traceability", "agent-personality"]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/project-management/project-management-jira-workflow-steward.md]]
+
+## Summary（用中文描述）
+- 核心主题：Jira Workflow Steward——软件交付可追溯性管理 Agent，通过 Jira-Git 全链路绑定，确保每一次代码变更都能从 Jira 任务追踪到分支、提交、PR 直至关线发布
+- 问题域：团队代码交付过程中分支命名混乱、提交信息不规范、PR 缺乏 ticket 上下文、发布链路不可审计等交付治理难题
+- 方法/机制：Jira Gate（Jira ID 强制前置检查）→ 分支策略（feature/bugfix/hotfix/release 分流）→ Gitmoji 规范提交 → PR 模板 → Commit Hook 自动化验证
+- 结论/价值：使代码交付可审查、可回滚、可审计，将 Jira-linked commits 定位为质量工具而非合规打勾
+
+## Key Claims（用中文描述）
+- Jira Task ID 是所有 Git 工作流输出的前提：分支名、提交信息、PR 标题均必须包含有效 Jira ID，无 ID 则停止工作流
+- 分支策略需遵循仓库意图：feature/bugfix 从 develop 分支；hotfix 从 main 分支；release 用于发布准备，各路径互不混淆
+- 提交信息遵循 `<Gitmoji> JIRA-ID: 简短描述` 格式，选择 Gitmoji 需参照官方 catalog（gitmoji.dev / carloscuesta/gitmoji）
+- PR 是 main、release/*、大型重构和关键基础设施变更的强制门控，任何合并均需经过 review
+- 秘密/凭证/客户数据严禁出现在分支名、提交信息、PR 标题或描述中
+- Jira-linked commits 的价值在于提升 review 上下文、代码结构、发布说明质量和事故溯源能力，而非仅为合规
+
+## Key Quotes
+> "If a change cannot be traced from Jira to branch to commit to pull request to release, you treat the workflow as incomplete." — 核心原则：可追溯性即质量
+> "Jira-linked commits as a quality tool, not just a compliance checkbox" — 提交绑定 Jira 的定位重塑：质量工具而非合规工具
+> "Protect repository clarity: the commit message should say what changed, not that you 'fixed stuff'." — 提交信息质量标准
+
+## Key Concepts
+- [[Jira-Git-Traceability]]：通过 Jira ID 将 Jira 任务、分支、提交、PR、发布五个环节串联为完整可追溯链路的实践
+- [[Atomic-Commit]]：每次提交仅包含一个逻辑变更，易于审查、回滚和溯源的提交粒度原则
+- [[Branch-Strategy]]：基于功能/缺陷/热修复/发布类型的分支分层管理模型（feature/bugfix/hotfix/release）
+- [[Gitmoji-Commit]]：使用标准化 Emoji 前缀标注提交类型的提交规范（✨ 新功能、🐛 缺陷修复、♻️ 重构等）
+- [[Jira-Gate]]：强制要求所有 Git 工作流输出必须携带有效 Jira Task ID 的门控机制，无 ID 则停止工作流
+- [[Pull-Request-Governance]]：通过 PR 模板、安全审查、风险记录保护分支合并质量的工作流规范
+- [[Delivery-Traceability]]：从需求到代码发布全链路的可重建、可审计交付记录体系
+
+## Key Entities
+- [[Gitmoji]]：标准化 Emoji 提交规范工具（来源：gitmoji.dev / carloscuesta/gitmoji）；Jira Workflow Steward 使用其作为提交类型的视觉标签
+- [[GitHub]]：PR 托管和分支策略执行平台；PR 模板和安全门控在此实现
+- [[Project-Management-Project-Shepherd]]：同为项目管理领域的 Agent；Project Shepherd 负责整体项目协调，Jira Workflow Steward 专注交付可追溯性，两者互补
+- [[Project-Management-Studio-Operations]]：同为 The Agency 项目管理层级中的 Agent；Studio Operations 负责运营流程，Jira Workflow Steward 负责技术交付链路
+
+## Connections
+- [[Jira-Gate]] ← 是 [[Delivery-Traceability]] 的第一步门控
+- [[Branch-Strategy]] ← 支撑 [[Jira-Git-Traceability]] 的分支层
+- [[Atomic-Commit]] ← 支撑 [[Jira-Git-Traceability]] 的提交层
+- [[Pull-Request-Governance]] ← 支撑 [[Jira-Git-Traceability]] 的审查层
+- [[Gitmoji-Commit]] ← 提供 [[Atomic-Commit]] 的标准化视觉表达
+- [[Project-Management-Project-Shepherd]] ← 上游协调者，提供 Jira 任务；[[Jira-Workflow-Steward]] 负责将任务转化为可追溯代码交付
+
+## Contradictions
+- 与 [[Project-Management-Project-Shepherd]] 在职责边界上存在互补但需协调的张力：
+  - 冲突点：Project Shepherd 生成 Jira 任务，Jira Workflow Steward 要求任务必须存在才能工作——两者均强调任务先行，但无主动对接机制
+  - 当前观点：Steward 严格 gate，要求任务 ID 前置；若缺失则停止工作流并请求补充
+  - 对方观点：Project Shepherd 可能期望 Agent 能自动创建或推断 Jira 任务 ID
+  - 建议协调：在 Project Shepherd 的工作流中增加 Jira 任务预创建步骤，确保交接给 Steward 时 ID 已就绪
+- 与 [[Project-Management-Studio-Producer]] 在交付粒度上存在层级差异：
+  - Studio Producer 关注组合级（Portfolio）ROI 和战略优先级，Jira Workflow Steward 关注原子级代码提交
+  - 当前观点：Steward 坚持每个 commit 对应一个 Jira ID，保持最小粒度可追溯
+  - 对方观点：Producer 可能在聚合分析时需要更高粒度的任务层级（Epic/Story vs Task）
+  - 无直接冲突，属不同抽象层级的关注点差异

wiki/sources/project-management-project-shepherd.md

@@ -0,0 +1,53 @@
+---
+title: "Project Shepherd Agent Personality"
+type: source
+tags: [project-management, agent, cross-functional, stakeholder-management, risk-mitigation]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/project-management/project-management-project-shepherd.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 项目管理人格——Project Shepherd，模拟跨职能项目协调专家，专注文档进度、对齐干系人、管理风险
+- 问题域：复杂项目的全生命周期管理，包括多团队/多部门协调、时间线规划、资源分配、干系人沟通
+- 方法/机制：四阶段工作流（项目启动→团队组建→执行监控→质量交付）、Project Charter 模板、Status Report 模板、风险缓解框架、干系人沟通策略
+- 结论/价值：提供一套完整的 AI Agent 项目管理人格定义，可直接用于 Multi-Agent 系统中的项目协调角色
+
+## Key Claims（用中文描述）
+- Project Shepherd Agent 通过四阶段工作流（启动→团队组建→执行→交付）驱动复杂项目按时、按范围、按预算完成
+- 通过 disciplined change control 限制范围蔓延，目标将范围蔓延控制在 10% 以下
+- 通过 proactive risk mitigation，目标实现 90% 的已识别风险在影响项目结果前被成功缓解
+- 通过透明沟通和诚实汇报维持干系人信任，即使在传递负面消息时也保持透明
+- 95% 项目按时交付、95% 干系人满意度 4.5/5 是核心成功指标
+
+## Key Quotes
+> "Never commit to unrealistic timelines to please stakeholders" — 绝不为了取悦干系人而承诺不现实的工期
+> "Provide honest, transparent reporting even when delivering difficult news" — 即便传递困难消息也提供诚实透明的汇报
+> "Escalate issues promptly with recommended solutions, not just problems" — 问题升级时必须附上建议的解决方案，而非仅提出问题
+
+## Key Concepts
+- [[CrossFunctionalProjectCoordination]]：跨职能项目协调——协调多个团队和部门完成复杂项目的能力
+- [[StakeholderAlignment]]：干系人对齐——通过沟通策略和透明汇报维持所有项目参与者的期望一致
+- [[RiskMitigationPlanning]]：风险缓解规划——在风险影响项目结果前主动识别、评估并制定应对策略
+- [[ChangeControl]]：变更控制——通过纪律化的范围管理控制项目范围蔓延（目标 < 10%）
+- [[ProjectCharter]]：项目章程——定义项目目标、范围、成功标准和治理结构的初始文档
+- [[WorkBreakdownStructure]]：工作分解结构（WBS）——将大型项目拆解为可管理的任务和依赖关系
+- [[CriticalPathAnalysis]]：关键路径分析——识别项目中最长的依赖链，确保关键里程碑按时完成
+- [[MatrixOrganization]]：矩阵式组织——在跨多条汇报线的组织结构中协调资源的能力
+
+## Key Entities
+- [[ProjectShepherd]]：AI Agent 项目管理人格定义，专职跨职能项目协调、时间线管理和干系人对齐
+- [[ProjectCharter]]（模板）：定义项目概览、干系人分析、资源需求和风险评估的文档模板
+- [[ProjectStatusReport]]（模板）：包含执行摘要、进度更新、问题风险和干系人行动的定期报告模板
+- [[ExecutiveSponsor]]：执行发起人——拥有决策权威和升级终点的干系人角色
+- [[CrossFunctionalProjectTeam]]：跨职能项目团队——由多个技能领域成员组成的核心项目团队
+
+## Connections
+- [[ProjectManagementStudioOperations]] ← extends ← [[ProjectShepherd]] — Studio Operations 是项目管理在创意制作场景的延伸
+- [[ProjectManagementSenior]] ← related_to ← [[ProjectShepherd]] — 两者都是项目管理者，但 Senior PM 侧重高级战略，Shepherd 侧重跨职能协调执行
+- [[AutonomousProjectManagement]] ← depends_on ← [[ProjectShepherd]] — 自主项目管理依赖 Shepherd 提供的工作流和模板框架
+- [[ProjectStateManagement]] ← related_to ← [[ProjectShepherd]] — 两者都涉及项目状态跟踪，但 State Management 偏向事件驱动替代看板的方法论
+
+## Contradictions
+- 无明显内容冲突。本文档与 [[ProjectManagementSenior]] 和 [[ProjectManagementStudioOperations]] 在项目管理层面上互补而非冲突，各有侧重领域。

wiki/sources/project-management-studio-operations.md

@@ -0,0 +1,54 @@
+---
+title: "Studio Operations Agent Personality"
+type: source
+tags: ["project-management", "agency-agents", "operations", "efficiency"]
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/project-management/project-management-studio-operations.md]]
+
+## Summary（用中文描述）
+- 核心主题：Studio Operations 智能体角色定义——一个专注于日常工作室运营效率、流程优化和资源协调的专业运营管理者
+- 问题域：工作室运营管理、流程标准化、资源调度、质量控制、持续改进
+- 方法/机制：通过标准操作程序（SOP）模板、运营效率报告模板、四步工作流（评估→协调→实施→监控）实现 95% 运营效率目标
+- 结论/价值：提供一套完整的工作室运营管理框架，涵盖流程优化、资源管理、团队支持、数字化转型和战略运营管理
+
+## Key Claims（用中文描述）
+- 通过标准操作程序和流程文档化，可实现 95% 运营效率（附带主动系统维护）
+- 流程优化可每周为所有团队节省 40 小时生产力时间
+- 新调度系统实施可将会议冲突减少 85%
+- 全面的供应商管理可降低运营成本 15%
+- 主动监控和维护可保持 99.5% 系统正常运行时间
+- 运营支持请求响应时间少于 2 小时
+- 团队满意度评分达到 4.5/5
+
+## Key Quotes
+> "You are **Studio Operations**, an expert operations manager who specializes in day-to-day studio efficiency, process optimization, and resource coordination." — 角色定义核心描述
+> "Ensure 95% operational efficiency with proactive system maintenance" — 默认运营效率要求
+> "Implemented new scheduling system reducing meeting conflicts by 85%" — 服务导向的运营成果示例
+> "99.5% system uptime maintained with proactive monitoring and maintenance" — 可靠性导向的运营成果示例
+
+## Key Concepts
+- [[Standard Operating Procedure]]：标准操作程序模板，包含概述、前提条件、分步程序、质量控制、文档记录五个部分
+- [[Operational Efficiency]]：运营效率，目标为 95%，通过主动系统维护实现
+- [[Resource Coordination]]：跨所有工作室活动的资源分配和调度协调
+- [[Continuous Improvement]]：持续改进文化，通过分析运营指标和实施流程自动化实现
+- [[Digital Transformation]]：数字化转型，使用现代工作流工具、集成平台和 AI 驱动的运营辅助
+- [[Vendor Management]]：供应商关系管理和成本优化
+
+## Key Entities
+- [[The Agency]]：工作室所属组织，Studio Operations 智能体为其提供全面运营支持
+
+## Connections
+- [[Project Management Senior]] ← related_to ← [[Studio Operations]]
+- [[Project Management Studio Producer]] ← related_to ← [[Studio Operations]]
+- [[Project Management Jira Workflow Steward]] ← related_to ← [[Studio Operations]]
+- [[Project Management Project Shepherd]] ← depends_on ← [[Studio Operations]]
+
+## Contradictions
+- 与 [[Project Management Senior]] 冲突：
+  - 冲突点：战略规划与日常运营的优先级
+  - 当前观点（Studio Operations）：强调流程优化和运营效率的日常执行
+  - 对方观点（Senior PM）：强调战略规划和项目组合管理
+  - 协调方式：Studio Operations 负责执行层面，Senior PM 负责战略层面，两者互补

wiki/sources/project-management-studio-producer.md

@@ -0,0 +1,52 @@
+---
+title: "Studio Producer Agent Personality"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/project-management/project-management-studio-producer.md]]
+
+## Summary（用中文描述）
+- **核心主题**：Studio Producer Agent——专注于高管级别创意与项目管理的高级战略领导者 Agent，属于 Agency 项目管理部门。核心职责：战略组合管理、创意愿景与商业目标对齐、跨职能团队协调。
+- **问题域**：多项目组合管理、资源分配优化、高管级利益相关者沟通、风险与财务管控、团队绩效管理。
+- **方法/机制**：Strategic Portfolio Plan 模板（四层项目分级）、Strategic Portfolio Review 模板（季度复盘）、四阶段工作流（战略规划→项目编排→领导力发展→绩效优化）、ROI + 按时交付双指标驱动。
+- **结论/价值**：AI Agent 角色定位为高管级战略领导者，要求 25% 组合 ROI + 95% 按时交付率，面向需要复杂创意项目管理的组织。
+
+## Key Claims（用中文描述）
+- **Studio Producer** 通过战略组合规划（Strategic Portfolio Plan）将创意愿景与商业目标对齐，在项目分级（Tier 1/2 + Innovation Pipeline）中平衡风险与创新
+- **Portfolio ROI ≥ 25% + 95% on-time delivery** 是该角色的核心成功指标，要求同时管理财务纪律与创意卓越
+- **四阶段工作流**（战略规划→项目编排→领导力发展→绩效优化）构成该 Agent 的标准运营框架
+- **利益相关者管理**是该角色的核心竞争力，涉及高管沟通、期望设定与战略投资获取
+- **团队绩效与保留率**是该 Agent 的间接成功指标，反映领导力发展的长期效果
+
+## Key Quotes
+> "Portfolio ROI consistently exceeds 25% with balanced risk across strategic initiatives" — 核心成功指标定义
+> "Our Q3 portfolio delivered 35% ROI while establishing market leadership in emerging AI applications" — 沟通风格示例：战略性启发
+> "Board presentation highlights our competitive advantages and 3-year strategic positioning" — 执行影响思维示例
+> "Creative excellence drove $5M revenue increase and strengthened our premium brand positioning" — 业务价值导向示例
+
+## Key Concepts
+- [[Strategic-Portfolio-Management]]：通过分级项目组合（Tier 1/2 + Innovation Pipeline）实现资源最优配置与商业目标对齐
+- [[Resource-Allocation]]：跨创意/技术资源的计划与分配，平衡短期交付与长期能力建设
+- [[Stakeholder-Alignment]]：高管级利益相关者关系管理与战略沟通，确保创意愿景与商业目标一致
+- [[Portfolio-ROI]]：组合层面的投资回报率优化，Studio Producer 要求 ≥ 25% ROI
+- [[Risk-Balancing]]：在创新实验与已验证方法之间管理风险敞口
+- [[Cross-Functional-Orchestration]]：协调跨职能团队形成与战略对齐，管理复杂相互依赖关系
+- [[Innovation-Pipeline]]：实验性项目的管理框架，设定学习目标而非短期回报
+
+## Key Entities
+- [[Project-Management-Studio-Operations]]：Studio Producer 的运营执行搭档，负责具体项目交付
+- [[Project-Manager-Senior]]：项目经理的高级版本，更侧重执行层面
+- [[Project-Management-Project-Shepherd]]：项目看护角色，关注项目生命周期跟进
+- [[Project-Management-Experiment-Tracker]]：实验跟踪角色，关注迭代与学习
+
+## Connections
+- [[Project-Management-Studio-Operations]] ← supports ← [[Project-Management-Studio-Producer]]（战略规划由 Producer 制定，Operations 负责落地执行）
+- [[Project-Management-Project-Shepherd]] ← coordinates_with ← [[Project-Management-Studio-Producer]]（项目看护与 Producer 的组合管理对齐）
+- [[Sales-Engineer]] ← interfaces_with ← [[Project-Management-Studio-Producer]]（售前赢单后转交 Producer 编排交付）
+
+## Contradictions
+- 与 [[Project-Management-Studio-Operations]] 的角色边界：张力存在于战略（Producer）与运营（Operations）之间的权责划分——Producer 偏向高管级战略视角，Operations 偏向执行层；两者需通过定期 Portfolio Review 对齐
+- 与传统 [[Project-Manager-Senior]] 的管理幅度：张力存在于管理广度——Producer 管理整个组合（Portfolio），而 Senior PM 通常管理单个项目；这是层级差异而非矛盾

wiki/sources/project-manager-senior.md

@@ -0,0 +1,50 @@
+---
+title: "Senior Project Manager Agent Personality"
+type: source
+tags: [agent, project-management, laravel, livewire, fluxui, scope-control]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/project-management/project-manager-senior.md]]
+
+## Summary（用中文描述）
+- 核心主题：AI Agent 项目经理（SeniorProjectManager）的人格定义与任务分解方法论
+- 问题域：Web 开发项目中需求规格到可执行任务的转化过程，以及如何避免范围蔓延（scope creep）
+- 方法/机制：读取 site-setup.md 规格文档 → 引用精确需求 → 拆解为 30-60 分钟粒度的任务列表 → 存储到 memory-bank
+- 结论/价值：提供一套结构化的 AI PM 工作流程，强调务实（realistic scope）、精确引用规格、开发者优先
+
+## Key Claims（用中文描述）
+- **Agent + 规格文件 + 精确引用 → 任务列表**：通过逐字引用规格文档中的原始需求来创建任务，避免主观添加功能
+- **Agent + 经验积累 + 模式库 → 持续改进**：从每个项目中学习，构建成功任务拆解的模式库
+- **Agent + 务实范围 + 基础实现 → 避免失败**：默认基础实现即可接受，优先完成功能而非打磨
+
+## Key Quotes
+> "Quote EXACT requirements (don't add luxury/premium features that aren't there)" — 规格引用原则，要求 Agent 不添加规格中未明确的功能
+> "Each task should be implementable by a developer in 30-60 minutes" — 任务粒度标准，保证任务可执行性
+> "Don't add 'luxury' or 'premium' requirements unless explicitly in spec" — 务实范围控制，防止范围蔓延
+> "No background processes in any commands - NEVER append `&`" — 技术约束，Agent 必须遵守的技术红线
+
+## Key Concepts
+- [[ScopeCreepPrevention]]：通过精确引用规格、限制基础实现、记录范围决策来防止项目范围蔓延
+- [[TaskDecomposition]]：将规格拆解为 30-60 分钟粒度的可执行任务，包含验收标准
+- [[AgenticProjectManagement]]：AI Agent 作为项目经理角色，通过记忆和经验积累持续改进任务创建流程
+- [[FluxUI]]：Laravel Livewire 生态的前端组件库，PM Agent 需了解其组件属性和约束
+- [[AcceptanceCriteria]]：每个任务必须包含可测试的验收标准
+
+## Key Entities
+- [[ProjectManagementJiraWorkflowSteward]]：同属项目管理体系，另一个专注于 Jira 工作流编排的 Agent
+- [[ProjectManagementProjectShepherd]]：同属项目管理体系，专注于项目全局把控的 Agent
+- [[ProjectManagementStudioOperations]]：同属项目管理体系，专注于工作室运营的 Agent
+
+## Connections
+- [[ProjectManagementJiraWorkflowSteward]] ← related_to ← [[ProjectManagerSenior]]
+- [[ProjectManagementProjectShepherd]] ← related_to ← [[ProjectManagerSenior]]
+- [[ProjectManagementStudioOperations]] ← related_to ← [[ProjectManagerSenior]]
+
+## Contradictions
+- 与 [[ProjectManagementProjectShepherd]] 可能的冲突：
+  - 冲突点：职责边界 — Project Shepherd 关注项目整体把控，Senior PM 关注任务拆解细节
+  - 当前观点：Senior PM 强调任务粒度控制和精确引用规格，务实处理基础功能
+  - 对方观点：Project Shepherd 可能更关注项目整体节奏和风险，需要更高层次的抽象
+  - 协调建议：Senior PM 产出任务列表供 Project Shepherd 调度，两者形成执行层与规划层的协作关系

wiki/sources/recruitment-specialist.md

@@ -0,0 +1,53 @@
+---
+title: "Recruitment Specialist Agent"
+type: source
+tags: []
+date: 2026-04-25
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/recruitment-specialist.md]]
+
+## Summary（用中文描述）
+- 核心主题：RecruitmentSpecialist 是一个专注于中国人力资源市场的招聘运营与人才获取专家 Agent，覆盖从人才吸引、入职到留任的全周期招聘引擎
+- 问题域：中国招聘平台运营、JD 优化、简历筛选、面试流程设计、校园招聘、猎头管理、劳动法合规、雇主品牌建设、入职管理、招聘数据分析
+- 方法/机制：多平台渠道运营（BOSS直聘、拉勾、猎聘、智联、前程无忧、脉脉、LinkedIn）、结构化面试（STAR 框架）、能力模型评估、ATS 系统集成、劳动法合规检查、招聘漏斗数据分析
+- 结论/价值：帮助企业建立高效、合规、数据驱动的全链路招聘系统，提升招聘ROI、缩短到岗周期、降低试用期流失率
+
+## Key Claims（用中文描述）
+- 通过多平台渠道精细化运营，可实现招聘ROI持续提升，每季度渠道成本趋于下降
+- 使用STAR行为面试框架和结构化评分卡，可提升面试评估准确性和一致性
+- 严格遵守中国劳动法（劳动合同法、就业促进法、个人信息保护法）可避免合规风险和赔偿损失
+- 数据驱动的招聘漏斗分析能识别瓶颈并持续优化各环节转化率
+- 候选人体验（NPS 80+）与 offer 接受率（85%+）高度相关
+
+## Key Quotes
+> "When candidates wait more than 5 days from application to first response, application conversion drops by 40%. We must keep initial response time under 48 hours." — 候选人响应时效对转化率的影响
+> "Boss Zhipin's cost per resume is one-third of Liepin's, but candidate quality for mid-to-senior roles is lower. I recommend using Boss for junior roles and Liepin for senior ones." — 招聘渠道ROI差异化建议
+> "If the probation period exceeds the statutory limit, the company must pay compensation based on the completed probation standard. This risk must be avoided." — 试用期合规风险警示
+
+## Key Concepts
+- [[RecruitmentFunnelAnalyzer]]：招聘漏斗分析器类，计算各环节转化率、渠道ROI、入职周期
+- [[STAR Framework]]：行为面试框架（Situation-Task-Action-Result），用于评估候选人具体行为
+- [[Structured Interview]]：结构化面试，使用标准化评分卡确保面试一致性和评估准确性
+- [[China Labor Law Compliance]]：中国劳动法合规，包括劳动合同法、试用期规定、五险一金、竞业限制、N+1 补偿等
+- [[Employer Brand Building]]：雇主品牌建设，通过短视频、内容营销、平台口碑管理提升对人才的吸引力
+- [[Onboarding SOP]]：标准化入职流程，从入职前7天到第一个月的完整 checklist
+
+## Key Entities
+- [[Boss Zhipin]]（BOSS直聘）：中国领先的直聊招聘平台，简历成本低，适合初级岗位
+- [[Lagou]]（拉勾网）：专注互联网/科技岗位的招聘平台，技能标签匹配算法
+- [[Liepin]]（猎聘网）：中高端猎头导向平台，适合资深岗位
+- [[Beisen]]（北森）：领先的HR SaaS，ATS 系统用于招聘流程管理
+- [[Moka]]（Moka智能招聘）：智能化 ATS 系统
+- [[Feishu Recruiting]]（飞书招聘）：字节跳动 Lark 的 HR 模块
+- [[STAR Method]]：行为面试评估方法论
+
+## Connections
+- [[Specialized Civil Engineer Agent]] ← 同一 Agent 体系下的专业 Agent
+- [[Sales Engineer Agent]] ← 同属专业 Agent 系列
+- [[HR Onboarding]] ← 入职管理是该 Agent 的核心功能模块
+- [[RecruitmentFunnelAnalyzer]] ← 内置于该 Agent 的数据分析工具
+
+## Contradictions
+- 暂无发现与现有 Wiki 页面的冲突内容

wiki/sources/specialized-civil-engineer.md

@@ -0,0 +1,52 @@
+---
+title: "Specialized Civil Engineer Agent"
+type: source
+tags: ["agent", "civil-engineering", "structural-design", "geotechnical", "building-codes"]
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/specialized/specialized-civil-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：面向 AI Agent 的土木与结构工程专家角色定义，涵盖全球设计标准体系、结构分析与岩土设计能力、建造文档合规全流程
+- 问题域：AI Agent 在建筑结构工程领域的专业化角色设计，涉及多国规范体系（Eurocode、ACI、AISC、ASCE、GB、IS、AIJ 等）的统一知识表示与任务执行框架
+- 方法/机制：通过结构化角色定义（身份记忆→核心使命→规范规则→交付物→工作流→高级能力）构建可执行的结构工程 Agent；提供钢梁/RC 梁/岩土计算示例作为能力基准
+- 结论/价值：产出安全、经济、可建造的结构设计，同时驾驭多管辖区域并发规范、多标准冲突解析、全生命周期碳评估等高级任务
+
+## Key Claims（用中文描述）
+- AI Agent 可通过规范引用驱动（"Per EN 1992-1-1 clause 6.2.3..."）的方式执行可验证的结构计算包
+- 多标准项目（IBC+Eurocode 混用等）中，Agent 可通过规范冲突识别→文档记录→保守优先→设计依据报告的流程提供可辩护的解决方案
+- 结构设计必须同时验证强度极限状态（ULS）和正常使用极限状态（SLS/挠度/振动），两者均满足方为合格
+- 岩土参数不得未经地勘报告或明确假设即行假定；沉降分析对差异沉降敏感结构为必做项
+
+## Key Quotes
+> "Always check **both** strength (ULS) and serviceability (SLS) limit states" — 强度与正常使用双重验证原则
+> "Default to the more conservative requirement unless AHJ rules otherwise" — 多标准冲突时的默认处理策略
+> "Never assume soil parameters without a ground investigation report or clear stated assumptions" — 岩土参数假设的铁律
+> "Calculation packages must be self-contained: inputs, references, calculations, results" — 计算包自包含性要求
+
+## Key Concepts
+- [[ULS]]（极限状态设计/Strength Limit State）：结构承载力极限状态，对应 Eurocode EN 1990 中的 ULS、ACI 318 LRFD
+- [[SLS]]（正常使用极限状态/Serviceability Limit State）：挠度、振动、裂缝控制，对应 EN 1990 SLS、ACI 318 serviceability provisions
+- [[National Annex]]（国家附录）：Eurocode 各成员国对 NDPs（国家确定参数）的本地化修订，是规范冲突的主要来源
+- [[AHJ]]（Authority Having Jurisdiction）：主管当局，拥有最终解释权，多标准项目需向 AHJ 确认
+- [[Basis of Design]]（设计依据）：记录所有关键假设、规范版本选择、荷载组合、设计决策的正式文件
+- [[Ductility Class]]（延性等级）：Eurocode EN 1998 的 DCL/DCM/DCH，地震设计中的结构延性要求分级
+- [[LRFD]]（荷载抗力系数设计）：美国 ACI/AISC 体系采用的设计方法，与 Eurocode 的部分系数法（EN 1990 DA1/DA2/DA3）思路相近但系数不同
+- [[BIM Coordination]]（BIM 协调）：结构模型导出 IFC 4.x、碰撞检测、穿楼板开孔、钢筋保护层协调等
+
+## Key Entities
+- [[Eurocode]]：欧洲规范体系 EN 1990–1999，覆盖结构设计荷载、混凝土/钢/木/砌体结构、岩土、抗震等九大领域，附各国 National Annex
+- [[AISC 360]]：美国钢结构设计规范（LRFD 与 ASD 双轨），含构件设计、连接设计、冷弯型钢结构
+- [[ACI 318]]：美国钢筋混凝土设计规范，LRFD/SD 方法，含特殊抗弯框架（SMF）抗震细部要求
+- [[ASCE 7]]：美国建筑及其他结构最小设计荷载规范，涵盖重力荷载、风荷载、地震荷载、冰雪荷载等第 2–31 章
+- [[EN 1997]]：Eurocode 岩土设计规范，含浅基础、深基础、挡土结构、土坡稳定的体系化设计方法
+- [[AIJ]]（Architectural Institute of Japan）：日本建筑学会规范，高抗震延性要求、响应谱法抗震设计指南
+
+## Connections
+- [[specialized-developer-advocate]] ← shares → [[specialized-mcp-builder]]（同属 specialized 专业 Agent 系列）
+- [[specialized-civil-engineer]] ← implements → [[specialized-workflow-architect]]（专业 Agent 依赖工作流架构）
+
+## Contradictions
+- 暂无已知冲突。该 Agent 覆盖全球多套独立规范体系，各标准间差异已明确标注（如 Eurocode vs ACI vs GB 的荷载分项系数不可混用），符合预期。

wiki/sources/visionos-spatial-engineer.md

@@ -0,0 +1,68 @@
+---
+title: "visionOS Spatial Engineer"
+type: source
+tags: []
+date: 2026-04-20
+---
+
+## Source File
+- [[Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md]]
+
+## Summary（用中文描述）
+- 核心主题：visionOS 原生空间计算 Agent，专注于 volumetric 界面与 Liquid Glass 设计系统实现
+- 问题域：Apple visionOS 26 平台上的空间应用开发，缺乏统一的设计与工程实践框架
+- 方法/机制：基于 SwiftUI/RealityKit 技术栈，通过 Liquid Glass Design System 驱动透明材质渲染，结合 WindowGroup 多窗口架构和 SwiftUI Volumetric API 实现 3D 内容集成
+- 结论/价值：为 The Agency Spatial Computing 部门提供 visionOS 原生开发能力，与 [[macos-spatial-metal-engineer]]（Metal 渲染侧）和 [[xr-immersive-developer]]（WebXR 浏览器侧）共同构成 Apple 空间计算全栈能力
+
+## Key Claims（用中文描述）
+- Apple 的 Liquid Glass Design System 通过自适应透明材质，在 light/dark 环境和周围内容变化时动态调整视觉表现
+- Spatial Widgets 可吸附于墙面和桌面，持久化放置于 3D 空间中，无需应用前台运行
+- SwiftUI Volumetric API 支持 3D 内容集成、volume 内 transient content 和 breakthrough UI 元素
+- RealityKit-SwiftUI 集成通过 Observable entities、直接手势处理和 ViewAttachmentComponent 实现声明式 3D 开发
+- Multi-Window Architecture 通过 WindowGroup 管理空间应用的玻璃背景效果和单实例窗口
+- GPU 高效渲染是多个玻璃窗口和 3D 内容同时展示的性能保障
+
+## Key Quotes
+> "Focuses on leveraging visionOS 26's spatial computing capabilities to create immersive, performant applications that follow Apple's Liquid Glass design principles." — Agent personality description
+
+## Key Concepts
+- [[Liquid Glass Design System]]：Apple visionOS 26 的核心视觉设计语言，通过透明材质实现深度感知和空间沉浸感
+- [[Spatial Widgets]]：可吸附于 3D 空间（墙面/桌面）并持久化放置的小组件，支持跨应用使用
+- [[SwiftUI Volumetric APIs]]：visionOS 26 新增的 3D 内容渲染 API 集，支持 volumetric 场景和 breakthrough UI
+- [[RealityKit-SwiftUI Integration]]：RealityKit 实体系统与 SwiftUI 声明式语法的深度集成模式
+- [[Glass Background Effects]]：glassBackgroundEffect modifier 实现窗口和控件的毛玻璃透明效果
+- [[Volumetric Presentations]]：空间展示模式，支持 single-instance 窗口和 volume 内的临时内容
+- [[Spatial Layouts]]：3D 空间定位、深度管理和空间关系处理
+- [[Multi-Window Architecture]]：基于 WindowGroup 的空间应用多窗口管理模式
+
+## Key Entities
+- [[Apple]]：visionOS/SwiftUI/RealityKit/ARKit 框架的缔造者，Liquid Glass Design System 的设计者
+- [[visionOS]]：Apple 空间计算操作系统，本 Agent 的核心目标平台（visionOS 26+）
+- [[SwiftUI]]：Apple 声明式 UI 框架，本 Agent 的主要开发语言
+- [[RealityKit]]：Apple 原生 3D 渲染引擎，与 SwiftUI 深度集成
+- [[ARKit]]：Apple 增强现实框架，本 Agent 的空间感知能力来源
+- [[Metal]]：Apple GPU 渲染 API，支撑 Liquid Glass 和 3D 内容的高性能渲染
+- [[XR-Interface-Architect]]：Spatial Computing 部门 UX/UI 设计专家，与本 Agent 协同构建空间界面
+- [[macOS-Spatial-Metal-Engineer]]：Apple 平台 Metal 渲染侧专家，与本 Agent 协同构成 Apple 空间计算全栈
+- [[Terminal-Integration-Specialist]]：Swift 终端仿真专家，本 Agent 依赖其提供命令行交互能力
+- [[XR-Immersive-Developer]]：同部门 WebXR 开发专家
+- [[XR-Cockpit-Interaction-Specialist]]：同部门座舱交互专家
+
+## Connections
+- [[XR-Immersive-Developer]] ← related_to ← [[visionos-spatial-engineer]]：两者同属 Spatial Computing 部门，前者专注浏览器端 WebXR，后者专注 Apple 原生 visionOS
+- [[macOS-Spatial-Metal-Engineer]] ← related_to ← [[visionos-spatial-engineer]]：前者专注 Metal 渲染管线，后者专注 SwiftUI/RealityKit 原生应用；两者协同构成完整的 Apple 空间计算平台能力
+- [[XR-Interface-Architect]] ← supports ← [[visionos-spatial-engineer]]：前者提供 UX/UI 设计框架，本 Agent 负责技术实现
+- [[Terminal-Integration-Specialist]] ← supports ← [[visionos-spatial-engineer]]：前者提供 Swift 终端仿真集成能力
+
+## Contradictions
+- 与 [[XR-Immersive-Developer]] 在平台选择上的差异：
+  - 冲突点：前者基于 WebXR（浏览器端，跨平台），后者基于 visionOS 原生（Apple 独占）
+  - 当前观点：visionOS Spatial Engineer 专注 Apple 原生平台，追求最优性能和平台特性
+  - 对方观点：XR Immersive Developer 优先跨平台兼容性，通过 A-Frame/Three.js 实现浏览器端部署
+  - 协调：两者面向不同场景，前者服务 visionOS 高端沉浸体验，后者服务广泛的 WebXR 设备覆盖
+
+- 与 [[macOS-Spatial-Metal-Engineer]] 在技术栈选择上的差异：
+  - 冲突点：前者侧重 SwiftUI/RealityKit 声明式开发，后者侧重 Metal/SceneKit 底层渲染
+  - 当前观点：visionOS Spatial Engineer 优先 SwiftUI 的声明式效率和 Apple 官方推荐模式
+  - 对方观点：macOS Spatial/Metal Engineer 认为 Metal 渲染管线对于大规模 3D 数据可视化更可控
+  - 协调：两者在同一问题域互补——前者处理 UI/UX 层应用开发，后者处理 GPU 密集型数据渲染