Art4/continuous-refactoring

Refactor Scan

Erkenne, schreibe nie. Schlägt vor, woran als nächstes gearbeitet werden könnte, und bemerkt, was sich seit dem letzten Durchlauf bereits von selbst gelöst hat – erstellt niemals ein Issue, entscheidet niemals über ein Ergebnis. refactor-design erstellt Issues für das, was ausgewählt wird; refactor-learn handelt auf Basis dessen, was dieser Skill erkennt.

Prozess

1. Voraussetzungen prüfen

• Kein Git-Repository → Durchlauf stoppen, melden, nichts vorschlagen.
• Fünf oder mehr offene refactor:candidate-Issues → stoppen, nichts Neues vorschlagen; vorhandene Arbeit zuerst erledigen lassen.

2. Zuerst ausstehende Arbeit fortsetzen

Das Feld Pending candidates in den Refactoring-Notizen (skills/continuous-refactoring/references/refactoring-bookkeeping.md) lesen. Wenn es ein Issue benennt, hat ein vorheriger Durchlauf von refactor-design es erstellt, wurde aber unterbrochen, bevor ein Merge-Request folgte. Genau dieses Issue vorschlagen und stoppen – das Abschließen ausstehender Arbeit hat Vorrang vor dem Vorschlagen neuer Arbeit.

3. Geschlossene/zusammengeführte gemerkte Zustände erkennen

