Auto-sync: 2026-04-22 19:20

wiki/concepts/Agent-Build-Gate.md

@@ -0,0 +1,53 @@
+---
+title: "Agent-Build-Gate"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Overview
+Agent 执行构建任务前的条件检查机制——只有通过门控条件的 Agent 才允许进入实际代码编写阶段。通过在 Agent 的 instructions 中嵌入 pre-gate 规则实现自动化门控，是 [[Pre-Build Validation]] 的技术实现机制。
+
+## Implementation Pattern
+在 [[OpenClaw]] Agent 的 instructions 中嵌入规则：
+
+```text
+Before starting any new project, feature, or tool, always run idea_check first.
+
+Rules:
+- If reality_signal > 70: STOP. Report top 3 competitors.
+  Ask me if I want to proceed, pivot, or abandon.
+- If reality_signal 30-70: Show me results and pivot_hints.
+  Suggest a niche angle that existing projects don't cover.
+- If reality_signal < 30: Proceed to build.
+  Mention that the space is open.
+- Always show the reality_signal score and top competitors before writing any code.
+```
+
+## How It Works
+1. 用户向 Agent 发送构建指令（如"build me a CLI tool for AI code review"）
+2. Agent 自动调用 `idea_check()` 工具（而非立即开始写代码）
+3. 获取 `reality_signal` 和竞品信息
+4. 根据阈值执行对应规则（STOP / 展示建议 / 直接构建）
+5. 只有在 `reality_signal < 30` 或用户明确授权的情况下，Agent 才进入代码编写阶段
+
+## Relationship to Related Concepts
+- [[Pre-Build Validation]] ← Agent-Build-Gate 是其技术实现
+- [[idea-reality-mcp]] ← 提供 `idea_check()` 工具
+- [[Reality-Signal]] ← Gate 的判断依据
+- [[Pivot-Strategy]] ← Gate 触发 STOP 时的后续建议
+- [[OpenClaw]] ← 当前唯一支持此模式的 Agent 框架
+
+## Advantages over Manual Gate
+- **自动化**：无需人工触发，Agent 自动执行检查
+- **强制化**：Agent 指令层面嵌入，无法绕过（除非修改 instructions）
+- **上下文保持**：检查结果和 Agent 对话上下文共存，无需额外工具切换
+- **持续生效**：每次新的构建指令都会自动触发，无需重复提醒
+
+## Related
+- [[Pre-Build Validation]]
+- [[idea-reality-mcp]]
+- [[Reality-Signal]]
+- [[Pivot-Strategy]]
+- [[OpenClaw]]
+- [[Competition-Analysis]]

wiki/concepts/Agent-Driven-Market-Research.md

@@ -0,0 +1,38 @@
+---
+title: "Agent-Driven Market Research"
+type: concept
+tags: [market-research, agentic-ai, automation]
+sources: [market-research-product-factory]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+Agent-Driven Market Research（Agent 驱动的市场调研）是指利用 AI Agent 自动采集、整理和分析市场信息的方法，替代传统人工搜索、浏览和归纳的市场调研模式。
+
+## Core Mechanism
+
+- **自动化数据采集**：AI Agent 主动从 Reddit、X、论坛等平台抓取用户讨论
+- **结构化信息提取**：从非结构化文本中提取痛点、功能请求、竞品评价等关键信息
+- **趋势分析**：按时间窗口（近7天/30天/90天）聚合分析，识别新兴趋势
+- **多源交叉验证**：综合多个来源确保洞察的可靠性和代表性
+
+## Contrast with Traditional Methods
+
+| 维度 | 传统市场调研 | Agent-Driven Market Research |
+|------|-------------|----------------------------|
+| 数据来源 | 问卷/访谈/一手报告 | Reddit/X/论坛/评论 |
+| 数据真实性 | 经过受访者过滤和美化的二手信息 | 用户原生表达，未加工的真实情绪 |
+| 时效性 | 调研周期长，数据可能滞后 | 近实时采集，可聚焦特定时间窗口 |
+| 成本 | 专业调研公司费用高 | AI Agent 自动化，成本极低 |
+| 规模 | 样本量受限 | 可覆盖数十万条讨论帖子 |
+
+## Relationship to Other Concepts
+
+- [[Agent-Driven Market Research]] → 输出 → [[Pain Point Mining]] → 支撑 → [[Startup MVP Pipeline]]
+- [[Agentic AI]] → 技术基础 → [[Agent-Driven Market Research]]
+- [[Last 30 Days Method]] → 工具方法 → [[Agent-Driven Market Research]]
+
+## Sources
+
+- [[market-research-product-factory]]

wiki/concepts/Agent-Personality.md

@@ -0,0 +1,44 @@
+---
+title: "Agent Personality"
+type: concept
+tags: [OpenClaw, Agent, Design, UX]
+sources: [multi-agent-team]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+**Agent Personality** 是给 AI Agent 赋予独特的名字、性格设定和沟通风格的设计实践，使其与用户协作时更加自然，而非像一个通用 AI 工具。
+
+## 核心洞察
+
+> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to 'talk to your team' rather than wrestle with a generic AI"
+
+赋予 Agent 个性比想象中更重要：
+- **降低协作摩擦**：用户自然地"与团队对话"，而非使用工具
+- **明确的职责边界**：名字和人格暗示了 Agent 的专长
+- **增强信任感**：有个性的 Agent 更容易建立情感连接
+
+## 设计要素
+
+- **Name（名字）**：简短、独特，如 Milo、Josh、Dev
+- **性格描述**：用叙事性语言定义 Agent 的行事风格
+  - Milo: "Confident, big-picture, charismatic"（策略领导型）
+  - Josh: "Pragmatic, straight to the point, numbers-driven"（商业分析型）
+  - Dev: "Precise, thorough, security-conscious"（开发严谨型）
+- **沟通风格**：决定 Agent 如何呈现信息和建议
+
+## 与 Agent Specialization 的关系
+
+Agent Personality 配合 Agent Specialization 共同作用：
+- **Personality** 解决"如何沟通"的问题
+- **Specialization** 解决"做什么任务"的问题
+- 两者结合让 Agent 更像一个真实的团队成员
+
+## Related Concepts
+
+- [[Agent Specialization]] — Agent 的专业分工
+- [[OpenClaw]] — SOUL.md 是 Agent Personality 的配置文件
+- [[Agent-Memory]] — 个性配合长期记忆增强 Agent 连续性
+- [[Chained Agents]] — 链式 Agent 中的角色设计
+

wiki/concepts/Agent-Specialization.md

@@ -0,0 +1,55 @@
+---
+title: "Agent Specialization"
+type: concept
+tags: [OpenClaw, Agent, Architecture, Team]
+sources: [multi-agent-team]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+**Agent Specialization** 是多 Agent 系统中，每个 Agent 拥有独立角色、专长领域和针对性优化的模型，通过协作完成复杂任务的架构设计原则。
+
+## 核心洞察
+
+> "One agent can't do everything well: A single agent's context window fills up fast when juggling strategy, code, marketing research, and business analysis"
+
+核心问题：
+- **上下文窗口瓶颈**：单个 Agent 同时处理多领域任务时上下文快速填满
+- **泛化输出的局限**：通用提示产生通用输出，专业任务需要专业 Agent
+- **效率不均衡**：不同任务需要的模型能力不同，混用造成资源浪费
+
+## 专业化 Agent 示例
+
+| Agent | 角色 | 模型选择 | 核心职责 |
+|-------|------|----------|----------|
+| Milo | 策略领导 | Claude Opus | 战略规划、OKR 追踪、Agent 协调 |
+| Josh | 商业分析 | Claude Sonnet | 定价策略、KPI 追踪、竞品分析 |
+| Marketing | 营销研究 | Gemini | 内容创意、SEO 研究、社媒监控 |
+| Dev | 开发工程 | Claude Opus/Codex | 代码审查、架构决策、文档撰写 |
+
+## 模型匹配原则
+
+> "Right model for the right job: Don't use an expensive reasoning model for keyword monitoring"
+
+- **复杂推理任务**：Claude Opus（深度思考、架构设计）
+- **分析性任务**：Claude Sonnet（快速分析、数据处理）
+- **研究性任务**：Gemini（长上下文、网页研究）
+- **执行性任务**：Codex（代码生成、工具调用）
+
+## 起步策略
+
+> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks"
+
+从最小可行团队开始：
+1. **1 个领导 Agent**：总协调、决策、汇总
+2. **1 个专家 Agent**：根据当前最大瓶颈选择
+3. **逐步扩展**：瓶颈出现时添加新 Agent
+
+## Related Concepts
+
+- [[Agent Personality]] — Agent 个性化与专业化相辅相成
+- [[Multi-Agent Coordination]] — 多 Agent 协调机制
+- [[Parallel Agent Execution]] — 并行执行提升效率
+- [[Chained Agents]] — 链式 Agent（另一种协作模式）
+

wiki/concepts/Ai-Powered-Digest.md

@@ -0,0 +1,29 @@
+---
+title: "AI-Powered Digest"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Definition
+AI-Powered Digest（AI 驱动的自动化摘要）是一种由 AI Agent 主导的信息获取-整理-格式化-投递模式。核心特征：定时/事件触发 → 自动抓取原始数据 → AI 理解与结构化 → 投递到即时通讯工具 → 用户无需主动搜索。
+
+## Pattern Components
+1. **Trigger**：定时（Cron Job）或事件驱动
+2. **Collection**：通过 API/Web 搜索/爬虫获取原始数据
+3. **Processing**：AI 理解内容，提取关键信息
+4. **Formatting**：结构化摘要（分类、排序、highlight）
+5. **Delivery**：推送至 Telegram/Slack/Email 等即时渠道
+
+## Variants in the Wiki
+| 场景 | 来源 | Trigger | 内容源 |
+|------|------|---------|--------|
+| 财报追踪 | [[earnings-tracker]] | Cron Job（周日扫描+财报发布后触发） | 财报日历+搜索结果 |
+| YouTube 摘要 | [[daily-youtube-digest]] | Cron Job（频道更新检测） | 视频转录+摘要 |
+| 晨报 | [[self-healing-home-server]] | Cron Job（每日 8AM） | 天气/日历/系统状态 |
+
+## Related Concepts
+- [[Cron Job]] — 定时触发的技术基础
+- [[Telegram Topic]] — 投递渠道
+- [[Daily-Digest]] — Digest 模式在 YouTube 场景的具体化
+- [[Earnings Calendar]] — Digest 模式的金融场景应用

wiki/concepts/Automated-Health-Logging.md

@@ -0,0 +1,37 @@
+---
+title: "Automated Health Logging"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-22
+---
+
+# Automated Health Logging
+
+利用 AI 自动解析自然语言输入并写入结构化健康数据日志的实践方法。
+
+## Definition
+通过自然语言接口（消息、语音、文本）收集健康数据，由 AI 自动解析提取关键实体（食物、症状、药物等）并写入结构化日志文件，减少人工录入负担。
+
+## Key Components
+1. **自然语言输入**：用户以日常语言描述，无需记忆特定格式
+2. **AI 解析引擎**：提取食物名称、数量、时间、症状描述等关键信息
+3. **结构化存储**：写入 Markdown/JSON 等可读且易处理的日志文件
+4. **定时提醒**：Cron Job 驱动的一日多次提醒，确保数据完整性
+
+## Comparison with Manual Logging
+
+| 维度 | 手动记录 | 自动化日志 |
+|------|---------|-----------|
+| 门槛 | 需要记忆格式 | 任意自然语言 |
+| 一致性 | 易遗漏 | 提醒驱动 |
+| 可分析性 | 依赖用户格式化 | AI 标准化 |
+| 维护成本 | 高 | 低 |
+
+## Implementation
+- [[health-symptom-tracker]]：Telegram topic → OpenClaw Agent → Markdown 日志文件
+- [[habit-tracker-accountability-coach]]：类似的自动化记录模式
+
+## Connections
+- [[Food Sensitivity Tracking]] ← enabled_by ← [[Automated Health Logging]]
+- [[OpenClaw]] ← powers ← [[Automated Health Logging]]

