Skip to content

chore(tests): drop expected_turns from every task YAML - #2711

Closed
bai-uipath wants to merge 1 commit into
mainfrom
bai/remove-expected-turns
Closed

chore(tests): drop expected_turns from every task YAML#2711
bai-uipath wants to merge 1 commit into
mainfrom
bai/remove-expected-turns

Conversation

@bai-uipath

Copy link
Copy Markdown
Contributor

The consumer-side cleanup for Proposal: optimizing for wall clock time instead of expected turns. The producer is coder_eval_uipath#86, which derives each task's expected wall clock from run history and stamps it into run.json; the evalboard half is coder_eval#125.

expected_turns is removed from all 935 task YAMLs that declared it. Nothing reads it any more: the expected line is now derived per task and per harness from the runs already in blob storage, so there is no number to type and none to go stale.

Why the field is not worth keeping

Problem Evidence
It was never maintained 147 commits in this repo touched expected_turns; six revised a value
The seed was a best-case extreme Bulk-seeded from the luckiest run ever observed, so 44.7% of passing budgeted tasks exceed budget on a healthy night
Post-seed values are guesses 49% are multiples of 5, and 204 tasks share a copy-pasted 300 against a p90 actual of 52, so they are permanently green
Coverage holes sat on the slow tasks 249 of 1002 tasks had no budget at all, and they held 34.7% of task-seconds
A turn is not a unit of time A Read and a 20-minute deploy both count as one
Not comparable across harnesses On identical tasks Codex uses 0.50x Claude's turns

Scope

Only expected_turns goes. max_turns, turn_timeout and task_timeout are untouched, so every real cap and timeout in the suite is unchanged. The 239 run_limits blocks whose only key was expected_turns are removed outright rather than left empty. Eight comments that justified a turn budget were rewritten or dropped so no prose is left pointing at a field that no longer exists.

Safe to merge in any order relative to the two PRs above: expected_turns stays accepted and ignored on RunLimits, and a task without it reads as unscored rather than erroring.

