timeline-report

时间线报告

使用 claude-mem 的持久化记忆时间线，生成对项目完整开发历史的全面叙述性分析。

适用场景

当用户提出以下请求时使用：

• “撰写时间线报告”
• “深入了解 [项目]”
• “分析我的项目历史”
• “完整项目报告”
• “总结完整的开发历史”
• “这个项目的故事是什么？”

前提条件

claude-mem worker 必须正在运行。项目必须已记录 claude-mem 观察记录。

解析 worker 端口（在开始时执行一次，并在下方每个 curl 调用中复用 $WORKER_PORT）：

WORKER_PORT="${CLAUDE_MEM_WORKER_PORT:-$(node -e "const fs=require('fs'),p=require('path'),os=require('os');const uid=(typeof process.getuid==='function'?process.getuid():77);const fallback=String(37700+(uid%100));try{const s=JSON.parse(fs.readFileSync(p.join(os.homedir(),'.claude-mem','settings.json'),'utf-8'));process.stdout.write(String(s.CLAUDE_MEM_WORKER_PORT||fallback));}catch{process.stdout.write(fallback);}" 2>/dev/null)}"

此操作会依次使用 CLAUDE_MEM_WORKER_PORT 环境变量、~/.claude-mem/settings.json，若均未设置，则回退到按 UID 计算的默认值 37700 + (uid % 100)——与 worker 自身选择端口的方式一致。这是多账户设置（#2101）以及任何覆盖了默认端口的用户（#2103）所必需的。

工作流

步骤 1：确定项目名称

如果上下文中无法明确判断，请询问用户要分析哪个项目。项目名称通常是项目的目录名（例如，“tokyo”“my-app”）。如果用户说“这个项目”，则使用当前工作目录的目录名。

检测 worktree： 在使用目录名之前，检查当前目录是否为 git worktree。在 worktree 中，数据源是父项目，而不是 worktree 目录本身。运行：

git_dir=$(git rev-parse --git-dir 2>/dev/null)
git_common_dir=$(git rev-parse --git-common-dir 2>/dev/null)
if [ "$git_dir" != "$git_common_dir" ]; then
  # We're in a worktree — resolve the parent project name
  parent_project=$(basename "$(dirname "$git_common_dir")")
  echo "Worktree detected. Parent project: $parent_project"
else
  parent_project=$(basename "$PWD")
fi
echo "$parent_project"

如果检测到 worktree，则使用 $parent_project（父仓库的目录名）作为所有 API 调用中的项目名称。告知用户：“检测到 git worktree。正在使用父项目‘[name]’作为数据源。”

步骤 2：获取完整时间线

使用 Bash 从 claude-mem worker API 获取完整时间线：

curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=PROJECT_NAME&full=true"

这会返回完整的压缩时间线——项目全部历史中的每条观察记录、会话边界和摘要。响应已预先格式化为便于大模型处理的 Markdown。

Token 估算： 完整时间线的大小取决于项目历史记录：

• 小型项目（< 1,000 条观察记录）：约 20-50K tokens
• 中型项目（1,000-10,000 条观察记录）：约 50-300K tokens
• 大型项目（10,000-35,000 条观察记录）：约 300-750K tokens

如果响应为空或返回错误，worker 可能未运行，或者项目名称有误。尝试运行 curl -s "http://localhost:${WORKER_PORT}/api/search?query=*&limit=1"，以确认 worker 正常运行。

步骤 3：估算 Token 数量

继续之前，估算获取到的时间线所含的 token 数量（大致每 4 个字符对应 1 个 token）。向用户报告估算结果：

Timeline fetched: ~X observations, estimated ~Yk tokens.
This analysis will consume approximately Yk input tokens + ~5-10k output tokens.
Proceed? (y/n)

如果时间线超过 100K tokens，继续之前请等待用户确认。

步骤 4：使用子 Agent 进行分析