wiki/concepts/CEOPattern.md

@@ -0,0 +1,32 @@
+---
+title: "CEO Pattern"
+type: concept
+tags: [multi-agent, architecture, orchestration]
+sources: [autonomous-project-management]
+last_updated: 2026-04-22
+---
+
+## 定义
+主 Agent 仅负责策略决策（strategy only），所有执行操作下沉至子 Agent 的极简主控模式。其名称来源于"CEO 只做战略，不管执行"的企业管理隐喻。
+
+## 核心原则
+- **主会话越薄越好**：0-2 步工具调用，响应速度与主会话的"薄度"成正比
+- **只做决策**：任务分配、优先级调整、结果汇总
+- **不做事**：不直接执行工具调用，不处理具体业务逻辑
+- **所有执行下沉**：子 Agent 自主工作，主会话只负责协调
+
+## 关键洞察
+> "The less the main agent does, the faster it responds."
+
+主会话的功能越少，其响应速度越快——这是去中心化协调架构的性能保障。
+
+## 实现方式
+通过 [[PM Delegation Pattern]]，每个子 Agent 被赋予特定范围的任务，独立完成，主会话不干预具体执行过程。
+
+## 与传统 Orchestrator 模式的区别
+| 维度 | Orchestrator 模式 | CEO 模式 |
+|------|-------------------|---------|
+| 主 Agent 角色 | 交通指挥员（所有调用必经） | CEO（仅决策） |
+| 并行能力 | 受限（中心瓶颈） | 强（完全并行） |
+| 响应速度 | 随任务数线性下降 | 稳定（子 Agent 异步执行） |
+| 扩展性 | O(n) 瓶颈 | O(1) 主会话成本 |

wiki/concepts/Competition-Analysis.md

@@ -0,0 +1,54 @@
+---
+title: "Competition-Analysis"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Overview
+在项目启动前，通过多平台（GitHub/npm/PyPI/Hacker News/Product Hunt）扫描竞品的存在性、成熟度和市场关注度的分析过程。是 [[Pre-Build Validation]] 的核心组成部分，帮助 AI Agent 和创业者判断赛道的真实竞争状态。
+
+## 5 Data Sources
+| 平台 | 评估维度 | 代表性指标 |
+|---|---|---|
+| GitHub | 仓库数量、Star 总数、贡献者活跃度 | Top 竞品 star counts |
+| npm | Node.js 包数量、下载量趋势 | 包生态成熟度 |
+| PyPI | Python 包数量、pip 安装量 | Python 领域成熟度 |
+| Hacker News | 讨论帖数量、帖子分数 | 技术社区关注度 |
+| Product Hunt | 早期产品数量、Upvote 数 | 市场需求验证 |
+
+## Process
+1. 输入：项目想法描述
+2. 扫描：5 个平台并行查询
+3. 聚合：综合评分（[[Reality-Signal]]）
+4. 输出：竞品列表 + 评分 + 转向建议
+
+## Output Example
+```
+reality_signal: 90/100 (very high)
+
+Top competitors:
+1. Gitea — 53,940 stars
+2. reviewdog — 9,104 stars
+3. Danger (Ruby) — 5,649 stars
+
+This space has 143,000+ related repos.
+
+Pivot suggestions:
+- Focus on a specific language (Rust/Go-only)
+- Target a specific framework (React/Vue component review)
+- Target a specific industry (financial/medical compliance)
+```
+
+## Relationship to Related Concepts
+- [[Pre-Build Validation]] ← 核心组成部分
+- [[Reality-Signal]] ← 输出指标
+- [[Pivot-Strategy]] ← 拥挤赛道的后续行动
+- [[idea-reality-mcp]] ← 技术实现工具
+
+## Related
+- [[Pre-Build Validation]]
+- [[Reality-Signal]]
+- [[Pivot-Strategy]]
+- [[idea-reality-mcp]]
+- [[Startup MVP Pipeline]]

wiki/concepts/DNS托管.md

@@ -64,5 +64,5 @@ Cloudflare 是全球知名的 CDN 和 DNS 服务提供商，提供免费的 DNS
 - [[Cloudflare]] — DNS 托管服务商
 - [[RackNerd]] — VPS 公网 IP（DNS A 记录指向）
 - [[Caddy]] — 自动 HTTPS + 反向代理
-- [[FRP]] — 内网穿透隧道
+- [[frp]] — 内网穿透隧道
 - [[阿里云 DNS]] — 国内 DNS 替代方案

wiki/concepts/Defense-in-Depth.md

@@ -0,0 +1,42 @@
+---
+title: "Defense-in-Depth"
+type: concept
+tags: [security, devsecops, ai-agents, risk-management]
+date: 2026-04-22
+---
+
+## Definition
+Defense-in-Depth（纵深防御）是一种信息安全策略：通过叠加多层独立的安全控制措施，确保任何单一安全措施的失效不会导致系统完全沦陷。每层防线相互补足，即使攻击者突破一层，仍面临其他层的阻挡。
+
+## In AI Agent Security Context
+在 [[self-healing-home-server]] 中，纵深防御针对 AI Agent 的特殊风险构建（特别是 [[OpenClaw]] 的 [[TruffleHog]] 第1天 API Key 泄露教训）：
+
+### 多层防御架构
+```
+Layer 1: Pre-push hooks (TruffleHog)
+  ↓ 阻止内嵌 secrets 的 commit
+Layer 2: Local-first Git (私有 Gitea)
+  ↓ 所有代码先到私有仓库
+Layer 3: CI Scanning Pipeline
+  ↓ TruffleHog + 依赖漏洞扫描
+Layer 4: Human Review
+  ↓ 必须人工审核 main 分支
+Layer 5: 1Password AI Vault
+  ↓ Agent 只能读取专用 vault 中的凭证
+Layer 6: Network Segmentation
+  ↓ 敏感服务网络隔离
+Layer 7: Daily Security Audit
+  ↓ 每日自动检查特权容器/过度权限
+```
+
+## Key Principle
+> "Never trust a single security control." — 纵深防御的核心哲学
+
+AI Agent 的风险在于它们**缺乏人类的"常识性危险感知"**——Agent 会在代码中直接写入 API Key而不产生"直觉性警告"。因此，安全防线必须设计为即使 Agent 无意识地绕过一层，仍有多层阻止最终损害。
+
+## Connections
+- [[TruffleHog]] — 第1层防线：pre-push secrets 检测
+- [[Local-first Git]] — 第2-3层防线：私有仓库 + CI 扫描
+- [[1Password]] — 第5层防线：凭证安全管理
+- [[OpenClaw]] — 需要纵深防御保护的 Agent 平台
+- [[Agentic AI]] — 纵深防御是对 AI Agent 固有风险的主动应对

wiki/concepts/Earnings-Beat-Miss.md

@@ -0,0 +1,28 @@
+---
+title: "Earnings Beat/Miss"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Definition
+Earnings Beat/Miss 是衡量公司实际财报表现与分析师预期之间差距的指标。Beat（超预期）指实际 EPS/营收等指标高于预期；Miss（低于预期）则相反。是 AI 格式化财报摘要中的核心判断输出。
+
+## Aliases
+- Beat/Miss
+- Earnings Surprise
+- 财报超预期 / 财报低于预期
+
+## Key Metrics
+- **EPS**（Earnings Per Share）：每股收益
+- **Revenue**（营收）：季度/年度总收入
+- **AI Highlights**：AI 相关业务亮点
+- **Guidance**（指引）：管理层对未来业绩的前瞻性预期
+
+## Context
+在 [[Earnings Tracker]] 工作流中，OpenClaw 搜索财报结果后，格式化摘要需包含 beat/miss 判断及上述关键指标，作为 Telegram 投递的核心内容。Beat/Miss 直接影响股价短期走势，是财报读者最关心的结论性信息。
+
+## Related Concepts
+- [[Earnings Calendar]] — 触发时机
+- [[Earnings Tracker]] — 使用此指标的工作流
+- [[AI-Powered Digest]] — 格式化摘要的通用模式

wiki/concepts/Earnings-Calendar.md

@@ -0,0 +1,22 @@
+---
+title: "Earnings Calendar"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Definition
+Earnings Calendar（财报日历）是上市公司财报发布时间表，列出每家公司计划发布季度/年度财务报告的具体日期和时间。AI Agent 自动化追踪系统的输入数据源。
+
+## Aliases
+- Earnings Schedule
+- 财报日历
+- 财报发布日程
+
+## Context
+在 [[Earnings Tracker]] 工作流中，Earnings Calendar 是第一步数据源——OpenClaw Cron Job 每周日扫描日历，过滤用户关注的公司（NVDA/MSFT/GOOGL/META/AMZN/TSLA/AMD 等）后，在 Telegram 投递预览列表，用户确认后启动下一步追踪。
+
+## Related Concepts
+- [[Earnings Beat/Miss]] — 财报结果判断
+- [[Earnings Tracker]] — 使用 Earnings Calendar 的自动化追踪工作流
+- [[Daily-Digest]] — 同属定时信息摘要模式

wiki/concepts/Email-Triage.md

@@ -0,0 +1,29 @@
+---
+title: "Email Triage"
+type: concept
+tags: [automation, productivity, agent, email]
+date: 2026-04-22
+---
+
+## Definition
+Email Triage（邮件分拣）指 AI Agent 自动扫描收件箱、识别待办事项、标记优先级，并归档噪音邮件的自动化流程。类似于医院急诊的分诊（triage）机制——快速评估、将紧急项优先处理、其余归档。
+
+## In Home Lab Context
+在 [[self-healing-home-server]] 中，每小时运行的 Cron Job 自动执行邮件分拣：
+- **标记待办项**：识别需要回复或跟进的邮件，自动添加到任务看板
+- **归档噪音**：Promotional/Newsletters 等噪音邮件自动归档
+- **紧急升级**：包含关键词（"urgent"/"deadline"/"ASAP"）的邮件触发告警
+
+## Tools Used
+- `gog CLI`：OpenClaw Agent 访问 Gmail 的接口
+- Gmail Labels：通过标签系统管理邮件分类
+- IMAP/SMTP：通用邮件访问协议
+
+## Key Insight
+自动化邮件分拣将每日 30-60 分钟的手动邮件处理时间降至接近零，让用户专注于高价值任务。
+
+## Connections
+- [[OpenClaw]] — 通过 gog CLI 访问 Gmail 的 Agent 平台
+- [[Morning Briefing]] — 晨报中包含邮件处理提醒
+- [[TaskAutomation]] — 邮件分拣后自动创建任务
+- [[Cron定时任务]] — 邮件分拣的调度机制（每小时 cron）

wiki/concepts/EventSourcing.md

