Forschungs-Review (Modulare & kombinierte Review-Gates)

Research Review (Modulare & kombinierte Review-Gates)

Plan, Coding und Test können eigenständig oder kombiniert ausgeführt werden:

• Wenn Sie nur geplant haben, führen Sie Modus A (Plan Review) aus.
• Wenn Sie Code geschrieben und sofort Tests geschrieben/ausgeführt haben (natürlicher Ablauf), führen Sie Modus B+C kombiniert (Code- & Test-Joint-Review) in einem einzigen parallelen Review-Durchgang aus. Verschwenden Sie keine Zeit mit zwei aufeinanderfolgenden separaten Review-Durchgängen.
• Wenn Sie nur Code ohne Tests geschrieben haben oder nur Tests für vorhandenen Code geschrieben/ausgeführt haben, führen Sie Modus B oder Modus C eigenständig aus.

1. Reviewer-Subagent-Dispatch (spawn_subagent)

• Standard-Reviewer (channel=mcli): Rufen Sie spawn_subagent parallel auf, um zwei parallele Reviewer zu starten, und warten Sie auf beide über get_command_or_subagent_output:
  • Subagent 1: model: "deepseek-v4.1-flash" (mcli-Kanal)
  • Subagent 2: model: "glm-5.3" (mcli-Kanal)
