Art4/continuous-refactoring

Refactor Scan (リファクタスキャン)

検出するが、決して書き込まない。 次に何に取り組むべきかを提案し、前回のパス以降に自然に解決されたものにも気づく——Issueを作成することはなく、結果を決定することもありません。refactor-design が選択されたものに対してIssueを作成し、refactor-learn がこのスキルが検出したものに対してアクションを実行します。

プロセス

1. 前提条件をチェック

• Gitリポジトリがない → パスを停止し、報告し、何も提案しない。
• 5つ以上の refactor:candidate Issueがオープン → 停止し、新しいものを提案しない。既存の作業を先に完了させる。

2. 保留中の作業を最初に再開

リファクタリングノートの bookkeeping.md にある Pending candidates フィールド（skills/continuous-refactoring/references/refactoring-bookkeeping.md）を読み取ります。これにIssueが指定されている場合、以前のパスで refactor-design がIssueを作成したが、マージリクエストに至る前に中断されたことを意味します。そのIssueのみを提案し、停止します。保留中の作業を完了させることが、新しい作業を提案するよりも優先されます。

3. クローズ/マージされた記憶状態を検出

記憶セットを取得します。docs/agents/issue-tracker.md にネイティブラベルトラッカー（GitHub、GitLab）が指定されている場合 → オープンな refactor:candidate Issueそれぞれについて、トラッカー自身のネイティブなIssue↔クローズPR相互参照（refactor-implement のステップ5で配信MRに既に追加されている Closes #<n>）を介してリンクされたプルリクエストに解決します。リンクされたPRがまだないIssueは、このステップでは調整するものがありません。それ以外の場合 → リファクタリングノートの merge-requests.md のすべてのエントリ。それぞれについて、外部トラッカー/gitをチェックします：MRはまだオープンか、Issueはまだオープンか？

gh/glab（または他のフォージAPI/トークン）が利用できない場合 → このステップをスキップする代わりに、gitのみによる調整にフォールバックします（ここで gh/glab のインストールを試みないでください。それらの不在をこのフォールバックのトリガーとして正確に扱います）：skills/refactor-scan/references/git-only-reconciliation.md。リモートがまったくない場合（git remote -v が空） → 同じファイルのローカルのみのバリアント——人間がローカルでのみ作業し、opening-a-merge-request.md の「フォージ/リモートなし」に従って、記憶された候補がマージまたは拒否された可能性があります。

• マージされた → 発見：配信済み。

• マージされずにクローズ → 発見：拒否——クローズ時のコメントに、メンテナーによる構造的な理由（スコープ外のマテリアル）が記載されているかどうかを記録します。

• まだオープンで、レビュー担当者のアクティビティ（レビューまたはコメント）がブランチの最終コミットより新しい → 再開候補であり、発見ではありません。まだ誰も何も決定しておらず、もう一度確認が必要なだけです。APIアクセスが利用可能 → また、タイムスタンプとともに実際のレビューステータスも読み取ります（gh pr view <n> --json reviews,reviewDecision または同等のもの）。「何かが変更された」というだけで停止しないでください。

  • CHANGES_REQUESTED、未対応（レビューよりも新しいコミットがない） → まだ再開候補ですが、ブランチだけでなく、レビューのコメント/本文も一緒に引き渡します。refactor-implement のステップ1は、その特定のフィードバックを読み取り、対処します。最初からブランチを再調査するだけではありません。
  • コメント、またはブロックするフィードバックのない APPROVED レビュー → 既存の一般的な再開候補処理。他に添付するものはありません。

  refactor-implement に直接引き渡します（refactor-prioritize/refactor-design をスキップ）。これは既に設計とオープンMRを持っています。修正ループのみが適用されます。refactor-implement のステップ1は既に既存のブランチの再開をサポートしています。APIアクセスがない（gitのみのフォールバック） → git-only-reconciliation.md ですでに文書化されているように、レビューステータスは利用できません。この改善はそこでは適用されません。

• まだオープンで、何も変更されていない → 発見なし。

また、リファクタリングノートの out-of-scope/<node>.md にあるすべてのエントリで、**Blocked by:** PHP >= X.Y 条件を指定しているものをチェックします（tooling_tree.py の detect_nodes() は実行時にこれを直接報告します。手動の場合は、ターゲットの現在の composer.json の require.php/config.platform.php と比較します）。ターゲットの現在のPHPバージョンが条件を満たしている場合、発見となります：この拒否は取り消されます。Blocked by: フィールドがない、または条件がまだ満たされていない場合 → 発見にはなりません。

すべての発見を refactor-learn に引き渡します。このスキルは気づくだけで、何かを done/wontfix とマークしたり、リファクタリングノートの out-of-scope/ 自体に書き込んだりすることはありません。

