Not a payment-safety defect: no redirect or non-200 can be read as delivered or as a refundable nondelivery (both adapters throw on status!==200 before any body is read, and a terminal-failure needs a 200 with a valid HMAC-signed body).

This concerns only the accuracy of the new wait text. runGoldServiceJobs (server/world-gold-delivery.ts:27) selects jobs with lease_ms<=now, where now is read at the start of the pass; claimGoldJob then sets lease_ms = (a later clock read)+60000. When Celestao answers pending (paid.py waits DELIVERY_WAIT_SECONDS=8 and the chart is not done), the job is left 'working' with that lease untouched.

At the next minute tick, now is read after the same schema checks and reconcileWorldGold prelude, so it is normally a few ms to seconds short of the lease (which was stamped after that prelude plus the job SELECT in the previous pass). The job is therefore skipped at tick N+1 and retried at tick N+2 unless cron jitter happens to exceed that gap.

The confirm-step text and the 'working' text both say 'usually in about 1-2 minutes'; the single measurement behind it (evidence/production_timeline.md) was a chart that finished inside the 8 s wait. The World checkout page (locked) correctly gives no time.

Not a false payment claim: the fallback text in showRun (line 68) is conditional ('If you paid in World...') and the retired run cannot have been paid. But GET /api/world/runs/{id} (paid.py:72-81) does not expose retired, so a run that vault.retire_lapsed marked after World reported lapsed (its quote expired unpaid, >5 min ago) still reads as state 'prepared'. The page then shows 'This reading has not started yet...

Check its original order; do not create another.' and re-polls every 5 s indefinitely, while the linked World page shows ORDER_EXPIRED: 'Wait 5 minutes, then return to Celestial Atlas to start again.' The only way forward is in fact to run compute again (vault.prepare skips retired rows and opens a new run and a new order).

Pre-existing wording ('do not create another') carried into 382a266; the new 'If you paid in World, it usually starts within 1-2 minutes' sentence is additionally misleading here because no payment is possible on this run.

Celestao's deliver endpoint (source/integrations/celestao/celestao_world/paid.py lines 127-139) answers 409 ORDER_BINDING_REQUIRED when the run is Missing and not pruned (e.g. the vault was restored from a backup taken before the run was admitted), or when product/inputHash do not match the row. All of these raise before vault.bind_order, so the run keeps order_id NULL. Consequences across the two systems:

1. World treats the 409 as a thrown DELIVERY_UNAVAILABLE and re-claims the job every cron minute for ever; the job never reaches 'failed', so the ledger never refunds and the World operator command refund-service is refused by its guard (world-gold.ts line 264: state IN ('failed','refunded') -> REFUND_NOT_ENTITLED).
2. Celestao's operator listing vault.stuck() (vault.py line 240) selects only rows WHERE order_id IS NOT NULL, so the unbound run is not listed either.
3. The only trace is console.error in the cron, which observability samples at 20% (wrangler.jsonc line 40).
4. The buyer's Celestao page keeps the run in 'prepared' and, after 382a266, shows 'This reading has not started yet. If you paid in World, it usually starts within 1-2 minutes' indefinitely (world-wallet.js line 68). The stated invariant 'a buyer who paid gets the report or the money back' (vault.py line 25) has no path to hold here, and neither operator has a tool to restore it. Pre-existing retry behaviour; the new text makes a time promise in a state the Worker already knows is unrecoverable (its own comment: 'retrying will not help').

Celestao 382a266 (deployed copy Submission32/celestao/world_wallet_web/world-wallet.js, same content with CRLF) adds the run-state text 'Paid. Your report is being prepared, usually in about 1-2 minutes. This page updates by itself; do not create another order.' in showRun().

The 5-second re-poll (line 69) is only scheduled inside the try block after a successful GET /api/world/runs/{id}. If one poll throws, control goes to the catch on line 70, which overwrites the status paragraph with errorText(e) and does nothing else: no timer is set, and the 'Check original World order' link and the 'Check again' button are appended only in the else branch (line 68), so they are never present after an error.

The buyer who was just told the page updates by itself is left with 'Temporarily unavailable. Try again shortly.' and no way to retry other than reloading, switching tabs (visibilitychange -> recheck) or refocusing the window. Every poll of /api/world/runs/{id} goes through identity(), which calls world.introspect() on each request (app.py line 113); a single BridgeUnavailable there is answered 503 WORLD_AUTH_UNAVAILABLE, so a transient World outage of one request is enough.

The previous text ('has not been delivered') made no self-updating claim, so this is new to the diff. Not a payment-safety issue: the text says nothing false about payment and no second payment is invited; it is a false statement about the page's behaviour during the exact window (a paid run in 'working') the change was made for.