Das gemerkte Set abrufen – docs/agents/issue-tracker.md benennt einen nativen Label-Tracker (GitHub, GitLab) → jedes offene refactor:candidate-Issue, aufgelöst zu seinem verknüpften Pull-Request über die native Issue↔Closing-PR-Querverweis des Trackers (der Closes #<n>-refactor-implement Schritt 5 fügt dies bereits einem liefernden MR hinzu); ein Issue ohne verknüpften PR hat in diesem Schritt nichts abzugleichen. Andernfalls → jeder Eintrag in den merge-requests.md der Refactoring-Notizen. Für jeden Eintrag den externen Tracker/Git prüfen: Ist der MR noch offen? Ist das Issue noch offen?

Kein gh/glab (oder andere Forge-API/-Token) verfügbar → auf reine Git-Abstimmung zurückfallen, anstatt diesen Schritt zu überspringen (niemals versuchen, gh/glab hier zu installieren – ihr Fehlen als genau diesen Auslöser für den Fallback behandeln): skills/refactor-scan/references/git-only-reconciliation.md. Kein Remote vorhanden (git remote -v leer) → die lokale Variante derselben Datei – ein gemerkter Kandidat könnte von einem Menschen rein lokal zusammengeführt oder abgelehnt worden sein, gemäß opening-a-merge-request.md's „Keine Forge/Remote verfügbar”.

• Zusammengeführt → ein Fund: ausgeliefert.

• Ohne Merge geschlossen → ein Fund: abgelehnt – vermerken, ob die Schließungskommentare einen strukturellen Grund des Maintainers nennen (außerhalb des Rahmens) oder nicht.

• Noch offen, mit neuerer Reviewer-Aktivität (Review oder Kommentar) als der letzte Commit des Branches → ein Wiederaufnahme-Kandidat, kein Fund – niemand hat eine Entscheidung getroffen, es braucht nur einen weiteren Blick. API-Zugriff verfügbar → auch den tatsächlichen Review-Status zusammen mit dem Zeitstempel lesen (gh pr view <n> --json reviews,reviewDecision oder gleichwertig) – nicht bei „irgendwas hat sich geändert” stehenbleiben:

  • CHANGES_REQUESTED, unbehandelt (kein neuerer Commit als der Review) → immer noch ein Wiederaufnahme-Kandidat, aber die Kommentare/den Text des Reviews selbst mit übergeben, nicht nur den Branch – refactor-implement Schritt 1 liest und adressiert dieses spezifische Feedback, nicht nur den Branch von Grund auf neu.
  • Ein Kommentar oder ein APPROVED-Review ohne blockierendes Feedback → die vorhandene allgemeine Wiederaufnahme-Kandidaten-Behandlung; nichts weiter anhängen.

  Dies auf die gleiche Weise weitergeben wie Schritt 2 einen Pending candidates-Eintrag weitergibt: direkt an refactor-implement, unter Umgehung von refactor-prioritize/refactor-design (es hat bereits ein Design und einen offenen MR; nur die Fix-Schleife greift – refactor-implement Schritt 1 unterstützt bereits das Fortsetzen eines bestehenden Branches). Kein API-Zugriff (reine Git-Abstimmung) → der Review-Status bleibt nicht verfügbar, wie bereits in git-only-reconciliation.md dokumentiert; diese Verfeinerung gilt dort nicht.

• Noch offen, nichts geändert → kein Fund.

  Auch jeden Eintrag in den out-of-scope/<node>.md der Refactoring-Notizen prüfen, der eine Bedingung **Blocked by:** PHP >= X.Y nennt (tooling_tree.py's detect_nodes() meldet dies direkt bei Ausführung; von Hand gegen die aktuelle composer.json require.php/config.platform.php des Ziels prüfen) – wenn die aktuelle PHP-Version des Ziels diese jetzt erfüllt, ein Fund: diese Ablehnung ist aufgehoben. Kein Blocked by:-Feld, oder Bedingung noch nicht erfüllt → niemals ein Fund.

  Jeden Fund an refactor-learn übergeben – dieser Skill bemerkt nur; er markiert niemals etwas als done/wontfix und schreibt niemals selbst in die out-of-scope/ der Refactoring-Notizen.

3b. Extern gelabelte Kandidaten erkennen

API-Zugriff verfügbar (nicht der reine Git-Fallback) → auch offene refactor:candidate-Issues abfragen, die noch nicht berücksichtigt sind: nicht Schritt 2's Pending candidates-Eintrag, nicht Schritt 3's gemerktes Set (ein Issue mit einem verknüpften Pull-Request ist bereits in Bearbeitung). Was übrig bleibt, ist ein Kandidat, der von einem Menschen (oder einem anderen Prozess) direkt gelabelt wurde und den diese Schleife nie entworfen oder implementiert hat – im Normalbetrieb sind die eigenen Kandidaten der Suite immer durch einen der beiden abgedeckt, daher ist nichts Extra nötig, um „unsere” von „fremden” zu unterscheiden. Jeden als Vorschlag weitergeben, dieselbe Liste, der sich Schritt 4's Werkzeugbaum-Vorschläge anschließen – refactor-prioritize bewertet ihn neben allem anderen nach seinen üblichen Faktoren; er konkurriert aus eigener Kraft, springt nie allein wegen seiner Existenz vor. Kein API-Zugriff (reine Git-Abstimmung) → diesen Schritt vollständig überspringen; Git allein kann keine Issues nach Label auflisten.

4. Werkzeugbaum-Knoten vorschlagen

Überspringen, wenn Schritt 2 bereits einen ausstehenden Kandidaten vorgeschlagen hat.

python3 skills/refactor-scan/references/tooling_tree.py <ziel-repo> ausführen und das next-Feld des JSON lesen – das echte, aktuell nicht blockierte Set; abgelehnte Knoten (ein vorhandener Eintrag in den out-of-scope/<node>.md der Refactoring-Notizen) bereits ausgeschlossen, so viele Einträge übernehmen wie vorhanden. Nicht roadmap (eine Vorwärtssimulation, keine echten Optionen heute). Auch withheld lesen: Knoten, die sonst in next wären, aber auf einen unentschiedenen empfohlenen Elternteil warten – jeder Eintrag nennt, welches/welche Elternteil(e). Kein python3 oder nicht erlaubt → einen Unter-Agenten mit dem Prompt aus skills/refactor-scan/references/tree-walk-prompt.md beauftragen ({N}=all) – dieser durchläuft dieselben Baumdokumente manuell (liest zuerst das Feld Fulfilled nodes in den Refactoring-Notizen' bookkeeping.md, um erneutes Ableiten von zwischengespeichertem Zustand zu vermeiden, überspringt jeden Knoten mit einem out-of-scope-Eintrag); kein Unter-Agent-Mechanismus → seine Schritte selbst inline ausführen.

• Gewöhnliche Werkzeugknoten (loop-config und sprachspezifische Knoten, z. B. skills/refactor-scan/references/php-tooling-tree.md) – nach ihrem Namen vorschlagen (niemals der rohe Slug); jeder ist bereits vollständig in seinem Baumdokument spezifiziert.
• structural-scan – vorschlagen, sobald jeder Knoten mit einer resolved-Kante zu ihm aufgelöst ist (erfüllt oder explizit unter den out-of-scope/ der Refactoring-Notizen abgelehnt): editorconfig an der generischen Wurzel, plus der aktive sprachspezifische Aggregationsknoten (PHP: php-structural-scan), selbst aufgelöst, sobald jeder seiner eigenen aufgelösten Eltern aufgelöst ist (skills/refactor-scan/references/tooling-tree.md). Nur structural-scan wird jemals so vorgeschlagen – php-structural-scan ist reine Infrastruktur, niemals ein Kandidat. Es vorzuschlagen bedeutet nur, es zu nennen; der Codebase-Durchlauf erfolgt in refactor-design, nur für den tatsächlich ausgewählten Knoten.
• Kein Sprachbaum erkannt: structural-scan wartet immer noch auf editorconfig, das generische Wurzelblatt – nicht sofort vorschlagbar, nur weil kein sprachspezifischer Baum zutrifft.

Ausgabe

Vom Orchestrator schlicht weitergegeben:

• Welche Voraussetzung den Durchlauf gestoppt hat, falls zutreffend – nichts untenstehendes gilt für diesen Durchlauf.
• Funde (ggf. leer) → refactor-learn.
• Ein Wiederaufnahme-Kandidat, falls erkannt → direkt an refactor-implement, unter Umgehung von refactor-prioritize/refactor-design.
• Vorschläge – der ausstehende Kandidat allein, oder jeder aktuell nicht blockierte Knoten-Name (niemals Slugs, niemals begrenzt) plus jeder extern gelabelte Kandidat aus Schritt 3b, oder keiner → refactor-prioritize. Jeder aktuell nicht blockierte Knoten (erforderliche Eltern erfüllt, nicht abgelehnt, jeder empfohlene Elternteil bereits entschieden) – niemals eine priorisierte Teilmenge. Daneben jeden withheld-Knoten nennen und welches Elternteil er erwartet (z. B. „Rector: Type Coverage Set – wartet auf: PHP CS Fixer”).

Abschlusskriterium

Funde (falls vorhanden) an refactor-learn übergeben, ein Wiederaufnahme-Kandidat (falls vorhanden) direkt an refactor-implement übergeben, Vorschläge (falls vorhanden) an refactor-prioritize übergeben – oder eine Voraussetzung hat den Durchlauf gestoppt und der Bericht sagt, welche. Niemals ein Knoten zusammen mit Einträgen hinter structural-scan in derselben Liste.