Ship
Revendor safely
Update managed runtime without touching host truth.
Re-vendoring is
/evalglass setup --upgrade. It re-vendors managed files
only — the core, harness, and adapters under
evals/_evalglass/ — with a diff and an explicit confirm. Your datasets,
rubrics, thresholds, calibration, baselines, and evaluators are never overwritten. Plugin component
directories are never vendored at all.
Upgrading the framework should never silently change your domain truth or your gates.
/evalglass setup --upgrade enforces that: it shows you exactly which managed files
change, flags any local patch to a managed file, and only writes when you confirm.
The safe sequence
Run /evalglass setup --upgrade. It previews the diff and writes only after you
confirm. Under the hood it drives the integration CLI:
bash
# 1. Preview — writes nothing
python -m evalglass.installer revendor --root . --dry-run
# 2. Apply after reviewing the diff
python -m evalglass.installer revendor --root . --confirm- Managed files only. Re-vendoring replaces the core, harness, and adapters under evals/_evalglass/. Plugin component dirs — skills/, commands/, hooks/, plugin-docs/, assets/, bin/, .claude-plugin/ — are never vendored.
- Manifest & lock. The
vendor-manifest.jsonandevalglass.lockrecord every managed file and version, so a change is visible, not implicit. - Host-patch guard. If you edited a managed file, the dry-run surfaces it rather than clobbering it — the patch stays visible in the manifest.
- Host files preserved. Re-vendoring touches only the managed column; host-owned truth is left exactly as it was.
Runtime outlives the plugin
The vendored runtime works after the plugin and any coding-agent context are removed — the runtime
never imports
evalglass.installer. This runtime-after-removal property holds across
runtimes, including Codex. Re-vendoring is an occasional, deliberate upgrade, not a dependency the
evaluation needs at run time.