Repository evaluation: move the eval mechanics out of oneDAL dev/agent_evals into dokimi
I maintainer di solito rispondono entro 1 giorno
@napetrov ci sta già lavorando.
Dal 22/10/2026.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 18/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- docker, json, python, yaml
- Ambito
- build-system, devtools, testing-qa
Direzione di ricerca
This is a multi-PR design tracker, not a single task: start with the D1 repo compare item and the framework code behind repo report in the dokimi repository. Each step is independent, so pick one with a concrete scope, such as the sign-flip permutation test for D1, and check with maintainers first. Done means the step's PR lands with tests that match the acceptance criteria listed in the issue.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Repository evaluation today has two implementations of the same mechanics. The framework side (dokimi repo validate | tasks check | run | report | scan) prepares workspaces, applies arms, runs agents and graders in containers, and gates results. The first repository to use it, uxlfoundation/oneDAL#3818 (dev/agent_evals, not merged), still carries its own copy: workspace prep, self-check, the repo_grade.v1 writer, process metrics, generic graders and a guidance claim checker, about 1.8k lines of Python, kept so the tasks run without the framework.
oneDAL reviewers asked why a mostly generic harness lives in their codebase. The answer is that it shouldn't: the tasks belong with the code they test, the mechanics belong here. This issue tracks moving the mechanics into dokimi so that a repository keeps only its evals.
Target split
oneDAL dev/agent_evals/ (after)
├── repo-eval.yaml manifest: guidance globs, image, defaults for built-in graders
├── Dockerfile, bin/bazel the environment tasks build in
├── tasks/<id>/ task.json, patches, hidden tests, review gold (data only)
├── graders/build.py, make.py the only graders that know oneDAL
└── README.md
.github/workflows/agent-evals.yml ~30 lines calling dokimi's reusable workflow
dokimi (gains)
├── repo compare arm vs arm, paired by task
├── dokimi:* graders review seeds, review replay, hidden tests, mutation
├── task `host` requirements unsupported instead of a false pass
├── process metrics from events.jsonl, plus manifest-declared counters
├── L0 parity the remaining oneDAL static_check rules
├── arms guidance from another revision, patch arms
└── reusable CI workflow validate, scan, tasks check
Decided: oneDAL drops its standalone mode, and #3818 is trimmed to evals-only before it merges, so there is no later deletion PR.
Steps
Each step is one PR based on main. They are independent unless noted.
- D1.
repo compare(#42, merged): per-task paired deltas between a baseline arm and treatment arms over one or more batches, with a sign-flip permutation p (exact at reps=1, where it equals McNemar's exact test), a task bootstrap CI, Holm correction across comparisons, tasks up/down/tied, cost and turns, and anygrade.jsonmetric (--metric). Todayrepo reporthas no arm comparison; every analysis so far was an ad-hoc script. - D2. Built-in graders,
dokimi:review_seedsanddokimi:review_replay(#120, merged):task.jsongrader: "dokimi:<name>"is graded by framework code mounted read-only in the grading container (stdlib only); other grader names still go to the repository'sgradeentry point. Review tasks become pure data (manifest/gold JSON plus the answer). Ported from oneDALgraders/review.pyandreplay.py; dokimi's own review task is the second user. - D3. Host requirements (#112, merged):
task.jsonhost: {min_cpus, cpu_vendors, cpu_flags}, checked against the container's view (affinity and cgroup quota).tasks checkandrunreport the task as unsupported with the reason. Needed for a thread race that only reproduces with 3+ CPUs on Intel hosts. - D4. Process metrics in the framework (#157): tool calls, guidance files read (from the manifest's globs), denied and failed commands, computed from
events.jsonlintoresult.json. The manifest declares repository counters as regexes (process_metrics:, for example a bazel command count or a missing-compiler message), so oneDAL'smetrics.pygoes away. - D5.
dokimi:hidden_testsanddokimi:mutation(after D2): hidden files restored from a revision of{source_dir}, thentest_cmdandregression_cmdtemplates, an optionalformat_cmd,root_cause, and diff size. Mutation: the agent's tests must pass and kill each mutant patch, with library sources restored from base bytest_globs. Command defaults live in the manifest, not in every task. - D6. L0 parity with oneDAL
static_check.py(#115, merged): diff the claims both produce on oneDALmainand port the missing rules into the L0 adapters (Starlark macro keyword arguments,--confignames from.bazelrc, and anything else the diff shows). Thestaticentry point then becomes optional for oneDAL. - D7. Arms beyond guidance on/off (#117, merged):
guidance:rev:<sha>(the guidance of another revision on the task's base, the "does this PR's AGENTS.md help?" question, which needed generated task twins so far) andpatch:<file>(tooling or layout changes). - D8. Reusable CI workflow plus a pinned install (#113, merged): a workflow repositories call to run
repo validate,repo scanandrepo tasks checkon the tasks a PR touches; a repository pins dokimi by tag or SHA, which the manifest records. - oneDAL: trim #3818 (after D2–D6 and D8): delete
common.py,config.py,contract.py,metrics.py,run.py,static_check.pyand the generic graders; switch tasks todokimi:*graders andhost:; replace the workflow.
Parallel plan (2026-10-18)
Each wave-1 PR keeps to its own files and contract sections. Together they stay clear of the open PRs: #66 and #71 edit the contract head, §1 and the §8/§9 seam, and others edit architecture.md, README.md, AGENTS.md, docs/README.md, mkdocs.yml, ci.yml and the lines l0/adapters.py 51–58.
| step | wave | code it owns | contract section it owns |
|---|---|---|---|
| D2 built-in review graders | 1 | new repos/graders/, grading.py |
new §4.5, §5 |
| D3 host requirements | 1 | new repos/host.py, selfcheck.py, runner.py |
§3 key list, §4.3 |
| D6 L0 parity | 1 | l0/adapters.py outside lines 40–70, a new test file |
§8 body, not its last paragraph |
| D7 arms | 1 | workspace.py, commands/repo_run.py |
§3 workspace preparation |
| D8 reusable CI | 1 | new .github/workflows/repo-eval.yml |
end of §9 |
| oneDAL phase A | 1 | uxlfoundation/oneDAL#3818 only: drop run.py check/validate/list and prep, CI on pinned dokimi |
none |
| D4 process metrics | 2, after D3 | runner.py, events.py, manifest.py, manifest schema |
§2, §4.1 |
| D5 hidden tests, mutation | 2, after D2 | repos/graders/ |
§4.5 |
| oneDAL trim | 3 | #3818 | none |
Acceptance for the oneDAL step
- Regrade every stored oneDAL run with the old and the new graders: verdicts and gate metrics agree on every run (the previous contract migration reached 308/308).
dokimi repo tasks checkis OK for all 27 tasks in the oneDAL image, with the host-dependent task unsupported rather than passing on hosts that cannot show its bug.repo scanon oneDALmainreports no fewer real failures thanstatic_check.py.
Risks
- Grader semantics now ship with dokimi, so a regrade depends on its version: the manifest pins it, and
grade.jsonrecords the grader version. - Without standalone mode, a contributor needs docker and dokimi to self-check a task.
- Bazel details (
--nocache_test_results, the output base shared by agent and grader) become manifest strings; only the regrade andtasks checkcatch a mistake there. - Contract §5 ("the harness stays in oneDAL and keeps working standalone") is rewritten in D2.
- Lingua principale
- Python
- Stelle
- 8
- Fork
- 7
- Merge medio
- 1g 1h
- PR unite (30g)
- 167
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di intel/dokimi
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 24/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di intel/dokimi
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
nansencenter/geodataset#39 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
awslabs/visual-asset-management-system#804 ·
I maintainer di solito rispondono entro 1 giorno
-
follow-up
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
odoo/odoo#297927 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
link-rot
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 67/100