@@ -0,0 +1,50 @@
+---
+title: "Event Sourcing"
+type: concept
+tags: [architecture, data-modeling, patterns]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+事件溯源（Event Sourcing）是一种软件架构模式——不直接存储数据的当前状态，而是将所有状态变更作为**不可变事件序列**持久化，通过重放事件来重建任意时间点的状态。源自 Martin Fowler 的经典模式。
+
+## Core Principles
+
+1. **唯一真实来源（Single Source of Truth）**：事件日志是唯一真实来源，当前状态由事件推导得出，而非直接存储
+2. **不可变性（Immutability）**：事件一旦写入，永不修改或删除，只能追加新事件
+3. **全历史可追溯（Audit Trail）**：天然具备完整审计日志，可回溯任何历史变更的"为什么"
+4. **时间旅行调试**：任意时刻的状态可精确重建，便于复现 BUG 和分析决策上下文
+
+## Event Sourcing vs Traditional State Storage
+
+| 维度 | 传统状态存储 | 事件溯源 |
+|------|------------|---------|
+| 存储内容 | 当前状态快照 | 状态变更事件序列 |
+| 历史保留 | 通常不保留或有限保留 | 完整保留（无上限）|
+| 变更原因 | 通常不记录 | 完整记录每次变更的原因 |
+| 回滚能力 | 依赖备份 | 通过反向事件补偿天然支持 |
+| 审计合规 | 需额外构建 | 内置，无需额外开发 |
+
+## Key Event Types
+
+- **Progress**：任务向前推进的里程碑事件
+- **Blocker**：阻塞/障碍事件，通常触发状态 → "blocked"
+- **Decision**：关键决策事件，记录决策理由和背景
+- **Pivot**：转向/重大调整事件，记录原因和备选方案
+- **Completion**：完成事件，触发状态 → "completed"
+
+## Applications in Project Management
+
+[[Project State Management]] 是事件溯源在个人/团队项目管理中的具体应用：
+
+- 用自然语言对话替代手动拖拽看板卡片
+- 每句话（"完成了X"/"被Y阻塞"）作为独立事件持久化
+- 当前状态由事件序列自动推导，无需手动维护
+- 查询"项目为什么这样"等同于"重放这个项目的所有事件"
+
+## Connections
+
+- [[Project State Management]] ← uses ← **Event Sourcing**
+- [[Centralized Logging]] ← related_to ← **Event Sourcing**（集中日志可视为事件溯源的一种实现）
+- [[Kanban]] ← alternative_to ← **Event Sourcing**（冲突：可视化协作 vs 自动追踪+上下文保留）

wiki/concepts/Food-Sensitivity-Tracking.md

@@ -0,0 +1,31 @@
+---
+title: "Food Sensitivity Tracking"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-22
+---
+
+# Food Sensitivity Tracking
+
+通过长期日志追踪来识别个人食物不耐受或过敏的实践方法。
+
+## Definition
+记录食物摄入与身体症状（如头痛、腹胀、皮疹等）的时间关联，通过模式分析发现潜在的触发食物。
+
+## How It Works
+1. **日志记录**：在摄入食物或出现症状时即时记录，带时间戳
+2. **一致性保证**：定时提醒确保不遗漏，建立长期数据积累
+3. **周期性分析**：每周或每月回顾日志，识别统计相关性
+4. **迭代验证**：排除疑似触发食物，观察症状变化以确认
+
+## Key Insight
+> "Identifying food sensitivities requires consistent logging over time, which is tedious to maintain." — 这是自动化的核心驱动力
+
+## Implementation Patterns
+- [[health-symptom-tracker]]：Telegram 话题 + OpenClaw 自动解析 + Markdown 日志
+- 移动端 App（如 Cara、Spoonful）作为专用替代方案
+
+## Connections
+- [[Automated Health Logging]] ← enables ← [[Food Sensitivity Tracking]]
+- [[Cron Job Reminders]] ← supports ← [[Food Sensitivity Tracking]]

wiki/concepts/Full-Draft-Generation.md

@@ -0,0 +1,50 @@
+---
+title: "Full Draft Generation"
+type: concept
+tags: [openclaw, productivity, content-automation]
+sources: [custom-morning-brief]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+完整草稿生成（Full Draft Generation）是一种 AI 内容创作范式——AI 不是仅提供标题或概要，而是生成可直接使用的完整内容成品（脚本、邮件、商业方案等），用户醒来后无需再从零开始。
+
+## Why "Full Draft" Matters
+
+传统 AI 助手通常生成：
+- ❌ 标题列表（"5 个标题供选择"）
+- ❌ 概要要点（"要点如下：..."）
+- ❌ 半成品框架（"你可以这样写..."）
+
+Full Draft 模式生成：
+- ✅ 完整脚本/大纲 → 拿来就用
+- ✅ 完整邮件正文 → 直接发送
+- ✅ 完整商业方案 → 提交即用
+
+## Key Insight
+
+> "Full drafts (not just ideas) are the key to saving time. Wake up to scripts, not suggestions." — 自定义晨间简报的核心差异化价值
+
+## Typical Workflow
+
+1. **睡前**：用户通过 Telegram 发送创作需求
+2. **夜间**：OpenClaw 在后台生成完整内容
+3. **晨起**：用户收到可直接使用的成品
+
+## Use Cases
+
+- **[[custom-morning-brief]]**：睡前生成完整演讲脚本/视频大纲/邮件草稿
+- **[[podcast-production-pipeline]]**：生成播客脚本和社媒推广包
+
+## Trade-off
+
+Full Draft 比概要生成：
+- **优势**：节省用户时间，交付物价值更高
+- **劣势**：计算成本更高，生成时间更长
+- **适合**：高频、固定格式、有明确使用场景的内容
+
+## Related Concepts
+
+- [[Scheduled Task Flywheel]] — Full Draft 生成的时间调度机制
+- [[Proactive Agent Recommendation]] — Full Draft 作为主动推荐的具体输出形式

wiki/concepts/GitAsAuditLog.md

@@ -0,0 +1,35 @@
+---
+title: "Git-as-Audit-Log"
+type: concept
+tags: [version-control, git, audit, multi-agent]
+sources: [autonomous-project-management]
+last_updated: 2026-04-22
+---
+
+## 定义
+将所有状态变更（包括 [[Shared State Coordination]] 中的 STATE.yaml 变更）作为 Git 提交处理，从而获得完整可追溯的决策和执行历史的方法。
+
+## 核心实践
+每次对 STATE.yaml 的修改都触发一个 Git 提交：
+```bash
+# 状态更新后
+git add STATE.yaml
+git commit -m "task(id=xxx): updated status from in_progress to done"
+```
+
+## 价值
+1. **完整历史追溯**：任意时刻可回滚到任何历史状态
+2. **决策上下文保留**：每次变更的 commit message 即变更理由的记录
+3. **团队协作基础**：多成员可查看、review 状态变更历史
+4. **自动化 CI/CD 集成**：可基于 Git 状态变更触发后续流程
+
+## 在 [[autonomous-project-management]] 中的角色
+- 规则明确：All state changes committed to git
+- 每个 PM 子 Agent 负责自己 STATE.yaml 的 Git 提交
+- 结合 [[Git-as-Audit-Log]] 和 [[Shared State Coordination]]，实现自文档化的项目协调
+
+## Commit Message 约定
+建议格式：`[type](task_id): description`
+- `type`: started / updated / completed / blocked / unblocked
+- `task_id`: 对应 STATE.yaml 中的任务 ID
+- `description`: 变更的具体内容

wiki/concepts/HTTPS自动化证书.md

@@ -74,4 +74,4 @@ Caddy 是用 Go 语言编写的现代化 Web 服务器，其核心特性之一
 - [[Caddy]] — 自动 HTTPS 实现者
 - [[RackNerd]] — Caddy 运行环境
 - [[Cloudflare]] — DNS 服务提供商，支持 DNS-01 挑战
-- [[FRP]] — 内网服务的传输通道
+- [[frp]] — 内网服务的传输通道

wiki/concepts/Last-30-Days-Method.md

@@ -0,0 +1,43 @@
+---
+title: "Last 30 Days Method"
+type: concept
+tags: [market-research, social-media-mining, agentic-ai]
+sources: [market-research-product-factory, last30days-使用指南]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+Last 30 Days Method（近30天法）是一种聚焦近期用户讨论以获取时效性洞察的市场研究方法论——通过限定时间窗口过滤噪音，专注于用户在此时此刻正在经历的问题和需求，避免被历史积累的过时信息干扰。
+
+## Core Mechanism
+
+1. **时间窗口锁定**：只采集最近30天内的帖子/推文/评论
+2. **数据源覆盖**：Reddit（社区讨论）和 X/Twitter（实时热点）双平台
+3. **聚类与排名**：将相似问题归类，按出现频率排序，识别TOP痛点
+4. **原始引用保留**：保留用户原始表述，而非经过转述的二手信息
+
+## Why 30 Days
+
+- **信息时效性**：30天足够收集足够样本量，又不至于被过时内容淹没
+- **市场敏感度**：技术领域变化快，过时的讨论可能反映已解决的旧问题
+- **信号/噪音比**：对比全量历史，30天内的讨论代表用户当前最关心的事
+
+## Relationship to Other Concepts
+
+- **[[Last 30 Days Method]]** → 工具方法 → **[[Agent-Driven Market Research]]**
+- **[[Last 30 Days Method]]** → 工具方法 → **[[Pain Point Mining]]**
+- **[[Last 30 Days Method]]** → 数据供给 → **[[Startup MVP Pipeline]]**
+- **[[Last 30 Days Skill]]** → 软件实现 → **[[Last 30 Days Method]]**
+
+## Implementation
+
+在 OpenClaw 生态中，通过 `Last 30 Days Skill` 实现：
+```text
+Please use the Last 30 Days skill to research challenges people are having with [your topic].
+```
+
+## Sources
+
+- [[market-research-product-factory]]
+- [[last30days-使用指南]]

wiki/concepts/Local-first-Git.md

@@ -0,0 +1,35 @@
+---
+title: "Local-first Git"
+type: concept
+tags: [git, security, devops, self-hosted, devsecops]
+date: 2026-04-22
+---
+
+## Definition
+Local-first Git 是一种 Git 工作流策略：所有代码变更首先推送到本地/私有 Git 服务（而非直接推送到公共 GitHub），经过 CI 扫描和人工 review 后再合并到公共仓库。核心原则：**公共仓库永远不应该是 Agent 的直接目标**。
+
+## In Home Lab Context
+在 [[self-healing-home-server]] 的安全架构中，Local-first Git 工作流：
+```
+Agent commits
+    ↓
+Gitea (private self-hosted) — 私有中转站
+    ↓
+CI pipeline — TruffleHog secrets scanning
+    ↓
+Human review — 必须人工审核 main 分支合并
+    ↓
+GitHub (public) — 最终发布目标
+```
+
+## Why Local-first for AI Agents?
+1. **Secrets 暴露风险**：AI Agent 会在代码中直接写入 API keys（TruffleHog 可检测但不能阻止）
+2. **CI 安全扫描**：在代码到达公共仓库前，有机会拦截问题
+3. **Human oversight**：人工 review 作为最后防线
+4. **Audit trail**：Gitea 提供完整的代码变更审计记录
+
+## Connections
+- [[Gitea]] — Local-first 工作流的核心基础设施
+- [[TruffleHog]] — CI pipeline 中的 secrets scanning 工具
+- [[Defense-in-Depth]] — Local-first Git 是多层安全防御的一环
+- [[OpenClaw]] — 使用 Local-first Git 工作流的 Agent 平台

wiki/concepts/Morning-Briefing.md

