nexus/wiki/log.md

## [2026-05-05] ingest | Performance Benchmarker Agent Personality
- Source file: Agent/agency-agents/testing/testing-performance-benchmarker.md
- Status: ✅ 成功摄入
- Summary: Performance Benchmarker——The Agency Testing 部门的性能测试与优化专家 Agent，通过系统性性能测试确保系统以 95% 置信度满足 SLA 要求。核心理念：量化一切可量化的，用数据证明优化价值。核心能力：负载/压力/耐力/可扩展性测试，Core Web Vitals 优化（LCP < 2.5s / FID < 100ms / CLS < 0.1），k6 性能测试框架，统计置信区间分析，容量规划与成本-性能权衡。成功指标：95% 系统持续满足性能 SLA，Core Web Vitals 达到"良好"评级（90th percentile），关键用户体验指标改善 25%，支持 10x 当前负载。
- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值）
- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值）
- Source page: wiki/sources/testing-performance-benchmarker.md
- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-performance-benchmarker 段落。与 testing-reality-checker 的互补张力（指标量化 vs 用户感受）已在 Source Page Contradictions 节记录。

## [2026-05-05] ingest | Testing Reality Checker Agent Personality
- Source file: Agent/agency-agents/testing/testing-reality-checker.md
- Status: ✅ 成功摄入
- Summary: Testing Reality Checker——The Agency Testing 部门的最后一道防线 Agent，通过自动化截图证据截断"幻想型认证"，要求压倒性视觉证明才授予生产就绪状态。默认"NEEDS WORK"，强制三步验证流程（Reality Check 命令 → QA 交叉验证 → 端到端截图分析）。C+/B- 评级属正常；第一次实现通常需要 2-3 轮修订。
- Concepts created: 无（所有 Key Concepts 均为单来源特定概念，不满足独立复用阈值）
- Entities created: 无（所有 Key Entities 均为单来源 Agent，不满足 ≥2 次创建阈值）
- Source page: wiki/sources/testing-reality-checker.md
- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-reality-checker 段落。与 testing-workflow-optimizer 的潜在张力（效率 vs 真实性）和与 testing-api-tester 的互补关系（截图 vs 接口）已在 Source Page Contradictions 节记录。

## [2026-05-05] ingest | Workflow Optimizer Agent Personality
- Source file: Agent/agency-agents/testing/testing-workflow-optimizer.md
- Status: ✅ 成功摄入
- Summary: Workflow Optimizer——The Agency Testing 部门的流程优化与工作流自动化专家 Agent，基于系统思维方法论分析、优化和自动化跨业务功能的工作流。核心理念：找到瓶颈，修复流程，其余自动化。四阶段工作流（现状分析→优化设计→实施规划→自动化执行），融合 Lean/Six Sigma/Kaizen/统计过程控制/变更管理/人本设计六大方法论体系。核心交付物：WorkflowOptimizer Python 框架。成功指标：40% 周期时间改善、60% 常规任务自动化率、75% 流程错误减少、90% 优化流程 6 个月内成功采纳、30% 员工满意度提升。
- Concepts created: [[Lean]], [[Six-Sigma]], [[Kaizen]], [[Value-Stream-Mapping]], [[Statistical-Process-Control]], [[Human-Centered-Design]], [[Design-Thinking]]（共 7 个，其中 Change-Management 已存在）
- Entities created: 无（The Agency 已在 entities/ 中存在；各工具仅出现 1 次，不满足 ≥2 次创建阈值）
- Source page: wiki/sources/testing-workflow-optimizer.md
- Notes: 无内容冲突。index.md 原占位条目已替换为完整摘要；overview.md Testing 部门已新增 testing-workflow-optimizer 段落；7 个新 Concept 页面已创建并添加到 index.md。与 specialized-workflow-architect（设计与执行的分层关系）和 product-behavioral-nudge-engine（自动化 vs 人机交互互补张力）已在 Source Page Contradictions 节记录。

## [2026-05-05] ingest | API Tester Agent Personality
- Source file: Agent/agency-agents/testing/testing-api-tester.md
- Status: ✅ 成功摄入
- Summary: API Tester Agent——The Agency Testing 部门的 API 测试专家智能体人格定义，涵盖功能、性能、安全三大维度的全面 API 质量保障方法论与自动化实现框架。核心理念"Breaks your API before your users do"，通过 Playwright/REST Assured/k6 框架实现 95%+ API 端点覆盖率，CI/CD 流水线集成，性能 SLA（95p < 200ms、10x 负载、< 0.1% 错误率），OWASP API Security Top 10 安全验证。
- Concepts created: 无（API Testing、Performance Testing、Security Testing、Contract Testing、CI/CD Integration、OWASP API Security Top 10 等概念均已在本文档出现，未达独立创建阈值）
- Entities created: 无（Playwright、REST Assured、k6、perf_hooks 等工具均仅在本文档出现，未达创建阈值）
- Source page: wiki/sources/testing-api-tester.md
- Notes: 无内容冲突。index.md 和 overview.md 已更新。新增 Testing 部门 section 到 overview.md。
- Source file: Agent/agency-agents/integrations/opencode/README.md
- Status: ✅ 成功摄入
- Summary: OpenCode Integration——The Agency Agent roster 与 OpenCode 编辑器的子 Agent 集成方案，通过 `./scripts/install.sh --tool opencode` 安装，将 .md 格式 Agent 转换为 OpenCode 的 `.opencode/agents/` 格式。核心机制：`mode: subagent` 使 Agent 仅在 `@agent-name` 触发时出现，不在 Tab 循环中占位；命名颜色自动映射为十六进制颜色代码。支持项目级和全局级两种安装范围。与 [[readme|Cursor Integration]]（.mdc）、[[github-copilot|GitHub Copilot Integration]]、[[windsurf-integration|Windsurf Integration]] 同属 The Agency 多 IDE 集成生态。
- Concepts created: 无（Subagent、OpenCode 仅在本文档出现1次，未达创建阈值）
- Entities updated: 无（[[The Agency]] 已在其他来源中覆盖，无需新建 OpenCode entity）
- Source page: wiki/sources/readme.md
- Notes: 无内容冲突。index.md 和 overview.md 已更新。

## [2026-05-04] ingest | Kimi Code CLI Integration
- Source file: Agent/agency-agents/integrations/kimi/README.md
- Status: ✅ 成功摄入
- Summary: Kimi Code CLI Integration——将 Agency agents 项目转换为 Kimi Code CLI 可用的 agent specification，通过 `convert.sh` 和 `install.sh` 脚本生成 `agent.yaml` + `system.md` 目录结构，安装到 `~/.config/kimi/agents/`。使用 `--agent-file` 标志激活，支持 `extend: default` 继承 Kimi 内置工具集。与 [[readme|Cursor Integration]] 和 [[github-copilot|GitHub Copilot Integration]] 同属 The Agency 多 IDE/CLI 集成生态。
- Concepts created: 无（YAML配置文件、Agent规范、SystemPrompt 均仅在本文档出现1次，未达创建阈值）
- Entities created: 无（Kimi Code CLI、Moonshot AI 均仅在本文档出现1次，未达创建阈值）
- Source page: wiki/sources/kimi.md
- Notes: 无内容冲突。index.md 和 overview.md 已更新。

## [2026-05-04] ingest | Antigravity Integration
- Source file: Agent/agency-agents/integrations/antigravity/README.md
- Status: ✅ 成功摄入
- Summary: Antigravity Integration——The Agency Agent roster 与 Antigravity/Gemini 的集成方案，通过 `./scripts/install.sh --tool antigravity` 将全部 Agent roster 转换为 Antigravity SKILL.md 文件，复制到 `~/.gemini/antigravity/skills/`。所有 skill slug 统一使用 `agency-` 前缀避免命名冲突。用户可通过自然语言激活对应 agent。与 [[Cursor Integration]]（.mdc 规则）、[[Windsurf Integration]]（.windsurfrules）、[[GitHub Copilot Integration]]（原生兼容）共同构成 The Agency 的完整多平台集成生态。
- Concepts updated: 无需更新（SKILL.md Format、Antigravity Skills、Skill Prefix Convention 等概念已在其他来源中覆盖）
- Entities created: 无（Antigravity/Gemini、Agency Agents 均已在其他来源中出现，无需新建）
- Source page: wiki/sources/antigravity-integration.md
- Notes: 无内容冲突。index.md 和 overview.md 已更新。与 [[Cursor Integration]] 在"多 IDE 集成覆盖"定位上存在功能重叠，已在 Contradictions 节标注区分（前者 GUI 编辑器生态，后者 Gemini 生态）。

## [2026-05-03] ingest | Windsurf Integration
- Source file: Agent/agency-agents/integrations/windsurf/README.md
- Status: ✅ 成功摄入
- Summary: Windsurf Integration——The Agency Agent roster 与 Windsurf 编辑器的集成方案，通过 `.windsurfrules` 文件将 Agent roster 聚合为单一规则文件，install.sh 从项目根目录安装，项目级生效。在 prompt 中按名称引用 Agent 即可激活。与 [[Cursor Integration]]（.mdc）和 [[Aider Integration]]（CONVENTIONS.md）同为项目级 IDE 集成，共同构成 The Agency 的多 IDE 覆盖体系。
- Concepts updated: [[Agent-Activation-Pattern]]（补充 Windsurf 应用场景）、[[Project-Scoped-Tools]]（替代 Project-Scoped-Integration，与 integrations-readme.md 保持一致）
- Entities created: [[Windsurf]]（Windsurf.md，Codeium 开发的 AI 代码编辑器，跨 3 个 source 页面出现）
- Source page: wiki/sources/windsurf-integration.md
- Notes: 无内容冲突。index.md 和 overview.md 已更新。slug 避免与同名 readme.md 冲突（已有多条同名占位条目），采用 windsurf-integration.md。

## [2026-04-26] ingest | Gemini CLI Integration
- Source file: Agent/agency-agents/integrations/gemini-cli/README.md
- Status: ✅ 成功摄入
- Summary: Gemini CLI Integration——将 61 个 Agency Agents 打包为 Gemini CLI 扩展插件，安装到 `~/.gemini/extensions/agency-agents/`，安装后可在 Gemini CLI 中通过自然语言按名称激活 Agent skill（如 `frontend-developer`）。
- Entities created: 无（Agency Agents 已在其他来源中出现，无需新建；Agent Skill 和 Extension 机制未达到 ≥2 次出现阈值）
- Concepts created: 无
- Source page: wiki/sources/gemini-cli.md
- Notes: 无内容冲突。

## [2026-05-03] ingest | Cursor Integration
- Source file: Agent/agency-agents/integrations/cursor/README.md
- Status: ✅ 成功摄入
- Summary: Cursor Integration——将 Agency roster 中的 agent 转换为 Cursor `.mdc` 规则文件，安装到项目根目录的 `.cursor/rules/` 下，**项目级别生效**。支持 `@agent-slug` 引用特定 agent，或通过 `alwaysApply: true` 设为常驻规则。与 Aider Integration 形成 IDE 集成互补。
- Entities created: 无（Agency Agents 和 Cursor 未达到 ≥2 次出现阈值）
- Concepts created: 无（Cursor.mdc Rules/Agency Roster/Project-Scoped Rules 仅出现 1 次，不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/readme.md
- Notes: 无内容冲突。overview.md 已新增 Cursor Integration 段落于 The Agency 贡献指南段落后。与 [[Aider Integration]] 存在功能重叠（两个工具都将 Agency agents 集成到不同 IDE），已在 Source page Contradictions 节记录。

## [2026-05-03] ingest | OpenClaw Integration
- Source file: Agent/agency-agents/integrations/openclaw/README.md
- Status: ✅ 成功摄入
- Summary: The Agency Agent 与 OpenClaw 多智能体框架的集成方案——通过 convert.sh 将 Agent 转换为 OpenClaw workspace（含 SOUL.md/AGENTS.md/IDENTITY.md），install.sh 复制到 ~/.openclaw/agency-agents/，openclaw gateway restart 使 Agent 通过 agentId 可用。slug 采用 openclaw-integration.md 以避免与同名 Aider Integration 的 readme.md 冲突。
- Entities created: 无（OpenClaw/The-Agency/OpenClaw-Gateway 在 overview.md 已出现多次，不满足新建阈值）
- Concepts created: 无（OpenClaw-Workspace/Workspace-Based-Agent/Agent-Conversion 仅在源页面内出现 1 次，不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/openclaw-integration.md
- Notes: 无内容冲突。overview.md 已有 OpenClaw 相关内容，无需修订。integrations-readme.md 已有 OpenClaw wikilink，无需重复创建 Entity 页面。

## [2026-05-02] ingest | MCP Memory Integration
- Source file: Agent/agency-agents/integrations/mcp-memory/README.md
- Status: ✅ 成功摄入
- Summary: MCP Memory Integration——通过在 Agent 提示词中加入标准化的 Memory Integration 段落，为 The Agency 中任意 Agent 添加跨会话持久记忆能力。MCP Memory Server 提供 remember/recall/rollback/search 四个核心工具。Rollback 是杀手级功能：QA 失败或架构决策出错时恢复到已知良好状态，无需手动 undo。无代码修改，仅需在 prompt 中加入标准化指令段。
- Entities created: 无（The-Agency 已存在于 entities/，Backend-Architect/Startup-MVP-Workflow 仅出现 1 次，均不满足 ≥2 次阈值）
- Concepts created: 无（Cross-Session-Memory/Handoff-Continuity/Rollback/Memory-Integration-Pattern/MCP-Memory-Tools/Checkpoint 均仅出现 1 次，均不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/mcp-memory-integration.md
- Notes: 无内容冲突。index.md 和 overview.md 已更新（新增 MCP Memory Integration 段落于 The Agency 段落后）。

## [2026-05-02] ingest | Claude Code Integration
- Source file: Agent/agency-agents/integrations/claude-code/README.md
- Status: ✅ 成功摄入
- Summary: The Agency Agent 资产与 Claude Code 的原生集成方案。The Agency 从一开始就为 Claude Code 构建，无需任何格式转换，Agent 天然使用 `.md` + YAML frontmatter 格式。通过 install.sh 或手动复制将 Agent 部署到 `~/.claude/agents/`，在 Claude Code 会话中通过名称引用即可激活对应 Agent。
- Entities created: 无（Claude Code/The Agency 均仅出现 1 次，不满足 ≥2 次阈值，以 wikilink 形式记录于 Source page）
- Concepts created: 无（Agent-Activation-Pattern 仅出现 1 次，不满足 ≥2 次阈值）
- Source page: wiki/sources/claude-code-integration.md
- Notes: 无内容冲突。slug 冲突解决：原 Aider Integration 已占用 `readme.md`，Claude Code README 同名，故采用 `claude-code-integration.md`。overview.md 无需修订（内容属配置说明，集成概述由 integrations-readme.md 覆盖）。

## [2026-05-02] ingest | Aider Integration
- Source file: Agent/agency-agents/integrations/aider/README.md
- Status: ✅ 成功摄入
- Summary: Aider 编辑器集成 The Agency Agent 资产的安装与使用指南。核心机制：通过 install.sh 将 Agent 配置转换为 Aider 可读的 CONVENTIONS.md 文件，Aider 自动读取并激活 Agent 角色。
- Entities created: 无（Aider 仅出现 2 次，未达到 ≥2 次阈值，以 wikilink 形式记录于 Source page）
- Concepts created: 无（CONVENTIONS.md/Project-Scoped-Integration 仅出现 1 次，不满足 ≥2 次阈值）
- Source page: wiki/sources/readme.md
- Notes: 无内容冲突。index.md 占位条目已替换为完整条目。overview.md 无需修订（The Agency 集成生态已有 integrations-readme.md 覆盖）。integrations-readme.md 已有 Aider wikilink，无需重复创建 Entity 页面。

## [2026-05-02] ingest | The Agency Integrations README
- Status: ✅ 成功摄入
- Summary: The Agency 多智能体编码系统与 11 种主流 Agentic Coding 工具的集成指南。覆盖 Claude Code（原生）、GitHub Copilot（原生）、Antigravity、Gemini CLI（需 convert）、OpenCode（项目级）、OpenClaw（需 convert）、Cursor（项目级）、Aider（项目级）、Windsurf（项目级）、Kimi Code（需 convert）、Qwen Code（需 convert）。统一通过 install.sh 和 convert.sh 脚本实现跨平台部署。
- Entities created: 无（各工具实体均仅出现 1 次，不满足 ≥2 次创建阈值）
- Concepts created: 无（Project-Scoped-Tools/Global-Scoped-Tools 仅出现 1 次）
- Source page: wiki/sources/integrations-readme.md
- Notes: 无内容冲突。index.md 和 log.md 已更新，overview.md 无需修订（已含 The Agency 段落）。

## [2026-05-02] ingest | Academic Geographer
- Source file: Agent/agency-agents/academic/academic-geographer.md
- Status: ✅ 成功摄入
- Summary: Academic Geographer——AI Agent 中的地理学家角色，专注于物理与人文地理的系统性建模，为虚拟世界构建地理连贯性。核心理念："Geography is destiny — where you are determines who you become"。通过严格地理连贯性规则（河流不分叉、气候成系统、地理非装饰）、五步工作流（板块构造→气候→水文→生物群落→人类定居）、交付物模板驱动 Agent 行为。理论基础涵盖 Koppen 气候分类、Christaller 中心地理论、Mackinder 心脏地带理论、雨影效应等。
- Entities created: [[Jared-Diamond]], [[Acemoglu]], [[Mackinder]]
- Concepts created: [[Geographic-Coherence]], [[Environmental-Determinism]], [[Mackinder-Heartland-Theory]]
- Source page: wiki/sources/academic-geographer.md
- Notes: 与 [[academic-historian]]（历时性时间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"，已在 overview.md 添加独立段落。Entity/Concept 页面已创建。无已知内容冲突。

## [2026-05-02] ingest | Academic Narratologist
- Source file: Agent/agency-agents/academic/academic-narratologist.md
- Status: ✅ 成功摄入
- Summary: Narratologist Agent——以叙事理论框架驱动故事结构分析的学术型 AI Agent。将俄罗斯形式主义、法国结构主义、认知叙事学等学术传统注入 Agent，使其能像专业叙事理论家一样分析故事结构、角色弧光、主题表达，并提供有命名框架依据的叙事建议。核心理念："每个故事都是一个论证"；核心原则：大多数叙事问题存在于讲述层面（sjuzhet）而非故事层面（fabula），诊断应优先于处方；每个建议必须引用至少一个命名理论框架。
- Concepts created: [[Fabula-Sjuzhet]], [[Propp-Morphology]], [[Character-Arc]], [[Narrative-Debt]]
- Source page: wiki/sources/academic-narratologist.md
- Notes: 与 [[academic-anthropologist]]（共时性文化系统）、[[academic-historian]]（历时性时间分析）、[[academic-geographer]]（空间维度）共同构成"人文社科 AI 研究者矩阵"，已在 overview.md 添加独立段落。Entity 方面，Academic Anthropologist 条目曾标注 academic-narratologist 为 source missing，现已补全。该文档为 Agent 角色设定，无外部内容冲突。

- Source file: Agent/agency-agents/academic/academic-anthropologist.md
- Status: ✅ 成功摄入
- Summary: Academic Anthropologist——基于文化人类学理论构建文化自洽社会的 AI Agent 设计框架。将田野调查方法论注入 Agent，使其能设计有社会学意义的亲属制度、交换系统、仪式信仰和权力结构。核心理念：每个文化元素必须有社会功能，先问"这个实践解决了什么问题"而非"这个仪式看起来酷不酷"。理论基础：结构人类学（列维-斯特劳斯）、象征人类学（格尔茨"厚描"）、实践理论（布迪厄）、仪式分析（特纳/范热内普）、经济人类学（莫斯/波拉尼）。关键原则：避免文化拼贴（culture salad）、不跳过亲属制度设计、无乌托邦（每个文化都有内部张力）。
- Concepts created: [[Thick-Description]], [[Liminality]], [[Gift-Economy]], [[Cultural-Coherence]], [[Rites-of-Passage]]
- Entities identified (not yet created): [[Claude-Lévi-Strauss.md]], [[Clifford-Geertz.md]], [[Pierre-Bourdieu.md]], [[Victor-Turner.md]], [[Arnold-van-Gennep.md]], [[Marcel-Mauss.md]], [[Mary-Douglas.md]], [[Émile-Durkheim.md]], [[Bronislaw-Malinowski.md]], [[Karl-Polanyi.md]], [[Marvin-Harris.md]]
- Source page: wiki/sources/academic-anthropologist.md
- Notes: 与 [[academic-historian]]（历时性视角）、[[academic-geographer]]（空间维度）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。Entity/Concept 页面已识别但未实际创建，可作为后续补充。无已知内容冲突。

## [2026-04-26] ingest | Academic Psychologist
- Source file: Agent/agency-agents/academic/academic-psychologist.md
- Status: ✅ 成功摄入
- Summary: Academic Psychologist——The Agency 学术部门的临床与研究心理学家人格智能体，为角色塑造提供心理学可信度支撑。基于 Big Five、依恋理论、Vaillant 防御机制层级、Karpman 戏剧三角、CBT 认知扭曲、社会心理学经典实验等多种理论与实证框架，对角色进行多维度心理画像。核心原则：拒绝将角色病理化，区分流行心理学与循证心理学，承认文化情境与创伤响应的多样性。
- Concepts created: [[Big-Five-Personality]], [[Attachment-Theory]], [[Defense-Mechanisms]], [[Cognitive-Distortions]], [[Karpman-Drama-Triangle]], [[Transactional-Analysis]], [[Trauma-Informed-Analysis]]
- Source page: wiki/sources/academic-psychologist.md

## [2026-04-25] ingest | Historian Agent Personality
- Source file: Agent/agency-agents/academic/academic-historian.md
- Status: ✅ 成功摄入
- Summary: Historian Agent——AI Agent 角色设定，扮演具有跨时代研究能力的历史学家，为创意项目提供历史真实性验证、时代背景丰富化和历史迷思纠正。核心理念：物质条件决定论（先理解经济基础再谈政治军事）、主动挑战欧洲中心主义、每条论断必须标注置信度和来源类型。方法论：Annales 学派、长时段分析（longue durée）、微观史、比较史、反事实推理、史料批判。五步工作流：定位时空坐标→核查物质基础→叠加社会结构→评估论断→标注置信度。典型交付物：Period Authenticity Report、Historical Coherence Check。
- Concepts created: [[Annales-School]], [[Longue-Duree]]
- Source page: wiki/sources/academic-historian.md
- Notes: 与 [[academic-geographer]]（空间维度）、[[academic-anthropologist]]（共时性文化系统）、[[academic-narratologist]]（叙事维度）共同构成"人文社科 AI 研究者矩阵"。无已知内容冲突——主要纠正通俗历史迷思而非与已有 Wiki 内容矛盾。
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目。Academic 部门未在 overview.md 单独设节，相关心理框架已融入 Wiki 的 Agent 心理学知识体系。7 个 Concept 页面已创建并添加到 index.md。所有 Key Entities（Erikson/Piaget/Bowlby/Aaron Beck/Karpman/Vaillant/Milgram/Zimbardo/Herman/van der Kolk/Porges/Eysenck/Lazarus）均仅出现 1 次，不足 Entity 建页阈值（≥2 次），以 wikilink 形式记录于 Source page。与 [[multi-agent-system-reliability]] 在"确定性 vs 概率性"上的张力已记录于 Contradictions 部分。

## [2026-04-26] ingest | Behavioral Nudge Engine
- Source file: Agent/agency-agents/product/product-behavioral-nudge-engine.md
- Status: ✅ 成功摄入
- Summary: Behavioral Nudge Engine——基于行为心理学原理的智能用户推动引擎，通过个性化交互节奏和激励策略最大化软件用户完成任务的可能性。核心四阶段工作流：偏好发现→任务拆解→精准推送→即时庆祝。支持 SMS/Email/应用内横幅等多渠道触达，利用默认偏差、微任务冲刺（5分钟）和游戏化机制持续驱动用户行为。有效降低认知负荷、提升任务完成率、减少平台流失。
- Entities created: [[BehavioralNudgeEngine.md]]
- Concepts created: [[Behavioral-Psychology.md]], [[Cognitive-Load-Reduction.md]], [[Default-Bias.md]], [[Gamification.md]], [[Momentum-Nudge.md]], [[Pomodoro-Technique.md]]
- Source page: wiki/sources/product-behavioral-nudge-engine.md
- Notes: index.md Sources 节更新原 expected 条目为正式标题；Entities 新增 Behavioral Nudge Engine 条目；Concepts 新增 5 个行为心理学相关概念页面；无已知内容冲突。

## [2026-04-26] ingest | Product Sprint Prioritizer Agent
- Source file: Agent/agency-agents/product/product-sprint-prioritizer.md
- Status: ✅ 成功摄入
- Summary: Product Sprint Prioritizer——The Agency 产品部门的冲刺规划与优先级排序专家 Agent，专注于敏捷冲刺规划、特性优先级排序和资源分配，通过数据驱动的优先级框架（RICE/MoSCoW/Kano/Value vs. Effort）最大化团队交付价值。核心方法：6 冲刺滚动平均团队速率预测（偏差 < 15%）；冲刺前五步准备（Backlog Refinement → 依赖分析 → 容量评估 → 风险识别 → 干系人审查）；技术债务与新功能 ROI 平衡建模；风险评分（概率 × 影响矩阵）定期重新评估。成功指标：承诺故事点交付率 90%+、干系人满意度 4.5/5、时间线偏差 ±10%、技术债务占比 < 20%。
- Entities created: 无（TheAgency 已存在；ProductManagerAgent 仅在连接关系中出现，通过 Source Page Key Entities 保留）
- Concepts created: [[SprintPlanning.md]]（Sprint Planning 在 7 个页面中被提及，满足独立创建条件）
- Source page: wiki/sources/product-sprint-prioritizer.md
- Notes: index.md Sources 节新增条目置于最前；overview.md Product 部门新增 [[product-sprint-prioritizer]] 条目置于 [[product-manager]] 之后；与 [[product-feedback-synthesizer]] 存在潜在张力（短期迭代优先级 vs 长期用户价值路线图），已在双方 Source Page Contradictions 节记录，建议分工：Sprint Planning 层面优先 Sprint Prioritizer，产品路线图层面优先 Feedback Synthesizer。

## [2026-04-26] ingest | Product Trend Researcher Agent
- Source file: Agent/agency-agents/product/product-trend-researcher.md
- Status: ✅ 成功摄入
- Summary: Product Trend Researcher——The Agency Product 部门的专家级市场情报分析师，专注于新兴趋势识别、竞争分析和机会评估。核心方法：七步趋势识别流程（信号收集→模式识别→上下文分析→影响评估→验证→预测→可操作性）；50+ 数据源实时聚合，统计验证弱信号检测，提前 3-6 个月识别主流采纳前趋势；TAM/SAM/SOM 三层市场量化；竞争情报框架（直接/间接/新兴/技术/替代）。成功指标：80%+ 准确率 6 个月趋势预测、90% 洞察转化战略决策、48h 紧急响应、15+ 验证来源。
- Entities created: 无（TheAgency 已存在；ProductManagerAgent/AgentsOrchestrator 仅出现 1-2 次，通过 Source Page Key Entities 保留）
- Concepts created: 无（TrendLifecycleMapping/AdoptionCurveAnalysis/TAM-SAM-SOM/CompetitiveIntelligence/WeakSignalDetection/TechnologyScouting/SocialListening 均为标准领域抽象，各仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注）
- Source page: wiki/sources/product-trend-researcher.md
- Notes: index.md Sources 节新增条目置于最前；overview.md Product 部门新增 [[product-trend-researcher]] 条目置于 [[product-manager]] 之前；与 [[Agents-Orchestrator]] 存在潜在张力（Trend Researcher 需要时间积累弱信号 vs Orchestrator 要求阶段质量门强制推进），已记录于 Source Page Contradictions 节。
- Source file: Agent/agency-agents/product/product-manager.md
- Status: ✅ 成功摄入
- Summary: Product Manager Agent (Alex)——The Agency 产品部门的核心战略 Agent，10+ 年 B2B SaaS/消费者应用/平台业务经验，Outcome-Driven 产品管理方法论。核心交付物：PRD/Opportunity Assessment/Now-Next-Later 路线图/GTM Brief/Sprint Health Snapshot。六阶段工作流：Discovery → Framing → Definition → Delivery → Launch → Measurement。关键原则：功能即假设、发布即实验；路线图是赌注清单而非承诺；经常说不保护团队焦点。
- Entities created: 无（Alex/PM persona 仅出现 1 次；B2B SaaS/Consumer Apps/Platform Businesses 属宽泛业务分类，无需单独创建 Entity）
- Concepts created: 无（RICE/NorthStarMetric/PRD/GTMBrief/SprintHealth 均属具体执行模板，不满足"可抽象、可复用"条件；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注，待后续独立创建）
- Source page: wiki/sources/product-manager.md
- Notes: 与 [[product-feedback-synthesizer]] 互补（反馈收集 vs 产品决策）；与 [[Senior Project Manager Agent]] 属产品-项目协作层级（PM 偏战略，Senior PM 偏执行任务分解），无冲突

- Source file: Agent/agency-agents/product/product-feedback-synthesizer.md
- Status: ✅ 成功摄入
- Summary: Product Feedback Synthesizer——The Agency Product 部门的用户反馈综合分析专家 Agent，专精于从多渠道（调查/访谈/工单/评论/社交媒体）收集、分析和综合用户反馈，将海量用户声音蒸馏为可量化的产品决策依据。核心能力：NLP 情感分析与满意度建模（RICE/MoSCoW/Kano 优先级框架）、用户旅程映射、流失预测与早期预警系统。核心理念：定性反馈 → 定量优先级 → 数据驱动路线图。成功指标：24h 内处理关键问题、90%+ 主题准确率、85% 综合反馈产生可衡量决策、NPS 提升 10+ 分。
- Concepts created: 无（NPS/RICE/MoSCoW/Kano/SentimentAnalysis/UserJourneyMapping/ChurnPrediction/VoC/FeedbackLoop 各仅在本文出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注）
- Entities created: 无（The Agency 仅在本文出现 1 次，通过 Source Page Key Entities 保留）
- Source page: wiki/sources/product-feedback-synthesizer.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md 新增 "### The Agency — Product 部门" 章节并添加 product-feedback-synthesizer 条目置于 Finance 部门之前；与 [[product-sprint-prioritizer]] 存在优先级框架差异（价值优先 vs 资源约束），已记录于 Source Page Contradictions 节。

## [2026-04-25] ingest | Specialized Developer Advocate
- Source file: Agent/agency-agents/specialized/specialized-developer-advocate.md
- Status: ✅ 成功摄入
- Summary: Developer Advocate Agent——The Agency Specialized 部门的开发者关系工程师，通过 DX 工程审计（Time-to-First-Success）、技术内容创作、社区运营（GitHub/Discord/Slack 响应）、产品反馈闭环（Voice of Developer 报告）推动平台采用。核心理念：Authentic 技术参与（"You don't do marketing — you do developer success"）；DX 改善复合效应优于内容发布；AstroTurf 永久性摧毁开发者信任。成功指标：首次成功 ≤15min、GitHub 响应 ≤24h、教程完成率 ≥50%、开发者 NPS ≥8/10。
- Concepts created: 无（DeveloperExperienceEngineering/TechnicalContentCreation/CommunityBuilding/ProductFeedbackLoop/DeveloperOnboardingAudit 等均在源文档仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注）
- Entities created: 无（GitHub/StackOverflow/Discord/KubeCon/OpenTelemetry/The Agency 等各仅出现 1 次，通过 Source Page Key Entities 保留）
- Source page: wiki/sources/specialized-developer-advocate.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Developer Advocate 条目置于 report-distribution-agent 之后；无重大内容冲突，仅与 [[specialized-workflow-architect]] 存在设计哲学层面的潜在张力（DX 质量优先 vs 快速交付），已记录于 Source Page Contradictions 节。

## [2026-04-25] ingest | Automation Governance Architect
- Source file: Agent/agency-agents/specialized/automation-governance-architect.md
- Status: ✅ 成功摄入
- Summary: Automation Governance Architect——企业自动化治理架构师，负责在实施前评估业务自动化的价值、风险和可维护性。基于 n8n 编排标准 + 四维决策框架（时间节省、数据关键性、外部依赖风险、可扩展性），通过 APPROVE/APPROVE AS PILOT/PARTIAL AUTOMATION ONLY/DEFER/REJECT 五种裁决防止低价值或高风险自动化进入生产，同时推动高价值自动化的标准化落地。核心原则：技术可行不等于值得自动化；简单健壮优于精巧脆弱；每个推荐必须包含降级方案和责任人；无文档和测试证据不得标记为完成。
- Concepts created: AutomationGovernance, DecisionFramework, N8nWorkflowStandard, ReliabilityBaseline, IntegrationGovernance, ReAuditTriggers
- Entities created: 无（n8n 仅出现 1 次，不满足"出现 ≥2 次"条件，通过 Source Page Key Entities 保留）
- Source page: wiki/sources/automation-governance-architect.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md compliance-auditor 条目中已引用 [[automation-governance-architect]]，无需额外修订；无重大内容冲突，仅与 [[specialized-workflow-architect]] 存在设计哲学层面的潜在张力（治理优先 vs 快速交付），已记录于 Source Page Contradictions 节。

## [2026-04-25] ingest | Report Distribution Agent
- Source file: Agent/agency-agents/specialized/report-distribution-agent.md
- Status: ✅ 成功摄入
- Summary: Report Distribution Agent——The Agency Specialized 部门的销售报告自动分发 Agent，基于区域路由参数将合并报告精准送达对应业务员和管理层，支撑工作日 8:00 AM 定时日报和周一 7:00 AM 周报分发，99%+ 定时送达率。核心能力：区域路由（业务员仅收到其区域数据）、公司级汇总报告（管理员/经理）、HTML 邮件格式化、SMTP 传输、分发日志审计（sent/failed 状态 + 时间戳）、失败重试 + 容错继续分发。属销售数据管道的分发层，上游对接 Data Consolidation Agent。
- Concepts created: 无（Territory Routing/SMTP Transport/Audit Trail/Scheduled Distribution 各仅在本文出现 1 次，暂不单独建 Concept 页面；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注）
- Entities created: 无（STGCRM/Data Consolidation Agent 各仅出现 1 次，通过 Source Page Key Entities 保留）
- Source page: wiki/sources/report-distribution-agent.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Report Distribution Agent 条目置于 data-consolidation-agent 之后；无内容冲突（与 [[specialized-document-generator]]（文档生成）和 [[data-consolidation-agent]]（数据整合）均为互补关系，无矛盾）。
- Source file: Agent/agency-agents/specialized/data-consolidation-agent.md
- Status: ✅ 成功摄入
- Summary: Data Consolidation Agent——The Agency Specialized 部门的销售数据整合专家 Agent，将分散的销售提取数据聚合为实时仪表盘。核心能力：并行多维度查询（地区/代表/管道/时间维度）、实时达成率计算（revenue/quota * 100，处理除零）、MTD/YTD/Year End 多时间视图、< 1 秒加载 + 60 秒自动刷新、零数据不一致保证。
- Concepts created: 无（Dashboard Report/Territory Report/Sales Attainment/Pipeline Snapshot/Metric Aggregation 均通过 Source Page 内 [[wikilink]] 形式表达，未单独建 Concept 页面）
- Entities created: 无（Sales Data Extraction Agent/Report Distribution Agent/Sales Pipeline Analyst/Sales Coach Agent 各仅出现 1 次，通过 Source Page Key Entities 保留）
- Source page: wiki/sources/data-consolidation-agent.md
- Notes: index.md 消除原 "source missing" 占位条目，替换为完整条目；overview.md 新增 Data Consolidation Agent 条目（置于 Specialized 部门末尾，与现有 Sales Pipeline Analyst/Sales Coach Agent 链接建立关系）；无内容冲突（与 Sales Pipeline Analyst 共享数据源但职责互补，与 Report Distribution Agent 构成顺序管道）。
- Source file: Agent/agency-agents/specialized/supply-chain-strategist.md
- Status: ✅ 成功摄入
- Summary: Supply Chain Strategist——The Agency Specialized 部门的中国制造业供应链全链路专家 Agent，帮助企业建立高效、有韧性、可持续的供应链体系。核心：供应商 ABC 分级管理 + Kraljic 矩阵采购策略 + TCO 全成本分析 + 库存优化模型（EOQ/ROP/安全库存/VMI/JIT）+ 供应链数字化成熟度 L1-L5 五级评估 + RBA/SA8000/CMRT 合规体系。典型成就：紧固件品类年采购成本降低 12%（节省 ¥870,000）。
- Concepts created: 无（Kraljic Matrix/TCO/EOQ/RBA/SA8000 等均在源文档仅出现 1 次，待后续批次独立创建；已在 Source Page Key Concepts 节以 [[wikilink]] 格式标注）
- Entities created: 无（1688/Canton Fair/SGS/TUV 等各渠道平台在源文档均仅出现 1 次，待后续批次独立创建；已在 Source Page Key Entities 节以 [[wikilink]] 格式标注）
- Source page: wiki/sources/supply-chain-strategist.md
- Notes: index.md 新增 Supply Chain Strategist Agent 条目，同时替换原有 "source missing" 占位条目（2026-04-20 supply-chain-strategist）为完整条目；overview.md Specialized 部门新增 Supply Chain Strategist 条目置于 zk-steward 之后；无内容冲突检测（与 [[specialized-french-consulting-market]] 为 Specialized 部门内的不同垂直领域，无直接矛盾）。

## [2026-04-25] ingest | ZK Steward Agent
- Source file: Agent/agency-agents/specialized/zk-steward.md
- Status: ✅ 成功摄入
- Summary: ZK Steward——AI 时代 Luhmann Zettelkasten 知识库管家，以 Niklas Luhmann 的卡片盒方法论为默认视角，融合多领域专家心智模型（Feynman/Karpathy/Munger/Ogilvy 等），通过原子笔记+ Luhmann 四原则验证门+领域专家切换实现有机知识网络增长。
- Concepts created: [[Zettelkasten]]（卡片盒知识管理法）、[[Luhmann-四原则]]（原子性/连接性/有机增长/持续对话验证门）、[[Domain-Thinking]]（领域专家三维切换机制）、[[Gegenrede]]（德语反诘，跨学科反问机制）、[[Link-Proposer]]（链接提议器三步流程）、[[Daily-Log]]（Intent/Changes/Open loops 每日日志）
- Entities created: [[Niklas-Luhmann]]（德国社会学家，Zettelkasten 发明者）、[[zk-steward-companion]]（GitHub 配套技能库）
- Source page: wiki/sources/zk-steward.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 ZK Steward 条目置于 specialized-korean-business-navigator 之后；entities/ 和 concepts/ 目录已创建并填充 2 个 Entity + 6 个 Concept 页面；无内容冲突检测（与 [[Second-Brain]] 为互补关系，详见 Contradictions 部分）。

## [2026-04-25] ingest | Korean Business Navigator
- Source file: Agent/agency-agents/specialized/specialized-korean-business-navigator.md
- Status: ✅ 成功摄入
- Summary: Korean Business Navigator——The Agency Specialized 部门的韩国商业文化导航 Agent，帮助外国专业人员解码韩国商业隐性规则。核心洞察：品의流程耗时 6-16 周，永远不要在第一次会议要求时间线；韩国"yes"≠同意，沉默=内部讨论进行中；成交发生在会议室外的走廊。六阶段品의时间线（소개→미팅→내부검토→품의서→결재→계약）、Nunchi 解码表（含"검토해보겠습니다"=婉拒等5+信号）、KakaoTalk 分阶段消息模板、韩国企业职级体系、Proof Project 策略。
- Concepts created: [[품의]]（韩国共识审批流程，含六阶段时间线及品의서/결재라인规范）、[[Nunchi]]（韩国文化"读心术"，含6+常用商业解码表）
- Entities created: [[KakaoTalk]]（韩国主流即时通讯平台，商务沟通核心渠道；群聊必须韩语、9AM-7PM KST商务时间、24h只读不回会被注意）
- Source page: wiki/sources/specialized-korean-business-navigator.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已移除并替换为完整条目；overview.md Specialized 部门新增 Korean Business Navigator 条目置于 specialized-french-consulting-market 之后；index.md 新增 Entities 条目（KakaoTalk）和 Concepts 条目（품의、Nunchi）；无内容冲突（与 Cultural Intelligence Strategist 为互补关系，已在 overview.md 建立链接）。

## [2026-04-25] ingest | French Consulting Market Navigator
- Source file: Agent/agency-agents/specialized/specialized-french-consulting-market.md
- Status: ✅ 成功摄入
- Summary: French Consulting Market Navigator——The Agency Specialized 部门的法国 IT 咨询市场（ESN/SI）生态导航 Agent，帮助独立顾问最大化 TJM 税后净收入。核心洞察：ESN Margin 25-40% 不透明；Portage Salarial vs Micro-Entrepreneur 税后收益差距 338€/天（社保保护价格）；付款延迟结构性 60-90 天；Malt 公开定价即为市场锚点。五大平台对比 + 三层 ESN 分层定价 + TJM 阶梯锚定谈判四步法。
- Concepts created: [[Portage-Salarial]]（Portage Salarial 机制完整解析：管理费5-10%、雇主/雇员社保合计~67%、700€/天→208€/天净）、[[ESN]]（Entreprise de Services Numériques 三级分类及 Margin 架构详解）
- Entities created: 无（平台 Malt/collective.work/Comet/Crème/Free-Work 及 ESN Cloudity/Accenture 仅出现1次，通过 Source Page Key Entities 保留）
- Source page: wiki/sources/specialized-french-consulting-market.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 specialized-french-consulting-market 条目置于 study-abroad-advisor 之后；Portage-Salarial 和 ESN 均已存在于 wiki/concepts/，无需重复创建，仅补充了本次来源的 sources 字段

## [2026-04-25] ingest | Blockchain Security Auditor
- Source file: Agent/agency-agents/specialized/blockchain-security-auditor.md
- Status: ✅ 成功摄入
- Summary: Blockchain Security Auditor——The Agency Specialized 部门的智能合约安全审计 Agent，专职发现 DeFi 协议与区块链应用中的漏洞。自动化静态分析（Slither/Mythril/Echidna）+ 人工逐行审查 + 属性化模糊测试 + 经济博弈建模五步工作流。每个发现必须包含可复现 PoC；自动化工具只能捕获约 30% 的真实漏洞；OpenZeppelin 误用本身是漏洞类型。
- Concepts created: [[Reentrancy]]（重入攻击，含单函数/跨函数/只读/ERC-777钩子四种模式及完整防御机制）、[[Oracle-Manipulation]]（预言机操纵，含AMM/TWAP/Chainlink三类模式及修复方案）
- Entities created: [[The-DAO-2016]]（2016年360万ETH重入攻击）、[[Euler-Finance]]（2023年1.97亿美元donate-to-reserves攻击）、[[Nomad-Bridge]]（2022年1.9亿美元未初始化代理漏洞）、[[Curve-Finance]]（2023年7000万美元Vyper编译器bug）
- Source page: wiki/sources/blockchain-security-auditor.md
- Notes: overview.md 同步更新；index.md 消除了原 source missing 标记并补全了摘要

## [2026-04-25] ingest | Agents Orchestrator
- Source file: Agent/agency-agents/specialized/agents-orchestrator.md
- Status: ✅ 成功摄入
- Summary: Agents Orchestrator——AI 多智能体开发流水线编排器，自主管理从规格到交付的完整开发流程。四阶段流水线（PM→ArchitectUX→[Dev↔QA循环]→最终集成），基于截图证据的质量门控，最大3次重试上限。
- Concepts created: 无（Dev-QA-Loop、Quality-Gate 等概念均通过 Source Page 内 wikilinks 形式表达，未单独建 Concept 页面）
- Entities created: 无（ArchitectUX、EvidenceQA、TestingRealityChecker、ProjectManagerSenior 等在现有 wiki 中已作为 wikilinks 使用，无需新建 Entity 页面）
- Source page: wiki/sources/agents-orchestrator.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Agents-Orchestrator 条目置于 identity-graph-operator 之后；与 specialized-workflow-architect 的职责关系已记录于 Contradictions 部分（设计层 vs 执行层，不存在功能重叠）。

## [2026-04-25] ingest | MCP Builder Agent
- Source file: Agent/agency-agents/specialized/specialized-mcp-builder.md
- Status: ✅ 成功摄入
- Summary: MCP Builder Agent——AI Agent 的 MCP（Model Context Protocol）服务器开发专家，设计、构建、测试和部署 MCP 服务器，为 AI Agent 提供自定义工具（Tools）、资源（Resources）和提示词模板（Prompts）能力。核心理念：工具命名即 UX，正确选用率目标 >90%；技术栈 TypeScript+Zod 或 Python+Pydantic；核心原则：无状态设计、结构化错误返回、环境变量密钥、边界验证、真实 Agent 测试。
- Concepts created: 无（Key Concepts 中 10 个术语均为 Source Page 内可解释的协议/框架级概念，通过 wikilinks 形式表达，不具备跨页面复用价值，未单独建 Concept 页面）
- Entities created: 无（MCP SDK/FastMCP/Zod/Pydantic 仅出现 1 次，不满足 ≥2 次条件，通过 Key Entities 链接保留在 Source Page）
- Source page: wiki/sources/specialized-mcp-builder.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 MCP Builder Agent 条目置于 visionos-spatial-engineer 之后；无冲突内容检测。

## [2026-04-25] ingest | Compliance Auditor Agent
- Source file: Agent/agency-agents/specialized/compliance-auditor.md
- Status: ✅ 成功摄入
- Summary: Compliance Auditor Agent——The Agency Specialized 部门的技术合规审计专家，专注 SOC 2、ISO 27001、HIPAA、PCI-DSS 认证审计全流程。五步工作流：Scoping → Gap Assessment → Remediation Support → Audit Support → Continuous Compliance。核心原则：不跟随的政策比没政策更危险、证据必须证明整个审计周期持续有效、技术控制优于管理控制、自动化证据收集从第一天建立。
- Concepts created: 无（Key Concepts 中 6 个术语均为 Source Page 内可解释的术语，不具备跨页面复用价值，未单独建 Concept 页面）
- Entities created: 无（SOC-2/ISO-27001/HIPAA/PCI-DSS 均为框架级标准，在多个来源中出现但以 wikilinks 形式表达，未单独建 Entity 页面）
- Source page: wiki/sources/compliance-auditor.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已移除并替换为完整条目；overview.md Specialized 部门新增 Compliance Auditor 条目置于 healthcare-marketing-compliance 之后；与 [[specialized-model-qa]] 在证据定义上的差异已记录于 Contradictions 部分。

## [2026-04-25] ingest | Specialized Salesforce Architect
- Source file: Agent/agency-agents/specialized/specialized-salesforce-architect.md
- Status: ✅ 成功摄入
- Summary: Salesforce 企业级解决方案架构师 Agent — 多云架构设计（Sales/Service/Marketing/Commerce/Data Cloud/Agentforce）、企业集成模式（REST/Platform Events/CDC/MuleSoft）、数据模型设计与治理、Governor Limit 预算规划、CI/CD 部署策略（Salesforce DX/DevOps Center）。核心原则：Governor limits 不可协商、Bulkification 强制要求、Declarative-first、Trigger 只委托不分发、集成模式必须处理失败场景。
- Concepts created: 无（技术术语通过 Source Page Key Concepts + wikilinks 表达，未单独建页面）
- Source page: wiki/sources/specialized-salesforce-architect.md
- Notes: 无冲突内容检测；MuleSoft、Shield Platform Encryption、DevOps Center 作为 Key Entities 链接保留在 Source Page；Platform Events vs CDC 对比表已提取为 Key Claims

## [2026-04-25] ingest | Model QA Specialist
- Source file: Agent/agency-agents/specialized/specialized-model-qa.md
- Status: ✅ 成功摄入
- Summary: Model QA Specialist——The Agency Specialized 部门的 ML/统计模型端到端独立审计专家 Agent，核心方法：10 大审计领域覆盖模型全生命周期（文档治理→数据重建→标签分析→分段评估→特征分析→模型复制→校准测试→性能监控→可解释性→业务影响），配套完整 Python 工具集（PSI 监控、Hosmer-Lemeshow 校准检验、SHAP 可解释性分析、PDP 偏依赖图、KS/AUC/Gini 判别指标）。核心原则：独立性、可复现性、证据链完整。成功指标：审计发现 95%+ 被确认有效、零部署后失败。
- Concepts created: [[SHAP]]（特征归因可解释性框架）、[[Calibration-Testing]]（概率校准验证方法）、[[Discrimination-Metrics]]（判别能力指标体系 AUC/Gini/KS）、[[Partial-Dependence-Plots]]（偏依赖图）、[[Population-Stability-Index]]（群体稳定性指数）、[[Hosmer-Lemeshow-Test]]（校准拟合优度检验）
- Entities created: （The Agency Specialized 部门在多个来源中多次出现，本次检查 entities/ 目录已存在，未新建）
- Source page: wiki/sources/specialized-model-qa.md
- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 Model QA Specialist 条目置于 cultural-intelligence-strategist 之后。与 [[multi-agent-system-reliability]] 存在潜在张力（对抗辩论 vs 统计检验），已在 Contradictions 中记录。6 个 Concept 页面创建前已做去重检查，确认均不存在。与 specialized-workflow-architect（Reality Checker 验证）构成质量保障互补，已在 overview.md 建立链接关系。


- Source file: Agent/agency-agents/specialized/corporate-training-designer.md
- Status: ✅ 成功摄入
- Summary: Corporate Training Designer——The Agency Specialized 部门的企业培训体系架构师 Agent，核心方法：ADDIE 教学设计模型（分析→设计→开发→实施→评估）、Kirkpatrick 四级评估（反应→学习→行为→业务结果）、Bloom 认知六层次、Kolb 体验式学习圈、OMO 混合学习（线上认知→线下实践→社群持续）。核心价值观：优秀培训的衡量标准不是"教了什么"，而是"学员回去做了什么"。覆盖培训需求分析、课程体系设计、内容开发、内训师培养（TTT）、新员工培训、领导力发展（HIPO）、合规培训等全链路能力。
- Concepts created: [[ADDIE-Model]]（ADDIE 教学设计模型）、[[Kirkpatrick-四级评估]]（培训效果四级评估框架）、[[Bloom-认知分类]]（认知六层次分类）、[[Kolb-体验式学习圈]]（体验式学习循环）
- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门）
- Source page: wiki/sources/corporate-training-designer.md
- Notes: index.md 中原有早期条目，本次为完整摄入。overview.md Specialized 部门新增 Corporate Training Designer 条目，并置于 Cultural Intelligence Strategist 之前（按摄取顺序）。4 个 Concept 页面创建前已做去重检查，确认均不存在。Corporate Training Designer 与 specialized-workflow-architect、cultural-intelligence-strategist 形成系统性设计能力互补，在 overview.md 中已建立链接关系。Corporate Training Designer 与其他 Agent 无明显内容冲突。

- Source file: Agent/agency-agents/specialized/specialized-cultural-intelligence-strategist.md
- Status: ✅ 成功摄入
- Summary: Cultural Intelligence Strategist——The Agency Specialized 部门的文化包容性专家 Agent，核心职责：检测软件开发中的"隐性排斥"（Invisible Exclusion），包括 Western 默认命名结构、颜色语义冲突（红色=中国金融上涨）、性别二元假设、RTL 阅读方向等。通过四阶段工作流（盲点审计→自主研究→结构修正→解释原理）提供架构级文化智能解决方案。核心价值：将国际化从"亡羊补牢"提升为"架构前提条件"，拒绝表演性多元化，追求结构性包容。
- Concepts created: [[Invisible-Exclusion]]（隐性排斥模式定义）、[[Architectural-Empathy]]（结构性同理心哲学）、[[Global-First-Architecture]]（国际化架构前提原则）
- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门）
- Source page: wiki/sources/specialized-cultural-intelligence-strategist.md
- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 Cultural Intelligence Strategist 条目。Concept 页面创建前已做去重检查，确认 Invisible-Exclusion、Architectural-Empathy、Global-First-Architecture 三个概念此前均不存在。与 [[InclusiveVisualsSpecialist]]（Design 部门包容性视觉专家）和 [[design-brand-guardian]]（品牌守护）存在跨部门协同与张力关系，已在 overview.md 和 source page Contradictions 中记录。

## [2026-04-25] ingest | Workflow Architect Agent Personality
- Source file: Agent/agency-agents/specialized/specialized-workflow-architect.md
- Status: ✅ 成功摄入
- Summary: Workflow Architect——The Agency Specialized 部门的工作流设计专家 Agent，负责在代码编写前穷举建模系统所有路径。核心交付物：四视角工作流注册表（按工作流/按组件/按用户旅程/按状态）+ 工作流树规范格式（覆盖快乐路径+七类失败分支）+ 交接合同（Handoff Contract）+ 清理清单（Cleanup Inventory）。关键原则：不只为快乐路径设计，每个系统边界定义显式交接合同，Reality Checker 验证是 Draft 升为 Approved 的前置条件。Agent 协作协议：Reality Checker 验证→Backend Architect 实现→API Tester 生成测试用例→DevOps Automator 验证清理顺序。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（确定性要求 vs LLM 概率性），已在 Contradictions 中记录。
- Concepts created: [[Workflow-Registry]]（四视角工作流注册表）、[[Observable-States]]（四维度可观察状态）、[[Handoff-Contract]]（系统边界交接合同）、[[Workflow-Tree-Spec]]（结构化工作流树规范格式）
- Entities created: （Backend Architect/Reality Checker/API Tester/DevOps Automator/Security Engineer 在当前 sources 中出现次数均 < 2，暂不创建 Entity 页面）
- Source page: wiki/sources/specialized-workflow-architect.md
- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目并修正日期。overview.md Specialized 部门新增 Workflow Architect 条目。Concept 页面创建前已做去重检查，Workflow-Engineering（已存在，定义侧重 AI 执行流程 vs 本文档侧重工作流规范格式）保留原页面，新增页面侧重建模规范维度。

## [2026-04-25] ingest | LSP/Index Engineer Agent Personality
- Source file: Agent/agency-agents/specialized/lsp-index-engineer.md
- Status: ✅ 成功摄入
- Summary: LSP/Index Engineer——The Agency Specialized 部门的代码智能系统架构师 Agent，通过 graphd LSP 聚合器将 TypeScript/PHP/Go/Rust/Python 等多语言 LSP 客户端统一编排为语义图谱。核心交付物：多语言 LSP 并发编排 + 统一图谱模式（节点：文件/符号，边：contains/imports/calls/refs）+ nav.index.jsonl 语义索引 + WebSocket 实时增量推送 + 原子性图谱更新保证。性能北极星：/graph <100ms、/nav <60ms、WebSocket <50ms、100k+ 符号无性能降级。TypeScript 和 PHP 为默认生产就绪要求。
- Concepts created: [[LSP-317-Specification]]（LSP 3.17 协议规范）、[[Semantic-Index-Infrastructure]]（语义索引基础设施）、[[Incremental-Graph-Update]]（增量图谱更新）、[[Performance-Contracts]]（性能契约）
- Entities created: [[The-Agency]]（The Agency 多智能体系统组织）、[[TypeScript-Language-Server]]（TypeScript 语言服务器）、[[Intelephense]]（PHP Intelephense LSP）、[[LSIF]]（Language Server Index Format）
- Source page: wiki/sources/lsp-index-engineer.md
- Notes: index.md 中原有 "source missing" 条目，本次摄入后已更新为完整条目。overview.md Specialized 部门新增 LSP/Index Engineer 条目，并同步更新 Conflict Areas（#12 LSP 图谱确定性 vs Workflow 穷举概率性）。4 个 Concept 页面创建前已做去重检查，确认 LSP-317-Specification、Semantic-Index-Infrastructure、Incremental-Graph-Update、Performance-Contracts 均不存在。与 [[specialized-workflow-architect]] 存在张力（确定性约束 vs LLM 概率性上限），已在 Contradictions 中记录。4 个 Entity 页面中 The-Agency 已在 overview.md 中被多次引用，新增 Entity 页面属首次正式创建。与 [[multi-agent-system-reliability]] 共享"架构约束优于提示词约束"思想，已在 overview.md 中建立链接。

## [2026-04-25] ingest | Agentic Identity & Trust Architect（补充摄入）
- Source file: Agent/agency-agents/specialized/agentic-identity-trust.md
- Status: ✅ 补充摄入（source page 已存在，本次补充 Concept 页面）
- Summary: Agentic Identity & Trust Architect——自主 Agent 身份认证与信任验证基础设施专家 Agent，解决多 Agent 环境中的身份伪造、授权冒用、审计日志篡改等安全威胁。核心方法：密码学身份体系（Ed25519）、零信任验证模型、惩罚型信任评分（初始1.0，证据链损坏扣0.5，结果失败率×0.4扣分，凭证超90天扣0.1）、append-only 哈希链式证据记录、多跳委托链验证（任意链节断裂则全链失效）、Fail-Closed 授权（无法验证时默认拒绝）、对等验证协议（Peer Verifier）。高级能力：算法敏捷性（后量子迁移预留抽象层）、NIST 后量子标准评估（ML-DSA/ML-KEM/SLH-DSA）、跨框架身份联邦（A2A/MCP/REST/SDK）。
- Concepts created: [[Zero-Trust]]（永不信任，必须验证）、[[Evidence-Chain]]（哈希链式仅追加证据记录）、[[Trust-Scoring]]（基于可验证结果的惩罚型信任评分）、[[Delegation-Chain]]（多跳委托链验证）、[[Fail-Closed]]（失败默认拒绝授权）、[[Peer-Verification]]（对等验证协议）、[[Algorithm-Agility]]（密码学算法可升级性）
- Source page: wiki/sources/agentic-identity-trust.md
- Notes: 与 [[Identity Graph Operator]] 互补——前者处理 Agent 身份证明（密码学确定性），后者处理实体身份匹配（概率性），共同构成完整身份层。与 [[Designing-for-Agentic-AI]] 存在潜在冲突（零信任要求确定性 vs LLM 概率性），已在 Contradictions 中记录。本文件在 index.md中原标记为"source missing"，本次已补全为完整 source page。
- Source file: Agent/agency-agents/specialized/specialized-document-generator.md
- Status: ✅ 成功摄入
- Summary: Document Generator——The Agency Specialized 部门的程序化文档生成专家 Agent，通过代码方式（Python/Node.js）生成 PDF、PPTX、DOCX、XLSX 等专业文档。核心工具栈：PDF（reportlab/weasyprint/fpdf2）、PPTX（python-pptx/pptxgenjs）、XLSX（openpyxl/xlsxwriter/exceljs）、DOCX（python-docx/docx）。核心原则：样式系统优先、品牌一致性、数据驱动、无障碍设计、模板可复用。
- Concepts created: 无（文档生成工具库不宜抽象为 Concept）
- Source page: wiki/sources/specialized-document-generator.md
- Notes: index 中已存在同名条目（来源缺失），本次摄入后标记为已解决。与 [[report-distribution-agent]]（文档分发）和 [[agents-orchestrator]]（工作流编排）存在潜在协同关系，建议后续摄入时补充连接。

- Source file: Agent/agency-agents/specialized/identity-graph-operator.md
- Status: ✅ 成功摄入
- Summary: Identity Graph Operator——多智能体系统共享身份图谱运营专家 Agent，解决多 Agent 系统的身份孤岛问题（重复记录/冲突操作/级联错误）。核心方法：规范化（昵称扩展/E.164 电话/邮箱小写）→ 阻塞（blocking key 筛选候选）→ 评分（字段级加权）→ 聚类。merge/split 通过乐观锁执行，按置信度分级（>0.95 直接合并、0.6-0.95 提案审查、<0.6 创建新实体）。保留完整事件历史。
- Concepts created: [[Identity-Resolution]]（身份解析四步流程框架）、[[Evidence-based-Merge-Proposal]]（证据驱动合并提案协议）、[[Blocking]]（阻塞分块技术）、[[Fuzzy-Matching]]（模糊匹配技术）、[[Confidence-Score]]（置信度评分与阈值决策）
- Source page: wiki/sources/identity-graph-operator.md
- Notes: 与 [[Designing-for-Agentic-AI]] 存在潜在冲突：确定性要求与 LLM 概率性行为如何协调，当前观点认为通过将核心逻辑从 LLM 推理分离来解决。index 中已存在同名 [[identity-graph-operator]] 条目（来源缺失），本次摄入后应标记为已解决。

## [2026-04-25] ingest | Accounts Payable Agent Personality
- Source file: Agent/agency-agents/specialized/accounts-payable-agent.md
- Status: ✅ 成功摄入
- Summary: AccountsPayable Agent——The Agency 财务部门的自主支付运营专员 Agent，处理供应商付款、承包商发票和周期性账单，覆盖 ACH/Wire/Crypto/Stablecoin/Payment API 全支付通道。核心原则：幂等性优先（reference ID 去重，零重复付款）、审计全链路、最优通道路由（失败自动切换备选通道）、严格额度管控（超授权额度人工审批）。通过 tool calls 与 Contracts Agent、Project Manager Agent、HR Agent 集成。成功指标：零重复付款、< 2 分钟执行时间、100% 审计覆盖、60 秒 escalation SLA。
- Concepts created: （文档内概念均为具体实现细节，不满足可独立复用条件，未创建 Concept 页面）
- Entities created: （各协作 Agent 在本文档中各仅出现 1 次，不满足出现 ≥ 2 次条件，未创建 Entity 页面）
- Source page: wiki/sources/accounts-payable-agent.md
- Notes: 无已知冲突。本文档为单一 Agent 设计文档，与 [[Accounts-Payable-Agent]] 协作的各 Agent 需在各自文档中补充对应协作关系。

## [2026-04-25] ingest | Specialized Civil Engineer Agent
- Source file: Agent/agency-agents/specialized/specialized-civil-engineer.md
- Status: ✅ 成功摄入
- Summary: Civil Engineer Agent——全球设计标准覆盖的结构与土木工程专家 Agent，驾驭 Eurocode（EN 1990–1999 + 各国 National Annex）、ACI 318（LRFD/SD）、AISC 360、ASCE 7、GB/IS/AIJ 等全球主流建筑规范体系。核心方法：ULS+SLS 双重验证、多标准冲突处理（识别→记录→保守优先→Basis of Design）、岩土工程全流程。计算交付物：钢梁 AISC 360 LRFD 计算包、RC 梁 Eurocode EN 1992-1-1 计算包、Terzaghi 岩土地基承载力分析。六阶段工作流：项目范围→初步设计→详细计算→建造文档→规范合规→施工支持。
- Concepts created: [[ULS]], [[SLS]], [[National-Annex]], [[LRFD]], [[Basis-of-Design]], [[BIM-Coordination]], [[Ductility-Class]]
- Entities created: [[Eurocode]], [[AISC-360]], [[ACI-318]], [[ASCE-7]], [[EN-1997]], [[AIJ]]
- Source page: wiki/sources/specialized-civil-engineer.md
- Notes: 无已知冲突。该 Agent 覆盖全球独立规范体系，各标准间差异已明确标注，不可混用。

- Source file: Agent/agency-agents/project-management/project-management-experiment-tracker.md
- Status: ✅ 成功摄入
- Summary: Experiment Tracker Agent——The Agency 项目管理部门的实验追踪专家 Agent，专注于 A/B 测试、功能实验和假设验证的科学化管理。核心交付物：实验设计文档模板和实验结果报告模板。成功指标：95% 实验达统计显著性、每季度 15+ 实验、70% 成功率、80% 成功实验落地。高级能力：多臂老虎机、贝叶斯分析、因果推断、ML 模型 A/B 测试。
- Concepts created: [[A/B-Testing]], [[Statistical-Significance]], [[Power-Analysis]], [[Hypothesis-Validation]], [[Experiment-Portfolio-Management]], [[Multi-Armed-Bandits]], [[Bayesian-Analysis]], [[Causal-Inference]]
- Entities created: [[Project-Management-Experiment-Tracker]]
- Source page: wiki/sources/project-management-experiment-tracker.md
- Notes: 与 [[Project-Management-Studio-Operations]] 存在潜在张力（实验节奏 vs 内容制作节奏），已记录于 Contradictions

## [2026-04-25] ingest | Studio Operations Agent Personality
- Source file: Agent/agency-agents/project-management/project-management-studio-operations.md
- Status: ✅ 成功摄入
- Summary: Studio Operations Agent——The Agency 项目管理部门的执行层 Agent，专注于工作室日常运营效率、流程优化和资源协调。核心交付物：SOP 模板（四步工作流：评估→协调→实施→监控）和运营效率报告模板。成功指标：95% 运营效率、99.5% 系统正常运行时间、年度成本降低 10%、支持响应时间 < 2 小时。
- Concepts created: （本次未创建独立 Concept 页面——文档内各概念（Standard Operating Procedure/Operational Efficiency 等）均与 [[The Agency]] 生态强绑定，不满足可独立复用条件）
- Entities created: （本次未创建独立 Entity 页面——文档内唯一实体 [[The Agency]] 在 Wiki 中已有充分引用）
- Source page: wiki/sources/project-management-studio-operations.md
- Notes: 与 [[project-management-studio-producer]]（战略层）和 [[ProjectManagerSenior]]（任务分解层）构成完整项目管理体系层级；与 [[Project-Management-Jira-Workflow-Steward]] 和 [[Project-Management-Project-Shepherd]] 协同；index.md 中标记的 expected 条目已补全

## [2026-04-25] ingest | Senior Project Manager Agent Personality
- Source file: Agent/agency-agents/project-management/project-manager-senior.md
- Status: ✅ 成功摄入
- Summary: Senior Project Manager——The Agency 项目管理部门的执行层 Agent，专注于将网站规格文档（site-setup.md）精准转化为 30-60 分钟可执行开发任务列表。核心方法：精确引用规格原则 + 务实范围控制（拒绝 luxury/premium 除非明确）+ 开发者优先任务描述。核心约束：不添加后台进程、不启动开发服务器、必须包含 Playwright 截图测试。
- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛）
- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛）
- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 存在职责边界张力——Senior PM 关注任务拆解细节，Shepherd 关注项目整体把控；两者形成执行层与规划层的协作关系，记录于 Source Page Contradictions 部分
- Source page: wiki/sources/project-manager-senior.md
- Notes: index.md 占位符条目已替换（添加中文摘要）；overview.md 已补充 [[ProjectManagerSenior]] 独立段落，完善了项目管理层级的战略-执行协作关系描述

## [2026-04-25] ingest | Jira Workflow Steward Agent Personality
- Source file: Agent/agency-agents/project-management/project-management-jira-workflow-steward.md
- Status: ✅ 成功摄入
- Summary: Jira Workflow Steward——交付纪律守护者 Agent，通过 Jira-Git 全链路绑定（Task→Branch→Commit→PR→Release）确保代码交付可审查、可回滚、可审计。核心机制：Jira Gate（无 Jira ID 则停止工作流）+ 分支策略（feature/bugfix/hotfix/release）+ Gitmoji 规范提交 + PR 模板 + Commit Hook 自动化验证。定位：Jira-linked commits 是质量工具而非合规打勾。
- Concepts created: [[Jira-Git-Traceability]], [[Atomic-Commit]], [[Branch-Strategy]], [[Gitmoji-Commit]], [[Jira-Gate]], [[Pull-Request-Governance]], [[Delivery-Traceability]]
- Entities created: [[Jira-Workflow-Steward]], [[Gitmoji]]
- Contradictions detected: 与 [[Project-Management-Project-Shepherd]] 在职责边界存在互补张力——Steward 严格 gate（Jira ID 前置），若 Shepherd 未预创建任务则工作流中断，建议在 Shepherd 端增加预创建步骤；与 [[Project-Management-Studio-Producer]] 在交付粒度上属不同抽象层级（原子 commit vs 组合 Epic/Story），无直接冲突
- Source page: wiki/sources/project-management-jira-workflow-steward.md
- Notes: 7 个 Concept 页面已创建并添加到 index.md；2 个 Entity 页面已创建（Jira-Workflow-Steward/Gitmoji）并添加到 index.md；source page 已添加与 Project-Management-Project-Shepherd 和 Studio-Producer 的跨文档矛盾记录；index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要）

## [2026-04-25] ingest | Project Shepherd Agent Personality
- Source file: Agent/agency-agents/project-management/project-management-project-shepherd.md
- Status: ✅ 成功摄入
- Summary: Project Shepherd——AI Agent 项目管理人格，专职跨职能项目协调、时间线管理、干系人对齐与风险缓解。四阶段工作流：项目启动→团队组建→执行监控→质量交付。核心交付物：Project Charter 模板、Status Report 模板、风险缓解框架。成功指标：95% 按时交付、范围蔓延 < 10%、90% 风险提前缓解、干系人满意度 4.5/5。
- Concepts created: （本次未创建独立 Concept 页面——文档内各概念均仅出现 1 次，不满足 ≥ 2 次创建门槛）
- Entities created: （本次未创建独立 Entity 页面——文档内各实体均仅出现 1 次，不满足 ≥ 2 次创建门槛）
- Contradictions detected: 无。本文档与 [[Project-Management-Studio-Operations]] 和 [[Project-Management-Senior]] 在项目管理层级上互补而非冲突，属层级差异。
- Source page: wiki/sources/project-management-project-shepherd.md
- Notes: index.md 占位符条目已替换（2026-04-20 → 2026-04-25，添加中文摘要）；overview.md 第 65 行已包含 [[Project-Management-Project-Shepherd]] wikilink（项目管理层级链一环），无需额外修订

## [2026-04-25] ingest | Studio Producer Agent Personality
- Source file: Agent/agency-agents/project-management/project-management-studio-producer.md
- Status: ✅ 成功摄入
- Summary: Studio Producer——The Agency 项目管理部门的高管级战略领导者 Agent，专注于创意愿景与商业目标对齐的组合管理。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级）、Portfolio ROI 管理（≥ 25%）、95% 按时交付率、高管级利益相关者沟通。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。
- Concepts created: [[Strategic-Portfolio-Management]], [[Resource-Allocation]], [[Portfolio-ROI]], [[Innovation-Pipeline]], [[Stakeholder-Alignment]]
- Entities created: [[Studio-Producer]]
- Contradictions detected: 与 [[Project-Management-Studio-Operations]] 在战略（Producer）与运营（Operations）的权责边界存在张力，需通过 Portfolio Review 机制对齐；与 [[Project-Manager-Senior]] 的管理广度差异（组合 vs 单项目）属层级差异而非矛盾
- Source page: wiki/sources/project-management-studio-producer.md
- Notes: 已在 overview.md 新增 "The Agency — Project Management 部门" 章节（位于 Paid Media 部门之前），包含 Studio Producer 完整段落及与其他项目管理 Agent 的层级关系描述；5 个 Concept 页面已创建；index.md 中 source 条目已替换（2026-04-20 → 2026-04-25）；Studio-Producer Entity 页面已创建并添加至 index.md

## [2026-04-25] ingest | visionOS Spatial Engineer Agent Personality
- Source file: Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md
- Status: ✅ 成功摄入
- Summary: visionOS Spatial Engineer——Apple visionOS 26 原生空间计算 Agent，专注于 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质设计、Spatial Widgets、SwiftUI Volumetric APIs、RealityKit-SwiftUI 集成、Multi-Window Architecture、GPU 高效渲染。技术栈：SwiftUI / RealityKit / ARKit / Metal。
- Concepts created: [[Liquid-Glass-Design-System]], [[Spatial-Widgets]], [[SwiftUI-Volumetric-APIs]], [[RealityKit-SwiftUI-Integration]], [[Multi-Window-Architecture]]
- Entities created: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[XR-Cockpit-Interaction-Specialist]], [[macOS-Spatial-Metal-Engineer]]
- Contradictions detected: 与 [[XR-Immersive-Developer]] 在平台选择上存在差异（WebXR 跨平台 vs visionOS 原生独占），已记录于 Source Page Contradictions 部分；与 [[macOS-Spatial-Metal-Engineer]] 在技术栈选择上存在张力（SwiftUI 声明式 vs Metal 底层渲染），已记录为互补关系
- Source page: wiki/sources/visionos-spatial-engineer.md
- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-25，添加摘要描述）；overview.md 已新增独立段落（位于 macOS Spatial/Metal Engineer 段落后）；5 个 Concept 页面已创建并添加到 index.md；4 个 Entity 页面已创建（XR-Interface-Architect/XR-Immersive-Developer/XR-Cockpit-Interaction-Specialist/macOS-Spatial-Metal-Engineer）并添加到 index.md；相关 Entity 和 Concept 页面的 sources 列表已更新

## [2026-04-25] ingest | XR Interface Architect Agent Personality
- Source file: Agent/agency-agents/spatial-computing/xr-interface-architect.md
- Status: ✅ 成功摄入
- Summary: XR Interface Architect——专注为 AR/VR/XR 沉浸式环境设计空间直觉化 UX/UI 的 AI Agent，支持 HUD / 浮动菜单 / 交互区域，支持四种输入模型（直接触摸/注视+捏合/控制器/手势），以人体工程学约束减少晕动症，构建座舱/仪表盘/可穿戴界面布局模板，运行可用性验证实验
- Concepts created: [[SpatialInterfaceDesign]], [[MotionSicknessMitigation]], [[PresenceEnhancement]], [[MultimodalInput]], [[HUDDesign]]
- Entities created: [[XRImmersiveDeveloper]], [[XRCockpitInteractionSpecialist]]
- Contradictions detected: 无内容冲突；该 Agent 侧重界面设计与 UX，与侧重底层渲染工程的 [[macOS Spatial/Metal Engineer]] 不在同一问题域
- Source page: wiki/sources/xr-interface-architect.md
- Notes: 更新了 overview.md 中 [[xr-cockpit-interaction-specialist]] 条目的层级关系描述（原文为 [[XR-Interface-Architect]]，现统一为小写 slug）；Entity 仅出现 1 次，不足独立建页阈值，通过 Sources 页面 Key Entities 建立链接

## [2026-04-25] ingest | Terminal Integration Specialist
- Source file: Agent/agency-agents/spatial-computing/terminal-integration-specialist.md
- Status: ✅ 成功摄入
- Summary: Terminal Integration Specialist——专注于终端仿真、文本渲染优化和 SwiftTerm 集成的 Agent，服务于现代 Swift 应用程序（iOS/macOS/visionOS）。核心能力：VT100/xterm ANSI 转义序列完整支持、SwiftTerm 库集成、Core Graphics 文本渲染优化、SSH I/O 桥接（SwiftNIO SSH/NMSSH）、无障碍支持（VoiceOver/动态类型）。
- Concepts created: [[VT100/xterm Standards]], [[SwiftTerm]], [[Core Graphics Optimization]], [[SSH I/O Bridging]], [[Scrollback Buffer]], [[Accessibility Integration]]
- Contradictions detected: 无明显内容冲突；该 Agent 专注于 Apple 平台和 SwiftTerm，与通用终端解决方案不在同一问题域
- Source page: wiki/sources/terminal-integration-specialist.md
- Notes: 相关页面已建立连接：[[visionOS Spatial Engineer]] / [[macOS Spatial Metal Engineer]] / [[XR Interface Architect]] 均依赖终端集成能力；Entity 层面 SwiftTerm/SwiftNIO SSH/NMSSH/Core Graphics/Core Text 仅出现 1 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接

## [2026-04-25] ingest | XR Immersive Developer Agent Personality
- Source file: Agent/agency-agents/spatial-computing/xr-immersive-developer.md
- Status: ✅ 成功摄入
- Summary: XR Immersive Developer Agent——WebXR 沉浸式开发专家，基于 A-Frame/Three.js/Babylon.js 构建跨平台浏览器 AR/VR/XR 体验。核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller）、raycasting / hit testing / 实时物理交互、LOD / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。
- Concepts created: [[Spatial-Computing]], [[WebXR]], [[Hand-Tracking]]
- Contradictions detected: 与 [[XR-Cockpit-Interaction-Specialist]] 在运动自由度设计上存在张力——后者强调固定视角约束（降低运动病），前者倾向开放空间沉浸体验；冲突点已记录于 overview.md 第 52 条及 [[xr-cockpit-interaction-specialist]] 来源页 Contradictions 节
- Source page: wiki/sources/xr-immersive-developer.md
- Notes: Concept 页面 Spatial-Computing/WebXR/Hand-Tracking 已创建并添加到 index.md；overview.md 新增 xr-immersive-developer 独立段落（位于 Paid Media 部门之前）；Entity 层面，Meta Quest/Vision Pro/HoloLens/Mobile-AR 仅出现 1-2 次，不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接

## [2026-04-25] ingest | Sales Engineer Agent
- Source file: Agent/agency-agents/sales/sales-engineer.md
- Status: ✅ 成功摄入
- Summary: Sales Engineer Agent——售前工程师 Agent，专注于在 B2B 技术评估中赢得技术决策。核心理念：技术决策先于商业合同，售前工程师必须将每一次技术对话连接到业务成果。核心能力：Demo Engineering（以影响力为导向的演示设计）+ POC Scoping（严格限定的概念验证）+ FIA Framework（Fact-Impact-Act 竞争定位）+ 技术异议解码 + 评估笔记维护。成功指标：技术赢率 70%+，POC 转化率 80%+，演示到下一步行动率 90%+，中位数 18 天技术决策。
- Concepts created: [[Demo-Engineering]], [[POC-Scoping]], [[FIA-Framework]], [[Technical-Objection-Handling]], [[Aha-Moment]]
- Contradictions detected: 与 [[Sales Discovery Coach Agent]] 在技术发现阶段参与深度上存在张力——前者主张售前主导技术发现，后者主张销售发现以业务语言建立信任，已记录于 overview.md Conflict Areas 第 6 条
- Source page: wiki/sources/sales-engineer.md
- Notes: 5 个新 Concept 页面已创建；overview.md 新增 sales-engineer 独立段落；index.md 新增 Sales Engineer Agent 条目；Conflict Areas 新增第 6 条；Entity 层面，Sales Engineer 与同团队其他 Agent 均仅出现 1-2 次，不足独立 Entity 建页阈值，已通过 Sources 页面的 Key Entities 部分建立链接

## [2026-04-25] ingest | Pipeline Analyst Agent
- Source file: Agent/agency-agents/sales/sales-pipeline-analyst.md
- Status: ✅ 成功摄入
- Summary: Pipeline Analyst Agent——Revenue Operations 领域的 Pipeline 健康诊断与收入预测 AI Agent。核心框架：Pipeline Velocity =（合格机会数 × 平均 Deal 规模 × 胜率）/ 销售周期长度；质量调整覆盖度（高质量少量 Pipeline 优于大量低质量 Pipeline）；MEDDPICC Deal 健康评分（资格深度 + 互动强度 + 进展速度三维度 0-36 分）；多信号预测模型（历史转化 + Velocity 加权 + 互动调整 + 季节性 + AI 模式匹配）。预测输出 Commit（>90%）/Best Case（>60%）/Upside（<60%）三档。
- Concepts created: [[MEDDPICC]], [[PipelineVelocity]], [[DealHealthScoring]], [[QualityAdjustedCoverage]]
- Contradictions detected: sales-coach.md 描述 MEDDPICC 为"六个维度"，正确为八个维度，已修正
- Source page: wiki/sources/sales-pipeline-analyst.md
- Notes: Entity 层面，Pipeline Analyst 与 Sales Deal Strategist / Sales Account Strategist / Sales Coach 存在依赖关系，待相关 Source 页面完善后可进一步深化链接

## [2026-04-25] ingest | Outbound Strategist Agent
- Source file: Agent/agency-agents/sales/sales-outbound-strategist.md
- Status: ✅ 成功摄入
- Summary: Outbound Strategist Agent——信号型出站销售策略师，将出站从"批量轰炸"转变为"精准触发"。核心理念：信号驱动出站转化率比无触发出站高 4-8 倍；信号半衰期 30 分钟，24 小时后失效，72 小时后竞争对手已成交。核心框架：三层信号分级体系（主动购买/组织变化/技术行为）+ 可证伪 ICP 定义 + 三层账户分级（Tier 1 深度多线程 / Tier 2 半个性化 / Tier 3 自动化轻定制）+ 8-12 触点 3-4 周多渠道序列。冷邮件回复率基准：泛化 1-3%、角色定制 5-8%、信号驱动 12-25%、推荐引入 30-50%。SDR 角色演变：从批量操作员 → 深度账户专家。
- Concepts created: [[Signal-Based-Selling-Framework]], [[ICP (Ideal Customer Profile)]], [[Multi-Channel-Sequence-Architecture]], [[Account-Tiering-Model]]
- Concepts updated: [[Challenger-Sales-Model]]（sources 添加 sales-outbound-strategist）、[[Land-and-Expand]]（sources 添加 sales-outbound-strategist）
- Entities linked: Outbound Strategist Agent, SDR
- Source page: wiki/sources/sales-outbound-strategist.md
- Notes: overview.md 新增"### Sales Outbound Methodology"章节（位于 Sales Discovery Methodology 之前）；index.md Concepts 节新增 4 个概念条目；Entity 页面未创建（Outbound Strategist Agent 和 SDR 均仅出现 1 次，不足独立建页阈值）；与 [[sales-deal-strategist]] 的漏斗互补关系已记录（出站=漏斗顶部，Deal=漏斗中部）

## [2026-04-25] ingest | Deal Strategist Agent
- Source file: Agent/agency-agents/sales/sales-deal-strategist.md
- Status: ✅ 成功摄入
- Summary: Deal Strategist Agent——高级deal策略师与管线架构师智能体，专注于MEDDPICC资质评分、竞争定位和复杂B2B销售周期的赢单规划。核心理念：每个deal都是战略问题而非关系练习；MEDDPICC全面推行的组织赢率提升18%、deal规模扩大24%；Commit deals预测准确率85%+；Qualified Pipeline（28/40+）赢率35%+；永远不做单线程账户。核心框架：MEDDPICC八维评分（每维度5分，满分40）+ Challenger商业教学六步序列 + 竞争三区定位（Winning/Battling/Losing）+ 地雷问题布局 + 交易检查方法论。
- Concepts updated: [[MEDDPICC]]（新增 Deal-Level Application 和 Deal Verdict Categories）、[[Challenger Sales Model]]（新增 Commercial Teaching 六步序列）
- Entities linked: [[Sales Coach Agent]], [[Discovery Coach Agent]], [[Sales Proposal Strategist]], Deal Strategist Agent（均出现1次，不足独立Entity建页阈值）
- Source page: wiki/sources/sales-deal-strategist.md
- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-25）；overview.md 已新增独立段落（Sales Coaching Methodology 章节末尾）；MEDDPICC 和 Challenger Sales Model 两个 Concept 页面均已更新 sources 列表 + 新增 sales-deal-strategist 专属内容；未创建新 Entity/Concept 页面（Deal Scoring/Competitive Positioning/Win Planning 等概念在 sales-deal-strategist 源文档中均仅出现1次，不足独立建页阈值）；与 [[sales-discovery-coach]] 的"发现→策略"协同关系已记录；与 [[sales-proposal-strategist]] 在"策略分析 vs 叙事构建"上的互补关系已记录于 Contradictions

## [2026-04-25] ingest | Account Strategist Agent
- Source file: Agent/agency-agents/sales/sales-account-strategist.md
- Status: ✅ 成功摄入
- Summary: Account Strategist Agent——售后账户扩张策略师智能体，专门负责 Land-and-Expand 执行、QBR 设计、利益相关者映射和净收入留存（NRR）最大化。核心理念：最佳销售时机是客户成功时；永远不做单线程账户；NRR 是终极指标。核心框架：扩张信号四维度（信号+情境+时机+利益相关者对齐）、账户健康三色评分（绿扩张/黄稳定/红救流失）、多线程关系建设（每账户至少三条独立关系线）。
- Concepts created: [[Land-and-Expand]], [[Net Revenue Retention (NRR)]], [[Account Health Score]]
- Entities linked: Account Executive (AE), Customer Success (CS), Product Team, Executive Sponsor
- Source page: wiki/sources/sales-account-strategist.md
- Notes: 与 [[sales-proposal-strategist]] 的"赢单叙事"互补（前者构建叙事，后者交付超越叙事）；与 [[sales-coach]] 协同（后者辅导卖方，前者辅导买方冠军）；与 [[sales-discovery-coach]] 形成完整销售生命周期覆盖（发现→赢单→扩张）；overview.md 新增"Sales Account Expansion Methodology"主题节；创建 3 个独立 Concept 页面（Land-and-Expand、NRR、Account Health Score）

## [2026-04-25] ingest | Sales Proposal Strategist
- Status: ✅ 成功摄入
- Summary: Sales Proposal Strategist——将 RFP 响应转化为赢单叙事的系统化提案方法论。核心框架：三幕提案叙事结构（理解挑战→解决方案旅程→转变状态）+ 3-5 个赢标主题矩阵 + 执行摘要五步模板 + 说服架构（首因/近因效应、认知负荷管理、社会认同排序、损失厌恶框架）。核心理念：提案在开篇100词决定胜负；叙事是差异化核心；永远不直接批评竞争对手；定价在价值之后；内容库按赢标主题而非章节组织。
- Concepts created: [[WinThemes]], [[ThreeActProposalNarrative]], [[PersuasionArchitecture]]
- Entities linked: 无特定命名实体
- Source page: wiki/sources/sales-proposal-strategist.md
- Notes: 与 [[sales-coach]] 在"辅导行为 vs 撰写结构"上形成 Sales 体系互补关系；与 [[sales-discovery-coach]] 的发现阶段输入为提案策略提供买方情境；无冲突发现；overview.md 暂不需要更新

## [2026-04-25] ingest | Sales Coach Agent
- Source file: Agent/agency-agents/sales/sales-coach.md
- Status: ✅ 成功摄入
- Summary: Sales Coach Agent——AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长。核心辅导框架：Richardson Sales Performance（四维能力）、Challenger 辅导模型、MEDDPICC 资质诊断。关键方法论：辅导行为而非结果；一次只做一件事；管道质量是管理工具；挑战"happy ears"要求可验证的承诺。数据支撑：正式辅导项目配额完成率91.2%，vs 非正式辅导84.7%；每周2小时辅导赢单率56%，vs 少于30分钟43%。
- Concepts created: MEDDPICC, Challenger Sales Model
- Entities linked: Discovery Coach Agent（已有）、Sales Pipeline Analyst Agent（已有）、Sales Deal Strategist Agent（已有）
- Source page: wiki/sources/sales-coach.md
- Notes: 与 Discovery Coach Agent 的辅导焦点层次差异已记录于 Contradictions；source页面内 Key Concepts 详细记录了 MEDDPICC、Challenger、Richardson Sales Performance 等框架；overview.md 新增"Sales Coaching Methodology"主题节，置于"Sales Discovery Methodology"之后，两者协同关系已明确

## [2026-04-25] ingest | Discovery Coach Agent
- Source file: Agent/agency-agents/sales/sales-discovery-coach.md
- Status: ✅ 成功摄入
- Summary: Discovery Coach Agent——销售发现访谈方法论教练智能体，坚信发现是交易成败的真正战场。整合三大发现框架（SPIN Selling / Gap Selling / Sandler Pain Funnel）+ 标准30分钟发现电话结构（开场2分钟 / 发现18分钟 / 定向pitch 6分钟 / 下一步4分钟）+ AECR异议处理框架（Acknowledg/Empathize/Clarify/Reframe）。核心原则：发现不是审讯，Implication问题通过激活损失厌恶推动成交，60/40规则（买家说话60%以上），最优秀销售多问一个问题。
- Concepts created: SPIN Selling（作为wikilink保留于source页面内）、Gap Selling（同）、Sandler Pain Funnel（同）、AECR Framework（同）、Upfront Contract（同）、Discovery Call Structure（同）
- Entities linked: Neil Rackham（同）、Keenan（同）、Sandler（同）
- Source page: wiki/sources/sales-discovery-coach.md
- Notes: Entity/Concept页面未单独创建（均首次出现且可抽象为独立概念，建议在后续摄入相关源文件时再评估）；未发现与现有Wiki内容的冲突；overview.md新增"Sales Discovery Methodology"主题节；source页面内详细记录了各框架的定义和引用

## [2026-04-25] ingest | Paid Media Ad Creative Strategist Agent
- Source file: Agent/agency-agents/paid-media/paid-media-creative-strategist.md
- Status: ✅ 成功摄入
- Summary: 付费媒体广告创意策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于 Google、Meta、Microsoft 及程序化平台的全渠道广告文案创作、响应式搜索广告（RSA）架构设计和系统性创意测试框架。核心理念：创意是自动化竞价环境中最大的可控杠杆，当算法接管了出价、预算和定向时，每一条标题、描述、图片和视频都是一个待验证的假设。
- Concepts created: [[ResponsiveSearchAds]], [[AdStrength]], [[CreativeFatigue]], [[HookBodyCTA]], [[ABTesting]], [[MessageMatch]], [[AdExtensions]]
- Entities linked: [[GoogleAds]], [[MetaAdsManager]], [[MicrosoftAdvertising]], [[PerformanceMax]], [[JohnWilliams]]（已存在）
- Source page: wiki/sources/paid-media-creative-strategist.md
- Notes: 与 [[paid-media-ppc-strategist]] 在"自动化 vs 创意质量"权衡上的张力已记录于 Contradictions；与 [[paid-media-programmatic-buyer]] 在"创意新鲜度"上的潜在冲突已记录；与 [[paid-media-paid-social-strategist]] 协同关系已记录（受众洞察→平台原生创意执行）；overview.md 中 paid-media-creative-strategist 条目已从简略描述更新为完整条目，Key Concepts 行已更新

## [2026-04-25] ingest | Paid Social Strategist
- Source file: Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md
- Status: ✅ 成功摄入
- Summary: 跨平台付费社交广告专家 Agent，覆盖 Meta（Facebook/Instagram）、LinkedIn、TikTok、Pinterest、X 和 Snapchat，设计从引流到再营销的全漏斗社交广告项目。核心理念：社交广告本质是"打断"而非"回答"，必须构建平台原生体验而非跨平台复用创意。
- Concepts created: [[Full-Funnel-Campaign-Architecture]], [[Custom-Audience-Engineering]], [[Conversions-API]], [[Advantage+-Campaigns]], [[Incrementality-Testing]], [[SKAdNetwork]]
- Entities created: [[Meta-Ads-Manager]], [[LinkedIn-Campaign-Manager]], [[TikTok-Ads]]; [[JohnWilliams]] 已更新
- Source page: wiki/sources/paid-media-paid-social-strategist.md
- Notes: 与 [[paid-media-programmatic-buyer]] 在"自动化 vs. 控制"权衡上存在张力已记录于 Contradictions；与 [[paid-media-ppc-strategist]] 在跨渠道预算分配验证原则上有协同关系；与 [[paid-media-creative-strategist]] 在受众策略→创意方向上有依赖关系已记录

## [2026-05-06] ingest | Paid Media Search Query Analyst Agent
- Source file: Agent/agency-agents/paid-media/paid-media-search-query-analyst.md
- Status: ✅ 成功摄入
- Summary: 付费媒体搜索词分析师 Agent——由 John Williams（@itallstartedwithaidea）设计，专注于从用户真实搜索词中挖掘洞察、构建分层负关键词架构、系统化提升付费搜索账户信噪比。核心能力：N-gram 分析、查询意图分类、匹配类型优化、查询雕塑（Query Sculpting）、浪费支出识别、关键词机会挖掘。核心理念：搜索查询优化是持续系统而非一次性任务，每浪费一美元在不相关查询上就是从转化查询中偷走一美元。成功指标：首次分析识别并消除 10-20% 非转化支出、无关查询展示占比 <5%、查询意图对齐度 80%+。
- Concepts linked: [[SearchQueryOptimization]], [[NegativeKeywordArchitecture]], [[NgramAnalysis]], [[IntentClassification]], [[QuerySculpting]], [[SQOSScoring]], [[CloseVariantAnalysis]], [[WasteIdentification]], [[QueryClustering]], [[MatchTypeOptimization]], [[BrandVsNonbrandLeakageAnalysis]], [[CompetitorQueryInterception]], [[ShoppingSearchTermAnalysis]], [[PerformanceMaxInsights]]
- Entities linked: [[JohnWilliams]], [[GoogleAdsMCP]]
- Source page: wiki/sources/paid-media-search-query-analyst.md
- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-06）；overview.md 已有 paid-media-search-query-analyst 条目（line 63），本次摄入更新了 Key Claims 和 Key Quotes，补充了 [[GoogleAdsMCP]] Entity；Concepts 和 Entities 在其他源页面中均仅出现 1 次，不足独立建页阈值（≥2 次），以 wikilink 形式记录于 Source page；与 [[paid-media-ppc-strategist]] 的协同关系已记录（策略制定依赖查询分析结果），与 [[paid-media-auditor]] 的协同关系已记录（审计触发查询分析需求）

## [2026-05-05] ingest | Paid Media Auditor Agent
- Source file: Agent/agency-agents/paid-media/paid-media-auditor.md
- Status: ✅ 成功摄入
- Summary: 企业级付费媒体账户审计 Agent——系统化评估 Google Ads、Microsoft Ads 和 Meta Ads 账户，覆盖 200+ 检查点（账号结构/追踪配置/竞价策略/创意/受众/竞争定位），每项发现附严重程度和预估业务影响。核心能力：8 大审计维度（账号结构/追踪/竞价/关键词/创意/Shopping/竞争定位/Landing Page）+ 历史趋势分析 + 合规审计。核心理念：像审计财务报表一样审计广告账户，不遗漏任何设置、假设和每一分钱。成功指标：审计通常识别 15-30% 效率提升机会，80%+ 高优先级建议 30 天内落地。
- Concepts linked: [[AccountAudit]], [[ConversionTracking]], [[AttributionModeling]], [[BidStrategy]], [[QualityScore]], [[NegativeKeywordManagement]], [[AuctionInsights]], [[Dayparting]], [[ResponsiveSearchAds]], [[ProductFeedOptimization]], [[LandingPageAudit]], [[CompetitivePositioning]]
- Entities linked: [[JohnWilliams]], [[GoogleAds]], [[MicrosoftAdvertising]], [[AmazonAds]], [[GA4]], [[GTM]]
- Source page: wiki/sources/paid-media-auditor.md
- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-05）；overview.md 已更新 paid-media-auditor 条目，补充 200+ 检查点框架和成功指标；所有 Entity/Concept 均仅出现 1 次，不足独立建页阈值（≥2 次），以 wikilink 形式记录于 Source page；与 [[paid-media-ppc-strategist]]（架构即战略 vs 现状审计）和 [[paid-media-programmatic-buyer]]（下漏斗 vs 上漏斗指标）的互补张力已记录于 Contradictions 节

## [2026-05-05] ingest | Paid Media PPC Campaign Strategist Agent
- Source file: Agent/agency-agents/paid-media/paid-media-ppc-strategist.md
- Status: ✅ 成功摄入
- Summary: 企业级付费搜索与效果媒体策略 Agent——由 John Williams（@itallstartedwithaidea）设计，专注 Google Ads、Microsoft Advertising、Amazon Ads 三大平台。核心能力：分层活动架构（品牌/非品牌/竞品/征服）、Smart Bidding（tCPA/tROAS/Max Conversions/Max CV）、Performance Max 资产组设计、Google Ads API 自动化、MCC 级策略、增量测试框架。核心理念：账户架构即战略——活动/广告组/受众/信号系统协同驱动业务成果。成功指标：品牌展示份额 90%+、非品牌 40-60%、QS 7+ 占比 70%+、日预算消耗率 95-100%、季度转化量增长 15-25%。
- Concepts created: [[PerformanceMax]], [[SmartBidding]], [[AccountArchitecture]], [[TieredCampaignArchitecture]], [[IncrementalityTesting]], [[ConversionActionHierarchy]], [[CustomerMatch]], [[BudgetPacing]]
- Entities created: [[GoogleAds]], [[MicrosoftAdvertising]], [[AmazonAds]], [[JohnWilliams]]
- Source page: wiki/sources/paid-media-ppc-strategist.md
- Notes: index.md 已新增 Sources 条目；Entities（4个）和 Concepts（8个）均已创建并添加到 index.md；overview.md 已新增 "The Agency — Paid Media 部门" 章节，整合了所有 Paid Media Agent 的协同关系；冲突已识别并记录：与 [[paid-media-programmatic-buyer]] 在预算分配方向上存在张力（高意图搜索流量 vs 品牌曝光），记录于 Source Page Contradictions 部分

## [2026-05-05] ingest | Paid Media Programmatic & Display Buyer Agent
- Source file: Agent/agency-agents/paid-media/paid-media-programmatic-buyer.md
- Status: ✅ 成功摄入
- Summary: 战略性程序化购买与展示广告 Agent——覆盖 Google Display Network、DV360、The Trade Desk、Amazon DSP 等 DSP 平台，支持 Demandbase/6Sense/RollWorks ABM 展示广告策略，管理 25+ 合作伙伴媒体 AMP 计划。以受众优先为核心（正确的人在正确的上下文以正确的频次触达），强调可见性（70%+ MRC 标准）、品牌安全（IVT <3%）、频次管理（3-7 次/月）。通过 MCP 工具与 Google Ads API 集成实现自动化：placement 性能报告拉取、GDN 广告位排除、跨账户审计自动化。
- Concepts linked: [[Programmatic Buying]], [[ABM Display]], [[Viewability]], [[Invalid Traffic]], [[Frequency Cap]], [[Supply Path Optimization]], [[Partner Media AMP]], [[MRC Standard]], [[CTV/OTT Advertising]], [[Brand Lift Measurement]]
- Entities linked: [[DV360]], [[The Trade Desk]], [[Amazon DSP]], [[Google Display Network]], [[Demandbase]], [[6Sense]], [[RollWorks]], [[John Williams]]
- Source page: wiki/sources/paid-media-programmatic-buyer.md
- Notes: index.md 已插入新条目至 paid-media-paid-social-strategist 之前；Entity/Concept 均未达到独立建页阈值（N=1）；冲突已识别并记录：与 paid-media-paid-social-strategist 在效果衡量指标上的差异（展示广告看上漏斗指标 vs 社交广告看直接转化指标）

## [2026-05-05] ingest | Visual Storyteller Agent
- Source file: Agent/agency-agents/design/design-visual-storyteller.md
- Status: ✅ 成功摄入
- Summary: Visual Storyteller Agent 角色定义——视觉叙事与品牌故事创作专家智能体，专注于将复杂信息转化为引人入胜的视觉叙事内容，驱动情感共鸣和用户参与。核心交付物：叙事弧创作（Beginning-Middle-End 三幕结构）、情感旅程映射、数据可视化叙事、跨平台视觉策略（Instagram/TikTok/YouTube/LinkedIn/Pinterest）。核心原则：叙事结构优先、情感驱动、品牌一致性（95%+触点）、WCAG 可访问性标准。成功指标：参与度提升 50%+、故事完成率 80%、品牌认知度提升 35%、视觉内容表现优于纯文本 3x。与 [[design-brand-guardian]] 互补（品牌叙事体系 vs 具体视觉内容），与 [[design-inclusive-visuals-specialist]] 协同（包容性视觉融入叙事），与 [[UX-Researcher]] 协同（用户洞察驱动情感旅程），与 [[design-whimsy-injector]] 互补（宏观叙事弧 vs 微交互趣味），共同为 [[LuxuryDeveloper]] 提供完整的品牌体验设计支撑。
- Concepts linked: [[Story-Arc-Creation]], [[Emotional-Journey-Mapping]], [[Data-Storytelling]], [[Cross-Platform-Adaptation]], [[Motion-Graphics]], [[Visual-Pacing]], [[Progressive-Disclosure]], [[Brand-Narrative-Strategy]]
- Entities linked: [[Visual-Storyteller-Agent]], [[The-Agency]], [[LuxuryDeveloper]]
- Source page: wiki/sources/design-visual-storyteller.md
- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-05-05）；overview.md 已新增独立段落（置于 design-whimsy-injector 和 design-image-prompt-engineer 之间）；无新 Entity/Concept 需创建（所有概念均为方法论术语，不足独立建页阈值）；无内容冲突检测到

## [2026-05-05] ingest | UI Designer Agent Personality
- Source file: Agent/agency-agents/design/design-ui-designer.md
- Status: ✅ 成功摄入
- Summary: UI Designer Agent 角色定义——视觉界面设计专家智能体，专注于视觉设计系统、组件库和像素级界面交付。核心交付物：设计令牌系统（CSS 变量管理颜色/字体/间距/阴影/过渡）、响应式设计框架（Mobile-first，4个断点 640/768/1024/1280px）、可访问性标准（WCAG AA，色彩对比度 4.5:1）、组件文档与设计 QA 流程。核心理念：Design System First（先建组件基础再创建界面）、Accessibility Built-In（从架构层面内置无障碍）、Developer Handoff（详细规格实现 90%+ 准确率）。与 [[design-brand-guardian]] 互补（品牌身份 vs 视觉执行），与 [[design-whimsy-injector]] 存在张力——前者追求 95%+ 视觉一致性，后者在规范内注入趣味元素，通过预定义可配置槽位协调。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。
- Concepts linked: [[Design-System]], [[Design-Tokens]], [[Visual-Hierarchy]], [[Responsive-Design]], [[WCAG-AA]], [[Component-Library]], [[Dark-Mode]], [[Design-QA]], [[Accessibility-First-Design]]
- Entities linked: [[The Agency]], [[ArchitectUX]], [[design-brand-guardian]], [[design-whimsy-injector]], [[UX-Researcher]], [[LuxuryDeveloper]]
- Source page: wiki/sources/design-ui-designer.md
- Notes: index.md 已新增 Sources 条目（置于 design-brand-guardian 之前）；overview.md 已新增独立段落并替换原有 design-ux-architect 条目，新增 design-brand-guardian 条目，调整各 Agent 描述使其更准确；无新 Entity/Concept 需创建（Design-System/WCAG/Component-Library 等概念均在 Agency Agent 系统上下文中以方法论形式出现，不足独立建页阈值）；与 [[design-whimsy-injector]] 存在一致性与趣味性的张力，已记录于 Contradictions 部分——通过预定义可配置槽位协调（如微交互动画）

## [2026-05-05] ingest | Design Brand Guardian
- Source file: Agent/agency-agents/design/design-brand-guardian.md
- Status: ✅ 成功摄入
- Summary: Brand Guardian Agent 角色定义——品牌战略与身份守护专家智能体，负责创建 cohesive 品牌体系、确保跨所有触点的品牌表达一致性、并通过品牌保护策略维护品牌价值。核心交付物：品牌战略框架（Purpose/Vision/Mission/Values/Personality 五要素）、视觉身份系统（CSS 变量定义的品牌色彩/字体/间距/Logo 变体）、品牌声音指南、品牌保护策略。核心原则：Brand-First（先建品牌基础再战术执行）、一致性优先（95%+ 触点保持一致）、战略性演进（随市场变化成长而不失核心身份）。与 [[design-whimsy-injector]] 互补（Brand Guardian 建边界，Whimsy Injector 在边界内注入个性），共同为 [[LuxuryDeveloper]] 提供完整品牌体验设计。与 [[ArchitectUX]]（技术架构）和 [[UX-Researcher]]（用户研究）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。
- Concepts linked: [[Brand-Strategy]], [[Visual-Identity-System]], [[Brand-Voice-Guidelines]], [[Brand-Protection-Strategy]]
- Entities linked: [[The Agency]], [[ArchitectUX]], [[design-whimsy-injector]], [[UX-Researcher]], [[LuxuryDeveloper]]
- Source page: wiki/sources/design-brand-guardian.md
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-whimsy-injector 和 multi-agent-system-reliability 之间）；无新 Entity/Concept 需创建（Brand-Strategy/Visual-Identity-System/Brand-Voice-Guidelines/Brand-Protection-Strategy 及 ArchitectUX/LuxuryDeveloper 仅出现 1 次，不足建页阈值）；与 [[design-whimsy-injector]] 存在品牌一致性与创意表达的张力，已记录于 Contradictions 部分——两者互补而非互斥

## [2026-04-24] ingest | Inclusive Visuals Specialist
- Source file: Agent/agency-agents/design/design-inclusive-visuals-specialist.md
- Status: ✅ 成功摄入
- Summary: Inclusive Visuals Specialist Agent 角色定义——包容性视觉表征专家智能体，专门对抗 AI 图像/视频生成模型（Midjourney、Sora、Runway Gen-3、DALL-E）中内嵌的系统性刻板印象偏见，生成具有文化真实性、尊严感和无歧视性的人类视觉表征。核心挑战：克隆脸（Clone Faces）、异域化偏见（Exoticism Bias）、文化符号乱码、地理/建筑失真。核心技术：结构化提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）+ 负向提示库 + 视频物理学定义。四阶段工作流：Brief Intake → Annotation Framework → Video Physics Definition → 7-Point QA Review Gate。成功指标：表征准确度 100%、AI 伪影消除率 100%、社区验证认可。
- Concepts created: [[InclusiveVisuals]], [[NegativePromptingLibrary]]
- Concepts linked: [[IntersectionalRepresentation]], [[CommunityValidation]], [[AIArtifactElimination]], [[PromptEngineering]]
- Entities linked: [[TheAgency]], [[Midjourney]], [[Sora]], [[Runway-Gen-3]], [[DALL-E]], [[InclusiveVisualsSpecialist]]
- Source page: wiki/sources/design-inclusive-visuals-specialist.md
- Notes: index.md 已替换占位符条目（2026-04-20 → 2026-04-24）；overview.md 已新增 InclusiveVisualsSpecialist 独立段落（置于 design-image-prompt-engineer 和 design-brand-guardian 之间）；新增 Concept 页面 [[InclusiveVisuals]] 和 [[NegativePromptingLibrary]]；与 [[design-image-prompt-engineer]] 互补（摄影美学精准度 vs 消除表征偏见），与 [[design-whimsy-injector]] 存在张力——Kumbaya 库存照片套路和表演性象征主义是包容性设计必须坚决拒绝的

## [2026-04-24] ingest | UX Researcher Agent Personality
- Source file: Agent/agency-agents/design/design-ux-researcher.md
- Status: ✅ 成功摄入
- Summary: UX Researcher Agent 角色定义——用户体验研究专家智能体，通过定性和定量研究方法验证设计决策。核心交付物：用户画像模板、用户旅程映射、可用性测试协议、A/B 测试框架。核心理念：研究方法论优先、证据优先沟通、研究推荐 80%+ 实施率。与 [[ArchitectUX]]（技术架构）和 [[design-whimsy-injector]]（品牌趣味）协同，共同为 [[LuxuryDeveloper]] 提供完整的用户中心设计支撑。
- Concepts linked: [[Mixed-Methods Research]], [[Usability Testing]], [[User Persona]], [[User Journey Mapping]], [[Triangulation]], [[A/B Testing]], [[Accessibility Research]], [[Behavioral Analytics]], [[Research Repository]]
- Entities linked: [[Design Teams]], [[Product Teams]], [[Stakeholders]], [[The Agency]]
- Source page: wiki/sources/design-ux-researcher.md
- Notes: index.md 已新增 Sources 条目；overview.md 已新增独立段落（Multi-Agent AI Systems 主题下，置于 design-whimsy-injector 之前）；无新 Entity/Concept 需创建（大多数概念和实体在源文档中出现次数不足建页阈值）；与 [[design-whimsy-injector]] 存在设计理性与创意表达的互补张力，已记录于 Contradictions 部分

## [2026-05-05] ingest | Design Whimsy Injector
- Source file: Agent/agency-agents/design/design-whimsy-injector.md
- Status: ✅ 成功摄入
- Summary: Whimsy Injector Agent 角色定义——品牌个性化和愉悦感注入专家，通过战略趣味设计为品牌体验增添个性、微交互和游戏化元素。核心交付物：品牌个性框架（专业/休闲/错误/成功四种场景人格光谱）、Whimsy 分类学（微妙/交互/发现/情境四类趣味）、微交互设计系统（CSS 动画 + 彩蛋 + 成就系统）。核心理念：有目的的趣味 + 包容性愉悦设计。与 [[ArchitectUX]] 互补，共同为 [[LuxuryDeveloper]] 提供完整品牌体验设计。
- Concepts linked: [[Whimsy-Injector]], [[Micro-Interaction-Design]], [[Gamification-System]], [[Inclusive-Delight-Design]]
- Entities linked: [[ArchitectUX]], [[LuxuryDeveloper]], [[The Agency]]
- Source page: wiki/sources/design-whimsy-injector.md
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-ux-architect 和 multi-agent-system-reliability 之间）；无新 Entity/Concept 需创建（ArchitectUX/LuxuryDeveloper/Micro-Interaction-Design 等仅出现 1 次，不足建页阈值）；无内容冲突

## [2026-05-05] ingest | Contributing to The Agency
- Source file: Agent/agency-agents/CONTRIBUTING.md
- Status: ✅ 成功摄入
- Summary: The Agency 多智能体框架贡献者指南英文原版——涵盖 Code of Conduct、四大贡献方式（创建智能体/优化现有/分享案例/报告问题）、智能体设计模板（YAML frontmatter + 结构化文档）、五大设计原则（鲜明性格/明确交付物/可量化指标/验证工作流/学习记忆）、PR 流程规范（单文件优先/Discussion 前置/提交前检查）、代码风格指南。
- Concepts linked: [[Agent-Design-Principles]], [[Agent-Template]], [[Multi-Agent-Team]], [[Multi-Agent-System-Reliability]]
- Entities linked: [[The Agency]], [[OpenClaw]], [[msitarzewski]]
- Source page: wiki/sources/contributing.md
- Notes: index.md 已替换占位符条目；overview.md 已更新 contributing_zh-cn 条目，补充英文原版 wikilink；无新 Entity 需创建（msitarzewski/The Agency 仅出现 1 次，不足建页阈值）；无实质内容冲突，与 contributing_zh-cn 差异属语言版本差异

## [2026-05-05] ingest | 为 The Agency 贡献代码
- Source file: Agent/agency-agents/CONTRIBUTING_zh-CN.md
- Status: ✅ 成功摄入
- Summary: The Agency 项目（agency-agents）贡献者指南，定义智能体设计规范、贡献流程和社区标准。核心贡献方式：创建全新智能体（8大分类）、优化现有智能体、分享成功案例、反馈问题。智能体设计五原则：鲜明性格、明确交付物、可量化指标、经过验证的工作流、学习记忆。PR 流程含提交前检查（真实场景测试、遵循模板、补充示例）、社区评审与迭代优化。
- Concepts created: [[Agent-Design-Principles]], [[Agent-Template]]
- Entities created: none（The Agency 已在 Wiki 中存在引用，无需新建 Entity 页面）
- Concepts linked: [[Multi-Agent-System-Reliability]], [[Multi-Agent-Team]]
- Source page: wiki/sources/contributing_zh-cn.md
- Notes: index.md 已新增 Sources 条目；overview.md 已新增独立段落（Multi-Agent AI Systems 主题下，置于 multi-channel-assistant 之前）；Agent-Design-Principles 和 Agent-Template 为新创建 Concept 页面；无 Entity 需创建；无冲突内容

## [2026-05-05] ingest | CTP Topic 12 Using SES SMTP service terraform module
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-12-using-ses-smtp-service-terraform-module.md
- Status: ✅ 成功摄入
- Summary: Christian Deckelmann 和 Filos Christolakis 主讲，Micro Focus 团队通过 Terraform 模块自动化部署 AWS SES SMTP 服务以替代传统本地 SMTP 网关——SES 是网络安全部门唯一批准的云端邮件发送方案；Terraform 模块封装 SMTP 终端节点配置，支持现有应用程序通过标准 SMTP 协议集成；VPC 端点私有连接 + IAM 用户凭证转 SMTP 认证信息存储于 Secrets Manager；自动化 DKIM 验证和 Infoblox DNS 记录创建；两个手动步骤（脱离 Sandbox Mode + 手动更新 DNS TXT 记录）；未来计划收件人限制和凭证滚动更新。
- Concepts created: [[VPC-Endpoint]], [[DKIM-Email-Authentication]], [[SES-Sandbox-Mode]]
- Entities created: none（Christian Deckelmann、Filos Christolakis、Infoblox 出现频次不足建页阈值，以 wikilink 形式记录于 Source page）
- Concepts linked: [[Infrastructure-as-Code]], [[Secrets-Management]]
- Source page: wiki/sources/ctp-topic-12-using-ses-smtp-service-terraform-module.md
- Notes: index.md 已替换占位符条目（日期 2026-04-14）；overview.md 已新增独立段落（Terraform 段落末尾，置于 RDS via Terraform 和 Topic 21 之间）；VPC-Endpoint/DKIM-Email-Authentication/SES-Sandbox-Mode 为新创建 Concept 页面；Secrets-Management 已存在，已建立 wikilink；无其他 Entity 需创建
- Conflicts: 与 [[ctp-topic-36-sendgrid-as-an-email-service]] 在邮件服务选型上的差异——SendGrid 被选定为新标准云邮件服务，SES 则服务现有应用通过 SMTP 协议平滑迁移上云，两者互补而非互斥

## [2026-05-05] ingest | design-ux-architect
- Source file: Agent/agency-agents/design/design-ux-architect.md
- Status: ✅ 成功摄入
- Summary: ArchitectUX 智能体角色定义——为 LuxuryDeveloper 提供坚实的技术架构和 UX 基础。核心交付物：CSS 设计系统（颜色/排版/间距令牌，light/dark/system 三模式）、响应式布局框架（Grid/Flexbox/mobile-first）、ThemeManager JS 类、信息架构规范。核心原则：Foundation-First 和消除开发者架构决策疲劳。所有新站点强制要求主题切换功能。
- Concepts linked: none（CSS 设计系统/ThemeManager 等属单一来源概念，以 wikilink 形式记录于 Source page，不足建 Concept 页阈值）
- Entities linked: [[ArchitectUX]], [[LuxuryDeveloper]], [[The Agency]]
- Source page: wiki/sources/design-ux-architect.md
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 multi-agent-system-reliability 之前）；无新 Entity/Concept 需创建（ArchitectUX/LuxuryDeveloper 仅出现 1 次，不足建 Entity 页阈值）；无实质内容冲突

## [2026-05-05] ingest | Learning Sessions Cloud Transformation Programme-20230808 183322-Meeting Recording
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md
- Status: ✅ 成功摄入
- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。
- Concepts linked: [[Infrastructure-as-Code]], [[Canary-Deployment]], [[ECS-Module]]
- Entities linked: [[Gruntwork]], [[AWS]], [[Cloud-Transformation-Programme]]
- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md
- Notes: index.md 已替换占位符条目；overview.md 已新增同主题 wikilink；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，ECS vs EKS 选型差异记录于 Contradictions 节
- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补

## [2026-05-05] ingest | CTP Topic 16 Cross-account Terraform modules
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-16-cross-account-terraform-modules.md
- Status: ✅ 成功摄入
- Summary: Fibos 主讲，多账号 AWS 环境中跨账号 Terraform 模块的中心化部署方案——基于 Shared Account（共享账号）作为中转站，Jenkins + ECS Deploy Runner + Assume Role 三联动。核心机制：Jenkins 检测 `cross-account.json` 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF state bucket accessor 和 cross-account ECS deploy runner role。三大目标：安全性（无 Workload 账号间直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块代码不硬编码特定账号角色）。
- Concepts created: [[Cross-account-Terraform-Modules]]
- Entities created: none（Gruntwork 已存在）
- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 ECS Deployment 和 Topic 21 之间）；Entity Jenkins/Fibos 提及次数不足建页阈值，以 wikilink 形式记录于 Source page；无实质性内容冲突，演进关系记录于 Contradictions 节

## [2026-05-05] ingest | Learning Sessions ECS Deployment using IAC - 20230808
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
- Status: ✅ 成功摄入
- Summary: JP 和 Raja M 主讲，CTP/SRE 团队通过 Terraform IaC 实现 ECS 容器化应用自动化部署——基于 Gruntwork 仓库构建 ECS 模块，支持 Docker 容器/EC2 部署；核心功能：自动扩缩容、自动故障恢复、金丝雀部署；Listener 集中管理方式；前置条件：VPC/ELB 安全组/EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus。ECS 作为 AWS 原生技术与 AWS 服务深度集成。
- Concepts created: [[Canary-Deployment]], [[Infrastructure-as-Code]]
- Entities created: [[Gruntwork]]
- Source page: wiki/sources/learning-sessions-ecs-deployment-using-iac-20230808-183322-meeting-recording.md
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 Terraform 工具选型后）；ECS 与 EKS 选型冲突记录于 Contradictions 节；JP 和 Raja M 各出现 1 次，不足独立 Entity 建页阈值，以 wikilink 形式记录于 Source page；无其他内容冲突
- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在容器编排选型上的差异——ECS 强调 AWS 原生集成，EKS 强调可移植性，两者适用于不同场景但可互补

## [2026-05-05] ingest | CTP Topic 48 Terraform vs Terragrunt
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/ctp-topic-48-terraform-vs-terragrunt.md
- Status: ✅ 成功摄入
- Summary: Bob（AWS Solutions Architect）对比 Terraform 与 Terragrunt——Terraform（HashiCorp 出品）是云厂商无关的 Golang 应用，通过状态文件绑定期望状态与实际环境；Terragrunt 是轻量封装，贯彻 DRY 原则，管理 provider 和 remote_state 块减少跨环境重复声明。两者命令和语法高度一致，Terragrunt 通过减少硬编码优化大规模企业部署。辅助工具：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest
- Concepts created: [[DRY Principle]], [[State-File-Management]]
- Entities created: [[HashiCorp]], [[Terragrunt]], [[Atlantis]]
- Entities updated: [[Terraform]], [[Gruntwork]]
- Concepts updated: [[Infrastructure-as-Code]]
- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
- Notes: 视频由 Gemini 摘要，原文状态为 "summarized (Gemini 摘要)"；来源 NAS 路径为 `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 48_ Terraform vs Terragrunt.mp4`

## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - AI Use Cases - 20241126 160106
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
- Status: ✅ 成功摄入
- Summary: AWS AI 专家 Stephen Frank 分享 Gen2 AI 发展驱动力（数据爆发+算力提升）、企业级 AI 应用场景（客户体验/洞察提取/流程自动化/内容生成）、AWS 三层产品战略（基础设施→Bedrock→AI 应用）、数据差异化策略（RAG/Fine-tuning/持续预训练）、Amazon Q 企业知识问答、负责任 AI 原则
- Concepts linked: [[RAG]], [[Fine-Tuning]], [[Continued-Pre-Training]], [[Responsible-AI]]
- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[Stephen-Frank]]
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-ai-use-cases-20241126-160106-meeting-rec.md
- Notes: index.md 已替换占位符条目（日期修正为 2026-04-14）；overview.md 已新增独立段落（Serverless & AI 专题，置于提示工程后）；RAG/Fine-Tuning/Responsible-AI/Stephen-Frank/Amazon-Q/Amazon-SageMaker 在 wiki 中出现频次不足独立建页阈值，以 wikilink 形式记录于 Source page；无内容冲突
- Conflicts: 无

## [2026-05-05] ingest | Public Cloud Learning Sessions (OpenText) - Event Driven Architecture Part 2 - 20240917
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
- Status: ✅ 成功摄入
- Summary: EDA 进阶实践——三组件（事件生产者/消费者/代理）、事件路由器（EventBridge/SNS）与事件存储（SQS/Kinesis）、编排与编排模式（Choreography vs Orchestration）、幂等性、事件排序、去中心化团队所有权、Fan-out 模式、竞争消费者模式、死信队列、EventBridge 最佳实践
- Concepts updated: [[Event-Driven-Architecture]]（补充 Part 2 内容：EDA 三组件、编排模式对比、生产级最佳实践：幂等性/事件排序/团队独立性、扩展 Event Patterns：Fan-Out/Competing Consumer/DLQ）
- Entities existing (no new): [[AWS]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]], [[AWS-Lambda]], [[AWS-Step-Functions]]
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
- Notes: index.md 已替换占位符条目（日期修正为 2026-05-05）；overview.md 已添加 Part 2 独立段落（新增于 Serverless 段落和 Part 1 之间），同时更新 Part 1 引用指向 Part 2；Event-Driven-Architecture 概念页已更新 sources + last_updated，新增 EDA 三组件/编排模式/生产级最佳实践内容，扩展 Event Patterns；Kinesis-Data-Streams 出现 1 次，不足独立建 Entity 阈值，以 wikilink 形式记录于 Concept 页
- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展（消费者按需处理），EKS 通过容器编排横向扩展（Pod 副本数调整），两者适用于不同场景但可互补使用
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
- Status: ✅ 成功摄入
- Summary: EDA 入门——AWS 解决方案架构师 Dr. Anil Giri 介绍 EventBridge/SQS/SNS 事件驱动架构与 Enterprise Integration Patterns；会议因 Teams 屏幕共享故障仅完成开场介绍，完整演示参见 Part 2
- Concepts linked: [[Event-Driven-Architecture]], [[Enterprise-Integration-Patterns]], [[Amazon-EventBridge]], [[Amazon-SQS]], [[Amazon-SNS]]
- Entities linked: [[Dr.-Anil-Giri]], [[AWS]], [[OpenText]], [[Micro-Focus]]
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-1-2024091.md
- Notes: index.md 已替换占位符条目（日期修正为 2026-04-19）；overview.md 已补充（Serverless & AI 专题段落新增，置于无服务器计算后）；Dr. Anil Giri/AWS/OpenText/Micro Focus 在 wiki 中出现频次不足独立建 Entity 页阈值，以 wikilink 形式记录于 Source page；EventBridge/SQS/SNS/Enterprise-Integration-Patterns 概念频次不足独立建 Concept 页阈值；已建立与 Part 2（public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091）、无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系；冲突记录与 ctp-topic-64-scaling-out-with-amazon-eks 的扩展方式差异已记录于 Contradictions 节
- Conflicts: 与 [[ctp-topic-64-scaling-out-with-amazon-eks]] 在扩展方式上的差异——EDA 通过事件驱动异步扩展，EKS 通过容器编排横向扩展，两者适用于不同场景但可互补使用

## [2026-05-05] ingest | Public Cloud Learning Sessions - Serverless Computing - 20240903
- Status: ✅ 成功摄入
- Summary: AWS 无服务器计算深度解析——Lambda 事件驱动模型（同步/异步/事件源映射）、Step Functions 状态机编排（Standard/Express）、API Gateway（边缘优化/区域/私有）、SAM 本地开发和部署；Serverless 业务价值（快速上市/按需付费/自动扩展/内置安全）；AWS 与客户共担运维责任
- Entities created: [[AWS-Lambda]], [[AWS-Step-Functions]], [[Amazon-API-Gateway]], [[SAM-Serverless-Application-Model]]
- Concepts linked: [[Serverless-Computing]], [[Event-Driven-Architecture]]
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（Cloud Transformation & DevOps 章节新增独立段落，置于 AI/ML 入门与 CTP Topic 20 之间）；Entity 页均按字母顺序插入 index.md Entities 节；无内容冲突（Serverless-Computing 概念页已存在，内容一致）
- Conflicts: 无

## [2026-05-05] ingest | Public Cloud Learning Sessions - Introduction to AI/ML with AWS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
- Status: ✅ 成功摄入
- Summary: AWS AI/ML 与生成式 AI 入门——AI 定义（复制人类智能任务的系统）、三类 AI（分类/预测/生成式 AI）、AWS 20 年 ML 积累、Amazon Bedrock 全托管服务（Titan 基础模型+微调+持续预训练+RAG+Agents+Guardrails）、SageMaker Canvas 无代码工具、ML Ops 数据/训练/推理三流水线
- Concepts linked: [[RAG]], [[MLOps]], [[Foundation-Models]], [[Amazon-Bedrock]], [[Amazon-SageMaker-Canvas]], [[Responsible-AI]]
- Entities linked: [[AWS]], [[Amazon-Bedrock]], [[Amazon-Titan]]
- Source page: wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
- Notes: index.md 已更新（替换占位符条目）；overview.md 已补充（Cloud Transformation & DevOps 章节新增 Serverless & AI 专题段落，置于 FinOps 后）；Suraav Paul/AWS Senior Solutions Architect 仅出现 1 次，以 wikilink 形式记录于 Source page；RAG/MLOps/Responsible AI 频次不足独立建页阈值；本来源属于 Cloud Transformation Programme 的 Serverless & AI 专题（09_Serverless_AI）；无内容冲突
- Conflicts: 无

## [2026-05-05] ingest | Cloud Learning Master Index
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md
- Status: ✅ 成功摄入
- Summary: OpenText/微焦点云转型学习会话视频总索引——NAS 源 `/volume2/work/Public Cloud Learning Sessions/`，覆盖 10 大技术领域共 111 个视频：AWS Landing Zone（22）、OpenText Series（21）、EKS & Kubernetes（14）、Security（9）、Networking（9）、Serverless & AI（9）、FinOps & Cost（10）、CI/CD & GitOps（8）、IAM & Identity（3）、Terraform & IaC（6）。该索引是所有 CTP 专题视频的元数据入口。
- Concepts created: 无（所有关键技术概念已通过其他来源创建独立页面；该索引为元数据文件，无需新建 Concept）
- Source page: wiki/sources/cloud-learning-master-index.md
- Notes: index.md 已更新（Sources 节新增条目置于顶部）；overview.md 已补充（Cloud Transformation & DevOps 章节新增 cloud-learning-master-index 段落）；CTP-Team 和 OpenText 以 wikilink 形式记录于 Source page（出现次数不足独立建页阈值）；Cloud-Transformation-Programme 已通过 Micro Focus Entity 页覆盖；无内容冲突
- Conflicts: 无

## [2026-05-05] ingest | CTP Topic 27 AWS Instance Scheduler
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-27-aws-instance-scheduler.md
- Status: ✅ 成功摄入
- Summary: AWS Instance Scheduler 原生方案——通过 CloudFormation + CloudWatch Events（每15分钟）+ Lambda + DynamoDB 调度配置表，自动定时启停 EC2/RDS 实例；通过标签（Schedule/Period）关联调度规则；由 Guardrails 框架自动推送至公司月消费10美元以上账号；基于"时间表"而非"空闲率"触发；RDS 维护窗口智能协同；关机行为必须设为"停止"而非"终止"
- Concepts created: 无（所有概念仅出现 1 次，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/ctp-topic-27-aws-instance-scheduler.md
- Notes: index.md 已更新（替换占位符条目，日期修正为 2026-04-14）；overview.md 已补充（FinOps 章节新增段落，置于 ctp-topic-63 后）；已建立与 ctp-topic-13（政策框架）、ctp-topic-63（Terraform Scheduler 互补）、ctp-topic-71（RightSizing 互补）的 Connections 关系；冲突记录：与 ctp-topic-63 在实现路径上的差异（AWS 原生 vs Terraform 层）已于 Contradictions 节说明为互补而非互斥
- Conflicts: 与 [[ctp-topic-63-optimise-resource-cost-using-automation]] 就 EC2/RDS 自动调度的实现路径差异——Instance Scheduler（AWS 原生方案）覆盖广账户层，Terraform Scheduler（IaC 层）提供细粒度控制，两者互补而非互斥

## [2026-04-25] ingest | CTP Topic 63 Optimise resource cost using automation
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-63-optimise-resource-cost-using-automation.md
- Status: ✅ 成功摄入
- Summary: 使用自动化手段优化 AWS 云资源成本——五大策略：批准区域标准化、Graviton ARM 实例选型（比 Intel 便宜 20-25%）、承诺计划（1年 40% / 3年 64% 折扣）、GP2→GP3 存储优化（节省 20%）、基于标签的 EC2/RDS 自动化调度（每天只运行 10 小时可节省 70% 成本）
- Concepts created: 无（已存在的 [[Savings-Plans]] 涵盖承诺计划；Graviton/RightSizing 等概念在本 wiki 中出现频次不足以独立建页）
- Source page: wiki/sources/ctp-topic-63-optimise-resource-cost-using-automation.md
- Notes: Pushka 演示 Terraform Scheduler 模块配置（`auto_shutdown = yes` 标签）；无内容冲突

## [2026-04-24] ingest | Public Cloud Learning Sessions - Best practices for EC2 cost optimization in AWS - 20240529
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md
- Status: ✅ 成功摄入
- Summary: Mike Dukes 和 Steele Taylor（AWS 专家）主讲 EC2 成本优化最佳实践——AWS Nitro 系统外部化网络/存储/安全组件提升效率；Graviton ARM 处理器基于 ARM64 架构，提供 40% 性价比提升，功耗减少 60%；EC2 Spot 实例利用闲置容量提供 90% 折扣；购买选项包括 On-Demand/Savings Plans/Spot Instances；Spot Invaders 游戏展示容错混沌工程实践；Spot + Graviton + 容器组合实现最大化成本节省
- Concepts created: [[Nitro-System]], [[EC2-Purchase-Options]]
- Concepts linked: [[Graviton]], [[Spot Instances]], [[Savings Plans]], [[FinOps]], [[Cloud Cost Optimization]]
- Entities identified: Mike Dukes 和 Steele Taylor 为演讲者，但提及次数不足 2 次，以 wikilink 形式记录于 Source page
- Source page: wiki/sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md
- Notes: index.md 已更新（Sources 节新增条目）；overview.md 已补充（FinOps 章节新增段落，置于 ctp-topic-13 后）；Nitro-System 和 EC2-Purchase-Options 不存在于现有 Wiki，新建 Concept 页面；已建立与 public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco、ctp-topic-13-cloud-finops-policies 的 Connections 关系
- Conflicts: 与 ctp-topic-14-octane-hub-on-aws 可能的冲突（Graviton 对有状态服务的适用性），已记录于 Source page Contradictions 节

## [2026-04-25] ingest | Public Cloud Learning Sessions - Storage Cost Optimization - 20240305
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md
- Status: ✅ 成功摄入
- Summary: AWS EBS（GP3 20% 节省+独立扩展 IOPS/吞吐）、EFS/FSx（生命周期分层）、S3（Intelligent Tiering 自动冷热迁移+生命周期策略+PrivateLink 规避数据传输费）、ADM 三阶段迁移案例（OpenZFS → 自管理 NetApp on EC2 → FSx for NetApp ONTAP 实现 60% 成本削减）
- Concepts linked: [[EBS-GP3]], [[EBS-Snapshot-Archive]], [[Data-Lifecycle-Manager]], [[AWS-Backup]], [[EFS-Infrequent-Access]], [[S3-Intelligent-Tiering]], [[S3-Lifecycle-Policies]], [[FSx-for-NetApp-ONTAP]], [[AWS-PrivateLink]], [[FinOps]], [[Cloud Cost Optimization]]
- Entities linked: [[AWS]], [[ADM]]
- Source page: wiki/sources/public-cloud-learning-sessions-storage-cost-optimization-20240305-160037-meeting.md
- Notes: index.md 已更新（Sources 节新增条目，置于 ctp-topic-71 前）；overview.md 已补充（FinOps 章节新增存储成本优化专题段落）；ADM 提及仅 1 次，以 wikilink 形式记录于 Source page；所有 AWS 服务特性概念（EBS-GP3/Snapshot-Archive/EFS-IA/S3-IntelligentTiering 等）已记录于 Source page Key Concepts 节，暂不单独建页；已建立与 public-cloud-learning-sessions-reducing-cloud-costs-20250318、ctp-topic-13-cloud-finops-policies 的 Connections 关系
- Conflicts: 与 ctp-topic-14-octane-hub-on-aws 可能的 EFS vs EBS 选型冲突，已记录于 Source page Contradictions 节

## [2026-04-25] ingest | Public Cloud Learning Sessions - Reducing Cloud Costs - 20250318
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md
- Status: ✅ 成功摄入
- Summary: Vinay（FinOps）主讲 AWS 云成本优化——工作负载优化（现代化：EC2 新代际/Graviton 20-25% 节省/AMD 6-10% 节省/GP2→GP3 存储 20% 节省/EKS 最新版避免扩展支持费/Spot 实例 90% 折扣）和 Right Sizing（EC2 Right Sizing 报告/实例调度/闲置资源清理）；费率优化（Savings Plans/RI 两种承诺类别 + 实施流程）；关键规则：承诺计划仅无预付选项，最低 $5k/年，仅 Phenops 团队实施
- Concepts created: [[Savings-Plans]], [[Spot-Instances]]
- Concepts linked: [[Cloud Cost Optimization]], [[Graviton]], [[Right Sizing]], [[EKS Extended Support]], [[EDP (Enterprise Discount Program)]]
- Entities created: [[Vinay]], [[Phenops-Team]]
- Entities linked: [[AWS]]
- Source page: wiki/sources/public-cloud-learning-sessions-reducing-cloud-costs-20250318-170100-meeting-reco.md
- Notes: index.md 已更新（Sources 节新增条目，Entities 节新增 Phenops-Team 和 Vinay，Concepts 节新增 Savings-Plans 和 Spot-Instances）；overview.md 已补充（FinOps 章节新增段落，Key Entities 新增 Vinay 和 Phenops-Team）；Graviton/Spot-Instances/Savings-Plans 均满足 Concept 可复用条件，新建页面；Vinay 出现 ≥2 次新建 Entity，Phenops-Team 出现 ≥2 次新建 Entity；与 [[ctp-topic-13-cloud-finops-policies]] 构成政策层→技术实施层互补关系，已记录于 Connections；无内容冲突
- Conflicts: 无

## [2026-04-25] ingest | CTP Topic 13 Cloud FinOps Micro Focus Policies best practices to optimize the costs
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md
- Status: ✅ 成功摄入
- Summary: PCG 团队 Uday 和 Vinay 主讲 Cloud FinOps 成本优化政策与最佳实践；PCG 三层服务模型（成本管理→成本优化→治理与自动化）；5 大核心策略（账单可见性、标签合规、预算责任、Reserved Instances 集中管理、区域限制）；安全控制（Godrails/MFA/告警重定向）；Cloud Health 工具；标准化实例选型 + Graviton；研发环境三合一优化
- Concepts identified: [[FinOps（云财务管理）]]（已存在）、[[Showback/Chargeback]]（已有引用）
- Entities identified: [[PCG]]（提及但 <2 次）、[[Cloud-Health]]（提及但 <2 次）
- Source page: wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md
- Notes: PCG 和 Cloud Health 出现次数不足 2 次，不满足独立 Entity 页面创建条件，以 wikilink 形式记录于 Source page；index.md 已更新（替换 expected 条目为实际内容）；overview.md Cloud Transformation 章节已补充（置于 ctp-topic-65 后）；已建立与 ctp-topic-63（自动化调度优化）、ctp-topic-71（Rightsizing）、ctp-topic-27（AWS Instance Scheduler）的连接关系；FinOps 概念页已存在于 wiki/concepts/，无需新建
- Conflicts: 与 [[ctp-topic-53-why-bother-with-cloud]] 存在视角差异：Topic 13 假设已在云上聚焦优化，Topic 53 聚焦是否应迁移的决策论证；已在 Source page Contradictions 节记录

## [2026-04-26] ingest | Public Cloud Learning Sessions - Budget Control - 20240319
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md
- Status: ✅ 成功摄入
- Summary: SRE Core 团队（Daniela/Evan/Alan）分享 AWS Budget Control 自动化——解决账户蔓延导致的成本失控。核心架构：AWS Budget → SNS → Lambda → Step Functions → SCP Enforcement（服务控制策略封禁新资源创建）。4 类告警：Forecast/Actual 80-98%/Severe/Enforcement。Source Identity 通过 CloudTrail 追踪联邦登录跨角色切换的原始用户身份。初始范围仅限 Lab 账户。
- Concepts created: [[AWS-Source-Identity]]
- Concepts linked: [[FinOps]], [[SCP-Enforcement]], [[CloudTrail]], [[Step-Functions]], [[Cost-Explorer]], [[AWS-Budget-Alerts]]
- Entities linked: [[SRE-Core-Team]], [[Phenops-Team]], [[NetIQ]]
- Source page: wiki/sources/public-cloud-learning-sessions-budget-control-20240319-160204-meeting-recording.md
- Notes: index.md 已更新（Sources 节新增条目，Concepts 节新增 AWS-Source-Identity）；overview.md 已补充（FinOps 章节新增段落，置于 reducing-cloud-costs-20250318 后）；AWS-Source-Identity 为 Source Identity 追踪机制的完整概念页，满足可复用条件；已建立与 ctp-topic-13（治理自动化政策层）、ctp-topic-63（主动优化）、reducing-cloud-costs-20250318（优化手段）的 Connections 关系；无内容冲突

## [2026-04-25] ingest | CTP Topic 15 Working with Renovatebot
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-15-working-with-renovatebot.md
- Status: ✅ 成功摄入
- Summary: Paul Hopkins 主讲 Renovate Bot 自动化管理云原生基础设施依赖项更新；解决"依赖地狱"问题，实时扫描 Docker/Terraform/Terragrunt/pre-commit 版本标签并自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting
- Concepts created: [[Renovate-Bot]], [[Dependency-Management]], [[Semantic-Versioning]]
- Source page: wiki/sources/ctp-topic-15-working-with-renovatebot.md
- Notes: Renovate-Bot 出现在 6 个以上来源中（index 有 416 行引用记录），满足 ≥2 次条件，创建独立 Concept 页面；Dependency-Management 和 Semantic-Versioning 作为支撑概念也一并创建；index.md 和 overview.md 均已更新；已建立与 ctp-topic-9（Gruntwork CI/CD）、ctp-topic-33（GitOps 入门）、ctp-topic-32（Atlantis CI/CD）的连接关系；Gruntwork 已有 Entity 页面（wiki/entities/Gruntwork.md），无需新建
- Conflicts: （暂无）

## [2026-04-24] ingest | Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md
- Status: ✅ 成功摄入
- Summary: Oli 工作流（超大规模云厂商支出审批三级工作流）+ 需求管理自动化端到端流程（ITIL 框架、Octane/Qixi 提交入口、主服务目录嵌入 SMACs、"机器做机器能做的事"理念）
- Concepts identified: [[Demand-Management]], [[ITIL-Service-Management]], [[FinOps]], [[SMACs]]
- Entities identified: [[Tom-Bice]], [[FPNA-Team]], [[MUI]], [[Shannon]], [[Octane]], [[Qixi]]
- Source page: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md
- Notes: entities 和 concepts 目录均为空（无历史页面）；未满足 ≥2 次出现条件，不新建独立页面，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation 章节已补充（置于 ctp-topic-57 后）；已建立与 ctp-topic-57（Backlog 管理管道）、ctp-topic-65（价值量化）、public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109（需求分析前置技法）、ctp-topic-4（敏捷实践）的连接关系
- Conflicts: （暂无）

- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md
- Status: ✅ 成功摄入
- Summary: Landing Zone 环境下通过 Terraform/Terragrunt 实现基础设施部署与维护的完整方法论；核心区分 Service Module（业务视角）与 Regular Module（技术视角）的分层抽象；Terragrunt HCL 版本锁定；Service Catalog 三级复用（单账户→产品团队→跨团队）
- Concepts identified: [[Service Module]], [[Service Catalog]], [[Terragrunt]], [[Infrastructure as Code]], [[Terraform Module]]
- Entities identified: [[Gruntwork]], [[AWS Landing Zone]]
- Source page: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md
- Notes: 已建立与 ctp-topic-1（Gruntwork LZ 架构）、ctp-topic-9（CI/CD with Gruntwork）、ctp-topic-32（Atlantis CI/CD）、ctp-topic-33（GitOps 入门）、ctp-topic-39（EKS Atlantis 约束差异）的连接关系；Service Module/Service Catalog 仅出现 1 次，不满足 ≥2 次建页条件，以 wikilink 形式记录于 Source page；index.md 已更新；overview.md Cloud Transformation & DevOps 章节已更新
- Conflicts: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 存在 Atlantis EKS 支持约束差异（Topic 3 通用原则 vs Topic 39 具体实践）

## [2026-04-24] ingest | CTP Topic 9 CI CD with Gruntwork
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-9-ci-cd-with-gruntwork.md
- Status: ✅ 成功摄入
- Summary: CTP Topic 9 CI/CD 与 Gruntwork 在 AWS Landing Zone 中的实践视频；源文档状态为"待 Whisper 转录"，基于文件元数据生成初始页面
- Concepts identified: [[CI/CD Pipeline]], [[Infrastructure as Code]], [[Gruntwork]], [[Terraform]], [[Terragrunt]]
- Entities identified: [[Gruntwork]], [[AWS Landing Zone]], [[Cloud Transformation Programme]]
- Source page: wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md
- Notes: 源视频待转录，Key Claims/Key Quotes 为占位内容；已建立与 ctp-topic-1（Gruntwork LZ 架构）、ctp-topic-2（Git）、ctp-topic-33（GitOps 入门）、ctp-topic-32（Atlantis CI/CD）的连接关系；index.md 已更新；overview.md Cloud Transformation & DevOps 章节已更新；无需新建 Entity/Concept 页面
- Conflicts: （暂无，待视频转录后补充）

## [2026-04-14] ingest | CTP Topic 32 Using Atlantis CICD for Infrastructure Deployments
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md
- Status: ✅ 成功摄入
- Summary: Atlantis 替代 Jenkins 用于 Terraform IaC 部署的 CTP 学习视频，涵盖 Atlantis 架构（单 EC2 + GitHub Webhook）、PR 评论式协作模型、跨账户 IAM 角色访问、并行构建、模块锁定机制
- Concepts identified: [[GitOps]], [[Infrastructure-as-Code]], [[CI/CD Pipeline]], [[Terraform]]
- Source page: wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md
- Notes: Source page 已创建；index.md 已更新（Sources 节顶部）；overview.md Cloud Transformation & DevOps 章节已更新；GitOps.md sources 列表已更新；已识别与 ctp-topic-39（EKS 不支持 Atlantis）的矛盾点并记录于 Contradictions 节
- Conflicts: [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]（Atlantis 不支持 EKS 部署 vs Atlantis 可替代 Jenkins 全面部署）

## [2026-04-14] ingest | CTP Topic 2 Git
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md
- Status: ✅ 成功摄入
- Summary: CTP Topic 2 Git 版本控制系统基础与实践视频讲座，作为 CI/CD/GitOps 系列开篇；源文档状态为"待 Whisper 转录"
- Concepts identified: [[Git]], [[Version Control]], [[DevOps]]
- Entities identified: [[Cloud Transformation Programme]]
- Source page: wiki/sources/ctp-topic-2-git.md
- Notes: 源视频待转录，Key Claims/Key Quotes 为占位内容；已建立与 ctp-topic-9（CI/CD with Gruntwork）和 ctp-topic-33（GitOps 入门）的连接关系；index.md 已更新，overview.md Cloud Transformation & DevOps 章节已更新

## [2026-04-14] ingest | CTP Topic 24 Micro Focus Product Privacy Framework
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-24-micro-focus-product-privacy-framework.md
- Status: ✅ 成功摄入
- Summary: Micro Focus 产品隐私框架在云转型中的应用——PSAC 与法律顾问合作，将 GDPR/CCPA 等晦涩法律条款翻译为约 110 项低级别技术要求；隐私框架是 STLC（安全开发生命周期）中 13 个安全与隐私轨道之一；通过五类需求（架构类/文档类/法律类/实现类/SAS 运营类）和成熟度模型（0-4 级）评估产品隐私合规状态；通过"蜘蛛图"直观展示产品隐私 KPI 合规现状
- Concepts identified: [[Product Privacy Framework（产品隐私框架）]], [[STLC（Security Development Life Cycle）]], [[PSAC（Product Security Advisory Committee）]], [[PII（Personally Identifiable Information）]], [[Maturity Model（成熟度模型）]], [[Spider Chart（蜘蛛图）]], [[Product Privacy Settings Document]], [[Data Controller vs. Data Processor]], [[Anonymization & Pseudonymization]]
- Entities identified: [[Micro Focus]], [[Shlomi Ben-Hur]]
- Source page: wiki/sources/ctp-topic-24-micro-focus-product-privacy-framework.md
- Notes: 无冲突检测；CTP Topic 21 和 Topic 24 均由 Shlomi Ben-Hur 主讲，PSAC 作为产品安全顾问委员会在多个 topic 中出现，实体创建条件待后续评估；STLC 作为 SDLC 的安全扩展已有提及，本次独立建 Concept 页面；overview.md 已更新，新增条目和 Key Concepts/Entities

## [2026-04-24] ingest | CTP Topic 49 Container Lifecycle Hardening Standards
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md
- Status: ✅ 成功摄入
- Summary: Micro Focus 产品安全小组 Ashish 主讲，容器镜像构建阶段 11 条安全加固标准——基础镜像选择、Init 系统（tini 防止僵尸进程）、只读根文件系统（readOnlyRootFilesystem: true）、emptyDir Volume、禁用 Kubernetes API 自动挂载（automountServiceAccountToken: false）、私有服务账号+RBAC、避免 hostNetwork/hostPort
- Concepts created: [[Container-Lifecycle-Hardening]], [[Pod-Security-Context]], [[emptyDir-Volume]]
- Entities created: [[Ashish]], [[Product-Security-Group]], [[tini]]
- Source page: wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md
- Notes: 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 就 hostNetwork 配置存在场景冲突（Topic 39 Lab 环境特例 vs Topic 49 通用最佳实践）；检测到 3 个潜在概念（Container-Lifecycle-Hardening/Pod-Security-Context/emptyDir-Volume）和 3 个实体（Ashish/Product-Security-Group/tini），均已创建 Entity/Concept 页面；overview.md 已更新

## [2026-04-14] ingest | CTP Topic 21 Supply Chain Security in Micro Focus
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-21-supply-chain-security-in-micro-focus.md
- Status: ✅ 成功摄入
- Summary: Micro Focus 软件供应链安全新方法——供应链（产品层面）涵盖 SCM/CI/CD 全环节；驱动因素：SolarWinds 攻击事件、美国网络安全行政命令、AWS/SaaS 迁移风险；安全观念转变：从 99% 关注研发安全转向全生命周期防护；供应链安全成为 SDL 第五支柱，强调 CI 和 CD 过程完整性
- Concepts identified: [[Supply Chain Security（供应链安全）]], [[SolarWinds Hack]], [[CI/CD Security]], [[SDL（Security Development Lifecycle）]], [[Executive Order on Cybersecurity]], [[Lateral Movement]]
- Entities identified: [[Micro Focus]], [[Shlomi Ben-Hur]]
- Source page: wiki/sources/ctp-topic-21-supply-chain-security-in-micro-focus.md
- Notes: 无冲突检测；Micro Focus 已在多处来源提及但无独立 Entity 页面，本次补充创建；SolarWinds/Shlomi Ben-Hur 仅出现一次，不满足 Entity 创建条件

## [2026-04-24] ingest | CTP Topic 52 3 Lines of Defence (3LoD) Framework Cloud Security Posture Management
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md
- Status: ✅ 成功摄入
- Summary: 3LoD 安全治理框架落地（业务单元→集团职能部门→审计三层责任分层）+ Cloud Guard CSPM 工具选型（态势管理/资产管理/网络可视化/事件管理/威胁情报）+ 新账户创建流程中自动纳入 Cloud Guard
- Concepts identified: [[Three Lines of Defence（3LoD）]], [[Cloud Security Posture Management（CSPM）]]
- Source page: wiki/sources/ctp-topic-52-3-lines-of-defence-3lod-framework-cloud-security-posture-management.md
- Notes: 无冲突内容；3LoD/CSPM 均属行业通用概念，已有 CSPM 相关内容于 cloud-security.md；Cloud Guard 为该组织专用 CSPM 工具，暂不单独建 Entity 页面

## [2026-04-24] ingest | CTP Topic 55 AWS Firewall Manager
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-55-aws-firewall-manager.md
- Status: ✅ 成功摄入
- Summary: AWS Firewall Manager 在 Grand Torque 多 Landing Zone 环境中的集中化安全策略管理实践——跨 RLABS/R&D/SAS/CAT 多个 Landing Zone 统一部署基线安全组；三种策略类型（通用/审计强制/清理冗余）；通过 AWS Config + Lambda 实现自动修复；RAM 前缀列表跨账户共享规则；独立 Firewall Manager 账户支持跨 LZ 部署；Demo 展示 EC2 实例安全组的自动附加与移除
- Concepts identified: [[Security-Group]], [[Prefix-List]], [[Auto-Remediation]], [[WAF-Rules-Management]]
- Entities identified: [[AWS-Firewall-Manager]], [[Landing-Zones]], [[QALIS]], [[Checkpoint-Firewall]]
- Source page: wiki/sources/ctp-topic-55-aws-firewall-manager.md
- Notes: 无冲突检测；与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 中的 Checkpoint 方案属互补关系（网络边界防火墙 vs 实例级安全组基线），已于 Contradictions 节记录

## [2026-04-30] ingest | CTP Topic 37 Secrets Certificates Management
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-37-secrets-certificates-management.md
- Status: ✅ 成功摄入
- Summary: 云转型计划密钥与证书管理解决方案选型与实施——30天试点对比 AWS Secrets Manager 与 HashiCorp Vault，AWS Secrets Manager 以更低成本和更简实施胜出；实施阶段从 Control Tower 开始，从 CI/CD 流程清除明文密钥，集中化管理。
- Concepts identified: [[Secrets-Management]], [[AWS-Secrets-Manager]]
- Entities identified: [[Micro-Focus]], [[CCLE]]（CCLE 在 2022 年 3 月负责评估工作，关键组织角色）
- Source page: wiki/sources/ctp-topic-37-secrets-certificates-management.md
- Notes: 无冲突；与 [[ctp-topic-62-aws-secrets-manager]] 的关系记录于 Contradictions 节（Topic 37 试点结论 + Topic 62 深度实践，属补充关系而非冲突）

## [2026-04-30] ingest | CTP Topic 62 AWS Secrets Manager
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-62-aws-secrets-manager.md
- Status: ✅ 成功摄入
- Summary: AWS Secrets Manager 企业级密钥管理——Nurit & Daniel 分享。选型：HashiCorp Vault vs AWS Secrets Manager POC，AWS Secrets Manager 以更低成本和更简实施胜出。分阶段实施：集中化密钥 → 自动化获取 → 轮换。核心原则：开发者无需直接访问密钥，IAM 角色+标签控制访问。实施案例：Oracle DB 密码轮换（Lambda）、SendGrid API 密钥集中化轮换（无需应用重启）、JDBC Wrapper + AWS SDK 免密登录。
- Concepts identified: [[Secrets-Management]], [[Secret-Rotation]], [[JDBC-Wrapper]], [[AWS-Secrets-Manager]], [[HashiCorp-Vault]]（HashiCorp Vault 作为备选方案被记录于源页面，实体重要性待定）
- Entities identified: [[Nurit]], [[Daniel]], [[Victor]]（CTP Topic 62 演讲者和演示者，作为演讲者提及一次，暂不创建独立页面）
- Source page: wiki/sources/ctp-topic-62-aws-secrets-manager.md
- Notes: 无冲突检测；相关来源 [[ctp-topic-37-secrets-certificates-management]] 和 [[ctp-topic-36-sendgrid-as-an-email-service]] 已于 Contradictions 和 Connections 节记录

## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md
- Status: ✅ 成功摄入
- Summary: OpenText 全球信息安全团队（GIS）安全策略全景——Mike & Ed 主讲。GIS 分层组织架构（安全运营/合规/治理风险验证/隐私）；OpenText 分层方法定义安全策略；ISO 27001 姿态框架（2022年更新）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查；每月处理 2250 亿条日志，分诊约 350 个案例；FedRAMP 等多项认证支撑多垂直市场销售。
- Concepts identified: [[ISO-27001]], [[FedRAMP]], [[Global-Information-Security-Policy]], [[Security-Awareness-Training]], [[Third-Party-Penetration-Testing]], [[Threat-Intelligence]], [[BrightCloud]]（均以 wikilink 形式记录于 Source page，各仅出现 1 次，暂不创建独立页面）
- Entities identified: [[Mike]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page）, [[Ed]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md）
  - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于所有条目最前）
  - overview.md 更新：新增 GIS Security Policies 摘要条目（置于 Thor Platform 之后，CTP Topic 28 之前）；Key Concepts 新增 ISO-27001/FedRAMP（已有条目）、BrightCloud 等
  - Connections 已建立：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 建立 related_to 关系
  - 冲突检测：与 [[ctp-topic-10]] 的互补而非冲突关系已记录于 Source Page Contradictions 节——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地

## [2026-04-25] ingest | CTP Topic 64 Scaling out with Amazon EKS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md
- Status: ✅ 成功摄入
- Summary: Amazon EKS 工作负载扩缩容完整方法论——Pod 层：HPA（标准指标）+ KEDA（事件驱动）；Node 层：Cluster Autoscaler（ASG 联动）+ Karpenter（直接 EC2 API）；IP 耗尽解决方案：IPv6 双栈 VPC；集群稳定性：API Server PPF + CoreDNS 扩缩容。Suravpul 主讲。
- Concepts identified: [[Horizontal Pod Autoscaler (HPA)]]（已在 ctp-topic-59 提及）, [[KEDA]]（新）, [[Cluster Autoscaler]]（已在 ctp-topic-70 提及）, [[Karpenter]]（已在 Part 1 提及）
- Entities identified: [[Suravpul]]（AWS 高级解决方案架构师，ctp-topic-59/64/67 三专题讲师）
- Source page: wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md
- Notes: 与 ctp-topic-59（EKS 可靠性，HPA/VPA）和 ctp-topic-70（IaC 部署，Cluster Autoscaler）形成互补知识链路。与 Part 3 EKS Auto Mode 共享 Karpenter 知识节点。

## [2026-04-25] ingest | CTP Topic 67 Cloud native observability using OpenTelemetry
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-67-cloud-native-observability-using-opentelemetry.md
- Status: ✅ 成功摄入
- Summary: AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践。涵盖可观测性三信号模型（Traces/Metrics/Logs）、OpenTelemetry Collector 架构（Receivers → Processors → Exporters）、ADOT 的多种 EKS/ECS 部署模式。核心观点：构建可观测的应用是开发者的责任；Trace 捕获调用栈各层处理耗时；Correlation ID 实现跨信号关联。
- Concepts identified: [[OpenTelemetry]], [[Three Signals]], [[SIGV4 Auth Extension]], [[Correlation ID]]
- Source page: wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md
- Notes: 与 ctp-topic-60（Hyperscale Observability with Grafana）同属可观测性专题，与 public-cloud-learning-sessions-observability-with-opentelemetry-20240402 同属 OpenTelemetry 主题

## [2026-04-24] ingest | Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md
- Status: ✅ 成功摄入
- Summary: Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版。核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。
- Concepts identified: [[Immutable-Root-Filesystem]], [[dm-verity]], [[SE-Linux-Enforcing]], [[Partition-Updates]], [[CIS-Benchmark]]
- Entities identified: [[Bottlerocket]], [[Amazon EKS]], [[AWS]]
- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md
- Notes: EKS 优化三专题 Part 2（Part 1 = Karpenter 计算优化，Part 3 = EKS Auto Mode）。Bottlerocket Entity 和 5 个 Concept 均为新增。Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统，形成知识链路补充。

## [2026-04-24] ingest | CTP Topic 42 Grafana Observability Dashboard
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-42-grafana-observability-dashboard.md
- Status: ✅ 成功摄入
- Summary: 企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践。涵盖 Grafana 核心定位（不存储数据，仅从数据源可视化）、基础设施架构（监控账户部署 Grafana，通过 IAM 角色跨账户访问产品团队 AWS 账户）、用户和团队访问控制、示例仪表盘（CPU/I/O/Network/EBS/Estimated Charges）、告警系统（Microsoft Teams 通知）、Terraform 模块化供给（数据源模块 + 组织模块 + LZSAP 自动化接入）、Prometheus 网络监控（Checkpoint/防火墙 SNMP 指标）。
- Concepts identified: [[Observability（可观测性）]], [[Prometheus]], [[SNMP（Simple Network Management Protocol）]], [[IAM Role（跨账户角色）]]
- Entities identified: [[AWS CloudWatch]], [[AWS Landing Zone]], [[Micro Focus Operations Bridge Manager]]
- Source page: wiki/sources/ctp-topic-42-grafana-observability-dashboard.md
- Notes: 该视频与 [[ctp-topic-60]] 均介绍 Grafana，视角互补（Grafana 本身 vs Hyperscale 场景），与 [[ctp-topic-54]] 和 [[ctp-topic-67]] 同属可观测性专题，共同构成监控知识体系。长期目标是构建应用级仪表盘替代 Micro Focus OBM。Entity 和 Concept 已有 Grafana/Prometheus/Terraform/Checkpoint 等，无需新建。

## [2026-04-25] ingest | CTP Topic 54 ESM SaaS Log Analytics
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-54-esm-saas-log-analytics.md
- Status: ✅ 成功摄入
- Summary: ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案——ELK/OpenSearch 技术栈架构（BEATS/Filebeat → Logstash → Elasticsearch/OpenSearch → Kibana）、双 VPC 隔离架构、Redis 缓冲层、GDPR 合规区域分割。安全：NVMe 静态加密、TLS 1.2、VPC 私有流量、RBAC。方案对比：AWS OpenSearch（~$1,500/月，SLA 99.9%，推荐）vs Logz.io（~$4,000/月，SLA 99.8%）vs 自托管 ELK vs Microfocus OBA。
- Concepts identified: [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[GDPR]]
- Entities identified: [[AWS OpenSearch]], [[Jackie]]
- Source page: wiki/sources/ctp-topic-54-esm-saas-log-analytics.md
- Notes: 新建 Concept 页面 ELK-Stack.md、BEATS.md；新建 Entity 页面 AWS-OpenSearch.md；已更新 overview.md（Sources 条目 + Key Concepts）；Key Concepts 列表中已有 Centralized-Logging、Redis缓存（Redis缓存.md）、TLS，未发现冲突内容

## [2026-04-26] ingest | CTP Topic 59 Achieving reliability with Amazon EKS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md
- Status: ✅ 成功摄入
- Summary: Amazon EKS 可靠性最佳实践——Surav Paul（AWS 高级解决方案架构师）主讲。涵盖 ECS vs EKS 选型、可靠性五维度（故障检测/优雅降级/确定性故障/自愈/按需扩缩）、Shared Responsibility Model（Fargate 免除节点管理）、应用层可靠性（AZ 分散/拓扑约束/HPA/VPA/部署策略/健康探针/PodDisruptionBudget）、控制平面可靠性（指标监控/认证加固/Webhook 管理/集群升级）和数据平面可靠性（节点问题检测/资源预留/QoS/配额/Pod 优先级）。
- Concepts identified: [[Reliability（系统可靠性）]], [[Application Reliability（应用可靠性）]], [[Control Plane Reliability（控制平面可靠性）]], [[Data Plane Reliability（数据平面可靠性）]], [[Shared Responsibility Model（EKS）]], [[Pod Anti-Affinity]], [[Topology Spread Constraints]], [[Horizontal Pod Autoscaler (HPA)]], [[Vertical Pod Autoscaler (VPA)]], [[Liveness/Readiness/Startup Probes]], [[PodDisruptionBudget]], [[Rolling/Blue-Green/Canary Deployment]]（均以 wikilink 形式记录于 Source page；均仅出现 1 次，暂无独立页面）
- Entities identified: [[Surav Paul]], [[Amazon EKS]], [[Amazon ECS]], [[AWS Fargate]]（均以 wikilink 形式记录于 Source page；仅 [[Amazon EKS]] 在多个页面中反复出现，符合独立页面创建条件，其余仅出现 1 次，暂无独立页面）
- Source page: wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md）
  - index.md 更新：新增 CTP Topic 59 条目于 Sources 节顶部
  - overview.md 更新：新增 CTP Topic 59 条目于 Cloud Transformation & DevOps → EKS 知识链路
  - Contradictions 记录：与 ctp-topic-39（EKS Lab LZ 网络部署）存在视角差异——Topic 39 面向受限网络环境的自定义网络方案，Topic 59 提供通用 EKS 可靠性最佳实践，互为补充而非冲突
  - 无需新建 Concept/Entity 独立页面（所有概念和实体仅在本页面出现 1 次；Amazon EKS 虽在多个其他页面提及，但本页面无新增独立维度，不单独创建）

## [2026-04-26] ingest | CTP Topic 29 Cloud Monitoring – SaaS LZ accounts
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md
- Status: ✅ 成功摄入
- Summary: AWS 云监控解决方案 OpsBridge Cloud Monitoring 覆盖多账户多区域的云原生监控架构——容器化部署于 EKS，支持 20+ AWS 数据服务，数据存储于 Optic Data Lake（Vertica）；通过 IAM Role 信任关系实现只读跨账户 CloudWatch 数据采集，无需在被监控账户安装服务器或共享 Access Key；基于标签的监控是最佳实践，自动化识别缺失标签；单一 OpsBridge 实例监控多账户多区域，降低运维成本；与 OpsBridge 产品研发团队协作，报表功能在下一版本持续增强。
- Concepts identified: [[Cloud Monitoring（AWS）]], [[Tag-Based Monitoring]], [[Vertica]], [[OpsBridge]], [[ITOM（IT Operations Management）]]（均以 wikilink 形式记录于 Source page；仅出现 1 次，暂无独立页面）
- Entities identified: [[Micro Focus OpsBridge]], [[AWS CloudWatch]], [[AWS Landing Zone]]（均以 wikilink 形式记录于 Source page；仅出现 1 次，暂无独立页面）
- Source page: wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md）
  - index.md 更新：新增 CTP Topic 29 条目于 Sources 节顶部
  - Contradictions 记录：与 ctp-topic-8（OBM 监控）存在视角差异——Topic 8 描述基础 OBM 组件栈（三层架构），Topic 29 描述 Cloud Monitoring 新模块（容器化+EKS+20+数据服务），当前观点认为两者是同一方案的不同层面

## [2026-04-24] ingest | CTP Topic 60 - Monitor AWS using Hyperscale Observability with Grafana
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md
- Status: ✅ 成功摄入
- Summary: 使用 Grafana Enterprise 实现 AWS 超大规模可观测性监控——Vinay 主讲（代替休假的 Sashi）。核心内容：Grafana 与多数据源集成、事件追踪、告警配置、实例监控和资源标签化；Optic DR 作为 VaticaDB 插件是导入 Grafana 仪表板的关键数据源；*Opsbridge 监控解决方案使用仪表板展示触发事件；Grafana 告警系统支持多通知渠道，可转发至 Opsbridge 创建工单；Terraform 模块自动化创建 Grafana 组织、用户、文件夹、IAM 角色和仪表板；默认指标不产生额外成本，自定义指标可能产生费用。未来路线图：SSO 认证、报表、URL 监控、进程监控、日志监控、与 PagerDuty/Slack Manager 集成。
- Concepts identified: [[Hyperscale Observability]], [[Dashboard as Code]], [[Grafana Alert System]], [[Resource Tagging]], [[Instance Monitoring]], [[Event Tracking]]（均以 wikilink 形式记录于 Source page）
- Entities identified: [[Vinay]], [[Optic DR]], [[Opsbridge]], [[VaticaDB]], [[Grafana]], [[Terraform]]（均以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md）
  - index.md 更新：新增 CTP Topic 60 条目于 Sources 节顶部
  - Contradictions 记录：与 ctp-topic-8（OBM 监控）的互补而非冲突关系已记录

## [2026-04-26] ingest | CTP Topic 8 Implementation of Cloud monitoring using Micro Focus Operations Bridge Manager
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md
- Status: ✅ 成功摄入
- Summary: 使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用 + Postgres RDS + Operation Agent 三层组件；Agent 通过 AWS Management Pack 利用 IAM Role 跨账户采集 CloudWatch 指标，无需在被监控账户安装服务器或共享 Access Key；Global OBM 作为 Manager of Managers 汇聚 Regional OBM 数据，事件通过 SMACKS 触发工单；新增实例自动发现与策略自动下发，解决云环境动态性监控难题；支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务。
- Concepts identified: [[Cloud-Monitoring]], [[Management-Pack]]（均已创建独立 Concept 页面）
- Entities identified: [[SMACKS]]（已有页面，更新 sources；其余实体仅出现 1 次，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid.md）
  - 新增 2 个 Concept Page（wiki/concepts/Cloud-Monitoring.md, wiki/concepts/Management-Pack.md）

## [2026-04-24] ingest | CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md
- Status: ✅ 成功摄入
- Summary: EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题：Micro Focus 网络的 AWS Lab 环境 IP 地址池不足，无法满足 Octane（IP 密集型 SaaS 应用）的 EKS Pod 需求。解决方案：创建独立私有子网（非主 VPC 子网）为 EKS Pod 提供充足 IP 池；EKS 模块自定义网络标志控制 Pod IP 分配；Terraform/Terragrunt 模块封装完整 EKS 部署逻辑，支持跨账户角色映射；Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源。Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。
- Concepts identified: [[Amazon EKS]], [[Kubernetes Custom Networking]], [[Terraform-Terragrunt Module]], [[IAM Role Mapping (EKS)]], [[Host Network Mode (Pod)]], [[Container Hardening]]（均以 wikilink 形式记录于 Source page；均仅出现 1 次，暂无独立页面）
- Entities identified: [[Octane-Hub]]（已有页面，更新 sources）、[[Terragrunt]], [[Atlantis]]（工具名，均仅出现 1 次，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md）
  - index.md 更新：新增 CTP Topic 39 条目于 Sources 节顶部
  - overview.md 更新：新增 CTP Topic 39 条目于 EKS 知识链路
  - 无需新建 Concept/Entity 独立页面（所有概念和实体仅出现 1 次）

## [2026-04-26] ingest | Public Cloud Learning Sessions EKS Optimization Part 3 of 3 Introduction to EKS Auto Mode
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks-.md
- Status: ✅ 成功摄入
- Summary: EKS Auto Mode 将 Kubernetes 数据平面管理责任从用户扩展至 AWS。Carpenter Controller 负责节点生命周期和滚动升级；Bottlerocket OS 提供最小化安全容器操作系统，自动应用安全补丁；AWS Load Balancer Controller（eks.aws/alb）管理 ingress；EBS CSI Controller 支持有状态工作负载；Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制；Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池（General Purpose AMD64 + System taint），支持自定义 Graviton 节点池。每个 Auto Mode 实例附加 12% 管理溢价。
- Concepts created: [[EKS Auto Mode]]（已创建独立 Concept 页面）
- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks.md）
  - 新增 1 个 Concept Page（wiki/concepts/EKS-Auto-Mode.md）
  - Entities：AWS 和 Amazon EKS 已在 overview.md 中存在，无需新建 Entity 页面

## [2026-04-24] ingest | Image Prompt Engineer Agent
- Source file: Agent/agency-agents/design/design-image-prompt-engineer.md
- Status: ✅ 成功摄入
- Summary: Image Prompt Engineer Agent 角色定义——AI 图像生成提示词工程专家智能体，专注于将视觉概念精准翻译为可执行的提示词语言，驱动 Midjourney/DALL-E/Stable Diffusion/Flux 等 AI 图像生成工具产出专业级摄影作品。核心方法：五层提示词结构框架（主体描述层 → 环境设定层 → 光线规范层 → 摄影技术层 → 风格美学层）+ 平台特定语法优化 + 体裁专属提示模式（人像/产品/风光/时尚摄影）。核心原则：摄影术语精确性 + 负向提示词 + 宽高比构图。成功指标：视觉概念还原率 90%+。与 [[design-ui-designer]]（像素级精确）存在张力，已记录于 Contradictions；与 [[design-brand-guardian]]（品牌一致性）、[[design-whimsy-injector]]（品牌趣味）协同，构成 [[The Agency]] 设计部门完整设计支撑体系。
- Concepts linked: [[Prompt-Engineering]], [[Five-Layer-Prompt-Structure]], [[Platform-Specific-Prompt-Optimization]], [[Negative-Prompts]], [[Film-Emulation]], [[Lighting-Patterns]]
- Entities linked: [[Midjourney]], [[DALL-E]], [[Stable-Diffusion]], [[Flux]], [[Annie Leibovitz]], [[Peter Lindbergh]], [[The Agency]]
- Source page: wiki/sources/design-image-prompt-engineer.md
- Notes: index.md 已替换占位符条目；overview.md 已新增独立段落（置于 design-whimsy-injector 之后，design-brand-guardian 之前）；无新 Entity/Concept 需创建（Midjourney/DALL-E/Stable-Diffusion/Flux/Prompt-Engineering 等仅出现 1 次，不足建页阈值）；与 [[design-ui-designer]] 在概率生成 vs 像素精确的张力已记录于 Contradictions 节——通过确定性约束（具体颜色值/光照参数）协调
- Conflicts: 与 [[design-ui-designer]] 在视觉还原精度上的差异——Image Prompt Engineer 目标 90%+ 概念还原（概率生成固有不确定性），UI Designer 要求 95%+ 实现准确率（设计到代码的翻译环节）；已建立协调方案

## [2026-04-24] ingest | CTP Topic 11 AD Integration and Login using AD Accounts
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md
- Status: ✅ 成功摄入
- Summary: Jenkins 与 SW Infra AD 安全域集成，实现基于 AD 账号的统一身份认证与自动化用户管理（入离职无需手动维护本地用户）；通过 AD 组策略实现 RBAC 精细化权限控制（只读/读写/流水线创建）；pre-commit 框架集成 terraform fmt/TFLint/Checkov 三款工具在代码提交阶段嵌入自动化安全检查；CI/CD 流水线分层治理模式（Commit 检查 → PR 检查+plan → Master 人工审核后 apply），核心理念为"左移"（Shift-Left）将安全问题提前到开发早期。
- Concepts identified: [[Active Directory Integration]], [[RBAC (Role-Based Access Control)]], [[Pre-commit Framework]], [[Terraform Fmt]], [[TFLint]], [[Checkov]], [[Shift-Left Security]], [[CI/CD Pipeline Governance]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面）
- Entities identified: [[Niranjan]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-11-ad-integration-and-login-using-ad-accounts.md）
  - index.md 更新：新增 CTP Topic 11 条目于 Sources 节顶部
  - overview.md 更新：新增 CTP Topic 11 详细条目于身份治理知识体系段落
  - Contradictions 记录：与 Atlantis（ctp-topic-32）关于 terraform apply 审批权的差异已记录

## [2026-04-24] ingest | CTP Topic 5 - AWS Identity and Access Management (IAM)
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/ctp-topic-5-aws-identity-and-access-management-iam.md
- Status: ✅ 成功摄入
- Summary: AWS IAM 核心组件与联邦访问机制——IAM Dashboard 四大资源（用户、组、客户托管策略、角色、身份提供商）；联邦用户通过 Active Directory 组映射到 IAM 角色；accounts.json 位于 Landing Zone 根目录；IAM 用户主要用于服务账号，人工用户优先使用联邦访问；角色本身不启用操作，而是将"谁可以做什么"与"可以做什么"关联；策略分为 AWS 托管和客户托管，Terraform 模块可定义 IAM 角色；PFSSO 工具实现 CLI 联邦访问；最小权限原则贯穿始终。
- Concepts identified: [[IAM（身份和访问管理）]], [[Federation（联邦身份）]], [[Least Privilege（最小权限）]], [[IAM Role（IAM 角色）]], [[IAM Policy（IAM 策略）]], [[Managed Policy vs Inline Policy]], [[Cross-Account Role Assumption]], [[PFSSO]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面）
- Entities identified: [[accounts.json]], [[VSM]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值）
- Source page: wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-5-aws-identity-and-access-management-iam.md）
  - index.md 更新：替换原有缺失条目为完整条目（日期 2026-04-24）
  - overview.md 更新：新增 CTP Topic 5 条目于身份治理知识体系段落

## [2026-04-24] ingest | Public Cloud Learning Sessions - AWS End User Compute Services - 20240430
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md
- Status: ✅ 成功摄入
- Summary: AWS EUC 服务全景介绍——覆盖 Workspaces（全持久虚拟桌面）、AppStream 2.0（选择持久/非持久应用流，多租户降本）、Workspace Core（第三方 VDI 集成）、Workspace Web（低成本安全浏览器）四大服务。选型原则：知识工作者完整桌面 → Workspaces；实验室/培训/非持久 → AppStream 2.0；第三方 VDI → Workspace Core；安全浏览 → Workspace Web。安全措施包括 AD 集成、加密、IAM 配置文件、SAML 认证、多因素认证。
- Concepts identified: [[Amazon-Workspaces]], [[AppStream-2.0]], [[AWS-End-User-Computing]], [[Virtual-Desktop-Infrastructure]], [[WSP-Protocol]], [[BYOD]], [[VDI]], [[SAML-Authentication]], [[VPC-Interface-Endpoints]]（均以 wikilink 形式记录于 Source page；各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面）
- Entities identified: [[Christian-O'Donough]]（仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-aws-end-user-compute-services-20240430-160120-mee.md）
  - index.md 更新：在 Sources 节顶部新增条目（日期 2026-04-24）
  - overview.md 更新：在 ctp-topic-6-aws-workspaces-demo 之后新增摘要段落；与 [[ctp-topic-6-aws-workspaces-demo]] 建立关联关系
  - Connections 已建立：与 [[ctp-topic-6-aws-workspaces-demo]]（实操演示）、[[AWS-Landing-Zone]]（VPC 架构）建立 depends_on 关系
  - 冲突检测：无已知冲突内容

## [2026-04-30] ingest | Public Cloud Learning Sessions - Applicable Business Analysis Techniques - 20240109
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109-.md
- Status: ✅ 成功摄入
- Summary: 业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型（连接业务与技术）、BOSCARD框架（复杂新工作定义）、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。INVEST原则检查需求质量，SAFe框架补充Features/Capabilities/NFR。核心理念：业务分析将业务需求与技术变更解决方案对齐，帮助定义企业架构中哪些变更是有益的。
- Concepts identified: [[Business-Analysis]], [[T-Shaped-Skills]], [[BOSCARD]], [[Stakeholder-Wheel]], [[Requirements-Gathering]], [[INVEST]], [[SAFe]], [[RACI]]（均以 wikilink 形式记录于 Source page；各仅出现 1 次，未达 ≥2 次阈值，暂不创建独立页面）
- Entities identified: [[BCS]], [[IIBA]], [[OpenText]]（均仅出现 1 次，未达 ≥2 次阈值，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109.md）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2024-01-09，添加摘要）
  - overview.md 更新：在 Cloud Transformation & DevOps 部分新增摘要段落（置于 ctp-topic-4 之后）；Key Concepts 新增 Business-Analysis、T-Shaped-Skills、BOSCARD、Stakeholder-Wheel、Requirements-Gathering、INVEST、SAFe
  - Connections 已建立：与 ctp-topic-4（敏捷实践）、ctp-topic-57（需求管理）、ctp-topic-20（需求流程）、ctp-topic-41（NFR）建立 related_to 关系
  - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 互补而非冲突——Topic 4 提供敏捷持续流动实践框架，本视频提供需求定义前置技法，构成云转型计划完整方法论（规划→需求→执行）

## [2026-04-14] ingest | CTP Topic 23 Introduction to the Technical Architecture Team and Function
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
- Status: ✅ 成功摄入
- Summary: Martin Nash（技术架构经理）介绍技术架构团队的核心职能、组织架构及在云转型中的价值。核心主题：从被动响应转向主动规划。团队推行"云优先"策略，维护 AWS Enterprise Landing Zones。三层架构分工：EA（企业架构）对接业务战略，SA（方案架构）负责中间件与服务优化，TA（技术架构）专注底层技术实施与基础设施治理。通过划分"技术领域"并由首席架构师负责，制定 12-24 个月前瞻性路线图。
- Concepts created: [[Enterprise-Architecture]], [[Solution-Architecture]], [[Technical-Architecture]]（均已创建独立页面）
- Entities created: [[Martin-Nash]]（Technical Architecture Manager，已创建独立页面）
- Source page: wiki/sources/ctp-topic-23-introduction-to-the-technical-architecture-team-and-function.md
- Notes:
  - 新增 1 个 Source Page
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
  - overview.md 更新：在 CTP Topics 部分添加 Topic 23 摘要条目（位于 Topic 47 和 Topic 72 之间）
  - 新增 3 个 Concept 页面：Enterprise-Architecture.md, Solution-Architecture.md, Technical-Architecture.md
  - 新增 1 个 Entity 页面：Martin-Nash.md
  - Key Concepts 新增：[[Cloud-First Strategy]], [[AWS Enterprise Landing Zones]], [[Technical Domains]], [[Enterprise Architecture (EA)]], [[Solution Architecture (SA)]], [[Technical Architecture (TA)]], [[Roadmaps]], [[ITIL Alignment]]
  - 无冲突内容

## [2026-04-25] ingest | CTP Topic 57 Product backlog managing demand
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-57-product-backlog-managing-demand.md
- Status: ✅ 成功摄入
- Summary: CTP 产品待办列表（Backlog）需求管理完整管道——SMACs提交→双周评审（20题问卷）→Octane特性化→Sprint规划（50%新需求/50%支持+技术债）→Prerequisite Phase→SRE构建账号→2周Hyper Care。核心理念：透明化需求管道，确保所有工作以同一标准评估。
- Concepts identified: [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Sprint-Planning]], [[Octane]]（均以 wikilink 形式记录于 Source page）
- Entities identified: [[Matthew Chapman]], [[David Grant]], [[Brendan Starnig]], [[ADM]], [[ITOM]], [[PCG]], [[SRE]]（均以 wikilink 形式记录于 Source page；Matthew Chapman/David Grant 仅出现1-2次，未达 ≥2 阈值，暂不创建独立 Entity 页面）
- Source page: wiki/sources/ctp-topic-57-product-backlog-managing-demand.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-57-product-backlog-managing-demand.md）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
  - overview.md 更新：在 CTP Topics 部分添加 Topic 57 摘要条目（位于 Topic 41 和 Topic 65 之间）；Key concepts 新增 [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]]
  - Connections 已建立：与 CTP Topic 20（需求流程）、CTP Topic 4（敏捷实践）、CTP Topic 30（变更管理）建立 related_to 关系
  - 无冲突内容

## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Thor Platform & Flows
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
- Status: ✅ 成功摄入
- Summary: Arnold Dacan 详解 Project Thor 平台架构与数据流——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全治理、Build Hub）；核心数据流：源代码（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。
- Concepts identified: Project Thor, Supply Chain Security, Build Hub, GitLab Proxy, GitLab Geo, Code Signing（均以 wikilink 形式记录于 Source page，暂不创建独立 Concept 页面）
- Entities identified: Arnold Dacan（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page）；GitLab/Artifactory/Backstage/UCMDB（通用工具名称，不创建独立 Entity 页面）
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet.md）
  - index.md 更新：替换预期占位符为正式条目（添加摘要）
  - overview.md 更新：在 GitHub→GitLab 迁移条目后新增 Thor Platform & Flows 摘要条目
  - Connections 已建立：与 GitHub→GitLab 迁移文档建立 extends 关系；与 CTP Topic 21 建立 related_to 关系
  - 无冲突内容

## [2026-04-25] ingest | CTP Topic 6 AWS Workspaces Demo
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-6-aws-workspaces-demo.md
- Status: ✅ 成功摄入
- Summary: AWS Workspaces 虚拟桌面演示——Windows Server 2016 托管桌面，预装 PFSSO/Terraform/TerraGrunt/Git/VS Code；21分钟完成 TerraGrunt Plan；通过 Federation 访问 AWS Console，GitHub Enterprise 登录（已过期，应为 GitLab）
- Concepts identified: [[AWS Workspaces]], [[Terraform]], [[TerraGrunt]], [[PFSSO]], [[AWS Federation]]（均已存在于 Wiki 或通过 Source page 内 wikilink 引用，暂不创建独立页面）
- Entities identified: [[Naga]]（仅出现1次，未达 ≥2 阈值，以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/ctp-topic-6-aws-workspaces-demo.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-6-aws-workspaces-demo.md）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
  - overview.md 更新：在 Cloud Transformation & DevOps 部分新增 Topic 6 摘要条目
  - Contradiction 已记录：与 GitHub→GitLab 迁移文档冲突（视频录制时仍使用 GitHub Enterprise，当前已被 GitLab 替代）

## [2026-04-25] ingest | CTP Topic 53 Why bother with Cloud
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-53-why-bother-with-cloud.md
- Status: ✅ 成功摄入
- Summary: Micro Focus 云转型计划商业价值论证——14个数据中心近20,000台资产，年营收25亿美元但VMware利用率不足40%；三个产品从Bublikan迁出后下线575台物理服务器，云端仅需240台虚拟服务器；Redding退出时40%应用直接关机；当前55% AWS成本发生在LZ之外。云迁移不仅是成本节约，更是创新催化剂。
- Concepts identified: Cloud Transformation Programme, Landing Zone (Labs/SAS/Corporate), AWS Account Tagging Framework, Enterprise Platform, Multi-Cloud Strategy（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Concept 页面）
- Entities identified: Micro Focus, ELT, Bublikan, Redding, Houston, Dart, CCOE, SRE（均已在 overview.md 中以 wikilink 关联，暂不创建独立 Entity 页面）
- Source page: wiki/sources/ctp-topic-53-why-bother-with-cloud.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-53-why-bother-with-cloud.md）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14，添加摘要）
  - overview.md 更新：在 Cloud Transformation & DevOps 部分添加 Topic 53 摘要条目
  - Contradiction 已记录：与 ctp-topic-43-vmware-cloud-on-aws 的观点张力（完全迁移 vs 混合云中间路线）

## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - GitHub Enterprise to GitLab Migration
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
- Status: ✅ 成功摄入
- Summary: OpenText 将源代码管理平台从 GitHub Enterprise 迁移至 GitLab——Project Thor 整合工具链，GitLab 作为源代码控制黄金标准；GitHub 许可证12月底到期不续；各团队自服务模式规划迁移；两种迁移方案（镜像同步 / 搬移重构）；PHT 跟踪进度；网络挑战通过 Brook Park GitLab 代理解决。
- Concepts identified: Project Thor（企业工具链整合）, Build Hub（中心工具支持团队）, Self-Serve Migration（自服务迁移模式）, Mirroring（镜像同步迁移）, Shift and Lift（搬移重构迁移）, Service Account Standard（服务账号标准）
- Entities identified: OpenText, GitHub Enterprise, GitLab, Build Hub, PHT（均未达 ≥2 次阈值，暂不创建独立页面，以 wikilink 关联）
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-github-enterprise-to-gitlab-migration-20.md）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-24）
  - overview.md 更新：新增摘要段落（置于 tagging-standard-v2 之后，ctp-topic-28 之前）
  - 冲突检测：未发现与其他 Wiki 页面的矛盾冲突

## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText Tagging Standard v2
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
- Status: ✅ 成功摄入
- Summary: OpenText 云资源标签标准 v2，Martin Rosler 主讲——三大驱动力（成本优化/风险降低/自动化效率）；覆盖云账户、云资源、Kubernetes 对象和容器镜像；标准化前缀（OT\_/app.opentext.com/com.opentext.image）确保跨平台语义无歧义；最佳实践：IaC 自动化、禁止标签存敏感数据。
- Concepts identified: Cloud-Cost-Optimization（成本优化）, Tag-Standardization（标签标准化）, Kubernetes-Labeling（Kubernetes 标签）, Container-Image-Tagging（容器镜像标签）, IaC-Tagging-Automation（IaC 标签自动化）
- Entities identified: Martin-Rosler（讲师，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联）, Phenops-Team（发起团队，出现 1 次，未达 ≥2 次阈值，以 wikilink 关联）
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-tagging-standard-v2-20250429-170111-meet.md
- Notes:
  - 新增 1 个 Source Page（替换 index.md 占位符条目，日期修正为 2026-04-14）
  - overview.md 新增摘要段落（置于 ctp-topic-17 之后，ctp-topic-28 之前）；Key Entities 新增 Martin Rosler 和 Phenops-Team
  - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 无矛盾——标签标准定义「应该怎么标」，验证工具发现「谁没标好」，两者互补
  - Terraform/Kubernetes/Container-Images 已在 Key Concepts 中存在，以 wikilink 关联


- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-41-nfrs-and-error-budgets.md
- Status: ✅ 成功摄入
- Summary: NFR（非功能需求）与 Error Budget（错误预算）在云转型和敏捷开发中的实践——Brendan Standing（Head of SRE）主讲。核心：NFR Epic 模板将 NFR 集成到 Sprint Backlog；AWS 共享责任模型；Error Budget = 1 - SLO，量化系统可容忍的不可靠程度；SLR/SLO/SLA 三层体系；混沌工程主动注入故障验证韧性。核心理念：Error Budget 将失败归一化为开发流程的一部分，弥合开发与运维的文化鸿沟。
- Concepts identified: NFR（非功能需求）, Error Budget（错误预算）, Chaos Engineering
- Entities identified: Brendan-Standing, AWS, Micro Focus（各仅出现 1-2 次，未达 ≥2 次阈值，暂不创建独立页面）
- Source page: wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-41-nfrs-and-error-budgets.md）
  - NFR/Error Budget/Chaos Engineering 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - Brendan-Standing 以 wikilink 形式建立关联，暂不创建独立页面（仅出现 1 次，未达 ≥2 次阈值）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 41 摘要段落（置于 ctp-topic-30 之后，ctp-topic-65 之前）；Key Concepts 新增 NFR（非功能需求）、Error Budget（错误预算）、Chaos Engineering
  - 冲突检测：与 [[ctp-topic-30-managing-change]] 在 SRE 职责范围上存在视角差异——Topic 30 强调变更管理，Topic 41 强调可靠性工程，两者互补而非矛盾，已记录于 Source Page Contradictions 节

## [2026-04-28] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
- Status: ✅ 成功摄入
- Summary: AWS Landing Zone 部署数据收集策略与基于标签的云原生安全架构——Steve Jarman 和 Pradeep 主讲。核心：OU+SCP 分层治理、标签即凭证（替代 IP 规则）、Checkpoint 有序层防火墙（地理→类型→BU→产品→环境→角色）、Inline 层账号号父子规则。标签缺失/篡改触发 SCP 拒绝策略，确保合规。
- Concepts identified: Service-Control-Policies-SCPs, Checkpoint-Firewall, AWS-Landing-Zone, Tag-Based-Security, OU-Layered-Security
- Entities identified: Steve-Jarman, Pradeep, Checkpoint, AWS-Organizations
- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
- Notes:
  - 新增 1 个 Source Page（替换 2 个占位符条目）
  - 5 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（Service-Control-Policies-SCPs/Checkpoint 已存在于 entities/；其余各仅出现 1-2 次，未达 ≥2 次阈值）
  - 4 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Checkpoint 已存在于 entities/；Steve-Jarman/Pradeep/AWS-Organizations 各仅出现 1-2 次，未达 ≥2 次阈值）
  - index.md 更新：修正日期为 2026-04-14，移除重复占位符条目（line 416）
  - overview.md 更新：修正 CTP Topic 10 段落的 wikilink 指向新 source page；Key Concepts 新增 3 个概念（Service-Control-Policies-SCPs/OU-Layered-Security/Tag-Based-Security）
  - 冲突检测：与 [[ctp-topic-28-aws-tag-validation-tool]] 在 SCP 标签强制能力边界上存在视角差异——Topic 10 认为 SCP 可「阻止不合规资源创建」，Topic 28 认为「无法修复存量资源」。两者互补：SCP 负责预防（准入控制），Tag Validation Tool 负责发现（存量审计）

## [2026-04-27] ingest | CTP Topic 20 Program demand process flow and PoC onboarding
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
- Status: ✅ 成功摄入
- Summary: 云转型计划的程序需求流程与 POC 入职流程——Sergio 和 Damian 主讲。核心内容：需求来源（业务案例/战略优先级/产品路线图）、Gate Process 三阶段审批（Gate 0/1/3）、POC 目的（验证架构可行性+熟悉 Gruntwork Landing Zone）、新环境强调 IaC（Terraform/Terragrunt）自动化、PCG 团队职责、成功标准前置定义。
- Concepts identified: Program-Demand-Process, Proof-of-Concept, Gate-Process, Solution-Design
- Entities identified: Sergio, Damian, PCG-Team, Gruntwork, Terraform, Terragrunt
- Source page: wiki/sources/ctp-topic-20-program-demand-process-flow-and-poc-onboarding.md
- Notes:
  - 新增 1 个 Source Page
  - 4 个 Concepts 以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - 6 个 Entities 以 wikilink 形式建立关联，暂不创建独立页面（Sergio/Damian/PCG-Team 各仅出现 1 次；Gruntwork/Terraform/Terragrunt 已存在于 wiki/）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 20 摘要段落（置于 ctp-topic-65 之后，ctp-topic-47 之前）；Key Concepts 列表新增 4 个概念（Program-Demand-Process/Proof-of-Concept/Gate-Process/Solution-Design）
  - 冲突检测：与 [[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]] 存在流程视角差异——Topic 4 强调 Kanban 持续流动允许随时调整优先级，Topic 20 强调 Gate Process 阶段性审批节点。两者非逻辑矛盾，而是适用场景不同（敏捷迭代 vs 迁移治理），已记录于 Source Page Contradictions 节

## [2026-04-24] ingest | CTP Topic 4 Using Agile to Run the Cloud Transformation Programme
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
- Status: ✅ 成功摄入
- Summary: 云转型计划中敏捷实践落地经验——从 Scrum（两周 Sprint）因"Sprint 期间不允许变更"转向 Kanban 持续流动，采用混合框架（Kanban 为主 + 保留 Scrum 仪式）。Microsoft Planner 看板五列布局，最佳实践：单一负责人、依赖链接、优先级和截止日期。核心价值观：快速反馈驱动产品和开发文化持续改进。
- Entities created: Heather-Norris, Microsoft-Planner
- Concepts created: Scrum, Kanban, Agile-Ceremonies, Continuous-Delivery
- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
- Notes: 与 CTP Topic 30 (变更管理) 和 Topic 57 (需求管理) 共同构成项目管理知识体系

## [2026-04-26] ingest | CTP Topic 65 Tracing the Value Delivered in Cloud Transformation
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
- Status: ✅ 成功摄入
- Summary: 云转型价值交付量化框架——涵盖 Process/Value/Value-Stream 基础概念、Lean 三类活动识别、收益四维度量化（财务/生产力/质量/体验）、WSJF 优先级排序（Cost of Delay / Size of Job）、功能级价值拆解方法。核心理念："以最小投入尽早交付最大价值"。
- Concepts identified: Process, Value, Value-Stream, Value-Adding, Waste, Benefits-Quantification, Cost-of-Delay, WSJF, SOM, Feature-Level-Value-Breakdown
- Entities identified: CTP（Cloud Transformation Programme），Scaled-Agile（WSJF 来源框架）
- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md

  - 新增 1 个 Source Page（wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md）
  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 65 摘要段落（置于 ctp-topic-30 之后，ctp-topic-47 之前）；Key Concepts 列表新增 10 个概念
  - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 存在视角张力——Topic 53 质疑迁移必要性，Topic 65 假设迁移已决策并聚焦如何量化交付价值。两者互补而非逻辑矛盾——前者回答"是否迁移"，后者回答"如何衡量价值"。已记录于 Source Page Contradictions 节。


- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/ctp-topic-30-managing-change.md
- Status: ✅ 成功摄入
- Summary: 云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性；②变更分类——Standard Change（预批准，完全自动化）→ Normal Change（需 CAB 审批）→ Emergency Change（立即执行，事后 CAPA）；③SRE 三阶段协作——Build/Early Live Support/BAU；④Self-Healing 演进方向。
- Concepts created: Standard-Change, Normal-Change, Emergency-Change, CAPA, Early-Live-Support
- Entities created: Brendan-Starnig, SMACs
- Source page: wiki/sources/ctp-topic-30-managing-change.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-30-managing-change.md）
  - 新增 2 个 Entity 页面（Brendan-Starnig.md, SMACs.md）
  - 新增 5 个 Concept 页面（Standard-Change.md, Normal-Change.md, Emergency-Change.md, CAPA.md, Early-Live-Support.md）
  - 更新现有 Entity：SRE-Team.md（添加三阶段支持职责和 Topic 30 来源）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 30 摘要段落
  - 冲突检测：与 [[ctp-topic-53-why-bother-with-cloud]] 的观点张力——Topic 30 假设迁移决策已做出，聚焦执行层面变更管理；Topic 53 质疑迁移必要性。已记录于 Source Page Contradictions 节。

## [2026-04-25] ingest | CTP Topic 69 Best Practices for Migrating On-Premises (IOD) Virtual Machines to VMware Cloud on AWS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
- Status: ✅ 成功摄入
- Summary: VMC on AWS 虚拟机迁移最佳实践——HCX 多云管理（每次迭代最多 200 台 VM）、UI 和 CCOE 脚本两种迁移方案、Direct Connect + Virtual Transit Gateway 混合云连接、预/后迁移自动化、Brown to Manage 系统集成 SMACS + HCMX 实现后迁移管理。
- Concepts created: Direct Connect, Virtual Transit Gateway, BGP, EC2-Bare-Metal, CCOE, SMACS Suite, HCMX
- Source page: wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-69-best-practices-for-migrating-on-premises-iod-virtual-machines-to-vm.md）
  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - index.md 更新：替换预期占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 69 摘要段落（置于 ctp-topic-43 之后），补充 HCX 和迁移执行层面的详细信息
  - 冲突检测：与 [[ctp-topic-43-vmware-cloud-on-aws]] 互补而非冲突——Topic 43 提供 VMC on AWS 概述，Topic 69 提供迁移执行细节，已记录于 Source Page Contradictions 节

## [2026-04-24] ingest | Public Cloud Learning Sessions (OpenText) - Evolving from DR to Recovery Assurance - 20240723
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
- Status: ✅ 成功摄入
- Summary: OpenText DR 向 Recovery Assurance 演进框架——Jim Rose 主讲，涵盖 CrowdStrike 事件警示、RTO/RPO 合同差异、DR 测试瓶颈（被动/手动/按客户时间表）、多云复杂性（AWS/GCP/Azure）、混合架构挑战，以及 Design/Software/Build/Environments 四位框架转型路径。SRE + 可观测性工程是核心驱动力。
- Concepts identified: RTO, RPO, SRE, Observability-Engineering, Disaster-Recovery, Business-Continuity-Plan, Self-Healing, Customer-Zero-Environment
- Entities identified: OpenText, Jim-Rose, CrowdStrike
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-evolving-from-dr-to-recovery-assurance-2.md
- Notes:
  - 新增 1 个 Source Page
  - Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - index.md 更新：插入至 Sources 顶部，日期 2026-04-24
  - overview.md 更新：无需更新（已有 ctp-topic-72 覆盖 DR 核心内容，本视频内容已通过 Connections 节与相关 Topic 建立关联）
  - 冲突检测：无冲突——与现有 Wiki DR 内容互补，记录于 Source Page Contradictions 节

## [2026-04-25] ingest | CTP Topic 31 Network Segregation and Secure Access to the New AWS Landing Zones
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md
- Status: ✅ 成功摄入
- Summary: AWS Landing Zone 网络隔离与安全远程访问方案。核心：①网络隔离——Checkpoint 防火墙 SPI default-deny 阻断内部网络直连 AWS；②安全访问——AWS SSM 替代 VPN，IAM 角色假设 + SSM Agent 实现浏览器/CLI 远程访问。定位为 SD-WAN 实施前过渡方案；长期目标 IaC 化消除控制台访问。与 Topic 18 互补（打通 vs 限制）。
- Concepts created: (已存在: SD-WAN, AWS-Landing-Zone, Network-Segregation, AWS-Systems-Manager-SSM, SPI-Security-Policy-Infrastructure; 新增 wikilinks 于 source page)
- Entities created: (已存在: Checkpoint)
- Source page: wiki/sources/ctp-topic-31-network-segregation-and-secure-access-to-the-new-aws-landing-zones.md
- Notes:
  - 新增 1 个 Source Page
  - 冲突记录：与 [[ctp-topic-18-wide-area-networking-in-aws-cloud]] 的视角张力——Topic 18 关注打通网络，Topic 31 关注限制网络；已记录于 source page Contradictions 章节

## [2026-04-25] ingest | CTP Topic 18 Wide Area Networking in AWS Cloud
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-18-wide-area-networking-in-aws-cloud.md
- Status: ✅ 成功摄入
- Summary: AWS Transit Gateway 全球广域网架构与 SD-WAN 演进路径——Micro Focus IT 网络架构师 Christian Deckelman 主讲。核心架构：全球划分为 APJ/EMEA/AMS 三个地理区域，每个区域设立 Hub，Landing Zones 通过 TGW Peering 以星型拓扑接入 Hub，区域 Hub 之间全网状互联。现状依赖静态路由缺乏 BGP，DR 需人工干预。未来演进：引入 Silver Peak SD-WAN 实现动态路径选择，Pulse VPN 迁移至 Prisma Access (SASE) 实现就近接入。
- Concepts created: AWS-Transit-Gateway, Hub-and-Spoke, SD-WAN, Overlay-Network, Static-Routing, Prisma-Access, TGW-Peering
- Entities created: (已存在: Micro Focus, AWS, Christian Deckelman, Silver Peak, Palo Alto Networks)
- Source page: wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-18-wide-area-networking-in-aws-cloud.md）
  - 新增 7 个 Concept 页面
  - index.md 更新：Sources 节新增条目（日期 2026-04-14）
  - overview.md 更新：新增 Topic 18 的完整段落
  - 冲突检测：无已知冲突

- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md
- Status: ✅ 成功摄入
- Summary: VMware Cloud on AWS（VMC on AWS）混合云服务介绍——VMware与AWS联合开发，在AWS裸金属服务器（i3.metal/i3en.metal）上原生安装vSphere 8。工作负载可在数秒内往返迁移于本地与云端之间，通过HCX实现any-to-any vSphere迁移。相比常规云方案节省27%成本，云经济学团队可提供TCO计算。
- Concepts created: VMware-Cloud-on-AWS, HCX, SDDC, Stretched-Cluster, Hybrid-Cloud
- Entities created: VMware, AWS
- Source page: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md）
  - 新增 2 个 Entity 页面（VMware.md, AWS.md）
  - 新增 4 个 Concept 页面（VMware-Cloud-on-AWS.md, HCX.md, SDDC.md, Stretched-Cluster.md）
  - index.md 更新：Sources 节新增条目（日期 2026-04-25，置顶于所有条目最前）；Entities 节新增 VMware 和 AWS；Concepts 节新增 4 个概念
  - overview.md 更新：新增 Topic 43 的完整段落；Key Concepts 新增 VMware-Cloud-on-AWS、VMware、HCX、SDDC、Stretched-Cluster、Hybrid-Cloud
  - 冲突检测：与 ctp-topic-53-why-bother-with-cloud 存在是否应迁移至云端的观点张力，已在 source page 中记录为 Contradictions

## [2026-04-24] ingest | CTP Topic 61 Workload VPC provision with IPAM Automation
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
- Status: ✅ 成功摄入
- Summary:
- Concepts created: VPC-自动化供给, CIDR-审批流程, Availability-Zone-ID
- Source page: wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-61-workload-vpc-provision-with-ipam-automation.md）
  - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前）；移除原有的 source missing 条目
  - overview.md 更新：新增 Topic 45 和 Topic 61 的完整段落，描述 IPAM 的"机制 → 应用"完整链路；Key Concepts 新增 [[VPC-自动化供给]] 和 [[CIDR-审批流程]]
  - 冲突检测：无已知冲突内容
  - IPAM（IP Address Management）和 Infoblox Grid 概念已在 overview.md Key Concepts 中，无需单独 Concept 页面

## [2026-04-24] ingest | CTP Topic 45 Automatic IP address allocation with IPAM
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
- Status: ✅ 成功摄入
- Summary: 使用 Infoblox NIOS IPAM 实现 AWS VPC 自动化 IP 地址分配的架构实践。核心内容：①传统方式（手工请求→网络团队计算CIDR→电子表格→手工配置YAML）效率低下；②Infoblox NIOS 自动分配下一个可用 IP 地址块（≤/24 自动，>/24 需审批）；③新 YAML 配置仅声明期望子网大小和区域父 CIDR，不含硬编码 IP；④销毁 VPC 时自动从 IPAM Grid 清除条目，支持撤销保护；⑤向后兼容旧配置。目标：创建 VPC 无需网络团队参与，建立单一可信数据源。
- Concepts created: IPAM（IP Address Management），Infoblox-NIOS，VPC-自动化供给
- Source page: wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-45-automatic-ip-address-allocation-with-ipam.md）
  - index.md 更新：将原有的 source missing 条目替换为正式条目（日期 2026-04-24）
  - IPAM 关键概念在 source page 内已有详细说明，无需单独 Concept 页面
  - 冲突检测：无已知冲突内容

## [2026-04-24] ingest | CTP Topic 19 Configuring DNS within AWS LZs
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs.md
- Status: ✅ 成功摄入
- Summary: AWS Landing Zone 多账号环境中的集中化 DNS 配置架构——Sankar Gopov 主讲。核心内容：①设立专用 DNS 账号集中管理所有私有托管区（优于分散管理）；②Route 53 Resolver Inbound/Outbound Endpoints 打通混合 DNS（Inbound 接收本地请求，Outbound 转发 AWS 请求至本地）；③AWS RAM 跨账号共享 Resolver Rules；④跨账号 VPC 关联必须先授权（Authorization）再关联（Association）；⑤Terraform 自动化实现新账号上线即具备完整解析能力。
- Concepts created: Hybrid DNS Resolution, Route 53 Resolver Rules, VPC Association Authorization, Terraform DNS Automation
- Entities created: Sankar Gopov
- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md）
  - 新增 1 个 Entity 页面（wiki/entities/SankarGopov.md）
  - 新增 1 个 Concept 页面（wiki/concepts/HybridDnsResolution.md）
  - index.md 更新：Sources 节新增条目（日期 2026-04-24，置顶于所有条目最前）
  - overview.md 更新：更新 CTP Topic 22 段落，移除"（待摄入）"标注，补全两条 DNS 视频的知识体系关系描述
  - 冲突检测：与 [[ctp-topic-22-global-dns-service-offerings]] 存在潜在视角差异——DNS 账号是否应包含公共托管区；前者侧重落地配置，后者侧重服务提供架构；两者的冲突是视角互补而非逻辑矛盾

## [2026-04-26] ingest | CTP Topic 36 SendGrid as an Email Service
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-36-sendgrid-as-an-email-service.md
- Status: ✅ 成功摄入
- Summary: SendGrid 被选定为 CTP 标准邮件服务，替换 Port 25 不安全的语义消息网关和每封限制 50 收件人的 SES。SendGrid 支持每封最多 1,000 收件人、TLS 端到端加密、双因素认证；两种架构（直连 vs 中继）；配置要求 software.microcopy.com 域名、smtp.sendgrid.net:587、TLS；SPF/DKIM 必要；API 密钥 180 天轮换；日志 7 天保留。同期更新了 Cyber Suite 加密标准（FIPS/Java/Golang/Node.js/OpenCell 等），可选套件因含 CBC 弱加密仅作向后兼容。
- Concepts created: SPF, DKIM, TLS, API-Key-Rotation, Cyber-Suite, CBC-Mode
- Entities touched: SendGrid, Twilio, Rejoy Ganapati, Rajiv, Yu-Yan, PSAC
- Source page: wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-36-sendgrid-as-an-email-service.md）
  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于 CTP Topic 34 之后）
  - overview.md 更新：新增 CTP Topic 36 摘要段落（置于 ctp-topic-22 之后，ctp-topic-17 之前）；Key Concepts 列表新增 8 个概念（SPF/DKIM/TLS/API-Key-Rotation/Cyber-Suite/CBC-Mode/SendGrid/Twilio）
  - 冲突检测：与 [[ctp-topic-12-using-ses-smtp-service-terraform-module]] 存在冲突——SES 作为标准邮件服务 vs SendGrid 被选定为新标准；SES 适合 AWS 原生集成场景，SendGrid 为大规模需求首选


- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md
- Status: ✅ 成功摄入
- Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 主讲。核心架构：Route 53 Private Hosted Zone + AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络 DNS 查询；Outbound Endpoint 配置多区域 AD 域控制器 IP 实现故障自动切换；Infoblox Anycast 提供本地 DNS 全球低延迟和高可用；AWS EC2 不支持 Anycast；DNS 安全涵盖防隧道攻击、缓存污染等；就近解析优化 Office 365 访问
- Concepts touched: Hybrid DNS Resolution、Route 53 Private Hosted Zone、Route 53 Resolver、DNS Anycast、Infoblox Grid、IPAM（IP Address Management）、Active Directory DNS、Landing Zone
- Entities touched: AWS、Infoblox、Microsoft Active Directory、Office 365、Sankar、Vino
- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-22-global-dns-service-offerings.md）
  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 22 摘要段落（置于 ctp-topic-14 之后，ctp-topic-17 之前）；Key Concepts 列表新增 7 个 DNS 相关概念
  - 冲突检测：ctp-topic-19（configuring DNS within AWS LZs）尚未摄入，无法进行完整对比；source page Contradictions 节已记录，待 ctp-topic-19 摄入后补充对比

## [2026-04-26] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md
- Status: ✅ 成功摄入
- Summary: CCOE AMI 路线图详解——涵盖 CCOE AMI 路线图规划、操作系统 EOL 时间线（Windows Server 2008/2008 R2 已 EOL；CentOS 8 已 EOL；Windows Server 2012 将于 2023 年 10 月 EOL；RHEL 7 和 CentOS 7 将于 2024 年 6 月 EOL）、AMI 通知机制、变更日志（CCRE 门户）、新 AMI 添加流程、当前支持的 AMI 清单及未来路线图。自 2023 年 5 月起所有 ARM AMI 同步发布。路线图优先级主要由 ADM 需求驱动，变更需通过需求管道流程提交。AMI 通过跨账号共享分发给组织内所有账户。
- Concepts touched: Foundation AMI、OS-End-of-Life、AMI Sharing、ARM-AMI、CCOE、ADM、SSM Agent
- Entities touched: CCOE、AWS、Ubuntu、CentOS、Rocky Linux、Red Hat Enterprise Linux、SLES、Windows Server、McAfee
- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md）
  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - index.md 更新：Sources 节替换预期占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 50 摘要段落（置于 learning-sessions-standard-amis-updates 之后，ctp-topic-26 之前）
  - 冲突检测：与 [[learning-sessions-standard-amis-updates]] 的 EOL 时间线一致（CentOS 7/RHEL 7 将于 2024 年 6 月 EOL）；与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 存在描述角度差异（本话题聚焦路线图规划，Topic 26 聚焦生命周期管理），非矛盾而是互补关系，已记录于 Source Page Contradictions 节

## [2026-04-24] ingest | CTP Topic 40 SaaS Database Architecture On AWS Cloud
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-40-saas-database-architecture-on-aws-cloud.md
- Status: ✅ 成功摄入
- Summary: SAS 数据库团队在 AWS 云上的架构与运维实践——全球分布式团队（美国/加拿大/印度/以色列）提供 24/7 支持，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移
- Concepts created: 无新增（高可用/Oracle Data Guard/Multi-AZ Deployment/Database Migration/DB-as-a-Service 各仅出现 1-2 次，不满足 ≥2 次建页条件，跳过独立建页）
- Entities created: 无新增（AWS/RDS/Aurora/Terraform/Micro Focus 各仅出现 1-2 次，不满足 ≥2 次条件，跳过独立建页）
- Source page: wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-40-saas-database-architecture-on-aws-cloud.md）
  - 所有 Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值）
  - index.md 更新：Sources 节新增条目（置顶）
  - overview.md 更新：新增 CTP Topic 40 摘要段落（置于 ctp-topic-10 之后，ctp-topic-46 之前）；Key Concepts 列表新增 Database Migration
  - 冲突检测：无明显冲突内容

## [2026-04-26] ingest | CTP Topic 26 Standard AMI – build, publish, share processes
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-26-standard-ami-build-publish-share-processes.md
- Status: ✅ 成功摄入
- Summary: Foundation AMI 全生命周期管理详解——基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS 安全基准加固；集成 McAfee EPO + Syslog-ng + AD SSO + SSM Agent + SiteScope；HashiCorp Packer + Jenkins 流水线实现全自动化；跨账号 AMI Sharing 分发至全球多区域（俄勒冈/法兰克福/悉尼）；每两个月更新，N-2 版本保留策略；责任共担模型（CCOE 提供 Foundation AMI，产品团队构建产品特定 AMI）
- Concepts created: 无新增（Foundation AMI/OS Hardening/CIS Benchmarks/HashiCorp Packer/SSM Agent/AMI Sharing/Central Repository 各仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页）
- Entities created: 无新增（Srihari/Alan/Praveen 各仅出现 1 次，不满足 ≥2 次条件；CCOE 仅出现 1 次）
- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md）
  - 7 个 Concept 均以 wikilink 形式建立关联，暂不创建独立页面（未达 ≥2 次阈值）
  - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 26 摘要段落（置于 learning-sessions-standard-amis-updates 之后，替换原 ctp-topic-58 段落位置）；Key Concepts 列表新增 Foundation AMI / OS Hardening / CIS Benchmarks / AMI Sharing / Central Repository
  - 冲突检测：与 [[ctp-topic-58-aws-ec2-image-builder]] 描述不同 AMI 生命周期阶段——ctp-topic-26 描述当前 Packer+Jenkins 生产实践，ctp-topic-58 描述 EC2 Image Builder 未来演进方向，非冲突而是演进关系，已记录于 Source Page Contradictions 节

## [2026-04-23] ingest | CTP Topic 68 Introduction to Redshift
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-68-introduction-to-redshift.md
- Status: ✅ 成功摄入
- Summary: AWS Redshift 数据仓库入门——核心架构（Leader Node + Compute Node + Slices）、MPP 并行处理、列式存储 vs 行式存储、数据压缩（ZSTD/LZO）、Sort Key / Distribution Key 优化、RA3 实例类型（AWS 托管 NVMe）
- Concepts created: [[MPP]], [[Columnar-Storage]]
- Entities created: [[Amazon-Redshift]]
- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-68-introduction-to-redshift.md）
  - 新增 1 个 Entity Page（wiki/entities/Amazon-Redshift.md）
  - 新增 2 个 Concept Page（wiki/concepts/MPP.md、wiki/concepts/Columnar-Storage.md）
  - index.md 更新：Sources 节移除预期占位符（"source missing"）替换为正式条目；Entities 节新增 Amazon-Redshift；Concepts 节新增 MPP、Columnar-Storage
  - overview.md 更新：新增 CTP Topic 68 摘要段落（置于 ctp-topic-51 之后）；Key Concepts 列表新增 Data-Warehouse、MPP、Columnar-Storage、Sort-Key、Distribution-Key
  - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 存在架构差异（Redshift 独立 Compute Node vs Aurora 共享存储），记录于 Source Page 的 Contradictions 节
  - Sort Key 和 Distribution Key 概念因在其他页面中暂未出现，本次不创建独立页面

## [2026-04-14] ingest | CTP Topic 58 AWS EC2 Image Builder
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-58-aws-ec2-image-builder.md
- Status: ✅ 成功摄入
- Summary: AWS EC2 Image Builder 替代 Packer/Jenkins 实现企业级 AMI 生命周期自动化——通过 Pipeline/Recipe/Component/Infrastructure Config 四层抽象，将 CCOE 加固脚本转换为可复用组件；POC 实现 CentOS 7 和 Ubuntu 18 端到端流水线；Lambda 工作流触发 AWS Inspector 扫描、邮件通知和 S3 报告归档
- Concepts identified: [[Golden-AMI]], [[CCOE]], [[Image-Pipeline]], [[Image-Recipe]], [[Image-Component]], [[Infrastructure-Configuration]], [[Distribution-Settings]], [[AWS-Inspector]]
- Entities identified: [[AWS]]（仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页）
- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 8 个 Concept，均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面
  - AWS Entity 页面已存在于 wiki/entities/（Amazon-RDS.md 等系列页面），本次复用
  - index.md 更新：Sources 节替换预期条目占位符为正式条目（日期修正为 2026-04-14）
  - overview.md 更新：新增 CTP Topic 58 摘要段落（置于 learning-sessions-standard-amis-updates 之后）
  - 冲突检测：与 [[ctp-topic-26-standard-ami-build-publish-share-processes]] 描述不同 AMI 生命周期阶段，非冲突，记录于 Source Page 的 Contradictions 节

## [2023-12-05] ingest | Learning Sessions: Standard AMI Updates 20231205
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md
- Status: ✅ 成功摄入
- Summary: AWS 标准 AMI 更新机制与生命周期管理——标准 AMI 基于 AWS 原生镜像增加 OS 加固、安全补丁、SSM Agent、QALIS Agent；Jenkins 多分支流水线构建测试 AMI，将验证周期从 3-4 天缩短至 60 分钟；支持 23 种 AMI 涵盖 Amazon Linux/CentOS/OEL/RHEL/Rocky Linux/SUSE/Ubuntu/Windows；机器人框架自动化验证为核心优化手段；CentOS 7/RHEL 7 将于 2024 年 6 月 EOL，由 Rocky Linux 替代；SSM 打补丁方案适用于长期运行实例。
- Concepts identified: [[Amazon-Machine-Image]], [[Jenkins-Multi-Branch-Pipeline]], [[AWS-Inspector]], [[Robotic-Framework]], [[SSM-Patching]], [[GP3-EBS-Storage]], [[OS-End-of-Life]]
- Entities identified: [[Rocky-Linux]], [[Sentinel-1]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页）
- Source page: wiki/sources/learning-sessions-standard-amis-updates-20231205-160324-meeting-recording-2.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 overview.md 条目，置于 CTP Topic 7 之前（按日期 2023-12-05 排序）
  - 7 个 Concept 均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立 Concept 页面
  - 无内容冲突

## [2026-04-23] ingest | CTP Topic 7 SaaS Landing Zone Design
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-7-saas-landing-zone-design.md
- Status: ✅ 成功摄入
- Summary: SAS（生产）Landing Zone 顶层设计——采用单一 Landing Zone 承载所有产品组；定义四层账户体系（Core Accounts: Shared/Logs/Security；Baseline Accounts: Network/DNS/AD；Shared Services Accounts: Software Factory/Cyber/ARC/Monitoring；Product Accounts）；Terraform IaC + GitHub/Jenkins CI/CD 端到端自动化部署链路（GitHub Hook → Jenkins → Management VPC → Lambda → ECS Cluster）；工作负载置于私有子网，WAF + CloudFront 提供入站安全；远程接入从 Checkpoint VPN 迁移至 Pulse VPN（AD 认证）。
- Concepts identified: [[Landing-Zone-Architecture]], [[Active-Directory-Integration]], [[Transit-Gateway]], [[WAF-Web-Application-Firewall]], [[Private-Subnet-Architecture]], [[Terraform-IaC]]
- Entities identified: [[Gruntwork]], [[Jenkins]], [[Checkpoint]], [[CloudFront]], [[Qalis]], [[OBM]]（均仅出现 1 次，不满足 ≥2 次建页条件，跳过独立建页）
- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 6 个 Concept（Landing-Zone-Architecture/Active-Directory-Integration/Transit-Gateway/WAF-Web-Application-Firewall/Private-Subnet-Architecture/Terraform-IaC），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面
  - 新增 6 个 Entity（Gruntwork/Jenkins/Checkpoint/CloudFront/Qalis/OBM），均仅出现 1 次，不满足 ≥2 次条件，跳过独立建页
  - Gruntwork、Checkpoint Entity 页面已存在于 wiki/entities/，本次复用
  - Landing-Zone-Architecture Concept 页面已存在于 wiki/concepts/，本次复用
  - index.md 更新：Sources 节替换预期条目占位符为正式条目
  - overview.md 更新：新增 CTP Topic 7 摘要段落（置于 ctp-topic-1 之前）
  - 冲突检测：与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 存在时间维度的架构演进关系（非冲突）——ctp-topic-7 定义原始设计，ctp-topic-35 补充近期变更（网络分段、Pulse VPN 替换 Checkpoint VPN），记录于 Source Page 的 Contradictions 节

## [2026-04-14] ingest | CTP Topic 34 Azure Landing Zone Architecture Overview
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-34-azure-landing-zone-architecture-overview.md
- Status: ✅ 成功摄入
- Summary: Kishore Garlopati 讲解 Azure Landing Zone 在 Micro Focus 的实施架构。核心：Azure Enterprise Enrollment → 管理组（Management Groups）四层分级（Platform/Landing Zones/Decommission/Sandbox）→ 独立订阅隔离目的 → Terraform Cloud IaC 自动化。Platform 层含 Identity 和 Connectivity 两个独立订阅；Connectivity 订阅作为中心枢纽汇聚所有入站/出站 Azure 流量（含 DDoS 防护和 Checkpoint 防火墙）；Landing Zones 设计为可扩展、模块化、全自动化；Terraform Cloud 管理跨订阅依赖；PIM/PAG 实现精细化访问控制。
- Concepts identified: [[Azure Landing Zone]], [[Management Groups]], [[Terraform Cloud]], [[Privileged Identity Management (PIM)]], [[Privileged Access Groups]]
- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 5 个 Concept（Azure Landing Zone / Management Groups / Terraform Cloud / Privileged Identity Management (PIM) / Privileged Access Groups），均仅出现 1 次，不满足 ≥2 次建页条件，本次不创建独立页面
  - 新增 1 个 Entity（Kishore Garlopati），仅出现 1 次，不满足 ≥2 次条件，本次不创建独立页面
  - index.md 更新：Sources 节替换预期条目占位符为正式条目
  - overview.md 更新：Cloud Transformation & DevOps 节新增 Azure Landing Zone 概念标注
  - 无冲突检测到
  - 本文档原状态为"🟡 Awaiting Whisper transcription → Summary"，现已摄入完成

## [2026-04-23] ingest | CTP Topic 35 AWS Landing Zone Design Refresher (SaaS Labs)
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md
- Status: ✅ 成功摄入
- Summary: AWS Landing Zone 设计复习，明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS LZ 为每个产品区域提供客户专属产品账户，连接共享服务账户（安全、日志、网络）；核心账户组含 AD、DNS、Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断 SaaS 工作负载直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail；入站流量通过 Network 账户 Checkpoint 重新路由；AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：SaaS = 生产，Labs = 开发；PoC LZ 并入 Labs。
- Concepts created: [[AWS-Landing-Zone]], [[Gruntwork]], [[Shared-Services-Account]], [[Core-Accounts]], [[Product-Accounts]], [[Gruntwork-Accounts]], [[CCOEs-CloudTrail]], [[Network-Segmentation]]
- Source page: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 8 个 Concept（AWS-Landing-Zone/Gruntwork/Shared-Services-Account/Core-Accounts/Product-Accounts/Gruntwork-Accounts/CCOEs-CloudTrail/Network-Segmentation）
  - 新增 1 个 Entity（Cloud-Technology-Design-Forum，仅在本文档提及，不满足 ≥2 次条件，跳过独立建页）
  - overview.md 更新：新增 CTP Topic 35 摘要段落（置于 ctp-topic-1 之前）
  - index.md 更新：Sources 节替换预期条目占位符为正式条目
  - 无冲突检测到

## [2026-04-14] ingest | CTP Topic 47 Enterprise Architecture Cloud Standards
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-47-enterprise-architecture-cloud-standards.md
- Status: ✅ 成功摄入
- Summary: Lindsay 分享企业架构云标准。核心：Landing Zone 框架聚焦安全、合规和可管理性；账户结构与环境和角色对齐，零信任+最小权限原则；Terraform/Terragrunt 实现 IaC 标准化；云防护栏文档捕获强制性要求和最佳实践；功能分区将单体应用拆分为更小的独立模块或无服务器函数；强调需要应用团队输入完善防护栏。
- Concepts created: [[Landing Zone]], [[Cloud Guardrails]], [[Functional Partitioning]]
- Source page: wiki/sources/ctp-topic-47-enterprise-architecture-cloud-standards.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 3 个 Concept（Landing Zone / Cloud Guardrails / Functional Partitioning）
  - overview.md 更新：新增 CTP Topic 47 摘要段落（置于 ctp-topic-17 之后）
  - 无 Entity 创建（Lindsay 仅出现 1 次，不满足 ≥2 次条件）
  - 无冲突检测到

## [2026-04-14] ingest | CTP Topic 72 Implementing an Enterprise DR Strategy Using AWS Backup
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md
- Status: ✅ 成功摄入
- Summary: AWS 解决方案架构师 Sabith 深入讲解企业级灾难恢复策略与 AWS Backup 架构设计。核心：HA（高可用）关注运行时间和 MTBF，DR（灾难恢复）专注防止数据丢失；RPO/RTO 定义恢复目标；AWS Backup 集中化、基于策略，支持跨账户跨区域复制；四级 DR 架构模式（Backup and Restore → Pilot Light → Warm Standby → Active-Active）；增量备份节省成本；Vault Lock 合规模式防勒索软件；Bunker Account + Forensic Account 增强隔离性和测试验证。
- Concepts created: [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[跨账户备份]], [[增量备份]], [[全量备份]], [[AWS Backup Audit Manager]]
- Source page: wiki/sources/ctp-topic-72-implementing-an-enterprise-dr-strategy-using-aws-backup.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 7 个 Concept（高可用/灾难恢复架构模式/Vault Lock/跨账户备份/增量备份/全量备份/AWS Backup Audit Manager）
  - overview.md 更新：新增 CTP Topic 72 摘要段落（置于 ctp-topic-17 之后），Key Concepts 节新增 7 个概念标注
  - index.md 更新：Sources 节新增条目（置顶于 ctp-topic-28 之前），并删除预期条目占位符
  - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 互补而非冲突，Topic 72 提供理论框架，Topic 44 提供内部评估视角，构成完整 AWS Backup 知识体系
  - 与 [[ctp-topic-44-aws-backup-in-micro-focus]] 和 [[ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program]] 三者构成递进关系（理论基础 → 内部评估 → 迁移实施）

## [2026-04-23] ingest | CTP Topic 51 Architecting with AWS Purpose-Built Databases
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-51-architecting-with-aws-purpose-built-databases.md
- Status: ✅ 成功摄入
- Summary: AWS 数据库专家 Femi George 分享专用数据库选型与架构原则。核心：现代应用"为正确的工作选择正确的专用数据库"，避免一刀切。AWS 提供完整数据库品类（关系型/NoSQL/键值/文档/宽列/内存/图/时序）。实战案例：Duolingo 用 DynamoDB + ElastiCache + Aurora；Netflix 用 DynamoDB 做高弹性 JSON；Peloton 用 ElastiCache Redis 即时反馈。云时代 DBA 从平台管理转向应用创新。
- Entities created: Amazon-DynamoDB, Amazon-DocumentDB, Amazon-ElastiCache, Amazon-Keyspaces, Amazon-Neptune, Amazon-Timestream
- Concepts created: Purpose-Built-Databases, DBA-Role-Evolution, Multi-Database-Architecture
- Source page: wiki/sources/ctp-topic-51-architecting-with-aws-purpose-built-databases.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 6 个 Entity（Amazon-DynamoDB/ElastiCache/Neptune/Timestream/Keyspaces/DocumentDB）
  - 新增 3 个 Concept（Purpose-Built-Databases / DBA-Role-Evolution / Multi-Database-Architecture）
  - overview.md 更新：新增 CTP Topic 51 摘要段落，置于 ctp-topic-66 之前
  - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 6 个实体，Concepts 节新增 3 个概念
  - 冲突检测：与 [[ctp-topic-66-rds-vs-aurora]] 视角互补而非冲突，已记录于 Source Page Contradictions 节

## [2026-04-23] ingest | CTP Topic 46 NetApps on AWS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws.md
- Status: ✅ 成功摄入
- Summary: Sandeep 和 Yael 主讲的 NetApp 存储系统培训。覆盖传统 NetApp 架构（ONTAP / Aggregate / FlexVol / Qtree / LUN / LIF / SVM）和 AWS 云版本 CVO。CVO 通过 EC2 实例提供软件定义存储，支持单节点或 HA 配对（跨多 AZ 同步复制）；数据分层机制将 30 天非活跃数据从 EBS 自动迁移到 S3；SnapMirror 实现块级跨集群复制；迁移工具包括 SnapMirror、NetApp XCP、Cloud Sync、AWS DataSync。组织已在 15 个 AWS 区域部署约 1.3 PB 数据。
- Concepts created: [[SnapMirror]]
- Entities created: [[NetApp]]
- Source page: wiki/sources/ctp-topic-46-netapps-on-aws.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 1 个 Entity（NetApp）
  - 新增 1 个 Concept（SnapMirror）
  - overview.md 更新：新增 CTP Topic 46 摘要段落，置于 ctp-topic-66 之前
  - index.md 更新：Sources 节新增条目（置顶于 Blogwatcher 前），Entities 节新增 NetApp，Concepts 节新增 SnapMirror
  - 冲突检测：暂无检测到与其他 Wiki 页面的冲突（NetApp 存储与 RDS/Aurora 属不同技术域，互补关系）

## [2026-04-14] ingest | CTP Topic 17 Active Directory Services in Gruntwork AWS LZs
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md
- Status: ✅ 成功摄入
- Summary: Paul 讲解 Gruntwork AWS Landing Zones 中的 AD 服务集成。核心内容：双域名策略（`swinford.net` 用于 R&D Labs，`intsas.local` 用于生产/SAS 环境）；SRE 预制 AMI 内置 PowerShell（Windows）/Shell（Linux）域加入脚本，通过 Terraform `user_data` 触发自动域加入；旧域名 `infra` 和 `AST` 已废弃，提供迁移路径；Linux 支持安全动态更新（Secure Dynamic Updates）自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。
- Concepts created: [[Swinford.net]]（作为 AD 域名概念）、[[Intsas.local]]（作为 AD 域名概念）、[[SMACKS]]（作为工单系统概念）
- Entities created: [[Gruntwork]]（Company/Project类实体）、[[SMACKS]]（Project类实体）
- Source page: wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 1 个 Entity（Gruntwork）
  - 新增 2 个 AD 域名概念实体（Swinford.net、Intsas.local）
  - 新增 1 个工单系统实体（SMACKS）
  - overview.md 更新：新增 CTP Topic 17 摘要段落
  - 冲突检测：暂无检测到与其他 Wiki 页面的冲突

## [2026-04-24] ingest | CTP Topic 66 Exposing the differences between PostgreSQL RDS and Aurora
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md
- Status: ✅ 成功摄入
- Summary: Greg Klau 深度对比 PostgreSQL RDS 与 Aurora。核心维度：①最小规格/成本（RDS 更低）；②最大容量/IO性能（Aurora 更优，>10-20TB首选）；③RTO（Aurora 30秒 vs RDS 2分钟）；④存储灵活性（RDS GP2/GP3/预置IOPS/磁性，Aurora按IO收费）；⑤架构（RDS：EC2+EBS分离，Multi-AZ备用；Aurora：6副本跨3AZ共享集群卷）；⑥Blue-Green部署（仅Aurora MySQL支持）；⑦端点设计（Aurora独立Writer/Reader Endpoint）。高可用调优：DNS TTL=1秒、TCP Keep-Alive、JDBC reader/writer端点路由。
- Concepts created: [[RTO]]
- Entities created: [[Amazon-Aurora]]（Product类实体）、[[Amazon-RDS]]（Product类实体）
- Source page: wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 1 个 Concept（RTO，灾备核心指标）
  - 新增 2 个 Entity（Amazon-Aurora、Amazon-RDS）
  - 冲突检测：与 learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform 存在视角差异——Terraform IaC 部署关注资源标准化，存储选型属运维决策层面，已记录于 Contradictions
  - overview.md 更新：新增 CTP Topic 66 摘要段落，更新 Key Entities 和 Key Concepts

## [2026-04-23] ingest | CTP Topic 14 Octane Hub on AWS Real Life Experience
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md
- Status: ✅ 成功摄入
- Summary: Octane Hub CTO Holger Rode 分享将生产服务从 Bibling Lab 数据中心迁移到 AWS Landing Zone 的实战经验。涵盖 Docker 容器化工作负载（QuickSee、Release Manager、Patch Manager 等）、Packer+Terraform/TerraGrunt IaC 演进、EFS vs EBS 存储选型（EFS 不适合数据库，需用 EBS）、VPC Transit Gateway 网络互联、Route 53 DNS 设置。下一步：DR 改进、MSSQL→Postgres 迁移、ECS 演进。
- Concepts created: [[Docker-Containerization]]、[[EFS-vs-EBS]]
- Entities created: [[Octane-Hub]]
- Source page: wiki/sources/ctp-topic-14-octane-hub-on-aws-real-life-experience-moving-production-services-i.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 2 个 Concept（Docker-Containerization、EFS-vs-EBS）
  - 新增 1 个 Entity（Octane-Hub）
  - 冲突检测：与 ctp-topic-7（SaaS Landing Zone 设计）存在视角差异——前者侧重多租户架构，后者侧重单体团队实际迁移路径，已记录于 Contradictions

## [2026-04-24] ingest | CTP Topic 44 AWS Backup in Micro Focus
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-44-aws-backup-in-micro-focus.md
- Status: ✅ 成功摄入
- Summary: AWS Backup 托管服务详解，vs Micro Focus 当前分散式快照管理。涵盖四级 DR 策略（Backup and Restore / Pilot Light / Warm Standby / Active-Active），不可变性防勒索软件，法律保留合规，AWS Backup 功能演示（备份保管库、备份计划、时间点恢复），以及当前流程的五大差距。
- Concepts created: 无（AWS Backup / RTO / RPO / Disaster Recovery / Pilot Light / Warm Standby / Active-Active / Legal Holds 已在 overview Key concepts 中覆盖）
- Entities created: 无（CCIE 门户仅出现1次，不满足创建条件）
- Source page: wiki/sources/ctp-topic-44-aws-backup-in-micro-focus.md
- Notes:
  - 新增 1 个 Source Page
  - 无新增 Entity/Concept
  - 无冲突内容，与 ctp-topic-72、ctp-topic-73 构成递进关系

## [2026-04-24] ingest | 实战笔记：本地部署 RSSHub 并获取 YouTube 订阅
- Source file: Home Office/实战笔记：本地部署 RSSHub 并获取 YouTube 订阅.md
- Status: ✅ 成功摄入
- Summary: 本地 Docker 部署 RSSHub（diygod/rsshub，端口1200），通过浏览器 view-source 方式获取 YouTube 频道 ID，使用 `/youtube/channel/{channel_id}` 路由生成稳定 RSS 订阅源。相比第三方在线服务，本地部署更稳定可靠。
- Concepts created: 无（RSSHub 已在 overview Key concepts 中）
- Entities created: 无（diygod 仅出现1次，不满足创建条件）
- Source page: wiki/sources/实战笔记-本地部署-rsshub-并获取-youtube-订阅.md
- Notes:
  - 新增 1 个 Source Page
  - 无新增 Entity/Concept
  - 冲突检测：与 "How to Get the RSS Feed For Any YouTube Channel" 的在线 vs 本地方案略有差异，已记录于 Contradictions

## [2026-04-24] ingest | Mac必装软件清单
- Source file: Home Office/Mac必装软件清单-2026-04-17.md
- Status: ✅ 成功摄入
- Summary: 精选8款Mac必备软件——Claude（AI助手）、Obsidian（AI知识库）、Chrome（浏览器）、Rectangle（分屏工具）、iShot（截图录屏）、Lemon（系统清理）、Raycast（启动器）、Homebrew（包管理器）。核心理念：用最少的软件达到最高的效率。Homebrew 是用 Claude Code 搭 Agent 的前置依赖。
- Concepts created: 无
- Entities created: 无
- Source page: wiki/sources/mac必装软件清单-2026-04-17.md
- Notes:
  - 新增 1 个 Source Page
  - 无新增 Entity/Concept（软件均不满足创建条件）
  - 冲突检测：无冲突

## [2026-04-18] ingest | fireworks-tech-graph
- Source file: raw/Skills/fireworks-tech-graph.md
- Status: ✅ 成功摄入
- Summary: fireworks-tech-graph Claude Code Skill，将自然语言描述转化为精美 SVG 技术图，支持 7 种视觉风格和 14 种 UML 图类型，通过 rsvg-convert 导出 1920px PNG。内置语义形状词汇表和语义箭头系统，确保图形语义一致性。安装：npx skills add yizhiyanhua-ai/fireworks-tech-graph，依赖 librsvg。
- Concepts created: 7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成
- Entities created: fireworks-tech-graph、rsvg-convert
- Source page: wiki/sources/fireworks-tech-graph.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 5 个 Concept Page（7种视觉风格系统、14种UML图、语义形状词汇表、语义箭头系统、技术图生成）
  - 新增 2 个 Entity Page（fireworks-tech-graph、rsvg-convert）
  - 更新 wiki/index.md（Sources + Entities + Concepts 章节追加条目）
  - 更新 wiki/overview.md（AI Tools & Prompt Engineering 章节追加条目）
  - 无内容冲突

## [2026-04-18] ingest | Install WSL
- Source file: raw/Home Office/Install WSL.md
- Status: ✅ 成功摄入
- Summary: 微软官方 WSL 完整安装指南，`wsl --install` 一键安装，支持 Ubuntu/Debian/SUSE/Kali 等多发行版并行安装，`wsl.exe --set-default-version` 切换 WSL1/WSL2；离线场景通过 MSI + DISM 命令手动启用 Virtual Machine Platform；运行入口推荐 Windows Terminal。与 [[WSL2 启动与网络配置指南]] 互补——前者解决安装，后者解决网络。
- Concepts created: 无新增（WSL2 已存在于 overview.md，WSL1/WSL安装命令/多发行版支持/离线安装 为 WSL 特定术语，无需独立页面）
- Entities created: 无新增（Microsoft/Ubuntu/PowerShell/Windows Terminal 已存在于 overview.md）
- Source page: wiki/sources/install-wsl.md
- Notes:
  - 新增 1 个 Source Page（install-wsl.md）
  - 更新 wiki/index.md（Sources 章节追加条目）
  - 更新 wiki/overview.md（新增 Install WSL 段落于 Home Server Automation 章节）
  - 冲突记录：[[WSL2 启动与网络配置指南]] vs [[Install WSL]] — 侧重点差异，均为互补关系，非矛盾

## [2026-04-23] ingest | Obsidian 官方 CLI 命令全景速查表
- Source file: raw/Skills/Obsidian 官方 CLI 命令全景速查表.md
- Status: ✅ 成功摄入
- Summary: Obsidian v1.12+ 内置官方 CLI 命令行工具的完整速查表，包含 80+ 条命令覆盖 16 个功能模块（基础操作/数据库/书签/命令面板/日记/文件历史/文件目录/链接网络/大纲/插件管理/属性元数据/发布/随机笔记/全局搜索/官方同步/标签/任务管理/模板/外观样式/卡片盒/仓库管理/内置浏览器/字数统计/工作区布局/开发者模式）。文档还包含 7 个典型自动化应用场景工作流（全局极速闪记、播客知识榨取、AI 收件箱自动分拣、绝对隐私本地 RAG 对话助理、跨平台数据库级联录入、历史知识自动唤醒、批量元数据重构清洗）。
- Concepts created: 无新增（Obsidian CLI / Obsidian Bases / Zettelkasten / 本地 RAG / 工作流自动化 / 元数据管理 / 快速闪记 均已存在于 overview.md）
- Entities created: 无新增（Obsidian / Obsidian CLI / Dataview / QuickAdd / Templater 已存在于 overview.md 或前次摄入）
- Source page: wiki/sources/obsidian-官方-cli-命令全景速查表.md
- Notes:
  - 新增 1 个 Source Page
  - 更新 wiki/index.md（Sources 章节追加条目）
  - 无内容冲突（与 obsidian-必装-skills 和 obsidian-cli 形成互补）

## [2026-04-23] ingest | Obsidian 必装 Skills
- Source file: raw/Skills/Obsidian 必装 Skills.md
- Status: ✅ 成功摄入
- Summary: Obsidian 与 AI Agent 集成的必装 Skills 全景图。覆盖五大方向：①kepano 官方 Skills（defuddle 网页清洗、obsidian-cli 官方 CLI、obsidian-bases .base 数据库）；②Axton 可视化 Skills（obsidian-canvas-creator 径向布局算法、mermaid-visualizer、excalidraw-diagram）；③学术研究工具链（tutor-skills 输入-内化-检测学习闭环、scholar-skill L1/L2/L3 分级论文阅读）；④第三方插件（Claudian 适配 Claude Code、obsidian-agent-client 支持多 Agent）；⑤不推荐工具（obsidian-skill 过时、json-canvas 自动化程度低）。
- Concepts created: Defuddle, Obsidian-CLI, Obsidian-Bases, Canvas, StudyVault, Scholar-Skill, Tutor-Skills, Claudian, Obsidian-Agent-Client
- Entities created: kepano, Axton, YishenTu, RAIT-09, Choi-Wontak, EESJGong
- Source page: wiki/sources/obsidian-必装-skills.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 9 个 Concept 页面（Defuddle / Obsidian-CLI / Obsidian-Bases / Canvas / StudyVault / Scholar-Skill / Tutor-Skills / Claudian / Obsidian-Agent-Client）
  - 新增 6 个 Entity 页面（kepano / Axton / YishenTu / RAIT-09 / Choi-Wontak / EESJGong）
  - 更新 wiki/index.md（Sources / Entities / Concepts 三个章节均已追加条目）
  - 更新 wiki/overview.md，补充 Obsidian Skills 生态段落
  - 无内容冲突（与已有 Obsidian 相关文档形成互补）

- Source file: raw/AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B
- Status: ✅ 成功摄入
- Summary: Ubuntu 系统上通过官方 install.sh 脚本一键部署 Ollama + Qwen2.5-Coder 7B。涵盖系统要求、安装步骤、服务管理、API 暴露（OLLAMA_HOST=0.0.0.0）、GPU 加速（CUDA 自动检测）、Python/Node.js SDK 调用，以及与 Open WebUI/n8n/OpenClaw 的集成方案。推荐搭配工具：Open WebUI（ChatGPT UI）、n8n（AI 自动化）、LangChain（Agent framework）、OpenClaw（AI coding agent）。qwen2.5-coder:7b 比通用版 qwen2.5:7b 更适合工程任务，因其 Tool usage 能力强、Shell/Python/SQL 理解强、Repo 级代码理解强。
- Concepts created: 无新增（[[Ollama]]/[[本地大模型部署]]/[[GPU 加速推理]]/[[REST API]] 已存在于 overview.md）
- Entities created: 无新增（[[Open WebUI]]/[[n8n]]/[[OpenClaw]] 已存在于 overview.md）
- Source page: wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md
- Notes:
  - 新增 1 个 Source Page
  - 更新 wiki/index.md Sources 节，追加新条目（按日期排序）
  - 更新 wiki/overview.md AI Tools 区域，追加 Qwen2.5-Coder 部署实战段落，关联 [[Ollama 本地 LLM 部署]]（DeepSeek-R1）形成 Ollama 部署双场景覆盖
  - 无需新建 Entity/Concept 页面（相关实体和概念已在 overview.md 中定义）
  - 检测冲突：无

## [2026-04-16] ingest | Learn AI for free directly from top companies
- Source file: raw/AI/Learn AI for free directly from top companies
- Status: ✅ 成功摄入
- Summary: @RodmanAi 汇总的 10 家顶级科技公司免费 AI 学习资源直链。涵盖：Anthropic（Skilljar）、Google（Grow.google/AI）、Meta（AI 资源中心）、NVIDIA（CUDA 开发者课程）、Microsoft（Microsoft Learn）、OpenAI（Academy）、IBM（SkillsBuild）、AWS（Skill Builder）、DeepLearning.AI（吴恩达课程）、Hugging Face（学习路径）。
- Concepts created: 无新增
- Entities created: [[DeepLearning.AI]], [[IBM]]
- Source page: wiki/sources/learn-ai-for-free-directly-from-top-companies.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/learn-ai-for-free-directly-from-top-companies.md）
  - 新增 2 个 Entity 页面：wiki/entities/DeepLearningAI.md, wiki/entities/IBM.md
  - 更新 wiki/overview.md Educational Resources 区域，追加免费 AI 学习资源全景介绍

## [2026-04-23] ingest | I Went Through Every AI Memory Tool I Could Find. There Are Two Camps.
- Source file: raw/Agent/AI-Memory-Tools-Two-Camps.md
- Status: ✅ 成功摄入
- Summary: AI 记忆工具全景分类框架。揭示两个根本不同的技术路线：Camp 1（Memory Backend，向量提取+检索，优化召回）vs Camp 2（Context Substrate，文件累积+背景整合，优化复合增长）。代表工具：Mem0、MemPalace（Camp 1）；OpenClaw、Zep、Thoth、TrustGraph（Camp 2）。核心洞察：Zep 从"memory"重塑为"context engineering"是最强市场信号；预测 6 个月内"context engineering"将取代"memory"成为主流术语；持续运行 Agent 必须采用 Context Substrate 架构。
- Concepts created: [[Context Substrate]], [[Memory Backend]]
- Entities created: [[OpenClaw]], [[Mem0]]
- Source page: wiki/sources/ai-memory-tools-two-camps.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ai-memory-tools-two-camps.md）
  - 新增 2 个 Concept 页面：wiki/concepts/Context-Substrate.md, wiki/concepts/Memory-Backend.md
  - 新增 2 个 Entity 页面：wiki/entities/OpenClaw.md, wiki/entities/Mem0.md
  - overview.md 新增 ai-memory-tools-two-camps 摘要条目，置于 semantic-memory-search 之后
  - index.md Sources 节新增条目（置顶）
  - 冲突记录：与 semantic-memory-search 存在文件优先 vs 向量优先的表面张力，实际互补（已记录）

## [2026-04-23] ingest | 可自动化、可扩展、AI增强的电商数据采集与处理系统
- Source file: raw/Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md
- Status: ✅ 成功摄入
- Summary: 基于 Docker + Ubuntu + n8n 的可自动化、可扩展、AI增强的电商数据采集与处理系统设计方案。三层架构：爬虫层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。推荐 Scrapy + Playwright 组合，Docker Compose 容器化；n8n 工作流实现定时爬取→LLM处理→数据库写入→报表通知的全链路自动化；本地可使用 Ollama 无需外部 API Key；防封策略包括 User-Agent 轮换和代理池。
- Concepts touched: [[Scrapy]], [[Playwright]], [[n8n]], [[Docker Compose]], [[Ollama]], [[Bright Data]], [[Scrapyd]], [[MinIO]], [[Grafana]], [[Metabase]], [[FastAPI]], [[LangChain]]
- Entities touched: [[Amazon]], [[JD]], [[Taobao]], [[Shopee]]
- Source page: wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md）
  - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（已存在于 Wiki）
  - 冲突检测：无已知冲突，与 [[scrapy-playwright-抓取tiktok-shop-data]] 同属电商数据采集技术栈
  - 已在 index.md 添加 Source 条目
  - 已在 overview.md TikTok E-commerce Operations 部分新增条目

## [2026-04-26] ingest | 电商视频Prompt库
- Source file: 跨境电商/电商视频Prompt.md
- Status: ✅ 成功摄入
- Summary: AI 生成宠物电商视频的 7 模块 Prompt 库（产品展示/宠物动作/衣服防穿帮/场景变化/Negative Prompt/卖货文案/全流程示例），以"拼积木"组合方式实现低翻车率 + 高真实感的 TikTok Shop 带货视频生成，扩展至 1产品→3视频→6文案→A/B 测试全链路自动化。
- Concepts touched: [[Prompt库设计原则]], [[Negative Prompt]], [[Image-to-Video]], [[TikTok电商内容自动化]], [[AI图生视频]]
- Entities touched: [[TikTok Shop]], [[宠物用品]], [[TikTok]]
- Source page: wiki/sources/电商视频prompt.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/电商视频prompt.md）
  - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（出现次数 < 2 次阈值）
  - 冲突检测：无已知冲突，与 [[AI图生视频工具盘点]]（工具盘点）和 [[做TK跨境思路不对努力白费]]（运营策略）互补
  - 已在 index.md 添加 Source 条目
  - 已在 overview.md 新增 [[电商视频Prompt库]] 小节，链接于 AI图生视频工具盘点 之后

## [2026-04-26] ingest | TikTok Shop - Apache Superset Dashboard设计思路
- Source file: 跨境电商/TikTok Shop - Apache Superset Dashboard设计思路.md
- Status: ✅ 成功摄入
- Summary: Apache Superset 在 TikTok Shop 电商选品分析场景的完整 Dashboard 设计方案——基于 products/reviews/variations 三表数据，通过 SQL View 预处理 JSON 字段，设计 4-Tab 专业 Dashboard（爆品雷达/类目洞察/店铺监控/评论分析），包含 KPI 卡/散点图/箱线图/热力图等可视化组件，提供选品评分加权公式（sold×0.4 + rating×15 + discount×0.5 + rating_count×0.2）。
- Concepts created: [[Apache Superset]], [[KPI Card]], [[选品评分公式]], [[SQL View]], [[Dynamic Filter]], [[GMV]], [[Scatter Plot]], [[Box Plot]], [[Heatmap]]
- Entities created: [[TikTok Shop]], [[tiktok_products 数据库]], [[products 表]], [[product_reviews 表]], [[product_variations 表]]
- Source page: wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/tiktok-shop-apache-superset-dashboard设计思路.md）
  - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - 冲突检测：无实质冲突，与 [[电商如何选品-如何找到爆款-选品策略]] 互补（策略 vs 数据工具）
  - 已在 index.md 添加 Source 条目
  - overview.md 已在 "TikTok E-commerce Product Management" 小节提及 Apache Superset 与 Dashboard 集成，无需额外更新

## [2026-04-18] ingest | 做TK跨境思路不对努力白费
- Source file: 跨境电商/做TK跨境思路不对努力白费.md
- Status: ✅ 成功摄入
- Summary: TikTok跨境电商全流程实战指南——从市场选择(美区/日本>东南亚)→账号准备→选品策略(数据软件+垂直类目)→店铺运营(流量监控+商品优化)→流量获取(短视频+达人营销)→仓储物流(海外仓+海运补货)→团队建设，提供完整执行框架。
- Concepts touched: [[跨境电商]], [[选品策略]], [[TikTok电商]], [[达人营销]]
- Entities touched: [[TikTok Shop]], [[美区]], [[日本]]
- Source page: wiki/sources/做tk跨境思路不对努力白费.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/做tk跨境思路不对努力白费.md）
  - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（出现次数<2次阈值）
  - 冲突检测：无已知冲突内容
  - 已在 index.md 添加 Source 条目
  - 已在 overview.md 新增 "TikTok E-commerce Operations" 小节

## [2026-04-23] ingest | 超达物流定价
- Source file: 跨境电商/超达物流定价.md
- Status: ✅ 成功摄入
- Summary: 超达物流跨境电商定价规则：申报/实重/材积取最大值计费，UIN渠道24-48h轨迹推送，TK平台面单"TKM"开头单号无效，UIN/TK取消单号收费规则，发货截止时间12点/美区周日休息。
- Concepts touched: [[计费重量原则]], [[轨迹推送机制]], [[取消单号收费]]
- Source page: wiki/sources/超达物流定价.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/超达物流定价.md）
  - Entity 和 Concept 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - 冲突检测：无实质冲突，与 [[TK美国面单授权及操作流程]] 互为补充（前者专注授权配置，本文专注计费规则）
  - 已在 index.md 添加 Source 条目
  - overview.md 无需更新（物流定价内容与 AI/软件主题 overview 相关性低）

## [2026-04-25] ingest | TK美国面单授权及操作流程
- Source file: 跨境电商/TK美国面单授权及操作流程.md
- Status: ✅ 成功摄入
- Summary: TikTok美国市场面单授权配置与操作流程截图教程，通过6张Zipline图床备份图片展示具体操作步骤。
- Concepts touched: [[TikTokShop]], [[面单授权]], [[跨境电商物流]]
- Entities touched: [[TikTok美国站]]
- Source page: wiki/sources/tk美国面单授权及操作流程.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/tk美国面单授权及操作流程.md）
  - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（内容为截图教程，信息量有限）
  - 冲突检测：无已知冲突内容
  - 已在 index.md 修正 Source 条目
  - overview.md 无需更新（物流操作类内容与 overview 主题相关性低）

## [2026-04-24] ingest | Scrapy + Playwright 抓取TikTok Shop Data
- Source file: 跨境电商/Scrapy + Playwright 抓取TikTok Shop Data.md
- Status: ✅ 成功摄入
- Summary: 使用 Scrapy + Playwright 技术栈抓取 TikTok Shop 商家数据的环境配置与运行指南。涵盖 Python venv 虚拟环境搭建、scrapy-playwright 依赖安装、Chromium 浏览器安装、Docker 容器化部署配置，以及 Playwright 验证方法。
- Concepts touched: [[Scrapy]], [[Playwright]], [[scrapy-playwright]], [[venv]], [[Docker]], [[Chromium]]
- Entities touched: [[TikTok Shop]], [[shenwei]]
- Source page: wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/scrapy-playwright-抓取tiktok-shop-data.md）
  - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面（各仅出现 1 次，未达 ≥2 次阈值）
  - 冲突检测：无已知冲突内容
  - 已在 index.md 添加 Source 条目
  - overview.md 无需更新（TikTok Shop 已存在于 Key Entities，Scrapy/Playwright 属技术工具不需独立概念页）

## [2026-04-23] ingest | GOG CLI 安装配置指南
- Source file: Skills/GOG-CLI-安装配置指南.md
- Status: ✅ 成功摄入
- Summary: gog CLI（Google Workspace 命令行工具）在 macOS 系统上的完整安装与配置流程。涵盖 Homebrew 安装、OAuth 凭证配置、测试用户白名单添加、Google API 启用、常用命令速查及故障排除。
- Concepts touched: [[OAuth 2.0]], [[Google Cloud Console]], [[API Enablement]], [[Google Workspace]]
- Entities touched: [[gog CLI]]
- Source page: wiki/sources/gog-cli-安装配置指南.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/gog-cli-安装配置指南.md）
  - 新增 1 个 Entity Page（wiki/entities/gog-CLI.md）
  - 冲突检测：无已知冲突内容
  - 已在 index.md 修正 Source 条目（去除 "(expected: source missing)" 标注）
  - 已在 overview.md Key Entities 添加 [[gog CLI]] 条目
  - 已在 overview.md Key Concepts 添加 [[OAuth 2.0]], [[Google Cloud Console]], [[API Enablement]]


- Source file: Skills/Last30Days-使用指南.md
- Status: ✅ 成功摄入
- Summary: Last30Days 方法论——通过 AI Agent 自动化追踪近30天内新增/更新的内容源，避免信息过载。核心价值：将"主动订阅"转变为"被动接收"，用 AI 替代人工巡检，节省 80% 信息搜集时间。
- Concepts touched: [[Last 30 Days Method]], [[信息消费习惯]]
- Entities touched: [[Last30Days]]
- Source page: wiki/sources/last30days-使用指南.md
- Notes:
  - 新增 1 个 Source Page
  - Concept 和 Entity 均以 wikilink 形式建立关联，暂不创建独立页面
  - 冲突检测：无已知冲突内容
  - 已在 index.md 添加 Source 条目
  - overview.md 无需更新（Last 30 Days Method 已存在于 Key Concepts）

## [2026-04-25] ingest | 如何利用Sora接口实现视频自动化生成工作流
- Source file: AI/如何利用Sora接口实现视频自动化生成工作流.md
- Status: ✅ 成功摄入
- Summary: 利用亚马逊 Bedrock 平台的 Sora API 实现视频生成全自动化工作流，覆盖注册→API调用→批量生成完整流程。成本仅 2-3 元人民币，远低于市场水平；新用户享 200 美元抵扣金和 6 个月免费试用；支持文本转视频和图像生成，可结合 n8n 实现批量 UGC 内容生产。
- Concepts touched: [[文字生成视频]], [[提示词优化]], [[肖像权合规]], [[n8n 工作流自动化]], [[UGC内容]]
- Entities touched: [[Sora]], [[亚马逊 Bedrock]], [[n8n]]
- Source page: wiki/sources/如何利用sora接口实现视频自动化生成工作流.md
- Notes:
  - 新增 1 个 Source Page
  - Concept 和 Entity 均已在 Source Page 中以 wikilink 形式建立关联，暂不创建独立页面（各出现 1 次，未达 ≥2 次阈值）
  - 冲突检测：无已知冲突内容
  - 已在 index.md 添加 Source 条目

## [2026-04-25] ingest | If You Have Multiple Interests, Do Not Waste the Next 2-3 Years
- Source file: AI/If you have multiple interests, do not waste the next 2-3 years  如果你有多项兴趣爱好，不要浪费接下来的两三年时间。.md
- Status: ✅ 成功摄入
- Summary: 系统论证多重兴趣是AI时代超能力的个人发展指南——核心主张：工业化专业化分工使人类沦为"愚蠢而依赖"的螺丝钉，第二次文艺复兴已经到来；个人成功三要素（自学+自利+自立）自然涌现通才型人才；品牌内容系统、创意密度方法论、系统经济是具体路径
- Concepts created: [[Generalist]], [[Self-Education]], [[Self-Interest]], [[Self-Sufficiency]], [[Second-Renaissance]], [[Idea-Density]], [[Idea-Museum]], [[Brand-Environment]], [[Content-Creator]], [[System-Economy]], [[Attention-Economy]]
- Entities created: [[AdamSmith]], [[LeonardoDaVinci]]
- Source page: wiki/sources/if-you-have-multiple-interests-do-not-waste-the-next-2-3-years-如果你有多项兴趣爱好-不要浪费接下来的两三年时间.md
- Notes:
  - 新增 1 个 Source Page、5 个 Concept 页面、2 个 Entity 页面
  - Concepts 全部符合"可抽象可复用"原则，创建独立页面
  - Entities: Adam Smith（≥2次引用分工理论）、Leonardo da Vinci（文艺复兴通才典范）均符合创建条件
  - 冲突检测：与 [[Multi-Agent System Reliability]] 的 Generalist 概念高度互补（后者从系统可靠性角度）
  - 已在 overview.md 个人品牌与一人公司段落添加新来源摘要
  - 已在 index.md 添加 11 个 Concept 条目、2 个 Entity 条目

## [2026-04-25] ingest | 我用 Gemini 3 一口气做了 10 个应用，附教程
- Source file: AI/我用 Gemini 3 一口气做了 10 个应用，附教程.md
- Status: ✅ 成功摄入
- Summary: 使用 Google Gemini 3 模型通过三步方法论（限定垂直场景→提示词约束结构化输出→前端SVG容器）快速构建 10 个可视化应用。核心发现：AI 生成 SVG 代码+前端渲染是快速交付 AI 应用的关键路径。
- Concepts touched: [[SVG可视化]], [[结构化输出]], [[Vibe-Coding]], [[AI应用开发]]
- Entities touched: [[Gemini-3]]（出现1次，不满足≥2次条件，暂不创建独立Entity页）
- Source page: wiki/sources/我用-gemini-3-一口气做了-10-个应用-附教程.md
- Notes:
  - 新增 1 个 Source Page
  - 已在 overview.md 添加 Gemini 3 十应用实战 段落，连接到 [[Vibe-Coding]]
  - 已更新 index.md 条目（日期从 2026-04-18 更新为 2026-04-23）
  - Entity 检查：Gemini-3 仅在本文出现，未达"出现≥2次"阈值，暂不创建独立页面
  - Concept 检查：SVG可视化/结构化输出等均未达"可抽象可复用"独立成页条件，暂纳入 Source Page Key Concepts
  - 冲突检测：无冲突内容

## [2026-04-25] ingest | Multi-Agent System Reliability
- Source file: AI/Multi-Agent System Reliability.md
- Status: ✅ 成功摄入
- Summary: 介绍4种提升多智能体系统可靠性的架构模式（Hierarchy/Consensus/Adversarial Debate/Knock-out），核心主张：停止拟人化LLM，将其视为分布式系统中不可靠的组件，通过架构约束而非提示词约束强制正确性
- Concepts created: [[Hierarchy-Agent-Pattern]], [[Consensus-Voting-Pattern]], [[Adversarial-Debate-Pattern]], [[Knock-out-Pattern]], [[Tree-of-Thoughts]], [[Genetic-Algorithm]], [[Reliability-Engineering]]
- Entities created: [[Alex Ewerlöf]]
- Entities updated: 无（Alex Ewerlöf 为新实体）
- Source page: wiki/sources/multi-agent-system-reliability.md
- Notes:
  - 新增 1 个 Source Page、1 个 Entity 页面、7 个 Concept 页面
  - Alex Ewerlöf Entity 在源文件中出现 ≥2 次（作者署名+引用），符合创建条件
  - 7 个 Concept 均符合"可抽象、可复用"原则，全部创建独立页面
  - 冲突检测：与 [[Designing for Agentic AI]] 互补而非冲突；与 [[Recursive Self-Optimization]] 共享自引用结构思想；与 [[Genetic-Algorithm]] 有明确关联（Knock-out 是 GA 的精简实现）
  - 已在 overview.md Key Concepts 列表添加所有 7 个新概念
  - 已在 overview.md Key Entities 列表添加 [[Alex Ewerlöf]]

## [2026-04-24] ingest | 全网最全！Nano Banana 2 使用指南（2025年12月更新）
- Source file: AI/全网最全！Nano Banana 2 使用指南（2025年12月更新） 1.md
- Status: ✅ 成功摄入
- Summary: 介绍 Google Nano Banana 2（Gemini 3 Pro Image）推理型图像生成模型的国内使用方法，通过 DeepSider 浏览器插件实现无 VPN 直连访问，同时支持数十款 AI 大模型
- Concepts created: 无（本次概念不足以独立建页）
- Entities created: [[DeepSider]], [[Nano Banana 2]]
- Entities updated: [[Google]]（新增 Nano Banana 2 产品信息）
- Source page: wiki/sources/全网最全-nano-banana-2-使用指南-2025年12月更新-1.md
- Notes:
  - Nano Banana 2 与 [[Nano Banana Pro]] 为不同版本，Nano Banana 2 为更新版（2025年12月发布）
  - [[Nano Banana Pro]] 已在 [[Google.md]] entity 中提及，本次新增 [[Nano Banana 2.md]] entity 独立页面

## [2026-04-24] ingest | 2025 年 11 个神级 AI 开源平替，GitHub 杀疯了
- Source file: AI/2025 年 11 个神级 AI 开源平替，GitHub 杀疯了。.md
- Status: ✅ 成功摄入
- Summary: 按 8 大领域（LLM/AI生图/生视频/AI智能体/AI编码/工作流/AI搜索/AI知识库）系统盘点 GitHub 上各领域最火的开源平替项目，核心洞察：国产开源模型在多领域达到或超越国际闭源竞品水平
- Concepts created: [[AI开源平替]]
- Entities created: [[Flux]], [[HunyuanVideo]], [[Manus]], [[OpenManus]], [[Cline]], [[Perplexica]], [[Dify]], [[Stable Diffusion]]
- Entities updated: [[DeepSeek]], [[Qwen]], [[n8n]]
- Source page: wiki/sources/2025-年-11-个神级-ai-开源平替-github-杀疯了.md
- Notes:
  - DeepSeek、Qwen、n8n 已在 Wiki 中存在，本次仅追加新版本信息
  - Flux（≥2次）、HunyuanVideo（≥2次）、Manus（≥2次）、OpenManus（≥2次）、Cline（≥2次）、Perplexica（≥2次）、Dify（≥2次）、Stable Diffusion（≥2次）均出现 ≥2 次，符合创建条件
  - OpenAI、MiniMax、Kimi K2、智谱 GLM 仅出现 1 次，未达到创建阈值
  - Perplexity 作为对比对象出现，但非本文主角，不创建独立页面
  - 冲突检测：内容与现有 Wiki 中 DeepSeek、n8n 等实体描述一致，无冲突
  - Meta 收购 Manus 是 2025 年重大事件，已体现在 [[Manus]] 实体页

## [2026-04-23] ingest | AI 解决方案专家培训课程
- Source file: AI/AI 解决方案专家培训课程.md
- Status: ✅ 成功摄入
- Summary: Coze 平台多行业 AI Agent 培训课程，涵盖国内版（coze.cn）和海外版（coze.com），提供覆盖金融、医疗、教育、电商、人力资源、泛娱乐、在线客服等 7 大行业共 50+ 可体验 Agent Demo，核心技术栈为 Prompt 工程、RAG、Function Call 和 Workflow 编排。
- Concepts created: [[Coze-Workflow]]
- Entities created: [[Coze]], [[SONY]], [[滴滴]]
- Source page: wiki/sources/ai-解决方案专家培训课程.md
- Notes:
  - Coze、SONY、滴滴三个实体在源文件中均出现 ≥2 次，符合创建条件
  - FaceFusion、F5-TTS、World Labs、抖音仅出现 1 次，未达到创建阈值（≥2次）
  - Prompt Engineering、Function Call、Workflow Engineering 等核心概念已存在于 Wiki，本次作为 Key Concepts 引用
  - 冲突检测：Coze 平台与其他 AI 工具（Claude Code、Ollama 本地部署）属互补关系，无内容冲突

- Source file: AI/RAG从入门到精通系列1：基础RAG.md
- Status: ✅ 成功摄入
- Summary: RAG 基础原理与实战：Indexing（文档加载→切分→向量化入库）→ Retrieval（向量相似度 Top-k 检索）→ Generation（问题+上下文→LLM 生成答案），Qwen+BAAI+LangChain+Qdrant 实战工具链。
- Concepts created: [[Indexing]], [[Retrieval]], [[Generation]], [[Split]], [[Context-Window]]
- Entities created: [[LangChain]], [[Qwen]], [[Qdrant]]
- Source page: wiki/sources/rag从入门到精通系列1-基础rag.md
- Notes:
  - RAG 概念页面 [[RAG]] 已存在于 wiki/concepts/RAG.md，已在 Source Page 中正确引用
  - 冲突检测：基础 RAG（Naive RAG）与 Advanced RAG / RAG Fusion 存在优化方向差异，待后续进阶内容补充后更新 Contradictions
  - [[PyTorch研习社]] 为文章来源方，raw 文档中有注明，Source Page Key Entities 已记录
  - BAAI（Embedding Model）和 LlamaIndex 在 Source Page 中作为 Key Entities 记录，暂未创建独立 Entity 页面

## [2026-04-23] ingest | 固定镜头短视频制作的AI全流程解析
- Source file: AI/固定镜头短视频制作的AI全流程解析.md
- Status: ✅ 成功摄入
- Summary: 利用 AI 技术快速制作高播放量固定机位家装类短视频的全流程方法论，涵盖分镜拆解（Google AI Studio）、九宫格图像生成（Midjourney/Nano Banana）、首尾针动画（海螺AI/KAI）、快节奏剪辑（剪映）、声音设计五大步骤，10 分钟内完成成片。
- Concepts created: [[固定机位]], [[首尾针动画]], [[九宫格法]]
- Entities created: [[Midjourney]], [[KAI]], [[剪映]]
- Source page: wiki/sources/固定镜头短视频制作的ai全流程解析.md
- Notes:
  - 冲突检测：与传统视频制作理念（复杂镜头语言+丰富转场）存在冲突，已记录至 Source Page Contradictions 部分
  - Google/Nano Banana 实体已存在于 wiki/entities/Google.md，已在 Source Page Key Entities 中正确引用
  - 海螺AI 仅为提及（非关键工具），未创建独立 Entity 页面
  - 快节奏剪辑、卡点、内容连续变化、时间压缩等为描述性术语，不满足"可抽象可复用"原则，未创建独立 Concept

## [2026-04-25] ingest | 大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏
- Source file: AI/大模型相关术语和框架总结｜LLM、MCP、Prompt、RAG、vLLM、Token、数据蒸馏.md
- Status: ✅ 成功摄入
- Summary: 大模型生态核心术语入门速查手册，涵盖 LLM、Prompt、MCP、Agent、RAG、Embedding、LangChain、vLLM、Token、数据蒸馏等概念，用通俗语言和可视化类比解释大模型领域关键术语
- Concepts created: [[Model Context Protocol]], [[vLLM]], [[LangChain]]
- Concepts updated: [[Large Language Model]]（添加来源引用）, [[AI Agent]]（添加 Model Context Protocol 关联 + 来源引用）, [[RAG]]（已包含来源）
- Entities identified: 无（shenwei 仅在本文出现 1 次，不满足 ≥2 次条件；OpenAI/vLLM 社区仅为引用来源，不满足关键影响条件）
- Source page: wiki/sources/大模型相关术语和框架总结｜llm-mcp-prompt-rag-vllm-token-数据蒸馏.md
- Notes:
  - 冲突检测：与 [[llms-rag-ai-agent-三个到底什么区别]] 属互补关系（术语科普 vs 三层架构梳理），已记录至 Source Page Contradictions 部分
  - 无需创建 shenwei Entity（仅出现 1 次，不满足 ≥2 次条件）
  - vLLM.md 中 KV Cache/PagedAttention/Continuous Batching 等子概念不单独创建页面，因其属于 vLLM 框架的内部技术细节，不满足"可抽象、可复用"原则
  - Embedding 已存在 [[Vector-Embedding]] Concept，LangChain 为框架类概念（已有充分讨论）

## [2026-04-25] ingest | Nano Banana Pro 提示词指南与策略（上篇）
- Source file: AI/Nano-Banana Pro Prompting Guide & Strategies 1.md
- Status: ✅ 成功摄入
- Summary: Google Nano Banana Pro 官方提示词指南上篇，涵盖 10 条黄金法则（编辑而非重生成、使用自然语言、提供上下文等）和前 9 个能力域（文本渲染/信息图、角色一致性/身份锁定、Google Search 信息锚定、高级编辑/修复/着色、2D/3D 维度转换、高分辨率/纹理、思考推理模式、故事板/概念艺术、结构控制/布局引导），附大量可直接复制的实战提示词模板。
- Concepts identified: 无（Nano Banana Pro 特有概念均为具体应用技术，不满足可复用抽象原则）
- Entities identified: [[Google]]（已存在于 wiki/entities/Google.md，已更新 Key Products 添加 Google AI Studio / Nano Banana Pro / Google Colab）
- Source page: wiki/sources/nano-banana-pro-prompting-guide-strategies-1.md
- Notes:
  - index.md 已修复旧条目（移除 expected/missing 标注，替换为完整标题和摘要）
  - overview.md 已更新「Nano Banana Pro 提示词指南」段落，明确标注本文为上篇及涵盖的 9 个能力域
  - 冲突检测：与 [[全网最全-nano-banana-2-使用指南-2025年12月更新-1]] 存在范围重叠，已记录至 Source Page Contradictions 部分，结论为互补而非冲突
  - 无需新建 Entity 页面（shenwei 作者仅在本文出现 1 次，不满足 ≥2 次条件）
  - 无需新建 Concept 页面（身份锁定/对话式编辑等为 Nano Banana Pro 特有应用技术，不满足可复用抽象条件）

- Source file: AI/我的工具集.md
- Status: ✅ 成功摄入
- Summary: 个人 AI 工具推荐清单，按类型分类（Text-to-Speech / Image-Editor / Image-to-Video / Web-Scraper / AI-Summary），覆盖 Google AI Studio（Wavespeed 图生视频、Vidu、海螺 AI）、Brightdata（网页爬取）、Decopy（AI 摘要）等服务。与 AI图生视频工具盘点属互补关系——本文为工具索引，后者为免费工具详细评测。
- Concepts identified: 无（工具索引类来源，各概念已在其他来源中有充分讨论）
- Entities identified: [[Google]]（已存在于 wiki/entities/Google.md）
- Source page: wiki/sources/我的工具集.md
- Notes:
  - 更新 index.md Sources 部分（替换 expected 标记行）
  - 更新 overview.md AI Tools & Prompt Engineering 部分（新增「我的工具集」段落）
  - Google Entity 已存在，无需重复创建
  - Vidu/海螺AI/Wavespeed/Brightdata/Decopy 仅在本文中出现 1 次，不满足 Entity ≥2 次创建条件
  - 无需新建 Concept 页面（各工具类型概念在其他来源中已充分覆盖）
  - 冲突检测：与 [[二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆]] 存在互补关系（工具清单 vs 详细评测），已记录至 Source Page Contradictions 部分

## [2026-04-24] ingest | 如何写出完美的Prompt（提示词）？
- Source file: AI/如何写出完美的Prompt（提示词）？.md
- Status: ✅ 成功摄入
- Summary: 系统阐述 Prompt 构建底层逻辑的职场应用指南。核心理念：Prompt 是人与 AI 的协作协议，本质是将模糊需求转化为 AI 可执行的结构化任务。四大构建要素（角色+需求+场景+目标）+ 三层技巧体系（基础：需求拆解/上下文补全/格式定义/示例引导；进阶：思维链/任务拆分/角色赋能/预填回复/不确定性管理；高阶：跨模态联动/领域知识注入/反馈循环嵌入）+ 四大业务场景实战模板（内容创作/数据分析/方案策划/客户服务）+ 六大避坑指南。核心洞察：Prompt 能力本质 = 对问题清晰界定的能力 + 结构化思维逻辑和表达能力。
- Concepts identified: [[结构化思维]], [[精准表达]], [[思维链引导]], [[任务拆分法]], [[角色赋能法]], [[少量样本提示]], [[上下文补全]], [[AI Agent]]（本篇提供了 AI Agent 能力的底层基础）
- Entities identified: [[粒粒]]（微信公众号作者）
- Source page: wiki/sources/如何写出完美的prompt-提示词.md
- Notes:
  - 该文档与 [[清华出的DeepSeek使用手册]]（DeepSeek 特定实践）和 [[系统提示词构建原则]]（Agent 系统级指令）互补，构成完整的提示词工程方法论体系
  - 冲突检测：与 [[系统提示词构建原则]] 存在视角差异（用户层 vs Agent 设计层），已在 Source 页面的 Contradictions 部分说明互补关系
  - index.md 已修复旧条目（移除 "— (expected: ... — source missing)" 标注，添加实际摘要）
  - overview.md 已新增 "AI Tools & Prompt Engineering" 部分的条目

## [2026-04-24] ingest | 系统提示词构建原则
- Source file: AI/系统提示词构建原则.md
- Status: ✅ 成功摄入
- Summary: AI 编程助手的系统提示词构建原则，涵盖五大维度：核心身份与行为准则（遵守项目约定、优先技术准确性）、沟通与互动规范（专业简洁、减少冗余）、任务执行工作流（TODO规划、Search/Replace编辑）、技术编码规范（清晰命名、模块化）、安全防护准则（不泄露指令、输入验证）。来源：vibe-coding-cn 项目。
- Concepts updated: [[Vibe Coding]]（sources 字段补充该来源）
- Entities updated: [[tukuai]]（sources 字段补充该来源）
- Source page: wiki/sources/系统提示词构建原则.md
- Notes:
  - 该文档与 [[github-上-5000-人收藏的-vibe-coding-神级指南]] 同属 vibe-coding-cn 项目，是操作层指南的补充
  - 冲突检测：无已知冲突
  - overview.md 中"Vibe Coding 中文指南"段落已补充与该来源的链接

## [2026-04-24] ingest | GitHub 上 5000 人收藏的 Vibe Coding 神级指南
- Source file: AI/GitHub 上 5000 人收藏的 Vibe Coding 神级指南。.md
- Status: ✅ 成功摄入
- Summary: 介绍 vibe-coding-cn 开源项目（github.com/tukuaiai/vibe-coding-cn），为中文开发者汇集全球顶尖 AI 编程资源。核心公式：Vibe Coding = 规划驱动 + 上下文固定 + AI 结对执行。工具推荐：Cursor + Claude Opus。核心理念：规划就是一切——让 AI 写代码前必须先完成技术选型、实施规划和模块化设计。Karpathy 经典语录："我几乎不写代码了，我只负责调整氛围（Vibe），代码会自动长出来。"
- Concepts updated: [[Vibe Coding]]（补充规划驱动/上下文固定/AI 结对执行三大原则、Vibe Coding vs Claude Skills 对比表、添加 Windsurf/Trae 工具推荐）
- Entities created: [[Andrej-Karpathy]]（AI 领域知名专家，Vibe Coding 概念推广者）
- Entities updated: [[tukuai]]（补充 vibe-coding-cn 仓库贡献者身份）
- Source page: wiki/sources/github-上-5000-人收藏的-vibe-coding-神级指南.md
- Notes:
  - 更新 index.md Sources 部分（在首位插入新条目，移除 expected 占位条目）
  - 更新 overview.md，添加"Vibe Coding 中文指南"段落至 AI Tools & Prompt Engineering 部分
  - 更新 index.md Entities 部分（添加 Andrej-Karpathy 条目）
  - Vibe Coding 概念页面已存在，本次更新 sources 字段和核心原则内容
  - 冲突检测：Vibe Coding（氛围感/直觉式）与 Claude Skills（结构化 SOP）存在视角差异，已记录至 source page Contradictions 部分

## [2025-12-18] ingest | 不会Gemini的产品经理真的要被淘汰了 | 附保姆级PRD生成指南
- Source file: AI/不会Gemini的产品经理真的要被淘汰了  附保姆级PRD生成指南.md
- Status: ✅ 成功摄入
- Summary: 产品经理Kira2red分享大模型（Gemini）辅助PRD生成的保姆级教程——三步工作流：①用FeatureList构思需求框架（大模型生成层级式功能表）、②Mermaid画逻辑图（ER图/时序图/泳道图辅助理解）、③分页面逐一描述生成PRD+HTML原型。核心方法论："人负责想，大模型负责写"，可缩短文档工作时间90%以上。深层洞察：未来可能不需要PRD文档，产品经理需进化为"超级个体"，核心能力是市场洞察而非写文档。
- Concepts created: [[FeatureList]], [[超级个体]], [[PRD生成工作流]]
- Entities updated: [[Gemini]]（关联本文工作流）
- Source page: wiki/sources/不会gemini的产品经理真的要被淘汰了-附保姆级prd生成指南.md
- Notes:
  - 更新 index.md Sources 部分（在首位插入新条目）
  - 更新 overview.md AI Tools & Prompt Engineering 小节（补充AI辅助PRD生成条目）
  - Vibe Coding Concept 已存在（无需新建）
  - FeatureList、超级个体、PRD生成工作流为新创建 Concept
  - 无内容冲突

## [2026-04-23] ingest | 3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！
- Source file: AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md
- Status: ✅ 成功摄入
- Summary: Anthropic 官方 Claude Skills 仓库（github.com/anthropics/skills，3.2 万收藏）介绍。Skills = 写给 Claude 的"说明书" + "SOP"，将反复执行的有固定流程的任务拆解为 AI 能理解、能复用、能自动执行的一套流程。官方库包含三大类：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server/自动化测试/Artifacts 构建）、创意类 Skill。核心洞察：Claude Skills 的爆发标志着从「提示词工程」向「流程工程」的范式转变；Vibe Coding 的尽头也是 Skills。
- Concepts created: [[Claude Skills]], [[Workflow Engineering]]
- Source page: wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md
- Notes:
  - 更新 index.md Sources 部分（修正 source missing 条目）
  - 更新 overview.md AI Tools & Prompt Engineering 小节（添加 Claude Skills 范式洞察）
  - 创建 Claude-Skills 和 Workflow-Engineering 两个 Concept 页面
  - 添加 Concepts 条目到 index.md（Claude-Skills、Workflow-Engineering）
  - 无内容冲突
  - Entity 页面（Anthropic/skillsmp/aitmpl 等）出现次数均 <2 次，未创建
- Source page: wiki/sources/7-ways-i-use-notebooklm-to-make-my-life-easier.md
- Notes:
  - 更新 index.md Sources 部分（替换 expected 占位条目）和 Concepts 部分（新增2个条目）
  - 更新 overview.md AI Tools & Prompt Engineering 小节（补充 NotebookLM 7种用法条目）
  - NotebookLM Entity 页面已存在，更新 sources 字段和内容
  - Source-Grounding 和 Passive-Learning 为新建 Concept 页面
  - 冲突检测：未发现与其他 Wiki 页面存在明显内容冲突

## [2026-04-24] ingest | Never write another prompt
- Source file: AI/Never write another prompt.md
- Status: ✅ 成功摄入
- Summary: 介绍一款能将简单描述自动转化为详细结构化提示词的 AI 工具，支持变量插入和自定义编辑，大幅降低提示词工程门槛。与 Claude Prompt Library（现成提示词库）和 Nano Banana 提示词框架（结构化模板）同属提示词工程的不同路径。
- Concepts covered: [[Prompt Engineering]], [[API Key]], [[Variables in Prompts]]
- Entities referenced: [[ChatGPT]], [[Google Gemini]]
- Source page: wiki/sources/never-write-another-prompt.md
- Notes:
  - 更新 index.md Sources 部分（新增条目，按日期排序）
  - 更新 overview.md AI Tools & Prompt Engineering 小节
  - 冲突检测：与 useful-prompt-lib.md 存在"是否需要预制提示词"视角差异（双方 Contradictions 均已记录）
  - ChatGPT/Google Gemini 已存在于 Wiki，无需新建 Entity 页面

## [2026-04-23] ingest | Best 7 news API data feeds - AI News
- Source file: AI/Best 7 news API data feeds - AI News.md
- Status: ✅ 成功摄入
- Summary: 7款主流新闻API横向评测（Webz.io/GNews/The Guardian/Bloomberg/Financial Times/Opoint/Mediastack），覆盖开放网/深网/暗网数据、金融情报、舆情监控、情感分析、内容聚合、AI预测分析等应用场景，为AI应用和数据分析场景选择新闻数据接口提供选型参考。
- Concepts covered: [[News API]], [[Financial Intelligence]], [[Media Monitoring]], [[Sentiment Analysis]], [[Risk Assessment]], [[Content Aggregation]], [[Predictive Analysis]]
- Entities referenced: [[Webz.io]], [[GNews API]], [[The Guardian API]], [[Bloomberg API]], [[Financial Times API]], [[Opoint]], [[Mediastack API]]
- Source page: wiki/sources/best-7-news-api-data-feeds-ai-news.md
- Notes:
  - 更新 index.md Sources 部分
  - 7个 Entity 均仅出现1次，未创建独立 Entity 页面
  - Concept 均为通用概念，已隐式覆盖，无冲突

## [2026-04-23] ingest | Claude Prompt Library 汇总表
- Source file: AI/Useful Prompt Lib.md
- Status: ✅ 成功摄入
- Summary: Anthropic Claude 官方提示词库完整汇总，收录 64+ 款专业化提示词，覆盖开发工具、效率工具、创意工具、营销工具、教育工具等 10+ 领域。TikTok 跨境电商推荐 Babel's Broadcasts（多语言推文）、Review Classifier（评论分类）、Data Organizer（非结构化→JSON）三剑客。
- Concepts covered: [[Anthropic Prompt Library]], [[Babel's Broadcasts]], [[Review Classifier]], [[Data Organizer]], [[Prompt Engineering]]
- Entities referenced: [[Anthropic]], [[TikTok]]
- Source page: wiki/sources/useful-prompt-lib.md
- Notes:
  - 更新 index.md Sources 部分
  - 更新 overview.md AI Tools & Prompt Engineering 小节
  - Anthropic/TikTok 均仅出现1次，未创建独立 Entity 页面
  - 冲突检测：与 never-write-another-prompt.md 存在"是否需要预制提示词"的冲突（已记录至 source page Contradictions 部分）

## [2026-04-23] ingest | 二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆
- Source file: AI/二创视频必不可少！2025年最热门AI工具推荐合集-AI配音、声音克隆.md
- Status: ✅ 成功摄入
- Summary: 2025年AI配音及声音克隆工具推荐合集，评测ElevenLabs、海螺AI（MiniMax）、F5-TTS、TTSMaker、剪映、魔音工坊、AnyVoice等7款主流工具。涵盖免费/付费、国际/国内、技术门槛等多维度对比，为不同用户群体提供选型建议。
- Concepts covered: [[AI配音]], [[声音克隆]]
- Entities referenced: [[ElevenLabs]], [[海螺AI]], [[F5-TTS]], [[TTSMaker]], [[剪映]], [[魔音工坊]], [[AnyVoice]], [[MiniMax]]
- Source page: wiki/sources/二创视频必不可少-2025年最热门ai工具推荐合集-ai配音-声音克隆.md
- Notes:
  - 更新 index.md Sources 部分
  - Entity/Concept 均未创建独立页面（各工具仅在本文出现一次，不满足Entity≥2次条件；AI配音/声音克隆概念在其他来源中已有相关讨论，可后续扩展）

## [2026-04-23] ingest | The Picture They Paint of You
- Source file: AI/The Picture They Paint of You.md
- Status: ✅ 成功摄入
- Summary: 探讨 AI 工具的市场定位如何折射对人类工作者的隐性认知。对比 10+ 款 AI SRE 产品和 8+ 款 Coding Assistant 的营销话语，发现：AI SRE 被建构为"替代者"，Coding Assistant 被建构为"合作伙伴"。这种差异映射了组织内部对不同角色真实价值的认知分裂，暗示决策者与从业者之间对工作意义理解的根本分歧。
- Concepts created: [[Taylorism]], [[Left-over-Principle]], [[Analogy-as-Straitjacket]]
- Source page: wiki/sources/the-picture-they-paint-of-you.md
- Notes:
  - 新增 Sources 条目至 index.md
  - 新增 3 个 Concept 页面：Taylorism.md、Left-over-Principle.md、Analogy-as-Straitjacket.md
  - 冲突检测：与 wiki/sources/what-i-know-about-cloud-service-delivery-1.md 中 SRE 角色认知存在冲突（已记录至 source page Contradictions 部分）
  - Entities: Anthropic、GitHub Copilot、OpenAI Codex、Cline、AWS DevOps Agent 均未创建独立页面（属产品类 Entity，命名类 Entity 价值待定）

## [2026-04-23] ingest | Nano Banana 提示词框架
- Source file: AI/Nano Banana 提示词框架.md
- Status: ✅ 成功摄入
- Summary: AI 图像生成的结构化提示词框架，提供两套 JSON Schema 模板——物件描述框架（item / materials / details / condition）和人物描述框架（age / appearance / pose）——共用 shot / environment / lighting / camera / color_grade / style / quality / negatives 参数字段。示例展示了如何将专业摄影描述语言（材质/布光/相机参数）结构化填入模板。
- Concepts covered: [[Nano Banana Prompting Framework]], [[Structured Prompt Engineering]], [[Negative Prompting]], [[Shot Composition]], [[Photography Lighting Description]], [[Camera Parameter Specification]]
- Entities referenced: [[Google]], [[Nano Banana]]
- Source page: wiki/sources/nano-banana-提示词框架.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - 更新 overview.md AI Tools & Prompt Engineering 部分
  - Google Entity 已存在于 wiki/entities/Google.md，未重复创建

## [2026-04-23] ingest | 谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版
- Source file: AI/谷歌深夜甩出一份【Nano Banana Pro提示词指南】，手把手教你生产专业级内容，实战案例+提示词模版.md
- Status: ✅ 成功摄入
- Summary: 谷歌发布的 Nano Banana Pro 官方提示词指南（《The Complete Guide to Nano Banana Pro》），核心主题是"将 AI 从趣味性图像生成升级为功能性专业资产生产"。10 大黄金法则：编辑而非重新生成、使用自然语言完整句子、具体且具描述性、提供上下文。9 个实战章节覆盖文本渲染/信息图、角色一致性、Google 搜索信息锚定、高级编辑、2D/3D 转换、高分辨率、思考推理、故事板、结构控制。
- Concepts created: [[提示词工程]], [[身份锁定（Identity Locking）]], [[思维推理模式（Thinking Mode）]], [[信息图生成]], [[2D/3D 转换]], [[草图转成品（Sketch to Final）]]
- Entities created: [[谷歌]]
- Source page: wiki/sources/谷歌深夜甩出一份-nano-banana-pro提示词指南-手把手教你生产专业级内容-实战案例-提示词模版.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - 新增 6 个 Concept 页面
  - 新增 1 个 Entity 页面：Google.md
  - 更新 overview.md，新增"Nano Banana Pro 提示词指南"段落至 AI Tools & Prompt Engineering 部分
  - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突

## [2026-04-23] ingest | 详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1
- Source file: AI/详细！离线部署大模型：ollama+deepseek+open-webui安装使用方法及常见问题解决 1.md
- Status: ✅ 成功摄入
- Summary: Ollama + DeepSeek-R1 + Open WebUI 本地离线部署完整指南，覆盖硬件要求、安装方法（macOS/Windows/Linux/Docker）、模型下载加速（魔塔/HF Mirror/夸克网盘）、API 安全配置（nginx + Bearer Token）和 Open WebUI Docker Compose 部署。
- Entities created: [[Ollama]], [[Open WebUI]]
- Concepts created: [[Local LLM Deployment]], [[Docker LLM Deployment]]
- Source page: wiki/sources/详细-离线部署大模型-ollama-deepseek-open-webui安装使用方法及常见问题解决-1.md
- Notes:
  - 新增 Sources 条目至 index.md（Sources 节顶部）
  - 新增 Entity 页面：Ollama.md、Open-WebUI.md
  - 新增 Concept 页面：Local-LLM-Deployment.md、Docker-LLM-Deployment.md
  - 更新 overview.md：Key Entities 节和 AI Tools 节

## [2026-04-23] ingest | OpenAI ChatGPT 个性化定义
- Source file: AI/OpenAI ChatGPT 个性化定义.md
- Status: ✅ 成功摄入
- Summary: ChatGPT 自定义指令（Custom Instructions）的完整配置——定义用户身份（47岁、云计算背景、跨境电商创业者）、响应风格（高度有条理、详细解释、错误零容忍）和交互偏好（主动预判需求、不道德说教、URL统一末尾引用）。核心原则：[[Expert User Assumption]]（用户为所有领域专家）、[[Proactive AI]]（主动出击而非被动等待）、[[Error Accountability]]（主动反馈配置导致的回复质量下降）。
- Concepts created: [[Personalization]], [[Custom Instructions]], [[Proactive AI]], [[Expert User Assumption]], [[Error Accountability]]
- Entities created: [[OpenAI]], [[ChatGPT]]
- Source page: wiki/sources/openai-chatgpt-个性化定义.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - 新增 5 个 Concept 页面：Personalization.md、Custom-Instructions.md、Proactive-AI.md、Expert-User-Assumption.md、Error-Accountability.md
  - 新增 2 个 Entity 页面：OpenAI.md（美国 AI 研究公司）、ChatGPT.md（OpenAI 对话产品）
  - 更新 overview.md，新增"ChatGPT 个性化配置"段落至 AI Tools & Prompt Engineering 部分
  - 将 5 个新 Concept 添加至 overview.md Key Concepts 列表
  - 将 OpenAI、ChatGPT 添加至 overview.md Key Entities 列表
  - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——[[designing-for-agentic-ai]] 中的 Personalization 原则与本文配置案例一致，无矛盾

## [2026-04-23] ingest | A Formalization of Recursive Self-Optimizing Generative Systems
- Source file: AI/A Formalization of Recursive Self-Optimizing Generative Systems.md
- Status: ✅ 成功摄入
- Summary: 递归自我优化生成系统的形式化理论模型——定义生成器空间 $\mathcal{G}$、优化算子 $O$、元生成算子 $M$、自映射 $\Phi$，稳定生成能力 $G^*$ = $\Phi$ 的不动点；用 λ-calculus Y 组合子表达自引用结构 $G^* \equiv Y\;\text{STEP}$。核心发现：递归自我优化自然涌现不动点结构，而非终止输出；为 Self-Improving AI 提供原则性理论基础。
- Concepts created: [[Recursive Self-Optimization]], [[Generator Space]], [[Self-Referential Computation]], [[Fixed-Point Semantics]], [[Y-Combinator]]
- Entities created: [[tukuai]]
- Source page: wiki/sources/a-formalization-of-recursive-self-optimizing-generative-systems.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - 新增 5 个 Concept 页面：Recursive-Self-Optimization.md、Generator-Space.md、Self-Referential-Computation.md、Fixed-Point-Semantics.md、Y-Combinator.md
  - 新增 1 个 Entity 页面：tukuai.md（独立研究者，本文作者）
  - 更新 overview.md，新增"Recursive Self-Optimizing Generative Systems"段落至 Multi-Agent AI Systems 部分
  - 将 5 个新 Concept 添加至 overview.md Key Concepts 列表
  - 将 tukuai 添加至 overview.md Key Entities 列表
  - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——本文为纯理论形式化，与 Wiki 中其他 Agent 应用案例属不同层次

## [2026-04-23] ingest | LLMs、RAG、AI Agent 三个到底什么区别？
- Source file: AI/LLMs、RAG、AI Agent 三个到底什么区别？.md
- Status: ✅ 成功摄入
- Summary: LLM、RAG、AI Agent 三者的定义与关系——LLM=思考（天才大脑），RAG=认知（记忆系统），Agent=执行（行动系统）。三者非竞争技术，而是在不同层面互补。未来不在于选择其一，而在于将三者结合架构设计。
- Concepts created: [[Large Language Model]], [[RAG]], [[AI Agent]], [[ReAct Pattern]]
- Entities created: （无新 Entity 创建）
- Source page: wiki/sources/llms-rag-ai-agent-三个到底什么区别.md
- Notes:
  - 新增 Sources 条目至 index.md（置于最前，按日期排序）
  - 新增 3 个 Concept 页面：Large-Language-Model.md、RAG.md、AI-Agent.md
  - 更新 overview.md Key Concepts 列表，添加 Large Language Model/RAG/AI Agent/ReAct Pattern
  - 更新 overview.md，新增"LLM / RAG / AI Agent 三层架构"段落至 AI Tools & Prompt Engineering 部分
  - 更新 index.md Concepts 部分，添加 3 个新 Concept 条目
  - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突——本文为基础概念梳理，与 Wiki 中 Agentic AI 相关内容一致

## [2026-04-23] ingest | Google 神级生产力工具，所有 GitHub 开源平替都找到了
- Source file: AI/Google 神级生产力工具，所有 GitHub 开源平替都找到了。.md
- Status: ✅ 成功摄入
- Summary: Google NotebookLM 的 6 款 GitHub 开源平替全景盘点——OpenNotebook（14.6k Stars 全功能）、SurfSense（11.4k Stars 综合研究智能体）、Podcastfy（播客垂直聚焦）、NotebookLlama（LlamaIndex 官方学习参考）、PageLM（教育场景）、InsightsLM（低代码架构）。覆盖从"全功能替代"到"垂直聚焦"的不同需求层次。
- Concepts created: [[文档问答]], [[播客生成]], [[语义搜索]], [[混合搜索]], [[本地化部署]]
- Entities created: [[Google]], [[NotebookLM]], [[OpenNotebook]], [[SurfSense]], [[Podcastfy]], [[NotebookLlama]], [[PageLM]], [[InsightsLM]]
- Source page: wiki/sources/google-神级生产力工具-所有-github-开源平替都找到了.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - 新增 Entity 页面：Google、NotebookLM、OpenNotebook、SurfSense、Podcastfy、NotebookLlama、PageLM、InsightsLM（共8个）
  - 新增 Concept 页面：文档问答、播客生成、语义搜索、混合搜索、本地化部署（共5个）
  - 更新 overview.md，新增"AI Tools & Prompt Engineering"部分的"NotebookLM 开源平替生态"段落
  - 无内容冲突——与现有 RAG、知识管理工具内容互补，未发现矛盾

## [2026-04-23] ingest | 教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報
- Source file: AI/教學 ChatGPT 先做知識整理，再讓 Canva、 Gamma AI 輸出簡報.md
- Status: ✅ 成功摄入
- Summary: AI 简报自动化工作流——先用 ChatGPT 做知识整理，再用 Canva / Gamma AI 输出演示文稿。两阶段工作流（思考者→设计师）比直接用 AI 生成简报效果更好。
- Concepts created: [[AI簡報工作流]]
- Entities created: [[Canva]], [[Gamma-AI]]
- Source page: wiki/sources/教學-chatgpt-先做知識整理-再讓-canva-gamma-ai-輸出簡報.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - 新增 Entity 条目：[[Canva]], [[Gamma-AI]]
  - 新增 Concept 条目：[[AI簡報工作流]]
  - 更新 overview.md，新增段落至 AI Tools & Prompt Engineering 部分
  - 无内容冲突

## [2026-04-23] ingest | Designing for Agentic AI
- Source file: AI/Designing for Agentic AI.md
- Status: ✅ 成功摄入
- Summary: 阐述 GenAI（创作内容）vs Agentic AI（主动行动）的核心差异，以及为 Agentic AI 设计用户体验的 TCPCA 五原则——透明度、控制感、个性化、对话、主动预判。核心洞察：观察 AI 决策过程本身就是一种参与方式，设计隐喻从"响应用户点击/滑动"转向"AI 运行时的实时反馈"。
- Concepts updated: [[Agentic AI]]（已存在，仅补充 TCPCA 五原则维度）, [[Transparency]], [[Control]], [[Personalization]], [[Conversation]], [[Anticipation]]
- Entities updated: [[Yuri Pessa]]（已存在，仅补充身份说明）
- Source page: wiki/sources/designing-for-agentic-ai.md
- Notes:
  - 新增 Sources 条目至 index.md（置于 Sources 末尾，因源文件日期 2025-03-02 早于所有现有条目）
  - 新增 overview.md 段落至 AI Tools & Prompt Engineering 部分
  - 无需新建 Entity/Concept 页面（Agentic-AI entity 已存在，TCPCA 五原则暂不满足独立 Concept 页面条件）
  - 与 [[Google-5个-Agent-Skill-设计模式]] 同属 AI Agent 设计方法论

## [2026-04-23] ingest | 养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流
- Source file: 微信公众号/养虾日记5：深夜与苏轼聊AI，他说：被浪打下去还能爬起来的才叫风流.md
- Status: ✅ 成功摄入
- Summary: 用AI蒸馏历史人物思维框架创建"数字导师"——以苏东坡为首位实践，展示如何将千年古人心智模型（六道：进退由时/此心安处/辞达而已/逆境转化/自出新意/天人合一）转化为可运行的AI Skill。女娲·Skill造人术通过6个并行Agent从6维度采集信息，产出自包含的.skill文件。
- Concepts created: [[数字导师]], [[思维蒸馏（女娲造人术）]], [[心智模型]], [[AI-Skill]]
- Entities created: [[苏东坡]], [[女娲]]
- Source page: wiki/sources/养虾日记5-深夜与苏轼聊ai-他说-被浪打下去还能爬起来的才叫风流.md
- Notes:
  - 新增 Sources 条目至 index.md（置于养虾日记4之后）
  - 新增 Entity 条目：[[苏东坡]]
  - 新增 Concept 条目：[[数字导师]], [[思维蒸馏（女娲造人术）]]
  - 与 [[养虾日记1/2/3/4]] 和 [[养龙虾5天血泪史]] 属同一「养虾日记」系列

## [2026-04-23] ingest | 一语点醒梦中人
- Source file: AI/一语点醒梦中人.md
- Status: ✅ 成功摄入
- Summary: 收录中国传统诗词与哲学典籍中的经典名句及其释义，涵盖儒道佛三家智慧——王维"行到水穷处，坐看云起时"的佛学顿悟、曾国藩"唯忘机可以消众机"的处世哲学、庄子"知其不可奈何而安之若命"的接受智慧、《老子》"大智若愚，大巧若拙"的守拙哲学、《金刚经》"一切有为法如梦幻泡影"的空性智慧。
- Concepts covered: [[空性智慧]], [[守拙]], [[安之若命]], [[和光同尘]], [[忘机]], [[中庸之道]], [[有为法]]
- Entities referenced: [[王维]], [[曾国藩]], [[庄子]], [[苏东坡]], [[郑板桥]]
- Source page: wiki/sources/一语点醒梦中人.md
- Notes:
  - 新增 Sources 条目至 index.md
  - 新增 overview.md 段落"经典智慧与人生哲学"
  - Entity/Concept 均未创建独立页面（各人物/概念仅在本文出现1次，未达≥2次阈值）
  - 与 [[养虾日记5]]（苏东坡数字导师）存在潜在关联，可后续扩展

## [2026-04-22] ingest | 不谈技术：普通人该怎么在AI时代赚钱？
     2|- Source file: 微信公众号/不谈技术：普通人该怎么在AI时代赚钱？.md
     3|- Status: ✅ 成功摄入
     4|- Summary: AI时代普通人如何赚钱的思维框架——三大原则：品味值钱（判断力是护城河）、做端到端的事（不当代价）、用死亡过滤器（找到真正热爱的事）。核心洞察：AI不会让普通人变富，AI会让那些知道自己要做什么、并且对品质有执念的人变得极其强大。
     5|- Concepts created: [[品味]], [[端到端]], [[死亡过滤器]], [[工具民主化]]
     6|- Entities created: [[乔布斯]]
     7|- Source page: wiki/sources/不谈技术-普通人该怎么在ai时代赚钱.md
     8|- Notes:
     9|  - 与 [[个人品牌与一人公司]] 属同一主题（AI时代个人定位与杠杆）
    10|  - 与 [[Ikigai框架]] 的"热情"维度高度相关
    11|
    12|## [2026-04-10] ingest | 养虾日记4：一次「Context Limit Exceeded」错误排查
    13|- Source file: 微信公众号/养虾日记4： 一次「Context Limit Exceeded」错误排查：我以为是小问题，结果踩了大坑.md
    14|- Status: ✅ 成功摄入
    15|- Summary: OpenClaw Telegram Channel「Context Limit Exceeded」错误深度排查——问题表象是 context 耗尽，实际根因是 Telegram channel 的模型被切换为 deepseek-reasoner（仅 16K context），safeguard 模式预留 16K tokens 导致实际可用为 0。解决关键：Agent 级别模型配置优先级高于全局 compaction 配置，需在路由规则层修复。
    16|- Concepts created: [[Context-Window]], [[Model-Fallback]], [[Compaction]], [[Agent-Routing-Rules]], [[Error-Surface-vs-Root-Cause]], [[Layered-Configuration]], [[Log-Driven-Debugging]], [[Hidden-Failure-Paths]]
    17|- Entities created: （无新增；[[OpenClaw]]/[[星枢]]/[[DeepSeek]]/[[MiniMax]] 均已在现有来源中出现，不满足 ≥2 次创建条件）
    18|- Source page: wiki/sources/养虾日记4-一次「context-limit-exceeded」错误排查-我以为是小问题-结果踩了大坑.md
    19|- Notes:
    20|  - 新增 Sources 条目至 index.md（置于养龙虾5天血泪史之后）
    21|  - 更新 overview.md，新增 [[养虾日记4]] 段落至 Multi-Agent AI Systems 部分
    22|  - 创建 8 个 Concept 页面：Context-Window.md、Model-Fallback.md、Compaction.md、Agent-Routing-Rules.md、Error-Surface-vs-Root-Cause.md、Layered-Configuration.md、Log-Driven-Debugging.md、Hidden-Failure-Paths.md
    23|  - 更新 index.md Concepts 节，新增 8 个条目（按字母顺序插入）
    24|  - 与 [[养龙虾5天血泪史]] 互补（记忆写入/压缩问题 vs 模型配置错误）
    25|  - 冲突检测：无与其他 Wiki 页面的实质性内容冲突
    26|
    27|## [2026-04-23] ingest | 养虾日记3：用 Obsidian + Gitea 为 AI 助手构庺持久化笔记系统
    28|- Source file: 微信公众号/养虾日记3：用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统.md
    29|- Status: ✅ 成功摄入
    30|- Summary: 用 Obsidian + Gitea 为 AI 助手构建持久化笔记系统——解决"AI 对话结束输出就消失"的核心问题。核心架构：Obsidian 做知识库（iCloud Drive 三端同步）+ Gitea 做版本控制（Git 历史）+ OpenClaw obsidian skill 做写入接口。核心价值：把 AI 变成"会自动整理笔记的实习生"。融合了 Karpathy 的 LLM Wiki 理念：让 AI 增量构建 Wiki，页面间互链，知识越积越厚。
    31|- Concepts created: [[LLM Wiki]], [[Obsidian Git]], [[Graph View]], [[Obsidian Web Clipper]], [[QMD]], [[版本管理]], [[被动更新]], [[双链笔记]]
    32|- Entities created: [[Obsidian]], [[Gitea]]
    33|- Source page: wiki/sources/养虾日记3-用-obsidian-gitea-为-ai-助手构建持久化笔记系统.md
    34|- Notes:
    35|  - 新增 Sources 条目至 index.md（置于最前）
    36|  - 更新 overview.md，替换原 [[养虾日记1]] 段落为 [[养虾日记3]]
    37|  - 创建 Entity 页面：Obsidian.md, Gitea.md
    38|  - 创建 Concept 页面：LLM-Wiki.md
    39|  - Gitea 已在 Entity 中存在（无需重复创建，仅更新）
    40|  - 冲突：无已知冲突
    41|
    42|## [2026-04-23] ingest | 养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录
    43|- Source file: 微信公众号/养龙虾5天血泪史：我的AI Agent为什么总失忆？OpenClaw 记忆调试全记录.md
    44|- Status: ✅ 成功摄入
    45|- Summary: AI Agent 记忆失效问题的5天专项调试全记录——发现5类根本原因（上下文压缩、搜索后端、检索触发、压缩协同、系统配置），对应10条黄金法则。核心洞察：写入纪律比读取纪律更重要；压缩不是敌人，未写入的上下文才是；系统提示词从209,652精简到9,349令牌（减少28%）。
    46|- Concepts created: 上下文压缩、上下文刷新、写入纪律、交接协议、启动序列
    47|- Entities created: —
    48|- Source page: wiki/sources/养龙虾5天血泪史-我的ai-agent为什么总失忆-openclaw-记忆调试全记录.md
    49|- Notes:
    50|  - 新增 Sources 条目至 index.md（置于养虾日记1、2之后）
    51|  - 更新 overview.md，新增 [[养龙虾5天血泪史]] 段落至养虾日记系列部分
    52|  - 创建 5 个 Concept 页面（上下文压缩/上下文刷新/写入纪律/交接协议/启动序列）
    53|  - Hybrid-Search 概念页面已存在（无需重复创建）
    54|  - 冲突已记录于 source page Contradictions 部分（与 Second Brain 的 MEMORY.md 定位差异、与 personal-crm 的联系人记录方式差异）
    55|
    56|## [2026-04-23] ingest | 养虾日记1：我用 OpenClaw 管了 28 万张照片
    57|- Source file: 微信公众号/养虾日记1：我用 OpenClaw 管了 28 万张照片：一次真实的多设备照片整理实战.md
    58|- Status: ✅ 成功摄入
    59|- Summary: AI Agent 照片整理实战——使用 OpenClaw 成功整理了 NAS 上 28 万张、跨越 20 年的家庭照片。OpenClaw 通过「提问澄清 → 方案制定 → 批次拆分（8 批次）→ Cron 凌晨自动执行 → Telegram Summary 报告」全流程自动化。核心机制：MD5 精确去重 + 小文件清理（<100KB）+ 安全删除策略（To-Be-Deleted 目录）。核心感悟：AI Agent 的价值是思维方式升级。
    60|- Concepts created: —
    61|- Entities created: —
    62|- Source page: wiki/sources/养虾日记1-我用-openclaw-管了-28-万张照片-一次真实的多设备照片整理实战.md
    63|- Notes:
    64|  - 新增 Sources 条目至 index.md（置于最前）
    65|  - 更新 overview.md，新增 [[养虾日记1]] 段落至 Self-Improving 部分，新增 [[AI-Agent思维方式]]/[[批次任务拆分]]/[[精确去重]]/[[小文件清理]]/[[安全删除策略]]/[[Telegram通知]] 至 Key Concepts
    66|  - Entity 数量不足阈值（OpenClaw/Synology Photos/NAS 均已存在或仅出现 1 次），未创建新 Entity 页面
    67|  - Concept 数量不足阈值（所有概念均为本篇特定实践，不满足可抽象/可复用条件），未创建独立 Concept 页面
    68|  - 冲突已记录于 source page Contradictions 部分（与 Self-Healing-Home-Server 的规划者 vs 修复者角色差异）
    69|
    70|## [2026-04-23] ingest | X Account Analysis
    71|- Source file: Agent/usecases/x-account-analysis.md
    72|- Status: ✅ 成功摄入
    73|- Summary: 基于 OpenClaw + Bird Skill 的 X 账号定性分析——通过 Cookie 认证读取真实账号推文，AI 分析内容质量模式（为何有时 1000+ 赞有时 <5 赞）、话题偏好与互动差异原因。免费替代 $10-$50/月订阅服务。
    74|- Concepts created: —
    75|- Entities created: —
    76|- Source page: wiki/sources/x-account-analysis.md
    77|- Notes:
    78|  - 新增 Sources 条目至 index.md（置于最前）
    79|  - 更新 overview.md，新增 [[x-account-analysis]] 段落至 X/Twitter Automation 部分（补充原 x-twitter-automation 段落的互补关系描述）
    80|  - 更新 wiki/sources/x-twitter-automation.md，移除"（尚未摄入）"标注
    81|  - Entity/Concept 数量不足阈值（每项仅在本文中出现 1 次），未创建新实体/概念页面；[[OpenClaw]] 已存在于 Key Entities
    82|  - 新增 Key Concepts: [[Social-Media-Analytics]], [[Credential-Isolation]]
    83|
    84|## [2026-04-23] ingest | Phone Call Notifications
    85|- Source file: Agent/usecases/phone-call-notifications.md
    86|- Status: ✅ 成功摄入
    87|- Summary: AI Agent 通过 clawr.ing 托管电话服务主动向用户拨打电话通知——Agent 评估事件优先级（股价暴跌/紧急邮件/日程提醒），自动拨叫用户真实号码，用户可实时提问，Agent 双向对话响应。与 [[phone-based-personal-assistant]] 互补（Agent 去电通知 vs 用户来电接收）。
    88|- Concepts created: [[Voice Notification Channel]], [[Two-Way Voice Conversation]], [[Call-Worthy Threshold]]
    89|- Entities created: [[clawr.ing]], [[clawhub.ai]] (updated)
    90|- Source page: wiki/sources/phone-call-notifications.md
    91|- Notes:
    92|  - 新增 Sources 条目至 index.md（置于最前）
    93|  - 更新 overview.md，新增 [[phone-call-notifications]] 段落至 AI Tools & Prompt Engineering 部分，新增 [[clawr.ing]]/[[clawhub.ai]] 至 Key Entities，新增 [[Voice Notification Channel]]/[[Two-Way Voice Conversation]]/[[Call-Worthy Threshold]]/[[PSTN Calling]] 至 Key Concepts
    94|  - 新增 Entity: wiki/entities/clawr.ing.md；更新 wiki/entities/ClawHub.md（添加 clawr.ing 作为托管 skill）
    95|  - 新增 Concept: wiki/concepts/Voice-Notification-Channel.md、wiki/concepts/Two-Way-Voice-Conversation.md、wiki/concepts/Call-Worthy-Threshold.md
    96|  - 更新 overview.md Conflict Areas，新增"Agent 去电通知 vs Agent 来电接收"冲突点
    97|
    98|## [2026-04-23] ingest | Autonomous Educational Game Development Pipeline
    99|- Source file: Agent/usecases/autonomous-game-dev-pipeline.md
   100|- Status: ✅ 成功摄入
   101|- Summary: AI Agent 全自动管理教育游戏开发生命周期——"Bugs First" 优先策略 + Round Robin 轮询 + 纯 HTML5/CSS3/JS 技术栈，单人实现每 7 分钟产出 1 款游戏或 1 个 bugfix，41+ 款游戏维护。
   102|- Concepts created: [[Bugs First]], [[Round Robin Strategy]], [[Conventional Commits]], [[Feature Branch Workflow]], [[HTML5 Game Development]]
   103|- Entities created: —
   104|- Source page: wiki/sources/autonomous-game-dev-pipeline.md
   105|- Notes:
   106|  - 新增 Sources 条目至 index.md（置于最前）
   107|  - 更新 overview.md，新增 [[autonomous-game-dev-pipeline]] 段落至 AI Tools & Prompt Engineering 部分
   108|  - Entity/Concept 数量不足阈值，未创建新实体页面；[[OpenClaw]] 实体已存在于 index.md
   109|
   110|## [2026-04-23] ingest | arXiv Paper Reader
   111|- Source file: Agent/usecases/arxiv-paper-reader.md
   112|- Status: ✅ 成功摄入
   113|- Summary: AI Agent 驱动的 arXiv 论文阅读助手——通过 `arxiv-reader` skill（3 工具：`arxiv_fetch`、`arxiv_sections`、`arxiv_abstract`）直接从 arXiv 下载 LaTeX 源码并自动扁平化展开，消除 PDF 下载后切换论文丢失上下文和 LaTeX 符号难以解析的痛点；支持摘要浏览、多论文对比排序、选择性细读和会话式分析；本地缓存使重复访问秒级响应；纯 Node.js 零依赖部署。
   114|- Concepts created: [[arXiv-API]], [[LaTeX-Flattening]], [[Local-Caching]], [[Paper-Abstract-Batch-Fetching]]
   115|- Entities created: [[Prismer-AI]]
   116|- Source page: wiki/sources/arxiv-paper-reader.md
   117|- Notes:
   118|  - 新增 Sources 条目至 index.md（替换 "source missing" placeholder）
   119|  - 更新 overview.md，在 YouTube Automation 部分后新增 [[arXiv-Paper-Reader]] 段落，在 Key Concepts 列表新增 4 个新概念
   120|  - 创建 Entity 页面：Prismer-AI.md（GitHub 组织，`arxiv-reader` skill 维护方）
   121|  - 创建 Concept 页面：arXiv-API.md（arXiv 开放 API）、LaTeX-Flattening.md（LaTeX 扁平化技术）、Local-Caching.md（本地缓存模式）、Paper-Abstract-Batch-Fetching.md（批量摘要对比模式）
   122|  - 与 [[academic-historian]] 同属学术研究场景互补——前者侧重理工科论文，后者侧重人文社科
   123|  - 与 [[YouTube-Content-Pipeline]] 的 Research Agent 共享研究工作流设计模式
   124|  - 冲突检测：无已知实质冲突
   125|
   126|## [2026-04-22] ingest | Semantic Memory Search
   127|- Source file: Agent/usecases/semantic-memory-search.md
   128|- Status: ✅ 成功摄入
   129|- Summary: 通过 memsearch（基于 Milvus 向量数据库）为 OpenClaw Markdown 记忆添加语义搜索能力——用自然语言提问即可找到相关内容，无需精确措辞。混合搜索（稠密向量 + BM25 + RRF）兼顾语义相似性和关键词精确匹配；SHA-256 内容哈希实现增量索引节省成本；文件监视器自动重建索引；支持本地模式无需 API Key。核心理念：Markdown 是唯一真相，向量索引是派生缓存。
   130|- Concepts created: [[Hybrid Search]], [[Reciprocal Rank Fusion]], [[Content Hashing]], [[File Watcher]]
   131|- Entities created: [[memsearch]], [[Milvus]]
   132|- Source page: wiki/sources/semantic-memory-search.md
   133|- Notes:
   134|  - 新增 Sources 条目至 index.md（替换 "source missing" placeholder）
   135|  - 更新 overview.md，在 Productivity & Knowledge Management 部分新增 [[semantic-memory-search]] 段落，在 Key Concepts 列表新增 6 个新概念
   136|  - 创建 Entity 页面：Memsearch.md（ZillizTech memsearch CLI/库）、Milvus.md（开源向量数据库）
   137|  - 创建 Concept 页面：Hybrid-Search.md（混合搜索策略）、Reciprocal-Rank-Fusion.md（排名融合算法）、Content-Hashing.md（增量索引机制）、File-Watcher.md（自动重建索引）
   138|  - 与 [[Knowledge-Base-RAG]] 同属 RAG 技术栈的不同场景——后者侧重 URL 入库，前者侧重现有 Markdown 文件的语义索引
   139|  - 冲突检测：wiki/concepts/Semantic-Search.md 已引用 [[Hybrid Search]]，与本 Source 一致；wiki/concepts/Knowledge-Base-RAG.md 有 Hybrid Search 说明，与本 Source 一致，暂无实质冲突
   140|
   141|## [2026-04-22] ingest | OpenClaw as Desktop Cowork (AionUi) — Remote Rescue & Multi-Agent Hub
   142|- Source file: Agent/usecases/aionui-cowork-desktop.md
   143|- Status: ✅ 成功摄入
   144|- Summary: 通过 AionUi 桌面应用将 OpenClaw 作为可视化 Cowork Agent 运行——提供文件感知工作空间（可见文件读写/命令/网页浏览），内置 OpenClaw 部署专家通过 Telegram/WebUI 远程诊断修复（`openclaw doctor`），统一 MCP 配置全局同步到 12+ Agent，支持 WebUI/Telegram/Lark/DingTalk 多渠道远程访问。
   145|- Concepts created: [[CoworkWorkspace]], [[RemoteRescuePattern]], [[Multi-AgentHub]], [[MCPOnceAllAgents]]
   146|- Entities created: [[AionUi]]
   147|- Source page: wiki/sources/aionui-cowork-desktop.md
   148|- Notes:
   149|  - 新增 Sources 条目至 index.md（替换 "source missing" placeholder）
   150|  - 更新 overview.md，在 AI Tools & Prompt Engineering 部分新增 [[aionui-cowork-desktop]] 段落，在 Key Entities 部分新增 [[AionUi]]，在 Key Concepts 部分新增 4 个新概念
   151|  - 创建实体页面 wiki/entities/AionUi.md
   152|  - 创建概念页面：CoworkWorkspace.md, RemoteRescuePattern.md, Multi-AgentHub.md, MCPOnceAllAgents.md
   153|
   154|## [2026-04-22] ingest | Family Calendar Aggregation & Household Assistant
   155|- Source file: Agent/usecases/family-calendar-household-assistant.md
   156|- Status: ✅ 成功摄入
   157|- Summary: AI Agent 作为家庭日程协调中心——聚合 5+ 个分散日历（工作/个人/家庭/学校/课外）生成每日晨间简报；通过环境消息监控（Ambient Message Monitoring）自动从 iMessage 中识别预约并创建日历事件（含行车时间缓冲）；维护家庭库存 JSON，支持照片 OCR 和小票识别更新；生成购物清单。核心洞察：Ambient > Active，Mac Mini 是最优硬件。
   158|- Concepts created: [[AmbientMessageMonitoring]], [[HouseholdInventoryTracking]]
   159|- Entities created: [[SparkryAI]]
   160|- Source page: wiki/sources/family-calendar-household-assistant.md
   161|- Notes:
   162|  - 新增 Sources 条目至 index.md（替换 "source missing" placeholder）
   163|  - 更新 overview.md，在 AI Tools & Prompt Engineering 部分新增 [[family-calendar-household-assistant]] 段落
   164|  - 新建 Concept 页面：AmbientMessageMonitoring.md（核心差异化机制）、HouseholdInventoryTracking.md（物资追踪模式）
   165|  - 新建 Entity 页面：SparkryAI.md（牙医预约案例的来源）
   166|  - 与 [[Custom Morning Brief]] 互补：同一晨间简报模式，个人场景 vs 家庭场景
   167|  - 与 [[Second Brain]] 共享 OpenClaw 持久记忆能力
   168|  - 冲突检测：暂无发现与其他 Wiki 页面的内容冲突
   169|
   170|## [2026-04-22] ingest | Personal Knowledge Base (RAG)
   171|- Source file: Agent/usecases/knowledge-base-rag.md
   172|- Status: ✅ 成功摄入
   173|- Summary: AI Agent 驱动的个人知识库 RAG 系统——通过 Telegram Topic 或 Slack Channel 投递任意 URL（网页/推文/YouTube 字幕/PDF），Agent 自动抓取内容并以 Embedding 向量入库；支持语义搜索，返回排名结果并附带来源；可被其他工作流（如 [[YouTube-Content-Pipeline]]）主动查询。核心理念：**捕获像发短信一样简单，检索像搜索一样容易**。
   174|- Concepts created: [[Semantic-Search]], [[Content-Ingestion]]
   175|- Source page: wiki/sources/knowledge-base-rag.md
   176|- Notes:
   177|  - 新增 Sources 条目至 index.md（替换 "source missing" placeholder）
   178|  - 更新 overview.md，在 Productivity & Knowledge Management 部分新增 [[Personal Knowledge Base (RAG)]] 段落
   179|  - 与 [[Second Brain]] 互补：Second Brain 侧重对话记忆，本方案侧重结构化知识检索
   180|  - 与 [[YouTube-Content-Pipeline]] 关联：后者在工作流中主动查询知识库
   181|  - [[Knowledge-Base-RAG]] 概念页已存在（2026-04-22 youtube-content-pipeline ingest 时创建），本次补充 Semantic-Search 和 Content-Ingestion 两个子概念
   182|  - Entity 页面（OpenClaw、ClawHub、Telegram、Slack）均已在 overview.md Key Entities 中覆盖，无需新建
   183|  - Contradiction：暂无发现与其他 Wiki 页面的内容冲突
   184|- Status: ✅ 成功摄入
   185|- Summary: AI Agent 驱动的 YouTube 选题发现与选题自动化流水线——每小时 Cron Job 扫描 Web + X/Twitter 突发 AI 新闻，向 Telegram 推送选题；维护 90 天视频目录（播放量 + 主题分析）避免选题重复；通过 SQLite 向量嵌入实现语义去重；在 Slack 分享链接时自动研究主题、搜索 X、查询知识库并创建带大纲的 Asana 任务卡。
   186|- Concepts created: [[Semantic-Deduplication]], [[Vector-Embedding]], [[Knowledge-Base-RAG]]
   187|- Source page: wiki/sources/youtube-content-pipeline.md
   188|- Notes:
   189|  - 新增 Sources 条目至 index.md（替换 "source missing" placeholder）
   190|  - 更新 overview.md，在 YouTube Automation 部分新增 [[YouTube-Content-Pipeline]] 段落
   191|  - 与 [[Daily-YouTube-Digest]] 互补：后者侧重订阅频道更新监控，前者侧重全网趋势主动发现
   192|  - 与 [[Content-Factory]] 共享并行子 Agent 执行模式
   193|  - Entity 页面（OpenClaw、Asana、Slack）均已存在，无需新建
   194|  - 新增 3 个 Concept 页面并注册至 index.md Concepts 索引
   195|  - Contradiction：暂无发现与其他 Wiki 页面的内容冲突
   196|- Source file: Agent/usecases/polymarket-autopilot.md
   197|- Status: ✅ 成功摄入
   198|- Summary: 基于 AI Agent 的 Polymarket 预测市场自动驾驶交易系统，实现 24/7 市场监控与自动化分析。AI Agent 自动监控 Polymarket 市场数据、智能分析预测概率变化、自动执行交易策略、定时推送市场洞察。
   199|- Concepts created: [[Prediction Market]], [[Agentic Trading]], [[Market Monitoring]]
   200|- Entities created: [[Polymarket]]
   201|- Source page: wiki/sources/polymarket-autopilot.md
   202|- Notes:
   203|  - 新增 Sources 条目至 index.md（替换 placeholder）
   204|  - 更新 overview.md，在 Multi-Agent Monitoring 部分的 Dynamic Dashboard 段落中补充 polymarket-autopilot 引用
   205|  - 与 [[Dynamic Dashboard]] 存在关联（监控仪表盘的具体用例）
   206|  - 与 [[earnings-tracker]] 属于同类模式（市场数据监控 + 定时推送）
   207|  - Polymarket 已在 overview.md Key Entities 中提及，无需重复创建 Entity 页面
   208|  - Contradiction：暂无发现与其他 Wiki 页面的内容冲突
   209|
   210|## [2026-04-22] ingest | Local CRM Framework with DenchClaw
   211|- Source file: Agent/usecases/local-crm-framework.md
   212|- Status: ✅ 成功摄入
   213|- Summary: DenchClaw 将 OpenClaw 转化为本地 CRM、销售自动化和生产力平台，通过 `npx denchclaw` 一键安装完整技术栈（DuckDB + Web UI + OpenClaw Profile + 浏览器自动化）。核心创新：所有设置/视图以 YAML/Markdown 文件存储，Agent 可直接修改 UI 而无需 API 抽象层；Chrome Profile 克隆使 Agent 继承用户认证状态，可直接导入 HubSpot 等平台数据。
   214|- Concepts created: [[File-System-First-UI]], [[DuckDB]]
   215|- Entities created: [[DenchClaw]]
   216|- Source page: wiki/sources/local-crm-framework.md
   217|- Notes:
   218|  - 新增 Sources 条目至 index.md（置于首位）
   219|  - 更新 overview.md，在 [[personal-crm]] 附近添加 Local CRM Framework 段落
   220|  - 创建 1 个 Entity 页面：DenchClaw.md
   221|  - 创建 2 个 Concept 页面：DuckDB.md、File-System-First-UI.md
   222|  - 与 [[Second Brain]] 均基于 OpenClaw 的记忆/持久化能力，属同类应用的不同垂直场景
   223|  - 与 [[personal-crm]] 同属个人 CRM 场景的不同实现方案
   224|  - 与 [[multi-channel-assistant]] 共享 Telegram/消息平台作为交互入口
   225|  - 核心设计哲学：文件系统即 Agent 原生 UI + DuckDB 嵌入式数据库 + Chrome Profile 克隆
   226|  - Contradiction：暂无发现与其他 Wiki 页面的内容冲突
   227|
   228|## [2026-04-22] ingest | Goal-Driven Autonomous Tasks
   229|- Source file: Agent/usecases/overnight-mini-app-builder.md
   230|- Status: ✅ 成功摄入
   231|- Summary: AI Agent 从被动执行者转变为主动规划者的目标驱动型自主任务系统。通过 Brain Dump 一次性倾倒所有目标，OpenClaw 每日清晨自动生成 4-5 个贴近目标的自主任务（研究/写作/MVP构建），通过 Next.js Kanban 看板实时追踪。核心价值：用户定义目的地，Agent 自动分解并执行每日步骤。还包含过夜惊喜 Mini-App 构建模式。核心工程实践：Git-style append-only 日志解决多 Agent 竞态条件；Token-Light Design 保持 AUTONOMOUS.md 在 50 行以内。
   232|- Concepts created: [[Sub-Agent-Race-Condition]], [[Token-Light-Design]], [[Brain-Dump]]
   233|- Entities created: （无新增，[[OpenClaw]]/[[Alex Finn]]/[[Next.js]] 均已存在）
   234|- Source page: wiki/sources/overnight-mini-app-builder.md
   235|- Notes:
   236|  - 新增 Sources 条目至 index.md（替换 placeholder，原标题为 overnight-mini-app-builder）
   237|  - 更新 overview.md，将 Market Research & Product Factory 段落替换为 Goal-Driven Autonomous Tasks 段落，补充 Git-style append-only 模式和 Token-Light Design 洞察
   238|  - 更新 Alex-Finn.md，将 overnight-mini-app-builder 添加至 sources
   239|  - 创建 3 个 Concept 页面：Sub-Agent-Race-Condition.md、Token-Light-Design.md、Brain-Dump.md
   240|  - 与 [[Project State Management]] 的看板 vs 事件溯源存在潜在冲突（已记录于 Source Page Contradictions）
   241|  - 与 [[market-research-product-factory]] 同属 Alex Finn 启发的 OpenClaw 高阶用法，前者侧重任务追踪和持续执行，后者侧重产品机会发现
   242|
   243|## [2026-04-17] ingest | Habit Tracker & Accountability Coach
   244|- Source file: Agent/usecases/habit-tracker-accountability-coach.md
   245|- Status: ✅ 成功摄入
   246|- Summary: AI Agent 作为主动问责伙伴，通过 Telegram/SMS 每日定时签到，替代被动习惯追踪 App。核心机制：主动问责 + 连续打卡追踪 + 自适应语气 + 每周模式分析。关键洞察：主动询问比被动记录更能驱动行为改变；保持 3-5 个习惯可避免签到疲劳；[[Adaptive Tone]] 自适应语气是关键差异化因素。
   247|- Concepts created: [[Adaptive-Tone]], [[Active-Accountability]], [[Streak-Tracking]], [[Check-in-Fatigue]], [[Weekly-Pattern-Analysis]]
   248|- Entities created: （无新增，[[Telegram Bot API]]/[[Twilio]]/[[Google Sheets API]] 各仅出现 1 次，不满足≥2次创建条件；[[OpenClaw]] 已存在）
   249|- Source page: wiki/sources/habit-tracker-accountability-coach.md
   250|- Notes:
   251|  - 新增 Sources 条目至 index.md（替换 placeholder）
   252|  - 更新 overview.md，添加 Habit Tracker & Accountability Coach 段落，补充 [[Adaptive Tone]], [[Active Accountability]], [[Streak Tracking]], [[Check-in Fatigue]], [[Weekly Pattern Analysis]] 至 Key Concepts
   253|  - 创建 5 个 Concept 页面：Adaptive-Tone.md、Active-Accountability.md、Streak-Tracking.md、Check-in-Fatigue.md、Weekly-Pattern-Analysis.md
   254|  - 已有相关 Concept：[[Scheduled-Reminder]]（定时签到技术基础）、[[Agent-Personality]]（Adaptive Tone 的上层设计）、[[Morning Briefing]]（同一 Cron + AI 推送模式）、[[Food-Sensitivity-Tracking]]（同一框架的不同垂直场景）
   255|  - 已有相关 Entity：[[OpenClaw]]（底层运行平台）
   256|  - 与 [[Health & Symptom Tracker]] 属同一框架（OpenClaw + Telegram + Cron Job + 每周分析），但垂直于个人习惯养成
   257|  - Contradiction：与[[Todoist Task Manager]] 同属 OpenClaw 生产力工具集，但 Todoist 侧重任务管理，Habit Tracker 侧重个人行为改变——不冲突，属于互补关系
   258|  - 与传统习惯 App（Streaks/Habitica）的对比：传统 App 强调被动记录和视觉激励；本方案强调主动询问和个性化文字激励
   259|
   260|## [2026-04-22] ingest | Todoist Task Manager
   261|- Source file: Agent/usecases/todoist-task-manager.md
   262|- Status: ✅ 成功摄入
   263|- Summary: AI Agent 通过 Todoist API 实现自然语言驱动的任务管理自动化——Agent 解析自然语言指令 → Todoist REST API 创建结构化任务（含截止/项目/标签）→ Cron Job 定时扫描逾期任务主动推送提醒。核心价值：用户只需发一条消息即可完成全套操作，AI 主动追踪逾期任务。
   264|- Concepts created: [[Todoist API]], [[AI-Driven Task Extraction]], [[Recurring Tasks]]
   265|- Entities created: （无新增，[[Todoist]]/[[OpenClaw]]/[[SuperCall]] 已存在）
   266|- Source page: wiki/sources/todoist-task-manager.md
   267|- Notes:
   268|  - 新增 Sources 条目至 index.md（替换 placeholder）
   269|  - 更新 overview.md，添加 Todoist Task Manager 段落，补充 [[Morning Briefing]], [[Todoist API]], [[AI-Driven Task Extraction]], [[TaskAutomation]], [[Recurring Tasks]] 至 Key Concepts
   270|  - 更新 entities/Todoist.md，添加 todoist-task-manager 至 sources
   271|  - 创建 3 个 Concept 页面：Todoist-API.md、AI-Driven-Task-Extraction.md、Recurring-Tasks.md
   272|  - [[Project State Management]] 冲突记录：Todoist（结构化字段/API驱动）与 Markdown 事件流（完整上下文/自托管）各有适用场景
   273|  - 与 [[multi-channel-assistant]] 中 Todoist 集成属同一技术栈，侧重不同：前者侧重多渠道统一入口，后者侧重任务管理深度自动化
   274|
   275|## [2026-04-22] ingest | Dynamic Dashboard with Sub-agent Spawning
   276|- Source file: Agent/usecases/dynamic-dashboard.md
   277|- Status: ✅ 成功摄入
   278|- Summary: 基于子代理并行执行的多数据源实时监控仪表盘——通过子代理并行抓取 GitHub/Twitter/Polymarket/系统健康等多数据源，定时聚合结果推送 Discord，支持告警阈值和历史趋势存储。用对话式指令替代数周前端开发，立即获得实时洞察。
   279|- Concepts created: [[Dynamic-Dashboard]], [[Alerting]]
   280|- Entities created: （无新增，[[OpenClaw]] 已存在）
   281|- Source page: wiki/sources/dynamic-dashboard.md
   282|- Notes:
   283|  - 新增 Sources 条目至 index.md（插入顶部）
   284|  - 更新 overview.md，添加 Multi-Agent Monitoring & Automation 段落，补充 [[Dynamic-Dashboard]] 和 [[Alerting]] 至 Key Concepts
   285|  - 创建 2 个 Concept 页面：Dynamic-Dashboard.md、Alerting.md
   286|  - 已有相关 Concept：[[Parallel-Agent-Execution]]（子代理并行）、[[Scheduled-Task-Flywheel]]（定时任务）
   287|  - 已有相关 Entity：[[OpenClaw]]（多代理框架）
   288|  - 冲突：与 [[content-factory]] 存在场景重叠（并行执行模式），但前者侧重数据监控，后者侧重内容创作
   289|
   290|## [2026-04-22] ingest | Pre-Build Idea Validator
   291|- Source file: Agent/usecases/pre-build-idea-validator.md
   292|- Status: ✅ 成功摄入
   293|- Summary: AI 项目启动前的竞争分析门控机制——在写代码之前通过 idea-reality-mcp 扫描 GitHub/Hacker News/npm/PyPI/Product Hunt 五个数据源，返回 reality_signal 分数（0-100）评估赛道拥挤度，防止 Agent 在已饱和赛道投入资源。
   294|- Concepts created: [[Pre-Build Validation]], [[Reality-Signal]], [[Competition-Analysis]], [[Pivot-Strategy]], [[Agent-Build-Gate]]
   295|- Entities created: [[idea-reality-mcp]]
   296|- Source page: wiki/sources/pre-build-idea-validator.md
   297|- Notes:
   298|  - 新增 Sources 条目至 index.md（插入顶部）
   299|  - 更新 overview.md，添加 pre-build-idea-validator 段落并补充 4 个新概念至 Key Concepts
   300|  - 创建 5 个 Concept 页面：Pre-Build-Validation.md、Reality-Signal.md、Competition-Analysis.md、Pivot-Strategy.md、Agent-Build-Gate.md
   301|  - 创建 1 个 Entity 页面：idea-reality-mcp.md
   302|  - Hacker-News 和 Product-Hunt 仅出现 1 次，不满足 ≥2 次的 Entity 创建阈值，未创建
   303|  - 与 market-research-product-factory 互补：后者挖痛点找方向，前者在动手前验证赛道的竞争密度
   304|  - 冲突：无
   305|
   306|## [2026-04-22] ingest | Autonomous Project Management with Subagents
   307|- Source file: Agent/usecases/autonomous-project-management.md
   308|- Status: ✅ 成功摄入
   309|- Summary: 去中心化多 Agent 项目协调模式——通过共享 STATE.yaml 实现并行自主执行，主会话遵循 CEO 模式（仅做策略决策），Git 作为审计日志记录所有状态变更。核心洞察：文件协调优于中心编排器，主会话越薄响应越快。
   310|- Concepts created: [[PM Delegation Pattern]], [[CEO Pattern]], [[Shared State Coordination]], [[Git-as-Audit-Log]]
   311|- Entities created: [[Nicholas Carlini]]
   312|- Source page: wiki/sources/autonomous-project-management.md
   313|- Notes:
   314|  - 新增 Sources 条目至 index.md（插入顶部）
   315|  - 更新 overview.md，添加 4 个新概念至 Key Concepts
   316|  - 创建 4 个 Concept 页面：PMDelegationPattern.md、CEOPattern.md、SharedStateCoordination.md、GitAsAuditLog.md
   317|  - 创建 1 个 Entity 页面：NicholasCarlini.md
   318|  - 冲突记录：与 [[project-state-management]] 的任务管理范式冲突（动态文件 vs 静态看板）
   319|  - Nicholas Carlini 未在原 Wiki 中出现，作为启发来源创建 Entity 页面
   320|
   321|- Source file: Agent/usecases/daily-reddit-digest.md
   322|- Status: ✅ 成功摄入
   323|- Summary: AI Agent 驱动的 Reddit 每日精选摘要自动化——通过 OpenClaw + reddit-readonly skill，每日定时抓取多 Subreddit 热门帖子，AI 记忆偏好持续优化规则，纯读取模式无需认证。
   324|- Concepts created: [[Daily-Digest]], [[Reddit Read-Only]], [[Preference Learning]]
   325|- Entities created: [[reddit-readonly]]
   326|- Source page: wiki/sources/daily-reddit-digest.md
   327|- Notes:
   328|  - 更新 index.md，替换缺失标记为正式条目
   329|  - 更新 overview.md，添加至 YouTube Automation / Daily Digest 章节
   330|  - OpenClaw Entity 页面已存在，无需新建
   331|  - Preference Learning Concept 已在 inbox-declutter 中引用，无需新建
   332|
   333|## [2026-04-22] ingest | Inbox De-clutter
   334|- Source file: Agent/usecases/inbox-declutter.md
   335|- Status: ✅ 成功摄入
   336|- Summary: AI Agent 每日自动整理 Newsletter 邮件摘要——通过 Cron Job 每日 20:00 阅读过去 24 小时 Newsletter 新邮件，生成精华摘要并附链接，根据用户反馈持续学习偏好。需前置 Gmail OAuth Setup。
   337|- Concepts created: [[Email Triage]], [[Newsletter Digest]], [[Preference Learning]]
   338|- Entities created: [[Gmail OAuth]]
   339|- Source page: wiki/sources/inbox-declutter.md
   340|- Notes:
   341|  - 新增 Sources 条目至 index.md（插入顶部）
   342|  - 更新 overview.md，添加 inbox-declutter 描述段落（作为 [[custom-morning-brief]] 的相似模式）
   343|  - 创建 Concept 页面：Email-Triage.md、Newsletter-Digest.md、Preference-Learning.md
   344|  - 创建 Entity 页面：Gmail-OAuth.md
   345|  - 与 [[custom-morning-brief]] 属同一 Cron Job + AI 摘要模式的不同垂直场景
   346|  - 冲突：无
   347|
   348|## [2026-04-22] ingest | Market Research & Product Factory
   349|- Source file: Agent/usecases/market-research-product-factory.md
   350|- Status: ✅ 成功摄入
   351|- Summary: AI Agent 驱动的"从市场调研到产品构建"全自动化流水线——通过 Last 30 Days skill 挖掘 Reddit 和 X 近30天真实用户痛点，OpenClaw 根据痛点构建 Web 应用 MVP。核心价值：发短信即可完成"发现问题→验证需求→构建方案"全流程，无需技术背景。
   352|- Concepts created: [[Pain Point Mining]], [[Startup MVP Pipeline]], [[Agent-Driven Market Research]], [[Last 30 Days Method]]
   353|- Source page: wiki/sources/market-research-product-factory.md
   354|- Notes:
   355|  - 新增 Sources 条目至 index.md
   356|  - 更新 overview.md，添加 Market Research & Product Factory 描述段落
   357|  - 添加 Pain Point Mining、Startup MVP Pipeline、Agent-Driven Market Research、Last 30 Days Method 到 Key Concepts
   358|  - Alex Finn 出现2次（content-factory + market-research），但按出现频次标准不满足 Entity 创建条件，跳过
   359|  - Matt Van Horne 仅出现1次，跳过 Entity 页面创建
   360|  - 冲突：无已知冲突
   361|
   362|## [2026-04-22] ingest | Phone-Based Personal Assistant
   363|- Source file: Agent/usecases/phone-based-personal-assistant.md
   364|- Status: ✅ 成功摄入
   365|- Summary: 通过 ClawdTalk + Telnyx 将任意手机变成 AI 助理语音入口——拨打电话即可与 OpenClaw 对话，支持日历查询、Jira 任务更新、网络搜索，无需智能手机 App 或浏览器，覆盖驾驶、步行等双手占用场景。与 [[multi-channel-assistant]] 互补：文字入口覆盖图文交互，语音入口覆盖无屏场景。
   366|- Concepts created: [[Voice Interface]], [[Telephony Integration]]
   367|- Entities created: [[ClawdTalk]], [[Telnyx]]
   368|- Source page: wiki/sources/phone-based-personal-assistant.md
   369|- Notes:
   370|  - 新增 Sources 条目至 index.md（插入 Multi-Channel Personal Assistant 之后）
   371|  - 更新 overview.md，添加 phone-based-personal-assistant 描述段落，添加 Voice Interface、Telephony Integration 到 Key Concepts
   372|  - 创建 2 个 Entity 页面：ClawdTalk.md、Telnyx.md
   373|  - 创建 2 个 Concept 页面：Voice-Interface.md、Telephony-Integration.md
   374|  - 冲突已记录（已在 overview.md Conflict Area #10）：[[phone-based-personal-assistant]] 通用语音 Agent vs [[event-guest-confirmation]] SuperCall 沙盒 Persona
   375|
   376|## [2026-04-22] ingest | Event Guest Confirmation
   377|- Source file: Agent/usecases/event-guest-confirmation.md
   378|- Status: ✅ 成功摄入
   379|- Summary: 基于 OpenClaw + SuperCall 的活动嘉宾自动确认方案——通过 AI 语音电话批量外呼客人，确认出席状态并收集备注（饮食禁忌、Plus-One、到达时间等），通话完成后生成出席确认/未出席/未接听三分类摘要。核心价值：真人电话比短信回复率高；SuperCall 沙盒 persona 设计确保安全隔离，无 Prompt Injection 风险；每通电话独立重置，无对话间信息混淆。
   380|- Concepts created: [[Sandboxed Persona]]
   381|- Entities created: （无新实体；OpenClaw 已在其他来源中出现）
   382|- Source page: wiki/sources/event-guest-confirmation.md
   383|- Notes:
   384|  - 新增 Sources 条目至 index.md（插入 Multi-Channel Personal Assistant 之后）
   385|  - 更新 overview.md，添加 AI Tools & Productivity 小节描述
   386|  - 更新 overview.md Conflict Area #10，添加 SuperCall 沙盒 Persona vs 通用语音 Agent 对比
   387|  - 创建 1 个 Concept 页面：Sandboxed-Persona.md
   388|
   389|## [2026-04-22] ingest | Multi-Channel Personal Assistant
   390|- Source file: Agent/usecases/multi-channel-assistant.md
   391|- Status: ✅ 成功摄入
   392|- Summary: 基于 Telegram Topic 路由 + OpenClaw 的多渠道个人助理方案——以 Telegram 为统一入口，通过 Topic 隔离不同上下文（config/updates/video-ideas/personal-crm/earnings/knowledge-base），整合 Google Workspace（gog）、Slack、Todoist、Asana，实现"说一句话完成全套工作"。核心价值：消除应用切换疲劳，AI 主动推送定时提醒。
   393|- Concepts created: [[Topic-Based Routing]], [[Scheduled Reminder]]
   394|- Entities created: [[Asana]], [[gog]]
   395|- Source page: wiki/sources/multi-channel-assistant.md
   396|- Notes: 与 [[multi-agent-team]] 存在互补关系——Multi-Agent Team 为底层专业化分工，Multi-Channel Assistant 为用户交互层。
   397|
   398|## [2026-04-22] ingest | Project State Management System: Event-Driven Alternative to Kanban
   399|- Source file: Agent/usecases/project-state-management.md
   400|- Status: ✅ 成功摄入
   401|- Summary: 用事件驱动系统替代传统看板——自然语言对话自动记录项目事件（progress/blocker/decision/pivot），PostgreSQL/SQLite 存储完整事件历史，Git 提交自动关联项目，每日 Cron 生成站会报告。消灭手动拖拽卡片的摩擦，保留完整决策上下文，让项目状态查询和每日站会自动化。
   402|- Concepts created: [[Event Sourcing]], [[Project State]]
   403|- Entities created: （无新实体；OpenClaw 已存在于多个来源中，无需独立 Entity 页面）
   404|- Source page: wiki/sources/project-state-management.md
   405|- Notes:
   406|  - 新增 Sources 条目至 index.md（插入 Sources 首行）
   407|  - 更新 overview.md Conflict Area #1，扩展 Kanban vs Event Sourcing 对比描述
   408|  - 创建 2 个 Concept 页面：EventSourcing.md、ProjectState.md
   409|  - 冲突已记录：Event Sourcing（自动追踪+上下文保留）vs Kanban（可视化协作+团队同步）
   410|- Source file: Agent/usecases/health-symptom-tracker.md
   411|- Status: ✅ 成功摄入
   412|- Summary: 通过 Telegram 话题 + OpenClaw AI Agent 自动追踪食物与症状，实现食物敏感性识别。每日三餐定时提醒（8AM/1PM/7PM）确保日志一致性，OpenClaw 自动解析消息并带时间戳写入 Markdown 日志，每周日分析关联模式识别潜在触发因素。无需专用 App，完全自托管。
   413|- Concepts created: [[Food Sensitivity Tracking]], [[Automated Health Logging]]
   414|- Entities created: （无新实体；OpenClaw 实体已存在）
   415|- Source page: wiki/sources/health-symptom-tracker.md
   416|- Notes:
   417|  - 新增 Sources 条目至 index.md（插入首行）
   418|  - 新增健康追踪主题至 overview.md
   419|  - 冲突记录：与 habit-tracker-accountability-coach 的习惯追踪 vs 健康数据追踪侧重对比
   420|
   421|
   422|## [2026-04-22] ingest | Second Brain
   423|- Source file: Agent/usecases/second-brain.md
   424|- Status: ✅ 成功摄入
   425|- Summary: AI Agent 作为个人第二大脑的记忆捕获与检索系统——通过短信/Telegram/Discord 零摩擦捕获任何内容，OpenClaw 永久记忆存储，Next.js 可搜索仪表盘提供全局检索。核心洞见：捕获像发短信一样简单，检索像搜索一样简单。灵感来源：Alex Finn YouTube 视频 + Tiago Forte《Building a Second Brain》。
   426|- Concepts created: [[Zero-Friction Capture]], [[Cumulative Memory]], [[Conversational Interface]], [[Text-and-Search]]
   427|- Entities created: [[Tiago Forte]]
   428|- Entities updated: [[OpenClaw]]（追加 second-brain 到 sources）, [[Alex Finn]]（追加 second-brain 到 sources）
   429|- Source page: wiki/sources/second-brain.md
   430|- Notes:
   431|  - 新增 Sources 条目至 index.md（替换 placeholder）
   432|  - 更新 overview.md，添加 Second Brain 段落，补充 4 个新概念至 Key Concepts
   433|  - 创建 4 个 Concept 页面：Zero-Friction-Capture.md、Cumulative-Memory.md、Conversational-Interface.md、Text-and-Search.md
   434|  - 创建 1 个 Entity 页面：Tiago-Forte.md
   435|  - 与 [[dataview-让我从"笔记黑洞"里逃出来的-obsidian-神器-1]] 存在冲突记录：Obsidian + Dataview（结构化查询）vs Second Brain（极简搜索）——互补而非互斥
   436|  - 与 [[custom-morning-brief]] 和 [[self-healing-home-server]] 属相似模式（零摩擦信息捕获 + AI 主动管理），已记录为 Connections
   437|  - 与 [[habit-tracker-accountability-coach]] 的互补关系：Second Brain 管理想法/链接/书目，Habit Tracker 管理习惯行为——场景不同但方法论相似
   438|  - 冲突检测：无与其他已摄入来源的实质性内容冲突
   439|
   440|
   441|- Status: ✅ 成功摄入
   442|- Summary: AI Agent 作为家庭服务器基础设施的全天候自动驾驶代理——OpenClaw + SSH + Cron Job 系统实现自动健康监控、故障自愈（重启 Pod/扩缩容/修复配置）、邮件分拣、每日 8AM 晨报（天气/日历/系统状态/看板）、知识库录入和安全审计。核心洞察：Cron Job 是真正的产品；知识提取具有复利效应；AI 会硬编码 secrets，TruffleHog pre-push hooks 是必须配置的防线；Local-first Git 是防止 API Key 暴露的架构基础。
   443|- Concepts created: [[Morning Briefing]], [[Email Triage]], [[Local-first Git]], [[Defense-in-Depth]]
   444|- Entities created: [[K3s]], [[Gitea]], [[TruffleHog]]
   445|- Entities updated: [[OpenClaw]]（追加 self-healing-home-server 到 sources）
   446|- Source page: wiki/sources/self-healing-home-server.md
   447|- Notes:
   448|  - 新增 Sources 条目至 index.md（替换缺失条目）
   449|  - 更新 overview.md，添加 "Self-Healing Infrastructure Agent" 章节
   450|  - 创建 3 个 Entity 页面：K3s.md、Gitea.md、TruffleHog.md
   451|  - 创建 4 个 Concept 页面：Morning-Briefing.md、Email-Triage.md、Local-first-Git.md、Defense-in-Depth.md
   452|  - 冲突已记录：Prometheus/Grafana 监控方案（人工介入）vs AI Agent 自愈方案（全自动闭环）
   453|
   454|## [2026-04-22] ingest | AI-Powered Earnings Tracker
   455|- Source file: Agent/usecases/earnings-tracker.md
   456|- Status: ✅ 成功摄入
   457|- Summary: AI Agent 自动化追踪科技公司财报——每周日 Cron Job 扫描财报日历并通过 Telegram 推送，用户选择后为每家公司创建一次性 Cron Job，财报发布后自动搜索结果并生成结构化摘要（beat/miss、营收、EPS、AI 亮点）。
   458|- Concepts created: （无新概念；Cron Job 已在其他来源中建立）
   459|- Entities created: （无新实体；OpenClaw 已存在；科技公司 NVDA/MSFT 等无需独立页面）
   460|- Source page: wiki/sources/earnings-tracker.md
   461|- Notes:
   462|  - 新增 Sources 条目至 index.md（插入首行）
   463|  - 无需更新 overview.md（与现有 OpenClaw + Cron Job 主题一致）
   464|  - 无需创建 Entity/Concept 页面
   465|  - 无冲突
   466|
   467|## [2026-04-23] ingest | Multi-Agent Specialized Team (Solo Founder Setup)
   468|- Source file: Agent/usecases/multi-agent-team.md
   469|- Status: ✅ 成功摄入
   470|- Summary: 用多个专业化 AI Agent 组建团队，解决一人创业者（Solo Founder）身兼数职的困境——4 个专业 Agent（Milo/策略、Josh/商业、Marketing/营销、Dev/开发）通过共享记忆 + 私有上下文 + Telegram 单一控制平面协调运作，定时任务驱动主动工作流。
   471|- Concepts created: [[Agent Personality]], [[Agent Specialization]], [[Shared Memory Architecture]], [[Private Context]], [[Single Control Plane]], [[Scheduled Task Flywheel]], [[Parallel Agent Execution]]
   472|- Entities updated: [[OpenClaw]]（追加 multi-agent-team 到 sources）
   473|- Source page: wiki/sources/multi-agent-team.md
   474|- Notes:
   475|  - 新增 Sources 条目至 index.md（插入首行）
   476|  - 更新 overview.md Key Concepts，添加 5 个新概念
   477|  - 创建 6 个 Concept 页面
   478|  - 更新 OpenClaw.md sources 字段
   479|  - 冲突已记录：Multi-Agent Team（并行专业化分工）vs Content Factory（链式协作）
   480|
   481|## [2026-04-23] ingest | Daily YouTube Digest
   482|- Source file: Agent/usecases/daily-youtube-digest.md
   483|- Status: ✅ 成功摄入
   484|- Summary: AI Agent 每日 YouTube Digest 全自动流水线——通过 youtube-full skill（ClawHub）监控订阅频道新视频，用 TranscriptAPI.com 提取字幕，AI 生成要点摘要后推送。两种模式：频道列表 + 关键词搜索。`channel/latest` 免费检查，`seen-videos.txt` 避免重复付费。核心洞察：把算法推荐的"被动消费"转变为系统化的"主动学习"。
   485|- Concepts created: [[Daily-Digest]], [[Transcript-Based Summarization]], [[Channel-Based Monitoring]], [[Keyword-Based Monitoring]], [[Credit-Efficient Processing]]
   486|- Entities updated: [[OpenClaw]]（追加 sources）
   487|- Entities created: [[TranscriptAPI.com]], [[ClawHub]], [[Recapio]]
   488|- Source page: wiki/sources/daily-youtube-digest.md
   489|- Notes:
   490|  - 新增 Sources 条目至 index.md（顶部插入）
   491|  - 更新 overview.md，补充 AI-Powered Daily Digest 章节到 YouTube Automation
   492|  - 更新 OpenClaw.md sources
   493|  - 创建 3 个 Entity 页面：TranscriptAPI.com.md、ClawHub.md、Recapio.md
   494|  - 创建 5 个 Concept 页面：Daily-Digest.md、Transcript-Based-Summarization.md、Channel-Based-Monitoring.md、Keyword-Based-Monitoring.md、Credit-Efficient-Processing.md
   495|  - 与 [[实战笔记-本地部署-rsshub-并获取-youtube-订阅]] 的互补关系已在 Contradictions 节记录（RSSHub 被动监控 vs AI Digest 主动学习）
   496|
- Source file: Agent/usecases/meeting-notes-action-items.md
- Status: ✅ 成功摄入
- Summary: AI Agent 将会议转录文本（Otter.ai、Google Meet、Zoom）自动转换为结构化摘要，提取行动项并创建 Jira/Linear/Todoist/Notion 任务，发送 Slack/Discord 摘要，支持截止日提醒。核心洞察：自动任务创建比摘要本身更有价值，无法转化为追踪任务的会议记录只是"文档剧场"。
- Concepts created: [[MeetingNotes]], [[ActionItemTracking]], [[TaskAutomation]], [[TranscriptProcessing]]

## [2026-04-23] ingest | 14个免费的AI图生视频工具，用AI让图片动起来
- Source file: AI/14个免费的AI图生视频工具，用AI让图片动起来 - AI视频教程  AI自动化工作流定制服务  AI培训学习平台  黑喵大叔.md
- Status: ✅ 成功摄入
- Summary: 14个免费AI图生视频工具盘点——覆盖阿里巴巴（绘蛙、通义万相、万相营造）、字节跳动（即梦AI）、快手（可灵AI）、智谱AI（智谱清影）、MiniMax（海螺AI）、生数科技（Vidu）、爱诗科技（PixVerse）、潞晨科技（Video Ocean）、智象未来（Viva）、MewXAI（艺映AI）、Stability AI（Stable Video）等厂商。核心能力：文本提示词控制、动作模板、运镜参数、首尾帧控制、主体一致性、音效自动生成。电商/视频创作/广告三大应用场景。
- Concepts created: [[AI图生视频]], [[AI文生视频]], [[主体一致性]], [[运镜控制]], [[首尾帧控制]], [[提示词控制]]
- Entities created: 14个工具均作为 Key Entities 记录于 Source 页面
- Source page: wiki/sources/14个免费的ai图生视频工具-用ai让图片动起来-ai视频教程-ai自动化工作流定制服务-ai培训学习平台-黑喵大叔.md
- Notes:
  - 更新 index.md，修正条目日期为 2025-12-05 并补充摘要描述
  - 更新 overview.md，新增 AI图生视频工具盘点章节
  - 创建 Concept 页面：AI图生视频.md、AI文生视频.md
  - 所有14个工具作为 Key Entities 记录于 Source 页面，未创建独立 Entity 页面（每个工具仅出现1次，未达≥2阈值）
  - Contradictions：无冲突

## [2026-04-23] ingest | 文字生成视频网站推荐
- Source file: AI/文字生成视频网站推荐.md
- Status: ✅ 成功摄入
- Summary: 5款文字生成视频AI工具推荐——万彩AI（完全免费，适合新手）、百度AI开放平台（大厂多模态技术）、Zeemo（多语言字幕，$79+）、Vizard（长视频自动剪辑）、快影（腾讯系模板剪辑）。总结推荐：最实惠选万彩AI，技术型选百度，多语言选Zeemo，长视频选Vizard。
- Concepts created: [[文字生成视频]], [[AI视频生成工具]], [[数字人]]
- Source page: wiki/sources/文字生成视频网站推荐.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - overview.md 中已存在与 [[AI图生视频工具盘点]] 的互补关系说明，无需更新
  - 所有工具作为 Key Entities 记录于 Source 页面，未创建独立 Entity 页面（每个工具仅出现1次，未达≥2阈值）
  - Contradictions：无冲突

## [2026-04-23] ingest | 清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）
- Source file: AI/清华出的DeepSeek使用手册，104页，真的是太厉害了！（免费领取）.md
- Status: ✅ 成功摄入
- Summary: 清华大学发布的《DeepSeek从入门到精通2025》官方使用手册（104页），由新闻与传播学院元宇宙文化实验室余梦珑博士后及团队撰写。手册核心价值在于"授人以渔"——不仅教用户"怎么问"，更教"为什么这么问"，帮助用户掌握提示词底层逻辑。涵盖 DeepSeek-R1 模型选择、提示语设计技巧、避免 AI 幻觉策略。内容实用性与理论深度兼备，适合不同层次读者。
- Concepts created: [[DeepSeek-R1]], [[提示语设计]], [[AI幻觉]], [[通用人工智能（AGI）]], [[推理模型]]
- Entities created: [[DeepSeek]], [[余梦珑]]
- Source page: wiki/sources/清华出的deepseek使用手册-104页-真的是太厉害了-免费领取.md
- Notes:
  - 新增 Sources 条目至 index.md（替换 expected 标记行）
  - overview.md 新增 DeepSeek 使用手册条目，归入 AI Tools & Prompt Engineering 部分
  - 创建 Entity 页面：DeepSeek.md（公司）、余梦珑.md（作者）
  - Concept 页面：RAG.md、Large-Language-Model.md、AI-Agent.md 已覆盖相关概念（幻觉、推理模型），无需新建
  - Contradictions：与 [[llms-rag-ai-agent-三个到底什么区别]] 互补而非冲突——前者聚焦 DeepSeek 特定实践，后者聚焦 LLM/RAG/Agent 三层架构宏观对比，均记录于 Contradictions 小节

## [2026-04-23] ingest | How to Get the RSS Feed For Any YouTube Channel
- Source file: AI/How to Get the RSS Feed For Any YouTube Channel.md
- Status: ✅ 成功摄入
- Summary: 作者 Chuck Carroll 分享获取 YouTube 频道 RSS Feed 的简单方法——在频道页面右键选择"查看页面源代码"，搜索 `channel_id=`，提取 RSS Feed URL 格式为 `https://www.youtube.com/feeds/videos.xml?channel_id=<ID>`。无需第三方服务，适合 RSS 阅读器用户。
- Concepts created: [[RSS Feed]], [[Channel ID]]
- Entities updated: [[YouTube]], [[Chuck Carroll]]
- Source page: wiki/sources/how-to-get-the-rss-feed-for-any-youtube-channel.md
- Notes:
  - RSS Feed 和 Channel ID Concept 已存在于 overview.md 相关章节
  - YouTube Entity 已存在于 overview.md Key Entities 列表
  - 无需新建 Entity 或 Concept 页面
  - 无内容冲突

## [2026-04-23] ingest | codecrafters-io/build-your-own-x
- Source file: raw/AI/codecrafters-iobuild-your-own-x Master programming by recreating your favorite technologies from scratch.md
- Status: ✅ 成功摄入
- Summary: GitHub 精选教程列表，26+ 技术领域分步骤指南，引用 Richard Feynman "What I cannot create, I do not understand" 作为核心理念，通过从零重建主流技术实现深度技术理解。
- Entities created: CodeCrafters, DanielStefanovic, RichardFeynman
- Concepts created: Build-Your-Own-X, Learn-By-Building
- Source page: wiki/sources/codecrafters-iobuild-your-own-x-master-programming-by-recreating-your-favorite-technologies-from-scratch.md
- Notes:
  - 冲突检测：BYOX vs 传统课程式学习（理论优先 vs 实践优先）已记录于 Source Page Contradictions
  - index.md 和 overview.md 均已更新
  - 覆盖 26+ 领域：3D Renderer, Web Browser, Database, Docker, Git, OS, Programming Language, Neural Network 等
  - 支持 15+ 编程语言：C++, Python, Java, JavaScript, Go, Rust, Haskell, TypeScript 等
  - 与 Vibe Coding 互补：BYOX 理解原理，Vibe Coding 高效实现

## [2026-04-18] ingest | 电商如何选品 - 如何找到爆款选品策略
- Source file: 跨境电商/电商如何选品 如何找到爆款 选品策略.md
- Status: ✅ 成功摄入
- Summary: YouTube 视频摘要，20 种电商选品策略 + 情境配对 + 季节性规划 + POD 低成本测款 + 工具辅助分析（Salesmartly / Erank / Pinterest / Etsy 趋势）。核心观点：未来品牌需针对细分市场而非大众市场；情境配对产品组合提升客单价；POD 模式降低库存风险。
- Concepts touched: [[电商选品策略]], [[爆款产品]], [[POD模式]], [[情境配对]], [[季节性选品]], [[细分市场定位]]
- Entities touched: [[Salesmartly]], [[Erank]], [[TikTok Shop]], [[Etsy]], [[Pinterest]]
- Source page: wiki/sources/电商如何选品-如何找到爆款-选品策略.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/电商如何选品-如何找到爆款-选品策略.md）
  - Concepts 和 Entities 均以 wikilink 形式建立关联，暂不创建独立页面
  - 冲突检测：与 [[做TK跨境思路不对努力白费]] 的平台优先级存在差异，但两者针对产品类型不同（Etsy/POD 手工艺 vs TikTok 快消品），属互补而非冲突
  - 已在 index.md 添加 Source 条目
  - 已在 overview.md TikTok E-commerce Operations 小节新增条目，置于 [[做TK跨境思路不对努力白费]] 之前

## [2026-01-26] ingest | 3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！
- Source file: AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md
- Status: ✅ 成功摄入（重复来源，slug 不同）
- Summary: Anthropic 官方 Skills 仓库（github.com/anthropics/skills）介绍；Skills = 说明书 + SOP；标志从「提示词工程」向「流程工程」的范式转变；Vibe Coding 尽头也是 Skills；三大聚合站和 Awesome-Claude-Skills 仓库推荐
- Concepts identified: 无（已存在于之前摄取）
- Source page: wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式.md
- Notes:
  - 同来源文章以不同 slug 重复摄取（与 wiki/sources/3-2-万人收藏的-claude-skills-才是-ai-这条路上最值得研究的一套范式-1.md 内容完全一致）
  - index.md 已添加新条目
  - 无需新建 Entity 或 Concept 页面
  - 无新内容冲突

## [2026-04-26] ingest | Building your Quartz
- Source file: Home Office/Building your Quartz
- Status: ✅ 成功摄入
- Summary: Quartz 静态网站的本地预览与自托管部署指南。涵盖 `npx quartz build --serve` 本地热重载预览、Nginx/Apache/Caddy 三种 Web 服务器自托管配置（处理无扩展名链接）、baseUrl 配置对 RSS Feed 和 Sitemap 的影响。Obsidian 笔记 → Quartz 构建 → 自托管构成完整个人知识发布链条。
- Concepts touched: [[Quartz]], [[Static Site Generator]], [[npx quartz build]], [[try_files]], [[RewriteRule]], [[baseUrl]]
- Entities touched: [[Obsidian]], [[GitHub Pages]]
- Source page: wiki/sources/building-your-quartz.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/building-your-quartz.md）
  - Concept 和 Entity 均以 wikilink 形式建立关联，Quartz/Nginx/Apache/Caddy 均已在 overview.md 中被提及，不创建独立页面
  - 检测到 1 处潜在冲突（自托管 vs Vercel/Netlify），已记录于 Source Page Contradictions 节
  - index.md Sources 节添加新条目
  - overview.md Productivity & Knowledge Management 部分添加 Quartz 段落

## [2026-04-23] ingest | 我做了个 Skill：让 AI 帮你生成 Logo 和图标
- Source file: raw/Skills/我做了个 Skill：让 AI 帮你生成 Logo 和图标.md
- Status: ✅ 成功摄入
- Summary: 介绍 Claude Code Skill `baoyu-imagine`（`npx baoyu-imagine` 安装），通过 Logo 专用提示词策略驱动 AI 生图工具生成专业 Logo 和图标。支持扁平化/几何/手绘/渐变等多种风格，SVG（矢量）和 PNG 格式导出。让非设计师快速产出专业品牌视觉资产。
- Concepts created: AI-Logo-Generation
- Entities created: baoyu
- Source page: wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/我做了个-skill-让-ai-帮你生成-logo-和图标.md）
  - 新增 1 个 Concept 页面（AI-Logo-Generation）
  - 新增 1 个 Entity 页面（baoyu）
  - index.md Sources / Entities / Concepts 三个章节均已追加条目
  - overview.md AI Tools & Prompt Engineering 部分添加 baoyu-imagine AI Logo 生成段落，Key Concepts 追加 baoyu-imagine / AI-Logo-Generation / Claude-Code-Skill
  - 无内容冲突（baoyu-imagine 与通用 AI 生图工具形成互补）

## [2026-04-16] ingest | Obsidian CLI
- Source file: raw/Skills/Obsidian CLI.md
- Status: ✅ 成功摄入
- Summary: Obsidian v1.12+ 内置的官方命令行工具文档，覆盖 60+ 命令（日常操作/文件管理/插件管理/属性操作/开发者命令/版本管理/发布/同步等），提供 TUI 交互模式和单命令两种使用方式。开发者命令通过 Chrome DevTools Protocol 实现截图、控制台执行、插件热重载。AI Agent 可通过标准化 CLI 接口实现笔记增删改查、日程管理、搜索、任务操作等全部 GUI 功能，无需图形界面。
- Concepts updated: [[Obsidian-CLI]]（补充 8 大能力域：日常操作/文件管理/插件管理/属性操作/开发者命令/版本管理/工作区管理/TUI 交互）
- Entities updated: [[Obsidian]]（添加 obsidian-cli 来源引用，更新 last_updated）
- Source page: wiki/sources/obsidian-cli.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/obsidian-cli.md）
  - 更新 Obsidian-CLI concept 页面，补充 8 大能力域和 TUI 交互模式说明
  - 更新 Obsidian entity 页面，添加 sources 字段
  - 更新 wiki/index.md Sources 节（新增 Obsidian CLI 条目，置顶）
  - 更新 wiki/overview.md Productivity & Knowledge Management 部分（补充 Obsidian-CLI 与其他 Agent 集成方案的互补关系）
  - 冲突记录：与 [[obsidian-必装-skills]] 中 obsidian-cli 的描述存在"官方内置"vs"kepano 发布 Skill"的视角差异，已记录至 Source Page Contradictions，结论为两者均正确（obsidian-cli 既是 Obsidian 官方内置功能，也是 kepano Skills 项目收录整理的工具）
  - 新建 Concept/Entity 页面：无（Obsidian-CLI concept 页面已于 2026-04-21 创建，本次仅更新内容；Obsidian entity 页面已存在，本次仅更新 sources 字段）

## [2026-04-23] ingest | WSL2 启动与网络配置指南
- Source file: raw/Home Office/WSL2 启动与网络配置指南.md
- Status: ✅ 成功摄入
- Summary: WSL2（Windows Subsystem for Linux 2）安装启动与网络配置实操指南。核心内容：① wsl --install 快速安装 Ubuntu；② .wslconfig 启用 networkingMode=mirrored 镜像网络模式解决 localhost 代理失效问题；③ 终端环境变量手动配置代理；④ ghproxy.com 反向代理加速 GitHub 下载。关键洞察：NAT 模式是 WSL2 无法访问 Windows 宿主机代理的根本原因，镜像网络模式是推荐解决方案。
- Concepts created: WSL2、镜像网络模式、NAT模式、ghproxy
- Entities created: WSL2、ghproxy
- Source page: wiki/sources/wsl2-启动与网络配置指南.md
- Notes:
  - 新增 1 个 Source Page（wsl2-启动与网络配置指南.md）
  - 更新 wiki/index.md（Sources 章节补全缺失条目）
  - 更新 wiki/overview.md（Home Server Automation 部分新增 WSL2 章节段落；Key Entities 部分新增 WSL2 和 ghproxy 条目）
  - 无内容冲突
  - 新建 Concept/Entity 页面：无（WSL2 和 ghproxy 作为 Entity/Concept 在 overview.md 中描述，未创建独立页面）

## [2026-04-24] ingest | Blogwatcher Daily 技能收藏
- Source file: Skills/blogwatcher-daily收藏.md
- Status: ✅ 成功摄入
- Summary: Hermes Agent 自定义 Skill `blogwatcher-daily` 的收藏笔记，实现 31 个 RSS/YouTube 订阅频道的自动化监控与每日摘要生成。通过 SQLite 数据库按 URL 去重，日常扫描追加写入 `YYYY-MM-DD.md` 日报，强制回扫写入独立文件。YouTube 频道通过本地 RSSHub 代理转换为 RSS Feed。
- Concepts created: 无（RSS Monitoring、Cron Job、RSSHub、每日日报 等均为已有或通用概念，在 overview.md Key Concepts 中已有覆盖）
- Entities created: 无（blogwatcher-daily 作为 Skill 名在 sources 中描述；feedparser 仅出现1次，不满足 ≥2 次创建条件）
- Source page: wiki/sources/blogwatcher-daily收藏.md
- Notes:
  - 新增 1 个 Source Page
  - 更新 wiki/index.md（Sources 章节补全缺失条目）
  - 更新 wiki/overview.md（YouTube Automation 部分 RSSHub 段落新增对 blogwatcher-daily 的关联说明）
  - 无内容冲突
  - 新建 Concept/Entity 页面：无

## [2026-04-23] ingest | CTP Topic 1 Gruntwork Landing Zone Architecture
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-1-gruntwork-landing-zone-architecture.md
- Status: ✅ 成功摄入
- Summary: Gruntwork AWS Landing Zone 架构基础培训。核心：参考架构（Reference Architecture）是包含核心账户（Shared/Logs/Security）和工作负载账户（Prod/Stage/Dev）的最佳实践起点；Landing Zone 基于 Gruntwork 由产品团队自行定义具体服务；安全账户使用联邦用户（Federated User）通过 AD 组映射到 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流；Terraform AWS 服务目录强调服务应具有业务上下文。
- Concepts created: Reference-Architecture, Landing-Zone-Architecture, Federated-Access, CI-CD-Pipeline, Terraform-Modules
- Entities created: 无（Gruntwork Entity 已存在）
- Source page: wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md
- Notes:
  - 新增 1 个 Source Page
  - 更新 wiki/index.md（Sources 章节替换预期条目为实际摘要；Concepts 章节新增 5 个概念）
  - 更新 wiki/overview.md（Cloud Transformation 部分新增 CTP Topic 1 段落）
  - 冲突检测：与 ctp-topic-35-aws-landing-zone-design-refresher-saas-labs 在 Landing Zone 产品定义粒度上有视角差异（前者强调灵活性，后者强调标准化），已记录于 Source Page Contradictions 节，判定为视角互补而非直接冲突
  - 新建 Concept 页面：5 个（Reference-Architecture / Landing-Zone-Architecture / Federated-Access / CI-CD-Pipeline / Terraform-Modules）
  - 新建 Entity 页面：无（Gruntwork Entity 已存在，无需重复创建）

## [2026-04-14] ingest | CTP Topic 73 AWS Backup Implementation of the Cloud Transformation Programme
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md
- Status: ✅ 成功摄入
- Summary: AWS Backup 在云转型计划中的企业级实施落地。SRE 团队开发 SRE Backup Model，为产品组提供预置的 AWS Backup Plans、Vaults、KMS 密钥策略等模板，支持 DRA 账户内独立备份和恢复；初始备份复制到远程 DR 账户实现即时恢复；AWS Backup Audit Manager 提供合规审计报告和控制评估。
- Concepts created: [[SRE Model]]
- Source page: wiki/sources/ctp-topic-73-aws-backup-implementation-of-the-cloud-transformation-program.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 1 个 Concept（SRE Model）
  - index.md 更新：Sources 节新增条目，附中文摘要
  - 冲突检测：与 [[ctp-topic-44-aws-backup-in-micro-focus]] 视角互补而非冲突——前者为 CTP 实施确认，后者为内部评估，AWS Backup 的局限性已在 Contradictions 节记录
  - AWS Backup / AWS Backup Audit Manager / 跨账户备份 已在 ctp-topic-72 摄入，无需重复创建

- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-28-aws-tag-validation-tool.md
- Status: ✅ 成功摄入
- Summary: Lewis Brown 主讲，SRE 团队开发的 AWS 标签验证工具。Checkpoint 防火墙通过读取 EC2/安全组/负载均衡器标签值配置网络访问策略，标签缺失或无效时拦截流量；SCPs 只能阻止新资源创建，无法修复存量资源。该工具通过 variables.yaml 定义每个账户合法标签值，自动扫描 EC2/SG/LB/Lambda，比对配置输出 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签还计划用于成本核算。
- Entities created: [[Checkpoint]], [[SRE-Team]]
- Concepts created: [[AWS-Tags]], [[AWS-Tagging-Standards]], [[Tag-Validation-Tool]], [[Service-Control-Policies-SCPs]], [[Variables-YAML]]
- Source page: wiki/sources/ctp-topic-28-aws-tag-validation-tool.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 2 个 Entity（Checkpoint / SRE-Team）
  - 新增 5 个 Concept（AWS-Tags / AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML）
  - overview.md 更新：新增 CTP Topic 28 摘要段落（置于 ctp-topic-17 之后，ctp-topic-47 之前），Key Concepts 节新增 6 个概念标注（AWS-Tagging-Standards / Tag-Validation-Tool / Service-Control-Policies-SCPs / Variables-YAML / Checkpoint-Firewall / SRE-Tools-Repository）
  - index.md 更新：Sources 节替换预期条目为实际摘要，Entities 节新增 2 个实体，Concepts 节新增 6 个条目
  - 冲突检测：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 互补而非冲突——后者聚焦标签收集机制和安全策略上下文，前者聚焦审计发现，共同构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环
  - Lewis Brown 仅出现 1 次，未创建 Entity 页面

## [2026-04-14] ingest | CTP Topic 10 AWS Landing Zone (LZ) Data Collection, Tagging Related Security
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
- Status: ✅ 成功摄入
- Summary: Steve Jarman 和 Pradeep 主讲 AWS Landing Zone 部署流程、数据收集策略与基于标签的云原生安全架构。核心：①Landing Zone 部署前需了解 BU 资产清单/IP 地址空间/数据敏感性；②DNS/Transit Gateway 等基础服务已通过 SRE 高度自动化；③基于标签的安全控制——用 AWS 标签替代传统 IP 防火墙规则；④SCP 强制执行标签规范——通过"显式拒绝"防止篡改标签绕过审计；⑤Checkpoint 防火墙有序层——按优先级执行地理屏蔽 → BU 隔离 → 产品隔离 → 环境隔离。
- Concepts created: 无（所有概念均已在 [[ctp-topic-28-aws-tag-validation-tool]] 中创建）
- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
- Notes:
  - 新增 1 个 Source Page
  - 无新增 Concept（[[AWS_Landing_Zone]] / [[Tagging_Methodology]] / [[SCP_Service_Control_Policy]] / [[OU_Organizational_Unit]] / [[Checkpoint_Firewall_Ordered_Layer]] / [[Transit_Gateway]] / [[SRE_Automation]] 均已在 ctp-topic-28 中创建）
  - overview.md 更新：新增 CTP Topic 10 摘要段落（置于 ctp-topic-1 之后），补充标签治理闭环描述
  - index.md 更新：Sources 节新增条目（置顶）
  - 冲突检测：无冲突
  - Steve Jarman 仅出现 1 次，Pradeep 仅出现 1 次，均未创建 Entity 页面
  - 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 互补——前者为基础架构，后者为安全层扩展
  - 与 [[ctp-topic-28-aws-tag-validation-tool]] 互补——构成"制定规范 → 强制执行 → 审计发现"的标签治理闭环

## [2026-04-14] ingest | CTP Topic 25 Labs Landing Zone Overview - ITOM Teams
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
- Status: ✅ 成功摄入
- Summary: Labs Landing Zone 基于 Gruntwork 参考架构的多账户策略——核心账户包括 Shared（Jenkins 主节点/加固 AMI/容器仓库）、Logs（CloudTrail/Config 日志）、Security（联邦用户/跨账户访问）、Core（AD 管理 Windows 实例和 IDP/DNS 管理 Swimford.net）、Network（Transit Gateway + JetPult 防火墙/标签驱动的网络策略/Pulse VPN）；Shared Services 提供 45 Arc Site 监控和 Qualys 漏洞扫描；Product Account 通过 Terraform/Terragrunt 模块部署，需与网络团队协调 IP 范围和标签策略；Jenkins 流水线扫描 GitHub Enterprise 仓库变更，触发 Terragrunt plan/apply，并通过 pre-commit 和 Fortify 扫描提升安全。
- Concepts created: 无（所有概念均已在其他 CTP 页面中创建：[[Landing Zone Architecture]] / [[Terraform]] / [[Terragrunt]] / [[Jenkins]] / [[Transit Gateway]] / [[Federated Access]] / [[Tag-Based Access Control]]）
- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
- Notes:
  - 新增 1 个 Source Page
  - 无新增 Concept/Entity（Gruntwork/Jenkins/JetPult/Pulse VPN/Qualys/45 Arc Site 均仅出现 1 次，不满足 ≥2 次建页条件）
  - overview.md 更新：新增 CTP Topic 25 摘要段落（置于 ctp-topic-35 之前），补充 Labs LZ 运维实践描述
  - index.md 更新：Sources 节新增条目（置顶于 CTP Topic 34 之前），移除旧 "source missing" 标记
  - 冲突检测：无冲突
  - 属 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（架构基础）和 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]（SaaS vs Labs 职责划分）共同构成完整的 AWS Landing Zone 知识体系

## [2026-04-24] ingest | Public Cloud Learning Sessions - Tagging Standards for All Hyperscalers - 20240123
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
- Status: ✅ 成功摄入
- Summary: OpenText 跨 AWS/Azure/GCP 的统一标签标准，目标将云浪费从 30% 降至 15%，预计年节省 2500 万美元。标准采用 OT_ 前缀标签、GCP 限制性字符集作为最低通用标准，通过 Terraform 默认标签注入和 SCP 强制执行实现合规化。
- Concepts referenced: [[FinOps]], [[Service-Control-Policies-SCPs]], [[Tag-Based-Security]], [[Terraform-Tagging]], [[Multi-Cloud-Governance]]（均已在其他页面定义，无需新建）
- Entities referenced: [[Tom Bice]]（仅出现 1 次，不满足 ≥2 次建页条件，未创建独立页面）
- Source page: wiki/sources/public-cloud-learning-sessions-tagging-standards-for-all-hyperscalers-20240123-1.md
- Notes:
  - 新增 1 个 Source Page
  - 无新增 Concept/Entity 页面
  - index.md 更新：移除 "source missing" 标记，添加正式条目
  - 冲突检测：无冲突
  - 属 [[public-cloud-learning-sessions-opentext-tagging-standard-v2]]（v2 扩展 v1，覆盖 K8s 和容器镜像标签）、[[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（基于标签的安全控制机制）、[[ctp-topic-28-aws-tag-validation-tool]]（标签合规审计）共同构成完整的标签治理知识体系

## [2026-04-25] ingest | Public Cloud Learning Sessions (OpenText) - Product Hub (PHT) Overview and Q&A - 20240806
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/10_OpenText-Series/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md
- Status: ✅ 成功摄入
- Summary: OpenText Product Hub（PhD/PHT）产品层次结构追踪器功能概述——三层层级（业务单元→业务线→产品）、自助服务新建流程、与 Jira/Value Edge/PSMQ/ITLS/OSS 等外部系统集成、Source Repo 和 Artifact Repo 权限管理。
- Concepts created: [[Product Hub (PhD)]]（已引用）
- Entities created: 无（OpenText 相关 Entity 仅出现 1 次，不满足 ≥2 次建页条件）
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-product-hub-pht-overview-and-qa-20240806.md
- Notes:
  - 新增 1 个 Source Page
  - 无新增 Concept/Entity 页面
  - index.md 更新：移除 "source missing" 标记，添加正式条目
  - 冲突检测：无冲突

## [2026-04-30] ingest | Learning Sessions Identity Governance VSM Replacement - 20231128
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/02_IAM/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md
- Status: ✅ 成功摄入
- Summary: 身份治理（Identity Governance）框架与 VSM→Micro Focus IGA 替换计划——身份治理三问：谁当前有访问/谁该访问/如何访问；Micro Focus IGA 通过 AD 组工作流管控权限审批，配合 AWS Identity Center + IAM 提供云资源访问；VSM 将被 IGA 全面替换，保持原架构但改接 Coptum 域，POC 正在进行。
- Concepts created: [[Identity-Governance]]
- Entities created: [[Micro-Focus-IGA]], [[DXC-VSM]]
- Source page: wiki/sources/learning-sessions-identity-governance-vsm-replacement-20231128-160326-meeting-re.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 1 个 Concept 页面（wiki/concepts/Identity-Governance.md）
  - 新增 2 个 Entity 页面（wiki/entities/Micro-Focus-IGA.md, wiki/entities/DXC-VSM.md）
  - index.md 更新：移除 "source missing" 标记，添加正式条目；在 Entities 和 Concepts 节添加新页面
  - overview.md 新增条目，位于 CTP Topic 17（AD 集成）之后
  - 冲突检测：无已知冲突内容

## [2026-04-25] ingest | CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md
- Status: ✅ 成功摄入
- Summary: 使用 Grafana Enterprise + Optic DR 数据源 + Opsbridge 告警 + Terraform IaC 模块实现 AWS 超大规模可观测性监控——推荐迁移至 Enterprise License 释放完整功能；Optic DR（VaticaDB 插件）是 Grafana 从 AWS 拉取数据的关键中间件；Terraform 模块为产品团队自动化创建 Grafana Organizations、用户、文件夹和仪表盘；EC2 Inventory 仪表盘可识别运行/未运行 EC2 实例及标签合规状态。
- Concepts identified: [[Grafana-Enterprise]], [[Observability（可观测性）]], [[Opsbridge]], [[Optic-DR]], [[Terraform-Module]], [[Resource-Tagging]]
- Entities identified: [[Grafana-Labs]], [[VaticaDB]], [[PagerDuty]], [[Slack-Manager]]（均以 wikilink 形式记录于 Source page，无需独立页面）
- Source page: wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana.md）
  - 无新增 Concept/Entity 页面（已识别概念均作为 wikilink 嵌入 Source page）
  - index.md 更新：在 Sources 节顶部添加新条目
  - 冲突检测：与 ctp-topic-42-grafana-observability-dashboard 存在潜在张力（开源版 vs Enterprise License）

## [2026-04-25] ingest | CTP Topic 70 EKS deployment using IAC
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-70-eks-deployment-using-iac.md
- Status: ✅ 成功摄入
- Summary: EKS 集群通过 IaC（Terraform + Service Catalog）部署的完整方法论——两种部署路径（Terraform `tera-grant.scl` vs Service Catalog 模块）、EMI 自定义网络解决 VPC CIDR 限制、Cluster Autoscaler 自动扩缩容 Worker Node、CloudWatch Agent + FluentBit + Container Insights + OpenTelemetry + Grafana 完整监控栈。
- Concepts created: [[Amazon EKS]], [[Cluster Autoscaler]], [[Infrastructure as Code]], [[Kubernetes]]（已有 entity，新增 source 引用）
- Entities updated: [[Kubernetes]]（添加 source 引用）
- Source page: wiki/sources/ctp-topic-70-eks-deployment-using-iac.md
- Notes:
  - 新增 1 个 Source Page（wiki/sources/ctp-topic-70-eks-deployment-using-iac.md）
  - 新增 3 个 Concept 页面：Amazon EKS、Cluster Autoscaler、Infrastructure as Code
  - Kubernetes entity 页面已存在，更新添加新 source 引用
  - index.md 更新：在 Sources 节顶部添加新条目；在 Concepts 节添加 3 个新条目；移除 "source missing" 标记
  - overview.md 更新：添加新条目，位于 EKS Auto Mode 条目之后
  - 冲突检测：与 ctp-topic-59-achieving-reliability-with-amazon-eks 可能存在内容重叠（侧重点不同：Topic 70 侧重部署方法，Topic 59 侧重可靠性实践）

## [2026-04-27] ingest | Public Cloud Learning Sessions - Observability with OpenTelemetry
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md
- Status: ✅ 成功摄入
- Summary: Jay Comer（AWS 解决方案架构师）主讲 OpenTelemetry 可观测性全景——三信号模型（Metrics/Logs/Traces）、OTLP 协议 + 11 种语言 SDK + Collector 架构、AWS Distribution for OpenTelemetry（统一代理 + EKS Operator 自动注入）、Fluent Bit → OTel Collector（端口 55681）→ Amazon OpenSearch 端到端管道演示。
- Concepts created: [[OpenTelemetry]], [[Observability（可观测性）]], [[Three Signals]], [[OTLP（OpenTelemetry Protocol）]], [[Fluent Bit]]
- Entities identified: [[Jay Comer]]
- Source page: wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md
- Notes:
  - 新增 1 个 Source Page
  - index.md 更新：新增条目（日期 2024-04-02）
  - overview.md 更新：新增条目于 Cloud Transformation & DevOps → EKS 知识链路；Key Concepts 新增 5 个条目
  - 新增 Entity 页面：Jay-Comer.md
  - 新增 Concept 页面：OpenTelemetry.md
  - 冲突检测：与 ctp-topic-54-esm-saas-log-analytics（ELK 日志）、ctp-topic-67（CTP Topic 67 OpenTelemetry）互补，无冲突

## [2026-04-25] ingest | CTP Topic 33 An Introduction to GitOps
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-33-an-introduction-to-gitops.md
- Status: ✅ 成功摄入
- Summary: GitOps 方法论入门——将软件开发原则应用于部署流程；四大原则（声明式配置 + 版本控制 + CD 流程分离 + 自修复协调器）；Pull 模型优于 Push 模型；幂等平台（Kubernetes）是 CD 顺利运行的必要条件；Git 提交日志即合规审计追踪
- Concepts created: [[GitOps]]
- Entities identified: [[Victor Etkin]]
- Source page: wiki/sources/ctp-topic-33-an-introduction-to-gitops.md
- Notes:
  - 新增 1 个 Source Page
  - 新增 1 个 Concept 页面：GitOps.md（覆盖四大原则、Pull vs Push 模型、与 IaC 关系）
  - index.md 更新：新增条目于 CI_CD_GitOps 分类
  - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节，GitOps 知识链路
  - Key Entities 中提及的 Victor Etkin 仅出现 1 次，不满足 ≥2 次条件，以 wikilink 形式记录于 Source page
  - Key Concepts 中 Kubernetes/Atlantis 已有 wikilink 指向其他 Source page
  - 冲突检测：与 ctp-topic-39（Atlantis 不支持 EKS）存在 Atlantis + Kubernetes 实践约束差异，已记录于 Source page Contradictions

## [2026-04-24] ingest | CTP Topic 56 Automated Infrastructure Testing
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-56-automated-infrastructure-testing.md
- Status: ✅ 成功摄入
- Summary: Mark Francis 主讲自动化基础设施测试，倡导将 TerraTest（Golang 框架）应用于 Terraform IaC 的 apply → test → destroy 自动化验证循环；核心主张集成测试超越语法检查，TDD 应用于 IaC 领域，测试作为首要开发步骤；价值观："让机器做重复的事，把人脑留给复杂的人类问题"
- Concepts identified: [[Infrastructure Testing]], [[TerraTest]], [[Test-Driven Development (TDD)]], [[IaC Testing Framework]]
- Source page: wiki/sources/ctp-topic-56-automated-infrastructure-testing.md
- Notes:
  - index.md 更新：新增条目于 CTP Topic 33 (GitOps) 之后
  - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节，GitOps 和 CI/CD Pipeline 质量保障层
  - Key Entities 中 Mark Francis 仅出现 1 次，不满足 ≥2 次条件，以 wikilink 形式记录于 Source page
  - Key Concepts 中 Kubernetes/Atlantis 已有 wikilink 指向其他 Source page
  - 冲突检测：与 ctp-topic-39（Atlantis 不支持 EKS）存在 Atlantis + Kubernetes 实践约束差异，已记录于 Source page Contradictions

## [2026-04-24] ingest | CTP Topic 71 PCG's guide to RightSizing, why, how when
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/05_FinOps/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md
- Status: ✅ 成功摄入
- Summary: PCG 团队讲解 AWS EC2 RightSizing 系统性方法论——为何要做、何时做、如何执行。RightSizing 通过分析实例实际资源使用情况，将过度配置的实例调整为合适规格，在不影响性能前提下实现成本节省。⚠️ 视频尚未完成 Whisper 转录，完整内容待补充
- Concepts created: RightSizing, EC2 Cost Optimization
- Source page: wiki/sources/ctp-topic-71-pcgs-guide-to-rightsizing-why-how-when.md
- Notes:
  - index.md 更新：将原 expected placeholder 更新为正式条目（2026-04-14）
  - overview.md 更新：新增条目于 Cloud Transformation & DevOps 章节 FinOps 知识链路
  - RightSizing/Cloud Cost Optimization 已通过 wikilink 嵌入 Source page
  - Key Entities: PCG (Platform Control Group) 已在 Wiki 中存在（ctp-topic-13），无需新建 Entity 页面
  - 冲突检测：未发现内容冲突，Contradictions 暂置空占位

## [2026-05-06] ingest | Public Cloud Learning Sessions (OpenText) - Generative AI & Prompt Engineering - 20241112
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
- Status: ✅ 成功摄入
- Summary: AWS 生成式 AI 服务与提示工程实践，由 OpenText 技术客户经理 Shikad Holtzman（以色列）主讲——生成式 AI 四大价值路径、企业数据差异化核心洞见、Amazon Bedrock 全托管基础模型服务（RAG/微调/Agents/Guardrails）、Amazon Q 助手（企业版/开发者版）、AWS 专用芯片（Trainium/Inferentia）、提示工程四组件（指令/上下文/用户输入/输出指示器）和基础技巧（One-shot/Few-shot、Chain of Thoughts）
- Concepts linked: [[RAG]], [[Prompt-Engineering]], [[Chain-of-Thought]], [[One-Shot-Prompting]], [[Few-Shot-Prompting]], [[Responsible-AI]], [[Guardrails-for-Amazon-Bedrock]]
- Entities linked: [[Shikad-Holtzman]], [[Amazon-Bedrock]], [[Amazon-SageMaker]], [[Amazon-Q]], [[AWS-Trainium]], [[AWS-Inferentia]], [[AWS]]
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
- Notes:
  - index.md 已更新：将原 expected placeholder 更新为正式条目（2026-04-19），补充中文摘要
  - overview.md 已更新：在 Cloud Transformation & DevOps 章节的 AI/ML 入门条目后新增独立段落，与 AI/ML 入门共同构成生成式 AI 知识链路
  - Key Concepts：RAG/Prompt-Engineering/Chain-of-Thought/Few-Shot-Prompting 频次不足独立建 Concept 页阈值，以 wikilink 形式记录于 Source page
  - Key Entities：Shikad Holtzman 仅出现 1 次，以 wikilink 形式记录于 Source page；Amazon Bedrock/Q/SageMaker 在同系列其他来源中提及频次不足独立建 Entity 页阈值
  - 同系列来源关联：已建立与 AI/ML 入门（public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin）和无服务器计算（public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee）的 Connections 关系
  - 冲突检测：与 ctp-topic-64-scaling-out-with-amazon-eks 在扩展方式上的差异已记录于 Source page Contradictions（EDA 事件驱动 vs EKS 容器编排，适用于不同场景可互补）

## [2026-05-06] ingest | Learning Sessions Cloud Transformation Programme-Deploying RDS via Terraform
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/03_Terraform/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
- Status: ✅ 成功摄入
- Summary: Greg（DBRE 团队）讲解通过 Terraform/Terragrunt 在 AWS 部署 RDS——IaC 六大优势（速度/灵活性/一致性/灾难恢复/文档/自动化）；代码即文档；grunt work RDS Service 推荐生产使用（预建 KMS 加密 + CloudWatch 告警），SRE 核心模块功能弱于 grunt work；Terragrunt 保持代码整洁、避免变量重复；Day 2 运维通过 GitHub PR + Atlantis 实现；CloudWatch Dashboard + Alarms 监控告警，注意突发性能实例 CPU credits
- Concepts linked: [[Infrastructure-as-Code]], [[DRY Principle]], [[GitOps]], [[CloudWatch-Alarms]], [[KMS-Encryption]]
- Entities linked: [[Gruntwork]], [[Atlantis]], [[Terraform]], [[Terragrunt]], [[DBRE]], [[CloudWatch]]
- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md
## [2026-04-25] ingest | Paid Media Tracking & Measurement Specialist Agent
- Source file: Agent/agency-agents/paid-media/paid-media-tracking-specialist.md
- Status: ✅ 成功摄入
- Summary: 付费媒体追踪与归因专家 Agent——由 John Williams（@itallstartedwithaidea）设计，负责构建跨平台（GTM、GA4、Google Ads、Meta CAPI、LinkedIn Insight Tag）的事件追踪架构，确保每一次转化都被正确计数，每一分广告投入都可衡量。核心理念：错误追踪比无追踪更糟糕，错误计数的转化会主动误导出价算法向错误方向优化。
- Concepts linked: [[GoogleTagManager]], [[GoogleAnalytics4]], [[MetaConversionsAPI]], [[ServerSideTagging]], [[ConversionTracking]], [[AttributionModeling]], [[ConsentModeV2]], [[DataLayerArchitecture]]
- Entities linked: [[JohnWilliams]], [[TheAgency]]
- Source page: wiki/sources/paid-media-tracking-specialist.md
- Notes: 该 Agent 为其他所有 Paid Media Agent 提供数据基础设施；与 paid-media-creative-strategist/paid-social-strategist/ppc-strategist/programmatic-buyer/search-query-analyst/auditor 均存在 depends_on 关系（协同关系已记录于 Connections）；index.md 已插入于 paid-media-programmatic-buyer 之后；Concepts 均为工具/框架类概念，当前仅出现 1 次，不足独立建页阈值，以 wikilink 形式记录于 Source page

## [2026-04-25] ingest | XR Cockpit Interaction Specialist Agent
- Source file: Agent/agency-agents/spatial-computing/xr-cockpit-interaction-specialist.md
- Status: ✅ 成功摄入
- Summary: XR Cockpit Interaction Specialist Agent——XR 座舱交互专家 Agent，专注于设计和实现沉浸式座舱式交互环境。核心理念：固定视角（fixed-perspective）+ 高存在感交互区（high-presence interaction zones），将真实感与用户舒适度结合。核心设计原则：约束驱动控制机制（constraint-driven control mechanics）通过 3D meshes 和输入约束将控制物理化，消除自由漂浮运动；座舱人体工学对齐自然眼-手-头协调流动；多模态交互集成（手势/语音/注视/物理道具）；固定视角设计降低运动病阈值。典型应用：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。核心工具：A-Frame / Three.js 原型开发。
- Concepts created: [[Constraint-Driven-Control-Mechanics]], [[Cockpit-Ergonomics]], [[Motion-Sickness-Threshold]], [[Spatial-Computing]]
- Entities linked: [[XR-Interface-Architect]], [[XR-Immersive-Developer]], [[Terminal-Integration-Specialist]]
- Source page: wiki/sources/xr-cockpit-interaction-specialist.md
- Notes: 4 个新 Concept 页面已创建；overview.md 新增 xr-cockpit-interaction-specialist 独立段落；index.md 修复 "source missing" 条目；Entity 层面，XR-Interface-Architect / XR-Immersive-Developer / Terminal-Integration-Specialist 在源文档中提及但尚未建立独立 Entity 页面，当前以 wikilink 形式记录于 Sources 页面；与 [[XR-Immersive-Developer]] 在运动自由度上存在设计张力（固定约束 vs 开放沉浸），已记录于 Contradictions 部分

## [2026-04-25] ingest | macOS Spatial/Metal Engineer Agent Personality
- Source file: Agent/agency-agents/spatial-computing/macos-spatial-metal-engineer.md
- Status: ✅ 成功摄入
- Summary: macOS Spatial/Metal Engineer Agent——Apple 平台专用 Metal 渲染与空间计算专家 Agent，专注于 Swift + Metal 高性能 3D 渲染和 visionOS 空间计算体验。核心能力：实例化 Metal 渲染（10k-100k 节点 @ 90fps 立体渲染）；RemoteImmersiveSpace + LayerRenderer 实现 macOS → Vision Pro 帧流；Metal Compute Shader GPU 力导向图布局；注视（Gaze）+ 捏合（Pinch）空间交互。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。
- Concepts linked: [[Instanced Rendering]], [[RemoteImmersiveSpace]], [[Compositor Services]], [[LayerRenderer]], [[Force-Directed Graph Layout]], [[Metal System Trace]], [[Stereoscopic Rendering]], [[GPU-Driven Rendering]], [[Triple Buffering]], [[Frustum Culling & LOD]]
- Entities linked: [[Apple]], [[Vision Pro]], [[Metal]], [[Xcode Instruments]], [[RealityKit]], [[ARKit]]
- Source page: wiki/sources/macos-spatial-metal-engineer.md
- Notes: Entity 层面 Apple/Vision Pro/Metal/Xcode Instruments/RealityKit/ARKit 在源文档中提及但均不足独立建页阈值，通过 Sources 页面的 Key Entities 部分建立链接；与 [[visionos-spatial-engineer]] 存在职责重叠（Vision Pro 开发），已记录于 Contradictions 部分——前者侧重 macOS 渲染侧 + Vision Pro 流式输出，后者倾向 visionOS 原生交互开发，两者可协同；与 [[xr-immersive-developer]] 互补——浏览器端 WebXR vs Apple 原生 Metal 渲染管线，共同构成 XR 产品矩阵

## [2026-04-25] ingest | Recruitment Specialist Agent
- Source file: Agent/agency-agents/specialized/recruitment-specialist.md
- Status: ✅ 成功摄入
- Summary: RecruitmentSpecialist 是一个专注于中国人力资源市场的招聘运营与人才获取专家 Agent，覆盖从人才吸引、入职到留任的全周期招聘引擎。涵盖中国招聘平台运营（BOSS直聘、拉勾、猎聘、智联、前程无忧、脉脉、LinkedIn）、JD 优化、简历筛选、面试流程设计（STAR、结构化面试）、校园招聘、猎头管理、劳动法合规（劳动合同法、PIPL、五险一金、N+1）、雇主品牌建设、入职 SOP、招聘数据分析全链路。
- Concepts created: [[STAR Framework]], [[Structured Interview]], [[China Labor Law Compliance]], [[Recruitment Funnel Analyzer]]
- Entities created: [[Boss Zhipin]]
- Source page: wiki/sources/recruitment-specialist.md
- Notes: 无已知冲突。Key Entities 中 Lagou/Liepin/Beisen/Moka/Feishu/STAR 等在源文档出现但出现次数不足以触发独立建页，通过 Sources 页面的 Key Entities 部分建立 wikilinks。

## [2026-04-25] ingest | Government Digital Presales Consultant
- Source file: Agent/agency-agents/specialized/government-digital-presales-consultant.md
- Status: ✅ 成功摄入
- Summary: Government Digital Presales Consultant 是面向中国ToG（政府）市场的全生命周期售前专家Agent，涵盖政策解读、等保2.0三级/商用密码评估/信创适配、数字政府/智慧城市/城市大脑方案设计、招投标全流程（POC→标书→述标→交接）。核心原则：业务场景驱动方案、技术价值需翻译为政府语言、等保/密评/信创是强制项非加分项。
- Concepts created: [[Dengbao-2.0]], [[Miping]], [[Xinchuang]]
- Source page: wiki/sources/government-digital-presales-consultant.md
- Notes: 无已知冲突。Key Entities（Digital China Master Plan、Kunpeng、Phytium、UnionTech UOS、DM Database等）在源文档中属于背景知识，未创建独立Entity页面，通过Source页面Key Entities部分建立wikilinks。Entities页面已添加Dengbao 2.0、Miping、Xinchuang三条概念索引。

## [2026-04-25] ingest | Healthcare Marketing Compliance Specialist
- Source file: Agent/agency-agents/specialized/healthcare-marketing-compliance.md
- Status: ✅ 成功摄入
- Summary: Healthcare Marketing Compliance Specialist——The Agency Specialized 部门的医疗营销合规专家，覆盖中国医疗健康全品类（药品/医疗器械/医美/保健食品/互联网医疗）营销合规。核心方法：广告法/医疗广告管理办法/互联网广告管理办法核心法规体系 + 企业内部三级审查机制（法务初审→合规复审→终审发布）+ 合规风险分级矩阵（Critical/High/Medium/Low）+ 违规应急响应（2小时下架→24小时报告→72小时审计）。关键原则：合规不是"堵营销"，而是"保护品牌"。
- Concepts created: [[Healthcare-Marketing-Compliance]]（总框架）、[[Medical-Advertisement-Review]]（医疗广告审查制度）、[[Three-Tier-Review-Mechanism]]（三级审查机制）、[[Blue-Hat-Logo]]（蓝帽子标识）、[[Appearance-Anxiety]]（容貌焦虑红线）、[[Patient-Privacy-PIPL]]（患者隐私合规）、[[Compliance-Risk-Matrix]]（合规风险分级矩阵）
- Entities created: [[NMPA]]（国家药品监督管理局）、[[SAMR]]（国家市场监督管理总局）、[[DXY]]（丁香园）、[[Douyin]]（抖音）、[[Xiaohongshu]]（小红书）
- Source page: wiki/sources/healthcare-marketing-compliance.md
- Notes: index.md 中原有"source missing"条目，本次摄入后已更新为完整条目并修正标题。overview.md Specialized 部门新增 Healthcare Marketing Compliance Specialist 条目。Conflict Areas 新增第11条（与通用法律合规 Agent 的职责边界冲突）。Entities 页面中 Haodf/WeDoctor/JD-Health/WeChat 在源文档中出现频次<2，暂未创建独立页面，通过 Source 页面 Key Entities 部分建立 wikilinks。

## [2026-04-25] ingest | Sales Data Extraction Agent
- Source file: Agent/agency-agents/specialized/sales-data-extraction-agent.md
- Status: ✅ 成功摄入
- Summary: Sales Data Extraction Agent——销售数据提取 AI Agent，专门监控 Excel 文件并提取关键销售指标（MTD/YTD/Year End）。核心能力：文件系统监控、灵活列名映射、PostgreSQL 事务持久化、完整审计跟踪。成功指标：100% 自动化处理、<2% 行级失败率、<5 秒单文件处理时间。
- Concepts created: 无（FilesystemWatcher/FuzzyColumnMapping/MetricExtraction/TransactionalDatabase/AuditTrail 等概念均通过 Source Page 内 wikilinks 形式表达，未单独建 Concept 页面）
- Entities created: 无（PostgreSQL/SalesRepresentative/ExcelWorkbook 在源文档中出现频次<2，暂未创建独立 Entity 页面，通过 Source 页面 Key Entities 建立 wikilinks）
- Source page: wiki/sources/sales-data-extraction-agent.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Sales Data Extraction Agent 条目；与 DataConsolidationAgent 的关系已记录于 Contradictions 部分（数据提取 vs 数据整合，互补关系）。

## [2026-04-25] ingest | Study Abroad Advisor
- Source file: Agent/agency-agents/specialized/study-abroad-advisor.md
- Status: ✅ 成功摄入
- Summary: Study Abroad Advisor——The Agency Specialized 部门的全链路留学申请规划专家，面向中国学生，覆盖美/英/加/澳/欧/港/新七大目的地，本科/硕士/博士全学位层次。核心理念：数据驱动、零焦虑贩卖；四步工作流（全面诊断→策略制定→材料打磨→提交跟进）；诚信原则（不代写文书、不承诺录取结果、区分确认信息与经验估算）。标准化交付模板：选校报告、多国申请时间线、文书诊断框架、Offer 比较矩阵。
- Concepts created: [[Holistic-Admissions]]（全面评估录取模式）、[[UCAS-System]]（英国本科统一申请系统）、[[IANG-Visa]]（非本地毕业生留港就业安排）、[[Grandes-Ecoles]]（法国精英大学体系）
- Entities created: [[The-Agency]]（The Agency 多智能体系统组织，147 个 Agent 跨 12 部门）
- Source page: wiki/sources/study-abroad-advisor.md
- Notes: index.md 中原有 "source missing" 占位条目（2026-04-20）已替换为完整条目；overview.md Specialized 部门新增 Study Abroad Advisor 条目置于 lsp-index-engineer 之后；与 corporate-training-designer 同属服务型 Agent 已在 overview.md 建立关联。4 个 Concept 页面（Holistic-Admissions/UCAS-System/IANG-Visa/Grandes-Ecoles）和 1 个 Entity 页面（The-Agency）创建前均已做去重检查，确认均不存在。

## [2026-04-26] ingest | Backend Architect with Memory
- Source file: Agent/agency-agents/integrations/mcp-memory/backend-architect-with-memory.md
- Status: ✅ 成功摄入
- Summary: 具备持久记忆能力的后端架构师 AI Agent 设计规范——专注于可扩展系统设计（微服务/Serverless）、数据库架构（PostgreSQL/索引/CQRS）、API 开发（REST/GraphQL/gRPC）与云基础设施。核心价值：MCP Memory 集成实现跨会话记忆召回，防止重复讨论已做决策；架构决策以标签化快照持久化；交付物完成后主动标记接收方供下游 Agent 查找；QA 失败时自动回滚到上一个良好检查点。
- Entities created: BackendArchitect（The Agency 工程部门资深后端架构师 Agent，满足 ≥2 次阈值）
- Concepts created: 无（MicroservicesArchitecture/CQRS/EventSourcing/ServerlessArchitecture/DatabaseIndexing/CircuitBreaker/DefenseInDepth 均仅出现 1 次，均不满足 ≥2 次阈值，均以 wikilink 形式记录于 Source page）
- Source page: wiki/sources/backend-architect-with-memory.md
## [2026-04-25] ingest | GitHub Copilot Integration
- Source file: Agent/agency-agents/integrations/github-copilot/README.md
- Status: ✅ 成功摄入
- Summary: The Agency 与 GitHub Copilot 的开箱即用集成——无需转换，`.md` + YAML frontmatter 格式原生兼容。一键安装 `./scripts/install.sh --tool copilot`，或手动复制到 `~/.github/agents/` 或 `~/.copilot/agents/`。用户可在 Copilot 会话中通过名称激活特定 agent。
- Concepts created: AgentFileFormat
- Entities created: GitHubCopilot
- Source page: wiki/sources/github-copilot.md
- Notes: 无内容冲突。index.md（Sources + Concepts + Entities）、overview.md（替换 Cursor Integration 段落为 GitHub Copilot Integration）、log.md 均已更新。Concept AgentFileFormat.md 已创建于 wiki/concepts/，Entity GitHubCopilot.md 已创建于 wiki/entities/。