mirror of
https://github.com/garrytan/gbrain.git
synced 2026-07-30 11:22:34 +00:00
Garry TanandClaude Opus 4.7
ca99fbfeb5
The original SKILL.md Step 6 told users to run `node harness.mjs` from the
gbrain repo as the mandatory ≥95% gate. But that runs the harness against
the COMMITTED sample variants in evals/functional-area-resolver/variants/,
not the file the user just compressed. The gate could pass while the edit
dropped a sub-skill.
Step 6 now:
- Gate 1 stays at `gbrain routing-eval --json` (structural, runs against
the user's actual routing-eval.jsonl fixtures).
- Gate 2 is rewritten: copy the user's edited routing file into a tmp
variants dir, then run `node harness.mjs --variants-dir <tmp>
--variants my-edit --model opus`. This exercises the harness's existing
--variants flag (added in commit 472cc686 / T4) but now points at the
user's actual edit. The harness uses gbrain-bundled fixtures, so this
is a regression check on shared skills, not a full eval of the user's
fixture set — and the SKILL.md says so explicitly.
Also adds a "common false negatives" callout: when the user's routing
file doesn't expose the skills gbrain's bundled fixtures target (e.g.
`gmail`, `enrich`), expect strict-scoring fails on those rows; lenient
scoring remains accurate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>