@@ -0,0 +1,48 @@
+---
+title: "Morning Briefing"
+type: concept
+tags: [automation, agent, productivity, daily-routine]
+date: 2026-04-22
+---
+
+## Definition
+Morning Briefing（晨报）是 AI Agent 每日定时（通常 8:00 AM）自动生成并推送的结构化摘要，将天气、日历、系统状态和任务看板整合为一份统一的可操作简报。
+
+## In Home Lab Context
+在 [[self-healing-home-server]] 中，OpenClaw Agent "Reef" 每日 8:00 AM 生成晨报，包含以下模块：
+
+### 晨报模板结构
+```
+### Weather
+- 当前天气条件和 [所在地] 预报
+
+### Calendars
+- 你的今日事件
+- 伴侣的今日事件
+- 冲突或重叠标记
+
+### System Health
+- 所有机器的 CPU / RAM / Storage
+- Services: UP/DOWN 状态
+- 最近部署（ArgoCD）
+- 过去 24h 的任何告警
+
+### Task Board
+- 昨日完成的卡片
+- 进行中的卡片
+- 需要关注的阻塞项
+
+### Highlights
+- 夜间头脑风暴的亮点
+- 需要处理的邮件
+- 本周即将到来的截止日期
+```
+
+## Key Insight
+晨报将来自多个系统的碎片信息（天气 API、日历 API、监控系统、看板）整合为单一可操作视图，大幅降低每日信息获取成本。
+
+## Connections
+- [[OpenClaw]] — 生成晨报的 Agent 平台
+- [[Agentic AI]] — 驱动晨报自动化的 AI 能力
+- [[Cron定时任务]] — 晨报调度的触发机制（每日 8:00 AM cron job）
+- [[Daily-Digest]] — 类似思路：AI 每日自动整理信息推送

wiki/concepts/PMDelegationPattern.md

@@ -0,0 +1,30 @@
+---
+title: "PM Delegation Pattern"
+type: concept
+tags: [multi-agent, project-management, coordination]
+sources: [autonomous-project-management]
+last_updated: 2026-04-22
+---
+
+## 定义
+主会话仅负责协调（coordinator），所有执行下沉至子 Agent 的委托模式。每个子 Agent 作为独立的 PM（Project Manager），拥有自己的 STATE.yaml 文件。
+
+## 核心规则
+- **主会话最大工具调用数**：0-2 步（仅 spawn/send 操作）
+- **PM 子 Agent 职责**：拥有和管理自己的 STATE.yaml 文件
+- **PM 可派生子子 Agent**：支持多层级的并行子任务
+- **Git 版本控制**：所有状态变更必须提交至 Git
+
+## 工作流
+1. 新任务到达主会话
+2. 检查 PROJECT_REGISTRY.md 确认是否存在对应 PM
+3. 存在 PM → `sessions_send(label="pm-xxx", message="[task]")`
+4. 新项目 → `sessions_spawn(label="pm-xxx", task="[task]")`
+5. PM 执行任务并更新 STATE.yaml，完成后汇报主会话
+6. 主会话向用户汇总
+
+## 标签约定
+使用 `pm-{project}-{scope}` 格式（如 `pm-auth-refactor`），便于追踪和管理。
+
+## 与 [[CEO Pattern]] 的关系
+PM Delegation Pattern 是 CEO Pattern 在项目管理场景的具体实现——主会话扮演 CEO，仅做战略决策；PM 子 Agent 扮演部门负责人，负责具体执行。

wiki/concepts/PUID-PGID.md

@@ -0,0 +1,43 @@
+# PUID/PGID
+
+## Type
+- Concept
+
+## Definition
+PUID（Process User ID）和 PGID（Process Group ID）是 LinuxServer.io Docker 镜像专用的环境变量，用于将容器内进程以宿主机指定用户/组的身份运行，从根本上解决 Docker 容器创建文件的权限归属问题。
+
+## Mechanism
+
+### 核心原理
+```
+宿主机：用户 shenwei (UID=1000, GID=1000)
+    ↓ 设置 PUID=1000, PGID=1000
+容器内：Transmission 进程以 UID=1000, GID=1000 运行
+    ↓ 结果
+容器创建的文件 → 归属 shenwei:shenwei → 宿主机可直接读写
+```
+
+### 获取宿主机 UID/GID
+```bash
+id shenwei
+# 输出：uid=1000(shenwei) gid=1000(shenwei) groups=1000(shenwei),...
+```
+
+### Docker Compose 配置示例
+```yaml
+environment:
+  - PUID=1000    # 对应宿主机用户 ID
+  - PGID=1000    # 对应宿主机组 ID
+```
+
+## Key Claims
+- PUID/PGID 是 LinuxServer.io 镜像的标准化用户配置，与非 root 用户运行（USER 环境变量）不同
+- 不设置 PUID/PGID 时，容器进程以 root（UID=0）运行，创建的文件归属 root:root，导致宿主机用户无法直接管理
+- PUID/PGID 解决了"容器内 root vs 宿主机普通用户"的跨环境文件权限冲突
+- 与 `user: "1000:1000"` Docker Compose 顶级键效果类似，但 PUID/PGID 由 LinuxServer.io 镜像内部脚本处理
+
+## Relationship to [[LinuxServer.io]]
+PUID/PGID 是 LinuxServer.io 所有镜像的标准化配置环境变量，属于其官方推荐的最佳实践。
+
+## Sources
+- [[用docker安装transmission]]

wiki/concepts/Pain-Point-Mining.md

@@ -0,0 +1,27 @@
+---
+title: "Pain Point Mining"
+type: concept
+tags: [market-research, agentic-ai, product-discovery]
+sources: [market-research-product-factory]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+Pain Point Mining（痛点挖掘）是通过系统化方式从真实用户讨论中识别未被满足的需求、抱怨和功能请求的过程，区别于传统调查问卷或访谈——它直接采集未经加工的用户原生表达。
+
+## Core Mechanism
+
+- **数据来源**：Reddit 社区帖子、X/Twitter 用户推文、论坛讨论、产品评论区
+- **时间窗口**：聚焦近期（如最近30天）讨论以获取时效性洞察
+- **分析方法**：频率统计（高频问题 → 高优先级）、情感分析（强烈负面情绪 → 强需求）、竞品对比（现有方案缺失 → 机会点）
+- **输出格式**：痛点排名 + 具体投诉引用 + 潜在解决方案方向
+
+## Relationship to Other Concepts
+
+- **[[Pain Point Mining]]** → 输入 → **[[Agent-Driven Market Research]]** → 支撑 → **[[Startup MVP Pipeline]]**
+- **[[Pain Point Mining]]** ← 工具依赖 ← **[[Last 30 Days Method]]**
+
+## Sources
+
+- [[market-research-product-factory]]

wiki/concepts/Parallel-Agent-Execution.md

@@ -0,0 +1,61 @@
+---
+title: "Parallel Agent Execution"
+type: concept
+tags: [OpenClaw, Agent, Architecture, Performance]
+sources: [multi-agent-team]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+**Parallel Agent Execution** 是多 Agent 系统中，多个 Agent 同时处理相互独立的任务，通过并行计算提升整体效率的架构模式。
+
+## 核心洞察
+
+> "Parallel execution: Multiple agents can work on independent tasks simultaneously"
+
+并行执行的价值：
+- **效率倍增**：多个任务同时处理，总时间大幅减少
+- **资源优化**：不同 Agent 使用各自擅长的模型
+- **独立扩展**：根据任务量动态调整 Agent 数量
+
+## 并行 vs 串行
+
+| 模式 | 描述 | 时间复杂度 | 适用场景 |
+|------|------|------------|----------|
+| **串行执行** | Agent A → Agent B → Agent C | O(n×t) | 有依赖关系的任务链 |
+| **并行执行** | Agent A ∥ Agent B ∥ Agent C | O(max(t₁,t₂,t₃)) | 独立任务 |
+
+## 并行执行的典型场景
+
+1. **多领域研究**
+   - Josh 分析市场数据
+   - Marketing 追踪竞品动态
+   - Dev 检查 CI/CD 健康状态
+   - 三者同时进行，无需等待
+
+2. **内容创作**
+   - 同时生成多个内容变体
+   - 不同 Agent 用不同风格/角度
+
+3. **监控与响应**
+   - Marketing 持续监控社媒
+   - Dev 持续监控代码质量
+   - Milo 持续追踪 OKR
+
+## 与 Chained Agents 的对比
+
+| 维度 | Parallel Execution | Chained Agents |
+|------|-------------------|----------------|
+| **任务关系** | 独立 | 串行依赖 |
+| **时间效率** | 高（同时） | 中（等待） |
+| **适用场景** | 多领域研究、监控 | 内容生产、审批流 |
+| **协调复杂度** | 低 | 中 |
+
+## Related Concepts
+
+- [[Agent Specialization]] — 专业化 Agent 是并行执行的基础
+- [[Chained Agents]] — 链式 Agent（串行依赖场景）
+- [[Multi-Agent Coordination]] — 多 Agent 协调机制
+- [[Scheduled Task Flywheel]] — 定时任务常利用并行执行
+

wiki/concepts/Pivot-Strategy.md

@@ -0,0 +1,54 @@
+---
+title: "Pivot-Strategy"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Overview
+当赛道拥挤度较高（`reality_signal > 30`）时，通过重新定位切入角度实现差异化的策略。通过分析现有竞品的覆盖盲区，找到一个可专注的细分维度，在该维度上构建竞争优势。
+
+## Three Pivot Dimensions
+当 `reality_signal` 显示赛道拥挤时，可通过以下三个维度实现转向：
+
+### 1. Language Specialization
+语言专一化——只支持特定编程语言的竞品细分。
+- 示例：不做通用的"AI code review tool"，而是"**Rust-only AI code review**"，规避与通用方案（GitHub Copilot、CodeRabbit）的正面竞争
+- 适用场景：某语言社区有特殊需求，通用方案覆盖不足
+
+### 2. Framework Specialization
+框架专一化——只针对特定框架的审查工具。
+- 示例："**React 组件合规性审查**"而非通用代码审查
+- 适用场景：某框架有独特的 linting/compliance 需求
+
+### 3. Industry Specialization
+行业专一化——针对特定垂直行业的合规/审查工具。
+- 示例："**金融/医疗代码合规性审查**"（HIPAA、SOX 相关代码检查）
+- 适用场景：强监管行业有特殊代码合规要求，通用方案无法满足
+
+## Decision Framework
+```
+reality_signal > 70?
+  → STOP + 展示竞品 + 询问用户是否继续/转向/放弃
+  → 用户选择 pivot 后，从三个维度中选择最合适的角度
+
+reality_signal 30-70?
+  → 展示竞品 + 提供 pivot_hints
+  → Agent 主动建议差异化角度
+
+reality_signal < 30?
+  → 赛道空白，直接构建
+```
+
+## Relationship to Related Concepts
+- [[Competition-Analysis]] ← 识别需要 pivot 的时机
+- [[Reality-Signal]] ← 决策阈值依据
+- [[Pre-Build Validation]] ← 包含 pivot 决策的工作流
+- [[Agent-Build-Gate]] ← pivot 决策通过后的后续动作
+
+## Related
+- [[Competition-Analysis]]
+- [[Reality-Signal]]
+- [[Pre-Build Validation]]
+- [[Agent-Build-Gate]]
+- [[Startup MVP Pipeline]]

wiki/concepts/Pre-Build-Validation.md

