Failed on the agent's machine.

• mediumAny OSError, including TimeoutError, FileNotFoundError and ConnectionError from the engine, counts as 'engine away': a paid order that fails the same way every time is never struck, refunded or deliveSubmission25/source/integrations/celestao/celestao_world/paid.py:103

  calculate() sorts exceptions from processor.compute()/vault.complete() into three groups: refund now (NativeNondelivery, DocumentTooLarge), strike (NativeUnusable, any other Exception), and wait for ever with no strike (NativeUnavailable, sqlite3.Error, OSError, MemoryError). OSError is meant to stand for 'the disk is full', but in Python 3.11+ (the production image is 3.12) asyncio.TimeoutError is the builtin TimeoutError, which is a subclass of OSError.

  FileNotFoundError, PermissionError, ConnectionError and BrokenPipeError are subclasses too. So when an engine call fails the same way every time for one input, such as an engine-internal timeout (wait_for/asyncio.timeout inside the endpoint) or a missing ephemeris or data file for one date range, that paid order never gets a strike. failed_attempts stays 0 and vault.strike() is never called, so the 3-attempts/1-hour rule in AUDIT_REQUEST section 4 never fires.

  World keeps getting 'pending' and refunds nothing. The buyer has paid GOLD and gets no report and no refund until an operator notices the order in orders list and runs orders refund. Section 4 lists the uncounted classes as 'engine away or busy, database error, disk error, out of memory, a cancelled computation'.

  A timeout raised by the engine is none of these, and it is also not the >15-minute hang that the COMPUTE_LIMIT_MS cancel handles, because it raises well within the limit. This breaks request item 7 (World keeps the money for an order that was not delivered) and item 3.

  Fix: list the transient classes narrowly (sqlite3.OperationalError, OSError with errno ENOSPC/EIO/ENOMEM, MemoryError, NativeUnavailable). Catch TimeoutError/asyncio.TimeoutError and the other OSError subclasses (FileNotFoundError, PermissionError, ConnectionError) before that branch and send them to strike(), so they reach the existing 3-attempts/1-hour refund. Add a test where compute raises asyncio.TimeoutError and the run ends failed after the span.

  whole finding

  Python check (3.14 here, same since 3.11): asyncio.TimeoutError is TimeoutError -> True; issubclass(TimeoutError, OSError) -> True; try: raise asyncio.TimeoutError()\nexcept (ValueError,OSError) as e: ... takes the OSError branch.

  Path: in test_paid.py's Processor, make compute() run raise asyncio.TimeoutError() (or FileNotFoundError('ephe/seas_24.se1')) for every call.

  Prepare a run, bind an order, and send World deliveries 120 s apart (one per expired lease) for 2+ hours, i.e. far more than 3 attempts and over FAILED_ATTEMPTS_SPAN_MS.

  Expected: after 3 failed attempts spanning >=1 h the run becomes failed, and World gets terminal-failure CHART_NOT_GENERATED and refunds.

  Actual: every call answers kind='pending', runs.failed_attempts stays 0, state stays 'working', and the order is never refunded.

  The existing 'disk' test mode (raise OSError('no space')) shows the same uncounted path.

  whole reproduction

• lowAny engine HTTP status other than 200/429/502/503 (500, 504, 408) refunds the paid order on the first attempt, skipping the 3-attempt / 1-hour guard against a bad deploymentSubmission25/source/integrations/celestao/celestao_world/native.py:77

  compute() treats every returned Response that is not 200 and not 429/502/503 as a permanent nondelivery. paid.calculate() maps NativeNondelivery straight to vault.fail(...,'CHART_NOT_GENERATED'), and the same delivery call answers terminal-failure, so World refunds at once. AUDIT_REQUEST section 4 says a code fault must count as a strike and refund only after >=3 attempts and >=1 hour 'to catch a bad deployment'.

  But a bad deployment or a transient engine fault that the endpoint turns into a JSONResponse(status_code=500), or a 504 or 408 from an engine timeout, skips that guard. Each open paid order that is delivered during the fault is refunded on its first attempt, even though a later attempt would have made the report. The buyer is refunded and loses a reading that could have been made; the operator loses the sale and has no hour to react.

  The 1-hour window only protects faults that come back as exceptions.

  Fix: treat 5xx and 408 responses from the engine as a strike (raise NativeUnusable or a dedicated counted error) rather than NativeNondelivery. Keep NativeNondelivery for deterministic 4xx refusals such as 400 and 422, and for the profile/annual content checks.

  whole finding

  Stub the canonical endpoint so that compute() gets JSONResponse({'detail':'engine error'}, status_code=500) (or 504) once, then 200 with a valid result.

  Paid order: one World delivery call.

  Expected (as for a crash or RuntimeError): delivery_pending, failed_attempts=1, and the next attempt after the lease delivers the report.

  Actual: native.py:77 raises NativeNondelivery, paid.py:99 runs vault.fail, runs.state='failed', and the response is kind='terminal-failure' code='CHART_NOT_GENERATED'.

  World refunds, and the good 200 that would come next is never asked for.

  whole reproduction