将完整时间线和以下分析提示词交给 Agent（使用 Task 工具）。将完整时间线作为上下文传递给 Agent。还应指示 Agent 查询 ~/.claude-mem/claude-mem.db 中的 SQLite 数据库，以完成 Token 经济性部分。

Agent 提示词：

You are a technical historian analyzing a software project's complete development timeline from claude-mem's persistent memory system. The timeline below contains every observation, session boundary, and summary recorded across the project's entire history.

You also have access to the claude-mem SQLite database at ~/.claude-mem/claude-mem.db. Use it to run queries for the Token Economics & Memory ROI section. The database has an "observations" table with columns: id, memory_session_id, project, text, type, title, subtitle, facts, narrative, concepts, files_read, files_modified, prompt_number, discovery_tokens, created_at, created_at_epoch, content_hash, generated_by_model, relevance_count, merged_into_project, agent_type, agent_id, metadata.

Write a comprehensive narrative report titled "Journey Into [PROJECT_NAME]" that covers:

## Required Sections

1. **Project Genesis** -- When and how the project started. What were the first commits, the initial vision, the founding technical decisions? What problem was being solved?

2. **Architectural Evolution** -- How did the architecture change over time? What were the major pivots? Why did they happen? Trace the evolution from initial design through each significant restructuring.

3. **Key Breakthroughs** -- Identify the "aha" moments: when a difficult problem was finally solved, when a new approach unlocked progress, when a prototype first worked. These are the observations where the tone shifts from investigation to resolution.

4. **Work Patterns** -- Analyze the rhythm of development. Identify debugging cycles (clusters of bug fixes), feature sprints (rapid observation sequences), refactoring phases (architectural changes without new features), and exploration phases (many discoveries without changes).

5. **Technical Debt** -- Track where shortcuts were taken and when they were paid back. Identify patterns of accumulation (rapid feature work) and resolution (dedicated refactoring sessions).

6. **Challenges and Debugging Sagas** -- The hardest problems encountered. Multi-session debugging efforts, architectural dead-ends that required backtracking, platform-specific issues that took days to resolve.

7. **Memory and Continuity** -- How did persistent memory (claude-mem itself, if applicable) affect the development process? Were there moments where recalled context from prior sessions saved significant time or prevented repeated mistakes?