@@ -0,0 +1,45 @@
+---
+title: "Pre-Build Validation"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Overview
+在代码编写之前进行市场/竞争验证的工作流模式。AI Agent 接收构建指令后，首先调用竞争分析工具（如 [[idea-reality-mcp]] 的 `idea_check()`）评估赛道的真实拥挤度，只有通过门控条件才允许进入实际代码编写阶段。
+
+## Mechanism
+1. 用户/Agent 提出构建需求（如"build me an AI code review tool"）
+2. Agent 调用 `idea_check()` 扫描多平台真实数据
+3. 返回 `reality_signal` 分数（0-100）
+4. 根据阈值决策：继续构建 / 暂停讨论 / 建议转向
+
+## Decision Thresholds
+| reality_signal | 决策 | 行动 |
+|---|---|---|
+| > 70 | STOP | 展示竞品，询问是否继续/转向/放弃 |
+| 30-70 | 展示+建议 | 显示结果和 pivot_hints，建议差异化角度 |
+| < 30 | 直接构建 | 提示市场空白，批准开始编写代码 |
+
+## Why It Matters
+防止 AI Agent 犯最昂贵的错误：**在一个已被成熟方案解决的领域投入大量时间**。GitHub 上有 143,000+ AI code review 相关仓库，顶端方案已有 53,000+ stars——Agent 不知道是因为没有人告诉它去查，也没有人告诉它应该查。
+
+## Relationship to Related Concepts
+- [[Pre-Build Validation]] ← 前置于 [[Startup MVP Pipeline]]
+- [[Pain Point Mining]] → [[Pre-Build Validation]] → [[Startup MVP Pipeline]]（完整的产品发现到构建流程）
+- [[Reality-Signal]] 是 [[Pre-Build Validation]] 的核心度量指标
+- [[Agent-Build-Gate]] 是 [[Pre-Build Validation]] 的技术实现机制
+
+## Aliases
+- Pre-Build Gate
+- Idea Validation Gate
+- Pre-Build Checkpoint
+
+## Related
+- [[idea-reality-mcp]]
+- [[Reality-Signal]]
+- [[Competition-Analysis]]
+- [[Pivot-Strategy]]
+- [[Agent-Build-Gate]]
+- [[Startup MVP Pipeline]]
+- [[Pain Point Mining]]

wiki/concepts/Private-Context.md

@@ -0,0 +1,63 @@
+---
+title: "Private Context"
+type: concept
+tags: [OpenClaw, Agent, Architecture, Memory]
+sources: [multi-agent-team]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+**Private Context** 是多 Agent 系统中，每个 Agent 独立维护的会话历史和领域特定笔记，与 Shared Memory 共同构成 Agent 的完整知识体系。
+
+## 核心洞察
+
+> "Shared memory + private context: The combination is critical — agents need common ground (goals, decisions) but also their own space to accumulate domain expertise"
+
+私有上下文的作用：
+- **积累领域专长**：Agent 在独立空间深耕专业知识
+- **会话连续性**：Agent 能记住自己的历史决策和上下文
+- **避免干扰**：专业笔记不会与其他 Agent 混淆
+
+## 私有上下文结构
+
+```
+team/agents/
+├── milo/          # Milo 的私有上下文
+│   ├── sessions/ # 会话历史
+│   └── notes/    # 战略分析和笔记
+├── josh/         # Josh 的私有上下文
+│   ├── sessions/ # 会话历史
+│   └── notes/    # 商业分析和模型
+├── marketing/    # 营销 Agent 的私有上下文
+│   ├── sessions/ # 会话历史
+│   └── notes/    # 营销研究和趋势分析
+└── dev/          # 开发 Agent 的私有上下文
+    ├── sessions/ # 会话历史
+    └── notes/    # 技术笔记和技术债追踪
+```
+
+## 与 Shared Memory 的关系
+
+**Private Context** + **Shared Memory** 组合是关键：
+
+| 维度 | Shared Memory | Private Context |
+|------|---------------|-----------------|
+| **可见性** | 所有 Agent | 仅该 Agent |
+| **用途** | 团队协调、共同决策 | 领域深耕、专业积累 |
+| **更新频率** | 决策时更新 | 持续积累 |
+| **典型内容** | 目标、决策、状态 | 会话历史、专业笔记 |
+
+## 为什么两者都需要
+
+- **只有共享记忆**：Agent 缺乏领域深度
+- **只有私有上下文**：Agent 无法协调，形成知识孤岛
+- **两者结合**：既能有团队协作，又能深耕专业
+
+## Related Concepts
+
+- [[Shared Memory Architecture]] — 团队共享记忆
+- [[Agent-Memory]] — OpenClaw 的长期记忆机制
+- [[Agent Specialization]] — 专业化 Agent 依赖私有上下文积累深度
+- [[OpenClaw]] — workspace 目录体系支持私有上下文
+

wiki/concepts/Proactive-Agent-Recommendation.md

@@ -0,0 +1,41 @@
+---
+title: "Proactive Agent Recommendation"
+type: concept
+tags: [openclaw, ai-agent, productivity]
+sources: [custom-morning-brief, multi-agent-team]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+主动任务推荐（Proactive Agent Recommendation）是一种 AI Agent 设计范式——Agent 不是被动等待用户指令，而是主动分析用户上下文并推荐可自主完成的辅助任务，使用户从"发出指令→等待结果"转变为"收到已完成的工作成果"。
+
+## Contrast with Reactive Mode
+
+| 维度 | 被动模式（Reactive） | 主动模式（Proactive） |
+|------|--------------------|--------------------|
+| 触发方式 | 用户主动发起请求 | AI 定时或基于上下文自动触发 |
+| 用户角色 | 指挥官 | 接收者/审批者 |
+| 价值交付 | 按需响应 | 提前完成，超出预期 |
+| 认知负担 | 用户需持续思考"要什么" | AI 承担"思考要做什么" |
+
+## Key Applications
+
+- **[[custom-morning-brief]]**：每日晨间简报中的"AI 主动推荐可完成任务"模块
+- **[[multi-agent-team]]**：Agent 主动推送工作成果，而非等待轮询
+
+## Implementation Pattern
+
+```text
+1. Cron Job 触发 → AI 分析用户上下文
+2. AI 生成 N 条可自主完成的任务建议
+3. 高置信度任务 → 自动执行
+4. 中置信度任务 → 推送选项，用户确认后执行
+5. 结果交付 → Telegram/Discord
+```
+
+## Related Concepts
+
+- [[Scheduled Task Flywheel]] — 主动推荐的时间调度机制
+- [[Agent Personality]] — 主动行为需要精心设计的 Agent 人格
+- [[Morning Briefing]] — 主动推荐的典型应用场景

wiki/concepts/ProjectState.md

@@ -0,0 +1,59 @@
+---
+title: "Project State"
+type: concept
+tags: [project-management, automation, ai]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+项目状态（Project State）指一个项目在任意时间点的完整快照——包括当前阶段、活跃阻塞项、最近进展、以及完整的事件历史上下文。与传统项目管理工具中"当前状态"字段不同，项目状态由底层事件自动驱动更新，而非手动维护。
+
+## What It Captures
+
+一个完整项目状态系统通常包含：
+
+- **基本元数据**：项目名称、当前阶段（phase）、总体状态（active/blocked/completed）
+- **时间戳**：最后更新时间，便于判断项目是否"失活"
+- **事件日志**：所有 progress/blocker/decision/pivot 事件的完整序列
+- **阻塞清单**：当前所有 open blockers 及创建时间
+- **上下文**：每次变更的决策理由，而非仅记录"变更了什么"
+
+## State Machine
+
+典型项目状态流转：
+
+```
+active → [blocked event] → blocked
+blocked → [blocker resolved event] → active
+active → [completion event] → completed
+any → [pivot event] → active (new phase)
+```
+
+## Event-Driven vs Kanban
+
+| 维度 | 事件驱动项目状态 | 传统看板（Kanban）|
+|------|---------------|----------------|
+| 更新方式 | 自然语言对话自动驱动 | 手动拖拽卡片 |
+| 状态来源 | 事件序列推导 | 卡片当前位置 |
+| 历史保留 | 完整事件日志，可回溯决策原因 | 通常不保留，状态变更即丢失 |
+| 上下文 | 每次变更附带决策理由 | 无，需额外备注 |
+| 阻塞追踪 | 独立 blocker 记录 + 自动状态更新 | 卡片标签/泳道，依赖人工识别 |
+| 团队协作 | 需要额外机制（如 Discord 多用户）| 原生支持多人实时协作 |
+| 适合场景 | 个人/小团队，需要上下文保留 | 中大型团队，强协作需求 |
+
+## AI Integration
+
+在 [[Project State Management]] 系统中，AI Agent 承担以下角色：
+
+- **自然语言解析器**：将用户日常对话转换为结构化事件
+- **状态引擎**：根据事件类型自动更新项目状态
+- **查询接口**：回答"项目X现在什么状态"/"为什么做了Y决策"
+- **报告生成器**：自动生成每日站会、每周总结
+
+## Connections
+
+- **Project State** ← derived_from ← [[Event Sourcing]]
+- **Project State** ← powered_by ← [[OpenClaw]]
+- **Project State Management** ← uses ← **Project State**
+- [[Kanban]] ← alternative_to ← **Project State**（冲突：参见 overview.md Conflict Area #1）

wiki/concepts/Reality-Signal.md

@@ -0,0 +1,40 @@
+---
+title: "Reality-Signal"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Overview
+通过 `idea_check()` 返回的 0-100 赛道拥挤度评分，基于 GitHub 仓库数量、Star 分布、Hacker News 讨论量等真实数据。用于 [[Pre-Build Validation]] 的核心度量指标，决定 Agent 是否可以继续构建还是需要暂停讨论。
+
+## Scoring Mechanism
+- **GitHub**：相关仓库数量 + Top 竞品的 Star 总数
+- **Hacker News**：相关讨论帖数量 + 平均分数
+- **npm / PyPI**：包数量 + 下载量分布
+- **Product Hunt**：早期产品关注度
+
+综合以上数据输出 0-100 的 `reality_signal` 分数。
+
+## Interpretation
+| 分数区间 | 信号含义 | 行动 |
+|---|---|---|
+| > 70/100 | 高度拥挤 | 成熟竞品众多，需强差异化 |
+| 30-70/100 | 中度竞争 | 存在机会但需细分角度 |
+| < 30/100 | 市场空白 | 真正的蓝海，白手起家的最佳区间 |
+
+## Key Properties
+- **基于真实数据，非 LLM 猜测**：unlike subjective assessment, reality_signal uses actual repo counts, star distributions, and HN discussion volume
+- **用途**：[[Pre-Build Validation]] 决策依据；Hackathon 想法排名（最低分 = 最佳机会）
+- **局限性**：无法评估技术实现难度、市场进入时机、团队执行能力
+
+## Aliases
+- Competition Score
+- Market Saturation Score
+- Idea Signal
+
+## Related
+- [[Pre-Build Validation]]
+- [[Competition-Analysis]]
+- [[idea-reality-mcp]]
+- [[Pivot-Strategy]]

wiki/concepts/Sandboxed-Persona.md

@@ -0,0 +1,31 @@
+---
+title: "Sandboxed Persona"
+type: concept
+tags: []
+last_updated: 2026-04-22
+---
+
+## Definition
+沙盒 Persona 是一种 AI 对话设计模式——AI persona 仅持有预设的上下文（persona name、goal、opening line），与外部系统（Agent、数据、工具、其他对话）完全隔离，无法访问、修改或泄露任何超出预设范围的信息。
+
+## Key Properties
+- **上下文隔离**：AI 只知道预设的三要素（名称、目标、开场白）
+- **状态重置**：每轮对话独立初始化，无跨对话状态保留
+- **攻击面收窄**：外部用户无法通过对话注入 Prompt 或窃取数据
+- **任务专注**：AI 不会因过多上下文而偏离单一任务
+
+## Use Cases
+- [[SuperCall]] — 电话外呼场景，AI 以沙盒 persona 接听来电确认出席
+- [[voice-call-confirmation]] — 需要纯确认流程的各类电话场景
+- AI 客服 / AI 面试官 / AI 问卷调查 — 需要严格控制信息边界的对话
+
+## Related Concepts
+- [[Agent Personality Design]] — Agent 的角色/性格设计
+- [[Private Context]] — Agent 的私有上下文保护
+- [[Prompt Injection Defense]] — 对抗恶意 Prompt 注入的防御策略
+
+## Contradictions
+- 与 [[General Purpose Voice Agent]] 对比：
+  - 冲突点：通用语音 Agent 追求多功能和上下文丰富性；沙盒 Persona 追求最小暴露
+  - 当前观点：沙盒 Persona 适用于确认类单一任务场景
+  - 对方观点：通用 Agent 适用于需要跨系统协调的复杂助手场景