• Benutzerüberschreibung: Wenn der Benutzer andere Modelle angibt (z. B. kimi-k3.1-pro, MiniMax-M3.1-Flash, deepseek-v4-pro oder friday/* / catpaw-ide/*-Slugs), übergeben Sie die vom Benutzer angegebenen model-Slugs an spawn_subagent.
• Inkrementeller Abschluss (resume_from) :
  • Entdeckung (Runde 1): Starten Sie frische Subagenten mit nur dem minimalen Artefakt (Plan, git diff, Testcode + Ausführungs-stdout/stderr) und wichtigen Dateipfaden. Übergeben Sie niemals Ihren Konversationsverlauf.
  • Abschluss (Runde 2+, falls Korrekturen oder zusätzliche Tests erforderlich waren): Rufen Sie spawn_subagent mit resume_from: "<subagent_id>" für jeden Reviewer auf, wobei nur die aktiven Befunde und das Fix/Test-Delta übergeben werden, damit sie das Update überprüfen können, ohne unveränderte Dateien erneut lesen zu müssen.

2. Kern-Rollengrenzen

1. Haupt-Agent führt zuerst Validierung durch: Es wird empfohlen, einen kurzen Syntax-/Smoke-Test durchzuführen, bevor Reviewer entsandt werden, damit diese keine Mühe mit defektem Syntax verschwenden. Übergeben Sie Ihren genauen Testbefehl und dessen Ausgabe als Nachweis der Haupt-Agenten-Validierung.
2. Strenge Read-Only-Reviewer: Weisen Sie die Review-Subagenten an, Dateien nur zu lesen/greppen, Befunde mit datei:zeile-Nachweis in Prioritätsreihenfolge zu melden und - Validierungsanfrage: <exakte Prüfung> auszugeben, wenn eine nicht getestete Grenzfall einen Laufzeitnachweis benötigt. Reviewer bearbeiten niemals Dateien oder führen Befehle aus.
3. Entscheidung durch Haupt-Agenten: Warten Sie darauf, dass alle gestarteten Reviewer fertig sind, bevor Sie Änderungen vornehmen. Reproduzieren Sie Kandidatenfehler unabhängig, führen Sie gültige Validierungsanfragen aus und entscheiden Sie (angenommen / abgelehnt) mit konkretem Code- oder Mathe-Nachweis.

---

Modus A: Plan-Review (Eigenständig)

1. Vorbereitung: Geben Sie das Ziel, die zu bearbeitenden Dateien, Tensorformen / Datenflüsse und explizite Annahmen an (jede nicht genannte Wahl, die die Trainingssemantik, die Belohnungsskala oder die Baseline-Fairness betrifft).
2. Aufforderung an die Reviewer:

   "Read-only-Review dieses Forschungsplans. Bearbeiten Sie keine Dateien und führen Sie keine Befehle aus. Hinterfragen Sie nicht genannte Annahmen, prüfen Sie auf Daten-/Label-Leakage, Baseline-Unfairness und verteilte/Rollout-Engpässe. Geben Sie Review coverage: FULL|PARTIAL - <geprüfte Dateien> an und enden Sie mit Review verdict: APPROVED|FINDINGS. [Plan & wichtige Dateipfade einfügen]"

Modus B: Code-Review (Eigenständig – wenn noch kein Test geschrieben wurde)

1. Vorbereitung: Sammeln Sie die Anforderungs-/Planübersicht und git diff.
2. Aufforderung an die Reviewer: Weisen Sie sie an, geänderte Dateien und One-Hop-Caller schreibgeschützt auf stille Forschungsfehler zu untersuchen:
   • Maskierung & Alignment: Off-by-One-Fehler in der SFT/RL-Prompt-vs-Response-Token-Maske, Padding-Seiten-Mismatches oder EOS/Truncation-Handling.
   • Tensorformen & Broadcasting: Unbeabsichtigtes Broadcasting (z. B. (B, 1) vs (B,)), Reduktionsdimensionsfehler (mean/sum über Sequenz vs. Batch).
   • Gradient- & State-Hygiene: Fehlplatzierte detach()/ no_grad(), KL-Richtung, Advantage-Normalisierungsbereich oder nicht zurückgesetzter Agenten-Umgebungszustand über Rollouts hinweg.
   • Erfordert Review coverage und Review verdict: APPROVED|FINDINGS.

Modus C: Test-Review (Eigenständig – wenn Tests für vorhandenen Code hinzugefügt oder auditiert werden)

1. Vorbereitung: Sammeln Sie den Testdateipfad, den Zielmodulpfad und die tatsächliche Testausführung (stdout/stderr).
2. Aufforderung an die Reviewer:

   "Read-only-Audit dieses Tests und seiner Ausführungsausgabe. Bearbeiten Sie keine Dateien und führen Sie keine Befehle aus. Hat er tatsächlich die mathematischen/Tensor-Invarianten und Grenzfälle verifiziert, oder hat er echte Logik weg-gemockt / Behauptungen abgeschwächt, um zu bestehen? Geben Sie - Validierungsanfrage: ... aus, wenn ein Grenzfall nicht getestet ist. Geben Sie Review coverage an und enden Sie mit Review verdict: APPROVED|FINDINGS."

Modus B+C: Gemeinsames Code- & Test-Review (Wenn der Haupt-Agent in einem Durchgang codiert und selbst getestet hat)

1. Vorbereitung: Packen Sie die Anforderungs-/Planübersicht, den Implementierungs- + Test-git diff und den Nachweis der Haupt-Agenten-Validierung (genauer ausgeführter Testbefehl und dessen stdout/stderr) zusammen.
2. Aufforderung an die Reviewer:

   "Read-only-gemeinsames Review des Implementierungs-Diffs und des Selbsttests des Haupt-Agenten. Bearbeiten Sie keine Dateien und führen Sie keine Befehle aus.

   1. Code-Prüfung: Suchen Sie in geänderten Dateien und One-Hop-Callern nach stillen Forschungsfehlern (Token-Mask-Off-by-One, Padding/EOS-Alignment, unbeabsichtigtes Tensor-Broadcasting (B,1) vs (B,), falsche Reduktionsdim, fehlplatzierte detach()/ no_grad(), KL/Advantage-Mathematik, nicht zurückgesetzter Rollout-State).
   2. Selbsttest-Audit: Prüfen Sie, ob der Selbsttest des Haupt-Agenten diese Invarianten und Grenzfälle tatsächlich verifiziert oder ob er unter Bestätigungsfehler leidet (nur Happy-Paths testen, Kernlogik weg-mocken oder schwache Behauptungen). Geben Sie - Validierungsanfrage: <exakte Prüfung> für jeden fehlenden Grenzfall-Test aus. Geben Sie Review coverage: FULL|PARTIAL - <geprüfte Dateien> an und enden Sie mit Review verdict: APPROVED|FINDINGS."

3. Entscheidung & Abschluss: Beheben Sie akzeptierte Code-Fehler und erfüllen Sie gültige Validierungsanfragen; wenn nicht-triviale Änderungen vorgenommen wurden, verwenden Sie resume_from bei beiden Reviewern, um das Delta zu überprüfen.

---

3. Leichtgewichtiges Ledger (docs/review-log.md)

Fügen Sie nach Abschluss jedes Review-Gates einen prägnanten 5–10-zeiligen englischen Eintrag in docs/review-log.md im aktuellen Projekt hinzu (erstellen Sie die Datei, falls nicht vorhanden). So bleiben subagent_id-Handles über Kontextverdichtung hinweg erhalten und es entsteht ein experimenteller Audit-Trail:

## [YYYY-MM-DD] <Kurzer Aufgabentitel> (<Modus A / B / C / B+C>)
- **Annahmen / Umfang**: <1-zeilige Zusammenfassung wichtiger Designannahmen und berührter Dateien>
- **Reviewer**: `deepseek-v4.1-flash` (`id: <subagent_id>`), `glm-5.3` (`id: <subagent_id>`)
- **Entscheidung**:
  - `[ANGENOMMEN]` `<datei:zeile>` — <präzise Beschreibung des Fehlers/Defekts und wie er behoben wurde>
  - `[ABGELEHNT]` `<datei:zeile>` — <warum der Review-Befund ein falsch Positiv war, mit Mathe-/Code-Nachweis>
- **Urteil & Nachweis**: `APPROVED` (<1-zeiliges Ergebnis des Test-/Smoke-Checks>)