Two new repo-lane editing primitives beyond exact-match edit_text and full-file write_file, both validated on the included editbench benchmark before adoption: - edit_batch: atomic batch of COUNTED exact replacements. Each edit declares the occurrence count it expects and replaces all of them; any mismatch aborts the whole batch with per-edit diagnostics. The safe replace-all: a miscount is an atomic refusal, not a silent corruption. - apply_patch: context-anchored multi-file patch (V4A-style, no line numbers; optional @@ anchors; trailing-whitespace fuzzy fallback). Atomic across all files/hunks with per-hunk diagnostics; parser tolerates decorative trailing *** on headers (observed model quirk). write_file repo lane gains two verification rails inherited from an edit_sketch fast-apply tool that was implemented, benchmarked, and REJECTED (data in devtools/benchmarks/editbench/README.md): a pre-write syntax guard for .py/.json (force bypasses with an explicit SYNTAX_GUARD_BYPASSED disclosure — no silent bypass, P3) and the unified diff vs the previous version appended to overwrite results (capped with an explicit truncation count, P1). Registration follows the New Tool rule across every canonical surface: safety.py TOOL_POLICY, tool_capabilities (CORE/ACTING envelopes + result limits; local-readonly and heal lanes deliberately excluded), registry (_FROZEN_TOOL_MODULES/_WORKSPACE_ALLOWED_TOOLS/_REPO_MUTATION_TOOLS), outcomes (_ROOT_WRITE_TOOLS so patch/batch-only turns stay acceptance- review-eligible; _RECOVERY_TOOL_NAMES), smoke EXPECTED_TOOLS, and the SYSTEM.md/ARCHITECTURE.md/DEVELOPMENT.md/CHECKLISTS.md documentation in the same commit (P6). The edit_text/write_file descriptions steer tool selection at the schema source (per DEVELOPMENT's anti-pattern guidance, not SYSTEM.md prose accretion). devtools/benchmarks/editbench/ is the evidence and the regression rig: 5 editing tasks (trap-laden rename, surgical edit in a 1691-line module, whole-function replacement, cross-file move, near-full-file transform), per-config tool restriction via disabled_tools, deterministic grading, token/latency/error mining. Migrated under the benchmark admission contract (admit_benchmark_run/finalize_run_manifest, launcher_audit MIGRATED_LAUNCHERS); it measures the current working tree by design, so real runs use the recorded --allow-dirty-seed escape. Headline numbers (grok-4.5, 3 runs/config, every run solved every task; full tables in the editbench README): edit_batch finishes the rename task in ONE tool call vs ~6 for edit_text/write_file; on a weak model (gemini-3.6-flash) its advantage grows to 1.5-2.5x cheaper/faster; a free-choice agent picked the right tool per task shape in every run. No version carriers touched (maintainer assigns the release version). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| common | ||
| continual_learning | ||
| editbench | ||
| gaia | ||
| harness_bench_fast | ||
| osworld | ||
| programbench | ||
| swe_bench | ||
| swe_bench_pro | ||
| terminal_bench | ||
| __init__.py | ||
| evolve_smoke.py | ||
| README.md | ||
Ouroboros Benchmark Devtools
This directory contains tracked operator tooling for reproducible benchmark work. These files are reviewed when touched, but are not imported by the runtime core and are not packaged as app runtime code.
Integrations
terminal_bench/— Harbor installed-agent adapter for Terminal-Bench 2.1. Userun_tb.pyfor leaderboard-shaped k-trial runs and submission layout; userun_harbor_smoke.pyfor small local smoke runs.osworld/— OSWorld 2.0-aligned step-loop adapter (pinnedxlang-ai/OSWorld-V2@c261cb57, 500-step budget, officialshow_result.pyresult layout, VM-state-aware prompting + terminalfinal_answeraudit capture) plus logs-only audit tooling; runnable against a local vmware/docker OSWorld checkout, cloud providers and checkpoint curves not implemented — seeosworld/METHODOLOGY.md.swe_bench_pro/— SWE-bench Pro patch capture/grading. Frozen prepared repos usepro_predictions.py; persistent evolutionary runs usee1v2/run_pro.py/e1v2/auto_run.py.swe_bench/— standard SWE-bench prediction helpers.programbench/— ProgramBench cleanroom runner (run_programbench_e2e.pyfor end-to-end Ouroboros harness runs;run_programbench.pyprepare/package-only).continual_learning/— launcher wrapper for the EXTERNAL CL-Bench (continual-learning-bench.com) runner: strictly sequential memory / continual-learning runs against a live Ouroboros agent (evolution off). Userun_clb.py; the runner repo + itssrc/systems/ouroboros/adapter are obtained separately (see its README).harness_bench_fast/— Ouroboros CLI wrapper and methodology notes for the publicai-forever/harness-bench-fastrunner.common/— shared manifests, result ledgers, safe run roots, secret hygiene, and official command builders.
Output Roots
Write generated run artifacts under an explicit benchmark output root outside
repo/ and outside live runtime data/, typically
/Users/anton/Ouroboros/bench_runs/.... Tests must set
OUROBOROS_BENCH_RUNS_ROOT to a temporary directory so local test runs do not
pollute real benchmark bundles.
CLEAN SEED IS MANDATORY FOR SUBMITTABLE RUNS
BEFORE STARTING ANY SUBMITTABLE / LEADERBOARD RUN, THE SEED WORKTREE MUST BE
CLEAN: git -C <seed> status --porcelain MUST BE EMPTY AND
git describe --dirty MUST NOT CARRY A -dirty SUFFIX. A DIRTY SEED
(UNCOMMITTED ADAPTER EDITS, STRAY FILES) MAKES THE RUN MANIFEST RECORD
...-dirty, THE PROVENANCE BECOMES NON-REPRODUCIBLE, AND THE RUN CANNOT BE
SUBMITTED — THE MONEY IS BURNED. IF ADAPTER EDITS ARE NEEDED, COMMIT THEM
FIRST (A WIP COMMIT IN THE SEED IS ACCEPTABLE IF RECORDED IN THE RUN NOTES),
CLEAN UP STRAY FILES, THEN LAUNCH. IF A DIRTY SEED IS DISCOVERED AFTER
LAUNCH, ESCALATE TO THE OWNER IMMEDIATELY (STOP VS FINISH IS THE OWNER'S
CALL) — NEVER STAY SILENT.
Shared Sidecar Schemas
- Run manifests record non-secret provenance: requested task ids where the
benchmark runner exposes them before execution, requested counts/selection
slots for deterministic first-N runs such as Terminal-Bench, exact argv,
official command shape, output paths, model slots, source commit, dirty-state
counts, and hashes. Defaults are adapter-specific (
run_manifest.json,<predictions>.run_manifest.json, orosworld_preflight.run_manifest.json). - Result ledgers are denominator-preserving Ouroboros JSONL files. They record
every requested instance, including setup failures, timeouts, and empty
patches, even when the official benchmark prediction/submission format only
accepts successful rows. Defaults are adapter-specific (
result_index.jsonl,<predictions>.ledger.jsonl, orosworld_preflight.ledger.jsonl).
These sidecars are audit artifacts, not replacement scoring. Official benchmark harnesses and official result files remain the scoring authority.
Bench-Template Scaffold Defaults (v6.55.0)
All committed bench settings templates share these disclosed defaults:
-
Cost pacing (v6.56.0): tasks with a finite budget receive latched in-task COST milestones (50/25/10% remaining + ~80%-spent wrap-up note) from the
task_pacingSSOT;budget_profile.cost_hard_stop_pct=0(SWE-Pro/PB profiles) disables the in-task hard stop so deadline/rounds own the bounds. -
OUROBOROS_MAX_WORKERS=4— same-model subagent slots for decomposition WITHIN one task (the root agent takes one lane). Never independent attempts with selection, so pass@1 claims hold. The core default (10) is untouched. -
OUROBOROS_SAFETY_MODE=light— bench containers/rendered data roots are disposable jails; deterministic guards stay, the LLM safety pass is kept for integration tools only. User defaults are untouched. -
OUROBOROS_RUNTIME_MODE=profor CONTAINER benches (Terminal-Bench, SWE-bench Pro, ProgramBench, OSWorld). GAIA stayslight: its solver runs without workspace isolation against a live repo, so pro would grant benchmark prompts write authority over the system body. -
claude_code_editdisabled in every bench solve task — benches measure the single-model Ouroboros harness; the embedded Claude-Code delegate is a separate experiment.
Per-bench METHODOLOGY files carry the full rationale.
Methodology Rule
Benchmark changes must be general-purpose harness improvements first. Do not add task-specific answers, hidden verifier knowledge, or resource/timeout overrides that violate a benchmark's official submission rules.
Upstream-Drift & Protocol-Fidelity Pre-Flight (MANDATORY before any expensive run)
Four checks, each of which failed at once in the CLB v6.81.0 campaign (continual_learning/METHODOLOGY.md §10-§12) and would have cost the whole budget if the run had been the submission:
- Upstream drift. Check the external benchmark repo's commits/PRs/issues AFTER our pin (via GitHub API/web; do not fetch into the pinned clone). A metric/scale change can ship as re-scored reference artifacts with no task-code commit — when reference artifacts carry two reward copies (top-level vs nested), prove which one the local scorer reads before trusting any number it prints.
- Empirical protocol fidelity. Verify every protocol parameter by its
ARTIFACTS, not its flag. Multi-seed must mean different question orders:
diff prompt hashes across seeds BEFORE mass spend (CLB:
--run-indexwas accepted and silently dropped on 4/6 domains — five "seeds" were five replicates). This generalizes the "declared vs applied" settings rule to the harness itself. - Read submission requirements BEFORE the run, not after. Which arms are mandatory (stateless baseline!), how many seeds, which artifact layout, whether a public implementation link is required — and run in submission-shape via the official runner from the start. Money burned on a non-submittable path converts to a submission only by fabricating provenance, which is prohibited.
- A pinned local scoring script is not ground truth. Reconcile local normalization against the PUBLIC leaderboard (top-1 value, last-updated date). A mismatch means a convention divergence to be root-caused — not "the other party's numbers are stale". Never compare two systems' raw scores without proving they are on the same scale.
LifelongAgentBench Status
lifelongagentbench (arXiv 2508.19005) has NO adapter here: the external
runner is unavailable (only traces from a prior external run exist), and
the observed 100% run was a metric artifact — the runner lacked a gold oracle,
so e.g. a NULL-primary-key task graded as pass. Do not cite that number.
Status: blocked until a real runner with gold labels is obtained.