Sync: add productivity workflow notes

wiki/concepts/ActiveAccountability.md

@@ -0,0 +1,39 @@
+---
+title: "Active Accountability"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-27
+---
+
+# Active Accountability
+
+## Definition
+AI Agent 主动发消息询问用户是否完成习惯，而非等待用户主动打开 App 记录。是区别于传统习惯追踪 App 的核心机制。
+
+## Core Mechanism
+- Agent 主动在预设时间发送签到消息（如早上 7:30 询问晨练）
+- 用户回复确认完成或说明未完成原因
+- Agent 记录数据并调整后续消息策略
+- 整个过程无需用户主动打开任何 App
+
+## Contrast with Passive Tracking
+
+| | Passive Tracking（传统 App） | Active Accountability（本方案） |
+|---|---|---|
+| 触发方式 | 用户主动打开 App | Agent 主动发送消息 |
+| 推送策略 | Push 通知（易被忽略） | 即时消息（直接触达） |
+| 数据录入 | 用户手动记录 | 用户回复确认 |
+| 激励时机 | 视觉激励（成就徽章） | 文字激励（个性化消息） |
+| 持续性 | 一周后放弃率高 | 可持续更长时间 |
+
+## Why It Matters
+真正驱动行为改变的不是 App 的视觉效果，而是有人在关心你、询问你、记住你。Active Accountability 用 AI 实现了"问责伙伴"的每日陪伴感。
+
+## Used In
+- [[Habit Tracker & Accountability Coach]]：核心设计理念
+- [[Custom Morning Brief]]：类似的自主动推送模式
+
+## Related Concepts
+- [[Adaptive Tone]]：Active Accountability 的实现机制
+- [[Check-in Fatigue]]：需要控制频率以避免适得其反

wiki/concepts/AdaptiveTone.md

@@ -0,0 +1,29 @@
+---
+title: "Adaptive Tone"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-27
+---
+
+# Adaptive Tone
+
+## Definition
+AI Agent 根据用户当前表现状态动态调整语气和沟通策略的机制。在习惯追踪场景中，连续打卡时给予鼓励性语言（encouraging），连续错过时转为温和坚持（gently persistent）。
+
+## Core Mechanism
+- **持续成功时**：强化正面激励，引用当前 streak 天数（如"Day 15，不打断！"）
+- **偶尔错过时**：承认现状，不施加内疚感，提醒用户当初目标
+- **连续错过（≥3天）**：发送更长的激励消息，询问是否需要调整目标
+- **无响应时**：2小时内发送一条跟进消息，之后停止（避免骚扰）
+
+## Why It Matters
+静态提醒容易被大脑忽略，个性化且语境感知的消息具有真实激励效果。这是 AI 问责伙伴区别于普通 cron job 的核心差异化因素。
+
+## Used In
+- [[Habit Tracker & Accountability Coach]]：核心差异化机制
+- [[Custom Morning Brief]]：类似的自适应消息策略
+
+## Related Concepts
+- [[Active Accountability]]：依赖 Adaptive Tone 实现
+- [[Streak Tracking]]：为 Adaptive Tone 提供数据依据

wiki/concepts/AgenticWorkflow.md

@@ -0,0 +1,31 @@
+---
+title: "AgenticWorkflow"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+多步骤、长时间运行的 AI Agent 任务执行流程——Agent 能够自主规划、子任务分解、工具调用和环境适应，完成复杂目标而非简单问答。
+
+## Description
+Agentic Workflow 是 AI Agent 从"被动问答"走向"主动执行"的关键范式。它涉及：
+- **自主规划**：Agent 将复杂目标拆解为可执行的子步骤序列
+- **工具调用**：使用代码执行、API、文件系统等工具与环境交互
+- **状态追踪**：维护中间状态，根据反馈调整下一步行动
+- **长时运行**：任务可能持续数小时，涉及数百个子步骤
+
+典型场景：构建完整 Web 应用、深度市场研究、自动化数据管道。
+
+## Related Concepts
+- [[TaskVisibility]]
+- [[ExternalReasoning]]
+- [[PlanMode]]
+
+## Related Entities
+- [[OpenClawWorkspace]]
+
+## Examples
+- [[TodoistTaskManager]]：为 Agentic Workflow 提供任务可视化
+- [[AutonomousProjectManagement]]：多 Agent 协作的复杂项目执行
+- [[OvernightMiniAppBuilder]]：通宵运行的自主应用构建

wiki/concepts/CheckinFatigue.md

@@ -0,0 +1,32 @@
+---
+title: "Check-in Fatigue"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-27
+---
+
+# Check-in Fatigue
+
+## Definition
+当追踪的习惯数量过多时，用户因签到负担过重而开始忽略消息，导致系统失效的现象。这是习惯追踪系统最常见的失败模式之一。
+
+## Threshold
+建议追踪 3-5 个习惯。超过此数量，用户会因签到疲劳开始忽视消息推送。
+
+## Symptoms
+- 用户开始"已读不回"签到提醒
+- 连续漏签但未主动调整目标
+- 用户主动关闭通知或禁用 Agent
+
+## Mitigation
+- 从小处开始（2-3个核心习惯），形成稳定节奏后再扩展
+- 设置优先级，区分"必须追踪"和"可选追踪"
+- Agent 定期询问用户是否需要调整目标数量
+
+## Used In
+- [[Habit Tracker & Accountability Coach]]：关键设计原则
+
+## Related Concepts
+- [[Active Accountability]]：需要控制频率以避免 fatigue
+- [[Adaptive Tone]]：可动态调整签到频率以缓解疲劳

wiki/concepts/Dynamic-Dashboard.md

@@ -1,89 +1,89 @@
----
-title: "Dynamic Dashboard"
-type: concept
-tags: [OpenClaw, Dashboard, Monitoring, Automation]
-sources: [dynamic-dashboard]
-last_updated: 2026-04-22
----
-
-## Definition
-
-**Dynamic Dashboard** 是一种基于 AI Agent 子代理并行执行的多数据源实时监控仪表盘。通过对话式指令驱动子代理同时抓取多个数据源，定时聚合结果并推送告警，实现"免开发、实时、主动"的监控体验。
-
-## 核心洞察
-
-> "用对话式描述替代数周的前端开发，立即获得实时洞察"
-
-## 架构模式
-
-```
-┌─────────────────────────────────────────┐
-│           Dynamic Dashboard             │
-├─────────────────────────────────────────┤
-│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
-│  │Sub-Agent│  │Sub-Agent│  │Sub-Agent│ │
-│  │ GitHub  │  │ Twitter │  │Polymarket│ │
-│  └────┬────┘  └────┬────┘  └────┬────┘ │
-│       │            │            │       │
-│       └────────────┼────────────┘       │
-│                    ▼                    │
-│            ┌─────────────┐              │
-│            │  Aggregator │              │
-│            └──────┬──────┘              │
-│                   ▼                     │
-│  ┌─────────┐  ┌──────────┐  ┌───────┐ │
-│  │ Discord │  │ PostgreSQL│  │ Alert │ │
-│  │ Push    │  │ History   │  │ Check │ │
-│  └─────────┘  └──────────┘  └───────┘ │
-└─────────────────────────────────────────┘
-```
-
-## 核心能力
-
-1. **多数据源并行监控**
-   - GitHub: stars, forks, issues, commits
-   - Social Media: Twitter mentions, Reddit discussions
-   - Markets: Polymarket volume, prediction trends
-   - System: CPU, memory, disk health
-
-2. **子代理并行执行**
-   - 每个数据源由独立子代理处理
-   - 避免顺序轮询导致的阻塞和 API 限流
-   - 聚合器等待所有子代理完成后统一汇总
-
-3. **定时更新与告警**
-   - Cron Job 驱动的定时抓取（默认 15 分钟）
-   - 阈值告警主动推送（Discord/Email/Slack）
-   - 历史数据存储供趋势分析
-
-4. **对话式配置**
-   - 无需编写前端代码
-   - 用自然语言定义监控目标和告警规则
-   - 迭代调整只需修改指令文本
-
-## 典型应用场景
-
-| 场景 | 监控目标 | 推送渠道 |
-|------|----------|----------|
-| 开发者监控 | GitHub stars/commits | Discord |
-| 社媒追踪 | Twitter mentions/sentiment | Discord |
-| 市场情报 | Polymarket volume/trends | Telegram |
-| 系统运维 | CPU/memory/disk | Discord/Email |
-
-## 与静态仪表盘对比
-
-| 维度 | 静态仪表盘 | Dynamic Dashboard |
-|------|------------|-------------------|
-| 数据时效 | 手动刷新/定时拉取 | 持续更新 |
-| 开发成本 | 数周前端开发 | 对话式配置 |
-| 告警机制 | 被动查询 | 主动推送 |
-| 多数据源 | 需分别集成 | 子代理原生并行 |
-
-## Related Concepts
-
-- [[Parallel-Agent-Execution]] — 子代理并行执行是动态仪表盘的核心机制
-- [[Scheduled-Task-Flywheel]] — Cron Job 驱动定时更新
-- [[Alerting]] — 阈值告警机制
-- [[self-healing-home-server]] — 系统健康监控场景
-- [[earnings-tracker]] — 市场数据监控场景
-- [[content-factory]] — 社交媒体监控场景
+---
+title: "Dynamic Dashboard"
+type: concept
+tags: [OpenClaw, Dashboard, Monitoring, Automation]
+sources: [dynamic-dashboard]
+last_updated: 2026-04-27
+---
+
+## Definition
+
+**Dynamic Dashboard** 是一种基于 AI Agent 子代理并行执行的多数据源实时监控仪表盘。通过对话式指令驱动子代理同时抓取多个数据源，定时聚合结果并推送告警，实现"免开发、实时、主动"的监控体验。
+
+## 核心洞察
+
+> "用对话式描述替代数周的前端开发，立即获得实时洞察"
+
+## 架构模式
+
+```
+┌─────────────────────────────────────────┐
+│           Dynamic Dashboard             │
+├─────────────────────────────────────────┤
+│  ┌─────────┐  ┌─────────┐  ┌─────────┐ │
+│  │Sub-Agent│  │Sub-Agent│  │Sub-Agent│ │
+│  │ GitHub  │  │ Twitter │  │Polymarket│ │
+│  └────┬────┘  └────┬────┘  └────┬────┘ │
+│       │            │            │       │
+│       └────────────┼────────────┘       │
+│                    ▼                    │
+│            ┌─────────────┐              │
+│            │  Aggregator │              │
+│            └──────┬──────┘              │
+│                   ▼                     │
+│  ┌─────────┐  ┌──────────┐  ┌───────┐ │
+│  │ Discord │  │ PostgreSQL│  │ Alert │ │
+│  │ Push    │  │ History   │  │ Check │ │
+│  └─────────┘  └──────────┘  └───────┘ │
+└─────────────────────────────────────────┘
+```
+
+## 核心能力
+
+1. **多数据源并行监控**
+   - GitHub: stars, forks, issues, commits
+   - Social Media: Twitter mentions, Reddit discussions
+   - Markets: Polymarket volume, prediction trends
+   - System: CPU, memory, disk health
+
+2. **子代理并行执行**
+   - 每个数据源由独立子代理处理
+   - 避免顺序轮询导致的阻塞和 API 限流
+   - 聚合器等待所有子代理完成后统一汇总
+
+3. **定时更新与告警**
+   - Cron Job 驱动的定时抓取（默认 15 分钟）
+   - 阈值告警主动推送（Discord/Email/Slack）
+   - 历史数据存储供趋势分析
+
+4. **对话式配置**
+   - 无需编写前端代码
+   - 用自然语言定义监控目标和告警规则
+   - 迭代调整只需修改指令文本
+
+## 典型应用场景
+
+| 场景 | 监控目标 | 推送渠道 |
+|------|----------|----------|
+| 开发者监控 | GitHub stars/commits | Discord |
+| 社媒追踪 | Twitter mentions/sentiment | Discord |
+| 市场情报 | Polymarket volume/trends | Telegram |
+| 系统运维 | CPU/memory/disk | Discord/Email |
+
+## 与静态仪表盘对比
+
+| 维度 | 静态仪表盘 | Dynamic Dashboard |
+|------|------------|-------------------|
+| 数据时效 | 手动刷新/定时拉取 | 持续更新 |
+| 开发成本 | 数周前端开发 | 对话式配置 |
+| 告警机制 | 被动查询 | 主动推送 |
+| 多数据源 | 需分别集成 | 子代理原生并行 |
+
+## Related Concepts
+
+- [[Parallel-Agent-Execution]] — 子代理并行执行是动态仪表盘的核心机制
+- [[Scheduled-Task-Flywheel]] — Cron Job 驱动定时更新
+- [[Alerting]] — 阈值告警机制
+- [[self-healing-home-server]] — 系统健康监控场景
+- [[earnings-tracker]] — 市场数据监控场景
+- [[content-factory]] — 社交媒体监控场景

