Skip to content

models --invalidate: correcting the model log shouldn't mean hand-editing runs.jsonl #40

Description

@mlava

Symptom

When model-log rows turn out to be invalid evidence — spawn failures logged as model FAILs (#35), or a task failed twice by a verify check later proven unsatisfiable on a pristine repo — the only correction today is manual surgery on runs.jsonl. In the field this happened three times in one day (backups runs.jsonl.bak-20260714-{pathbug,fixswarm,specsregistry}, 39 rows removed by hand-rolled python).

Deletion also loses history: there's no record that the rows ever existed or why they were removed, so the correction itself is unauditable.

Proposed fix

./ringer.py models --invalidate --run <run_id> [--task <key>] --reason "..."

  • marks matching rows excluded-from-aggregates (kept in the file, flagged with the reason and a timestamp) rather than deleting them
  • aggregations (models, scoreboard page, explore ladder) skip invalidated rows
  • models output could show an invalidated-row count per model so the correction is visible

#35 prevents the largest source of invalid rows at write time; this is the repair path for everything it can't anticipate (e.g. orchestrator check bugs discovered after the run).

Size: M. Evidence and context: 2026-07-13/14 runs agents-json-generator, protocol-spec-audit, protocol-spec-fixes.

🤖 Generated with Claude Code

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions