Skip to content

The Time Graph

開発の第四次元

従来のバージョン管理はスナップショットを提供します。Time Graph は生きたタイムラインを提供します — すべての決定、すべての変更、すべての可能性が、探索可能な多次元空間に同時に存在します。

線形履歴の問題

Git やその他の VCS ツールは、フラットで線形の進行を示します:

  • コミットは単なる差分
  • コンテキストはコミットメッセージで失われる
  • 決定は追跡されない
  • 代替案は消える
  • デバッグは考古学を意味する

Time Graph は、これを根本的により強力なものに変換します。

多次元コードベース

ブランチを超えて

従来:

main ──●──●──●──●──● (now)

Time Graph:

         ┌─ Attempt 1 ─── Failed ────┐
         │                           │
main ────┼─ Attempt 2 ─── Success ───┼─── Merged ─── Future
         │                           │
         └─ Attempt 3 ─── Partial ───┘

              └── 各試行には以下が含まれます:
                  - 完全なコンテキスト
                  - 決定の根拠
                  - パフォーマンスメトリクス
                  - チームディスカッション
                  - 代替アプローチ

コア機能

1. 決定ノード

すべてのアーキテクチャ決定が、永続的でクエリ可能なノードになります:

yaml
node: '2024-01-15-14:30:00'
type: 'architectural-decision'
title: 'Switch from REST to GraphQL'
context:
  problem: 'N+1 queries killing mobile performance'
  constraints:
    - 'Must maintain backward compatibility'
    - 'Cannot increase backend complexity'
  options-considered:
    - REST-optimization: 'Rejected: Too complex'
    - GraphQL: 'Accepted: Solves N+1, good tooling'
    - gRPC: 'Rejected: Client compatibility issues'
participants: ['alice', 'bob', 'charlie']
outcome: 'Implemented GraphQL gateway'
metrics:
  before: 'Avg response: 2.3s'
  after: 'Avg response: 0.4s'

2. 因果連鎖

時間を超えた原因と結果を追跡:

ユーザーレポート: "App crashes on login"

Time Graph は逆方向にトレース...

3時間前: "Login API response format changed"

6時間前: "Backend validation updated"

2日前: "Security patch applied"
    ← 根本原因発見

3. 並列タイムライン

中断なしに「もしも」シナリオを探索:

yaml
timeline-alpha:
  approach: 'Microservices'
  status: 'Testing in staging'
  metrics: 'Good isolation, high complexity'

timeline-beta:
  approach: 'Modular monolith'
  status: 'Testing in staging'
  metrics: 'Simple deployment, harder to scale'

decision-point: '2024-02-01'
chosen: 'timeline-beta'
reason: 'Complexity not justified for our scale'

4. 知識保存

コンテキストを二度と失わない:

  • なぜその API を非推奨にしたのか?
  • 誰がこのアーキテクチャを決定したのか?
  • 何を検討した代替案か?
  • いつパフォーマンスが低下したのか?
  • どのように以前にこれを解決したのか?

実用的なアプリケーション

時間を超えたデバッグ

bash
# バグが導入された時期を見つける
hatcher time-graph bisect --bad HEAD --good v1.0.0 --test "npm test"

# 重要な期間に何が変更されたかを確認
hatcher time-graph diff --from "last-working" --to "first-broken"

# クラッシュ時の正確な状態を再生
hatcher time-graph replay --timestamp "2024-01-15T14:30:00" --with-state

アーキテクチャの進化

システムがどのように進化したかを追跡:

yaml
query: 'Show database evolution'
result:
  2021: 'SQLite - MVP phase'
  2022: 'PostgreSQL - Scaling up'
  2023: 'PostgreSQL + Redis - Caching layer'
  2024: 'PostgreSQL + Redis + Elasticsearch - Search features'

Each transition includes:
  - Migration strategies
  - Rollback plans
  - Performance benchmarks
  - Lessons learned

チーム知識

Time Graph は人間の知性を捕捉します:

yaml
query: 'Who knows about payment integration?'
result:
  experts:
    - alice: 'Implemented Stripe integration'
    - bob: 'Debugged webhook issues'
  decisions:
    - 'Chose Stripe over PayPal (2023-03-15)'
    - 'Added idempotency keys (2023-06-20)'
  problems-solved:
    - 'Double charging bug (2023-07-10)'
    - 'Webhook replay issue (2023-09-05)'

HATs との統合

Time Graph はすべての HAT を駆動します:

  • Code HAT: コード進化パターンを表示
  • Gen HAT: 生成履歴を追跡
  • Visual HAT: ビジュアル回帰タイムライン
  • Time Graph HAT: 直接タイムライン操作

哲学的シフト

状態から履歴へ

従来の開発は状態で考えます:

  • 現在のコード
  • 現在のバグ
  • 現在の機能

Time Graph 思考は履歴を受け入れます:

  • どのようにここに到達したか
  • なぜ選択をしたか
  • 何を学んだか
  • どこへ向かっているか

個人から集団へ

Time Graph は、個人の知識を集団の知性に変換します:

  • 決定は自動的に文書化される
  • コンテキストは永遠に保存される
  • パターンは履歴から現れる
  • ミスは教訓になる

開発の未来

Time Graph を使用すると、以下のことができます:

パターンから学ぶ

yaml
pattern-detected: 'Performance degrades after deploys'
analysis:
  - 'Cache not warming properly'
  - 'Happens every 3rd deploy on average'
  - 'Solution applied 5 times before'
recommendation: 'Implement cache warmup in CD pipeline'

問題を予測

yaml
prediction: 'Database will hit connection limit'
based-on:
  - 'Current growth rate: 10% weekly'
  - 'Historical pattern: Issues at 80% capacity'
  - 'Time to limit: ~3 weeks'
action: 'Scale connection pool now'

決定を最適化

yaml
similar-decision: 'Choosing message queue'
previous-instances:
  - 2023: 'Chose RabbitMQ - worked well'
  - 2022: 'Chose Kafka - over-engineered'
  - 2021: 'Chose Redis Pub/Sub - outgrew it'
recommendation: 'RabbitMQ fits your scale'

時間革命

Time Graph は単なる機能ではありません — それはコードについて考える方法の根本的なシフトです:

  • コードは何であるかだけでなく、どのようになったか
  • バグは謎ではなく、追跡可能な効果
  • 決定は失われず、永続的にアクセス可能
  • 知識はサイロ化されず、集合的に共有される

コードベースには豊かな履歴があります。Time Graph は、それをナビゲート可能で、クエリ可能で、学習可能にします。

コードのタイムラインをマスター

git 履歴をナビゲート可能でインテリジェントな知識ベースに変換