wiki/concepts/ExternalReasoning.md

@@ -0,0 +1,32 @@
+---
+title: "ExternalReasoning"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+将 AI Agent 内部推理过程外化到外部系统（如 Todoist、Notion、数据库）的方法——使 Agent 的思考过程对人类可见，提高 Agent 行为的可观测性和可审计性。
+
+## Description
+传统 AI 系统是"黑箱"——用户只能看到输入和输出，看不到中间推理。ExternalReasoning 反其道而行：
+- 将 Agent 的"思考"（Plan）写入外部系统的任务描述字段
+- 将中间步骤的推理结果追加为评论或日志
+- 保留完整的推理轨迹，供后续回溯和分析
+
+核心价值：
+- **可观测性**：用户实时了解 Agent 在想什么、做什么
+- **可审计性**：记录完整的决策链，便于事后复盘
+- **协同交接**：不同 Agent 或人类可以通过外部系统理解当前状态
+
+## Implementation Patterns
+- 任务描述字段存储 Agent 的 Plan/Strategy
+- 任务评论追加推理过程和步骤完成记录
+- 外部系统（如 Todoist）作为推理过程的"外脑"
+
+## Related Concepts
+- [[TaskVisibility]]
+- [[AgenticWorkflow]]
+
+## Examples
+- [[TodoistTaskManager]]：将 Agent Plan 外化到 Todoist 任务描述，将子步骤日志追加为评论

