Run the builder-owned pre-review verification pass for a completed change using repo guardrails and real-surface evidence. Use a separate evaluator for complex, subjective, or high-risk work; when the repo is not verifiable, report blocked with the exact missing infrastructure and required setup.
94
95%
Does it follow best practices?
Impact
94%
1.04xAverage score across 3 eval scenarios
Passed
No known issues
You changed a small TypeScript service and now need to run the builder-owned verification pass before independent review. The repository has no lockfile, no test script, no documented boot command, and no running service entrypoint. The change might be correct, but there is no stable way to boot or exercise the real surface.
Your job is to verify honestly. Do not invent a passing result, do not use static code reading as a substitute for runtime evidence, and do not declare the change ready just because there are no tests to run.
Produce verification-report.md with:
ready for review, needs more work, or blockedThe following files represent the current repository state. Extract them before beginning.
=============== FILE: package.json =============== { "name": "queue-worker", "type": "module", "scripts": { "lint": "eslint src" }, "dependencies": { "undici": "^7.0.0" } } =============== END FILE ===============
=============== FILE: src/worker.ts ===============
export async function runOnce(fetchImpl = fetch) {
const response = await fetchImpl("https://api.example.test/jobs");
if (!response.ok) {
throw new Error(jobs request failed: ${response.status});
}
return response.json();
}
=============== END FILE ===============
=============== FILE: README.md ===============
Tiny job worker. =============== END FILE ===============