wiki/concepts/Scheduled-Reminder.md

@@ -0,0 +1,37 @@
+---
+title: "Scheduled Reminder"
+type: concept
+tags: [Automation, Cron, Agent, Proactive, OpenClaw]
+sources: [multi-channel-assistant]
+last_updated: 2026-04-22
+---
+
+# Scheduled Reminder
+
+## Definition
+Scheduled Reminder（定时提醒）是一种基于 Cron Job 的主动推送机制——AI Agent 在预设时间自动触发提醒消息，无需用户主动查询。在 [[multi-channel-assistant]] 中展示了定时提醒的典型应用。
+
+## Mechanism
+OpenClaw 通过 Cron Job 系统调度定时任务：
+
+- **周一 18:00** → "🗑️ 明天是垃圾清理日"
+- **周五 15:00** → "✍️ 该写每周公司周报了"
+
+## Significance
+Scheduled Reminder 是 AI Agent 区别于传统问答式 AI 工具的核心特征：
+
+| 被动模式 | 主动模式 |
+|---------|---------|
+| 用户问，AI 答 | AI 定时推送，用户被动接收 |
+| 需要用户主动关注 | 用户无需记住，系统主动提醒 |
+| 依赖用户记忆 | 零记忆负担 |
+
+## Related Patterns
+- [[Scheduled Task Flywheel]] — 定时任务驱动的持续运转机制
+- [[Morning Briefing]] — 定时提醒的具体应用场景
+- [[Topic-Based Routing]] — `updates` Topic 承载提醒消息的投递
+
+## Connections
+- [[multi-channel-assistant]] — Scheduled Reminder 的应用场景
+- [[OpenClaw]] — Cron Job 调度引擎
+- [[Telegram]] — 提醒消息的投递渠道

wiki/concepts/Scheduled-Task-Flywheel.md

@@ -0,0 +1,42 @@
+---
+title: "Scheduled Task Flywheel"
+type: concept
+tags: [openclaw, automation, productivity]
+sources: [multi-agent-team, custom-morning-brief, earnings-tracker, self-healing-home-server]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+定时任务飞轮（Scheduled Task Flywheel）是 OpenClaw 的核心自动化范式——通过定时 Cron Job 触发 AI Agent 自主工作，用户无需主动发起指令，AI 在后台完成情报收集、内容生成、数据处理等任务，结果在用户需要时已就位。
+
+## Core Mechanism
+
+1. **调度层**：通过 Cron Job 设置定时触发规则（每日 8AM、每周日 6PM 等）
+2. **执行层**：AI Agent 在触发时间自动执行任务（网络搜索、内容生成、数据处理）
+3. **交付层**：结果通过 Telegram/Discord/iMessage 推送给用户
+4. **飞轮效应**：每次执行都为下次提供更好的上下文积累，形成自动化正向循环
+
+## Key Applications
+
+- **[[custom-morning-brief]]**：利用夜间空闲时间让 AI 完成新闻研究和草稿生成，晨起直接收到完整简报
+- **[[earnings-tracker]]**：每周日自动扫描财报日历，用户选择后为每家公司创建一次性 Job
+- **[[self-healing-home-server]]**：Reef Agent 的 24/7 全天候自动化（每15分钟健康检查、每小时监控）
+- **[[multi-agent-team]]**：多个 Agent 定时轮转，主动向用户推送成果
+
+## Key Insight
+
+> "The AI-recommended tasks section is the most powerful part — it has the agent proactively think of ways to help you, rather than waiting for instructions." — 自定义晨间简报的核心洞察
+
+## Why "Flywheel"
+
+与被动等待指令的传统助手不同，飞轮模式下 AI **主动**创造价值。每次定时触发后：
+- 上下文积累 → 下次执行更精准
+- 模板成熟 → 输出质量持续提升
+- 用户习惯养成 → 简报成为每日必需
+
+## Related Concepts
+
+- [[Morning Briefing]] — 定时飞轮的具体应用场景
+- [[Proactive Agent Recommendation]] — 飞轮中"主动思考如何帮助用户"的关键能力
+- [[Single Control Plane]] — 飞轮与用户之间的统一交互界面

wiki/concepts/Shared-Memory-Architecture.md

@@ -0,0 +1,57 @@
+---
+title: "Shared Memory Architecture"
+type: concept
+tags: [OpenClaw, Agent, Architecture, Memory]
+sources: [multi-agent-team]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+**Shared Memory Architecture** 是多 Agent 系统中，所有 Agent 共用一套公共记忆文件（GOALS.md、DECISIONS.md、PROJECT_STATUS.md），确保团队目标、关键决策和项目状态对所有 Agent 可见的架构模式。
+
+## 核心洞察
+
+> "Shared memory + private context: The combination is critical — agents need common ground (goals, decisions) but also their own space to accumulate domain expertise"
+
+共享记忆解决的问题：
+- **知识孤岛**：营销洞察不会自动影响开发优先级
+- **上下文丢失**：每个 Agent 独立会话无法继承团队决策
+- **重复工作**：Agent A 的发现对 Agent B 不可见
+
+## 共享文件结构
+
+```
+team/
+├── GOALS.md           # 当前 OKR 和优先级（所有 Agent 读取）
+├── DECISIONS.md       # 关键决策日志（追加写入）
+├── PROJECT_STATUS.md  # 当前项目状态（所有 Agent 更新）
+├── agents/
+│   ├── milo/          # Milo 的私有上下文和笔记
+│   ├── josh/          # Josh 的私有上下文
+│   ├── marketing/     # 营销 Agent 的研究笔记
+│   └── dev/           # 开发 Agent 的技术笔记
+```
+
+## 共享记忆类型
+
+| 文件 | 用途 | 写入规则 |
+|------|------|----------|
+| GOALS.md | 团队目标和 OKR | 定期更新（周/日） |
+| DECISIONS.md | 关键决策记录 | 决策时追加 |
+| PROJECT_STATUS.md | 项目当前状态 | 状态变更时更新 |
+
+## 与 Private Context 的关系
+
+**Shared Memory** + **Private Context** 组合是关键：
+- **Shared Memory**：共同基础（目标、决策、项目状态）
+- **Private Context**：独立空间积累领域专业知识
+- 两者缺一不可：只有共享记忆导致缺乏深度，只有私有上下文导致知识孤岛
+
+## Related Concepts
+
+- [[Agent-Memory]] — OpenClaw 的长期记忆机制
+- [[Private Context]] — Agent 私有上下文
+- [[OpenClaw]] — 提供 workspace 目录体系支持
+- [[Agent Specialization]] — 专业化 Agent 依赖共享记忆协调
+

wiki/concepts/SharedStateCoordination.md

@@ -0,0 +1,59 @@
+---
+title: "Shared State Coordination"
+type: concept
+tags: [multi-agent, coordination, architecture]
+sources: [autonomous-project-management]
+last_updated: 2026-04-22
+---
+
+## 定义
+多 Agent 通过读写共享状态文件（而非消息传递）实现协调的通信范式。在 [[autonomous-project-management]] 中具体实现为共享的 `STATE.yaml` 文件。
+
+## 核心机制
+- **单一真相来源**（Single Source of Truth）：STATE.yaml 作为项目协调的单一事实来源
+- **文件读写协调**：各子 Agent 读取自己被分配的任务，写入进度/完成状态
+- **轮询自驱动**：Agent 主动轮询 STATE.yaml，发现任务解锁后自动拾取
+- **无需消息队列**：避免引入额外的消息传递中间件依赖
+
+## STATE.yaml 结构示例
+```yaml
+project: website-redesign
+updated: 2026-02-10T14:30:00Z
+
+tasks:
+  - id: homepage-hero
+    status: in_progress
+    owner: pm-frontend
+    notes: "Working on responsive layout"
+
+  - id: api-auth
+    status: done
+    owner: pm-backend
+    output: "src/api/auth.ts"
+
+  - id: content-migration
+    status: blocked
+    owner: pm-content
+    blocked_by: api-auth
+
+next_actions:
+  - "pm-content: Resume migration now that api-auth is done"
+```
+
+## 优势
+- **去中心化**：无中心协调器，单点故障风险低
+- **版本可控**：Git 作为审计日志，完整可追溯
+- **简单可靠**：无需额外的消息队列或 RPC 中间件
+- **持久化**：状态天然持久，支持断点恢复
+
+## 与消息传递模式对比
+| 维度 | 共享文件协调 | 消息传递协调 |
+|------|-------------|-------------|
+| 中间件依赖 | 仅文件系统 | 需要 MQ/Pub-Sub |
+| 状态持久性 | 天然持久 | 需要额外存储 |
+| 并发控制 | 文件锁 | 队列ACK |
+| 调试难度 | 高（需读文件） | 中（需追踪消息流） |
+| 适用场景 | 并行独立任务 | 有序依赖链 |
+
+## 衍生概念
+- [[Git-as-Audit-Log]]：将所有 STATE.yaml 变更提交至 Git，获得完整历史

wiki/concepts/Single-Control-Plane.md

@@ -0,0 +1,67 @@
+---
+title: "Single Control Plane"
+type: concept
+tags: [OpenClaw, Agent, Architecture, Interface]
+sources: [multi-agent-team]
+last_updated: 2026-04-23
+---
+
+## Definition
+
+**Single Control Plane** 是多 Agent 系统中，通过单一消息接口（如 Telegram 分组）统一接入所有 Agent，每个 Agent 仅在收到特定标签时响应的架构设计。
+
+## 核心洞察
+
+> "Single control plane: All agents are accessible through one Telegram group chat — tag the agent you need"
+
+单一控制平面的价值：
+- **降低使用门槛**：用户只需在一个地方与团队互动
+- **统一入口**：不需要记住多个 Agent 的独立接口
+- **自然协作**：像在团队群组中与不同成员对话
+
+## Telegram 路由配置
+
+```
+Telegram group: "Team"
+
+Routing:
+- @milo → Strategy agent (spawns/resumes milo session)
+- @josh → Business agent (spawns/resumes josh session)
+- @marketing → Marketing agent (spawns/resumes marketing session)
+- @dev → Dev agent (spawns/resumes dev session)
+- @all → Broadcast to all agents
+- No tag → Milo (team lead) handles by default
+
+Each agent:
+1. Reads shared GOALS.md and PROJECT_STATUS.md for context
+2. Reads its own private notes
+3. Processes the message
+4. Responds in Telegram
+5. Updates shared files if the response involves a decision or status change
+```
+
+## Agent 处理流程
+
+每个 Agent 收到消息时的标准处理流程：
+
+1. **读取共享上下文**：GOALS.md 和 PROJECT_STATUS.md
+2. **读取私有笔记**：自己的 agents/<name>/ 目录
+3. **处理消息**：结合上下文和专业知识
+4. **响应 Telegram**：在群组中回复
+5. **更新共享文件**：如有决策或状态变更
+
+## 与其他接口模式的对比
+
+| 模式 | 描述 | 适用场景 |
+|------|------|----------|
+| **Single Control Plane** | 统一入口 + 标签路由 | 团队协作、多 Agent 协调 |
+| **独立接口** | 每个 Agent 独立通道 | 简单任务、专业工具 |
+| **网页界面** | Web UI 控制台 | 监控和管理 |
+
+## Related Concepts
+
+- [[OpenClaw]] — 提供 sessions_spawn/sessions_send 能力
+- [[Telegram]] — 常用作控制平面的消息平台
+- [[Multi-Agent Coordination]] — 协调多 Agent 的机制
+- [[Agent Specialization]] — 专业化 Agent 便于标签路由
+

wiki/concepts/Startup-MVP-Pipeline.md