3b. 外部ラベル付けされた候補を検出

APIアクセスが利用可能（gitのみのフォールバックではない） → また、すでに考慮されていないオープンな refactor:candidate Issueをクエリします。ステップ2の Pending candidates エントリでも、ステップ3の記憶セット（リンクされたプルリクエストを持つIssueはすでに進行中）でもないものです。残っているのは、人間（または別のプロセス）が直接ラベル付けした候補で、このループが設計も実装もしたことがないものです。通常の運用では、スイート自身の候補は常にこれら2つのいずれかでカバーされるため、「私たちの」ものと「他の誰かの」ものを区別するために追加の処理は必要ありません。それぞれを 提案 として引き渡します。ステップ4のツールツリーからの提案が加わる同じリストです。refactor-prioritize は通常の要素に基づいて他のすべてと一緒にランク付けします。存在するだけで優先順位が上がることはありません。APIアクセスがない（gitのみのフォールバック） → このステップは完全にスキップします。gitだけではラベルでIssueを列挙できません。

4. ツールツリーノードを提案

ステップ2ですでに保留中の候補を提案している場合はスキップします。

python3 skills/refactor-scan/references/tooling_tree.py <target-repo> を実行し、JSONの next フィールドを読み取ります。実際の、現在ブロックされていないセットであり、拒否されたノード（リファクタリングノートの out-of-scope/<node>.md に既存のエントリがあるもの）は既に除外されています。エントリ数に関係なく、そのまま取得します。roadmap ではありません（将来のシミュレーションであり、今日の実際のオプションではありません）。また withheld を読み取ります。これはそうでなければ next に含まれるが、未決定の推奨親を待っているノードです。各エントリはどの親を待っているかを示します。python3 がない、または許可されていない場合 → skills/refactor-scan/references/tree-walk-prompt.md のプロンプト（{N}=all）を使用してサブエージェントをディスパッチします。サブエージェントは手動で同じツリードキュメントをウォークします（最初にリファクタリングノートの bookkeeping.md の Fulfilled nodes を読み、キャッシュされた状態の再導出をスキップします。out-of-scopeエントリがあるノードはスキップします）。サブエージェントメカニズムがない場合 → その手順をインラインで自分で実行します。

• 通常のツールノード（loop-config、および言語特化ノード、例：skills/refactor-scan/references/php-tooling-tree.md）—— 名前（生のスラッグではなく）で提案されます。それぞれは既にツリードキュメントで完全に指定されています。
• structural-scan —— それに対する resolved エッジを持つすべてのノードが解決された（履行された、またはリファクタリングノートの out-of-scope/ のもとで明示的に拒否された）場合にのみ提案されます：editorconfig（汎用ルート）、およびアクティブな言語特化自身の集約ノード（PHP：php-structural-scan）。php-structural-scan 自身も、自身の解決済み親すべてが解決されると解決されます（skills/refactor-scan/references/tooling-tree.md）。この方法で提案されるのは structural-scan のみです。php-structural-scan は純粋な配管であり、候補になることはありません。提案することは単に名前を挙げることです。コードベースのウォークは refactor-design で行われ、実際に選択されたノードに対してのみ行われます。
• 認識された言語ツリーがない: structural-scan は依然として editorconfig（汎用ルートのリーフ）を待ちます。言語固有のツリーが適用されないからといって、すぐに提案可能になるわけではありません。

出力

オーケストレーターによって、平易に引き渡されます：

• 前提条件によってパスが停止された場合、どれが停止したか。このパスでは以下のものは適用されません。
• 発見（空の場合もある。→ refactor-learn。
• 再開候補（検出された場合。→ refactor-implement に直接、refactor-prioritize/refactor-design をバイパス。
• 提案 —— 保留中の候補のみ、または現在ブロック解除されているすべてのノードの名前（スラッグではなく、上限なし）に加えて、ステップ3bからの外部ラベル付けされた候補、またはなし → refactor-prioritize。現在ブロック解除されているすべてのノード（必要な親が満たされ、拒否されておらず、推奨される親がすべて決定済み）。優先度によって切り詰められたサブセットではありません。それに加えて、すべての withheld ノードと、それが待機している親（例：「Rector: Type Coverage Set — waiting on: PHP CS Fixer」）を名前を挙げます。

完了基準

発見（ある場合）は refactor-learn へ、再開候補（ある場合）は refactor-implement へ直接、提案（ある場合）は refactor-prioritize へ引き渡される。または、前提条件によってパスが停止され、レポートにその旨が記載される。同じリストに structural-scan を超えるエントリとノードが混在することは決してありません。