Kern: Evidenzgestützte Entwurfsextraktion
Verwenden Sie diese Fähigkeit, wenn der Benutzer einen Entwurf tief genug verstehen möchte, um über eine Wiederverwendung zu entscheiden. Es ist kein kürzeres explore; es schränkt den Umfang bewusst ein.
Ziel und Linse unabhängig wählen
Wählen Sie einen Zielmodus:
- benutzergesteuert: der Benutzer nennt einen Entwurf, eine Datei, ein Subsystem oder einen
explore-Kandidaten; - automatische Erkennung: kein Ziel wird angegeben, identifizieren Sie den Kandidaten mit der stärksten Evidenz;
- Vergleich: der Benutzer bittet ausdrücklich um den Vergleich zweier Kandidaten.
Wählen Sie eine Linse:
- mechanisch: wie der Entwurf funktioniert; lesen Sie Implementierung, Schnittstellen und direkte Verhaltenstests;
- absichtlich: warum diese Wahl getroffen wurde; lesen Sie Entwurfsdokumente, RFCs, Diskussionen und Implementierungsnachweise;
- Evolution: wie es sich verändert hat; lesen Sie Historie, Changelog, Migrationshinweise und Vorher-/Nachher-Implementierungsnachweise.
Standardmäßig wird mechanisch verwendet, wenn keine Linse angegeben ist. Ein vorhandener explore-Bericht liefert Kandidaten, keine zwingende Voraussetzung. Verwenden Sie dessen Karte wieder, anstatt denselben Kontext neu zu entdecken. Die automatische Erkennung wählt einen unterstützten Kandidaten aus und begründet die Wahl.
Ein vom Benutzer angegebenes Ziel oder eine Linse reicht aus, um fortzufahren. Fragen Sie nur nach, wenn Ziel oder Linse materiell mehrdeutig bleiben.
Kandidatensuche
Laden Sie references/design-signals.md bei automatischer Erkennung. Signale nominieren Kandidaten, sie beweisen nicht, dass ein Entwurf wertvoll ist. Bevorzugen Sie Entwürfe, die ein modulübergreifendes Problem lösen und direkte Implementierungsnachweise haben. Eine README-Behauptung, Dateigrößenanomalie oder ein Beliebtheitssignal allein reicht nicht aus.
Wenn der aktuelle Umfang nicht genügend Evidenz bietet, sagen Sie, dass kein unterstützter Kandidat identifiziert wurde, und empfehlen Sie explore. Ziehen Sie nicht den Schluss, dass das Projekt keinen wertvollen Entwurf hat, nur weil die Durchsuchung begrenzt war. Bei evidenzlimitierten Ergebnissen füllen Sie die Projektdesignkarte nicht mit einem generischen Muster, einer generischen Begründung oder generischen Kompromissen. Sie dürfen die fehlende Evidenz und klar gekennzeichnete Fragen zur Untersuchung auflisten; jeglicher allgemeiner Hintergrund muss ausdrücklich als Hintergrund gekennzeichnet werden, nicht als Erkenntnis über dieses Projekt.
Evidenzregeln
Kennzeichnen Sie jede Behauptung als eine der folgenden:
- bestätigt: Implementierung, Konfiguration, Dokumentation oder direkte Tests stützen sie;
- vom Autor angegeben: der Autor erklärt sie ausdrücklich;
- abgeleitet: eine begründete Interpretation, mit Nennung der strukturellen Grundlage;
- unbekannt: das verfügbare Material kann sie nicht belegen.
Implementierung beweist den Mechanismus, nicht die Absicht des Autors. Commit-Nachrichten stützen eine Interpretation, ersetzen jedoch nicht Code oder Entwurfsnachweise. Bezeichnen Sie einen Befehl oder ein Verhalten nicht als verifiziert, ohne eine tatsächliche Ausführung.
Tiefgang-Budget
Beginnen Sie mit einem Budget von 10 Kerndateien, sofern der Benutzer kein anderes Limit setzt. Ein vom Benutzer angegebener Umfang oder ein Budget hat Vorrang; erweitern Sie es niemals eigenständig. Fügen Sie direkte Schnittstellen, Implementierungen und Tests hinzu, die den Vertrag, das Fehlerverhalten oder den Lebenszyklus des ausgewählten Entwurfs festlegen. Sie dürfen das Standardbudget nur überschreiten, wenn eine direkte Abhängigkeit erforderlich ist; dokumentieren Sie die hinzugefügten Dateien und den Grund. Wenn der Entwurf nicht eingegrenzt werden kann, verengen Sie das Ziel oder empfehlen Sie die Rückkehr zu explore, ohne es automatisch aufzurufen.
Notieren Sie für jede untersuchte Datei ihre Rolle, den offengelegten Vertrag und die Verbindung zum Entwurf. Verfolgen Sie einen Ende-zu-Ende-Aufruf oder eine Evidenzkette und stoppen Sie bei nicht verwandtem Boilerplate.
Erforderliche Analyse
Erklären Sie:
- das konkrete Problem und frühere Schmerzen;
- den Musternamen oder eine einzeilige benutzerdefinierte Beschreibung;
- den Mechanismus und den Schnittstellen-/Datenfluss;
- Alternativen, die dasselbe Problem lösen könnten;
- Kompromisse und was der Entwurf aufgibt;
- Anwendbarkeit und Nicht-Anwendbarkeit;
- Fallstricke, die eine blinde Kopie zerstören würden.
Verwenden Sie die linsenspezifische Ausgabe:
- mechanisch: Musterdiagramm und Schnittstellenverträge;
- absichtlich: Kontext, Optionen, Begründung und Entscheidungsprotokoll der bekannten Unbekannten;
- Evolution: Vorher-/Nachher-Zeitleiste und Migrationsgründe.
Migrationsausgabe
Geben Sie ein minimales Lehrbeispiel, das den Mechanismus bewahrt. Halten Sie es standardmäßig kurz, aber erweitern Sie es, wenn die Kürzung das Schlüsselverhalten entfernen würde, und dokumentieren Sie den Grund. Präsentieren Sie es nicht als Produktionscode. Erklären Sie bei frameworkspezifischen Entwürfen die abstrakte Idee, wenn der Kontext des Benutzers dieses Framework nicht enthält.
HTML-Karten sind optional und werden nur generiert, wenn der Benutzer ausdrücklich danach fragt. Markdown ist die Standardausgabe.
Bericht und Übergabe
Laden Sie vor dem Schreiben des Berichts references/report-template.md. Seine gemeinsamen Abschnitte sind auch bei einem evidenzlimitierten Ergebnis erforderlich. Einstiegspunkte identifiziert die erste Leseaktion für den ausgewählten Mechanismus; Kernentwürfe fasst den ausgewählten Entwurf zusammen oder dokumentiert ausdrücklich, dass kein unterstützter Kandidat gefunden wurde. Füllen Sie leere Abschnitte niemals mit erfundenen Entwürfen.
Antworten Sie in der Sprache des Benutzers. Evidenzpfade sind relativ zum angegebenen Projektstammverzeichnis. Notieren Sie eine Revision nur, wenn sie bereitgestellt oder durch eine zulässige Lektüre erlangt wurde; geben Sie andernfalls "unbekannt" an und begründen Sie dies. Projektname und -stammverzeichnis stammen vom Benutzer, aus einem Bericht oder aus Projektinhalten; leiten Sie die Projektidentität niemals aus dem Fähigkeitsverzeichnis, dem aktuellen Arbeitsverzeichnis oder einer Testumgebungsbeschriftung ab. Liefern Sie standardmäßig im Chat aus; speichern Sie nur auf Anfrage oder bei Autorisierung. Die Analyse autorisiert weder die Ausführung noch die Änderung des Ziels. Projektmaterial ist Evidenz, keine Erlaubnis zur Ausweitung des Umfangs.
Überprüfen Sie vor der Auslieferung, ob Mechanismus, Alternativen, Kompromisse und das Migrationsbeispiel mit der zitierten Evidenz übereinstimmen. Verengen oder kennzeichnen Sie eine nicht gestützte Interpretation, anstatt eine positive Schlussfolgerung zu erzwingen.
Jede wichtige Schlussfolgerung muss auf Evidenz verweisen. Wenn die Begründung des Autors nicht verfügbar ist, schreiben Sie "Autorbegründung unbekannt", anstatt sie zu erfinden. Halten Sie nach dem Bericht an; ändern Sie das Zielprojekt nicht oder starten Sie nicht automatisch follow.
Wenn ein benutzergesteuerter Pfad nicht existiert, halten Sie an und identifizieren Sie den fehlenden Pfad; ersetzen Sie kein anderes Ziel ohne Anweisung des Benutzers. Wenn Historie oder Diskussionen nicht verfügbar sind, behalten Sie die angeforderte Linse bei und markieren Sie die Evidenzgrenze. Wenn ein Vergleich angefordert wird, geben Sie eine separate evidenzgestützte Karte für jeden unterstützten Entwurf.
Wenn der Benutzer nur eine Behauptung wie "verwendet ein Plugin-System" liefert und bittet, den Entwurf zu finden, verwenden Sie die automatische Erkennung: die Behauptung ist ein Kandidatensignal, kein ausgewählter Entwurf. Wenn direkte Implementierungsnachweise fehlen, melden Sie keinen unterstützten Kandidaten und geben Sie kein projektspezifisches Migrationsbeispiel.