Synthèse automatique
Vérifie de bout en bout les changements moteur/gql de gochickpeas au moyen d'une passe de parité sur de vraies données LDBC et d'une prise en main de l'API publique.
Points forts
- Porte de parité sur le pipeline complet (parse → plan → exec) avec hachages de lignes épinglés sur les exports SF1/FinBench SF10 (~26M relations)
- Le golden de forme de plan détecte les régressions de qualité de plan que la parité des lignes ne peut pas voir
- L'option -cached-parity couvre le chemin PlanCache auto-paramétré et révèle les divergences littéral/plan mis en cache
- Donne un protocole concret de verrouillage de la machine partagée et une méthodologie ABBA pour les comparaisons de temps bruitées
Limites
- Suppose des chemins locaux précis (exports LDBC, racine du dépôt) et l'outillage taskman propres à cet environnement
- La passe complète charge ~26M relations et prend plusieurs minutes, avec un verrou exclusif sur la machine
- Les conseils sur le bruit de mesure et les compteurs d'allocations sont spécifiques à cette machine, pas généraux
À utiliser avant de committer un changement non trivial du moteur ou du langage gql, en particulier s'il touche au planificateur ou au recognizer.
À éviter pour des changements purement documentaires ou triviaux, ou lorsque les données LDBC et le verrou machine ne sont pas disponibles.
Analyse de sécurité
PrudenceThe skill is a developer verification runbook. It issues ordinary Go build/test/benchmark and lock-manager commands against a local repository and dataset, with no destructive, exfiltrating, or obfuscated actions and no instruction to bypass safety. It is classified caution only because it drives local shell/compilation tooling (including running repo code) for legitimate purposes.
- •Runs local shell operations (`go run ./cmd/gqlbench`, `go build ./...`, `go test ./...`, `taskman lock run`) that compile and execute code from the target repo — powerful tooling but legitimate for verification.
- •Depends on the agent having bash/terminal access; no `allowed-tools` are declared, so the skill itself does not constrain which tools the agent may use.
- •Contains developer-specific absolute paths (`/Users/efreeman/gochickpeas`, `~/rustychickpeas-ldbc/...`), which is not a security issue but assumes a specific machine layout.
- •Heavy invocation loads ~26M relations and runs multi-core builds/tests; resource contention is acknowledged and gated via the shared-box lock, not a risk to the host.
- •No exfiltration, no curl|sh, no `rm -rf`, no base64/obfuscated payloads, no safety-disabling instructions.
Exemples
I changed the planner's VarExpand pushdown logic in gochickpeas. Run the full verification: parity gate with -cached-parity and -plans-golden, and tell me whether the plan-shape golden drifted.Set up a scratchpad module with a replace directive to /Users/efreeman/gochickpeas, build a small graph with chickpeas.NewBuilder, then run a few gql.Run queries and check gql.Explain output for the [mono ...] pushdown marker.Compare allocations before and after my recognizer change using gqlbench profiles, and if we need timing run the whole ABBA comparison inside one taskman lock run local-cpu session with -max-load 2.name: verify description: Verify gochickpeas engine/gql changes end-to-end -- parity gate against real LDBC data plus a public-API sample drive.
Verifying gochickpeas changes
The surface is the library's public API. Two handles, use both for nontrivial engine/gql changes:
1. Parity gate (real data, full pipeline)
go run ./cmd/gqlbench -manifest ~/rustychickpeas-ldbc/viz/data/gql_variants.tsv \
-verify-only -cached-parity \
-plans-golden cmd/gqlbench/testdata/plans_golden.txt
Expect 89/89 MATCH, 0 DIFF, 0 SKIP, plus plan-shape golden: 89 queries unchanged. This drives parse -> plan -> exec over SF1/FinBench SF10 exports
with pinned row hashes. Loads ~26M rels; takes a few minutes. Never emit
(-verify-only) from a dirty tree -- the append-only bench-out protocol stamps
engineCommit.
-
-cached-parityalso checks the auto-parameterized PlanCache path against the same reference hashes (catches literal-vs-cached-plan divergence). -
-plans-goldenguards plan QUALITY, which row parity cannot see: a planner change that stays correct still moves the plan, and drift here fails the run. For an INTENTIONAL planner change, review the drift, then regenerate the golden with-plans-golden-captureand commit it in the same change. Do a planner change WITHOUT this and a regression that stays row-correct lands invisibly. -
Run heavy invocations under the shared-box lock -- and not just the gate: full builds, full test runs, fuzz runs, and benchmarks are exactly the multi-core work that lands on top of an ldbc sweep mid-measurement.
taskman lock run -ttl 20m -wait 30m -reason "<what>" local-cpu -- go build ./... taskman lock run -ttl 20m -wait 30m -reason "<what>" local-cpu -- go test ./...Incremental builds,
go vet, and editor-driven builds are fine unlocked. A non-zero exit fromlock runmeans another session holds the box: wait or do unrelated work -- never run the job anyway.
2. Sample drive through the public export
Scratchpad module with a replace directive resolves the local repo:
module verifydrive
require github.com/freeeve/gochickpeas v0.0.0
replace github.com/freeeve/gochickpeas => /Users/efreeman/gochickpeas
Build a small graph with chickpeas.NewBuilder (AddNode/SetProp/AddRel/
SetRelPropAt, then Finalize("name")), run queries with gql.Run, and
inspect plans with gql.Explain (e.g. grep the [mono ...] marker on
VarExpand lines to see whether a pushdown fired). Probe near-miss
phrasings and malformed input; errors should be clean plan/bind errors.
Gotchas:
- Timing on this machine is very noisy; alloc counts (gqlbench profiles
output) are the most trustworthy A/B signal. For timing A/Bs, run the
whole comparison inside ONE
taskman lock run local-cpusession in ABBA order (new-old-old-new): interleaving alone does not cancel a load trend, only ABBA does. A run whose TIMING is the product must also pass-max-load 2and must not publish on a non-zero exit. gqlbenchmust run from the repo root (HeadStamp shells to git); point -out/-plans-out/-profiles-out at the scratchpad.- 45s of
go test ./gql -fuzz FuzzQuery -fuzztime 45sis cheap insurance after recognizer/planner changes.
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/verify-gochickpeas-engine-gql-changes-mrwak9i9/download' --output '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md.part' && mv '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md.part' '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md' && test -s '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/verify' && cp -R '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9' '.claude/skills/verify'Cursor
test -f '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md' && test -s '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md' && mkdir -p '.cursor/skills' && test ! -e '.cursor/skills/verify' && cp -R '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9' '.cursor/skills/verify'Codex
test -f '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md' && test -s '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/verify' && cp -R '.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9' '.agents/skills/verify'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9'openskills read 'verify-gochickpeas-engine-gql-changes-mrwak9i9'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/verify-gochickpeas-engine-gql-changes-mrwak9i9/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Comparaison de performances ClickHouse
Testing
Évaluez les résultats de tests de performance ClickHouse, analysez les régressions de PR, comparez avec l'historique et vérifiez la fiabilité des mesures.
Analyse des rapports de performance CI
Testing
Analyse les rapports de comparaison de performance CI pour une PR ClickHouse. Recoupe l'historique master pour distinguer les vraies régressions des tests instables.
Méthode Santa
Testing
Vérification adversarial multi-agents avec deux réviseurs indépendants. La sortie est vérifiée deux fois et corrigée itérativement jusqu'à ce que les deux acceptent avant publication.