@@ -0,0 +1,37 @@
+---
+title: "Startup MVP Pipeline"
+type: concept
+tags: [startup, agentic-ai, mvp, product-building]
+sources: [market-research-product-factory]
+last_updated: 2026-04-22
+---
+
+## Definition
+
+Startup MVP Pipeline（创业最小可行产品流水线）是从市场机会发现到可演示产品原型的端到端自动化流程——用 AI Agent 替代人工完成"调研→验证→构建→交付"全链路。
+
+## Core Mechanism
+
+1. **Pain Point Mining**：从 Reddit/X 挖掘真实用户痛点（按频率排序）
+2. **Opportunity Validation**：分析现有方案缺口，确定未被满足的需求
+3. **MVP Specification**：用自然语言描述要解决的问题，AI 自动生成产品需求
+4. **Automated Build**：AI Agent（OpenClaw）根据需求构建 Web 应用原型
+5. **Delivery**：生成的 Web 应用可直接分享给用户验证
+
+## Key Characteristics
+
+- **全自动化**：用户只需发一条消息，即可获得可演示的 Web 应用
+- **无技术门槛**：无需编程能力，OpenClaw 承担所有构建职责
+- **快速迭代**：发现痛点 → 构建原型 → 用户验证，周期以小时计
+- **持续监控**：可定期调度调研，持续追踪市场痛点演化
+
+## Relationship to Other Concepts
+
+- [[Pain Point Mining]] → 供给数据 → [[Startup MVP Pipeline]]
+- [[Agent-Driven Market Research]] → 提供方法论 → [[Startup MVP Pipeline]]
+- [[content-factory]] ← extends ← [[Startup MVP Pipeline]]：内容工厂延伸为产品工厂
+- [[product-trend-researcher]] ← depends_on ← [[Last 30 Days Method]] → 支持 [[Startup MVP Pipeline]]
+
+## Sources
+
+- [[market-research-product-factory]]

wiki/concepts/TCP隧道.md

@@ -0,0 +1,112 @@
+---
+title: "TCP 隧道"
+type: concept
+aliases: [TCP Tunnel, TCP端口转发, TCP代理]
+tags: [network, tunneling, protocol]
+---
+
+# TCP 隧道
+
+## Definition
+**TCP 隧道**是通过在两个端点之间建立虚拟连接，将本地 TCP 端口的流量透明传输到远程端点的技术。TCP 隧道是构建 VPN、反向代理和内网穿透的基础机制之一。
+
+## How It Works
+
+```
+┌─────────────┐                        ┌─────────────┐
+│  本地机器    │                        │   VPS       │
+│             │                        │             │
+│  应用 → :22 │ ──── TCP 隧道 ──── →   │ :60022 ← ──│──── 外部 SSH 客户端
+│             │    (frp/nc/socat)      │             │
+└─────────────┘                        └─────────────┘
+```
+
+## TCP vs HTTP/HTTPS 隧道
+
+| 特性 | TCP 隧道 | HTTP/HTTPS 隧道 |
+|------|----------|----------------|
+| **协议** | 任意 TCP | HTTP/HTTPS |
+| **应用层解析** | ❌ 不解析 | ✅ 可解析 |
+| **WebSocket** | ❌ 不支持 | ✅ 支持 |
+| **使用场景** | SSH、数据库、任意 TCP | Web 服务 |
+| **Caddy 支持** | ❌ 不支持 | ✅ 支持 |
+
+## frp TCP 映射
+
+### 配置示例
+```ini
+# frpc.ini
+[ssh]
+type = tcp
+local_ip = 127.0.0.1
+local_port = 22
+remote_port = 60022
+```
+
+### 访问链路
+```
+外部 SSH 客户端
+   ↓
+ssh -p 60022 user@vps-ip
+   ↓
+VPS :60022 (frps 监听)
+   ↓
+frp 隧道
+   ↓
+内网机器 :22
+   ↓
+本地 SSH 服务
+```
+
+## Common Tools for TCP Tunneling
+
+| 工具 | 特点 | 使用场景 |
+|------|------|---------|
+| **frp** | 高性能、支持 Dashboard | 内网穿透 |
+| **socat** | 简单单次转发 | 临时调试 |
+| **netcat (nc)** | 基础端口转发 | 快速测试 |
+| **ssh -L** | SSH 内置隧道 | 临时访问 |
+| **stunnel** | SSL 隧道加密 | 安全转发 |
+
+## SSH 原生隧道 (替代方案)
+
+### 临时隧道
+```bash
+# 本地端口转发：访问远程内网服务
+ssh -L 8080:internal:80 user@vps
+
+# 远程端口转发：暴露本地服务到公网
+ssh -R 60022:localhost:22 user@vps
+```
+
+### 持久化问题
+SSH 隧道在网络中断后不会自动重连，生产环境推荐使用 frp。
+
+## Security Considerations
+
+### TCP 隧道注意事项
+1. **不经过 HTTP 代理**：TCP 流量不被 Caddy/Nginx 解析
+2. **直接暴露端口**：SSH 22 端口不宜直接暴露，使用非标准端口
+3. **IP 白名单**：防火墙限制来源 IP
+4. **公钥认证**：禁用密码登录
+
+### 建议配置
+```bash
+# VPS 防火墙：只允许特定 IP
+sudo ufw allow from <home_ip> to any port 60022 proto tcp
+
+# SSH 配置：禁用密码
+sudo nano /etc/ssh/sshd_config
+PasswordAuthentication no
+PubkeyAuthentication yes
+```
+
+## Related Concepts
+- [[内网穿透]] — TCP 隧道的典型应用场景
+- [[frp]] — 实现 TCP 隧道的工具
+- [[反向代理]] — HTTP/HTTPS 层面的代理（与 TCP 层互补）
+- [[VPS]] — TCP 隧道的公网端点
+
+## References
+- frp TCP: https://gofrp.org/docs/features/common-address-types/#tcp
+- SSH Tunneling: https://www.ssh.com/academy/ssh/tunneling

wiki/concepts/Telephony-Integration.md

@@ -0,0 +1,25 @@
+---
+title: "Telephony Integration"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-22
+---
+
+# Telephony Integration（电话能力集成）
+
+## Definition
+电话能力集成指 AI Agent 框架通过电信 API 实现来电接收和去电呼叫的能力，使 AI Agent 能够通过传统电话网络与用户通信，无需依赖智能手机 App 或互联网连接。
+
+## Implementation Pattern
+1. **电信 API**：通过 [[Telnyx]] 等提供商获取电话号码和电话连接
+2. **客户端库**：通过 [[ClawdTalk]] 等客户端库与 Agent 框架对接
+3. **Agent 框架**：[[OpenClaw]] 等支持 phone skill 的多 Agent 框架
+4. **语音处理**：实时语音流与 Agent 的对话能力结合
+
+## Use Cases
+- **来电接收**：用户主动拨打，接听并与 AI 对话
+- **去电外呼**：Agent 主动拨打电话（参见 [[event-guest-confirmation]] 中的 [[SuperCall]] 方案）
+
+## Sources
+- [[phone-based-personal-assistant]]

wiki/concepts/Topic-Based-Routing.md

@@ -0,0 +1,39 @@
+---
+title: "Topic-Based Routing"
+type: concept
+tags: [Routing, Telegram, Multi-Context, OpenClaw]
+sources: [multi-channel-assistant]
+last_updated: 2026-04-22
+---
+
+# Topic-Based Routing
+
+## Definition
+Topic-Based Routing（基于话题的路由）是一种通过标签/话题机制将用户请求分发到不同上下文处理单元的设计模式。在 [[multi-channel-assistant]] 中，通过 Telegram Topic 实现多上下文隔离。
+
+## Mechanism
+用户在不同 Telegram Topic 中发送消息，OpenClaw 根据 Topic 标签识别上下文域：
+
+| Topic | 处理的上下文 |
+|-------|------------|
+| `config` | 系统设置、调试 |
+| `updates` | 日报摘要、定时提醒、日历 |
+| `video-ideas` | 内容管线、研究 |
+| `personal-crm` | 联系人和会议准备 |
+| `earnings` | 财务追踪 |
+| `knowledge-base` | 知识库存取与检索 |
+
+## Key Properties
+- **上下文隔离**：每个 Topic 携带独立的记忆上下文，不会跨 Topic 污染
+- **单一入口**：用户只需记住 Telegram 一个入口，不需要切换多个 App
+- **意图推断**：通过 Topic 标签帮助 LLM 理解用户当前关注域，降低提示词复杂度
+
+## Related Concepts
+- [[Multi-Tool Integration]] — Topic Routing 是触发不同工具集的前提
+- [[Single Control Plane]] — Telegram 作为统一控制平面的实现方式
+- [[Scheduled Reminder]] — `updates` Topic 承载主动提醒推送
+
+## Connections
+- [[multi-channel-assistant]] — Topic-Based Routing 的应用场景
+- [[OpenClaw]] — 路由逻辑的执行引擎
+- [[Telegram]] — 路由机制的载体平台

wiki/concepts/Voice-Interface.md

@@ -0,0 +1,25 @@
+---
+title: "Voice Interface"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-22
+---
+
+# Voice Interface（语音接口）
+
+## Definition
+语音接口是通过电话等语音通道与 AI Agent 进行交互的接口层。相比文字入口（如 Telegram、Slack），语音接口无需屏幕或键盘，覆盖驾驶、步行、双手占用等场景。
+
+## Characteristics
+- **免提交互**：用户无需盯着屏幕或使用键盘
+- **场景覆盖**：驾驶、步行、双手忙碌时
+- **输入限制**：语音输入的信息密度低于文字（无法精确指定参数）
+- **输出优化**：需要将结构化信息转译为自然语言表述
+
+## Related Concepts
+- [[Telephony Integration]]：语音接口的底层电话能力集成
+- [[Multi-Tool Integration]]：语音接口通常需要 Calendar/Jira/Web Search 等多工具配合才能提供完整价值
+
+## Sources
+- [[phone-based-personal-assistant]]

wiki/concepts/内网穿透.md

