The review is complete. .imd-findings.json holds two substantiated low findings; the assigned math area came out consistent.

Math area (assigned, reviewed in depth, no defect found)

• Grant limits: the server guards in goldAdminCommand, the trigger in migration 0024, and the grantLeft/grantsLeft computation all use the same rolling window (created_ms > now - 86400000), the same 5000 per grant, 20000 and 100 per window, and agree at the boundary (a grant exactly 24 hours old leaves the window in all three).
• Strike and wait clocks: strike fails a run only when attempts ≥ 3 and ≥ 1 hour since the first strike; note_wait only when ≥ 24 hours since the first wait; both require state='working', the current attempt and result_id IS NULL, so neither can end a run with a saved report. The compute limit, lease, and World's 60-second lease and 10-second timeout are consistent.
• Lapse: lapsed is true only for a pending order at expires_ms + 300000 <= now, and the vault retires only runs with no known order. Retention: prune_failed touches failed rows only, and the delivery path still answers terminal-failure from the tombstone. World's checkout pruning keeps rows with an order, so a paid undelivered order cannot lose its binding.
• Refunds: the refund credit is link.gold minus prior refunds, which equals order.amount for every GOLD service quote; it requires the job to be failed and the order paid.

Findings written

1. Low: the grant button is disabled only when grantLeft is exactly '0', so with 1 to 4999 GOLD left an administrator signs a grant the server then refuses, and the message says the limit "is reached" when it is not. WorldGoldPanel.tsx:64.
2. Low: the privacy text says unadmitted birth details are deleted "at the next cleanup" after the 15-minute window, but no cleaner handles them. They are swept only inside another wallet's successful prepare, so under paused sales or a dead bridge they stay indefinitely. vault.py:107.

Other areas, read but not fully exercised

• Signature: message fields are newline-separated with a JSON-encoded reason, origin from the request URL that is pinned to the site, admin bound to the session, request id, expiry. The replay path returns the stored result with no new effect. The test seam is not passed by the worker. personal_sign without chainId is acceptable here because the signature authorizes nothing on chain and the only verifier binds origin, admin and request id.
• Birth-time form: from the builder's diff, the sent time is always rebuilt from the two selects on submit and cleared under "unknown time", so I found no input that sends a time the buyer did not choose. The generated app.js is not in the package, so the draft-merge behaviour could not be confirmed.
• Not run: the Python suite (FastAPI is not installed here), the real engines, and the polar boundary. No Foundry proof applies, since the scope contains no Solidity.

The review is complete and .imd-findings.json holds one substantiated finding. No file in the repository was changed.

Outcome. The permission model in Submission26 held up against every attack the brief lists. I found no way to forge, stretch or replay a grant signature into a second grant, no way for one wallet to reach another wallet's run, order or checkout, and no path by which World refunds a delivered order or keeps the money for an undelivered one. The one defect I could substantiate is a status-code misclassification on the Celestao prepare route, rated low.

The finding. A request id the wallet already used, sent again with a different system or a changed input, makes vault.prepare raise an idempotency conflict. The prepare route in paid.py does not catch it, so the application-wide handler answers 503 STORAGE_UNAVAILABLE and the overlay tells the buyer to retry what can never succeed with that id. The same route maps the neighbouring lapse conflict to a named 503 on purpose, so this is the asymmetric case. From the page it is reachable only if the validated payload changes under an unchanged form, which the request's own section 4 says happens when the target date defaults to today across midnight. That trigger is a lead: the chart request model is not in the package. The direct HTTP trigger is verified by reading. No money moves and no run is lost.

Answers to the questions the brief asks of this area:

• personal_sign without chainId is acceptable here. The grant is an off-chain ledger write, nothing on any chain consumes it, and the message binds origin, administrator, recipient, amount, JSON-quoted reason, request id and expiry on separate lines with restricted character sets, so no two grants share a message. Message malleability cannot mint twice because the idempotency row is keyed by administrator and request id, not by signature.
• The test seam does not reach production. The deployed entry in worker/app.ts never passes a signer recovery override, and a test asserts the string is absent from both the worker and the vite plugin.
• The origin from the request URL is safe because the same handler refuses any origin other than the production site before it reads the body, and the local exception is loopback only.
• The replay before the signature check creates nothing. It only returns the stored result when a row with that id already exists, and the row is written in the same batch as the grant, so a grant refused by a limit leaves no row to replay.
• One wallet cannot reach another's run. Every vault read is scoped by an HMAC of the verified wallet, World's checkout rows are read with the session address, the deliver endpoint takes the wallet from World's signed body which World derives from the paid order, and a foreign run id at prepare yields a conflict without state change.
• Trust assumptions, not defects: three administrators, two of which may grant and one of which is the treasury signing in a browser; any of the three can publish a cheap top-up product; the stored grant signature in the audit log is readable by all three admins but is already consumed.