Both new texts (the confirm step and the 'working' state) say the report is usually ready about 1-2 minutes after payment, and AUDIT_REQUEST.md section 4 derives that from 'the cron runs every minute and Celestao waits up to 8 seconds'. That holds only when the first delivery call completes the chart inside Celestao's 8-second DELIVERY_WAIT_SECONDS.

When Celestao answers kind:'pending' (a chart that takes longer than 8 s, the profile product, an engine busy answer, or the engine being briefly away), runGoldServiceJobs leaves the World job in state 'working' with lease_ms = claim time + 60000 (this line), and the job SELECT in world-gold-delivery.ts line 27 only picks it up again when lease_ms <= now, where now is read at the start of runGoldServiceJobs in the next tick.

The claim in tick N happens after sharedGoldSchemaPresent, worldGoldSchemaReady, reconcileWorldGold and the job SELECT (several D1 round trips), so lease_ms is set tens to hundreds of milliseconds after the tick's own clock read. Tick N+1 runs 60 s later with independent scheduling jitter; whenever its clock read falls earlier than 60 s after tick N's claim, the lease has not expired and the job is skipped until tick N+2.

Consecutive-tick retry is therefore roughly a coin flip, and the expected retry interval for a pending job is about 1.5 minutes, with 2 minutes common. A report that is not ready in 8 s is thus typically delivered 2-3 minutes after payment, not 1-2.

The text hedges with 'usually', so this is informational; it matters because the stated basis of the number is a single measured delivery that happened to complete inside the first 8-second call, and because a shorter retry interval also shortens the time an operator needs to notice a stuck order.

The audit request's claim for question 1 ('a 3xx is still refused') is correct: I ran createCelestaoDelivery and createAIMarketDelivery against stub transports answering 301, 302, 307, 409, 500 and a 200 text/html body, and every case throws (DELIVERY_UNAVAILABLE, or BAD_REQUEST from celestaoBody for the HTML case), which runGoldServiceJobs turns into 'retry'; none returns kind:'delivered' or kind:'terminal-failure'.

But nothing in the suite checks this. tests/celestao-checkout.test.mjs lines 68-77 and tests/aimarket-delivery.test.mjs line 12 only return status-200 responses (modes 'ok', 'wrong-wallet', 'unsigned') and assert init.redirect==='manual' as a string.

The new guard test reads only top-level .ts files of server/ and worker/ (readdirSync is not recursive), matches one spelling of the option, and cannot see src/shared/ or src/world/ files that worker/app.ts bundles (cadence.ts, collections.ts, the shared pricing modules; none currently calls fetch). It also cannot catch the next option Workers reject or treat differently, since it is a source grep rather than an execution of the adapter against a redirect answer.

Related, not in the diff: a 409 from Celestao (ORDER_BINDING_REQUIRED) is logged with console.error and then retried every minute for ever; it never refunds and never ends, which is the inverse of the question asked and is the intended conservative behaviour, but it means a wrong or restored Celestao database leaves a paid order in 'working' indefinitely with only a console line as signal.

Celestao 382a266 (deployed copy Submission32/celestao/world_wallet_web/world-wallet.js, identical modulo CRLF) adds the run-state text "Paid. Your report is being prepared, usually in about 1-2 minutes. This page updates by itself; do not create another order." in showRun().

The 5-second re-poll (line 69) is scheduled only inside the try block after a successful GET /api/world/runs/{id}. If one poll throws, control goes to the catch on line 70, which overwrites the status paragraph with errorText(e) and does nothing else: no timer is set, and the "Check original World order" link and the "Check again" button are appended only in the else branch (line 68), so they are not present after an error.

Every poll goes through identity(), which calls world.introspect() per request (app.py line 113); one BridgeUnavailable is answered 503 WORLD_AUTH_UNAVAILABLE, so a single transient World outage is enough. The buyer who was just told the page updates by itself is left with "Temporarily unavailable. Try again shortly." and no control; polling resumes only after a tab switch/refocus (recheck()) or a reload.

The previous text made no self-updating claim, so the gap is new to this diff. Not a payment-safety issue: nothing false is said about payment and no second payment is invited; the false statement is about the page's behaviour during exactly the window (a paid run in working) the change was made for. Merged from audit_flow.

Fix: in the catch, for errors other than AUTH_REQUIRED/CONTEXT_CHANGED, append the World order link and the "Check again" button and reschedule showRun with the same 5 s timer (optionally with a bounded back-off); or move the timer scheduling into a finally that runs whenever the run state is unknown or in ['prepared','working'].

tests/worker-fetch-redirect.test.mjs (added in f33468a) is the only regression guard against a repeat of the incident class "a RequestInit value Node accepts and workerd throws a TypeError on before sending", which produced the silent two-hour stall (runGoldServiceJobs catches the throw without logging and retries each minute; no refund is possible).