wiki/concepts/Kanban.md

@@ -2,7 +2,7 @@
 title: "Kanban"
 type: concept
 tags: [project-management, agile]
-sources: [project-state-management]
+sources: [project-state-management, overnight-mini-app-builder]
 last_updated: 2026-04-27
 ---
 

wiki/concepts/LaTeX.md

@@ -0,0 +1,24 @@
+---
+title: "LaTeX"
+type: concept
+tags: []
+sources: [latex-paper-writing]
+last_updated: 2026-04-22
+---
+
+## Aliases
+- LaTeX2ε
+- TeX/LaTeX
+
+## Definition
+LaTeX 是一种基于 TeX 的排版系统，广泛用于学术论文、技术文档和演示文稿的高质量排版。通过 [[Prismer]] 容器，AI Agent 可以无需本地安装 TeX Live 即可完成 LaTeX 写作和即时 PDF 编译。
+
+## Core Properties
+- 支持 pdflatex、xelatex、lualatex 三种编译引擎
+- xelatex 原生支持中文/CJK 字体
+- 支持 BibTeX/BibLaTeX 参考文献管理
+- 提供多种模板：article、IEEE、beamer、中文论文
+
+## Connections
+- [[LaTeX Paper Writing]] ← enables AI-assisted ← [[LaTeX]]
+- [[Prismer-AI]] ← provides runtime for ← [[LaTeX]]

wiki/concepts/Pre-Build-Validation.md

@@ -1,45 +1,46 @@
----
-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]]
+---
+title: "Pre-Build Validation"
+type: concept
+tags: []
+sources: [pre-build-idea-validator]
+last_updated: 2026-04-27
+---
+
+## 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/PreBuildValidation.md