Also checked, clean by reading: the rolling-window arithmetic in code, panel and trigger agree, including grantLeft reporting zero at the count limit; the 3-attempt and 1-hour, 24-hour, 15-minute, 5-minute and 30-day comparisons all use the boundary the request text states; refund amount equals the link's gold which equals the order amount for every service product; note_wait, strike and abandon all require a working state with no saved record, so none can end a run that has a report; prune_failed touches failed runs only and a foreign-key constraint would refuse a run with a record anyway; the privacy sentences in world-wallet.js match the code, with the known caveat that unpaid cleanup runs only on a prepare.

Limits of this review. This machine has no pip and no FastAPI, httpx or cryptography, so t

The review is complete. The findings file holds two substantiated items, and no repository file was changed.

Outcome. No critical, high or medium defect was substantiated in the nine areas. The money paths hold: a run can only become failed from a working state with no saved report, a complete run is never pruned, World refunds only a job in state failed, and the refund amount is the same link gold the order was quoted at. The two reported items are below that bar.

Findings written to .imd-findings.json:

• Low, vault.py line 108. The request-id lookup in vault.prepare returns a failed run unchanged, while only the input-digest lookup excludes failed runs. The page keeps one request id per input for its lifetime, so after a refund a client that still holds that id (back-forward cache, retry after a 5xx) gets the refunded run back and a checkout link with a past expiry. The reading cannot be bought again until the id changes. The existing re-purchase test uses a new request id, so it misses this. Fix suggested: skip failed runs in the request-id path or rename the request id on failure as retire_lapsed already does.
• Info, world-wallet.js line 93. The sentence about backups holding cleared data for at most 30 more days is enforced by nobody but the operator. Already disclosed in the request; recorded so the judged report states it.

Checked and found consistent. Grant limits and rolling windows in code and trigger agree, as do grantLeft and grantsLeft. The 3-attempt and 1-hour counts, the 24-hour clock measured to the millisecond, the 15-minute compute limit, the 5-minute lapse grace and the 30-day retention all match the request's text. The grant message is unambiguous (JSON-encoded reason, origin from a URL the API already pins to the production host, request id and expiry inside the signed text), the replay path has no effect, and the test seam is not passed by the worker. personal_sign without chainId is acceptable here: the authorization is off-chain and bound to origin, administrator, recipient, amount, reason, request id and expiry. note_wait, strike, fail and abandon all require state working with no result, so none can end a run with a report, and the operator tool is serialized against the server by BEGIN IMMEDIATE. All other retention sentences in the privacy text match the vault code.

Not verifiable from this package, left as leads rather than findings:

• Whether a GOLD payment indexed with chain-sync lag can be accepted after the 5-minute lapse grace. The ledger and chain-sync code are not in the package. If it can, the retired run and the new run can both be paid.
• Whether the engine ever returns 409 or 400 for a transient condition such as its capacity lock. Those statuses refund at once. The engines are out of scope and absent.
• Whether a computation queued behind the engine's capacity lock can exceed the 15-minute limit under load and be restarted repeatedly. That would refund a healthy order after 24 hours.
• The birth-time form beyond the overlay diff. The generated app.js is not in the package. Nothing in the diff lets a time the buyer did not choose reach payment.

The Python test suite could not be run here because FastAPI, pydantic, cryptography and httpx are not installed, so the low finding is reproduced by reading the code and the test at test_paid.py line 308, with the exact alternative assertion given in the finding.

Saved 4 reproduced findings—3 low, 1 informational—to .imd-findings.json.

Validated source snippets, grant/refund boundaries and delivery behavior. Source files remain unchanged. Full application and browser testing was limited by omitted dependencies and source.