---
description: TODO / tickets / docs / git history から次の作業候補を見繕い、課題発見や方針決定を半自動でイテレーションする WIP maintainer workflow
model_invokation: false
user_invocable: true
requires: []
---
# Auto Maintain Workflow (WIP)

insomnia を AI maintainer として運用するための半自動 loop。TODO / tickets から「今進められそうな作業」を選ぶだけでなく、課題の発見、設計判断の切り分け、次に人間へ戻すべき問いの整理までを扱う。

これは unattended 自動開発ではない。実装の並列委譲は `multi-agent-workflow`、worktree の機械的作成は `worktree-workflow` に任せる。本 Workflow はその前段として、何を進めるべきか、何をまだ決めるべきかを整理する。

参照:

- `docs/plan/ai-maintainer.md`
- `tickets/auto-maintain-workflow.md`

## 位置づけ

AI maintainer の目的は、コードを書くこと自体ではなく、プロジェクト状態を前に進めることである。

この Workflow は WIP として、以下を行う。

- TODO / tickets / docs / git history を読んで現在地を把握する。
- 実装可能な ticket と、方針決定が必要な ticket を分ける。
- 小さく実装できる候補を提案する。
- 設計相談が必要な論点を人間に戻す。
- 運用上の問題や繰り返し発生する詰まりを report / ticket / workflow 改訂候補として整理する。

## 非目標

現時点では以下をしない。

- 常駐 scheduler として自動実行する。
- 人間の合意なしに新規 ticket を作る。
- 人間の合意なしに既存 ticket を大幅変更する。
- 人間の合意なしに ticket 完了削除を行う。
- push する。
- Workflow を自律生成・自律改訂する。
- scope / permission / history persistence / prompt context 加工原則に関わる判断を勝手に決める。

## 入力として読むもの

必要に応じて以下を読む。

1. `TODO.md`
2. `tickets/*.md`
3. `docs/plan/`
4. `docs/report/`
5. `git log --oneline` / ticket file の git history
6. 既存 worktree / branch 状態
7. 最近の失敗や通知、ユーザーからの観測

TODO と ticket の不整合を見つけたら、勝手に修正せず、まず報告する。ただしユーザーが明示的に「直して」と言った場合は Mode 1 として整理してよい。

## 分類

候補を以下に分ける。

### A. 実装委譲可能

- 要件と完了条件が具体的。
- 影響範囲が限定的。
- test / build で確認できる。
- 大きな設計判断が不要。
- scope を狭く切れる。

この場合は、人間に候補として提示する。人間が実行を許可したら `$user/multi-agent-workflow` に進む。

### B. 方針決定が必要

- 複数の設計方針が自然に導ける。
- protocol / permission / scope / persistence / prompt context に触れる。
- UX の仕様が未確定。
- 既存 ticket の要件が古い。

この場合は、実装せず、決めるべき問いを短く提示する。

### C. ticket 整理が必要

- TODO にあるが ticket がない。
- ticket があるが TODO にない。
- 完了済みに見えるが残っている。
- ticket の前提が変わっている。

この場合は、不整合と修正案を提示する。修正は人間の許可後に行う。

### D. report / workflow 改善候補

- 同じ tool 問題が繰り返し出る。
- Workflow の指示が曖昧で実装 Pod が迷った。
- AI が過剰に Task tool を使うなど、運用上の癖が出た。
- 通知や Pod completion tracking など、開発基盤の不足が観測された。

この場合は、すぐ ticket 化するか、`docs/report/` に観測として残すか、人間に確認する。

## 半自動 iteration

1. 状態把握
   - TODO / tickets / git status を読む。
   - 最近完了した流れや未完了 branch を確認する。

2. 候補抽出
   - 実装可能そうな ticket を 2〜5 件挙げる。
   - correctness / developer experience / user-visible UX / cleanup で分類する。

3. 推奨順位
   - blocking correctness を最優先。
   - 実害が出ている運用問題を次点。
   - 小さく完了できる UX / cleanup を次点。
   - 大きな設計変更は方針相談に回す。

4. 人間への提示
   - 「次に進めるなら X」を1つ推奨する。
   - 理由を短く述べる。
   - 実装委譲する場合の scope / test 方針を添える。

5. 実行への接続
   - 人間が「進めて」と言ったら `$user/multi-agent-workflow` に接続する。
   - worktree 作成は `$user/worktree-workflow` に従う。

## エスカレーション基準

以下では実装に進まず、人間へ戻す。

- ticket の要件から複数の設計方針が自然に導ける。
- 長期構造、crate boundary、protocol、permission、scope、history persistence に触れる。
- prompt context 加工原則に関わる。
- 新 ticket の作成、既存 ticket の大幅変更、ticket 完了削除について合意がない。
- test 不能、再現不能、または作業範囲外の不具合に遭遇した。
- WorkItem / Thread / Lease / maintainer state など、まだ設計中の概念が必要になる。


## まだ固定しないもの

以下は `docs/plan/ai-maintainer.md` の上位設計に残し、本 Workflow では詳細を固定しない。

- WorkItemStore / LeaseStore。
- operation inbox / trial log。
- QA feedback を ticket / review / report のどれに落とすか。
- AI 自身の feedback を Knowledge / report / ticket / workflow 改訂のどれにするか。
- maintainer doctor。
- reviewer Pod の評価基準の機械化。
