A clear contract
A concise description of the expected behavior, checked for originality and approved by a human.
Inside the quest / A visual field guide
A hard problem.
Made visible.
What actually happens between finding an edge case and creating a challenge worth solving?
A small world for serious work. Follow three tiny contributors through the quest lab as they turn an idea into evidence, one workstation at a time.
8 chapters · One careful processAct 01 / ScoutReading the repository
builder / on the moveSmall world. Real engineering.
builder says
“There is an edge case here.”
repo@commitWorkbench / repo@commit
- open repository / inspect license
- waiting for this step
- waiting for this step
- waiting for this step
01 / 08
Chapter 01 / Scout
Start where the real work lives.
Explore an eligible open-source repository. Pin a specific commit, understand the code, and identify a meaningful bug or missing capability. Check existing issues and solutions before choosing the problem.
What this produces
- Pinned commit
- Bug or feature
- Originality research
Why this matters
The challenge should come from a real engineering need. Originality and a precise starting point make the result useful and reproducible.
The builderFinds the problem and builds the proof.
The solverTests what works and where agents get stuck.
The reviewerChecks clarity, fairness, and the evidence.
An illustrated explanation of the contributor process. Trial criteria are checked against the current review requirements.
What the work produces
Four pieces.
One consistent story.
The brief, tests, solution, and environment all describe the same problem. Every revision has to keep them aligned.
A fair measurement
Focused tests for the approved behavior. The intended failure appears on the untouched starting commit.
A proof of solvability
A complete reference implementation that passes the tests and preserves existing behavior.
A repeatable starting point
A built container and a small runner so the same checks can be reproduced in a controlled environment.
The parts you should never skip
Difficult is useful.
Fair is essential.
Good challenges test engineering judgment. The workflow checks the environment, the measurement, and the interpretation as carefully as the solution.
Why pause for a human before building?
The edited workflow calls for an originality check followed by a human refinement and approval of the problem description. The approved brief stays fixed during artifact creation. A later requirement change returns to this checkpoint.
Why do the baseline and reference both matter?
The new test should fail on the unmodified starting commit for the intended reason, then pass with the reference solution. That separates a real behavioral gap from an environment failure or a test that does not measure the change.
What happens when the checks find a problem?
Inspect the evidence and repair the cause. Test gaps and implementation defects return to the artifacts; ambiguity that changes the contract returns to the brief. Rebuild a changed environment, rerun affected checks, and refresh stale scope results before more agent trials.
What do agent trials tell us?
Completed, unhinted batches show how independent agents handle the task. Inspect their patches, failed tests, reasoning, and long-horizon evidence against the live criteria. Invalid runs and environment blockers are investigated separately. Re-evaluation is useful only when the platform accepts it for the current content and agent lineup.
Does a passing review mean automatic acceptance?
Auto Review is another evidence check. The contributor reads its full result, resolves blockers, and makes the final submission themselves. Review readiness, submission, and acceptance are separate milestones.
Now you know the process