@@ -0,0 +1,122 @@
+---
+title: "内网穿透"
+type: concept
+aliases: [NAT穿透, 内网访问, 穿透技术]
+tags: [network, tunneling, infrastructure]
+---
+
+# 内网穿透
+
+## Definition
+**内网穿透**（NAT Traversal / Reverse Proxy Tunneling）是一种使位于私有网络（内网）中的设备能够被公网访问的技术。家用网络设备通常位于 NAT（网络地址转换）后面，无法直接接收公网连接，内网穿透通过在公网服务器建立反向隧道来解决这一问题。
+
+## Core Principle
+
+传统正向代理：客户端 → 公网代理服务器 → 目标服务器
+内网穿透（反向隧道）：公网服务器 → 反向隧道 → 内网客户端
+
+```
+Internet
+   │
+   │ ← 发起连接（公网）
+   ▼
+┌───────────────┐
+│   VPS (公网)   │
+│  frps/Caddy   │
+└───────┬───────┘
+        │ ← 反向隧道建立
+        ▼
+┌───────────────┐
+│  内网机器 (frpc) │
+│  192.168.x.x   │
+└───────────────┘
+```
+
+## Common Tools
+
+| 工具 | 协议 | 特点 | 适用场景 |
+|------|------|------|---------|
+| **frp** | TCP/UDP/HTTP | 高性能、支持 Dashboard | 多服务穿透 |
+| **ngrok** | TCP/HTTP | 简单易用、托管服务 | 临时测试 |
+| **natapp** | TCP/HTTP | 国内服务 | 国内访问 |
+| **花生壳** | TCP/HTTP | 老牌、商业化 | 企业用户 |
+| **ZeroTier** | VPN | 虚拟局域网 | 远程办公 |
+
+## frp 实现方案
+
+### 架构组件
+1. **frps (Server)**：部署在公网 VPS，监听端口（默认 7000）
+2. **frpc (Client)**：部署在内网机器，主动连接 frps
+
+### 典型配置流程
+1. VPS 安装 frps，配置 systemd 服务
+2. 内网机器安装 frpc，配置连接参数
+3. frpc 配置端口映射（local_port → remote_port）
+4. Caddy/Nginx 在 VPS 做反向代理
+
+### 映射示例
+```ini
+# frpc.ini
+[nas]
+type = tcp
+local_ip = 127.0.0.1
+local_port = 5000
+remote_port = 15000
+```
+
+### 完整访问链路
+```
+用户浏览器 → https://nas.domain.com
+   ↓
+阿里云 DNS → VPS 公网 IP
+   ↓
+Caddy (443) → reverse_proxy 127.0.0.1:15000
+   ↓
+frps 在 VPS :15000 监听
+   ↓
+frp 隧道
+   ↓
+frpc 在内网 :5000 监听
+   ↓
+NAS Web UI
+```
+
+## Security Considerations
+
+### 认证保护
+- frps 配置 `token` 与 frpc 匹配
+- Caddy 可添加 HTTP Basic Auth
+- 使用非标准端口避免扫描
+
+### 访问控制
+```bash
+# UFW 防火墙限制来源 IP
+sudo ufw allow from <your_home_ip> to any port 60022 proto tcp
+```
+
+### SSH 安全
+```bash
+# 使用公钥认证，禁用密码
+# 编辑 /etc/ssh/sshd_config
+PasswordAuthentication no
+PubkeyAuthentication yes
+```
+
+## Trade-offs
+
+| 优势 | 劣势 |
+|------|------|
+| 无需公网 IP | 依赖 VPS 稳定性 |
+| 支持任意 TCP/UDP 服务 | 增加延迟 |
+| 可绑定独立域名 | 需要维护 frps/frpc |
+| 成本低（月付几美元 VPS） | 安全配置复杂 |
+
+## Related Concepts
+- [[frp]] — 实现内网穿透的工具
+- [[反向代理]] — 内网穿透的上层组件
+- [[TCP 隧道]] — 内网穿透的底层机制
+- [[VPS]] — 内网穿透的公网中转站
+- [[Let's Encrypt]] — 自动 HTTPS 证书
+
+## References
+- frp 官方文档: https://gofrp.org/docs/

wiki/concepts/反向代理.md

@@ -0,0 +1,149 @@
+---
+title: "反向代理"
+type: concept
+aliases: [Reverse Proxy, 反向代理服务器]
+tags: [network, proxy, infrastructure, web-server]
+---
+
+# 反向代理
+
+## Definition
+**反向代理**（Reverse Proxy）是一种服务器架构模式，代理服务器位于客户端与源服务器之间，代表源服务器接收客户端请求，并对请求进行转发、负载均衡或缓存。与正向代理（代理客户端）不同，反向代理对客户端透明，客户端不知道真实服务器的存在。
+
+## Architecture
+
+```
+                    ┌─────────────────────────────────────┐
+                    │           Reverse Proxy              │
+                    │  (Caddy / Nginx / Apache)           │
+                    │                                     │
+  Client Request →  │  example.com → localhost:8080       │
+  (隐藏真实服务器)    │  api.example.com → localhost:3000  │
+                    └──────────────┬──────────────────────┘
+                                   │
+                    ┌──────────────┼──────────────────────┐
+                    │              │                       │
+                    ▼              ▼                       ▼
+              ┌──────────┐ ┌──────────┐          ┌──────────┐
+              │ Server 1 │ │ Server 2 │   ...   │ Server N │
+              │ :8080    │ │ :3000    │          │ :5000    │
+              └──────────┘ └──────────┘          └──────────┘
+```
+
+## Common Use Cases
+
+### 1. 多服务域名复用
+单台 VPS 通过不同子域名代理到不同内网服务：
+```
+nas.ishenwei.online → 127.0.0.1:15000 (NAS)
+n8n.ishenwei.online → 127.0.0.1:15678 (n8n)
+grafana.ishenwei.online → 127.0.0.1:13000 (Grafana)
+```
+
+### 2. 自动 HTTPS
+反向代理自动处理 SSL 证书申请和续期：
+```
+Caddy: 自动从 Let's Encrypt 获取证书
+Nginx: 需要手动配置 certbot
+```
+
+### 3. 负载均衡
+```
+upstream backend {
+    server 192.168.1.10:8080;
+    server 192.168.1.11:8080;
+    server 192.168.1.12:8080;
+}
+```
+
+### 4. 缓存加速
+静态资源缓存，减少源服务器负载：
+```
+location /static/ {
+    proxy_cache_valid 200 60m;
+    proxy_cache_use_stale error timeout updating;
+}
+```
+
+## Comparison of Tools
+
+| 工具 | 语言 | 配置复杂度 | 自动 HTTPS | 内存占用 | 适用场景 |
+|------|------|-----------|------------|----------|---------|
+| **Caddy** | Go | ⭐ 简单 | ✅ 内置 | ~20MB | 个人/小型服务 |
+| **Nginx** | C | ⭐⭐⭐ 中等 | 需配置 | ~5MB | 生产环境 |
+| **Traefik** | Go | ⭐⭐ 简单 | ✅ 内置 | ~50MB | 容器编排 |
+| **Apache** | C | ⭐⭐⭐⭐ 复杂 | 需配置 | ~50MB | 传统企业 |
+
+## Caddy Configuration
+
+### 基本反向代理
+```caddyfile
+example.com {
+    reverse_proxy localhost:8080
+}
+```
+
+### 多域名代理
+```caddyfile
+nas.ishenwei.online {
+    reverse_proxy 127.0.0.1:15000
+}
+
+n8n.ishenwei.online {
+    reverse_proxy 127.0.0.1:15678
+}
+```
+
+### 带路径重写
+```caddyfile
+example.com/api/* {
+    rewrite /api
+    reverse_proxy localhost:3000
+}
+```
+
+### 带负载均衡
+```caddyfile
+example.com {
+    reverse_proxy localhost:8080 localhost:8081 localhost:8082 {
+        lb_policy round_robin
+    }
+}
+```
+
+## Integration with frp
+
+典型架构：frp 隧道 → 反向代理 → 自动 HTTPS
+
+```
+┌──────────────────────────────────────────────────────────┐
+│                        VPS                               │
+│                                                          │
+│  Internet → :443 → Caddy (反向代理) → 127.0.0.1:15000  │
+│                     ↓                                    │
+│                  frps 监听 :15000                        │
+│                     ↓                                    │
+│                  frp 隧道                                 │
+└──────────────────────────────────────────────────────────┘
+                          ↓
+┌──────────────────────────────────────────────────────────┐
+│                     内网机器                              │
+│                                                          │
+│  frpc 连接 VPS:7000                                      │
+│     ↓                                                    │
+│  frpc 映射 localhost:5000 → VPS:15000                    │
+│     ↓                                                    │
+│  NAS Web UI (5000端口)                                   │
+└──────────────────────────────────────────────────────────┘
+```
+
+## Related Concepts
+- [[Caddy]] — 自动 HTTPS 的反向代理工具
+- [[内网穿透]] — 反向代理在内网服务访问中的应用
+- [[TCP 隧道]] — 反向代理的底层机制之一
+- [[Let's Encrypt]] — 自动 HTTPS 证书来源
+- [[负载均衡]] — 反向代理的高级功能
+
+## References
+- Caddy: https://caddyserver.com/docs/
+- Nginx: https://nginx.org/en/docs/

wiki/concepts/桥接网络.md

@@ -0,0 +1,47 @@
+# 桥接网络
+
+## Type
+- Concept
+
+## Definition
+桥接网络（Bridge Network）是 Docker 的默认网络模式，每个容器连接到宿主机上的 `docker0` 网桥，容器之间通过内部 Docker 网络通信，外部流量通过端口映射（-p）访问。
+
+## Mechanism
+
+### 工作原理
+```
+宿主机网络
+    ↓
+docker0 网桥 (172.17.0.1)
+    ├── 容器A (172.17.0.2)  ←→ 容器B (172.17.0.3)
+    └── 容器C (172.17.0.4)
+```
+
+### Docker Compose 配置
+```yaml
+network_mode: bridge  # 使用 Docker 默认桥接网络
+```
+
+### 与 host 网络模式对比
+| 特性 | bridge（桥接） | host（主机） |
+|------|---------------|-------------|
+| 网络命名空间 | 独立 | 共享宿主机 |
+| 端口映射 | ✅ 支持 | ❌ 被忽略 |
+| 网络隔离 | ✅ 容器间隔离 | ❌ 无隔离 |
+| 性能 | 轻微NAT开销 | 最优（直接访问） |
+| 适用场景 | Web服务、数据库 | 网络监控、代理 |
+
+## Key Claims
+- bridge 模式是 Docker 默认网络模式，无需显式配置
+- 容器通过 docker0 网桥与宿主机和互联网通信
+- 端口映射（-p）在 bridge 模式下生效，将容器端口暴露到宿主机
+- 容器间通过 DNS 自动解析服务名通信（同 docker-compose 服务名）
+
+## Relationship to [[端口映射]]
+[[端口映射]] 是桥接网络模式的核心能力——通过 iptables NAT 规则将容器端口转发到宿主机，实现外部访问。
+
+## Relationship to [[LinuxServer.io]]
+LinuxServer.io 所有官方 Docker 镜像默认使用 `network_mode: bridge`，这是其标准化配置模式的一部分，确保端口映射正常工作。
+
+## Sources
+- [[用docker安装transmission]]

wiki/concepts/端口映射.md

@@ -0,0 +1,43 @@
+# 端口映射
+
+## Type
+- Concept
+
+## Definition
+端口映射（Port Mapping）是 Docker 容器网络配置的核心机制，通过 `-p host:container` 语法将容器内部端口暴露到宿主机网络，使得外部流量可以通过宿主机 IP:端口 访问容器内的服务。
+
+## Mechanism
+
+### 基本语法
+```yaml
+ports:
+  - "9091:9091"           # host:container（TCP）
+  - "51413:51413/udp"      # 支持协议指定
+```
+
+### 映射规则
+| 格式 | 说明 | 适用场景 |
+|------|------|---------|
+| `host:container` | 指定宿主机和容器端口 | 生产环境 |
+| `host:container/protocol` | 指定协议（TCP/UDP） | BT下载、语音等 |
+| `:container` | 宿主机随机端口 | 开发环境 |
+| `host-ip:host:container` | 绑定特定IP | 多网卡服务器 |
+
+## Key Claims
+- Docker 通过 iptables 规则在宿主机层面实现端口映射转发
+- 桥接网络（bridge）模式下端口映射生效；host 网络模式下端口映射被忽略
+- 容器重启后端口映射保持（配置持久化在 Docker daemon）
+- 宿主机端口冲突会导致容器启动失败
+
+## Relationship to [[桥接网络]]
+端口映射是 [[桥接网络]] 模式的核心功能：
+- **host 网络模式**：容器直接共享宿主机网络命名空间，端口映射无效（服务直接在宿主机端口监听）
+- **bridge 网络模式**（默认）：容器有独立网络命名空间，通过 NAT 规则实现端口映射访问
+
+## Relationship to [[Transmission]]
+Transmission 依赖端口映射实现两个关键功能：
+- Web UI 访问：`9091:9091` → 用户通过浏览器访问 http://host:9091
+- BT Peer 通信：`51413:51413` + `51413:51413/udp` → 其他BT客户端发现并连接
+
+## Sources
+- [[用docker安装transmission]]