流马 liuma
中文 Bring one problem
Trajectory 01 · UNATTENDED-ACCEPTANCE

Unattended acceptance

The acceptance contract is echoed back and can be changed in one sentence. Every round’s verdict carries environment evidence. Output arrives as an image in the conversation. Before delivery it passes the buyer’s own script, then renders the result and looks at it.

Where
2026-08-08 · SG production
Duration
about 16 minutes · 2 rounds
Scale
68 messages · 30 tool calls
Prerequisites
nothing installed · nothing connected · no credentials
Full timeline · times in UTC

From handover to acceptance, nine beats.

Start
14:33:44
Setup: the data base file is handed over as an attachment and stored in the org workspace.
The path is given a business-neutral name. Put business in the filename and the base file leaks into the capability layer — for a customer outside logistics that name would be wrong on arrival.
14:37:57
You hand over the work, with your own acceptance script attached.
"This script is the spec. It must reach verdict=pass, and not one character of it may change; before delivering, you have to render the result and look at it yourself." The task prompt contains no company name, no entity name, and not one number.
Unattended steps
Unattended · round 1
It reads the base file and the acceptance script, and echoes the contract back as a card.
Goal, the four acceptance checks, the verifier command line, the budget — all on the card. This is not an approval workflow: the criteria are laid out for you and you can keep changing them in plain language.
Unattended · round 1
The frozen verifier stops the first candidate.
pages unreachable from entry page dashboard: driver-detail, waybill-detail
Unattended · round 1
It converges against the error list, reruns, and clears all four checks.
The two list pages get their 13 missing drill-down edges (8 waybills + 5 drivers), and the 2 return edges on the detail pages stay. The failure changed the next candidate; it was not talked around.
Unattended · round 1
Passing the script is not enough to send the file: it renders the pages and looks at them first.
The rendered result enters the session timeline as an image, and only then does it write the round 1 verdict: pass / 100, each of the four named checks passing with its own /workspace/report.json evidence reference.
14:45
In one sentence you add two more criteria. The script still may not change.
"The dashboard needs a total freight figure covering every waybill; the driver detail page must show all waybills under that driver." No second contract card is issued — the change is tracked by your message, its reply, and the round 2 verdict together.
Unattended · round 2
A sixth metric and a related sub-table go in. It reruns; all four pass again.
4200 + 1800 + 3150 + 900 + 2400 + 1250 + 0 + 3300 = 17000. Total freight is a full-table sum with no where clause; the driver detail page gets its related-waybill sub-table keyed on driver_id.
Acceptance
14:48:35 → 14:49:37
Round 2 is judged pass / 100, selected as best, and the delivery card points at prototype.html.
23,959 bytes, one file, no CDN, no second file. From here, you accept it.
Key frames · captured in a native browser on physical Windows, unretouched

The seven frames this run left behind.

The user hands over the work with the acceptance script attached
01 Handover. The task prompt carries only file paths and structural requirements; every business value lives in the base file.
The rendered result enters the session timeline as an image
02 It reads the base file and the script, and sets the contract. The rendered result goes straight into the timeline as an image.
Sandbox output showing verdict fail and the unreachable page list
03 The frozen verifier returns fail and lists every violation at once, rather than stopping at the first.
The round 1 verdict card listing four named checks with evidence references
04 Round 1 verdict: four named checks, each passing, each with its environment evidence reference.
The user adds two criteria and liuma confirms it will continue under them
05 You add two criteria. It confirms it will continue under them, and the script still does not change.
The round 2 verdict card and the final delivery card
06 Only after round 2 clears all four checks and the render is confirmed does the delivery card go out.
The acceptance contract card and the round 1 verdict card in full
07 The full view: contract card above, verdict card below. Goal, criteria, verifier command line and budget all in the open.
The exam

The criteria came in with the buyer. They are not ours.

The acceptance script was frozen before any candidate existed. It judges the delivered file itself — environment fact, not the model’s description of its own output. All four checks run in one pass and every violation is listed; it does not stop at the first.

verify_prototype.py · four mechanical checks
sha256 527fd455… · 352 lines · zero dependencies · 6 calibration fixtures, 6/6 re-verified as designed
single_file
exactly one HTML document, no cross-file or remote reference
reference_integrity
every page reference resolves inside this document’s config
positive_connectivity
from any page, every menu-declared page is reachable
data_consistency
every declared metric equals the value recomputed from its rows
candidate ①
round 1
round 2 · best
pass
fail
the run left no evidence for this cell, so it stays empty
Rubber-stamp control

During the audit the 17000 in the delivered file was hand-edited to 17100. The verifier failed immediately: declares 17100 but its rows compute 17000. It computes from the rows; it does not read the claim.

Final read-only audit · an independent stage that takes no self-report on trust

After delivery there is one more gate, and it is ours to fail.

Frozen verifier, re-run independently
pass · all four
Data vs base file, field by field
waybills 8/8 · drivers 5/5 · zero differences across seven fields
All 6 metrics recomputed by hand
all consistent
External references
0 · single file · no CDN
Real browser walk · driver detail
the sub-table is correct, but the driver’s own five fields are all empty
Honest observation · kept exactly as it happened

On the driver detail page the title, the back button and the related-waybill sub-table are all correct, but the driver’s own id, name, phone, plate and depot — five fields — rendered no value at all. The root cause is that two detail cards shared one DOM id. The frozen verifier checks structure and explicitly does not check runtime rendering; the pre-delivery self-check could not follow hash routing and never reached that page. "Script passes + self-check before delivery", both together, still missed an entire class of defect. The final independent read-only audit is what caught it. This stays with the exhibit, unpolished.

Evidence index
Demo session
e91ce597-2d8d-4ca4-b0d6-cca477550c9c
Final deliverable
prototype.html · 23,959 bytes · sha256 af063c01…
Frozen verifier
verify_prototype.py · sha256 527fd455…
Version
redguard-v23.0.1+build.114
Download the full walkthrough PDF →Download the capability manual PDF →

Build one inside your organization.

To run this for another customer you replace exactly one file — the base file. Not one character of the task prompt or the acceptance script changes. That is not a claim; it was checked mechanically: of the 70 business values in the base file, 0 appear in the prompt or the script.

Bring one problem. We build it with you in 30 minutes.