feature-tracker-mcp

プロジェクトに依存しない機能・意思決定トラッカー。一人が複数のAIコーディングセッションを同時に指揮しており、その人がボトルネックになっているケースのために作られた。

このツールが解決するのは「機能を追跡すること」ではない。複数のトラックが進行中で、各セッションは互いに見えず、意思決定が絶えず発生し、すべてを読むのが仕事になっている、という状況だ。それらの意思決定の大半は平凡で委任可能なものだ。本当に自分が決めるべきものはごく一部。今日、それらを分離する仕組みがないため、すべてを読むことになる。

これがその仕組みだ。

目次

• 役割

• 現在存在するもの

• 形

• 動詞

• モード

• 背骨：プロジェクトごとに1つのデータベース

• カテゴリ

• ゲート：承認待ちキュー

• カウントと収束

• 停止条件

• チェックポイント、一時停止、要約

• なぜgitに入れないのか

• 何がこれを壊すか

• 構築順序

役割

この分割の要点は、2行目が現在は人間の仕事であり、そのほとんどが人間である必要がない、ということだ。

形

flowchart TD
    Ideate["/ideate — dialog"] -->|features as they are invented| DB[("project database")]
    Session["coding session (Claude)"] -->|every substantive turn| Capture{"implies a feature,<br/>guardrail, schema change<br/>or risk?"}
    Capture -->|yes, and not a duplicate| DB
    Capture -->|no| Session
    DB --> PM["ChatGPT as manager"]
    PM -->|next task, in priority order| Session
    PM -->|mundane decisions| PM
    PM -->|architectural · install · spend| Gate[["gate queue"]]
    Gate -->|approve / alter / reject| You([You])
    You -->|proceed| Session
    DB --> Table["/tracker-table · /standup"]
    Table --> You

2つの特性が機能する：データベースが状態であるため、モデルの記憶に依存しない。そしてゲートがブロックするため、「はい、進めてよい」はメッセージではなく仕組みになる。あなたがその場にいて受け取らなければならないものではない。

現在存在するもの

正直な内訳。この文書の残りは、部分的にしか構築されていないシステムを指定しているからだ。

現在動作中 — 8つのMCPツール、実データベースに対してエンドツーエンドで検証済み：

仕様はあるが未構築： 次のセクションのすべてのスラッシュコマンド、継続的キャプチャ、実行ループ、データベースからマークダウントラッカーを再生成するジェネレーター。

実際のプロジェクトで検証済み。 既存の387行のマークダウントラッカーから75の機能をインポートし、すべてのIDを保持 — DIP-16、GLG-1、UA-11 などは、コミットメッセージやワークツリー名で引用されているため、再割り当てするとその履歴が孤立する。カテゴリカウンターはインポートされた最大IDを超えて進められ、既に使用中のIDが再発行されることはない。

動詞

それぞれがスキルであり、スラッシュコマンドでもある。これらはまだ構築されていない — 上記のツールの上に意図されたインターフェースだ。

/standup、/tracker-table、/gates は読み取り専用で、作業のターンを消費しない。

モード

アイデア出し。 副産物としてバックログが埋まるダイアログ。機能が発明されるたびに即座にデータベースに提案され、それぞれが同意または変更のために提示される — 何も黙って記録されることはない。これがキューを満たす方法だ。

実行。 カテゴリの機能が優先順位順に次々と完了まで駆動される。ChatGPTが次の項目を選択し、コーディングセッションに指示し、返ってきたものをレビューし、受け入れるか、もう一度送り返す。

継続的キャプチャ。 平凡な部分であり、リストが真実であり続ける理由だ。どのセッションでも、実質的なターンごとに、それが何を意味するかが調べられる：新しいテーブル、ガードレール、CHECK制約、緩和が必要なリスク、誰も名前を付けなかったサブ機能。それぞれが提案された行になる。代替案は今日起こっていることだ：一度言及され、スクロールして消え、後で高くつく再発見が待っている。

キャプチャは、ファイルを変更したターンまたは結論に達したターンで実行される。ほとんどのターンは何も意味しない。すべてのターンで実行すると、誰も読まないバックログができる。

背骨：プロジェクトごとに1つのデータベース

各プロジェクトには独自のPostgresデータベースが与えられ、初回使用時に作成され、プロジェクトのgitリモートから名前が付けられる（そのため、同じプロジェクトのすべてのワークツリーとすべてのクローンが同じトラッカーに一致する）。

kind は feature、guardrail、schema、risk、mitigation のいずれか。status は proposed → agreed → in_progress → done、または dropped と進む。

IDはデータベースによってアトミックに割り当てられる。 これは細部ではない — 実際に繰り返し発生するバグの修正だ。2つのセッションが独立してファイルを読み、次の空き番号を見て両方がそれを取得すると、重複したマイグレーション016や衝突するイシュー番号が発生する。トランザクション内でインクリメントされるカウンターは、それを構造的に不可能にする。

すべてのイベントはgitコミット、ブランチ、ツリーを記録する。 書き換えられたコミットに対して提案された機能は、HEADに対して提案されたものとは異なる主張であり、スタンプがなければ後で誰も違いを判断できない。

