2026 年 11 月 9 日更新

ロードマップ

段ごとに「次へ進んでよい条件」を置いて進めています。 tadori が役に立つかどうかは、実際の案件で人が「確かにそこが漏れていた」と言えるかで決めます。言えなければ、開発をやめて公開を畳みます。

済み

1. 手元で起動する（MVP）

判定の核：下流がある・上流を元にしている・列が埋まっている・人の承認、の 4 種類のルールと、存在しない ID
工程ごとの完了判定（漏れと承認待ち）と、1 件から上下に辿る
コマンド：check（記録を残す）・why・serve・init
画面：リリースまでの残課題（タイムライン／カード）・プロダクト（WBS）・ルールセット・チェックの記録・つながりを辿る・設定・用語
架空の見本の案件

次へ進んでよい条件：手元で起動して、残課題とつながりの画面で状況が読めると言えた → 達成

いま

2. エージェントと一緒に進める

MCP の読む道具：使い方・用語・残課題・漏れ（担当と直し方つき）・つながり・台帳の行を探す
画面の中の専用カーソル：エージェントが人のマウスを使わずに、指す・押す・打つ
デスクトップアプリ（自作の上の帯・ライト／ダーク・案件の切り替え・新しく始める）
md-business・git-qa を開く URL の雛形（漏れの横の md / qa のアイコン）
macOS（Apple シリコン・Intel）と Windows（x64・ARM）のインストーラー
MCP の書く道具：台帳の行・WBS のタスク・ルール・人の表・工程・記録つきのチェック・案件の切り替え（人の承認には口を作らない）
画面を TypeScript で型の検査にかけ、画面のテスト（Playwright）を push のたびに回す
ルールを画面から足す・直す・消す
人単位の 1 日の進行（WBS の変化・台帳の差分・チェックの記録から下書きし、正本へのリンクを付ける）
新しい版の確認と知らせ。server の例外を手元に残し、エージェントが読める
英語と日本語の両方（紹介ページ・README・画面・文・CLI・MCP・使い方）
値で判定するルール：列に書いてよい値（例：結果は OK か NG）と、列名=a|b・列名!=値 での絞り込み（例：試験結果が NG なら不具合票につながっている）
md-business の検証シートを、書き写さずに台帳の行として直接読む・その行を選んだ状態で開く

次

3. 実案件 2 件で回す

実際の案件の中で、既存の指摘を 2 案件分、台帳に起こす（実案件のデータはこのリポジトリには入れない）
check が出した漏れを人が読む。列の形が 2 件目で崩れたら、列を直して見本も直す

止めどころ：人が「確かにそこが漏れていた」と言えたか。言えなければ、開発をやめて公開を畳みます。

その後

4. 広げる

リリース前の確認（tadori before）・同じ漏れの繰り返しを見る（tadori repeat）・ほかの台帳から取り込む（tadori import）
承認のあとに対象の文書が変わったら、承認待ちに戻す（どの版を確かめたかを残す）
複数のプロダクト・プロジェクトの一覧と切り替え
インストーラーのコード署名、Node.js を同梱した版

作らないもの

役に立ちそうでも、tadori は次のものを作りません。

「漏れを埋めた」の判定直ったと認めるのは人。
承認の代行MCP にも人の承認の口は作らない。
割合・点数形だけの行を増やすもとになるため。
外の道具との同期読んだ時点の記録を残し、正本は元の道具に置く。