Testing done

  • Every one of the 1191 task YAMLs parses and validates against TaskDefinition, and the same 12 tasks fail validation before and after this change, all for reasons unrelated to run_limits (the local venv's coder_eval predates skill_triggered, advisory zero weights, and sandbox.record_cli).
  • coder-eval plan over the full suite: 1191 tasks planned, the same 12 pre-existing errors, no run_limits or expected_turns diagnostics.
  • Machine-checked that the diff is semantics-preserving: each of the 935 files was loaded before and after and compared as parsed YAML, with the only permitted difference being the dropped key and the dropped empty block. Zero mismatches.
  • No file gained a blank-line run or lost its trailing newline.

Nightly runs now score wall clock instead of a turn budget. The expected
line is derived per task and per harness from the runs already in blob
storage and stamped into run.json (coder_eval_uipath#86); the evalboard
reads that stamped value (coder_eval#125). Nothing consumes
expected_turns any more, so the 935 declarations here are dead weight.

The field was never maintained: it was bulk-seeded from the luckiest run
ever observed, 49% of the values are multiples of 5, and 204 tasks share
a copy-pasted 300 against a p90 actual of 52. It also cannot compare
across harnesses, since a Read and a 20-minute deploy both count as one
turn.

expected_turns stays accepted and ignored on RunLimits, so this lands
safely in either order relative to the two PRs above. run_limits blocks
left with no other key are removed outright; max_turns, turn_timeout and
task_timeout are untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Claude finished @bai-uipath's task in 3m 25s —— View job


PR Review: chore(tests): drop expected_turns from every task YAML

  • Read review criteria and project conventions
  • Read PR diff and conversation
  • Spot-check changed files for correctness
  • Post review findings

Summary

Removes the expected_turns field from all 935 task YAMLs that declared it. Where expected_turns was the only key in a run_limits block, the entire block is removed. Five files have comment rewrites to update prose that previously referenced expected_turns. All other run_limits fields (max_turns, turn_timeout, task_timeout) are untouched.

Change-by-Change Review

1. Mechanical expected_turns deletion (930 files)

Severity: OK

Two clean patterns applied uniformly:

  • Pattern A (239 files): run_limits block contained only expected_turns → entire block removed (3-line deletion).
  • Pattern B (691 files): run_limits block contained other keys → only the expected_turns line removed (1-line deletion).

Verified: zero expected_turns references remain anywhere in tests/tasks/. No empty run_limits blocks were left behind. No blank-line runs introduced. No files outside tests/ were touched.

2. tests/tasks/uipath-agents/coded/guardrails/escalation/escalation.yaml

Severity: OK

Comment rewritten: removed the sentence "expected_turns drives the cap in coder-eval" and rephrased to explain max_turns is kept for parity. Accurate — the comment now describes what actually remains.

3. tests/tasks/uipath-agents/lowcode/eval_run/eval_run.yaml

Severity: OK

Collapsed two comment blocks (one justifying expected_turns: 80, one justifying max_turns: 120) into a single block that explains max_turns: 120 with the observed 80-turn baseline. Good — the provenance data (2026-08-11 sonnet-5 run) is preserved, just the dead reference removed.

4. tests/tasks/uipath-agents/lowcode/guardrails/escalation_app/escalation_app.yaml

Severity: OK

Comment changed from "expected_turns is 41" to "A clean run takes ~41 turns". Accurate substitution — same number, better framing now that the field is gone.

5. tests/tasks/uipath-agents/lowcode/solution_deploy_activate/solution_deploy_activate.yaml

Severity: OK

Comment block consolidated: the run-data provenance (37 and 61 assistant turns from 2026-08-12 sonnet-5 runs) is preserved inline in the max_turns comment rather than split across an expected_turns comment. Clean.

6. tests/tasks/uipath-coded-apps/e2e_orchestrator_dashboard_web_app.yaml

Severity: OK

Top-level comment changed from "max_turns 85→110, expected_turns 45→90" to "max_turns 85→110". Accurate — the expected_turns history is no longer relevant.

What's Missing

Nothing identified.

Area Ratings

Area Status Notes
Frontmatter OK No frontmatter changes — all edits are to run_limits blocks
E2E Tests OK No test logic changed — only the dropped field and associated comments
Skill Body N/A No skill files touched
References & Assets N/A No reference files touched
Repo Hygiene OK All changes scoped to tests/tasks/, no secrets, no unrelated edits

Issues for Manual Review

None found.

Conclusion

Clean, well-scoped mechanical cleanup. The 930 single-pattern deletions are correct, and the 5 comment rewrites are accurate — each preserves the run-data provenance while removing references to the now-dead field. CI is green (8/8 completed checks passing, 3 in progress). No issues found — approve.

@github-actions

github-actions Bot commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Claude finished @bai-uipath's task in 2m 28s —— View job


Coder-eval task lint (advisory)

935 task YAMLs modified; 0 Critical, 0 High, 0 Medium, 0 Low, 935 OK.

Rubric: .claude/commands/lint-task.md. This check is advisory and never blocks merge.

Evidence of passing run

✅ Author confirms semantic preservation: "Machine-checked that the diff is semantics-preserving: each of the 935 files was loaded before and after and compared as parsed YAML, with the only permitted difference being the dropped key and the dropped empty block. Zero mismatches." and "Every one of the 1191 task YAMLs parses and validates against TaskDefinition" and "coder-eval plan over the full suite: 1191 tasks planned, the same 12 pre-existing errors, no run_limits or expected_turns diagnostics."

This PR removes a single unused metadata field (expected_turns) across all tasks. No task behavior, prompts, criteria, or real caps (max_turns, turn_timeout, task_timeout) changed. A per-task passing-run claim is not warranted for a semantics-preserving field removal.

Per-task lint

All 935 files: verdict OK — no rubric axis applies.

The diff falls into exactly two mechanical patterns:

  1. 930 files — pure removal of expected_turns: line (and run_limits: block when it was the sole key). No other content changed.

  2. 5 files — same removal plus comment rewrites that drop stale references to expected_turns:

    • tests/tasks/uipath-agents/coded/guardrails/escalation/escalation.yaml
    • tests/tasks/uipath-agents/lowcode/eval_run/eval_run.yaml
    • tests/tasks/uipath-agents/lowcode/guardrails/escalation_app/escalation_app.yaml
    • tests/tasks/uipath-agents/lowcode/solution_deploy_activate/solution_deploy_activate.yaml
    • tests/tasks/uipath-coded-apps/e2e_orchestrator_dashboard_web_app.yaml

    All 5 comment rewrites are correct — they preserve the rationale for max_turns/task_timeout while dropping the now-irrelevant expected_turns references.

No task was changed in a way that affects any rubric axis (self-report, prompt over-specification, meaningful coverage, gameability, near-duplicate, validate-only, CLI verb reachability, sandbox config, or run-limit placement). The rubric evaluates task design quality; this PR modifies no task design.

Within-PR duplicates

No new tasks added; check not applicable.

Conclusion

✅ All 935 changed tasks pass the rubric. Clean mechanical removal of an unused field. The 5 comment rewrites are well-crafted. No issues found.

@bai-uipath

Copy link
Copy Markdown
Contributor Author

Closing this PR as we'll keep this field for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants