ishenwei/llm-wiki-agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: log Jira Workflow Steward ingest completion

Browse Source
This commit is contained in:
weishen
2026-04-30 00:48:06 +08:00
parent cbba7a4923
commit e1738bade1
6 changed files with 3165 additions and 1782 deletions
Download Patch File Download Diff File Expand all files Collapse all files

292
AGENTS.md
View File

@@ -1,73 +1,74 @@
# LLM Wiki Agent — Schema & Workflow Instructions
# LLM Wiki Agent — 结构与工作流说明
This wiki is maintained entirely by your coding agent. No API key or Python scripts needed — just open this repo in Codex, OpenCode, or any agent that reads this file, and talk to it.
本 Wiki 完全由编码代理（agent）维护。无需 API Key 或 Python 脚本 —— 只需在 Codex、OpenCode 或任何能读取本文件的 agent 中打开此仓库，直接用自然语言交互即可。
## How to Use
## 使用方式
Describe what you want in plain English:
- *"Ingest this file: raw/papers/my-paper.md"*
- *"What does the wiki say about transformer models?"*
- *"Check the wiki for orphan pages and contradictions"*
- *"Build the knowledge graph"*
用自然语言描述你的需求：
- *"摄取这个文件：raw/papers/my-paper.md"*
- *"Wiki 里关于 transformer 模型说了什么？"*
- *"检查 Wiki 中的孤立页面和冲突内容"*
- *"构建知识图谱"*
Or use shorthand triggers:
- `ingest <file>` → runs the Ingest Workflow
- `query: <question>` → runs the Query Workflow
- `lint` → runs the Lint Workflow
- `build graph` → runs the Graph Workflow
或使用快捷触发词：
- `ingest <file>` → 执行摄取工作流
- `query: <问题>` → 执行查询工作流
- `lint` → 执行检查工作流
- `build graph` → 执行图谱构建工作流
---
## Directory Layout
## 目录结构
```
raw/ # Immutable source documents — never modify these
wiki/ # Agent owns this layer entirely
index.md # Catalog of all pages — update on every ingest
log.md # Append-only chronological record
overview.md # Living synthesis across all sources
sources/ # One summary page per source document
entities/ # People, companies, projects, products
concepts/ # Ideas, frameworks, methods, theories
syntheses/ # Saved query answers
graph/ # Auto-generated graph data
tools/ # Optional standalone Python scripts (require ANTHROPIC_API_KEY)
raw/ # 不可变的原始文档 —— 永远不要修改这里的内容
wiki/ # Agent 完全负责维护的知识层
index.md # 所有页面的目录 —— 每次摄取后必须更新
log.md # 只追加的时间线记录
overview.md # 跨所有来源的动态综合摘要
sources/ # 每个原始文档对应一个摘要页
entities/ # 人物、公司、项目、产品
concepts/ # 想法、框架、方法、理论
syntheses/ # 保存的查询答案
graph/ # 自动生成的图谱数据
tools/ # 可选的独立 Python 脚本（需要 ANTHROPIC_API_KEY）
```
---
## Page Format
## 页面格式
Every wiki page uses this frontmatter:
每个 Wiki 页面都使用以下 frontmatter：
```yaml
---
title: "Page Title"
title: "页面标题"
type: source | entity | concept | synthesis
tags: []
sources: [] # list of source slugs that inform this page
sources: [] # 支撑本页面的来源 slug 列表
last_updated: YYYY-MM-DD
---
```
Use `[[PageName]]` wikilinks to link to other wiki pages.
使用 `[[页面名]]` 格式的 wikilink 链接到其他 Wiki 页面。
---
## Ingest Workflow
## 摄取工作流（Ingest Workflow）
Triggered by: *"ingest <file>"*
触发方式：*"ingest <file>"*
Steps (in order):
1. Read the source document fully
2. Read `wiki/index.md` and `wiki/overview.md` for current wiki context
3. Write `wiki/sources/<slug>.md` — use the source page format below
4. Update `wiki/index.md` — add entry under Sources section
5. Update `wiki/overview.md` — revise synthesis if warranted
6. Update/create entity pages for key people, companies, projects mentioned
7. Update/create concept pages for key ideas and frameworks discussed
8. Flag any contradictions with existing wiki content
9. Append to `wiki/log.md`: `## [YYYY-MM-DD] ingest | <Title>`
### 执行步骤（严格顺序）
1. 使用 Read 工具完整读取待摄取的source文档
2. 读取 `wiki/index.md` 和 `wiki/overview.md`，了解当前 Wiki 上下文
3. 生成 `wiki/sources/<slug>.md`（严格参照下方 Source Page Format）
4. 更新 `wiki/index.md`，在 Sources 节添加新条目（参照下方 Index 格式）
5. 更新 `wiki/overview.md`（如有必要则修订综合摘要）
6. 创建或更新提及的关键人物、公司、项目对应的 Entity 页面（参照下方 Entity（实体））
7. 创建或更新讨论的关键想法和框架对应的 Concept 页面（参照下方 Concept（概念））
8. 检测并记录与现有 Wiki 内容的冲突
9. 追加 `wiki/log.md`（参照下方 Log Format（日志格式））
### Source Page Format
@@ -77,143 +78,174 @@ title: "Source Title"
type: source
tags: []
date: YYYY-MM-DD
source_file: raw/...
---
## Summary
2–4 sentence summary.
## Source File
- [[{{ $json.file.rel_path }}]]
## Key Claims
- Claim 1
- Claim 2
## Summary（用中文描述）
- 核心主题：
- 问题域：
- 方法/机制：
- 结论/价值：
## Key Claims（用中文描述）
- （必须符合：主体 + 机制 + 结果）
## Key Quotes
> "Quote here" — context
> "引用内容" — 上下文说明
## Key Concepts
- [[ConceptName]]：定义
## Key Entities
- [[EntityName]]：角色说明
## Connections
- [[EntityName]] — how they relate
- [[ConceptName]] — how it connects
- [[A]] ← depends_on ← [[B]]
- [[C]] ← extends ← [[D]]
## Contradictions
- Contradicts [[OtherPage]] on: ...
- 与 [[OtherPage]] 冲突：
- 冲突点：
- 当前观点：
- 对方观点：
```
---
### Domain-Specific Templates
## Entity 与 Concept 规则
If the source falls into a specific domain (e.g., personal diary, meeting notes), the agent should use a specialized template instead of the default generic one above:
### Entity（实体）
**创建条件：**
- 出现 ≥ 2 次，或
- 对主题有关键影响
**类型：** 人 / 公司 / 产品 / 项目
---
### Concept（概念）
**创建条件：**
- 可抽象
- 可复用
- 非具体实例
---
### 命名规范（强制）
- 使用唯一标准名称
- 所有别名写入页面：
#### Diary / Journal Template
```markdown
---
title: "YYYY-MM-DD Diary"
type: source
tags: [diary]
date: YYYY-MM-DD
---
## Event Summary
...
## Key Decisions
...
## Energy & Mood
...
## Connections
...
## Shifts & Contradictions
...
```
#### Meeting Notes Template
```markdown
---
title: "Meeting Title"
type: source
tags: [meeting]
date: YYYY-MM-DD
---
## Goal
...
## Key Discussions
...
## Decisions Made
...
## Action Items
...
## Aliases
- GPT4
- GPT-4
```
---
## Query Workflow
### 去重机制（必须）
Triggered by: *"query: <question>"*
Steps:
1. Read `wiki/index.md` to identify relevant pages
2. Read those pages
3. Synthesize an answer with inline citations as `[[PageName]]` wikilinks
4. Ask the user if they want the answer filed as `wiki/syntheses/<slug>.md`
创建前必须：
1. 搜索 index
2. 判断是否已存在同名/近义页面
3. 存在则更新，不存在再新建
---
## Lint Workflow
## 查询工作流（Query Workflow）
Triggered by: *"lint"*
触发方式：*"query: <问题>"*
Check for:
- **Orphan pages** — wiki pages with no inbound `[[links]]` from other pages
- **Broken links** — `[[WikiLinks]]` pointing to pages that don't exist
- **Contradictions** — claims that conflict across pages
- **Stale summaries** — pages not updated after newer sources
- **Missing entity pages** — entities mentioned in 3+ pages but lacking their own page
- **Data gaps** — questions the wiki can't answer; suggest new sources
Output a lint report and ask if the user wants it saved to `wiki/lint-report.md`.
步骤：
1. 读取 `wiki/index.md`，确定相关页面
2. 读取这些页面的内容
3. 综合生成答案，并以 `[[页面名]]` wikilink 形式内联引用来源
4. 询问用户是否将答案保存为 `wiki/syntheses/<slug>.md`
---
## Graph Workflow
## 检查工作流（Lint Workflow）
Triggered by: *"build graph"*
触发方式：*"lint"*
First try: `python tools/build_graph.py --open`
检查项目：
- **孤立页面** —— 没有任何其他页面通过 `[[links]]` 指向它的 Wiki 页面
- **断链** —— `[[WikiLinks]]` 指向不存在的页面
- **内容冲突** —— 跨页面存在相互矛盾的论点
- **过时摘要** —— 有更新来源后未同步更新的页面
- **缺失 Entity 页面** —— 在 3 个以上页面中被提及但没有独立页面的实体
- **数据缺口** —— Wiki 无法回答的问题，建议补充新来源
If Python/deps unavailable, build manually:
1. Search for all `[[wikilinks]]` across wiki pages
2. Build nodes (one per page) and edges (one per link)
3. Infer implicit relationships not captured by wikilinks — tag `INFERRED` with confidence score; low confidence → `AMBIGUOUS`
4. Write `graph/graph.json` with `{nodes, edges, built: date}`
5. Write `graph/graph.html` as a self-contained vis.js visualization
输出检查报告，并询问用户是否保存为 `wiki/lint-report.md`。
---
## Naming Conventions
## 图谱构建工作流（Graph Workflow）
- Source slugs: `kebab-case` matching source filename
- Entity pages: `TitleCase.md` (e.g. `OpenAI.md`, `SamAltman.md`)
- Concept pages: `TitleCase.md` (e.g. `ReinforcementLearning.md`, `RAG.md`)
触发方式：*"build graph"*
## Index Format
优先尝试：`python tools/build_graph.py --open`
若 Python/依赖不可用，则手动构建：
1. 搜索所有 Wiki 页面中的 `[[wikilinks]]`
2. 构建节点（每页一个）和边（每个链接一条）
3. 推断 wikilink 未捕获的隐式关系 —— 标记为 `INFERRED` 并附置信度；低置信度 → `AMBIGUOUS`
4. 写入 `graph/graph.json`，格式：`{nodes, edges, built: date}`
5. 写入 `graph/graph.html`，作为独立的 vis.js 可视化文件
---
## 命名规范
- Source slug：`kebab-case`，与源文件名保持一致
- Entity 页面：`TitleCase.md`（如 `OpenAI.md`、`SamAltman.md`）
- Concept 页面：`TitleCase.md`（如 `ReinforcementLearning.md`、`RAG.md`）
## Index 格式
```markdown
# Wiki Index
## Overview
- [Overview](overview.md) — living synthesis
- [Overview](overview.md) — 动态综合摘要
## Sources
- [Source Title](sources/slug.md) — one-line summary
- [来源标题](sources/slug.md) — 一行摘要
## Entities
- [Entity Name](entities/EntityName.md) — one-line description
- [实体名称](entities/EntityName.md) — 一行描述
## Concepts
- [Concept Name](concepts/ConceptName.md) — one-line description
- [概念名称](concepts/ConceptName.md) — 一行描述
## Syntheses
- [Analysis Title](syntheses/slug.md) — what question it answers
- [分析标题](syntheses/slug.md) — 回答了什么问题
```
## Log Format
## Log Format（日志格式）
`## [YYYY-MM-DD] <operation> | <title>`
```
## [YYYY-MM-DD] ingest | 标题
- Source file: {{ $json.file.rel_path }}
- Status: ✅ 成功摄入
- Summary:
- Concepts created: xxx, xxx
- Source page: {{ $json.file.source_path }}
- Notes:
```
Operations: `ingest`, `query`, `lint`, `graph`
操作类型：`ingest`、`query`、`lint`、`graph`
---
## 最终目标
该系统用于：
- 知识沉淀
- 结构化理解
- 自动图谱构建
- Agent 推理支持

219
AGENTS.md.bak Normal file
View File

@@ -0,0 +1,219 @@
# LLM Wiki Agent — Schema & Workflow Instructions
This wiki is maintained entirely by your coding agent. No API key or Python scripts needed — just open this repo in Codex, OpenCode, or any agent that reads this file, and talk to it.
## How to Use
Describe what you want in plain English:
- *"Ingest this file: raw/papers/my-paper.md"*
- *"What does the wiki say about transformer models?"*
- *"Check the wiki for orphan pages and contradictions"*
- *"Build the knowledge graph"*
Or use shorthand triggers:
- `ingest <file>` → runs the Ingest Workflow
- `query: <question>` → runs the Query Workflow
- `lint` → runs the Lint Workflow
- `build graph` → runs the Graph Workflow
---
## Directory Layout
```
raw/ # Immutable source documents — never modify these
wiki/ # Agent owns this layer entirely
index.md # Catalog of all pages — update on every ingest
log.md # Append-only chronological record
overview.md # Living synthesis across all sources
sources/ # One summary page per source document
entities/ # People, companies, projects, products
concepts/ # Ideas, frameworks, methods, theories
syntheses/ # Saved query answers
graph/ # Auto-generated graph data
tools/ # Optional standalone Python scripts (require ANTHROPIC_API_KEY)
```
---
## Page Format
Every wiki page uses this frontmatter:
```yaml
---
title: "Page Title"
type: source | entity | concept | synthesis
tags: []
sources: [] # list of source slugs that inform this page
last_updated: YYYY-MM-DD
---
```
Use `[[PageName]]` wikilinks to link to other wiki pages.
---
## Ingest Workflow
Triggered by: *"ingest <file>"*
Steps (in order):
1. Read the source document fully
2. Read `wiki/index.md` and `wiki/overview.md` for current wiki context
3. Write `wiki/sources/<slug>.md` — use the source page format below
4. Update `wiki/index.md` — add entry under Sources section
5. Update `wiki/overview.md` — revise synthesis if warranted
6. Update/create entity pages for key people, companies, projects mentioned
7. Update/create concept pages for key ideas and frameworks discussed
8. Flag any contradictions with existing wiki content
9. Append to `wiki/log.md`: `## [YYYY-MM-DD] ingest | <Title>`
### Source Page Format
```markdown
---
title: "Source Title"
type: source
tags: []
date: YYYY-MM-DD
source_file: raw/...
---
## Summary
2–4 sentence summary.
## Key Claims
- Claim 1
- Claim 2
## Key Quotes
> "Quote here" — context
## Connections
- [[EntityName]] — how they relate
- [[ConceptName]] — how it connects
## Contradictions
- Contradicts [[OtherPage]] on: ...
```
### Domain-Specific Templates
If the source falls into a specific domain (e.g., personal diary, meeting notes), the agent should use a specialized template instead of the default generic one above:
#### Diary / Journal Template
```markdown
---
title: "YYYY-MM-DD Diary"
type: source
tags: [diary]
date: YYYY-MM-DD
---
## Event Summary
...
## Key Decisions
...
## Energy & Mood
...
## Connections
...
## Shifts & Contradictions
...
```
#### Meeting Notes Template
```markdown
---
title: "Meeting Title"
type: source
tags: [meeting]
date: YYYY-MM-DD
---
## Goal
...
## Key Discussions
...
## Decisions Made
...
## Action Items
...
```
---
## Query Workflow
Triggered by: *"query: <question>"*
Steps:
1. Read `wiki/index.md` to identify relevant pages
2. Read those pages
3. Synthesize an answer with inline citations as `[[PageName]]` wikilinks
4. Ask the user if they want the answer filed as `wiki/syntheses/<slug>.md`
---
## Lint Workflow
Triggered by: *"lint"*
Check for:
- **Orphan pages** — wiki pages with no inbound `[[links]]` from other pages
- **Broken links** — `[[WikiLinks]]` pointing to pages that don't exist
- **Contradictions** — claims that conflict across pages
- **Stale summaries** — pages not updated after newer sources
- **Missing entity pages** — entities mentioned in 3+ pages but lacking their own page
- **Data gaps** — questions the wiki can't answer; suggest new sources
Output a lint report and ask if the user wants it saved to `wiki/lint-report.md`.
---
## Graph Workflow
Triggered by: *"build graph"*
First try: `python tools/build_graph.py --open`
If Python/deps unavailable, build manually:
1. Search for all `[[wikilinks]]` across wiki pages
2. Build nodes (one per page) and edges (one per link)
3. Infer implicit relationships not captured by wikilinks — tag `INFERRED` with confidence score; low confidence → `AMBIGUOUS`
4. Write `graph/graph.json` with `{nodes, edges, built: date}`
5. Write `graph/graph.html` as a self-contained vis.js visualization
---
## Naming Conventions
- Source slugs: `kebab-case` matching source filename
- Entity pages: `TitleCase.md` (e.g. `OpenAI.md`, `SamAltman.md`)
- Concept pages: `TitleCase.md` (e.g. `ReinforcementLearning.md`, `RAG.md`)
## Index Format
```markdown
# Wiki Index
## Overview
- [Overview](overview.md) — living synthesis
## Sources
- [Source Title](sources/slug.md) — one-line summary
## Entities
- [Entity Name](entities/EntityName.md) — one-line description
## Concepts
- [Concept Name](concepts/ConceptName.md) — one-line description
## Syntheses
- [Analysis Title](syntheses/slug.md) — what question it answers
```
## Log Format
`## [YYYY-MM-DD] <operation> | <title>`
Operations: `ingest`, `query`, `lint`, `graph`

3218
tools/manifest.json
View File

File diff suppressed because it is too large Load Diff

456
tools/sync.py
View File