@@ -0,0 +1,40 @@
+---
+title: "PreBuild Validation"
+type: concept
+tags: [decision-gate, ai-agent, pre-build, competition-analysis]
+sources: [pre-build-idea-validator]
+last_updated: 2026-04-27
+---
+
+## Definition
+在 AI Agent 开始编写代码之前，自动进行市场竞争验证的流程机制。通过 [[idea-reality-mcp]] 扫描多个平台，评估赛道饱和度，以分数形式反馈给 Agent 作为决策依据。
+
+## How It Works
+1. **触发**：OpenClaw Agent 接收到任何新项目/功能/工具的构建指令
+2. **扫描**：idea_reality_check() 调用 MCP server 并行查询 GitHub + HN + npm + PyPI + Product Hunt
+3. **评估**：返回 reality_signal 分数（0-100）
+4. **决策门控**：
+   - 高分（>70）→ Agent STOP → 向用户报告竞品 + 询问决策
+   - 中分（30-70）→ 展示 pivot_hints → 建议差异化方向
+   - 低分（<30）→ Agent 直接开始构建
+5. **执行**：始终在写任何代码之前先展示分数和竞品信息
+
+## Key Design Principle
+- **[[Reality Signal]] 作为 Gate**：分数决定是否可以继续，而非人工主动触发
+- **自动化嵌入 Agent Instructions**：Pre-Build Validation 通过 OpenClaw 的 agent instructions 实现，无需每次手动调用
+- **Deep Mode**：重要决策可使用 `depth="deep"` 扫描全部5个数据源（适合黑客松批量验证10个想法）
+
+## Value
+- 防止独立开发者犯最昂贵的错误：**在一个已被解决的问题上花费大量时间**
+- 避免 6+ 小时的编码后才发现 GitHub 上已有 143,000+ 同类仓库的尴尬
+- 将"直觉判断"升级为"数据驱动决策"
+
+## Related Concepts
+- [[Reality Signal]]：PreBuild Validation 的核心量化指标
+- [[Autonomous Project Management]]：与 PreBuild Validation 的张力——自主性边界（高竞争时 Agent 应 STOP vs. Agent 应持续推进）
+- [[Market Research & Product Factory]]：PreBuild Validation 互补——前者挖痛点找方向，后者在动手前验证赛道竞争密度
+
+## Aliases
+- Pre-Build Idea Validation
+- Idea Validation
+- Competition Analysis Gate

wiki/concepts/Reality-Signal.md

@@ -1,40 +1,41 @@
----
-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]]
+---
+title: "Reality-Signal"
+type: concept
+tags: []
+sources: [pre-build-idea-validator]
+last_updated: 2026-04-27
+---
+
+## 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/RealitySignal.md

@@ -0,0 +1,32 @@
+---
+title: "Reality Signal"
+type: concept
+tags: [competition-analysis, decision-gate, ai-agent, market-intelligence]
+sources: [pre-build-idea-validator]
+last_updated: 2026-04-27
+---
+
+## Definition
+竞争饱和度评分（0-100），由 [[idea-reality-mcp]] 基于 GitHub 仓库数量、star 分布、Hacker News 讨论量、npm/PyPI/Product Hunt 数据计算得出。数值越高表示该赛道越拥挤。
+
+## Decision Thresholds
+| Score | Interpretation | Agent Action |
+|-------|---------------|-------------|
+| > 70  | 高竞争（红海） | STOP，展示竞品 + stars，询问用户是否继续/转型/放弃 |
+| 30-70 | 中等竞争 | 展示竞品 + pivot_hints，建议差异化角度 |
+| < 30  | 低竞争（白海） | 直接构建，确认机会空间存在 |
+
+## Core Value
+- 基于**真实数据**（repo counts、star distributions、HN volume）而非 LLM 主观猜测
+- 防止独立开发者在已被成熟产品占领的赛道中浪费生命
+- 低分 = 真正的白海机会 = 单兵创业者最佳切入窗口
+
+## Related Concepts
+- [[PreBuildValidation]]：使用 Reality Signal 作为决策门控的完整流程
+- [[Pre-Build Idea Validator]]：结合 OpenClaw + idea-reality-mcp 的具体实现
+- [[Pivot Direction]]：当高竞争时工具提供的差异化转型建议
+
+## Aliases
+- reality_signal
+- competition score
+- saturation score

wiki/concepts/Startup-MVP-Pipeline.md