The test uses readdirSync(dir) without recursion, keeps only names ending in .ts, scans only server/ and worker/, and matches only /redirect\s*:\s*['"]error['"]/.

Gaps, each confirmed: (1) a file in any subdirectory of server/ or worker/ is never read; (2) src/shared/ and the src/world files worker/app.ts bundles are never scanned; (3) .mjs/.js helpers are skipped; (4) the cache option is unchecked, although Cloudflare's Request documentation states only cache:'no-store' and 'no-cache' are supported and any other value throws TypeError "Unsupported cache mode: " (compatibility_date 2026-05-15 enables cache_option_enabled), and Node accepts all cache modes.

AUDIT_REQUEST section 4 discloses that the search for other options is not a test; this finding adds that the test does not cover the whole Worker bundle even for the one option it checks. Currently no Worker-side file in the bundle uses any of these options (the only cache:/credentials:/redirect:'error' uses are browser code in src/world/worldGoldClient.ts:23 and src/world/squeekCheckoutClient.ts:32), so this is a coverage defect, not a live one.

Merged from audit_math, audit_economics, audit_flow and audit_permissions.

Fix: walk server/, worker/, src/shared/ (and the src/world modules worker/app.ts imports) recursively over .ts/.tsx/.mjs/.js, reject redirect:'error' and cache values other than 'no-store'/'no-cache' (and mode/credentials/referrer/integrity/keepalive/priority), or better route all Worker-side outbound calls through one helper and unit-test its init object; and add one miniflare/workerd test (@cloudflare/vitest-pool-workers or wrangler unstable_dev) that calls createCelestaoDelivery with the real fetch against a local stub and asserts the request is sent.

Celestao's deliver endpoint (integrations/celestao/celestao_world/paid.py lines 127-139) answers 409 ORDER_BINDING_REQUIRED when vault.run raises Missing and the run is not in pruned_runs (vault.py 16-17: Missing is a ValueError subclass, so the re-raise at line 134 is caught by the except on line 139), or when product/inputHash do not match the row (line 137). All these paths run before vault.bind_order, so the run keeps order_id NULL. Consequences:

1. World: the adapter logs console.error('celestao_delivery_refused') and throws DELIVERY_UNAVAILABLE; runGoldServiceJobs records 'retry' and the job stays queued/working and is re-claimed every cron minute (world-gold-delivery.ts 27-37, world-gold.ts 139) with no bound; it never reaches 'failed', so neither reconcile's refundGold nor the operator command refund-service can run (world-gold.ts 264: guard REFUND_NOT_ENTITLED requires state IN ('failed','refunded')).
2. Celestao: vault.stuck() (vault.py 240) lists only rows WHERE order_id IS NOT NULL and vault.abandon(order_id) (vault.py 245) looks up by order_id, so the unbound run is invisible to the Celestao operator too and cannot be ended.
3. The only signal is this console.error line, emitted inside the scheduled handler, and wrangler.jsonc line 40 sets observability head_sampling_rate 0.2, so each minute's line is kept with probability 0.2 and a one-off refusal usually leaves nothing (this is why the 2026-11-08 stall needed a separate probe Worker).
4. The buyer's Celestao page, if the run row exists but mismatches, stays in 'prepared' and after 382a266 reads "This reading has not started yet. If you paid in World, it usually starts within 1-2 minutes" on every 5 s poll, indefinitely. The refusal-not-refund rule is the owner's stated design for a wrong or restored database and is correct; the defect is that the stated invariant (vault.py line 25: a buyer who paid gets the report or the money back) has no path to be restored by anyone, while the Worker's own comment says retrying will not help. Preconditions are operator-side (restore from a backup taken before the run was admitted, or an inconsistent row), not attacker-reachable, hence low. Merged from audit_economics (409 dead end) and audit_economics (log sampling). Fix: in createCelestaoDelivery return a distinct outcome for 409 (or persist a 'refused' marker and counter in world_gold_jobs.failure) and stop re-claiming after a bounded number of consecutive refusals, listing the job for operator review; add an admin action that can move such a job to 'failed' with evidence {kind:'operator-confirmed-nondelivery'} so refundGold can run; on the Celestao side make vault.stuck() or the deliver log include refused orders (orderId is known at the 409). Set head_sampling_rate to 1 for scheduled invocations or write the last delivery error into world_gold_jobs so it is queryable regardless of log sampling.

f33468a changes redirect:'error' to redirect:'manual' and argues it is safe because both callers refuse any non-200. Under 'manual', Workers and Node hand the 3xx response itself to the caller, so the status check (celestao-delivery.ts 21, aimarket-delivery.ts 29) is now the only thing between a redirect and the signature/JSON path.

The claim is correct today: I ran createCelestaoDelivery and createAIMarketDelivery against stub transports answering 301, 302 (with a JSON body claiming kind:'delivered'), 307, 308, 409, 500, 204 and a 200 text/html body, and every case throws (DELIVERY_UNAVAILABLE, or BAD_REQUEST from celestaoBody for the HTML case), which runGoldServiceJobs turns into 'retry'; none returns kind:'delivered' or kind:'terminal-failure'.

I also confirmed with a local HTTP server that Node's fetch with redirect:'manual' returns the 3xx with its real status, as Workers does. But nothing in the suite checks this: tests/celestao-checkout.test.mjs lines 68-77 return only status-200 responses (modes ok, wrong-wallet, unsigned) and assert init.redirect==='manual' as a string; tests/aimarket-delivery.test.mjs line 17 has one 500 case and no 3xx.

A later edit that relaxes response.status!==200 (to !response.ok plus following the Location header, or to any 2xx) would pass the suite. Merged from audit_flow and audit_permissions.

Fix: add a 302-with-Location case and a 307 case to both test files next to the existing 'unsigned' and 500 cases, asserting assert.rejects(provider.deliver(order),/DELIVERY_UNAVAILABLE/) and that calls increased by one; and in the celestao test assert the World job is still working/queued afterwards.

Both new texts (the confirm step and the working state in world-wallet.js line 39 and 68) say the report is usually ready about 1-2 minutes after payment, and AUDIT_REQUEST section 4 derives that from "the cron runs every minute and Celestao waits up to 8 seconds". That holds only when the first delivery call finishes the chart inside DELIVERY_WAIT_SECONDS=8 (paid.py 13).

When Celestao answers kind:'pending' (a chart that needs more than 8 s, the four-system profile product, an engine busy or briefly away), runGoldServiceJobs leaves the World job in state 'working' with lease_ms = claim time + 60000 (this line), and the SELECT in world-gold-delivery.ts line 27 picks it up again only when lease_ms <= now, where now is read at line 22 at the start of the pass.

The claim in tick N happens after sharedGoldSchemaPresent, worldGoldSchemaReady, reconcileWorldGold and the job SELECT (several D1 round trips) and claimGoldJob reads clock() again (line 138), so lease_ms is stamped later than tick N's own now by the prelude plus the SELECT. Tick N+1's now is read after the same prelude, so it is earlier than lease_ms unless cron jitter exceeds the SELECT round trip; the job is then skipped until tick N+2.

A report not ready in 8 s is therefore typically delivered 2-3 minutes after payment, not 1-2. The text hedges with "usually", and the single measurement behind it (evidence/production_timeline.md) was a chart that finished inside the first 8-second call, so this is informational. It also matters because a shorter retry interval shortens the time an operator needs to notice a stuck order.

The bundle lacks tests/d1-sqlite.mjs, so runGoldServiceJobs could not be executed here; the reproduction is arithmetic from the quoted lines. Merged from audit_math and audit_flow.

Fix (any one): claim with the same now the SELECT used (pass now instead of clock() at world-gold-delivery.ts 30 and drop the fresh read), make the lease shorter than the cron period (e.g. nowMs+45000; finishGoldJob still requires lease_ms>finishedAt and the delivery call is bounded at 10 s), select with lease_ms<=now+grace of a few seconds, or soften the text to "a few minutes".

GET /api/world/runs/{id} returns run['state'] from vault._run_view (vault.py 130-131), which does not expose the retired column. vault.retire_lapsed (vault.py 166-174) marks a run retired after World reports lapsed (the quote expired unpaid and 5 minutes passed, celestao-checkout.ts 11 and 51) but leaves state='prepared'. The World checkout page for that run shows ORDER_EXPIRED: "This unpaid quote expired. Wait 5 minutes, then return to Celestial Atlas to start again."

(CelestaoCheckout.tsx 9) and its back link is always https://celestao.com/?world_run=#/saved (line 31). On that page showRun() renders the 382a266 text for anything not complete/cleared/failed/working: "This reading has not started yet. If you paid in World, it usually starts within 1-2 minutes.

Check its original order; do not create another." and, because the state is in ['prepared','working'], re-polls every 5 s indefinitely (world-wallet.js 68-69). No payment is possible on a retired run, and the only way forward is to run compute again, which vault.prepare does by skipping retired rows and opening a new run (vault.py 118).

The payment clause is conditional, so nothing false is said about payment and no second payment is invited; the "do not create another" wording pre-dates this diff. The new sentence adds a suggestion that waiting may help where it cannot. Informational.

Merged from audit_math.

Fix: expose retired (or a state 'lapsed') from GET /api/world/runs/{id}, render a lapsed text that points to starting the reading again and states no payment was taken, and exclude it from the ['prepared','working'] polling list.