Grex 2.0 · October–November 2026
Can Grex repair a missed customer-journey defect?
An assisted test exposed stale resale fees. Grex supplied the repair, which passed focused checks and was independently verified after deployment.
Completed · one repair verified
Changing the resale platform left item and batch profit based on the old platform’s fee. Grex produced a two-line product repair and six focused regressions across three executions. Independent checks confirmed the released behavior. This is one assisted, verified repair, not proof of autonomous discovery or an entirely green application test suite.
The experiment, explained
A narrated explanation of recorded results, with synthetic narration and visible English captions. Diagrams explain the method; they are not recordings of execution.
Read the video transcript
A journey existing tests missed
Changing a resale platform should update its fee and the expected profit. In this case, the interface kept the old calculation even though the existing selected tests were green.
Assisted discovery
A frontier assistant selected the risk, reproduced the defect and supplied its cause. This was assisted discovery. Grex was asked to make a bounded repair, not independently find the bug.
One repair, three executions
Grex produced the calculation repair and focused regressions. Two executions were rejected because operator-authored evidence was insufficient. The third supplied the required checks and received independent acceptance.
A concrete before and after
For the retained synthetic fixture, the fee changed from eight dollars sixty one to six dollars fifty. Expected net changed from twenty eight thirty nine to thirty fifty.
Verify what was released
Independent verification checked the exact released frontend, three platform choices, item and batch totals, and the existing fee override. At this release, the broader mock suite had seven failures.
One verified repair
The result is one verified repair. It does not establish autonomous discovery, real valuation quality, customer impact or sustained reliability. Those questions require different evidence.
What were we trying to find out?
Can an evidence-driven repair workflow turn a missed frontend journey defect into a reviewed and deployed correction?
Hypothesis
A focused journey check might expose a defect that existing tests miss, and Grex could produce a repair that survives independent acceptance.
Retrospective framing of the recorded case, not a prospective controlled hypothesis. A frontier assistant selected the risk, supplied the symptom and cause, and authored the synthetic browser check. Grex did not independently discover this defect.
How the experiment worked
Use a synthetic browser fixture to reproduce a stale-fee calculation, ask Grex to repair the selected behavior, then independently verify the exact accepted code and deployed frontend.
Frontier assistance
- Choose risk + reproduce defect
- Provide symptom, cause and check
Grex repair
- Repair calculations + regressions
- Reject → reject → accept
Independent source review + deployed browser verification
1 repair; assisted discovery; broader mock suite was 117/124 at this release.
Download the method illustration
Sample: One established product defect in a resale-analysis application. Two other observations did not establish defects and are not counted as repairs.
Select and reproduce the journey
A frontier assistant inspected the code, selected the platform-switch risk and wrote a synthetic check that failed on unchanged code.
Ask Grex for a bounded repair
Supply the known symptom and cause. Grex changes the fee and net calculations and adds focused regression checks.
Review the evidence contract
Two executions were rejected because operator-authored evidence was insufficient. The third supplied the required machine-recorded checks.
Verify the released behavior
A separate reviewer checked the diff and browser behavior. Test and production verification confirmed the exact released frontend assets and platform-dependent totals.
Controls and differences
- The focused regression failed on unchanged source before the final repair passed it.
- The accepted source tree matched the merged tree, and released asset hashes were checked across test and production.
- Independent verification covered three platform selections, item and batch totals, and the existing explicit dollar-fee override.
- Synthetic responses and generated images isolated the frontend behavior; they did not exercise real valuation, backend persistence or commercial outcomes.
What happened
| Measure | Before / attempted | Final scoped result |
|---|---|---|
| Retained synthetic fixture: fee / net | $8.61 / $28.39 | $6.50 / $30.50 |
| Focused before / after checks | 2 failed before | 8 passed after |
| Application unit tests | 91 passed before | 97 passed after |
| Native worker execution outcomes | Rejected · rejected | Accepted on third execution |
| Broader four-tenant mock suite at this release | Outside the scoped release gate | 117 / 124 passed; 7 failed |
Existing green tests missed the journey
Ninety-one application unit tests and six selected browser journeys passed before the new platform-switch regression exposed the stale calculation.
Grex supplied the product repair
The accepted change added the selected platform to two calculations and included six focused regressions. The frontier assistant made no permanent product-source repair edits.
The rejected attempts exposed authoring gaps
The first packet lacked sufficient behavioral evidence. During the second attempt, an operator repository change cleared saved checks and they were not restored. Those rejections do not demonstrate runtime evidence loss or a wrong causal repair.
Verification was scoped and concrete
The final submission passed two-before-red and eight-after-green focused checks, all 97 application unit tests and four tenant builds. Independent deployed browser checks confirmed the selected behavior.
A wider suite was red at this release
At this case’s release, the broader four-tenant mock run passed 117 of 124 tests. Only two failures were reproduced on the untouched prior revision; the case did not establish that all seven failures pre-existed. This is a historical observation, not the current pipeline status.
What this does not establish
- Discovery and test design were assisted. This was not autonomous Grex browser discovery or an unassisted end-to-end quality workflow.
- One synthetic fixture and one verified production repair do not establish customer impact, revenue, real valuation accuracy or sustained reliability.
- This case did not qualify the broader multi-tenant/backend pipeline; the accepted release used the specifically reviewed frontend path. Later pipeline work is a separate record.
- Worker execution time, reviewer time and queue delay are different measures. Complete operator effort and all-in cost were not measured.
- Requested worker configuration did not prove the actual model identity in the retained receipts, so no worker-model performance claim is made.
The decision
Accept the specific frontend repair after independent source and deployed-behavior checks. Preserve the failed evidence packets and broader suite failures in the case record.
What followed
This case verified the repair once in production. It did not establish sustained reliability, autonomous discovery or broader pipeline acceptance; subsequent work must be assessed separately.
Evidence and further reading
Public summaries retain the reported counts and limitations. Private execution traces and infrastructure details are not published.
- Download the evidence summary
Sanitized aggregate transcription of retained study reports and final closeout evidence. This is not a raw-data release or independent reproduction.