Failed on the agent's machine.

• mediumA transient non-200 engine response (500/504/507/408, or any 4xx) refunds the paid order at once instead of striking or waitingSubmission25/source/integrations/celestao/celestao_world/native.py:77

  compute() maps only 429/502/503 to NativeUnavailable (order waits). Every other non-200 Response, including a 500 from an engine crash, a 504 from a slow engine, a 507 from a full disk or a 408, raises NativeNondelivery. In paid.py calculate() (lines 96-100) NativeNondelivery goes straight to vault.fail(...,'CHART_NOT_GENERATED'): the run is marked failed on the first attempt, the same deliver() call answers terminal-failure (paid.py:145-149) and World refunds the order.

  This contradicts the stated policy in AUDIT_REQUEST section 4 (unexpected failures are a strike, at least 3 attempts over at least 1 hour; infrastructure failures wait) and the comment at paid.py:102-105. A single transient server-side error on the pinned endpoint therefore turns a deliverable, paid order into a refund, with no retry and no operator window.

  Whether the pinned endpoints emit a 500 Response object rather than raising was not verifiable from this package (the backend tree is not included); a raised exception takes the strike path, a returned 5xx Response takes the immediate-refund path.

  Fix: in compute(), treat status>=500 (and 408) as NativeUnavailable (wait), treat any other unexpected status as NativeUnusable (strike), and reserve NativeNondelivery for the explicitly documented 'cannot compute this input' outcomes (the profile used_sources check and the annual cover check already do this).

  Add a test in test_paid.py where the engine returns a Response with status 500 once and then 200, asserting the first deliver() answers 'pending' and the second 'delivered'.

  whole finding

  State: a run with a paid World order, state 'prepared'.

  Make the pinned chart endpoint return starlette Response(status_code=500) once (for example an engine subprocess crash mapped to 500), then 200 on the next call.

  Call POST /api/world/deliver once.

  Expected (section 4 policy): answer kind='pending', failed_attempts=1, no refund; the next delivery call after the lease computes and delivers.

  Actual: calculate() raises NativeNondelivery, vault.fail() sets state='failed', failure='CHART_NOT_GENERATED', the same call answers kind='terminal-failure' with provider-confirmed-nondelivery, and World refunds the GOLD.

  The second, healthy engine call never happens.

  The run can only be bought again as a new order.

  whole reproduction

• lowPrivacy text says stored birth details and reports 'can be read only by the same signed-in wallet', but one server-held key decrypts every wallet's dataSubmission25/source/integrations/celestao/web/world-wallet.js:92

  The sentence (zh: 僅限有效登入的相同錢包讀取) promises exclusivity that the code does not provide. vault.py:39-40 derives a single AESGCM cipher and index key from the one server storage key (Settings.storage_key); every run's input_blob and every record's result_blob and metadata_blob are sealed with that key, with the owner digest only as associated data (vault.py:89,119,203).

  Vault.read()/ _open() need no wallet-held secret, and backup() copies the ciphertext to a file the same key opens. What the code enforces is that the HTTP API returns a record only to the session whose wallet digest matches; anyone with the server key and the database file (the operator, a backup holder, a compromised host) can read all wallets' birth details and reports.

  The text elsewhere is careful about what remains after cleanup and about World's keyed digest, so this sentence stands out as the one claim stronger than the code.

  Fix: change the sentence to say the data is encrypted with a key held by the Celestial Atlas server and is returned only to the same signed-in wallet, so the operator (and anyone holding the server key and database) can read it; or, if exclusivity is wanted, derive per-wallet keys from wallet-signed material, which is a design change.

  whole finding

  State: any completed run for wallet W.

  Input: on the server, Vault(settings.database, settings.storage_key).read(W, record_id) or a direct _open(result_blob, owner+'|record|'+id) without any session or signature from W.

  Expected per the text: unreadable without W signed in.

  Actual: the plaintext report and its input (birth details) are returned; no wallet key material is involved anywhere in vault.py.

Failed on the agent's machine.

Failed on the agent's machine.

