自作KanbanをHermes本体へ重ねた失敗
参謀AI構築案 と ADR-013-supervisor-driven-work-system は、実行状態をKanban、長期判断をVault、実装履歴をGitへ分ける構想だった。今回失敗したのは、その分離そのものではない。Kanban固有の完了配送・中断回復・Desktop表示を、Hermesの内部実装にpatchとして重ねたこと。
観測されたこと
- 完了通知の重複や欠落、中断後の再開、human gateと技術retryの区別を直すたびに、gateway・session・deliveryの内部へ変更が増えた。
- それぞれの修正にはtestと完了cardがあった。しかし「個別の障害を塞いだ」ことを、「現在のKanbanが一つの製品として安定している」証拠にしてしまった。
- Hermes v0.20.4への更新では、durable origin delivery patchが
tui_gateway/methods_session.pyの変更に追随できなかった。 - 最終的に更新を通せたのは、独自のsource注入・Kanban delivery patch群をpackage recipeから外し、公式sourceへ戻したときだった。残ったローカル変更は、公式desktop buildのElectron header取得hashを補正する1枚だけ。
どこで失敗したか
拡張ではなくforkになっていた
Kanbanの価値はtaskの正本、依存、実行、判断待ちを扱うことにある。そこへ「この環境だけの配送契約」を足すなら、本来は外部adapterかplugin境界に置くべきだった。
しかし実際には、session resume、gateway server、WebSocket、TUI deliveryの内部を同時に変更した。Hermesが更新されるたび、Kanban機能の改善ではなく、上流の内部構造を読み直すfork維持作業が発生する形になった。
障害修正が設計判断を置き換えた
重複通知やsilent completionは実害があった。だから局所修正は必要だった。ただ、障害ごとにpatchを足すことは、「この責務をHermes本体に持たせ続けるか」という判断を先送りする。
patchが複数の内部モジュールへ広がった時点で、次の障害修正ではなく、独自機能を退役・分離・上流提案のどれにするかを決めるべきだった。そこを「あと一hunk」として扱ったため、更新の価値と維持コストを比較できなくなった。
検証対象が狭すぎた
focused test、dry-run、個別cardの完了は必要だった。でも、運用に必要だったのは次の二つだった。
- 現在のKanbanが人間の仕事を実際に前へ進めているか。
- 次の公式版へ、短い手順で安全に更新できるか。
前者が利用価値、後者が保守可能性。どちらも満たさないなら、局所testが緑でも採用する理由はない。
今回の結論
Hermesは更新可能な基盤として使う。product固有の状態機械や配送保証を、内部patchとして育てない。
独自の仕事の流れが必要なら、まず公式の公開境界で実現する。公開境界に置けないほど内部へ入る必要があるなら、それは小さな拡張ではない。別サービスとして分離するか、価値に見合わない機能として退役する。
この結論は「Kanbanを使わない」ではない。上流Kanbanを使うことと、その内部を自分たちのworkflow専用にforkすることを分ける、ということ。
次に同じ失敗を避ける基準
- upstreamの内部モジュールを複数またぐ変更は、bug fixではなくfork開始として扱う。
- 独自機能には、利用価値の確認方法と、公式更新で止まったときの退役条件を先に置く。
- 完了cardや局所testではなく、実運用の成功と最新stableへの更新可能性を受け入れ条件にする。
- local patchは、公式のpackaging欠陥のように責務が狭く、削除条件が明確なものに限る。