カテゴリ

カテゴリは「トラック」という非公式な概念を置き換え、機能が記録される際に生成され、事前に設定されるものではない。新しいカテゴリの下で機能を提案すると、独自のIDプレフィックスとカウンターとともに作成される — そのためDIP-17とGLG-1は、衝突も中央管理もなく共存できる。

ゲート：承認待ちキュー

ゲートとは、作業セッションが単独で下してはならない決定だ。

ゲートを上げると、それを上げたセッションがブロックされる。ゲートは一箇所にキューされ、あなたが承認、変更、または拒否すると、セッションは再開する。これが「これには$40かかるけど、それでいい？」というメッセージを、あなたが待っていなければならなかったものから、待つキュー項目に変える。

カウントと収束

進捗は2つの動きとして報告され、比率としては決して報告されない：

3/14  ->  5/16     +2 agreed, +2 surfaced

分子は合意であり、収束を測る。分母が増えるのは健全だ — 新しい項目は、実際には以前から存在していたが表明されていなかった不一致が見つかったことを意味する。

パーセンテージはそれを逆転させる。12/16 -> 12/20 は75% -> 60%と読め、低下に見えるが、何も後退しておらず、2つの本物の問題が名前付けられただけだ。単一の比率は、システムが生み出すために存在する行動をまさに罰するため、決して表示されない。

停止条件

停滞は分子だけで判断される。何も合意されないまま項目が浮上するのは循環であり、それを進捗として報告するのは午後を無駄にする最も簡単な方法だ。

チェックポイント、一時停止、要約

2ターンごとにループは停止して報告する：

NEEDS YOU (1)
  · Is the target "one dollar per Track" or "one opportunity live"?
    Not a fact — it is what you are optimising.

HANDLED (6 of 7 tracks)      +2 agreed, +2 surfaced
  filter-decide   uncommitted migration 020 — no collision with other tracks
  layer-lift      6 behind main, clean rebase available
  ...

一時停止と言えば、チェックポイントを待たずに即座に要約が得られる。許可した以上に無人で実行されることはない — 自律性は2ターンから始まり、実績を積んで初めて延長される。

なぜgitに入れないのか

トラッカーは以前はマークダウンファイルだった。最近の1週間で、並行ワークツリーからのコミットが115件あり、履歴には手動で解決した番号衝突が含まれている。バージョン管理下の単一ファイルは、人間の書き込み速度でもすでに競合点だ。複数のセッションからの自動化されたターンごとの書き込みを追加すれば、使えなくなるだろう。

したがって、データベースが正規であり、マークダウンは生成された出力となり、要求に応じて再生成され、バージョン管理から除外される。

意図的に受け入れるべき結果：git履歴が監査証跡だった。feature_eventはそれを置き換える — 追記専用で、アクターとコミットが刻印される — そして、その置き換えは必須条件であって、ぜいたく品ではない。さもなければ、マージコンフリクトは記憶喪失と引き換えになる。

マークダウンファイルを正本として指定するプロジェクトレベルの指示は、すべて同じ変更の中で書き直さなければならない。セッションはそれらの指示に従う。指示の1つでも古いファイルを指したままにしておくと、セッションは誰も読まないものに書き続けることになる。

何がそれを壊すのか

提案スパム。 複数のトラックにまたがるターンごとのキャプチャは、価値の低い行を何百件も生成し得る。そうなると、トランスクリプトの代わりにバックログを読むことになる — 同じ問題が着替えただけだ。基準は明確である：記録するのは、そうしなければ失われるもの、実行可能なもの、そしてまだカバーされていないものだけだ。重複排除は必須である。なぜなら、2つのセッションが同じ欠落した制約に独立して気づくのは、例外的なケースではなく通常のケースだからだ。

間違ったツリーを読む。 ワークツリーは独立したチェックアウトである。セッションを間違ったツリーに向けると、ファイルが存在しない、変更が適用されていないと報告される — 自信を持って、しかも設定ミスではなくコードに関する指摘として読める形で。すべての操作は読み取ったツリーを記録するので、誰かがそれに基づいて行動する前に不一致が見える。

計算する代わりに語るマネージャー。 件数はデータベースから計算され、真実でないことについて雄弁になることはできない。モデルが書いた要約は雄弁になれる。両者が食い違う場合、テーブルが勝つ。

注意を追い越す自律性。 複合するエラーは、誰も読んでいないときに最も速く高くつく。ゲートとチェックポイントはこのために存在し、デフォルトの間隔は意図的に短く設定されている。

構築順序

1. category、feature、feature_event、gate；プロジェクトごとのデータベース作成；アトミックなID割り当て

2. MCPツール: propose、list、update、table、history、gate raise/list/decide

3. 基準と重複排除を備えた継続的キャプチャ、さらに同意または変更（agree-or-alter）のレビューキュー

4. トラック横断の/standup、未コミットの作業を含む — コミットだけでは、作業が実際にある場所を見落とす

5. セッションをブロックするゲート

6. /ideate

7. カテゴリを優先順位順に完了まで駆動する実行ループ