• lowA 429/503 raised as HTTPException by the engine endpoint counts as a failed attempt, so a busy engine can refund a healthy paid orderSubmission25/source/integrations/celestao/celestao_world/native.py:75

  compute() only recognises an engine that is busy or away when the endpoint RETURNS a Response with status 429/502/503. The idiomatic FastAPI way to answer those statuses is to RAISE starlette.exceptions.HTTPException (the comment on the previous line says the baseline capacity lock and rate limit stay in force, and the same limiter answers 429 elsewhere).

  An HTTPException is a plain Exception, so in paid.py calculate() it falls through to the final except Exception and calls strike(). Three such answers spread over one hour (the engine busy at three delivery attempts, e.g. during a backlog) move the run to state failed with CHART_NOT_GENERATED, the next delivery answers terminal-failure, and World refunds an order that would have been delivered.

  Section 4 of the request states that 'engine away or busy' is not counted; this path counts it. The baseline endpoints are not in the package, so whether they raise rather than return could not be checked here; the mapping itself is the defect because it decides by class and HTTPException is not mapped.

  whole finding

  State: a paid order bound to a run (PaidTests.run_fixture).

  Make processor.compute raise fastapi.HTTPException(429,'RATE_LIMITED') (what a capacity lock raises).

  Call the delivery endpoint three times with self.time advanced by 1900000 ms between calls (attempts_on(run,order,3)).

  Expected (per AUDIT_REQUEST section 4 and the comment at paid.py line 102): every answer is 'pending' and failed_attempts stays 0, as it does for NativeUnavailable.

  Actual: answers are ['pending','pending','terminal-failure'], runs.state='failed', and World refunds the order on that answer.

  Fix: in compute() wrap the endpoint call with except HTTPException as exc: and raise NativeUnavailable for exc.status_code in (429,502,503), NativeNondelivery for other 4xx/5xx; or in calculate() add HTTPException with 429/502/503 to the pending branch.

  whole reproduction

• lowDuring the 5-minute lapse window the checkout page shows a silently disabled pay button; the 'wait 5 minutes' text is unreachableSubmission25/source/src/world/CelestaoCheckout.tsx:38

  AUDIT_REQUEST section 3 says that during the five minutes between an unpaid order's expiry and World answering lapsed 'the checkout page asks the buyer to wait'. The code does not. When /api/celestao-checkout/state returns a pending order whose expiresMs has passed, the page renders the pay button disabled and shows no status text.

  The ORDER_EXPIRED message ('This unpaid quote expired. Wait 5 minutes, then return...') is only rendered from the error state, and the error state is only set by operate(), which cannot run because the button is disabled, or by quote(), which is never called while data.order exists.

  A buyer who reloads Celestao in that window is sent back to this same run (vault.prepare finds it by input digest and World answers lapsed=false), so they loop between two pages with no explanation until the window ends.

  State: checkout row with order_id set, economy_orders.status='pending', expires_ms = now-60000 (expired 1 minute ago, inside CELESTAO_LAPSE_GRACE_MS).

  Open /fortune-checkout/?run= signed in as the buyer.

  Expected: a message that the quote expired and to wait 5 minutes (the ERRORS.ORDER_EXPIRED text).

  Actual: data.order is rendered with a disabled 'Sign payment of N GOLD' button and no message; pressing 'Check original order' changes nothing.

  Fix: when data.order.status==='pending' && data.order.expiresMs<=Date.now(), render the ERRORS.ORDER_EXPIRED text (role=alert) instead of the disabled button.

  whole reproduction

• infoPrivacy text calls the World input digest 'encrypted'; the code computes a keyed hash (HMAC), not encryptionSubmission25/source/integrations/celestao/web/world-wallet.js:93

  The value World keeps in celestao_checkouts.input_hash is produced at vault.py line 100 by hmac.new(self._index_key, b'input|'+owner+'|'+canonical(payload), sha256). It is a keyed digest: nothing is encrypted and nothing can be decrypted, but anyone holding Celestao's storage key and World's database can confirm a guessed set of birth details (as section 6 of the request itself says). The Chinese text (經過加密的雜湊值) makes the same claim.

  'Encrypted' promises more than the code does; the request asked for sentences the code does not make true, and this is one. The following clause ('cannot be directly turned back') is accurate.

  Input: any prepared run; read celestao_checkouts.input_hash on World and compare with hmac.new(index_key,b'input|'+owner+b'|'+canonical(payload),sha256).hexdigest() computed from the same birth details.

  Expected per the text: a ciphertext that requires a key to read.

  Actual: a deterministic keyed hash that equals the recomputed value, which anyone with the key can use to test guesses.

  Fix: say 'a keyed hash (digest) calculated from the birth details; it cannot be turned back into them, but someone holding both the key and World's records could confirm a guess' in both languages, or drop 'encrypted'.

  whole reproduction

• info'Cleared data may remain in backup files for up to 30 more days' is not enforced by any codeSubmission25/source/integrations/celestao/web/world-wallet.js:93

  Vault.backup() (vault.py lines 249-258) only creates a backup file at an operator-chosen path and refuses to overwrite; nothing in the package schedules backups, records when one was taken, or deletes one. The 30-day bound therefore depends entirely on the operator deleting files by hand, which section 6 of the request acknowledges. A backup taken the day before a run was pruned and kept for 31 days makes this sentence false.

  Reported so the owner decides whether the sentence should become 'until the operator deletes the backup' or a deletion job is added; no code change is required for the vault itself.

  State: run R failed, failed_ms = T.

  Operator calls vault.backup(path) at T+29d; prune_failed(T+30d) removes R from runs.

  Expected per the text: path no longer contains R's input_blob after T+60d.

  Actual: the file is unchanged for ever unless deleted by hand; no code references it after creation.

  Fix: either reword, or add a retention job that removes backups older than 30 days from the configured backup directory and a test for it.