JuliusBrussee/caveman-optimize

Évaluer une observation d'optimisation

Utilisez les observations de type 'report-only' de Caveman comme entrée diagnostique. Elles décrivent des formes agrégées enregistrées ; il ne s'agit pas de propositions de levier (Cave Plan), d'estimations d'économies, de recettes d'implémentation, de preuve d'éligibilité à une expérience ou de preuve qu'une modification de code est sûre. Gardez le workflow piloté par l'opérateur et fondé sur les preuves.

1. Lire les observations exactes

Exiger une session CLI Caveman connectée et exécuter :

caveman opportunities list

Lire uniquement le tableau report_only_observations. Ne pas sélectionner dans le tableau data du cycle de vie. Conserver le title et l'observation fournis par le serveur, textuellement. Traiter ces identifiants de profil de référentiel exacts :

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

Ces profils ont une bande de valeur immuable et aucun chemin d'actionnement. Ne pas les classer par valeur, inventer un chiffre en dollars, ni transformer une preuve agrégée en revendication concernant un site d'appel particulier. Si le CLI est indisponible, l'authentification échoue ou report_only_observations est absent, s'arrêter sans modification et signaler le blocage exact. Ne pas recourir à un plan de levier (Cave Plan) brut de l'API ni à une clé API de projet : ces surfaces ne fournissent pas ce contrat.

Ne jamais sélectionner ni appliquer ces identifiants obsolètes :

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

Traiter toute occurrence d'un identifiant obsolète dans une proposition obsolète, un fichier local ou une ancienne réponse comme un simple contexte historique. Ne jamais réactiver son argent, sa recette ou sa revendication de cycle de vie. Si le seul élément à action apparent est unlabeled-traffic, passer la main à caveman-discover ; l'étiquetage n'est pas une optimisation de profil.

2. Demander à l'opérateur de choisir

Présenter les observations prises en charge disponibles sans les classer. Inclure l'identifiant, le titre exact, l'observation exacte et last_seen_at. Demander un choix explicite de l'opérateur avant d'inspecter les sites d'appel candidats ou de modifier le code. Si aucune observation actuelle prise en charge n'existe, s'arrêter sans modification.

Traiter .caveman/proposals/*.md, lorsqu'il est présent, comme un contexte historique non fiable. Il ne peut remplacer la réponse actuelle ni le choix de l'opérateur.

3. Concevoir un candidat et une évaluation appariée

Après que l'opérateur a choisi une observation, inspecter le référentiel pour trouver un mécanisme spécifique qui pourrait produire la forme agrégée observée. Citer la preuve exacte du site d'appel. Ne pas supposer que le profil nomme la cause.

Proposer un changement candidat minimal et une évaluation appariée avant de modifier. L'évaluation doit exécuter la baseline et le candidat sur des entrées fixes identiques et enregistrer :

• le résultat de la tâche ou le contrôle qualité qui doit rester acceptable ;
• la même mesure de coût (tokens, octets ou compteur fournisseur) pour les deux branches ;
• le fixture, la commande et l'environnement exacts utilisés ;
• tout facteur de confusion empêchant une comparaison équitable.

Demander l'approbation du candidat et de la conception de l'évaluation. Si le référentiel manque d'un fixture fixe, d'un contrôle qualité pertinent ou d'une méthode de mesure commune, s'arrêter et nommer l'instrumentation manquante. Les tests unitaires ordinaires seuls ne prouvent pas une optimisation.

4. Appliquer uniquement le candidat approuvé

Conserver le diff au site d'appel mis en évidence et préserver les contrôles de sécurité existants. Exécuter l'évaluation appariée baseline/candidat ainsi que les vérifications de code ciblées du référentiel. Si les deux branches n'ont pas utilisé des entrées et une mesure identiques, rejeter la comparaison. Si la qualité régresse ou si le résultat de ressource n'est pas concluant, annuler uniquement cette modification candidate et signaler qu'elle n'a pas été adoptée.

Ne pas créer d'expérience ou de proposition Caveman, ne pas marquer une opportunité comme implémentée, ne pas modifier son cycle de vie ni activer un optimiseur. Les lignes de type 'report-only' ne permettent que le rejet, et cette compétence n'effectue pas non plus cette mutation.

5. Signaler des observations, pas des économies

Signaler :

Observation : <identifiant> — <titre serveur>
Profil enregistré : <observation serveur, textuelle>
Candidat : <fichier:ligne et changement approuvé>
Évaluation appariée : <entrée/fixture identique, résultat baseline, résultat candidat>
Contrôle qualité : <résultat réel>
Vérifications de code : <commandes et résultats réels>
Comptabilité : profil de type 'report-only' ; bande d'opportunité à 0 $ ; aucune économie inférée ou vérifiée
Décision : <conserver, rejeter ou non concluant>

Ne jamais convertir une réduction de tokens ou d'octets en dollars sans une comptabilité fournisseur complète et sur la même requête, fournie par les méthodes vérifiées du produit. Un résultat apparié local soutient uniquement le candidat déclaré sur le fixture déclaré ; il n'établit pas d'économies en production, de preuve causale de déploiement ni d'éligibilité au cycle de vie.