| 1 | Inventory → claims ledger | buhhdy-level | — | Sweep buhhdy/config.yaml AND every buhhdy/skills/*/SKILL.md for dated operator notes and factual claims: model IDs and tier slots, deprecation/shutdown dates, per-token pricing, auth/tier/billing shape, and CLI/harness behavior claims (e.g. the ACP model-pinning constraint, flag spellings, minimum runtime versions). Cross-reference each against the calibration notes in config.yaml and MODEL-MANIFEST.md. Ledger row: claim / where stated / last verified / verification method / age. The ledger MUST cover at minimum: the model tier table, the Fable escalation-gate cost basis, the Gemini ACP/auth notes, and the opencode OpenRouter billing note — a run whose ledger misses one of these is incomplete, not done |
| 2a | Verify: CLI / harness behaviors | buhhdy-level shell | — | Cheapest check runs FIRST — free and local: CLI --version/--help, opencode models, the installed omnigent runtime source. Never verify a harness claim from docs alone when the binary is right there; a claim disproven here never spends a dispatch |
| 2b | Verify: availability + auth | Dispatched | one LIGHTWEIGHT dispatch per provider (gemini-lite for gemini), fanned out across all providers in ONE parallel wave | sys_list_models plus one live round-trip per provider — the round-trip doubles as the auth check. A failed ID here is a finding, not an error |
| 2c | Verify: deprecations / pricing / releases | Dispatched | gemini-standard or codex (STANDARD), fanned out across claims in one parallel wave; the SECOND, different-vendor dispatch is spent only when the lead source surfaces a would-flip discrepancy | Web verification against provider primary docs. A consequential claim (anything a routing rule, tier slot, or cost basis rests on) still flips ONLY on cross-vendor confirmation: two independent sources, or two different-vendor agents each citing primary docs. One source is a lead, not a flip — and an unchanged lead needs no second vendor |
| 3 | Update the notes | buhhdy-level | — | For every claim that CHANGED or is newly discovered, update the dated calibration notes in config.yaml and MODEL-MANIFEST.md — append a fresh dated line and mark the superseded one rather than deleting it. Claims verified UNCHANGED are recorded in the ledger and report only — never as new note lines; freshness lives in the report, and the notes stay compact. Contradictions BETWEEN sources are never resolved silently: record both sources verbatim, mark the claim disputed, and escalate (house style: config's gemini-2.5-flash-lite disputed-retirement note — state both positions, name both sources, pick the migration-safe action only if one exists) |
| 4 | Config PR | buhhdy-level, cross-reviewed | opposite-vendor local review before the PR | Propose the config.yaml + MODEL-MANIFEST.md diffs that update the dated calibration notes in place. Model-ID currency WITHIN an existing tier slot (a renamed successor at the same tier, verified per 2b) is calibration knowledge and updates in place with evidence. NEVER rewrite routing STRUCTURE autonomously — the decision tree, which tier a slot maps to, adding/removing slots, gates, or Merge Authorization: if verification implies such a change (a model retired out of a tier slot, a repricing that breaks a cost-basis assumption), it goes in the PR under a clearly flagged ## ROUTING CHANGES — HUMAN JUDGMENT REQUIRED section as a proposal with the evidence, never as an applied edit. Low confidence → escalate instead of proposing. One PR per refresh run, standard pipeline: local cross-review → PR → CodeRabbit → pr-shepherd |
| 5 | Report | buhhdy-level | — | Delta summary: verified unchanged (count + ledger refs) / updated (old → new, record written) / contradicted → escalated (both sources) / newly discovered (e.g. a new model or tier worth evaluating — surfaced, not wired). End with the next recommended refresh date (default: +1 month) |