8. **Token Economics & Memory ROI** -- Quantitative analysis of how memory recall saved work:
   - Query the database directly for these metrics using `sqlite3 ~/.claude-mem/claude-mem.db`
   - Count total discovery_tokens across all observations (the original cost of all work)
   - Count sessions that had context injection available (sessions after the first)
   - Calculate the compression ratio: average discovery_tokens vs average read_tokens per observation
   - Identify the highest-value observations (highest discovery_tokens -- these are the most expensive decisions, bugs, and discoveries that memory prevents re-doing)
   - Identify explicit recall events (observations where narrative mentions "recalled", "from memory", "previous session")
   - Estimate passive recall savings: each session with context injection receives ~50 observations. Use a 30% relevance factor (conservative estimate that 30% of injected context prevents re-work). Savings = sessions_with_context × avg_discovery_value_of_50_obs_window × 0.30
   - Estimate explicit recall savings: ~10K tokens per explicit recall query
   - Calculate net ROI: total_savings / total_read_tokens_invested
   - Present as a table with monthly breakdown
   - Highlight the top 5 most expensive observations by discovery_tokens -- these represent the highest-value memories in the system (architecture decisions, hard bugs, implementation plans that cost 100K+ tokens to produce originally)

   Use these SQL queries as a starting point:
   ```sql
   -- Total discovery tokens
   SELECT SUM(discovery_tokens) FROM observations WHERE project = 'PROJECT_NAME';

   -- Sessions with context available (not the first session)
   SELECT COUNT(DISTINCT memory_session_id) FROM observations WHERE project = 'PROJECT_NAME';

   -- Average tokens per observation
   SELECT AVG(discovery_tokens) as avg_discovery, AVG(LENGTH(title || COALESCE(subtitle,'') || COALESCE(narrative,'') || COALESCE(facts,'')) / 4) as avg_read FROM observations WHERE project = 'PROJECT_NAME' AND discovery_tokens > 0;

   -- Top 5 most expensive observations (highest-value memories)
   SELECT id, title, discovery_tokens FROM observations WHERE project = 'PROJECT_NAME' ORDER BY discovery_tokens DESC LIMIT 5;

   -- Monthly breakdown
   SELECT strftime('%Y-%m', created_at) as month, COUNT(*) as obs, SUM(discovery_tokens) as total_discovery, COUNT(DISTINCT memory_session_id) as sessions FROM observations WHERE project = 'PROJECT_NAME' GROUP BY month ORDER BY month;

   -- Explicit recall events
   SELECT COUNT(*) FROM observations WHERE project = 'PROJECT_NAME' AND (narrative LIKE '%recalled%' OR narrative LIKE '%from memory%' OR narrative LIKE '%previous session%');

9. 时间线统计——定量摘要：

   • 日期范围（从第一条观察记录到最后一条）
   • 观察记录和会话总数
   • 按观察记录类型分类统计（功能、错误修复、发现、决策、变更）
   • 最活跃的日期/周
   • 持续时间最长的调试会话

10. 经验教训与元观察——从完整历史中能发现哪些模式？新开发者阅读时间线后会对这个代码库有什么了解？哪些反复出现的主题或原则指导了开发工作？

写作风格

• 以技术叙事的形式撰写，而非罗列项目符号
• 提及事件时使用具体的观察 ID 和时间戳（例如：“12 月 14 日（#26766），终于找到了根本原因……”）
• 将不同时期的事件串联起来，展示早期决策如何造成后续影响
• 坦诚地描述遇到的困难和走过的弯路，而不只是成功
• 根据项目规模，目标篇幅为 3,000 至 6,000 字
• 适当使用标题、强调和代码引用等 Markdown 格式

重要事项

• 按时间顺序分析整个时间线，不要跳过早期历史
• 寻找叙事脉络：问题 -> 调查 -> 解决方案
• 找出项目方向发生根本性变化的转折点
• 记录对开发过程本身的观察（工具、工作流、协作模式）

以下是完整的项目时间线：

[此处放置时间线内容]

### Step 5: Save the Report

Save the agent's output as a markdown file. Default location:

./journey-into-PROJECT_NAME.md

Or if the user specified a different output path, use that instead.

### Step 6: Report Completion

Tell the user:
- Where the report was saved
- The approximate token cost (input timeline + output report)
- The date range covered
- Number of observations analyzed

## Error Handling

- **Empty timeline:** "No observations found for project 'X'. Check the project name with: `curl -s \"http://localhost:${WORKER_PORT}/api/search?query=*&limit=1\"`"
- **Worker not running:** "The claude-mem worker is not responding on port ${WORKER_PORT}. Start it with your usual method or check `ps aux | grep worker-service`."
- **Timeline too large:** For projects with 50,000+ observations, the timeline may exceed context limits. Suggest using date range filtering: `curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=X&full=true"` -- the current endpoint returns all observations; for extremely large projects, the user may want to analyze in time-windowed segments.

## Example

User: "Write a journey report for the tokyo project"

1. Fetch: `curl -s "http://localhost:${WORKER_PORT}/api/context/inject?project=tokyo&full=true"`
2. Estimate: "Timeline fetched: ~34,722 observations, estimated ~718K tokens. Proceed?"
3. User confirms
4. Deploy analysis agent with full timeline
5. Save to `./journey-into-tokyo.md`
6. Report: "Report saved. Analyzed 34,722 observations spanning Oct 2025 - Mar 2026 (~718K input tokens, ~8K output tokens)."