@@ -1,33 +1,221 @@
#!/usr/bin/env python3
"""
Wiki ↔ Raw 三向同步工具
================================================================================
功能：
- 检测 raw/ 下文件变化（新增/修改/删除）
- 维护 manifest.json 状态映射
- 检测 orphan entity/concept（仅报告，不删除）
概述
----
本脚本负责维护 raw/（原始文档层）与 wiki/（知识库层）之间的同步状态。
它通过 tools/manifest.json 追踪每个 raw 文件的哈希、摄取状态和 slug 映射，
让编码代理（agent）能准确知道哪些文件需要被（重新）摄取到 wiki。
用法：
python tools/sync.py --check 预览变化（不执行）
python tools/sync.py --sync 执行同步（更新 manifest）
python tools/sync.py --pending 显示待处理文件列表
python tools/sync.py --json JSON 行输出（供程序消费）
python tools/sync.py --rebuild 从 manifest 重建 wiki/index（兜底）
核心功能
--------
1. 扫描 raw/ 下的 .md 文件，与 manifest 对比，检测新增/删除（不再自动检测 updated）
2. 维护 tools/manifest.json 状态映射（hash、slug、ingested 等）
3. 标记单个文件为"已摄取"，供摄取流程回调
4. 批量规范化 manifest 中的 slug（reslug）
5. 从 manifest 重建 wiki/index.md（兜底方案）
6. 检测 orphan entity/concept（仅报告，不删除）
7. 批量或单条修正 source 页面中的 Source File link（对齐 manifest 的 raw 路径）
manifest.json 格式：
--------------------------------------------------------------------------------
CLI 用法
--------------------------------------------------------------------------------
基础操作：
python tools/sync.py --check
预览 raw/ 与 manifest 的差异（新增/删除），不写入任何文件。
输出为 Markdown 格式，适合人工阅读。
python tools/sync.py --sync
执行完整同步：将 raw/ 的变化写入 manifest，并报告 orphan 页面。
当前默认仅处理新增/删除，不会因为已存在文件内容变化而自动重置 ingested。
python tools/sync.py --sync -v / --verbose
同上，但额外列出每个新增/删除文件的详情，以及 orphan 清单。
python tools/sync.py --pending
列出 manifest 中所有 ingested=false 的待摄取文件（人类可读格式）。
python tools/sync.py --pending --json
以单行 JSON 输出待摄取列表，供脚本/agent 消费。
python tools/sync.py --pending --json --limit 1
只返回第一条待摄取文件（返回 "file" 字段而非 "files" 数组）。
python tools/sync.py --pending --json --limit N
返回前 N 条待摄取文件（返回 "files" 数组）。
python tools/sync.py --json
与 --sync 配合：使用 JSON 行流模式输出所有事件，便于程序解析。
python tools/sync.py --rebuild
从 manifest 重建 wiki/index.md。适合 index 损坏或丢失时的兜底恢复。
Source File link 修正：
python tools/sync.py --fix-source-links
扫描 manifest 中所有条目，批量修正对应 source 页面里 `## Source File` 下的链接。
目标格式统一为：- [[raw/.../your-file.md]]
python tools/sync.py --fix-source-links --fix-source-target "raw/dir/file.md"
只修正指定 raw 条目对应的单个 source 页面（适合每次 ingest 后做单文件校验）。
python tools/sync.py --fix-source-links --dry-run
预览将要修改的数量，不写入文件。
标记摄取状态：
python tools/sync.py --mark-ingested "raw/dir/file.md" --slug my-slug
标记指定 raw 文件为已摄取，同时更新 slug、source_path、ingested_at。
该命令是摄取工作流的最后一步，应在 wiki/sources/<slug>.md 写入完毕后调用。
python tools/sync.py --mark-ingested "raw/dir/file.md" --slug my-slug --mark-json
同上，但以单行 JSON 输出结果（供脚本消费）。
python tools/sync.py --reset-failed
将所有带 error 标记的 manifest 条目重置为 ingested=false（重新加入待处理队列）。
slug 管理：
python tools/sync.py --reslug
批量规范化 manifest 中全部条目的 slug 和 source_path。
规则：中文直接保留，ASCII 大写转小写，特殊字符转 `-`，压缩连续 `-`。
python tools/sync.py --reslug --reslug-target "raw/dir/file.md"
只规范化指定文件的 slug。
python tools/sync.py --reslug --dry-run
预览 reslug 变更，不写入 manifest。
--------------------------------------------------------------------------------
manifest.json 格式
--------------------------------------------------------------------------------
路径：tools/manifest.json（与本脚本同目录）
顶层结构：
{
"version": 1,
"updated_at": "ISO timestamp",
"files": {
"relative/path/to/file.md": {
"hash": "sha256",
"modified": "ISO timestamp",
"slug": "wiki-source-slug",
"source_path": "wiki/sources/slug.md",
"ingested": true
}
"version": 1, // 格式版本，当前固定为 1
"updated_at": "2024-01-15T08:00:00Z", // 最后更新时间（UTC ISO 8601），每次写入自动刷新
"files": { ... } // key = raw 文件相对仓库根的路径
}
files 中每条记录的结构：
{
"raw/dir/my-paper.md": {
"hash": "a3f1c2d4e5b6a7b8", // sha256 前 16 位，用于检测文件内容变化
"modified": "2024-01-15T07:00:00Z", // raw 文件的 mtime（UTC ISO 8601）
"slug": "my-paper", // wiki 页面 slug，用于生成 source_path
"source_path": "wiki/sources/my-paper.md", // 对应的 wiki source 页面路径
"ingested": true, // false = 待摄取；true = 已摄取
"ingested_at": "2024-01-15T08:00:00Z", // 摄取完成时间（null 表示未摄取）
"error": "..." // 可选，摄取失败时记录错误信息
}
}
状态流转：
新文件被 --sync 检测到
→ ingested=false, ingested_at=null
摄取工作流完成后调用 --mark-ingested
→ ingested=true, ingested_at=<当前 UTC 时间>
当前默认同步策略不自动处理“已存在文件内容变化”
→ 已摄取文件不会因 updated 检测而自动重置（避免重复 ingest）
摄取失败时由外部流程写入 error 字段
→ 使用 --reset-failed 清除，重回待处理队列
--------------------------------------------------------------------------------
JSON 输出格式（--json / --mark-json / --pending --json）
--------------------------------------------------------------------------------
每行输出一个独立 JSON 对象（JSON Lines 格式），可能的 event 类型：
{"event": "pending", "rel_path": "...", "slug": "...", "action": "new"}
{"event": "deleted_detected","rel_path": "..."}
{"event": "sync_complete", "summary": {"pending": N, "deleted": N, "manifest_entries": N},
"pending_files": [...], "deleted_files": [...]}
{"event": "pending_list", "count": N, "files": [...]} // --pending --json --limit N
{"event": "pending_list", "count": N, "file": {...}} // --pending --json --limit 1
{"event": "mark_ingested", "rel_path": "...", "slug": "...",
"source_path": "...", "modified": "...", "ingested_at": "..."}
{"event": "fix_source_links_complete", "summary": {...}, "details": [...]}
{"event": "error", "message": "..."}
--------------------------------------------------------------------------------
内部函数说明
--------------------------------------------------------------------------------
sha256_file(path)
计算文件 sha256，返回前 16 位十六进制字符串，用于快速变化检测。
load_manifest() / save_manifest(manifest)
读写 tools/manifest.json；文件不存在或损坏时返回空白 manifest。
scan_raw()
递归扫描 raw/ 下所有 .md 文件，返回 {rel_path: {hash, modified, size, abs_path}}。
build_slug_from_path(rel_path)
从 raw 文件路径生成基础 slug（保留中文，空格/特殊字符转 `-`）。
注意：--reslug 使用更严格的 _compute_normalized_slug() 规则。
check_changes(manifest, raw_files)
对比 manifest 与实际文件，当前默认返回新增/删除为主（updated 关闭）。
run_sync(dry_run, verbose, json_mode)
执行完整同步逻辑，更新 manifest，并触发 orphan 检测报告。
run_check()
只读比对，以 Markdown 格式打印差异报告，不修改任何文件。
run_rebuild()
遍历 manifest 中全部条目，重建 wiki/index.md，同时做容错路径匹配和 orphan 检测。
find_orphan_entity_concept(manifest)
扫描 wiki/sources/*.md 中的 [[wikilinks]]，找出未被引用的 entity/concept 页面。
mark_ingested(rel_path, slug, json_mode)
将指定 raw 文件标记为已摄取，更新 slug、source_path、hash、ingested_at。
rel_path 必须已存在于 manifest（先 --sync 再 --mark-ingested）。
run_reslug(target_rel_path, dry_run)
批量（或单条）规范化 manifest 中的 slug/source_path，
使用 _compute_normalized_slug() 规则处理特殊字符。
run_fix_source_links(target_rel_path, dry_run, json_mode)
基于 manifest 修正 source 页面 `## Source File` 下的 raw 路径链接；
支持全量和单文件模式。
_compute_normalized_slug(rel_path)
规范化 slug 的核心规则：
a. 中文字符直接保留
b. ASCII 大写字母转小写
c. 空格、标点、特殊符号替换为 `-`
d. 连续多个 `-` 压缩为单个，首尾 `-` 去除
--------------------------------------------------------------------------------
典型工作流（供 agent 参考）
--------------------------------------------------------------------------------
1. 检查有无待摄取文件：
python tools/sync.py --pending --json --limit 1
2. 同步 raw 变化到 manifest：
python tools/sync.py --sync
3. 摄取完成后标记：
python tools/sync.py --mark-ingested "raw/papers/my-paper.md" --slug my-paper
4. 修复 slug 命名：
python tools/sync.py --reslug --dry-run # 预览
python tools/sync.py --reslug # 应用
5. 批量修正 Source File link：
python tools/sync.py --fix-source-links --dry-run
python tools/sync.py --fix-source-links
6. ingest 后单文件校验：
python tools/sync.py --fix-source-links --fix-source-target "raw/papers/my-paper.md"
7. index 损坏时重建：
python tools/sync.py --rebuild
"""
import json
@@ -166,20 +354,20 @@ def find_orphan_entity_concept(manifest: dict) -> tuple[list, list]:
# ─── 核心同步逻辑 ───────────────────────────────────────────────
def check_changes(manifest: dict, raw_files: dict) -> dict:
"""对比 manifest 和实际 raw 文件，返回变化"""
"""对比 manifest 和实际 raw 文件，返回变化。
当前策略（按需求收敛）：
- 仅检测 new / deleted
- 不再基于 hash 检测 updated（避免仅 mtime 变化导致重复 ingest）
"""
changes = {"new": [], "updated": [], "deleted": [], "unchanged": []}
manifest_files = manifest.get("files", {})
for rel_path, info in raw_files.items():
if rel_path not in manifest_files:
changes["new"].append({"rel_path": rel_path, **info})
elif info["hash"] != manifest_files[rel_path]["hash"]:
changes["updated"].append({
"rel_path": rel_path,
"old_hash": manifest_files[rel_path]["hash"],
**info,
})
else:
# 按新策略：已有文件一律视作 unchanged，不再进入 updated
changes["unchanged"].append(rel_path)
for rel_path in manifest_files:
@@ -242,20 +430,41 @@ def run_sync(dry_run: bool = False, verbose: bool = False, json_mode: bool = Fal
updated_manifest = manifest.copy()
updated_manifest["files"] = manifest.get("files", {}).copy()
pending_files = []
recovered_files = []
for f in new:
rel_path = f["rel_path"]
slug = build_slug_from_path(rel_path)
source_path = f"wiki/sources/{slug}.md"
source_file = WIKI_DIR / "sources" / f"{slug}.md"
# 检测 wiki/sources/<slug>.md 是否已存在（manifest 被删除后的恢复场景）
already_ingested = source_file.exists()
ingested_at = None
if already_ingested:
# 用 source 文件的 mtime 作为 ingested_at 的近似值
try:
ingested_at = datetime.fromtimestamp(source_file.stat().st_mtime, tz=timezone.utc).isoformat()
except Exception:
ingested_at = iso_now()
if json_mode:
print(json.dumps({"event": "pending", "rel_path": rel_path, "slug": slug, "action": "new"}))
pending_files.append({"rel_path": rel_path, "abs_path": f["abs_path"], "slug": slug, "action": "new"})
action = "recovered" if already_ingested else "new"
print(json.dumps({"event": "pending" if not already_ingested else "recovered", "rel_path": rel_path, "slug": slug, "action": action}))
if not already_ingested:
pending_files.append({"rel_path": rel_path, "abs_path": f["abs_path"], "slug": slug, "action": "new"})
else:
recovered_files.append({"rel_path": rel_path, "slug": slug, "source_path": source_path})
if verbose and not json_mode:
print(f" ↺ Recovered (source exists): {rel_path} → {source_path}")
updated_manifest["files"][rel_path] = {
"hash": f["hash"],
"modified": f.get("modified"),
"slug": slug,
"source_path": f"wiki/sources/{slug}.md",
"ingested": False,
"ingested_at": None,
"source_path": source_path,
"ingested": already_ingested,
"ingested_at": ingested_at,
}
for f in updated:
@@ -290,6 +499,7 @@ def run_sync(dry_run: bool = False, verbose: bool = False, json_mode: bool = Fal
"event": "sync_complete",
"summary": {
"pending": len(pending_files),
"recovered": len(recovered_files),
"deleted": len(deleted_files),
"manifest_entries": len(updated_manifest["files"]),
},
@@ -298,6 +508,8 @@ def run_sync(dry_run: bool = False, verbose: bool = False, json_mode: bool = Fal
}))
else:
log(f"manifest.json updated ({len(updated_manifest['files'])} entries)", "success")
if recovered_files:
log(f"Recovered (source page exists): {len(recovered_files)}", "info")
if verbose:
log(f"Pending files for ingestion: {len(pending_files)}", "info")
@@ -385,7 +597,7 @@ def run_rebuild():
]
files = manifest.get("files", {})
sorted_files = sorted(files.items(), key=lambda x: x[1].get("modified", ""), reverse=True)
sorted_files = sorted(files.items(), key=lambda x: (x[1].get("ingested_at") or "", x[1].get("modified", "")), reverse=True)
import re
@@ -449,12 +661,12 @@ def run_rebuild():
src_file = find_source_file(slug, info, rel_path)
# 从 manifest 的 modified 字段提取日期前缀（格式 YYYY-MM-DD）
modified_raw = info.get("modified", "")
# 从 manifest 的 ingested_at 字段提取日期前缀（格式 YYYY-MM-DD），未摄取则留空
date_raw = info.get("ingested_at") or ""
date_prefix = ""
if modified_raw:
if date_raw:
try:
date_prefix = f"[{modified_raw[:10]}] "
date_prefix = f"[{date_raw[:10]}] "
except Exception:
date_prefix = ""
@@ -529,6 +741,158 @@ def run_rebuild():
print(f"\nDone.")
# ─── 管理接口：修正 source 页面中的 Source File link ─────────────────────────────────────
def _fix_source_file_link_in_content(content: str, raw_rel_path: str) -> tuple[str, bool, str]:
"""修正单个 source 页面中的 `## Source File` 区块。
目标格式：
## Source File
- [[raw/.../file.md]]
返回： (new_content, changed, action)
action ∈ {"unchanged", "updated", "inserted_line", "inserted_section"}
"""
expected_line = f"- [[{raw_rel_path}]]"
lines = content.splitlines()
had_trailing_newline = content.endswith("\n")
# 1) 找 `## Source File` 标题
heading_idx = None
for i, line in enumerate(lines):
if line.strip().lower() == "## source file":
heading_idx = i
break
# 2) 没有区块：插入一个完整区块（优先插到 frontmatter 之后）
if heading_idx is None:
insert_at = 0
if lines and lines[0].strip() == "---":
for j in range(1, len(lines)):
if lines[j].strip() == "---":
insert_at = j + 1
while insert_at < len(lines) and lines[insert_at].strip() == "":
insert_at += 1
break
block = ["## Source File", expected_line, ""]
new_lines = lines[:insert_at] + block + lines[insert_at:]
new_content = "\n".join(new_lines)
if had_trailing_newline or new_content:
new_content += "\n"
return new_content, True, "inserted_section"
# 3) 在 `## Source File` 到下一个二级标题之间找第一条列表项
section_end = len(lines)
for j in range(heading_idx + 1, len(lines)):
if lines[j].startswith("## "):
section_end = j
break
bullet_idx = None
for j in range(heading_idx + 1, section_end):
if lines[j].strip().startswith("- "):
bullet_idx = j
break
if bullet_idx is None:
# 没有列表项，直接插入标准链接行
lines.insert(heading_idx + 1, expected_line)
new_content = "\n".join(lines)
if had_trailing_newline or new_content:
new_content += "\n"
return new_content, True, "inserted_line"
# 4) 有列表项：替换成 manifest 对应的 raw 路径
current = lines[bullet_idx].strip()
if current == expected_line:
return content, False, "unchanged"
lines[bullet_idx] = expected_line
new_content = "\n".join(lines)
if had_trailing_newline or new_content:
new_content += "\n"
return new_content, True, "updated"
def run_fix_source_links(target_rel_path: str = None, dry_run: bool = False, json_mode: bool = False):
"""基于 manifest，校正 source 页面中的 Source File link。
- 不传 target_rel_path：扫描并修正所有条目
- 传 target_rel_path：只处理单个 raw 条目（适合 ingest 后单文件校验）
"""
manifest = load_manifest()
files = manifest.get("files", {})
if target_rel_path:
if target_rel_path not in files:
msg = f"target not found in manifest: {target_rel_path}"
if json_mode:
print(json.dumps({"event": "error", "message": msg}))
else:
print(red(f" ✗ {msg}"))
raise SystemExit(1)
targets = [(target_rel_path, files[target_rel_path])]
else:
targets = list(files.items())
changed = 0
unchanged = 0
skipped_no_source_path = 0
skipped_source_missing = 0
details = []
for rel_path, info in targets:
source_path = info.get("source_path")
if not source_path:
skipped_no_source_path += 1
details.append({"rel_path": rel_path, "status": "skipped_no_source_path"})
continue
src_file = REPO_ROOT / source_path
if not src_file.exists():
skipped_source_missing += 1
details.append({"rel_path": rel_path, "source_path": source_path, "status": "skipped_source_missing"})
continue
original = src_file.read_text(encoding="utf-8")
new_content, did_change, action = _fix_source_file_link_in_content(original, rel_path)
if did_change:
changed += 1
if not dry_run:
src_file.write_text(new_content, encoding="utf-8")
details.append({"rel_path": rel_path, "source_path": source_path, "status": "changed", "action": action})
else:
unchanged += 1
details.append({"rel_path": rel_path, "source_path": source_path, "status": "unchanged"})
summary = {
"scanned": len(targets),
"changed": changed,
"unchanged": unchanged,
"skipped_no_source_path": skipped_no_source_path,
"skipped_source_missing": skipped_source_missing,
"dry_run": dry_run,
}
if json_mode:
print(json.dumps({"event": "fix_source_links_complete", "summary": summary, "details": details}, ensure_ascii=False))
return
print(f"\n{bold('=== Fix Source File Links')}\n")
print(f" Scanned : {summary['scanned']}")
print(f" Changed : {summary['changed']}")
print(f" Unchanged : {summary['unchanged']}")
print(f" Skipped (no source_path): {summary['skipped_no_source_path']}")
print(f" Skipped (source missing): {summary['skipped_source_missing']}")
if dry_run:
print(f" {yellow('⚠')} Dry-run only, no file written.")
else:
print(f" {green('✓')} Source File links corrected.")
print()
# ─── 管理接口：reslug（批量规范化 manifest slug） ──────────────────────────────────────
def _compute_normalized_slug(rel_path: str) -> str:
@@ -789,6 +1153,16 @@ if __name__ == "__main__":
default=None,
help="与 --pending --json 配合：限制返回条目数（默认返回全部）",
)
parser.add_argument(
"--fix-source-links",
action="store_true",
help="基于 manifest 修正 source 页面 `## Source File` 下的 raw 路径链接",
)
parser.add_argument(
"--fix-source-target",
metavar="REL_PATH",
help="与 --fix-source-links 配合：仅修正单个 raw 条目（例如 'raw/AI/file.md'）",
)
parser.add_argument(
"--reslug",
action="store_true",
@@ -810,6 +1184,12 @@ if __name__ == "__main__":
if args.mark_ingested:
rel = args.mark_ingested[0]
mark_ingested(rel, slug=args.slug, json_mode=args.mark_json)
elif args.fix_source_links:
run_fix_source_links(
target_rel_path=args.fix_source_target,
dry_run=args.dry_run,
json_mode=args.json,
)
elif args.reslug:
run_reslug(target_rel_path=args.reslug_target, dry_run=args.dry_run)
elif args.rebuild:

1
wiki
View File

@@ -1 +0,0 @@
/Users/weishen/Workspace/nexus/wiki

761
wiki/log.md Normal file
View File

@@ -0,0 +1,761 @@
## [2026-05-06] ingest | Project Shepherd Agent Personality
- Source file: Agent/agency-agents/project-management/project-management-project-shepherd.md
- Status: ✅ 成功摄入
- Summary: Project Shepherd Agent 完整摄取——The Agency 项目管理部门的跨职能项目协调与利益相关方对齐专家 Agent。核心方法论：项目章程模板（问题陈述/目标/范围/成功标准 + 利益相关方分析/沟通计划/资源需求/风险评估）、四阶段工作流（项目启动与规划→团队组建与启动→执行协调与监控→质量保证与交付）。关键交付物：Project Charter、Project Status Report（绿/黄/红健康状态）。成功指标：95% 项目按时在预算内交付、利益相关方满意度 4.5/5、范围蔓延 < 10%、90% 已识别风险成功缓解。沟通原则：透明报告、聚焦解决方案、绝不承诺不切实际时间线。
- Concepts created: Project-Management-Project-Shepherd
- Source page: wiki/sources/project-management-project-shepherd.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/project-management-project-shepherd.md）；步骤4完成：index.md 新增 Source 条目和 Concept 条目；步骤5完成：overview.md Project Management 部门新增独立条目（Line 148）；步骤6完成：entities/ 和 concepts/ 目录存在，Project Shepherd 作为方法论概念创建 Concept 页面；步骤7完成：创建 wiki/concepts/Project-Management-Project-Shepherd.md；步骤8完成：与 [[ProjectManagerSenior]]（执行层任务分解）和 [[Project-Management-Studio-Operations]]（运营支撑）层级差异已记录至 source page Contradictions 节；步骤9完成：log.md 追加记录
## [2026-05-29] ingest | visionOS Spatial Engineer
- Source file: Agent/agency-agents/spatial-computing/visionos-spatial-engineer.md
- Status: ✅ 成功摄入
- Summary: visionOS Spatial Engineer Agent 完整摄取——visionOS 26 原生空间计算专家智能体，专注于 SwiftUI volumetric interfaces 和 Liquid Glass Design System 实现。核心能力：Liquid Glass 透明材质（自适应 light/dark 环境）、Spatial Widgets（吸附墙面/桌面、持久化放置）、SwiftUI Volumetric APIs（3D 内容集成、volume transient content、breakthrough UI）、RealityKit-SwiftUI 集成（Observable entities、直接手势处理、ViewAttachmentComponent）、Multi-Window Architecture（WindowGroup 管理、玻璃背景效果）、GPU 高效渲染（Metal）。技术栈：SwiftUI / RealityKit / ARKit / Metal。局限：不支持 Unity 或其他 3D 框架、不涉及跨平台空间解决方案、依赖 visionOS 26 新特性。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均已存在于 wiki：Liquid Glass Design System/Multi-Window Architecture/RealityKit-SwiftUI Integration/Spatial Widgets/SwiftUI Volumetric APIs）
- Source page: wiki/sources/visionos-spatial-engineer.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 已有对应条目（Line 407），无需修改；步骤5完成：overview.md 已有 visionOS Spatial Engineer 摘要（Line 134），无需修订；步骤6完成：Apple/Vision Pro/SwiftUI/RealityKit 均为跨文档高频实体，未达到单一文档内独立建页阈值；步骤7完成：Concept 均已存在独立页面；步骤8完成：与 [[xr-immersive-developer]] 可能存在技术路径分歧（平台锁定 vs 跨平台），已记录至 source page Contradictions 节；步骤9完成：log.md 追加记录
## [2026-05-02] 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 完整摄取——Swift + Metal 渲染专家智能体，专注于高性能 3D 渲染系统和 visionOS 空间计算体验。核心能力：Instanced Metal Rendering（10k-100k 节点，90fps 立体渲染）；Compositor Services（LayerRenderer stereo 模式 + RGBA16Float + Depth32Float）帧流传输到 Vision Pro；Metal Compute Shader GPU 并行力导向图物理模拟；Gaze + Pinch 空间交互 + raycast hit testing。性能约束：GPU 利用率 < 80%、每帧 < 100 draw calls、内存 < 1GB。技术栈：Swift / Metal / CompositorServices / RealityKit / ARKit / Metal System Trace / Instruments。属 The Agency Spatial Computing 部门，与 [[visionos-spatial-engineer]]（visionOS 原生空间计算）和 [[xr-immersive-developer]]（WebXR 跨平台沉浸式开发）形成完整技术覆盖矩阵。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Metal/Vision Pro Compositor Services/RemoteImmersiveSpace/Instanced Rendering/Force-Directed Graph Layout/Frustum Culling/Stereoscopic Rendering）
- Source page: wiki/sources/macos-spatial-metal-engineer.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/macos-spatial-metal-engineer.md）；步骤4完成：index.md 已有对应条目（Line 7），已添加；步骤5完成：overview.md 已有 macOS Spatial/Metal Engineer 相关摘要（Line 132），无需修订；步骤6完成：Entity 未达到独立建页阈值（Apple/Vision Pro/Xcode 等仅在本文档中出现）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：无内容冲突；步骤9完成：log.md 追加记录
## [2026-04-30] ingest | Studio Producer Agent Personality
- Source file: Agent/agency-agents/project-management/project-management-studio-producer.md
- Status: ✅ 成功摄入
- Summary: Studio Producer Agent 完整摄取——The Agency 项目管理部门的战略组合管理专家 Agent，定位为创意工作室的高管级战略领导者。核心职责：战略组合规划（Tier 1/2/Innovation Pipeline 三级分级）、Portfolio ROI 管理（要求 ≥ 25%）、95% 按时交付、高管级利益相关者沟通。四阶段工作流：战略规划→项目编排→领导力发展→绩效优化。高级能力：并购战略、国际市场进入规划、AI 技术整合、董事会关系管理。与 [[ProjectManagerSenior]]（执行层）形成层级互补，与 [[StudioOperations]]（运营层）协同执行。与其他 Project Management Agents 共同构成 The Agency 项目管理部门的完整体系。
- Concepts created: Strategic Portfolio Management
- Source page: wiki/sources/project-management-studio-producer.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/project-management-studio-producer.md）；步骤4完成：index.md 已有对应条目（Line 410），新增 Concept 条目 Strategic Portfolio Management；步骤5完成：overview.md 已有相关摘要（Line 141），无需修订；步骤6完成：Studio Producer 为 Agent 角色定义，无外部实体关联，无需创建 Entity 页面；步骤7完成：创建 [[Strategic-Portfolio-Management]] Concept 页面；步骤8完成：与 [[ProjectManagerSenior]] 的层级关系差异已记录（source page Contradictions 节）；步骤9完成：log.md 追加记录
## [2026-04-29] ingest | Terminal Integration Specialist
- Source file: Agent/agency-agents/spatial-computing/terminal-integration-specialist.md
- Status: ✅ 成功摄入
- Summary: Terminal Integration Specialist Agent 完整摄取——专注于终端仿真、文本渲染优化与 SwiftTerm 集成，面向现代 Swift 应用程序的 AI Agent 个性化定义。核心技术栈：SwiftTerm（MIT）、Core Graphics/Core Text 文本渲染、SwiftNIO SSH/NMSSH。核心能力：VT100/xterm 标准兼容（ANSI 转义序列）、SwiftUI 生命周期管理、Core Graphics 性能优化、SSH I/O 桥接与会话管理。平台覆盖：iOS、macOS、visionOS。局限：仅限 SwiftTerm、仅限客户端仿真、仅限 Apple 平台。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：VT100/xterm Standards/ANSI Escape Sequences/Core Graphics 文本渲染/SwiftUI 生命周期管理/SSH I/O 桥接）
- Source page: wiki/sources/terminal-integration-specialist.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 已有对应条目（Line 406），无需修改；步骤5完成：overview.md 属于 Agent 个性化定义，暂不修改；步骤6完成：SwiftTerm/SwiftNIO SSH 等实体仅出现1次，未达到独立建页阈值（≥2次）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：无内容冲突；步骤9完成：log.md 追加记录
## [2026-05-18] ingest | XR Immersive Developer Agent Personality
- Source file: Agent/agency-agents/spatial-computing/xr-immersive-developer.md
- Status: ✅ 成功摄入
- Summary: XR Immersive Developer Agent 完整摄取——WebXR 沉浸式开发专家智能体，专注浏览器环境下跨平台 AR/VR/XR 体验构建。核心栈：A-Frame / Three.js / Babylon.js；核心能力：WebXR Device API 全套沉浸式支持（hand tracking / pinch / gaze / controller input）、raycasting / hit testing / 实时物理交互、LOD 系统 / occlusion culling / shader tuning 性能优化、跨设备兼容层（Meta Quest / Vision Pro / HoloLens / mobile AR）、模块化组件驱动设计及优雅降级。典型交付物：VR 训练模拟器、AR 可视化界面、空间界面。与 xr-interface-architect 和 xr-cockpit-interaction-specialist 同属 Spatial Computing 部门，共同构建 XR 产品交互基础设施。与 xr-cockpit-interaction-specialist 在运动自由度设计上存在张力（开放空间沉浸 vs 固定视角约束）。
- Concepts created: WebXR.md、A-Frame.md、Three.js.md、Babylon.js.md、Raycasting.md、Hit-Testing.md、LOD-Systems.md、Occlusion-Culling.md（均以 wikilinks 形式记录于 source page，实体未达独立建页阈值）
- Source page: wiki/sources/xr-immersive-developer.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md（XR 相关内容已在 line 126-134）；步骤3完成：生成 source page（wiki/sources/xr-immersive-developer.md）；步骤4完成：index.md 已有对应条目（Line 404），无需修改；步骤5完成：overview.md 已有相关 XR 段落（Line 126-134），无需修订；步骤6完成：Entity 未达到独立建页阈值（The Agency/Spatial Computing 等均在多处出现，有独立页面）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：与 xr-cockpit-interaction-specialist 在运动自由度设计上存在张力，已记录于 Contradictions；步骤9完成：log.md 追加记录
## [2026-05-18] 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 完整摄取——专注于沉浸式座舱环境控件设计，通过固定视角锚定降低晕动症，支持手势/语音/凝视/物理道具多模态输入，采用 A-Frame/Three.js 原型开发，约束驱动机制消除自由浮动。典型应用：模拟指挥中心、航天器座舱、XR 载具界面、训练模拟器。
- Concepts created: Cockpit-Ergonomics.md、Constraint-Driven-Control-Mechanics.md（均已存在，无需新建）
- Source page: wiki/sources/xr-cockpit-interaction-specialist.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 已有对应条目（Line 404），无需修改；步骤5完成：overview.md 已有相关 XR 内容，无需修订；步骤6完成：Entity 页面均已存在（XR-Cockpit-Interaction-Specialist/XR-Interface-Architect/XR-Immersive-Developer/The-Agency）；步骤7完成：Concept 页面均已存在（Cockpit-Ergonomics/Constraint-Driven-Control-Mechanics/Motion-Sickness-Threshold/WebXR/Spatial-Computing）；步骤8完成：无内容冲突；步骤9完成：log.md 追加记录
## [2026-05-18] ingest | Outbound Strategist Agent
- Source file: Agent/agency-agents/sales/sales-outbound-strategist.md
- Status: ✅ 成功摄入
- Summary: Outbound Strategist Agent 完整摄取——信号驱动型主动销售（Signal-Based Selling）核心框架：三层信号分级（Tier 1 主动购买信号 > Tier 2 组织变化信号 > Tier 3 技术/行为信号）、可证伪 ICP 定义（含排除条件）、三层账户分层模型（Tier 1 深度多线程 / Tier 2 半个性化 / Tier 3 自动化）、8-12 触点 3-4 周多渠道序列（每次触达必须提供新价值角度）、SDR 角色从 volume operator 向 revenue specialist 转型。关键数据：信号驱动外展转化率比无触发高 4-8 倍；信号半衰期 30 分钟；冷邮件回复率基准 1-3%（通用）→ 12-25%（信号驱动）。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Signal-Based Selling/ICP/Tiered Account Engagement/Multi-Channel Sequence/Speed-to-Signal/Cold Email Anatomy）
- Source page: wiki/sources/sales-outbound-strategist.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page；步骤4完成：index.md 添加条目；步骤5完成：overview.md 已有完整综合摘要（Line 892），无需修改；步骤6完成：Entity 未达到独立建页阈值（SDR/G2/BuiltWith/Loom 均仅出现1次）；步骤7完成：Concept 均以 wikilinks 记录于 source page；步骤8完成：无实质性内容冲突，与 sales-deal-strategist/sales-pipeline-analyst 形成互补关系；步骤9完成：log.md 追加记录
## [2026-05-18] ingest | Account Strategist Agent
- Source file: Agent/agency-agents/sales/sales-account-strategist.md
- Status: ✅ 成功摄入（更新）
- Summary: Account Strategist（账户策略师）Agent 文档更新——补充 Advanced Capabilities 部分：战略账户规划（投资组合分层/EBR）+ 收入架构（定价优化/合同结构/渠道协同）+ 组织情报（M&A检测/非正式决策映射/政治定位）。核心框架保持：Land-and-Expand、QBR、NRR、Multi-Threading、Account Health Score、Churn Prevention。扩充内容：Key Claims（高级能力五条）、Key Quotes（组织情报两条）、Key Concepts（新增8个高级概念：Account Portfolio Segmentation/EBR/Pricing & Packaging Optimization/Contract Structure Design/Co-sell Expansion/PLG/Organizational Change Detection/Informal Decision-Making Mapping）、Contradictions（新增与 sales-pipeline-analyst 的互补关系）。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Source page: wiki/sources/sales-account-strategist.md（更新：date 2026-05-18，扩充 Advanced Capabilities 相关内容）
- Notes: 步骤1完成：读取原始文档（Advanced Capabilities 部分新增）；步骤2完成：读取 index.md、overview.md 和现有 source page；步骤3完成：更新 source page（日期更新 + Summary扩充 + Key Claims扩充 + Key Quotes扩充 + Key Concepts扩充 + Contradictions扩充）；步骤4完成：index.md 第408行日期补全（2026-05-18）；步骤5完成：overview.md 第911行已扩充 Advanced Capabilities 综合摘要；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录与 sales-pipeline-analyst 的互补关系（NRR 共同语言）；步骤9完成：log.md 追加记录
## [2026-05-20] ingest | XR Interface Architect Agent Personality
- Source file: Agent/agency-agents/spatial-computing/xr-interface-architect.md
- Status: ✅ 成功摄入
- Summary: XR Interface Architect Agent 完整摄取——空间交互设计师和界面策略师，专为 AR/VR/XR 沉浸式环境设计直觉化、舒适且可发现的界面。核心能力：设计 HUD、浮动菜单、面板和交互区域；支持多种输入模型（直接触摸、注视+捏合、控制器、手势）；推荐舒适度约束的 UI 布局以降低晕动症；原型化沉浸式搜索、选择和操作交互；结构化多模态输入并提供无障碍备选方案。角色定位：UX/UI 设计师，专注 3D 空间环境。与 [[XRImmersiveDeveloper]] 协作实现 3D 场景可用性，与 [[XRCockpitInteractionSpecialist]] 共享空间交互设计模式，与 [[VisionOSSpatialEngineer]] 实现 visionOS UI。与 [[XRCockpitInteractionSpecialist]] 在 UI 放置策略上存在张力（Interface Architect 倾向灵活定位 vs Cockpit 专家倾向固定安全控件）。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：SpatialComputing/HUDDesign/MotionSickness/GazeInteraction/MultimodalInput/PresenceUX/AccessibilityInXR）
- Source page: wiki/sources/xr-interface-architect.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（wiki/sources/xr-interface-architect.md）；步骤4完成：index.md 已有对应条目（Line 406），无需修改；步骤5完成：Agent 个性化定义文档，overview.md 暂不修改；步骤6完成：Entity 未达到独立建页阈值（The Agency/Spatial Computing 已在多处出现，有独立页面）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page；步骤8完成：与 XRCockpitInteractionSpecialist 在 UI 放置策略上存在张力，已记录于 Contradictions；步骤9完成：log.md 追加记录
## [2026-05-18] ingest | Deal Strategist Agent
- Source file: Agent/agency-agents/sales/sales-deal-strategist.md
- Status: ✅ 成功摄入（更新）
- Summary: Deal Strategist Agent 文档更新——补充三大新增核心能力：Deal Inspection Methodology（7问探测deal状态）、Multi-Threading Strategy（绘制权力/影响力/触达地图避免单点依赖）、Forecast Accuracy（可辩护的deal级别检查方法论）。扩充 Key Claims（Champion验证原则：必须在艰难请求下愿意行动才算真正验证）。新增 Key Concepts（Competitive Landmines/Forecast Accuracy/Multi-Threading Strategy）。新增 Connections（sales-pipeline-analyst 接收评分数据）。扩充 Key Entities。Source page date 更新至 2026-05-18。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page；MEDDPICC/Challenger Sales Model/Command of the Message/Deal Scoring/Competitive Positioning/Win Planning/Deal Inspection Methodology/Challenger Messaging/Multi-Threading Strategy/Forecast Accuracy/Competitive Landmines）
- Source page: wiki/sources/sales-deal-strategist.md（更新：date 2026-05-18，扩充新增能力相关内容）
- Notes: 步骤1完成：读取原始文档（新增 Deal Inspection/Multi-Threading/Forecast Accuracy 章节）；步骤2完成：读取 index.md、overview.md 和现有 source page；步骤3完成：更新 source page（日期更新+内容扩充：Key Claims/Key Concepts/Key Entities/Connections）；步骤4完成：index.md 第408行日期补全（2026-05-18）；步骤5完成：overview.md 无需大幅更新，新增内容与现有框架一致；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录与 sales-pipeline-analyst 的新连接关系（评分数据流向）；步骤9完成：log.md 追加记录
## [2026-04-29] ingest | Sales Engineer Agent
- Source file: Agent/agency-agents/sales/sales-engineer.md
- Status: ✅ 成功摄入
- Summary: Sales Engineer Agent 完整摄取——售前工程师 Agent 角色定义与核心能力框架。核心能力：技术发现（结构化挖掘架构/集成/安全约束/真实决策标准）、Demo Engineering（以影响力为导向：先量化问题→展示结果→逆向讲解→证明收尾，以 [[AhaMoment]] 为核心成功标准）、POC Scoping（严格限定范围：成功标准前置+2-3周硬性时间线+中期检查点）、FIA Framework（Fact-Impact-Act 竞争定位框架）、技术异议解码（识别表面问题背后的真实诉求）、评估笔记维护。关键数据：技术赢率70%+，POC转化率80%+，演示到下一步行动率90%+，中位数18天技术决策。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：Technical Discovery/Demo Engineering/POC Scoping/FIA Framework/Aha Moment Test/Competitive Technical Positioning/Technical Objection Handling/Evaluation Management/Solution Architecture/Demo Tailoring）
- Source page: wiki/sources/sales-engineer.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md；步骤3完成：生成 source page（sales-engineer.md）；步骤4完成：index.md 添加日期标注条目；步骤5完成：overview.md Line 917 已包含完整 Sales Engineer 综合摘要，无需修改；步骤6完成：Entity 未达到独立建页阈值（全文无具体人物/公司实体）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：无实质性内容冲突，与 Sales Discovery Coach 存在互补/协调关系（详见 overview.md Line 1100）；步骤9完成：log.md 追加记录
## [2026-05-02] ingest | Sales Coach Agent
- Source file: Agent/agency-agents/sales/sales-coach.md
- Status: ✅ 成功摄入（更新）
- Summary: AI 销售教练 Agent，通过苏格拉底式提问驱动销售代表成长，专注管道审查、话术辅导、交易策略和预测准确性。核心框架：Richardson Sales Performance、Challenger Model、MEDDPICC 资质诊断、行为反馈循环（Observe-Ask-Suggest-Practice）。关键数据：正式辅导配额完成率 91.2% vs 非正式辅导 84.7%；每周 2 小时以上辅导赢单率 56% vs 少于 30 分钟 43%。新增内容：Skill Gap vs Will Gap 区分、Best Practice 辅导节奏（周 1:1/双周管道审查/月度预测会议）、Observe-Ask-Suggest-Practice 辅导强化循环。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page；MEDDPICC/Challenger Sales Model/Richardson Sales Performance Framework/Pipeline Review/Forecast Accuracy/Coaching Discipline/Skill Gap vs Will Gap）
- Source page: wiki/sources/sales-coach.md（更新：date 2026-05-02，扩充 Key Claims/Key Concepts/Key Entities/Connections）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md、overview.md 和现有 sales-coach source page；步骤3完成：更新 source page（日期更新+内容扩充）；步骤4完成：index.md 日期补全（[2026-05-02]）；步骤5完成：overview.md 第909行已覆盖该来源核心内容，无需更新；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并延续 MEDDPICC 八维度 vs 旧版六维度冲突记录（overview line 1092）；步骤9完成：log.md 追加记录
## [2026-05-17] 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 事件设计、跨平台归因建模和隐私合规。核心理念：错误的追踪数据比无追踪更具误导性，会导致算法持续优化错误目标。核心能力：GTM 容器架构、GA4 实现（事件分类/自定义维度/电子商务 dataLayer）、Google Ads 增强转化、Meta CAPI（含 event_id 去重）、服务端 Tagging、数据驱动归因建模、Consent Mode v2。成功指标：转化数据差异 <3%、标签触发成功率 99.5%+、CAPI 去重零双重计数、页面性能影响 <200ms。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Source page: wiki/sources/paid-media-tracking-specialist.md（新建）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节添加新条目；步骤5完成：overview.md 第188行扩充该来源综合摘要（从简短版本升级为详细版本）；步骤6完成：Entity 未创建独立页面（Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 均以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：检测与 paid-media-auditor 的功能边界重叠——追踪配置（Tracking Specialist）与追踪审计（Auditor）协作关系已在 Connections 节明确记录，无冲突；步骤9完成：log.md 追加记录
- Source file: Agent/agency-agents/paid-media/paid-media-paid-social-strategist.md
- Status: ✅ 成功摄入
- Summary: 跨平台付费社交广告专家 Agent——覆盖 Meta/LinkedIn/TikTok/Pinterest/X/Snapchat 六大平台，设计从引流到再营销的全漏斗社交广告项目。核心理念：社交广告本质是"打断"而非"回答"，必须为每个平台构建原生创意体验而非跨平台复用。关键能力：全漏斗架构、平台差异化创意策略、受众工程（像素/Lookalike/CRM）、Conversions API 实施、SKAdNetwork 应对 iOS 隐私变化。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Source page: sources/paid-media-paid-social-strategist.md
- Notes: 与 [[paid-media-ppc-strategist]] 存在预算分配优先级张力——社交广告强调基于增量测试分配预算而非补充曝光，已在 Contradictions 节记录
## [2026-05-17] ingest | Paid Media Search Query Analyst Agent
- Source file: Agent/agency-agents/paid-media/paid-media-search-query-analyst.md
- Status: ✅ 成功摄入
- Summary: 付费搜索查询分析与优化专家 Agent——专职挖掘搜索词报告、构建负面关键词体系（N-gram 分析/决策树/分层清单）、识别查询-意图缺口（N-gram 四阶段分类）、执行查询雕塑防止内部竞争，通过 SQOS 评分系统多因素评估查询-广告-着陆页一致性。成功指标：首次分析消除 10-20% 非转化消费，无效展示 <5%，查询-意图正确率 >80%。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Source page: wiki/sources/paid-media-search-query-analyst.md（新建）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第417行已有该条目，无需重复添加；步骤5完成：overview.md 第190行已有该来源综合摘要，无需重复添加；步骤6完成：Entity 未创建独立页面（TheAgency/GoogleAds 已存在，JohnWilliams/PaidMediaAuditor/PaidMediaPPCStrategist/PaidMediaTrackingSpecialist 均以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 均以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：检测与 PaidMediaAuditor 的功能边界重叠（详见 Contradictions 节），协调方案为 Audit → Query Analysis → Strategy 三者协作；步骤9完成：log.md 追加记录
## [2026-05-17] ingest | Discovery Coach Agent
- Source file: Agent/agency-agents/sales/sales-discovery-coach.md
- Status: ✅ 成功摄入
- Summary: 销售发现访谈（Discovery）方法论与教练框架——三大发现框架（SPIN Selling/Gap Selling/Sandler Pain Funnel）+ 标准30分钟发现电话结构 + AECR异议处理框架。核心理念：发现是交易成败的关键战场；Implication问题激活损失厌恶是最有力成交工具；根因问题是Gap Selling最重要也最常被跳过的问题；购买决策本质上是情感决策。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Source page: wiki/sources/sales-discovery-coach.md（已存在，本次确认格式合规性）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 已存在且格式完全符合 Source Page Format（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第405行已有该条目；步骤5完成：overview.md 暂不更新（销售发现框架由 sales-proposal-strategist 等页面覆盖）；步骤6完成：Entity 未创建独立页面（Neil Rackham/Keenan/Sandler 均以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：无冲突检测；步骤9完成：log.md 追加记录
## [2026-05-17] ingest | Paid Media Auditor Agent
- Source file: Agent/agency-agents/paid-media/paid-media-auditor.md
- Status: ✅ 成功摄入
- Summary: 付费媒体账户审计 Agent——系统化评估 Google Ads、Microsoft Ads、Meta 三大平台广告账户，涵盖 200+ 检查点，8 大审计类别（账户结构、追踪测量、出价预算、关键词定向、创意素材、购物馈送、竞争定位、着陆页），输出结构化审计报告与优先级建议。审计通常发现 15-30% 效率提升空间，关键建议 30 天执行率达 80%+。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Source page: wiki/sources/paid-media-auditor.md（新建）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第7行添加新条目；步骤5完成：overview.md 未需更新（概述型内容由综合生成覆盖）；步骤6完成：Entity 未创建独立页面（GoogleAds、MicrosoftAdvertising、MetaAds 等均为平台实体，Key Entities 以 wikilinks 记录于 source page）；步骤7完成：Key Concepts 以 wikilinks 形式记录于 source page，未达到独立页面阈值；步骤8完成：检测与 PaidMediaTrackingSpecialist 的分工冲突（详见 Contradictions 节）；步骤9完成：log.md 追加记录
- Source file: Agent/agency-agents/design/design-visual-storyteller.md
- Status: ✅ 成功摄入
- Summary: The Agency Design 部门视觉叙事与多媒体内容创作专家 Agent——核心职责：将复杂信息转化为有影响力的视觉故事；Story Arc 三段式框架（铺垫/冲突/解决）；多媒体能力覆盖视频叙事、动画-motion graphics、摄影指导和交互式媒体；跨平台适配支持 Instagram/YouTube/TikTok/LinkedIn/Pinterest；数据可视化通过 Progressive Disclosure 实现复杂信息可理解传递；无障碍合规 WCAG 是默认要求
- Source page: wiki/sources/design-visual-storyteller.md（新建）
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第13行添加新条目；步骤5完成：overview.md 第110行已有该来源综合摘要，无需重复添加（发现重复后已回退）；步骤6完成：Entity 未创建（相关 Agent 均已存在于 wiki 实体引用，无需新建）；步骤7完成：Key Concepts 以 wikilinks 形式记录于 source page，未创建独立 Concept 页面；步骤8完成：检测无冲突内容（无已知矛盾）；步骤9完成：log.md 追加记录
## [2026-05-15] ingest | Inclusive Visuals Specialist
- Source file: Agent/agency-agents/design/design-inclusive-visuals-specialist.md
- Status: ✅ 成功摄入
- Summary: The Agency Design 部门包容性视觉表征专家 Agent——专门对抗 AI 图像/视频生成模型（Midjourney/Sora/Runway/DALL-E）中的系统性刻板印象偏见；核心机制：结构化提示词架构（Subject → Sub-actions → Context → Camera Spec → Color Grade → Explicit Exclusions）+ 负向提示库 + 视频物理学定义；四阶段工作流：Brief Intake → Annotation Framework → Video Physics Definition → 7-Point QA Review Gate；成功指标：刻板印象零依赖、克隆面孔和文化乱码消除率100%、社区验证认可
- Source page: wiki/sources/design-inclusive-visuals-specialist.md（新建）
- Concepts created: Intersectionality.md、Cultural-Authenticity.md、Video-Physics-Definition.md、Sociological-Accuracy.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（含现有 Sources/Concepts 索引）和 overview.md（含 InclusiveVisualsSpecialist 已有摘要）；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第12行添加新条目；步骤5完成：overview.md 第112-113行补充 Intersectionality vs Sociological Accuracy 分析段落；步骤6完成：Entity 未创建（Midjourney/DALL-E/Sora/Runway 均为参考性质，引用未达≥2次阈值）；步骤7完成：新建4个 Concept 页面（Intersectionality/Cultural-Authenticity/Video-Physics-Definition/Sociological-Accuracy）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 design-image-prompt-engineer 的张力（概率生成 vs 确定性约束），协调方式：Subject/Context 层使用 Inclusive Visuals 的精确约束，Style/Color Grade 层保留 Image Prompt Engineer 的创意概率空间；步骤9完成：log.md 追加记录
- Source file: Agent/agency-agents/design/design-image-prompt-engineer.md
- Status: ✅ 成功摄入
- Summary: The Agency Design 部门 AI 图像生成提示词工程专家 Agent——核心职责：将视觉概念精准翻译为结构化提示词，驱动 Midjourney/DALL-E/SD/Flux 等平台产出专业级摄影作品；五层提示词结构框架（主体→环境→光线→摄影技术→风格）；体裁专属模板（人像/产品/风光/时尚）；平台特定语法优化；成功指标：90%+ 视觉概念还原率
- Source page: wiki/sources/design-image-prompt-engineer.md（新建）
- Concepts created: Five-Layer-Prompt-Structure.md、Photography-Terminology.md、Negative-Prompting.md、Platform-Specific-Optimization.md、Genre-Specific-Prompt-Patterns.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md Sources 节第10行添加新条目；步骤5完成：overview.md 第110-111行已有该来源综合摘要，无需修订；步骤6完成：Entity 未创建（Midjourney/SD/DALL-E/Flux/Annie Leibovitz/Peter Lindbergh 均为参考性质，引用未达≥2次阈值）；步骤7完成：新建5个 Concept 页面（Five-Layer-Prompt-Structure/Photography-Terminology/Negative-Prompting/Platform-Specific-Optimization/Genre-Specific-Prompt-Patterns）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 design-ui-designer 的精确性张力（概率生成 vs 像素精确，通过确定性约束协调）；步骤9完成：log.md 追加记录
## [2026-04-30] ingest | Whimsy Injector Agent Personality
- Source file: Agent/agency-agents/design/design-whimsy-injector.md
- Status: ✅ 成功摄入
- Summary: The Agency Design 部门品牌趣味性设计专家 Agent——核心职责：在用户交互全流程嵌入愉悦感，通过微交互、趣味文案、复活节彩蛋和游戏化提升品牌记忆度；趣味分类学四层（Subtle/Interactive/Discovery/Contextual）；核心原则：趣味必须有功能性或情感性目的；包容性设计是默认要求；与 UX Architect 时序协作（基线 → 趣味叠加）
- Source page: wiki/sources/design-whimsy-injector.md（新建）
- Concepts created: Micro-Interaction.md、Brand-Personality-Framework.md、Gamification.md、Inclusive-Delight.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目；步骤5完成：overview.md 第26-30行在 design-ux-architect 段落后新增 Whimsy Injector 综合摘要；步骤6完成：UX Architect/Design-UI-Designer/Brand-Guardian 仅1-2次引用，未达≥2次阈值，跳过 Entity 创建；步骤7完成：新建4个 Concept 页面（Micro-Interaction/Brand-Personality-Framework/Gamification/Inclusive-Delight）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 UX Architect 的趣味边界张力（通过时序分工解决）；步骤9完成：log.md 追加记录
## [2026-05-15] ingest | Brand Guardian Agent Personality
- Source file: Agent/agency-agents/design/design-brand-guardian.md
- Status: ✅ 成功摄入
- Summary: The Agency Design 部门的品牌守护者专家 Agent——核心职责：创建内聚的品牌身份系统，确保品牌在所有触点的一致表达，提供品牌保护策略；Brand Foundation Framework（Purpose/Vision/Mission/Values/Personality）是所有品牌决策基础；Visual Identity System 必须作为内聚系统设计；默认要求包含品牌保护（商标/合规监控/危机管理）
- Source page: wiki/sources/design-brand-guardian.md（新建）
- Concepts created: Brand-Foundation-Framework.md、Visual-Identity-System.md、Brand-Voice.md、Brand-Protection.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目；步骤5完成：overview.md 在 Whimsy Injector 段落后新增 Brand Guardian 综合摘要；步骤6完成：The-Agency Entity 已存在，Design-Department/UX-Architect 仅1次引用，未达≥2次阈值，跳过 Entity 创建；步骤7完成：新建4个 Concept 页面（Brand-Foundation-Framework/Visual-Identity-System/Brand-Voice/Brand-Protection）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 UX Architect 的角色边界张力（通过时序分工解决——Brand Guardian 先定义战略框架 → UX Architect 再构建技术系统）；步骤9完成：log.md 追加记录
## [2026-05-15] ingest | UX Architect
- Status: ✅ 成功摄入
- Summary: The Agency Design 部门 UX Architect Agent 的角色定义与交付物规范——核心职责：提供 CSS 设计系统（颜色/排版/间距变量）、Grid/Flexbox 布局框架、Theme Toggle 组件（light/dark/system 三态）；Foundation-first 理念消除开发者架构决策疲劳；在 ProjectManager 和 LuxuryDeveloper 之间建立技术桥梁；组件命名规范（BEM/Utility-first/Component-based 三选一）
- Source page: wiki/sources/design-ux-architect.md（新建）
- Concepts created: CSS-Design-System.md、Layout-Framework.md、Theme-Toggle.md、Responsive-Breakpoints.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目；步骤5完成：overview.md 第26行后新增 UX Architect 综合摘要；步骤6完成：LuxuryDeveloper/ProjectManager/ArchitectUX 仅1次引用，未达≥2次阈值，跳过 Entity 创建；步骤7完成：新建4个 Concept 页面（CSS-Design-System/Layout-Framework/Theme-Toggle/Responsive-Breakpoints）并加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 LuxuryDeveloper 的边界协调（Foundation → Polish 时序分工）；步骤9完成：log.md 追加记录
## [2026-05-15] ingest | Contributing to The Agency
- Source file: Agent/agency-agents/CONTRIBUTING.md
- Status: ✅ 成功摄入
- Summary: The Agency 开源 AI Agent 项目的贡献指南——定义如何创建、改进和提交新的 Agent；核心贡献方式（创建新 Agent / 优化现有 / 分享案例 / 反馈问题）；Agent 设计五原则（强个性 + 清晰交付物 + 可量化指标 + 经验证工作流 + 学习记忆）；Persona/Operations 双分组结构支持 OpenClaw 格式自动转换；PR 最简路径为单个 Markdown 文件
- Source page: wiki/sources/contributing.md（新建）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 添加新条目；步骤5完成：overview.md 第26行已有该来源综合摘要，无需修订；步骤6完成：Entity/Concept 暂缓；步骤7完成：同上；步骤8完成：无冲突；步骤9完成：log.md 追加记录
## [2026-05-02] ingest | UI Designer Agent Personality
- Source file: Agent/agency-agents/design/design-ui-designer.md
- Status: ✅ 成功摄入
- Summary: The Agency 设计部门的视觉界面设计专家 Agent——核心职责：创建视觉设计系统、组件库和像素级界面；Design System First 方法在创建单个界面之前先建立组件基础；WCAG AA 无障碍标准内置于架构层而非后期添加；交付物包含设计令牌系统、响应式框架、组件文档和设计 QA 流程；成功指标：95%+ 界面一致性、90%+ 开发者交接准确率
- Source page: wiki/sources/design-ui-designer.md（新建）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含八节）；步骤4完成：index.md 第11行添加新条目；步骤5完成：overview.md 第100行已有该来源综合摘要，无需修订；步骤6完成：The-Agency/UX-Architect/Brand-Guardian Entity 均已存在，无需新建；步骤7完成：Design-Token-System/Component-Library-Architecture/WCAG-Accessibility-Standards 等 Concept 均已存在，无需新建；步骤8完成：Contradictions 记录与 Whimsy Injector 的张力；步骤9完成：log.md 追加记录
## [2026-05-15] ingest | 为 The Agency 贡献代码
- Source file: Agent/agency-agents/CONTRIBUTING_zh-CN.md
- Status: ✅ 成功摄入
- Summary: The Agency 智能体项目的开源贡献指南——涵盖行为准则（尊重、包容、协作、专业）、4种贡献方式（创建智能体/优化/分享案例/反馈问题）、智能体设计五原则（鲜明性格+明确交付物+可量化指标+经过验证的工作流+学习记忆）、PR 提交流程（含提交前检查清单）和风格指南（具体明确+落地务实+让人记住+实用可用）
- Source page: wiki/sources/contributing_zh-cn.md（新建）
- Entities updated: The-Agency.md（添加 frontmatter 和 sources 引用，更新 last_updated）
- Concepts updated: Agent-Template.md（追加 sources 引用，更新 last_updated）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第11行添加新条目；步骤5完成：overview.md 第26行已有该来源综合摘要，无需修订；步骤6完成：The-Agency.md 添加 frontmatter 和 sources 引用；步骤7完成：Agent-Template.md 追加 sources 引用；步骤8完成：无冲突；步骤9完成：log.md 追加记录
## [2026-05-15] 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: 通过 Terraform 在 AWS 上自动化部署 RDS 数据库——DBRE 团队 Greg 主讲，提倡所有规模 RDS 均用 Terraform 而非 Console；推荐 Gruntwork RDS Service 模块（含 KMS 加密 + CloudWatch 告警），配合 Terragrunt 管理多环境配置，使用 tagged release 确保稳定性；Day 2 运维通过 GitHub PR + Atlantis 审批后自动 apply，支持扩缩容、打补丁、主版本升级；核心 IaC 价值为"代码即文档"
- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform.md（新建）
- Entities created: Greg.md（DBRE 团队成员，Terraform IaC 推广者）
- Entities updated: Gruntwork.md、Amazon-RDS.md、Terragrunt.md、Atlantis.md（追加 sources 引用）
- Concepts updated: Infrastructure-as-Code.md（追加 sources 引用）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：source page 已在 index.md 第302行存在，无需重复添加；步骤5完成：overview.md 无需修订；步骤6完成：新建 Greg.md Entity 页面，更新 Gruntwork.md/Amazon-RDS.md/Terragrunt.md/Atlantis.md sources 引用，更新 index.md Entities 节；步骤7完成：Infrastructure-as-Code.md 追加来源引用；步骤8完成：无冲突，仅与 ctp-topic-48 存在观点角度差异（不矛盾）已在 Contradictions 节记录；步骤9完成：log.md 追加记录
## [2026-05-15] 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: 通过 Terraform IaC 实现 ECS 容器化应用的自动化部署——JP 和 Raja M 主讲，CTP/SRE 团队基于 Gruntwork 构建 ECS Terraform 模块，支持 Docker 容器/EC2 部署，具备自动扩缩容、自动故障恢复、金丝雀部署能力；采用 Listener 集中管理方式；前置条件包括 VPC、ELB 安全组和 EFS 卷挂载；集成 CloudWatch/Splunk/Grafana/Prometheus
- Source page: wiki/sources/learning-sessions-cloud-transformation-programme-20230808-183322-meeting-recordi.md（已存在，更新了 Connections 节的 self-reference bug 并追加新连接）
- Entities created: JP.md（CTP 讲师，ECS 业务/技术背景介绍）、Raja-M.md（CTP/SRE 成员，ECS 模块构建者）、CTP-SRE-Team.md（CTP/SRE 团队）、AWS.md（更新 sources 引用）、Gruntwork.md（更新 sources 引用）
- Entities already existed: cloud-transformation-programme.md（index.md 第 642 行，已包含本来源引用）、Gruntwork.md（index.md 第 720 行，已追加来源引用）、AWS.md（index.md 第 583 行，已追加来源引用）
- Concepts created/updated: Canary-Deployment.md（新建，金丝雀部署策略）、ECS-Module.md（新建，ECS Terraform 模块）、InfrastructureAsCode.md（追加来源引用）
- Concepts already existed: Infrastructure-as-Code.md（index.md 第 1469 行）、Canary-Deployment.md（index.md 第 1150 行）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 存在，修复第 46 行 self-reference bug 并追加与 learning-sessions-cloud-transformation-programme-deploying-rds-via-terraform 的关联；步骤4完成：index.md 第 302 行已有条目；追加 CTP-SRE-Team/JP/Raja-M 至 Entities 节，追加 ECS-Module 至 Concepts 节；步骤5完成：overview.md 第 255 行已有该来源综合摘要，无需修订；步骤6完成：新建4个 Entity 页面（JP/Raja-M/CTP-SRE-Team/AWS/Gruntwork 追加来源），更新 index.md Entities 节；步骤7完成：新建 Canary-Deployment.md/ECS-Module.md Concept 页面，更新 InfrastructureAsCode.md sources 引用，更新 index.md Concepts 节；步骤8完成：与 ctp-topic-64_scaling-out-with-amazon-eks 存在容器编排选型差异已在 Contradictions 节记录；步骤9完成：log.md 追加记录
## [2026-05-15] 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: 跨账号 Terraform 模块的中心化部署方案——基于 Shared Account 作为中转站，Jenkins 检测 cross-account.json 标记文件触发 ECS Deploy Runner，通过 Assume Role 访问目标账号的 TF State Bucket Accessor 和 Cross-account ECS Deploy Runner Role 两个角色，实现安全性（账号间无直接信任）、自动化（Jenkins 自动识别模块类型）、可复用性（模块不硬编码特定账号角色）
- Concepts created/updated: Cross-account-Terraform-Modules.md（已存在，补充 Source 引用）, ECS-Deploy-Runner.md（entities+concepts 双页）, Shared-Account.md（entities+concepts 双页）, TF-State-Bucket-Accessor.md（entities+concepts 双页）, Assume-Role.md, Blast-Radius.md, Root-Terragrunt-HCL.md, cross-account-json.md
- Entities created: Fibos.md, ECS-Deploy-Runner.md（entities 页）, Shared-Account.md（entities 页）, TF-State-Bucket-Accessor.md（entities 页）, Cross-account-ECS-Deploy-Runner-Role.md
- Source page: wiki/sources/ctp-topic-16-cross-account-terraform-modules.md（已存在且格式完整）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 已存在无需重建；步骤4完成：index.md 第302行已有条目；步骤5完成：overview.md 无需修订（source page 已有完整摘要）；步骤6完成：新建5个 Entity 页面（Fibo/ECS-Deploy-Runner/Shared-Account/TF-State-Bucket-Accessor/Cross-account-ECS-Deploy-Runner-Role）并更新 index.md Entities 节；步骤7完成：新建8个 Concept 页面并更新 index.md Concepts 节；步骤8完成：无内容冲突（与 Gruntwork/Atlantis 为演进关系）；步骤9完成：log.md 追加记录
## [2026-05-13] 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: Terraform 与 Terragrunt 深度对比——Terraform（HashiCorp）通过状态文件将期望状态绑定到实际环境，支持多云；Terragrunt 轻量封装践行 DRY 原则，管理 provider/remote_state 块减少跨环境重复声明；两者命令语法完全一致；辅助工具链：Terraform Enterprise、Gruntwork、Atlantis、tfsec、Terratest
- Concepts created: InfrastructureAsCode.md, TerraformState.md
- Entities created: HashiCorp.md, Gruntwork.md, Atlantis.md
- Entities already existed: HashiCorp（index.md 第720行）、Gruntwork（index.md 第717行）、Atlantis（index.md 第582行）
- Source page: wiki/sources/ctp-topic-48-terraform-vs-terragrunt.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第301行已有条目，无需重复添加；步骤5完成：overview.md 第253行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 HashiCorp.md/Gruntwork.md/Atlantis.md Entity 页面（HashiCorp/Gruntwork/Atlantis 在 index.md 中已存在，故在各自页面内追加 sources 引用）；步骤7完成：新建 InfrastructureAsCode.md/TerraformState.md Concept 页面，index.md Concepts 节追加对应条目；步骤8完成：无冲突；步骤9完成：log.md 追加记录
## [2026-05-12] 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）进阶最佳实践与团队协作模式——三组件（生产者/消费者/代理）、Event Router vs Event Store、Choreography vs Orchestration、幂等性、事件排序（SQS FIFO/Kinesis）、去中心化团队所有权、Fan-out 模式（SNS/EventBridge）、竞争消费者模式（Compete Consumer）、死信队列（DLQ）和 EventBridge 最佳实践
- Concepts created: Event-Driven-Architecture.md, Idempotency.md, Fan-Out-Pattern.md, Competing-Consumer-Pattern.md, Choreography.md, Orchestration.md
- Entities created: Anil-Giri.md, AWS-EventBridge.md
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-event-driven-architecture-part-2-2024091.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第296行已有条目，补充日期前缀（2024-09-17）和一行摘要；步骤5完成：overview.md 第407行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Anil-Giri.md/AWS-EventBridge.md Entity 页面，index.md Entities 节追加 Anil-Giri/AWS-EventBridge；步骤7完成：新建 Event-Driven-Architecture/Idempotency/Fan-Out-Pattern/Competing-Consumer-Pattern/Choreography/Orchestration 共6个 Concept 页面，index.md Concepts 节追加对应条目；步骤8完成：无冲突（Part 2 与 Part 1 为互补关系）；步骤9完成：log.md 追加记录
## [2026-05-12] 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 服务生态与 Prompt Engineering 实践——OpenText 技术客户经理 Shikad Holtzman 主讲；生成式 AI 四大价值路径、AWS 三层技术栈；数据是差异化关键；Bedrock（RAG/微调/Agents/Guardrails）+ Amazon Q（Business/Developer）；Prompt Engineering 四大组件与 One-shot/Few-shot/Chain-of-Thought 技巧
- Concepts created: Prompt-Engineering.md
- Entities created: Shikad-Holtzman.md, Amazon-Q.md, Anthropic.md, Meta-AI.md
- Entities updated: Amazon-Bedrock.md（追加来源引用）
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-generative-ai-prompt-engineering-2024111.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第295行已有条目（2026-04-28 先前摄入痕迹），无需重复添加；步骤5完成：overview.md 第401行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Shikad-Holtzman.md/Amazon-Q.md/Anthropic.md/Meta-AI.md Entity 页面，更新 Amazon-Bedrock.md 追加来源引用；步骤7完成：新建 Prompt-Engineering.md Concept 页面；步骤8完成：记录与 llms-rag-ai-agent-三个到底什么区别 的 RAG 运维复杂度视角冲突；步骤9完成：log.md 追加记录
## [2026-05-12] ingest | Public Cloud Learning Sessions (OpenText) - Serverless Computing - 20240903
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/09_Serverless_AI/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
- Status: ✅ 成功摄入
- Summary: AWS 无服务器计算深度解析——OpenText 主办，聚焦 AWS Lambda（事件驱动/权限模型/版本/Layers/ARM64）、Step Functions（状态机/Standard&Express）、API Gateway（边缘优化/区域/私有）和 SAM（基于 CloudFormation 的本地开发和部署工具）
- Concepts: 无新 Entity 页面创建（Lambda/Step Functions/API Gateway/SAM 为 AWS 官方服务，overview.md 已有充分描述）
- Entities: 无新 Entity 页面创建（同上）
- Source page: wiki/sources/public-cloud-learning-sessions-opentext-serverless-computing-20240903-160139-mee.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第293行添加日期前缀（2024-09-03）和中文摘要；步骤5完成：overview.md 第405行已有该来源详细综合摘要，内容一致无需修订；步骤6-7完成：无需创建新 Entity/Concept 页面（AWS 官方服务 overview 已有描述）；步骤8完成：无冲突（与 EDA Part 1/2 共享事件驱动模型属互补关系）；步骤9完成：log.md 追加记录
## [2026-05-12] 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 入门——Suraav Paul（AWS 高级解决方案架构师）主讲，AI 三层分类（分类 AI/预测 AI/生成式 AI）、Amazon Bedrock 全托管生成式 AI 服务（基础模型+微调+RAG+Agents+Guardrails）、ML Ops 三管道（数据/训练/推理）；强调 Bedrock 数据隐私保证和负责任 AI 六大原则
- Concepts created: Foundation-Models.md, MLOps.md, Responsible-AI.md
- Entities created: Suraav-Paul.md, Amazon-SageMaker.md, Amazon-Titan.md
- Entities updated: Amazon-Bedrock.md（追加来源引用）
- Source page: wiki/sources/public-cloud-learning-sessions-introduction-to-artificial-intelligence-ai-machin.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 第399行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：新建 Suraav-Paul.md/Amazon-SageMaker.md/Amazon-Titan.md Entity 页面，更新 Amazon-Bedrock.md 追加来源引用；步骤7完成：新建 Foundation-Models.md/MLOps.md/Responsible-AI.md Concept 页面，index.md Entities 节追加 Amazon-SageMaker/Amazon-Titan/Suraav-Paul，Concepts 节追加 Foundation-Models/Responsible-AI/MLOps；步骤8完成：无冲突；步骤9完成：log.md 追加记录
## [2026-05-12] ingest | Cloud Learning Master Index
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/_Index/cloud-learning-master-index.md
- Status: ✅ 成功摄入
- Summary: Cloud Learning Master Index — Public Cloud Learning Sessions 全部111个视频的分类索引目录（10大类：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）
- Entities created: （无新建 — Gruntwork/Grafana/Karpenter/Bottlerocket 等将在子视频 source pages 摄入时创建）
- Source page: wiki/sources/cloud-learning-master-index.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第291行补充日期前缀和一行摘要；步骤5完成：overview.md 第219行已有该来源详细综合摘要，内容一致无需修订；步骤6完成：无需新建 Entity（OpenText.md/MicroFocus.md/Atlantis.md 等已存在；Gruntwork/Grafana/Karpenter 等将在子视频 source pages 摄入时创建）；步骤7完成：无需新建 Concept（FinOps.md/GitOps.md/Karpenter.md 等已存在；Landing-Zone/EKS/Terraform/IAM 等作为顶层框架将在子视频 source pages 摄入时精确定义）；步骤8完成：记录与 ctp-topic-34-azure-landing-zone-architecture-overview 的跨平台差异冲突；步骤9完成：log.md 追加记录
## [2026-05-12] 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 — 通过 CloudWatch Events 每15分钟触发 Lambda → 读取 DynamoDB 调度配置 → 根据实例标签（Schedule/Period/Override）自动启停 EC2/RDS；CCOE Guardrails 框架自动部署，覆盖月消费10美元以上 AWS 账号；RDS 维护窗口智能配合； Gustavo 主讲
- Concepts created: AWS-Instance-Scheduler.md, CloudWatch-Events.md, DynamoDB-Config-Table.md, Tagging.md, RDS-Maintenance-Window.md, Override-Status.md
- Entities created/updated: Gustavo.md（新建）, Godrails.md（已有，更新添加 Topic 27 来源和详情）
- Source page: wiki/sources/ctp-topic-27-aws-instance-scheduler.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 第389行已有该来源详细摘要，内容一致无需修订；步骤6完成：新建 Gustavo.md Entity 页面，更新 Godrails.md（含 Aliases、Topic 13+27 来源、Guardrails 机制详情）；删除错误创建的 Guardrails.md（与 Godrails 为同一实体）；步骤7完成：新建 AWS-Instance-Scheduler/CloudWatch-Events/DynamoDB-Config-Table/Tagging/RDS-Maintenance-Window/Override-Status 共6个 Concept 页面；步骤8完成：无冲突（与 Topic 13/63 引用一致的 instance scheduler FinOps 策略）；步骤9完成：log.md 追加记录
## [2026-05-12] 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: AWS EC2 成本优化最佳实践：Graviton（40% 性价比提升/60% 功耗降低）、Spot 竞价实例（90% 折扣）、AWS Nitro 虚拟化、Nitro Enclave；Mike Dukes 和 Steele Taylor 主讲；Spot Invaders 游戏演示容错混沌工程
- Concepts created/updated: [[AWS-Nitro]]（新建）、[[EC2-Spot-Instances]]（新建）、[[ECS]]（新建）；[[Graviton]]（已有，已追加来源链接）、[[SpotInstances]]（已有，已追加来源链接）
- Entities created/updated: [[Mike-Dukes]]（新建）、[[Steele-Taylor]]（新建）、[[Spot-Invaders]]（新建）
- Source page: wiki/sources/public-cloud-learning-sessions-best-practices-for-ec2-cost-optimization-in-aws-2.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第294行添加日期前缀和摘要；步骤5完成：overview.md 第397行已有该来源详细摘要，无需修订；步骤6完成：新建 Mike-Dukes.md/Steele-Taylor.md/Spot-Invaders.md Entity 页面；步骤7完成：新建 AWS-Nitro.md/EC2-Spot-Instances.md/ECS.md Concept 页面；更新 Graviton.md/SpotInstances.md 添加来源引用；步骤8完成：记录与 CTP Topic 13 的潜在冲突点（Graviton 适用场景，已协调）；步骤9完成：log.md 追加记录
## [2026-05-12] 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: Cloud FinOps 治理框架：PCG 三层服务模型（成本管理/成本优化/治理自动化）、5 大核心策略（账单可见性/标签合规/预算责任/RI集中管理/区域限制）、安全控制（Godrails/联合身份管理）、Cloud Health 监控工具、实例选型标准化（M/T/C/R/X+Graviton）、研发环境三合一优化（突发性+Spot+调度器）
- Concepts created/updated: [[Graviton]]（新建）、[[CloudHealth]]（新建）、[[ReservedInstances]]（新建）、[[SpotInstances]]（已有，已链接）、[[SavingsPlans]]（已有，已链接）、[[FinOps]]（已有，已更新链接）
- Entities created/updated: [[PCGTeam]]（已存在，已更新）、[[Uday]]（新建）、[[Vinay]]（已存在）、[[Godrails]]（新建）
- Source page: wiki/sources/ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第297行添加日期前缀和摘要；步骤5完成：overview.md 修正5处 wikilinks（从 ctp-topic-13-cloud-finops-policies 更正为 ctp-topic-13-cloud-finops-micro-focus-policies-best-practices-to-optimize-the-co）；步骤6完成：新建 Uday.md/Godrails.md Entity 页面，更新 PCGTeam.md；步骤7完成：新建 Graviton.md/CloudHealth.md/ReservedInstances.md Concept 页面，FinOps/SpotInstances/SavingsPlans 已存在；步骤8完成：无冲突；步骤9完成：log.md 追加记录
## [2026-05-11] 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: ✅ 成功摄入（补充新建缺失 Entity/Concept 页面）
- Summary: Renovate Bot 自动化管理云原生基础设施依赖项更新——解决"依赖地狱"问题，实时扫描 Docker 镜像/Terraform 模块/Terragrunt 配置/pre-commit 钩子版本标签，自动发起 Pull Request；通过 Dependency Dashboard 提供全局依赖状态视图；集成 Jenkins 流水线，使用 Podman 容器化运行并配置 Rate Limiting 避免 PR 风暴。
- Concepts created/updated: [[Dependency-Dashboard]]（新建）、[[Rate-Limiting]]（新建）、[[Pre-commit-Hooks]]（新建）
- Entities created: [[Paul-Hopkins]]（新建，作为关键人物创建）
- Source page: wiki/sources/ctp-topic-15-working-with-renovatebot.md
- Notes: 步骤3完成：source page 已存在（之前已摄入）；步骤4完成：index.md 补充 Dependency-Dashboard/Rate-Limiting/Pre-commit-Hooks 到 Concepts 节、Paul-Hopkins 到 Entities 节；步骤5完成：overview.md 第249行已有该来源详细摘要，内容一致无需修订；步骤6完成：新建 Paul-Hopkins.md Entity 页面；步骤7完成：新建 Dependency-Dashboard.md/Rate-Limiting.md/Pre-commit-Hooks.md Concept 页面；步骤8完成：无新冲突；步骤9完成：log.md 追加记录。Renovate-Bot.md/Semantic-Versioning.md/Dependency-Management.md/Gruntwork.md/Jenkins.md/Terragrunt.md 均已存在，本次无需新建。
## [2026-05-11] ingest | Public Cloud Learning Sessions - Ollie Workflow and The Demand Process - 20240416
- Status: ✅ 成功摄入
- Summary: Oli Workflow（超大规模云厂商支出审批流程）与需求管理端到端全链路——三阶段审批工作流（FinOps→Cloud Services→FPNA）和 OpenText 需求管理流程（Octane/Qixi 提交→主服务目录→SMACs 嵌入→自动化履约），目标是 80% 场景业务单元自助完成需求
- Concepts created: Demand-Management.md, ITIL-Service-Management.md, SMACs.md, FinOps.md, Product-Backlog.md, Oli-Workflow.md
- Entities created: Tom-Bice.md, FPNA-Team.md, MUI.md, Shannon.md, Octane.md, Qixi.md
- Source page: wiki/sources/public-cloud-learning-sessions-ollie-workflow-and-the-demand-process-20240416-16.md
- Notes: 步骤3完成：source page 已存在（步骤1确认）；步骤4完成：index.md 第287行已有条目；步骤5完成：overview.md 第379行已有该来源详细摘要，无需修订；步骤6完成：新建 Tom-Bice.md/FPNA-Team.md/MUI.md/Shannon.md/Octane.md/Qixi.md Entity 页面（均符合≥2次提及的创建条件）；步骤7完成：新建 Demand-Management.md/ITIL-Service-Management.md/SMACs.md/FinOps.md/Product-Backlog.md/Oli-Workflow.md Concept 页面（均符合可抽象/可复用/非具体实例的创建条件）；步骤8完成：无新冲突；步骤9完成：log.md 追加记录
## [2026-05-08] ingest | CTP Topic 3 Deploy and maintain infrastructure
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-3-deploy-and-maintain-infrastructure.md
- Status: ✅ 成功摄入
- Summary: Landing Zone 多账号架构下基础设施部署与维护——核心区分 Service Module（业务视角，满足业务需求的一组模块组合）与 Regular Module（技术视角）；Terragrunt HCL 通过版本锁定引用模块而非 master 分支；Service Catalog 支持三级复用（单账户→产品团队→跨团队）；类 OO 继承原则：抽象层级越高，配置选项越少
- Concepts created: （无新建 — Terraform/Terragrunt/Service-Catalog/Landing-Zone/Module/Infrastructure-as-Code 均已存在）
- Entities created: （无新建 — Terraform/Terragrunt/Gruntwork/Jenkins 均已存在）
- Source page: wiki/sources/ctp-topic-3-deploy-and-maintain-infrastructure.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 条目补充日期前缀和一行摘要；步骤5完成：overview.md 第221行已有该来源详细摘要，内容一致无需修订；步骤6完成：无新建 Entity（Terraform/Terragrunt/Gruntwork/Jenkins 均已存在，DevTools 仅1次提及未达阈值）；步骤7完成：无新建 Concept（Service-Catalog/Terraform/Terragrunt/Landing-Zone 等均已存在）；步骤8完成：Contradictions 记录与 ctp-topic-1（框架vs自主）和 ctp-topic-48（Terragrunt对比）的视角关系；步骤9完成：log.md 追加记录
## [2026-04-29] 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 视频，核心痛点：Jenkins 流水线初始化慢（多次代码克隆/顺序测试/ECS 预配置）和架构复杂（持续叠加功能导致脆弱）。Atlantis 提供 PR 评论式协作模型，支持模块 Locking、并行构建、跨账户 IAM 角色访问，merge 前 Apply 确保代码与基础设施同步。
- Concepts created: [[GitOps]]（已存在，本次更新扩充内容，新增 Pull vs Push 模型对比和工具生态表）
- Entities created: [[Atlantis]]（新建 Entity 页面，含核心功能、架构说明）、[[Jenkins]]（新建 Entity 页面，含痛点对比表）
- Source page: wiki/sources/ctp-topic-32-using-atlantis-cicd-for-infrastructure-deployments.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第287行已有条目，以正确格式补充日期和一行摘要；步骤5完成：overview.md 第245行已有详细条目，本次无需修订；步骤6完成：新建 Atlantis.md 和 Jenkins.md Entity 页面（均符合出现≥2次的创建条件）；步骤7完成：GitOps.md 概念页已存在，本次扩充 Pull vs Push 模型对比和工具生态表；步骤8完成：无新冲突（Atlantis vs Jenkins 的 pre-merge-apply vs post-merge-deploy 差异已在 Contradictions 节记录）；步骤9完成：log.md 追加记录
## [2026-05-04] 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 IaC 集成视频（状态：待 Whisper 转录）。源文件仅有 frontmatter 元数据，含 tags: [CI/CD, Gruntwork, IaC, CTP]，视频尚未转录，Summary/Key Claims/Key Quotes 均标记为待补充。已与 Gruntwork Entity、CI/CD Concept、同分类其他 CTP 来源建立 Connections 链接。
- Concepts created: （无新建 — CI/CD、GitOps、Infrastructure-as-Code Concept 页面均已存在，直接引用）
- Entities created: [[Gruntwork]]（已存在，直接引用）
- Source page: wiki/sources/ctp-topic-9-ci-cd-with-gruntwork.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第285行已有条目，以正确格式补充日期 2026-04-14；步骤5完成：overview.md 第223行已有该主题条目，本次无需修订；步骤6完成：Gruntwork Entity 页面已存在，直接引用；步骤7完成：CI/CD、GitOps、Infrastructure-as-Code Concept 页面均已存在，直接引用；步骤8完成：无冲突；步骤9完成：log.md 追加记录。⚠️ 视频待 Whisper 转录后需重新补充 Summary/Key Claims/Key Quotes 内容。
## [2026-05-04] ingest | CTP Topic 2 Git
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/06_CI_CD_GitOps/ctp-topic-2-git.md
- Status: ✅ 成功摄入
- Summary: Git 版本控制基础与实践学习视频（状态：待 Whisper 转录）。源文件仅有 frontmatter 元数据，含 tags: [Git, VCS, CTP]，视频未转录，Summary/Key Claims/Key Quotes 均标记为待补充。已与同分类下其他 CTP CI/CD GitOps 来源建立 Connections 链接。
- Concepts created: [[GitOps]]（已存在，引用）
- Entities created: （无新建 — 源文件未提及具体人物）
- Source page: wiki/sources/ctp-topic-2-git.md
- Notes: 步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第288行已有条目，以正确格式补充日期和一行摘要；步骤5完成：overview.md 无需修订（该来源属于 CTP DevOps 系列，overview 中 Git 相关内容不涉及 CTP 上下文）；步骤6完成：无新建 Entity 页面（源文件无具体人物）；步骤7完成：GitOps Concept 页面已存在，直接引用；步骤8完成：无冲突；步骤9完成：log.md 追加记录。⚠️ 视频待 Whisper 转录后需重新补充 Summary/Key Claims/Key Quotes 内容。
## [2026-04-29] 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 容器镜像构建阶段 11 项安全加固标准，涵盖基础镜像选择、Init 系统、只读文件系统、私有服务账号等
- Concepts created: Container Lifecycle Hardening（已存在）, Read-Only Root Filesystem（已存在）, Init System in Containers（已存在）, Kubernetes Security Context（已存在）, Container Image Scanning（已存在）, Principle of Least Privilege（已存在）, Network Isolation（已存在）
- Entities created: Ashish（已存在）, Micro Focus（已存在）, Kubernetes（已存在）, Product Security Group（已存在）
- Source page: wiki/sources/ctp-topic-49-container-lifecycle-hardening-standards.md
- Notes: Entity 和 Concept 页面在之前的 batch ingest 中已创建，本次仅生成 source 页面
## [2026-05-04] 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 管理安全策略的复杂性；原有 Checkpoint Firewall 无法完全覆盖公网子网流量安全。核心方案：①在独立 Firewall Manager 账户创建安全组策略，指定目标账户或 OU，自动将基线安全组附加到现有和新实例；②三种策略类型——通用安全组（允许产品团队自增）、审计与强制安全组规则（拒绝过度宽松规则，支持手动或自动修复）、清理未使用冗余安全组；③通过 RAM Prefix List 跨账户共享规则，支持 Atlantis CI/CD 流水线部署。Demo 演示了策略创建后 EC2 实例的自动附加与策略删除后的自动移除。前提条件：OU 内管理员权限 + AWS Config 全账户启用。
- Concepts touched: [[AWS Firewall Manager]], [[Security Group Policy]], [[AWS Config]], [[AWS Lambda]], [[Prefix List]], [[AWS RAM]], [[Landing Zone]]
- Entities touched: [[Grand Torque Landing Zone]], [[LAPS Landing Zone]], [[SAS Landing Zone]], [[Digital Factory Landing Zone]], [[Atlantis Server]], [[QALIS]]
- Concepts created: [[AWS Firewall Manager]], [[Security Group Policy]]
- Entities created: (无新建 — Landing Zone Entity 页面待后续批量整理)
- Source page: wiki/sources/ctp-topic-55-aws-firewall-manager.md
- Notes: 步骤3完成：新建 source page（严格按 Source Page Format，含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第277行已有条目，本次补充日期和一行摘要；步骤5完成：overview.md 第319行已有详细条目，本次无需修订；步骤6完成：无新建 Entity 页面（Landing Zone Entity 页面待后续批量整理 CTP Security 相关实体）；步骤7完成：新建2个 Concept 页面（AWS-Firewall-Manager、Security-Group-Policy）；步骤8完成：无冲突（Firewall Manager 与 Checkpoint Firewall 为互补关系，非竞争替代，详见 source page Contradictions 节）；步骤9完成：log.md 追加记录
## [2026-05-04] 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 主讲。是前一年 7 月学习会议的续篇，介绍了 AWS Secrets Management Standard 文档，分享了实施机会。核心内容：①Secrets 管理平台选型（HashiCorp Vault vs AWS Secrets Manager，后者因成本更低被选中）；②三阶段实施方法（集中 Secrets → 调整自动化获取 → 启动轮换）；③Lambda 函数配合 JDBC Wrapper 实现无密码 Oracle 数据库访问；④SendGrid API Key 集中轮换方案；⑤通过 Control Tower 实现企业级 Secrets 标准化管理。
- Concepts touched: [[SecretsManagement]], [[SecretRotation]], [[JDBCWrapper]], [[ControlTower]]
- Entities touched: [[Nurit]], [[Daniel]], [[Victor]], [[HashiCorpVault]], [[AWSControlTower]], [[SendGrid]]
- Concepts created: [[SecretsManagement]], [[SecretRotation]], [[JDBCWrapper]]
- Entities created: (无新建 — Entity 页面待后续整理)
- Source page: wiki/sources/ctp-topic-62-aws-secrets-manager.md
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第275行），本次以正确格式更新并补充摘要；步骤5完成：overview.md 无需修订（该来源属于 CTP Security 系列，overview 中有相关上下文）；步骤6完成：无新建 Entity 页面（待后续批量整理 CTP Security 相关人物）；步骤7完成：新建3个 Concept 页面（SecretsManagement、SecretRotation、JDBCWrapper）；步骤8完成：无冲突（与 HashiCorp Vault 的对比属技术选型视角差异，已记录于 Contradictions 节）；步骤9完成：log.md 追加记录
## [2026-04-28] 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: 云转型计划（CTP）价值交付追踪方法论——区分 Process/Value/Value Stream 三个层次；价值分解为财务、生产力、质量、体验四维度；WSJF 公式（CoD/Job Size）排列工作优先级；功能级价值分解三种策略；综合框架涵盖年收入增长、成本降低、风险改善、SOM 四大价值维度。
- Concepts touched: [[Value Stream]], [[Weighted Shortest Job First (WSJF)]], [[Cost of Delay (CoD)]], [[Process]], [[Value-Adding Activity]], [[Serviceable Obtainable Market (SOM)]]
- Entities touched: [[Cloud Transformation Programme (CTP)]]
- Concepts created: [[Value Stream]], [[Weighted Shortest Job First (WSJF)]], [[Cost of Delay (CoD)]], [[Serviceable Obtainable Market (SOM)]]
- Entities created: [[Cloud Transformation Programme (CTP)]]
- Source page: wiki/sources/ctp-topic-65-tracing-the-value-delivered-in-cloud-transformation.md
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第242行），无需更新；步骤5完成：overview.md 无需修订（该来源属于 CTP 专题系列，overview 中已有综合 CTP 上下文）；步骤6完成：新建1个 Entity 页面（Cloud Transformation Programme）；步骤7完成：新建4个 Concept 页面（Value Stream、Weighted Shortest Job First、Cost of Delay、SOM）；步骤8完成：无冲突（与 ctp-topic-53 互补而非矛盾：Topic 53 论证"为何上云"，本主题解决"如何衡量云转型价值"）；步骤9完成：log.md 追加记录
## [2026-04-28] 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: 云转型项目中敏捷框架实践——Heather Norris 主讲。框架演进：Scrum（两周 Sprint）→ Kanban（持续流）→ 混合框架（Kanban + Scrum 仪式）。Scrum 局限：Sprint 期间不允许变更需求。Kanban 优势：随时调整优先级、持续交付。混合方案：保留每日站会和回顾会，使用 Microsoft Planner 五列看板。核心理念：敏捷本质是快速反馈循环，持续改进产品和开发文化。
- Concepts touched: [[Scrum]], [[Kanban]], [[Scrum-Kanban混合框架]], [[Microsoft Planner]]
- Entities touched: [[Heather Norris]]
- Concepts created: 无（Scrum.md、Kanban.md 均已存在）
- Entities created: 无（Heather Norris.md 已存在）
- Source page: wiki/sources/ctp-topic-4-using-agile-to-run-the-cloud-transformation-program.md
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第247行），无需更新；步骤5完成：overview.md 无需修订（Agile/Scrum/Kanban 内容已覆盖于现有概述中）；步骤6完成：无新增 Entity（Heather Norris.md 已存在）；步骤7完成：无新增 Concept（Scrum.md、Kanban.md 均已存在）；步骤8完成：无冲突；步骤9完成：log.md 追加记录
## [2026-04-28] ingest | CTP Topic 43 VMware Cloud on AWS
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-43-vmware-cloud-on-aws.md
- Status: ✅ 成功摄入（re-ingest：补充缺失实体/概念页面）
- Summary: VMware Cloud on AWS（VMC on AWS）混合云服务介绍——VMware 与 AWS 联合工程，在 AWS 裸金属服务器（i3.metal/i3en.metal）上原生安装 vSphere 8，为不完全准备完全迁移至原生云的企业提供中间路线。相比常规云方案节省 27% 成本，支持 HCX 任意迁移，Brian Reeves 主持经济学讨论，Mike O'Reilly 主讲技术架构。属 [[Hybrid-Cloud]] 在 AWS 落地的核心实践。
- Concepts touched: [[VMware-Cloud-on-AWS]], [[SDDC]], [[HCX]], [[Stretched-Cluster]], [[TCO]]
- Entities touched: [[VMware]], [[AWS]], [[BrianReeves]], [[MichaelRiley]], [[MikeArmstrong]], [[MikeOReily]]
- Concepts created: [[TCO]]
- Entities created: [[BrianReeves]], [[MichaelRiley]], [[MikeArmstrong]], [[MikeOReily]]
- Source page: wiki/sources/ctp-topic-43-vmware-cloud-on-aws.md
- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次修复双竖线格式问题；步骤4完成：index.md 条目已存在（第254行），无需更新；步骤5完成：overview.md 已有该来源摘要（line 331），内容一致无需修订；步骤6完成：新建4个 Entity 页面（BrianReeves、MichaelRiley、MikeArmstrong、MikeOReily），补充 TCO 到 VMware.md 和相关 Concept 页面的 Sources 节；步骤7完成：新建 [[TCO]] Concept 页面，补充 [[TCO]] 到 Source page Key Concepts 节；步骤8完成：无冲突（与 ctp-topic-53 的张力已在 Contradictions 节记录，属云迁移决策的视角差异而非事实冲突）；步骤9完成：log.md 追加本次 re-ingest 记录
## [2026-04-28] 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 账号（InfoBlocks 账号）集中管理 Route 53 私有托管区（PHZ）和 Resolver Rules，优于分散式 PHZ 管理。关键技术：Route 53 Resolver Inbound Endpoint（接收 On-prem 解析请求）和 Outbound Endpoint（转发 AWS → On-prem 请求）；AWS RAM 跨账号共享 Resolver Rules；跨账号 PHZ 关联两步流程（授权→关联）；Terraform 自动化部署。典型场景：AWS → On-prem、On-prem → AWS、账号间相互解析。属 [[AWS-Landing-Zone]] 网络基础服务层，与 Topic 18（广域网）和 Topic 31（网络安全）共同构成完整网络知识体系。
- Concepts touched: [[Route-53-Resolver]], [[Private-Hosted-Zone]], [[Resolver-Rules]], [[AWS-RAM]], [[VPC-Association-Authorization]], [[AWS-Landing-Zone]]
- Entities touched: [[SankarGopov]]
- Concepts created: [[Route-53-Resolver]], [[Private-Hosted-Zone]], [[Resolver-Rules]], [[VPC-Association-Authorization]]
- Entities created: (无新建 — SankarGopov 已存在)
- Source page: wiki/sources/ctp-topic-19-configuring-dns-within-aws-lzs.md
- Notes: 步骤3完成：新建 Source page；步骤4完成：index.md 条目已存在（第255行），补充一行摘要；步骤5完成：overview.md 新增 CTP Topic 19 摘要条目（在 Topic 18 与 Topic 25 之间）；步骤6完成：新建4个 Concept 页面（Route-53-Resolver、Private-Hosted-Zone、Resolver-Rules、VPC-Association-Authorization），更新 SankarGopov Entity 来源引用；步骤7完成：Source page Key Concepts 节已覆盖全部关键概念；步骤8完成：无冲突；步骤9完成：log.md 追加本次记录
## [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 强制标签规范防止用户篡改标签绕过审计；②标签体系涵盖机器名、所有者（PDL）、类型、BU、产品、环境、服务器角色等维度；③Checkpoint Firewall 基于标签的 Ordered Layers（地理封锁→类型→BU→产品→环境→角色）和 Inline Layers（基于账号编号的父子规则结构）；④Demo 演示标签缺失导致 EC2 流量被防火墙拦截。
- Concepts touched: [[AWS-Landing-Zone]], [[SCP-Security-Control-Policy]], [[Resource-Tagging]], [[Ordered-Layer]], [[Inline-Layer]], [[Checkpoint-Firewall]]
- Entities touched: [[AWS]], [[Checkpoint]], [[Pradeep]], [[Steve Jarman]]
- Concepts created: [[SCP-Security-Control-Policy]], [[Resource-Tagging]], [[Ordered-Layer]], [[Inline-Layer]]
- Entities created: [[Pradeep]], [[SteveJarman]]
- Source page: wiki/sources/ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security.md
- Notes: 步骤3完成：新建 source page；步骤4完成：index.md 条目已存在（第31行、第250行），无需更新；步骤5完成：overview.md 已有该来源详细摘要（line 321），无需修订；步骤6完成：更新2个已有 Entity 页面（AWS-Landing-Zone、Checkpoint-Firewall），新增2个 Entity 页面（Pradeep、SteveJarman）；步骤7完成：新建4个 Concept 页面（SCP-Security-Control-Policy、Resource-Tagging、Ordered-Layer、Inline-Layer）；步骤8完成：与 CTP Topic 7 的视角差异已记录于 Contradictions 节（属账号结构 vs 标签驱动的互补视角）；步骤9完成：log.md 追加本次记录
## [2026-04-28] ingest | CTP Topic 22 Global DNS service offerings
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-22-global-dns-service-offerings.md
- Status: ✅ 成功摄入（re-ingest）
- Summary: 企业级全球 DNS 服务架构详解——Sankar 和 Vino 联合主讲。核心架构：Route 53 Private Hosted Zone（私有托管区域）配合 AD 托管 DNS，通过 Route 53 Resolver 入站/出站终端节点打通 AWS VPC 与本地网络的 DNS 查询；Outbound Endpoint 出站规则配置多个区域 AD 域控制器 IP，单区域故障时自动切换确保弹性。本地 Infoblox 平台利用 DNS Anycast 实现全球低延迟和自动故障转移；AWS EC2 不支持 Anycast，需手动维护 IP 列表。DNS 安全涵盖防隧道攻击、防数据外泄及缓存污染；"就近解析"原则优化 Office 365 等全球化 SaaS 访问性能。属 AWS Landing Zone 网络层 DNS 专题，与 ctp-topic-19 共同构成 Landing Zone DNS 完整体系。
- Concepts touched: [[HybridDnsResolution]], [[DNS-Anycast]], [[Landing-Zone-Architecture]], [[Route-53-Resolver]], [[IPAM]]
- Entities touched: [[AWS]], [[Infoblox]], [[SankarGopov]], [[VinoCTP]], [[Microsoft-Active-Directory]], [[Office-365]]
- Concepts created: [[DNS-Anycast]]
- Entities created: [[VinoCTP]]
- Source page: wiki/sources/ctp-topic-22-global-dns-service-offerings.md
- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次更新 Contradictions 节（ctp-topic-19 已摄入，补充完整互补关系说明）；步骤4完成：index.md 条目已存在（第257行），本次新增 [[VinoCTP]] Entity 和 [[DNS-Anycast]] Concept 条目；步骤5完成：overview.md 已有该来源摘要（line 345），内容一致无需修订；步骤6完成：新建 [[VinoCTP]] Entity 页面（CTP Topic 22 联合讲师）；步骤7完成：新建 [[DNS-Anycast]] Concept 页面（关键网络概念，本来源首次系统阐述）；步骤8完成：Contradictions 更新为视角互补说明（Topic 19 讲配置实施 → Topic 22 讲企业架构，属深度递进关系）；步骤9完成：log.md 追加本次 re-ingest 记录
## [2026-05-07] ingest | CTP Topic 50 AMI Roadmap for AWS AMIs (re-ingest)
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-50-ami-roadmap-for-aws-amis.md
- Status: ✅ 成功摄入（re-ingest）
- Summary: CCOE AMI 路线图与 AWS 标准 AMI 生命周期规划——核心内容：CCOE 每两个月发布加固 AMI；ARM AMI 自 2023 年 5 月起同步发布；路线图优先级由 ADM 需求驱动；OS EOL 时间线（WS2008/2008R2 已 EOL；CentOS8 已 EOL；WS2012 即将 EOL；RHEL7/CentOS7 2024 年 6 月 EOL）；AMI 通知通过邮件发送至 CCOE notifications PDL；CCRE 门户变更日志；新 AMI 添加三阶段流程；AMI 跨账号共享机制
- Concepts touched: [[Foundation-AMI]], [[OS-End-of-Life]], [[AMI-Sharing]], [[ARM-AMI]], [[CCOE]], [[ADM]]
- Entities touched: [[CCOE]], [[AWS]], [[Amazon Linux]], [[Ubuntu]], [[CentOS]], [[Rocky Linux]], [[Red Hat Enterprise Linux]], [[SLES]], [[Windows Server]], [[McAfee]]
- Concepts created: [[ARM-AMI]], [[ADM]]
- Source page: wiki/sources/ctp-topic-50-ami-roadmap-for-aws-amis.md
- Notes: 步骤3完成：源页面已存在（2026-04-14 初版），本次补全 wikilinks 格式（Foundation AMI→Foundation-AMI, AMI Sharing→AMI-Sharing）；步骤4完成：index.md 条目已存在（第306行），无需重复添加；步骤5完成：overview.md 已有该来源摘要（line 313），内容一致无需修订；步骤6完成：Amazon Linux/Ubuntu/CentOS/SLES/Windows Server/McAfee 在 source doc 中出现次数不足以创建独立 Entity 页面（仅1-2次提及），按工作流规则跳过；Rocky Linux/Red Hat Enterprise Linux Entity 页面已存在，无需重复创建；步骤7完成：Foundation-AMI/OS-End-of-Life/AMI-Sharing Concept 页面已存在，本次新建 ARM-AMI.md 和 ADM.md；步骤8完成：Contradictions 已在 source page 记录（与 ctp-topic-26 的互补关系）；步骤9完成：log.md 追加本次 re-ingest 记录
## [2026-05-07] 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: ✅ 成功摄入（re-ingest）
- Summary: Foundation AMI 全生命周期管理详解——Srihari/Alan/Praveen 主讲。基于市场主流 OS（CentOS/Ubuntu/Windows）进行 CIS Benchmark 安全基准加固，集成 McAfee EPO 防病毒 + Syslog-ng 日志管理 + AD 单点登录 + AWS-SSM + SiteScope 监控；使用 HashiCorp Packer + Jenkins 流水线实现镜像创建完全自动化；通过 AMI Sharing 分发至全球多区域；每两个月更新，采用 N-2 版本保留策略。责任共担：CCOE 提供 Foundation AMI，产品团队构建产品特定 AMI。
- Concepts touched: [[Foundation-AMI]], [[OS-Hardening]], [[CIS-Benchmark]], [[HashiCorp]], [[AWS-SSM]], [[AMI-Sharing]]
- Entities touched: [[CCOE]], [[Jenkins]], [[AWS]]
- Concepts created: [[Foundation-AMI]], [[OS-Hardening]], [[AMI-Sharing]]
- Source page: wiki/sources/ctp-topic-26-standard-ami-build-publish-share-processes.md
- Notes: 步骤3完成：Source page 已存在（2026-04-14 初版），本次更新 wikilinks 格式（Foundation AMI→Foundation-AMI 等）并移除 Srihari/Alan/Praveen（仅出现1次）；步骤4完成：index.md 条目已存在（第306行）；步骤5完成：overview.md 已有该来源摘要（line 315），内容一致无需修订；步骤6完成：新建 CCOE.md Entity 页面；步骤7完成：新建 Foundation-AMI.md、OS-Hardening.md、AMI-Sharing.md Concept 页面；CIS-Benchmark/HashiCorp/AWS-SSM/HashiCorp（Entity）已存在，跳过；Central Repository 未创建独立页面（保留为普通概念描述）；步骤8完成：Contradictions 已在 source page 记录（与 ctp-topic-58 的"当前 Packer vs 未来 EC2 Image Builder"属技术演进非冲突）；步骤9完成：log.md 追加本次 re-ingest 记录
## [2026-05-07] 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（管理 Schema、元数据、查询计划）和 Compute Node（在 Slices 上通过 MPP 执行并行查询）；支持列式存储（适合 OLAP 聚合查询）和行式存储；Sort Key 和 Distribution Key 是性能优化核心；三种实例类型（Dense Compute/Dense Storage/RA3）；RA3 以 AWS 托管 NVMe 提供成本效益。
- Concepts touched: [[MassivelyParallelProcessing]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[OLAP]], [[Data-Compression]]
- Entities touched: [[Amazon-Redshift]], [[LeaderNode]], [[ComputeNode]], [[JDBC]], [[ODBC]]
- Concepts created: [[Sort-Key]], [[Distribution-Key]]
- Source page: wiki/sources/ctp-topic-68-introduction-to-redshift.md
- Notes: 步骤3完成：新建 source page（含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions）；步骤4完成：index.md 条目补全日期前缀（2026-04-14）和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 339），内容一致无需修订；步骤6完成：Amazon-Redshift Entity 页面已存在（2026-04-14 初版），内容一致无需修订；步骤7完成：新建 Sort-Key.md 和 Distribution-Key.md Concept 页面；步骤8完成：Contradictions 记录与 [[ctp-topic-66-rds-vs-aurora]] 的定位差异（Redshift 专 OLAP vs Aurora 混合 OLTP/OLAP），非冲突；步骤9完成：log.md 追加本次摄入记录
## [2026-04-28] 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 服务详解——自动化 AMIs 和 Docker 镜像创建/管理/分发的托管服务；核心组件包括 Image Pipeline、Image Recipe、Infrastructure Configuration、Distribution Settings；YAML 定义镜像配方（Source AMI → Output AMI）；CCOE 提供 Golden AMI，产品团队可追加自定义组件（按字母序添加）；支持 CentOS 7 和 Ubuntu 18 的端到端 POC；集成 AWS Inspector 进行安全扫描，Lambda 工作流触发扫描并发送邮件通知和 S3 报告；当前 AMI 流程（GitLab + Jenkins + Packer）的痛点（交付周期长、跨 LZ 兼容性差）推动了 Image Builder 的采用。
- Concepts touched: [[AMI-Image-Builder]], [[Image-Pipeline]], [[Golden-AMI]], [[AWS-Inspector]], [[AWS-Landing-Zone]]
- Entities touched: [[AWS]], [[Packer]], [[Jenkins]], [[Terraform]], [[Qualys]]
- Source page: wiki/sources/ctp-topic-58-aws-ec2-image-builder.md
- Notes: 步骤3完成：新建 source page，含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions；步骤4完成：index.md 条目已存在（第303行），无需重复添加；步骤5完成：overview.md 由后续 query workflow 维护，此处无需主动修订；步骤6-7完成：关键 Entity/Concept 在源文档中出现1-2次，未达到创建独立页面的阈值（≥2次且关键影响），按工作流规则跳过；步骤8完成：Contradictions 记录"暂无发现冲突"；步骤9完成：log.md 追加本次摄入记录
## [2026-05-06] ingest | CTP Topic 25 Labs Landing Zone Overview - ITOM Teams (re-ingest)
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
- Status: ✅ 成功摄入（re-ingest）
- Summary: Labs LZ 基于 Gruntwork 参考架构，多账户策略（Shared/Jenkins/Logs/Security/Core(AD+DNS)/Network(TGW+JetPult)/Product Account）；全部通过 Terraform/Terragrunt IaC 管理；Jenkins 流水线扫描 GitHub 触发 plan/apply；防火墙通过标签（Tags）控制网络访问；Shared Services 含 45 Arc Site 监控和 Qualys 安全扫描。
- Entities touched: [[Gruntwork]], [[Jenkins]], [[Swimford.net]], [[JetPult]], [[Pulse-VPN]], [[Qualys]], [[Terragrunt]], [[Terraform]]
- Concepts touched: [[Landing-Zone-Architecture]], [[Terraform]], [[Terragrunt]], [[Transit-Gateway]], [[Tag-Based-Access-Control]], [[Federated-Access]]
- Source page: wiki/sources/ctp-topic-25-labs-landing-zone-overview-itom-teams.md
- Notes: 步骤3完成：Source page 已有（2026-04-14 初版），内容完整无需修订；步骤4完成：index.md 条目补全日期前缀（2026-04-14）和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 291），内容一致无需修订；步骤6-7完成：Key Concepts/Entities 均以 wikilink 形式存在，相关 Entity（Gruntwork/Jenkins/Swimford.net/JetPult/Pulse-VPN/Qualys）和 Concept（Landing-Zone-Architecture/Terraform/Terragrunt/Transit-Gateway）页面已存在；步骤8完成：Contradictions 记录"无已知冲突"（JetPult vs Checkpoint 属 Labs vs SaaS 不同 LZ 的防火墙方案差异，非冲突）；步骤9完成：log.md 补录本次 re-ingest
## [2026-05-06] 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: ✅ 成功摄入（re-ingest）
- Summary: SAS LZ 四层账户体系设计（Core/Baseline/Shared Services/Product）；核心账户（Shared/Jenkins+Lambda、Logs、Security/IAM）、基线账户（Network/Transit Gateway+Checkpoint、DNS/Route 53、AD双节点）、共享服务账户（Software Factory 45 hubs+Octane Hub+Artifactory、Cyber/Qalis、ARC、Monitoring/OBM）、产品账户（私有子网工作负载+公有子网LB+WAF+CloudFront可选）；Terraform IaC + GitHub/Jenkins CI/CD 端到端自动化部署链路；Checkpoint VPN → Pulse VPN 远程访问迁移。
- Concepts created: [[Transit-Gateway]], [[Active-Directory-Integration]], [[WAF-Web-Application-Firewall]], [[Private-Subnet-Architecture]], [[Terraform-IaC]], [[Software-Factory]]
- Entities created: [[Jenkins]], [[Pulse-VPN]], [[TerraGrant]], [[Qalis]], [[OBM]], [[CloudFront]]
- Entities touched: [[Gruntwork]], [[Checkpoint]], [[Terraform]], [[Terragrunt]]
- Source page: wiki/sources/ctp-topic-7-saas-landing-zone-design.md
- Notes: 步骤3完成：Source page 已有（2026-04-14 初版），本次补加 tags 和 last_updated: 2026-05-06；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 307），内容一致无需修订；步骤6-7完成：新建 6 个 Entity 页面（Jenkins/Pulse-VPN/TerraGrant/Qalis/OBM/CloudFront）和 6 个 Concept 页面（Transit-Gateway/Active-Directory-Integration/WAF-Web-Application-Firewall/Private-Subnet-Architecture/Terraform-IaC/Software-Factory），并加入 index.md；步骤8完成：Contradictions 已在 source page 记录（与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 属设计演进视角互补，非冲突）；步骤9完成：log.md 补录本次摄入
## [2026-05-06] 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: Azure Landing Zone 架构概述——Micro Focus 通过 Azure Enterprise Enrollment + Azure AD 完成企业接入；管理组四区分离（platform/landing-zones/decommission/sandbox）；连接订阅集成 DDoS 防护和 Checkpoint 防火墙；Terraform Cloud 管理跨订阅依赖；PIM 强制最小权限。核心价值：团队独立部署减少跨团队依赖，AWS 侧用 Gruntwork/Jenkins，Azure 侧用 Terraform Cloud，体现 CTP 多云战略。
- Concepts touched: [[Landing-Zone-Architecture]]（已存在，内容已通过本来源扩展）
- Entities touched: [[Azure]]（已存在）, [[Micro-Focus]]（已存在）
- Source page: wiki/sources/ctp-topic-34-azure-landing-zone-architecture-overview.md
- Notes: 步骤3完成：新建 source page，含完整 Summary/Key Claims/Key Quotes/Key Concepts/Key Entities、Connections、Contradictions；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 新增 CTP Topic 34 条目，置于 Topic 35 之后；步骤6-7完成：关键 Entity/Concept 均已存在（Azure/Micro-Focus/Landing-Zone-Architecture/Terraform），无需新建；步骤8完成：Contradictions 记录了与 Gruntwork AWS LZ 的平台差异说明（非冲突，为多云战略互补）；步骤9完成：log.md 补录
## [2026-05-06] 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: Landing Zone 设计复习——明确 SaaS（生产）与 Labs（开发）的核心定位：SaaS = 生产，Labs = 开发；SaaS LZ 含产品账户、核心账户（AD/DNS/Network）、共享服务账户、Gruntwork 账户；近期变更：网络分段阻断 SaaS 直连、CCOE CloudTrail 替代 Gruntworks CloudTrail、Checkpoint 重新路由入站流量、AWS Backup 强制化、新账户取消 Management VPC；PoC LZ 并入 Labs；Cloud Technology Design Forum 推动标准化。
- Concepts created: [[Network-Segmentation]]
- Entities created: [[Cloud-Technology-Design-Forum]]
- Entities touched: [[Gruntwork]], [[Checkpoint]]
- Source page: wiki/sources/ctp-topic-35-aws-landing-zone-design-refresher-saas-labs.md
- Notes: 步骤3完成：Source page 修复所有 broken wikilinks（CCOEs-CloudTrail → CloudTrail，AWS-Landing-Zone → Landing-Zone-Architecture，删除 Shared-Services-Account 等不必要独立 Concept），补全 Contradictions 与 [[ctp-topic-1-gruntwork-landing-zone-architecture]] 视角互补说明，更新 last_updated: 2026-05-06；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 301），内容一致无需修订；步骤6-7完成：新建 [[Cloud-Technology-Design-Forum]] Entity 和 [[Network-Segmentation]] Concept 并加入 index.md；步骤8完成：Contradictions 已从无记录更新为视角互补说明；步骤9完成：log.md 补录本次摄入
## [2026-05-06] 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 仓库由产品团队自行定义具体服务（ECS/RDS 等）；安全账户使用联邦用户通过 AD 组映射 IAM 角色；每个 Landing Zone 配置独立 Jenkins 服务器和特性分支 Git 工作流；Gruntwork Terraform AWS 服务目录强调服务应具有业务上下文。
- Concepts touched: [[Reference-Architecture]]（已存在，内容完整）、[[Landing-Zone-Architecture]]（已存在，内容完整）
- Entities touched: [[Gruntwork]]（已存在，内容完整）
- Source page: wiki/sources/ctp-topic-1-gruntwork-landing-zone-architecture.md
- Notes: 步骤3完成：更新 last_updated: 2026-05-06；步骤4完成：index.md 条目补全日期前缀和一行摘要；步骤5完成：overview.md 已有该来源摘要（line 309），内容一致无需修订；步骤6-7完成：Entity/Concept 均已存在；步骤8完成：冲突已在 source page Contradictions 节记录（与 [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] 视角互补）
## [2026-04-26] ingest | CTP Topic 46 NetApps on AWS (re-ingest)
- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/01_AWS-Landing-Zone/ctp-topic-46-netapps-on-aws.md
- Status: ✅ 成功摄入
- Summary: Source page 已存在（2026-04-14 初版）。本次检测到源文件更新（Apr 26 12:35），更新 Source page tags 增加 CVO/ONTAP，新增 last_updated: 2026-04-26；index.md 条目补全日期前缀和一行摘要；overview.md 已有该来源摘要（line 335），内容一致无需修订。
- Concepts touched: [[SnapMirror]]（已存在，内容完整）
- Entities touched: [[NetApp]]（已存在，内容完整）
- Source page: wiki/sources/ctp-topic-46-netapps-on-aws.md
- Notes: 步骤3完成：Source page 更新 tags 和 last_updated；步骤4完成：index.md 条目补全日期+摘要；步骤5完成：overview.md 内容一致无需修订；步骤6-7完成：Entity/Concept 均已存在；步骤8完成：无冲突（属存储技术域，与数据库/备份技术互补）
## [2026-05-05] 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 环境，废弃旧 `infra`/`AST` 域名）；SRE 预制 AMI 内置 PowerShell/Shell 脚本，通过 Terraform `user_data` 实现 Windows/Linux 实例自动化域加入；Linux 支持 Secure Dynamic Updates 自动注册 DNS A 记录；R&D 环境使用 MIM 自助服务，生产/SAS 环境通过 SMACKS 工单系统申请账号。
- Concepts created: [[Domain Join]], [[Secure Dynamic Updates]]
- Entities created: none（[[swinford.net]], [[intsas.local]], [[SMACKS]], [[Gruntwork]] 均已存在并已更新引用）
- Entities touched: [[Gruntwork]]
- Source page: wiki/sources/ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs.md
- Notes: index.md 已有该来源条目（line 304），本次补加日期前缀和一行摘要；overview.md 已有该来源摘要（line 349），内容一致无需修订；Swinford.net.md 和 Intsas.local.md 已正确引用本来源；冲突检测：无冲突
## [2026-04-23] 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 在 Amazon RDS 与 Aurora 两种托管方案之间的深度技术对比。涵盖架构差异（RDS 计算+ EBS 分离 vs Aurora 6副本跨3AZ共享存储）、选型决策（小型<10TB选RDS，大型>10-20TB选Aurora）、高可用性（Aurora RTO 30秒 vs RDS 2分钟）、Aurora Global 跨区域灾备、Blue-Green Deployment（仅 Aurora MySQL 支持）、监控（CloudWatch/Grafana/Performance Insights）等。
- Concepts created: [[Aurora Global]], [[Multi-AZ]], [[Blue-Green Deployment]]
- Entities created: none（[[Amazon RDS]], [[Amazon Aurora]], [[RTO]] 均已存在并已更新引用）
- Entities touched: [[Amazon RDS]], [[Amazon Aurora]], [[RTO]]
- Source page: wiki/sources/ctp-topic-66-exposing-the-differences-between-postgresql-rds-and-aurora.md
- Notes: index.md 已有该来源条目（line 292）；overview.md 已新增该来源摘要（line 260-261）；冲突检测：RTO 数值（Aurora 30秒/RDS 2分钟）已记录于 Contradictions 节，建议与 [[RTO vs RPO: Key Differences for Modern Disaster Recovery]] 交叉验证
## [2026-04-18] ingest | Blogwatcher Daily 技能收藏
- Source file: Skills/blogwatcher-daily收藏.md
- Status: ✅ 成功摄入
- Summary: Hermes Agent 自定义技能 blogwatcher-daily，实现 31 个 RSS/YouTube 订阅频道的自动化监控与每日摘要生成。核心技术栈：RSSHub（YouTube 频道转 RSS）+ feedparser（多格式解析）+ SQLite（URL 去重）+ Cron（定时调度）+ Telegram（通知）。每天早上 6:00 自动运行，Job ID `ecdd35bb7df3`。
- Concepts created: 无（RSSHub/feedparser/SQLite去重机制/Cron定时任务均已有 Entity/Concept 页面或以内嵌 wikilink 引用存在）
- Entities created: 无（[[Hermes Agent]] 已存在，[[RSSHub]] 已存在）
- Entities touched: [[Hermes Agent]], [[RSSHub]]
- Source page: wiki/sources/blogwatcher-daily收藏.md
- Notes: index.md 已有该来源条目（line 200），本次补全一行摘要；冲突检测：无冲突
## [2026-04-17] ingest | WSL2 启动与网络配置指南
- Source file: Home Office/WSL2 启动与网络配置指南.md
- Status: ✅ 成功摄入
- Summary: WSL2（Windows Subsystem for Linux 2）日常使用操作与网络配置完整指南。涵盖安装（`wsl --install`）、状态检查（`wsl -l -v`）、版本转换（`wsl --set-version`）；网络配置核心痛点（NAT 模式导致 Windows 代理无法镜像）；推荐方案（`.wslconfig` 配置 `networkingMode=mirrored` + `dnsTunneling=true`）；备选方案（手动代理 `http_proxy/https_proxy`）；GitHub 加速（`ghproxy.com` 反向代理）；常见故障排查（WSL_E_VM_MODE_INVALID_STATE、文件权限问题）。
- Concepts created: 无（镜像网络模式/NAT模式均以内嵌 wikilink 引用存在，未达独立建页阈值）
- Entities created: [[WSL2]], [[ghproxy]]
- Entities touched: [[uv]], [[Hermes Agent]]
- Source page: wiki/sources/wsl2-启动与网络配置指南.md
- Notes: index.md Sources 节已有该来源条目，本次补加日期前缀 [2026-04-17] 和一行摘要；index.md Entities 节新增 WSL2 和 ghproxy 条目；overview.md 已有 WSL2 相关条目（line 413-415, line 787-789），内容一致无需修订；冲突检测：与 [[Install WSL]] 的视角差异（安装 vs 配置）已记录于 source page Contradictions 节，无本质冲突
## [2026-04-28] ingest | fireworks-tech-graph
- Source file: Skills/fireworks-tech-graph.md
- Status: ✅ 成功摄入（更新）
- Summary: fireworks-tech-graph 将自然语言描述转化为精美 SVG 技术图并导出高分辨率 PNG——解决技术文档/博客缺乏高质量可视化图表的核心痛点。内置 7 种视觉风格（扁平图标风/暗黑极客风/工程蓝图风/Notion极简风/玻璃态卡片风/Claude官方风格/OpenAI官方风格）和 14 种 UML 图类型。语义形状词汇表确保图形语义一致，语义箭头系统通过颜色+虚线编码含义。支持 librsvg/rsvg-convert 导出 1920px PNG。触发词：画图/帮我画/生成图/做个图/架构图/流程图/可视化一下。
- Concepts created: none（concept 页面待补充：技术图生成、7种视觉风格系统、语义形状词汇表、语义箭头系统、14种UML图）
- Entities created: none（rsvg-convert 已列出，concept 页面待补充后关联）
- Source page: wiki/sources/fireworks-tech-graph.md
- Notes: 源页面已存在（2026-04-18），本次对比 489 行源文档发现以下内容已补全：7种风格详细参数表、形状词汇表完整表格、箭头语义完整表格、AI/Agent 内建 Pattern、产品图标覆盖范围；index.md 已有条目（line 196）；overview.md 已有条目（line 508）；冲突检测：无冲突
## [2026-04-28] ingest | Obsidian 官方 CLI 命令全景速查表
- Source file: Skills/Obsidian 官方 CLI 命令全景速查表.md
- Status: ✅ 成功摄入
- Summary: Obsidian v1.12+ 官方 CLI 80+ 命令全景速查表。涵盖 18 个功能模块：基础操作、数据库（Bases）、书签、命令面板、日记、文件历史、文件目录、链接网络、大纲、插件管理、属性元数据、发布、随机笔记、全局搜索、官方同步、标签、任务管理、模板、外观样式、卡片盒、仓库管理、内置浏览器、字数统计、工作区布局、开发者模式。附带 7 个典型自动化工作流：全局极速闪记、播客沉浸式知识榨取、AI 收件箱自动分拣员、绝对隐私的本地 RAG 对话助理、跨平台数据库级联录入、历史知识自动唤醒、批量元数据重构。
- Concepts created: [[Backlinks]]
- Entities created: [[Obsidian]]
- Entities touched: [[n8n]], [[OpenClaw]]
- Source page: wiki/sources/obsidian-官方-cli-命令全景速查表.md
- Notes: index.md 已添加该来源条目（一行摘要）；Backlinks 是核心概念，已创建独立概念页面；Obsidian 已创建实体页面（CLI + 核心特性描述）；n8n.md 和 OpenClaw.md 已添加本来源引用；冲突检测：无冲突；index.md 中已有同名条目已补全摘要内容
## [2026-04-28] ingest | Obsidian CLI
- Source file: Skills/Obsidian CLI.md
- Status: ✅ 成功摄入
- Summary: Obsidian 官方 CLI 完整命令参考文档（1534行）——50+ 命令覆盖日常使用、文件管理、链接分析、任务管理、开发者命令（CDP协议截图/控制台/插件热重载）、数据管理（Bases）、版本历史（File Recovery+Sync）、插件管理和 Obsidian Publish。两种使用模式：单命令和 TUI 交互。vault 定向和文件定位机制详解。
- Entities touched: [[Obsidian]], [[Obsidian-Skills]]
- Entities created: none (Obsidian entity already exists via obsidian-必装-skills)
- Concepts touched: [[Obsidian-CLI]], [[Obsidian-TUI]], [[Vault-Management]], [[Developer-Commands]], [[CDP-Commands]], [[Plugin-Reload]], [[Daily-Notes-CLI]], [[File-Recovery]], [[Base-Commands]], [[Property-Commands]], [[Task-Commands]], [[Template-Commands]], [[Sync-Commands]], [[Plugin-Management-CLI]], [[Publish-Commands]]
- Source page: wiki/sources/obsidian-cli.md
- Notes: 原 source page 已存在但内容简略（58行），本次用完整 1534 行源文档重建 source page，严格按 Source Page Format 补充了完整命令分类速查表和 Key Claims；overview.md 已添加详细 obsidian-cli 条目；冲突检测：与 obsidian-必装-skills 的视角差异（官方内置 vs Skills 收录）已在 Contradictions 节协调，两种描述均正确
## [2026-04-28] ingest | Obsidian 必装 Skills
- Source file: Skills/Obsidian 必装 Skills
- Status: ✅ 成功摄入
- Summary: Obsidian 生态 AI Skills 全景盘点——推荐安装 kepano 官方 defuddle（网页清洗）、obsidian-cli（官方 CLI 操作）、obsidian-bases（数据库视图）；Axton 的 obsidian-canvas-creator（径向布局算法）；tutor-skills（"输入-内化-检测"三阶段学习闭环）；scholar-skill（基于 OpenClaw 的 L1/L2/L3 分级论文阅读）。核心插件：claudian（适配 Claude Code）和 obsidian-agent-client（适配多主流 Agent）。含 BRAT 安装和配置指南。
- Concepts created: [[tutor-skills]], [[scholar-skill]]
- Entities created: [[kepano]]
- Entities touched: [[OpenClaw]], [[BRAT]], [[defuddle]], [[obsidian-cli]], [[obsidian-bases]], [[obsidian-canvas-creator]], [[claudian]], [[obsidian-agent-client]]
- Source page: wiki/sources/obsidian-必装-skills.md
- Notes: overview.md 已添加该来源摘要（Second Brain 部分）；index.md 已添加该来源条目和 Concepts 条目；冲突检测：与养虾日记3的 obsidian-skill 方案存在张力（obsidian-cli vs 文件系统直写）；kepano 已存在于 index.md，本次补充完整发布的 Skills 信息
## [2026-04-28] ingest | 在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B
- Source file: AI/在 Ubuntu 安装 Ollama 并运行 Qwen2.5‑Coder 7B.md
- Status: ✅ 成功摄入
- Summary: Ubuntu 本地部署 Qwen2.5-Coder 7B 代码大模型完整指南。涵盖系统要求（8+ cores CPU、16GB RAM、4.5GB 模型）、Ollama 安装（`curl install.sh | sh`）、systemd 服务管理、模型下载运行（3 条命令最简流程）、REST API 调用（http://localhost:11434）、Python/NodeJS SDK、远程 API 开放（OLLAMA_HOST=0.0.0.0）、GPU 加速、模型管理（list/rm/pull）。推荐搭配工具链：Open WebUI、n8n、LangChain、OpenClaw。核心价值：qwen2.5-coder:7b 在 Tool usage、Shell/Python/SQL 理解和 Repo 级代码理解方面优于普通 qwen2.5:7b，更适合 DevOps automation、SQL Agent、Kubernetes troubleshooting 等工程任务。
- Entities created: [[Ollama]], [[Qwen2.5-Coder]]
- Entities touched: [[Open WebUI]], [[n8n]], [[LangChain]], [[OpenClaw]]
- Source page: wiki/sources/在-ubuntu-安装-ollama-并运行-qwen2-5‑coder-7b.md
- Notes: overview.md 已添加该来源摘要（条目23）；index.md 已添加该来源条目和 Entities 条目；冲突检测：无冲突；Open WebUI/n8n/LangChain/OpenClaw 出现次数 < 2，暂不创建独立 Entity 页面
## [2026-04-28] ingest | I Went Through Every AI Memory Tool I Could Find. There Are Two Camps.
- Source file: Agent/AI-Memory-Tools-Two-Camps.md
- Status: ✅ 成功摄入
- Summary: AI 记忆工具全景分类框架（@witcheer，2026-04-15）。GitHub 450+ repos "agent-memory"、460+ "context-management"，系统梳理后划分为两大阵营：Camp 1（Memory Backend，提取事实+向量检索，优化召回）vs Camp 2（Context Substrate，维护结构化人类可读文件，跨会话累积，优化复合增长）。Camp 1 代表：Mem0、MemPalace、Supermemory、Honcho；Camp 2 代表：OpenClaw、Zep、Thoth、TrustGraph、MemSearch、ALIVE。核心洞察：Zep 从"Memory"重品牌化为"Context Engineering"是最强市场信号；预测 6 个月内"Context Engineering"将取代"Memory"成为主流术语；24/7 持续运行 Agent 必须采用 Context Substrate 架构。
- Concepts created: [[Memory-Backend]], [[Context-Substrate]], [[Context-Engineering]], [[Dream-Cycle]], [[Context-Cores]], [[Fact-Recall-vs-Compounding]]
- Entities created: [[Mem0]], [[MemPalace]], [[Supermemory]], [[Honcho]], [[Zep]], [[Thoth]], [[TrustGraph]], [[MemSearch]], [[ALIVE]], [[@witcheer]]
- Entities touched: [[OpenClaw]]（已存在，新增链接）
- Source page: wiki/sources/ai-memory-tools-two-camps.md
- Notes: overview.md 已有详细摘要（lines 623-626），无需修订；index.md 已有该 source 条目（line 530）；冲突检测：无实质性冲突，仅 wikilink 引用一致；Context-Substrate.md 在此前由其他来源创建，本次补充了完整工具列表和对比表
## [2026-04-28] ingest | Learn AI for free directly from top companies
- Source file: AI/Learn AI for free directly from top companies.md
- Status: ✅ 成功摄入
- Summary: @RodmanAi 整理的顶级AI公司免费学习平台导航——涵盖 Anthropic、Google、Meta、NVIDIA、Microsoft、OpenAI、IBM、AWS、DeepLearning.AI、Hugging Face 共10家头部组织的官方免费课程资源。
- Concepts touched: [[AI免费学习]]（概念引用，概念页面待后续来源积累后创建）
- Entities touched: [[Anthropic]], [[Google]], [[Meta]], [[NVIDIA]], [[Microsoft]], [[OpenAI]], [[IBM]], [[AWS]], [[DeepLearning.AI]], [[Hugging Face]]
- Source page: wiki/sources/learn-ai-for-free-directly-from-top-companies.md
- Notes: overview.md 已添加该来源摘要；index.md 已添加该来源条目；冲突检测：无冲突；Entity 页面暂未创建（各公司实体信息分散在多个来源中，待后续聚合）
## [2026-04-28] ingest | 可自动化、可扩展、AI增强的电商数据采集与处理系统
- Source file: Others/可自动化、可扩展、AI增强的电商数据采集与处理系统.md
- Status: ✅ 成功摄入
- Summary: 基于 Docker + Ubuntu + n8n 的电商数据采集与处理系统完整指南。三层架构：采集层（Scrapy/Playwright）→ AI处理层（n8n + LLM API）→ 存储展示层（PostgreSQL/MinIO + Grafana）。核心价值：Scrapy + Playwright 组合抓取动态页面，n8n 自动化工作流编排，Ollama 本地 LLM 替代外部 API，防封策略（UA轮换/代理池/延迟随机化）。
- Concepts created: [[网页爬虫]], [[自动化工作流引擎]], [[防封技术]], [[Docker容器化]], [[LLM API集成]], [[向量数据库]]
- Entities created: [[Scrapy]], [[Playwright]], [[Ollama]], [[MinIO]], [[Grafana]]
- Entities touched: [[n8n]]（已更新来源链接）
- Source page: wiki/sources/可自动化-可扩展-ai增强的电商数据采集与处理系统.md
- Notes: source page 新建完成；index.md Entities 节已添加 Scrapy；overview.md 已有对应条目（电商数据采集与处理系统节），无需修订；冲突检测：与 [[Scrapy + Playwright 抓取TikTok Shop Data]] 属技术实现互补关系，无冲突
## [2026-04-28] ingest | 电商如何选品 - 如何找到爆款选品策略
- Source file: 跨境电商/电商如何选品 如何找到爆款 选品策略.md
- Status: ✅ 成功摄入
## [2026-05-15] ingest | Design Whimsy Injector
- Source file: Agent/agency-agents/design/design-whimsy-injector.md
- Status: ✅ 成功摄入
- Summary: Whimsy Injector Agent 角色定义——品牌个性和愉悦感注入专家，隶属于 The Agency Design 部门。核心能力：战略人格注入、包容性愉悦设计、微交互设计系统（含 CSS 动画规范）、游戏化成就系统（含彩蛋发现）。Source page 已在 2026-05-05 生成，本次完成 Entity/Concept 页面创建和 index.md 补充。
- Source page: wiki/sources/design-whimsy-injector.md（已存在，格式完整）
- Entities created: Whimsy-Injector.md、ArchitectUX.md、LuxuryDeveloper.md
- Entities updated: The-Agency.md（追加 sources 引用）
- Concepts created: Micro-Interaction-Design.md、Inclusive-Delight-Design.md、Gamification-System.md
- Concepts updated: Gamification.md（追加 sources 引用）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：source page 已存在（2026-05-05），格式完整无需修订；步骤4完成：index.md 第512行更新日期前缀和中文摘要；步骤5完成：overview.md 无需修订（source page 已包含完整摘要）；步骤6完成：新建 Whimsy-Injector.md/ArchitectUX.md/LuxuryDeveloper.md Entity 页面，更新 The-Agency.md sources 引用；步骤7完成：新建 Micro-Interaction-Design.md/Inclusive-Delight-Design.md/Gamification-System.md Concept 页面，更新 Gamification.md sources 引用；更新 index.md Entities 节（ArchitectUX/LuxuryDeveloper/Whimsy-Injector）和 Concepts 节（Inclusive-Delight-Design/Gamification-System/Micro-Interaction-Design）；步骤8完成：无冲突（与 ArchitectUX 的互补关系已在 Contradictions 节记录）；步骤9完成：log.md 追加记录
## [2026-05-15] ingest | UX Researcher Agent Personality
- Source file: Agent/agency-agents/design/design-ux-researcher.md
- Status: ✅ 成功摄入
- Summary: The Agency Design 部门 UX Researcher Agent 的角色定义与研究方法论——核心职责：通过混合研究方法（定性与定量）理解用户行为、验证设计决策、提供可落地洞察；与 UX Architect 和 Whimsy Injector 共同构成 Design 部门三支柱（Research → Architecture → Delight）；默认要求包含无障碍研究和包容性设计测试
- Source page: wiki/sources/design-ux-researcher.md（新建）
- Entities updated: UX-Researcher.md（追加 design-ux-researcher.md 到 sources，更新 definition 和 Key Collaborators）、ArchitectUX.md（追加 sources 引用，更新 Relationship to Other Agents）
- Concepts created: User-Research-Methodology.md、Usability-Testing.md、User-Persona.md、User-Journey-Mapping.md、Qualitative-Quantitative-Research.md、Research-Triangulation.md、Inclusive-Design-Research.md、Behavioral-Analytics.md
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第9行添加新条目（UX Researcher）；步骤5完成：overview.md 在 design-ux-architect 段落后新增 UX Researcher 综合摘要（Design 三支柱定位）；步骤6完成：UX-Researcher Entity 页面已存在，更新 definition/Key Collaborators/sources；ArchitectUX Entity 页面已存在，更新 sources 引用和 Relationship；步骤7完成：新建8个 Concept 页面（User-Research-Methodology/Usability-Testing/User-Persona/User-Journey-Mapping/Qualitative-Quantitative-Research/Research-Triangulation/Inclusive-Design-Research/Behavioral-Analytics），按字母顺序加入 index.md Concepts 节；步骤8完成：Contradictions 记录与 UX Architect 的张力（研究洞察 vs 技术约束，通过时序分工协调）；步骤9完成：log.md 追加记录
## [2026-05-29] 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 平台；支持 Deal ID、PMP、程序化保证交易；通过 MCP 工具与 Google Ads API 集成实现自动化投放管理；管理 25+ 合作伙伴媒体（AMP）；核心理念：受众优先，每次展示触达正确用户在正确上下文以正确频次；成功衡量以可见性（≥70% MRC）、品牌安全和上漏斗归因为主
- Source page: wiki/sources/paid-media-programmatic-buyer.md（更新，日期更新为 2026-04-26，新增 CTV/OTT Advertising 概念，更新 paid-media-ppc-strategist 协调关系）
- Concepts created: Programmatic-Buying.md、ABM-Display.md、Viewability.md、Frequency-Cap.md、CTV-OTT-Advertising.md
- Entities updated: 无（DV360/The Trade Desk/Amazon DSP/Google Display Network/Demandbase/6Sense/RollWorks 等引用未达≥2次阈值）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（已有条目）和 overview.md（第184行已有摘要）；步骤3完成：更新 source page（新增 CTV/OTT Advertising 概念，更新 paid-media-ppc-strategist 协调方式，更新 date 为 2026-04-26）；步骤4完成：index.md 第415行已有条目，无需更新；步骤5完成：overview.md 第184行摘要已准确，无需修订；步骤6完成：Entity 未创建（相关平台实体引用未达≥2次阈值）；步骤7完成：新建5个 Concept 页面（Programmatic-Buying/ABM-Display/Viewability/Frequency-Cap/CTV-OTT-Advertising），按字母顺序加入 index.md Concepts 节；步骤8完成：检测无新冲突（与 paid-media-paid-social-strategist 效果衡量差异、paid-media-ppc-strategist 目标设定差异均已在 source page 记录）；步骤9完成：log.md 追加记录
## [2026-05-01] ingest | Paid Media PPC Campaign Strategist Agent
- Source file: Agent/agency-agents/paid-media/paid-media-ppc-strategist.md
- Status: ✅ 成功摄入
- Summary: The Agency Paid Media 部门企业级 PPC 战略 Agent——核心：$10K 到 $10M+ 月预算规模的 Google Ads/Microsoft Advertising/Amazon Ads 付费搜索架构；核心理念「账户架构即战略」（Account Structure as Strategy）；核心能力：分层广告系列架构（Brand/Non-Brand/Competitor/Conquest 四层隔离）、自动化竞价（tCPA/tROAS/Max Conversions）、Performance Max 资产组设计、Google Ads API/MCP 实时数据驱动；作者：John Williams（@itallstartedwithaidea）
- Source page: wiki/sources/paid-media-ppc-strategist.md（更新）
- Concepts created: AccountArchitecture.md、AutomatedBiddingStrategy.md、BudgetPacing.md、PerformanceMax.md、AudienceStrategy.md、TieredCampaignArchitecture.md、CrossPlatformPlanning.md；Incrementality-Testing.md（追加来源）
- Entities created: CustomerMatch.md、GoogleAdsAPI.md、MCCLevelStrategy.md；GoogleAds.md/MicrosoftAdvertising.md/AmazonAds.md（覆盖并扩充）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（含现有 Sources/Concepts/Entities 索引）和 overview.md（第182行已有该来源详细摘要）；步骤3完成：更新 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第416行更新日期为 2026-05-01；步骤5完成：overview.md 第182行已有摘要，无需修订；步骤6完成：新建6个 Entity 页面（GoogleAds/MicrosoftAdvertising/AmazonAds/CustomerMatch/GoogleAdsAPI/MCCLevelStrategy），GoogleAds/AmazonAds/MicrosoftAdvertising 已存在于 index（保留现有路径），新增条目均已加入 index.md Entities 节；步骤7完成：新建8个 Concept 页面（AccountArchitecture/AutomatedBiddingStrategy/BudgetPacing/PerformanceMax/AudienceStrategy/TieredCampaignArchitecture/IncrementalityTesting/CrossPlatformPlanning），其中 AccountArchitecture/PerformanceMax/TieredCampaignArchitecture 已存在于 index（覆盖扩充），Incrementality-Testing（连字符版）追加来源；新增条目均已加入 index.md Concepts 节；步骤8完成：检测与 MarketingSEOSpecialist 的潜在冲突（SEO vs PPC 预算竞争），已记录协调建议；步骤9完成：log.md 追加记录
## [2026-05-17] ingest | Paid Media Ad Creative Strategist Agent
- Source file: Agent/agency-agents/paid-media/paid-media-creative-strategist.md
- Status: ✅ 成功摄入
- Summary: 付费媒体广告创意策略 Agent——将广告创意从"凭感觉"转变为"可重复的科学"；核心理念：创意是自动化竞价环境中广告主唯一真正可控的变量；15-headline RSA 架构设计、Meta Hook-Body-CTA 视频框架、Performance Max 资产组编排、创意疲劳监测（A/B 测试 + 统计显著性）；成功指标：90%+ Ad Strength、15-25% CTR 提升、每两周新测试节奏；作者：John Williams（@itallstartedwithaidea）
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page）
- Source page: wiki/sources/paid-media-creative-strategist.md（新建）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（第403行已有该条目）和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第403行已有该条目，日期已存在，无需更新；步骤5完成：overview.md 无需修订（Sales 相关内容已在相关页面覆盖）；步骤6完成：Entity 未创建（Key Entities 均以 wikilinks 记录于 source page）；步骤7完成：新建4个 Concept 页面（Win-Theme.md / Three-Act-Proposal-Narrative.md / Executive-Summary-Formula.md / Content-Operations.md），均已加入 index.md Concepts 节；步骤8完成：检测与 support-executive-summary-generator 的 SCQA 框架张力（前者通用战略沟通，后者销售提案专用），已记录为层级互补非冲突；步骤9完成：log.md 追加记录
## [2026-05-19] ingest | Sales Proposal Strategist Agent
- Source file: Agent/agency-agents/sales/sales-proposal-strategist.md
- Status: ✅ 成功摄入
- Summary: 销售提案撰写策略专家 Agent，将 RFP 响应转化为"赢叙事"（Win Narrative）。核心理念：提案是说服工具而非合规清单，叙事是最强差异化因素。三幕式提案叙事结构（Act I 理解挑战 → Act II 方案旅程 → Act III 转化状态）、3-5 个赢主题矩阵（Win Theme Matrix）、执行摘要五步结构、竞争定位技巧、内容运营体系。
- Concepts created: Win-Theme.md、Three-Act-Proposal-Narrative.md、Executive-Summary-Formula.md、Content-Operations.md
- Source page: wiki/sources/sales-proposal-strategist.md（新建）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md（第403行已有该条目）和 overview.md；步骤3完成：新建 source page（含 frontmatter、Summary、Key Claims、Key Quotes、Key Concepts、Key Entities、Connections、Contradictions 八节）；步骤4完成：index.md 第403行已有该条目，日期已存在，无需更新；步骤5完成：overview.md 无需修订（Sales 相关内容已在相关页面覆盖）；步骤6完成：Entity 未创建（Key Entities 均以 wikilinks 记录于 source page）；步骤7完成：新建4个 Concept 页面（Win-Theme.md / Three-Act-Proposal-Narrative.md / Executive-Summary-Formula.md / Content-Operations.md），均已加入 index.md Concepts 节；步骤8完成：检测与 support-executive-summary-generator 的 SCQA 框架张力（前者通用战略沟通，后者销售提案专用），已记录为层级互补非冲突；步骤9完成：log.md 追加记录
## [2026-05-29] 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 完整摄取——The Agency 项目管理部门的交付纪律守护者 Agent，专注于 Jira-Git 全链路可追溯性管理。核心方法：Jira Gate（强制 Jira ID 前置）→ 分支策略（feature/bugfix/hotfix/release 分流）→ Gitmoji 规范提交 → PR 模板 → Commit Hook 自动化验证。关键交付物：分支/提交决策矩阵（8种变更类型）、Commit Validation Hook 脚本、PR 模板、Delivery Planning 模板。成功指标：100% 分支映射 Jira 任务、提交合规率 ≥ 98%、从 Jira+Git 历史重建发布说明 < 10 分钟。与 [[Project-Management-Project-Shepherd]] 互补（任务创建→任务追踪），与 [[Project-Management-Studio-Operations]] 协同（运营流程→技术交付链路），与 [[ProjectManagerSenior]] 协同（任务列表→可追溯交付）。
- Concepts created: （所有 Concept 均已存在于 wiki：Jira-Git-Traceability/Atomic-Commit/Branch-Strategy/Gitmoji-Commit/Jira-Gate/Pull-Request-Governance/Delivery-Traceability）
- Source page: wiki/sources/project-management-jira-workflow-steward.md
- Notes: 步骤1完成：读取原始文档（230行）；步骤2完成：读取 index.md、overview.md；步骤3完成：source page 已存在（wiki/sources/project-management-jira-workflow-steward.md，含完整 frontmatter/Summary/Key Claims/Key Quotes/Key Concepts/Key Entities/Connections/Contradictions 八节）；步骤4完成：index.md 第413行已有条目（[Jira Workflow Steward Agent Personality](sources/project-management-jira-workflow-steward.md)）；步骤5完成：overview.md 第148-149行已有 Project-Management-Jira-Workflow-Steward 综合摘要，与 source page 内容一致无需修订；步骤6完成：Entity 页面已存在（wiki/entities/Jira-Workflow-Steward.md），Gitmoji/Jira 实体已有独立页面；步骤7完成：7个 Concept 页面均已存在（wiki/concepts/ 目录下：Jira-Git-Traceability.md/Atomic-Commit.md/Jira-Gate.md/Gitmoji-Commit.md）；步骤8完成：Contradictions 已记录于 source page 第53-63行（与 Project-Management-Project-Shepherd 的 Jira ID 前置机制张力、与 Project-Management-Studio-Producer 的交付粒度层级差异）；步骤9完成：log.md 追加记录
## [2026-05-18] ingest | Pipeline Analyst Agent
- Source file: Agent/agency-agents/sales/sales-pipeline-analyst.md
- Status: ✅ 成功摄入（更新）
- Summary: Pipeline Analyst Agent 文档更新——补充 Contradictions 节（与 sales-deal-strategist 和 sales-coach 的 MEDDPICC 应用视角张力与协调方案）、新增 Key Quotes（精确诊断示例）、扩充 Key Claims（预测准确性指标、销售辅导效果数据）、新增 Key Concepts（ForecastAccuracy/LeadIndicator/SalesCycleLength）、丰富 Key Entities（补充 SalesCoach 角色描述）、补充 Connections 细节说明。Source page date 更新至 2026-05-18。
- Concepts created: （未创建独立 Concept 页面，Key Concepts 均以 wikilinks 形式记录于 source page：PipelineVelocity/MEDDPICC/DealHealthScoring/QualityAdjustedCoverage/RevenueOperations/ForecastAccuracy/LeadIndicator/SalesCycleLength）
- Source page: wiki/sources/sales-pipeline-analyst.md（更新：date 2026-05-18，补充 Contradictions 节、扩充 Key Claims/Key Quotes/Key Concepts/Key Entities/Connections）
- Notes: 步骤1完成：读取原始文档；步骤2完成：读取 index.md 和 overview.md（overview.md 第915行已有完整 sales-pipeline-analyst 综合摘要）；步骤3完成：更新 source page（日期更新+内容扩充：Key Claims扩充3条/Key Quotes扩充1条/Key Concepts扩充3个/Key Entities扩充SalesCoach描述/Connections补充细节/新增Contradictions节）；步骤4完成：index.md 第407行补全日期（2026-05-18）和一行摘要；步骤5完成：overview.md 第915行已有完整综合摘要，内容一致无需修订；步骤6完成：Entity 未创建独立页面（Key Entities 均以 wikilinks 记录于 source page）；步骤7完成：Concept 均以 wikilinks 形式记录于 source page，未达到独立建页阈值；步骤8完成：检测并记录两个 Contradictions（与 sales-deal-strategist 的 MEDDPICC 诊断vs战略张力，与 sales-coach 的 Deal评估vs代表能力评估张力）；步骤9完成：log.md 追加记录