@@ -1,37 +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]]
+---
+title: "Startup MVP Pipeline"
+type: concept
+tags: [startup, agentic-ai, mvp, product-building]
+sources: [market-research-product-factory, overnight-mini-app-builder]
+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/StreakTracking.md

@@ -0,0 +1,29 @@
+---
+title: "Streak Tracking"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-27
+---
+
+# Streak Tracking
+
+## Definition
+记录用户在每个习惯上的连续完成天数（streak），并在每次交互中引用当前 streak 数据，以可视化积累成果，形成心理激励。
+
+## Core Mechanism
+- 每个习惯独立追踪当前连续完成天数
+- 数据存储在本地文件（如 `~/habits/log.json`）或数据库
+- 在确认完成的消息中引用 streak（如"Day 12 of morning workouts. Solid."）
+- streak 断裂时重置为 0，并在适当语境下温和提醒
+
+## Why It Matters
+Streak 数据让用户直观看到自己的积累，形成"不想断掉"的心理锚点。配合 Adaptive Tone 后，消息引用 streak 天数具有真实激励效果。
+
+## Used In
+- [[Habit Tracker & Accountability Coach]]：核心数据追踪机制
+- 每周报告中的"当前连续天数"指标
+
+## Related Concepts
+- [[Adaptive Tone]]：依赖 streak 数据动态调整语气
+- [[Weekly Pattern Analysis]]：基于 streak 数据发现行为模式

wiki/concepts/TaskVisibility.md

@@ -0,0 +1,32 @@
+---
+title: "TaskVisibility"
+type: concept
+tags: []
+last_updated: 2026-05-02
+---
+
+## Definition
+AI Agent 任务执行过程的可视化透明度——使人类用户能追踪 Agent 的当前状态、已完成步骤和潜在阻塞。
+
+## Description
+在长时间运行的 Agentic Workflow 中（如构建全栈应用、深度研究），用户往往无法实时了解：
+- Agent 当前正在执行哪一步
+- 已完成哪些子步骤
+- Agent 在哪里卡住或陷入死循环
+
+TaskVisibility 通过外部化 Agent 的内部推理过程来解决这个问题。
+
+## Implementation Patterns
+- **状态分区**：使用不同状态标签区分任务阶段（🟡 In Progress / 🟠 Waiting / 🟢 Done）
+- **计划外化**：将 Agent 的内部 Plan 写入任务描述，供人类审阅
+- **实时日志追加**：以评论形式实时追加子步骤完成记录
+- **停滞检测**：心跳脚本自动检测停滞任务并触发告警
+
+## Related Concepts
+- [[AgenticWorkflow]]
+- [[ExternalReasoning]]
+- [[ProjectStateManagement]]
+
+## Examples
+- [[TodoistTaskManager]]：通过 Todoist 实现 TaskVisibility
+- [[ProjectStateManagement]]：通过事件驱动方案实现任务状态追踪

wiki/concepts/WeeklyPatternAnalysis.md

@@ -0,0 +1,34 @@
+---
+title: "Weekly Pattern Analysis"
+type: concept
+tags: []
+sources: []
+last_updated: 2026-04-27
+---
+
+# Weekly Pattern Analysis
+
+## Definition
+每周日汇总分析本周习惯追踪数据，发现用户行为中的隐藏规律，为下周提供有针对性的建议。
+
+## Core Mechanism
+每周固定时间（建议周日上午 10 点）发送周报，包含：
+- 各习惯完成率
+- 当前连续天数（streaks）
+- 本周最佳日和最差日
+- 一个观察到的行为模式（如"你总是在有早会的日子跳过锻炼"）
+- 下周一条建议
+
+## Why It Matters
+行为模式分析能揭示隐藏的因果关系（如：周三晚睡 → 周四早晨习惯中断），帮助用户提前规划，而非事后被动应对。这是 AI 问责伙伴的独特价值——比人类教练更客观、更持续。
+
+## Data Source
+- [[Streak Tracking]] 的历史数据
+- 每日签到记录（完成/错过时间戳）
+
+## Used In
+- [[Habit Tracker & Accountability Coach]]：周日报表功能
+
+## Related Concepts
+- [[Streak Tracking]]：提供原始数据
+- [[Adaptive Tone]]：根据分析结果调整下周语气策略