JuliusBrussee/caveman-optimize

Auswerten einer Optimierungsbeobachtung

Cavemans reine Beobachtungsberichte als diagnostische Eingabe verwenden. Sie beschreiben aufgezeichnete aggregierte Formen; sie sind keine Cave-Plan-Züge, Sparschätzungen, Umsetzungsrezepte, Experimenteignung oder der Nachweis, dass eine Codeänderung sicher ist. Halten Sie den Workflow operatorgewählt und evidenzbasiert.

1. Die genauen Beobachtungen lesen

Eine angemeldete Caveman-CLI-Sitzung ist erforderlich. Führen Sie aus:

caveman opportunities list

Nur das report_only_observations-Array lesen. Nicht aus dem Lebenszyklus-data-Array auswählen. Jeden vom Server bereitgestellten title und jede observation wortgetreu beibehalten. Diese exakten Repository-Profil-IDs verwenden:

• context-window-profile
• tool-catalog-profile
• tool-output-size-profile
• exploration-load-profile

Diese Profile haben ein unveränderliches Null-Band und keinen Aktionspfad. Bewerten Sie sie nicht nach Wert, erfinden Sie keinen Dollarbetrag und machen Sie aus aggregierten Belegen keine Behauptung über einen bestimmten Aufrufort. Falls die CLI nicht verfügbar ist, die Authentifizierung fehlschlägt oder report_only_observations fehlt, anhalten, ohne zu bearbeiten, und den genauen Blocker melden. Nicht auf einen rohen Gateway-Cave-Plan oder einen Projekt-API-Key zurückgreifen: Diese Oberflächen stellen diesen Vertrag nicht bereit.

Diese veralteten IDs niemals auswählen oder anwenden:

• context-window-bloat
• tool-catalog-utilization
• verbose-tool-output

Jedes Vorkommen einer veralteten ID in einem veralteten Vorschlag, einer lokalen Datei oder einer alten Antwort ausschließlich als historischen Kontext behandeln. Niemals deren Geld, Rezept oder Lebenszyklusbehauptung wiederbeleben. Falls der einzig umsetzbar erscheinende Eintrag unlabeled-traffic ist, an caveman-discover übergeben; die Beschriftung ist keine Profiloptimierung.

2. Den Operator zur Auswahl auffordern

Die verfügbaren unterstützten Beobachtungen ohne Rangfolge präsentieren. Die ID, den genauen Titel, die genaue Beobachtung und last_seen_at einschließen. Vor der Untersuchung von Kandidaten-Aufruforten oder Codeänderungen eine explizite Operator-Auswahl verlangen. Falls keine unterstützte aktuelle Beobachtung vorhanden ist, ohne Änderung anhalten.

.caveman/proposals/*.md – sofern vorhanden – als nicht vertrauenswürdigen historischen Kontext behandeln. Es kann weder die aktuelle Antwort noch die Wahl des Operators ersetzen.

3. Einen Kandidaten und eine gepaarte Evaluierung entwerfen

Nachdem der Operator eine Beobachtung ausgewählt hat, das Repository auf einen spezifischen Mechanismus untersuchen, der die beobachtete aggregierte Form erzeugen könnte. Den genauen Aufrufort als Beleg anführen. Nicht annehmen, dass das Profil die Ursache benennt.

Vor dem Bearbeiten einen minimalen Kandidatenvorschlag und eine gepaarte Evaluierung vorschlagen. Die Evaluierung muss Baseline und Kandidaten auf identischen, festen Eingaben ausführen und Folgendes aufzeichnen:

• das Aufgaben-Ergebnis oder die Qualitätsprüfung, die akzeptabel bleiben muss;
• das gleiche Token-, Byte- oder anbietergezählte Kostenmaß für beide Arme;
• die genaue Testumgebung, der Befehl und die Umgebung;
• alle Störfaktoren, die einen fairen Vergleich verhindern.

Die Zustimmung zum Kandidaten- und Evaluierungsdesign einholen. Falls dem Repository eine feste Testumgebung, eine relevante Qualitätsprüfung oder eine gemeinsame Messmethode fehlt, anhalten und die fehlende Instrumentierung benennen. Normale Komponententests allein beweisen keine Optimierung.

4. Nur den genehmigten Kandidaten anwenden

Das Diff auf den belegten Aufrufort beschränken und bestehende Sicherheitskontrollen beibehalten. Die gepaarte Baseline-/Kandidaten-Evaluierung sowie die fokussierten Code-Prüfungen des Repositorys ausführen. Falls die beiden Arme nicht identische Eingaben und Messung verwendet haben, den Vergleich verwerfen. Bei Qualitätsverschlechterung oder nicht aussagekräftigem Ressourcen-Ergebnis nur diese Kandidatenänderung rückgängig machen und melden, dass sie keine Übernahme erreicht hat.

Kein Caveman-Experiment oder keinen Vorschlag erstellen, keine Gelegenheit als umgesetzt markieren, deren Lebenszyklus ändern oder einen Optimierer einschalten. Nur Beobachtungszeilen erlauben eine Verwerfung, und dieses Skill führt auch diese Mutation nicht durch.

5. Beobachtungen melden, keine Ersparnisse

Melden:

Beobachtung: <id> — <Server-Titel>
Aufgezeichnetes Profil: <Server-Beobachtung, wortgetreu>
Kandidat: <Datei:Zeile und genehmigte Änderung>
Gepaarte Evaluierung: <identische Eingabe/Testumgebung, Baseline-Ergebnis, Kandidaten-Ergebnis>
Qualitätsprüfung: <tatsächliches Ergebnis>
Code-Prüfungen: <Befehle und tatsächliche Ergebnisse>
Abrechnung: Nur-Beobachtungs-Profil; 0 $-Gelegenheitsband; keine abgeleiteten oder verifizierten Ersparnisse
Entscheidung: <behalten, ablehnen oder nicht aussagekräftig>

Token- oder Byte-Reduktion niemals in Dollar umrechnen, ohne eine anbieterumfassende, gleichlauffende Abrechnung, die von den verifizierten Methoden des Produkts bereitgestellt wird. Ein lokales gepaartes Ergebnis unterstützt nur den genannten Kandidaten auf der genannten Testumgebung; es begründet keine Produktionsersparnisse, kausale Ausbringungsbelege oder Lebenszyklus-Eignung.