You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
perf(test): cut audit-engine.test.sh's Windows wall clock (1660 s against 135 s on Linux) #13229
Parent: #3716 (criteria 3 and 4). Measured in #10241, docs/test-wall-clock-baseline.md.
Problem
plugins/harness-config/skills/audit/scripts/audit-engine.test.sh took 1660 s on the Windows Git Bash host in #10241's corpus run, against 135 s on Linux CI: 12 times slower, and on its own nearly three times the 10-minute budget for the whole Windows corpus. Git Bash pays per process spawn (#3716 summary), so a suite this far behind Linux almost certainly spawns per case or per line.
Fix
Profile the suite and the engine it drives with scripts/run-plugin-tests.sh's timing option (#10200) and a spawn count. Cut the spawns the way #3716 step 3 lists: builtins over subprocesses, one batched git or jq call over many, hoisted find walks, shared fixtures over a fresh mktemp -d per case. The suites must pass unchanged, so behavior is preserved.
Done when
Linux wall clock for the suite, before and after, is in the PR body
The Windows time, re-measured on a Windows Git Bash host, is in the PR body and in the suite's row in docs/test-wall-clock-baseline.md
The suite's assertions are unchanged (any test edit is a fixture or harness change, named in the PR body)
ci-status is green on the PR head
Split by the backlog HITL session from #10241's result. This was generated by AI.
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: cut process spawns in audit-engine.test.sh and the engine it drives, so the suite runs faster (1660 s on Windows Git Bash against 135 s on Linux). The assertions must stay unchanged and ci-status must be green.
Done-when item 2 needs a Windows Git Bash host re-measure. An unattended lane run can't do that, so it is split off for the host queue. The other items can be triaged here as usual. Nothing is missing from the issue.
Related, not duplicates: #3716 (parent), #13231 and #13232 (sibling suites).
Not admitted to the issue lane: its done-when asks for what an unattended lane run cannot perform: item 2 (measure-over-time: "The Windows time, re-measured on a Windows Git Bash host, is in the PR body a..."); recommended split: keep the other items here as the admissible issue and move these to a child issue for the host queue (host-run). Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).
Decision recorded. Route this issue to the host queue whole, for a laptop lane with a Windows Git Bash host.
Agent choice, not an owner answer.
Admission refused it for the lane because Done-when item 2 needs a Windows Git Bash host, and a child issue for that one step would raise the open count, so the issue goes host-run instead. The spawn cuts and the Linux before/after can be built and measured on Linux; only the Windows re-measure needs the Windows host, so one host session does the whole change in one PR. The body's Done-when stands unchanged.
On a fleet host with Windows Git Bash, re-measure the suite before and after the change and record both times in the PR body and in the suite's row in docs/test-wall-clock-baseline.md.
The work-resolve-issue lane stopped on this issue (host-only): the run reports the work needs a host run the lane cannot make.
It added host-run and removed agent-ready: an agent run on a host builds it, and it waits on no decision from a person.
In the run's words:
host-only: the work needs the suite profiled and timed (scripts/run-plugin-tests.sh timing option plus a spawn count on audit-engine.test.sh and audit-engine.sh), and done-when item 1 needs the Linux wall clock before and after. This lane's Bash runs only the named check and verify wrappers, so it cannot run the suite, time it or count spawns. Spawn cuts were already merged in #6400 and #7189, so what remains has to be found by profiling; editing the 2539-line engine without running its suite would be a guess.
What the run says it did not do:
Profile audit-engine.test.sh and audit-engine.sh (timing option and spawn count): the lane cannot run scripts
Linux wall clock before and after for the PR body: the lane cannot run the suite
Merged in #13281 (7f6329b). Windows Git Bash: 1336 s, against 1660 s recorded in docs/test-wall-clock-baseline.md (about 20% less). Linux, paired runs: median 115.4 s before, 80.0 s after; process starts down 31%.
A same-day Windows run before the change took 2714 s, but other jobs on this laptop overlapped it, so it is not used as the before figure. At 1336 s this suite still takes more than twice the 10-minute budget for the whole Windows corpus, so #3716 should not count it as solved. What remains is mostly per-case engine runs (174 in the suite).
Posted by host-run Lane 5. This was generated by AI.
Activity
github-actions commentedon Nov 4, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Medium
Complexity: Medium
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: cut process spawns in audit-engine.test.sh and the engine it drives, so the suite runs faster (1660 s on Windows Git Bash against 135 s on Linux). The assertions must stay unchanged and ci-status must be green.
Done-when item 2 needs a Windows Git Bash host re-measure. An unattended lane run can't do that, so it is split off for the host queue. The other items can be triaged here as usual. Nothing is missing from the issue.
Related, not duplicates: #3716 (parent), #13231 and #13232 (sibling suites).
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Nov 4, 2026
Not admitted to the issue lane: its done-when asks for what an unattended lane run cannot perform: item 2 (measure-over-time: "The Windows time, re-measured on a Windows Git Bash host, is in the PR body a..."); recommended split: keep the other items here as the admissible issue and move these to a child issue for the host queue (
host-run). Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Nov 4, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.8 remaining items
github-actions commentedon Nov 4, 2026
kyle-sexton commentedon Nov 4, 2026
Decision recorded. Route this issue to the host queue whole, for a laptop lane with a Windows Git Bash host.
Agent choice, not an owner answer.
Admission refused it for the lane because Done-when item 2 needs a Windows Git Bash host, and a child issue for that one step would raise the open count, so the issue goes host-run instead. The spawn cuts and the Linux before/after can be built and measured on Linux; only the Windows re-measure needs the Windows host, so one host session does the whole change in one PR. The body's Done-when stands unchanged.
docs/test-wall-clock-baseline.md.github-actions commentedon Nov 4, 2026
melodic-automation-lanes commentedon Nov 4, 2026
The work-resolve-issue lane stopped on this issue (
host-only): the run reports the work needs a host run the lane cannot make.It added
host-runand removedagent-ready: an agent run on a host builds it, and it waits on no decision from a person.In the run's words:
What the run says it did not do:
Run: https://github.com/melodic-software/claude-code-plugins/actions/runs/41838630048
To hand it back to the lane, remove
host-runand addagent-readyagain.kyle-sexton commentedon Nov 4, 2026
chore(harness-config): name the fragment and mark the jq program for …
docs(test-wall-clock): record audit-engine's Windows time after #13229
kyle-sexton commentedon Nov 4, 2026
Merged in #13281 (7f6329b). Windows Git Bash: 1336 s, against 1660 s recorded in
docs/test-wall-clock-baseline.md(about 20% less). Linux, paired runs: median 115.4 s before, 80.0 s after; process starts down 31%.A same-day Windows run before the change took 2714 s, but other jobs on this laptop overlapped it, so it is not used as the before figure. At 1336 s this suite still takes more than twice the 10-minute budget for the whole Windows corpus, so #3716 should not count it as solved. What remains is mostly per-case engine runs (174 in the suite).
Posted by host-run Lane 5. This was generated by AI.