# Audit report > Public review export 53333fea5707ac4514a44ff2556a7e3315c7dbf4. Producing World source 5dedb6f160ba29f123bf1fd719e92b0ad9c5dc32. > > Review World source 5dedb6f160ba29f123bf1fd719e92b0ad9c5dc32, repairing the two Low and three Info findings in job f5a3b8f9-c3ee-4706-aa61-d1a7e4fb3159. The original report and exact patch from producing e5f17432/public87b64e20 are in context/. Seven runtime files change, plus tests/docs; no contracts, schema, prices, dependencies, provider, World rendering or media change. > > L1/L2: reproduce logout after the final session read but before the SQL write batch for quote, admin, campaign, legacy GOLD pay and inventory. Atomic live-session SQL remains intact. Error/no-op paths now revalidate the exact original authentication context and return401 AUTH_REQUIRED rather than503/409 when authority is lost. Invalid or regressing time remains503; a real database failure with a valid session remains503; genuine inventory CAS remains409. Test expiry equality, verification downgrade, wallet/expiry changes, final-read awaits, session-read DB faults, pending and committed writes. A legitimate commit followed by logout must not be undone, leak a success body or repeat a debit on retry. Include sibling legacy order/challenge and all private read routes. > > I3/I4: state, quote and admin service control/product publication share the API capability predicate: installed readiness, declared products and bound result contract. Empty/fully unsupported lists cannot enable service or publish deliveryReady:true. Omitted trusted lists retain existing compatibility. Per-product serviceable is returned without rewriting immutable product rows or erasing historical orders. The GOLD service-order button refuses serviceable:false; old optional-field compatibility stays. Check mixed lists, readiness=false, supported research, preparatory disabled definitions, pauses, version changes and provider transitions. > > I5: owned HTTP reconciliation observes retry_ms on topup/job creation and failed-service refunds, like cron. Before the deadline it returns409 with the stored code and preserves attempts/deadline. Equality and later may retry; clearing capacity credits/refunds the original entitlement once. Check HTTP/cron interleaving, paused new admissions, ownership/origin/auth, stale resolved failures and genuine DB errors. Explicit audited admin repair/refund retains manual recovery authority. This is not a new distributed lease; in-flight concurrency remains protected by existing idempotent credit SQL. > > Reproduce all eight baseline failures and53 new issue/boundary regressions, plus previous suites. Inspect complete admission/signature/debit/delivery/refund/reward/hold/Mint/recovery chains and UTC/schema boundaries, not just changed lines. GOLD remains wallet-bound, nontransferable and nonredeemable, not an AMM/token trading pair. Formal retail prices remain unset, topup/service/Mint controls closed and approved game NFT whitelist empty. Existing mainnet contracts and research-only VPS adapter remain unchanged. Distinguish source tests, native D1, portable tests, actual deployment, public ref, paid submission and an external verdict. No peak-load or real-wallet payment claim. Report actionable severity/reproduction/regression details. | | | |---|---| | Repository | https://github.com/tungweb3/imd-ember-world-review.git | | Commit | `53333fea5707ac4514a44ff2556a7e3315c7dbf4` | | Job | `dba183e6-d81c-41a9-b9f0-1b7fb6e7b4af` | | Judged | 2026-10-20 00:09 UTC | | Findings | 2 low · 6 info | Four agents audited the code as it is at `53333fe`, each in one area (math, permissions, economics, control flow), and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the repository was changed or deployed. ## Findings ### 1. Low: Legacy GOLD challenge answers 401 AUTH_REQUIRED to a still-valid session when its guarded INSERT matches no row for a non-auth reason (concurrent payment of the same order, or ledger halt); the new re `world-source/server/economy-ledger.ts:248` ``` if(!saved){await sharedServiceAdmission(db,id,args.serviceReady,args.serviceProducts);throw new EconomyConflict('AUTH_REQUIRED');}if(saved.origin!==args.origin)throw new EconomyConflict('IDEMPOTENCY_CONFLICT'); ``` createEconomyGoldChallenge reads the order (pending), then runs INSERT INTO economy_gold_challenges ... WHERE AND AND AND AND . If the INSERT writes nothing, line 248 re-runs sharedServiceAdmission, which re-checks only provider readiness, product list, result contract and the service pause. It then throws EconomyConflict('AUTH_REQUIRED') for every other cause. Two of those causes are not authentication: (a) another tab or request paid the same order between the read at line 233 and the INSERT, so status is no longer 'pending'; (b) the indexer halted the ledger (economy_chain_state.halted_reason set) after requireRunning(). The L1/L2 remediation added an inner catch in economy.ts:83 that revalidates the exact session. When the session is still valid it rethrows the original cause, and the outer catch maps AUTH_REQUIRED to 401. So the request has just proven the session is valid and still answers 401 {error:'AUTH_REQUIRED'}. That breaks the remediation's rule that 401 means authority was actually lost. A client that follows the contract treats it as a logout and re-prompts sign-in. In (a) the right answer is 409 ORDER_ALREADY_PAID, in (b) 409 ECONOMY_HALTED, which the very next request returns. No nonce, debit or journal row is written, so the impact is misclassification only. The sibling createEconomyOrder (line 274, if(!inserted)throw new EconomyConflict('AUTH_REQUIRED')) has the same pattern for a halt during the INSERT. It is only reachable on a standalone economy DB, because the shared-book World throws LEGACY_*_ORDER_UNSUPPORTED before inserting. Fix: in economy.ts's inner catch, when revalidation succeeds and cause.code==='AUTH_REQUIRED', do not rethrow 401. Alternatively, after a zero-row INSERT in the ledger, re-read the order (paid -> ORDER_ALREADY_PAID, expired -> ORDER_EXPIRED) and the halt state (-> ECONOMY_HALTED) before throwing, and use a non-auth 409 such as CHALLENGE_UNAVAILABLE as the final fallback. Regressions: (a) and (b) with a live session must give 409 and leave sessions.revoked_at NULL; the same races with the session also revoked must stay 401. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. (a) Concurrent payment: f=await fixture(); await f.topup(); id=await f.quote('research'); a=await f.challenge(id) (challenge A for the same order); create a session for W. Wrap f.db.prepare so that the first time the SQL starts with 'INSERT INTO economy_gold_challenges', its run() first awaits payEconomyOrderGold(f.db,f.config,a) (another tab paying with challenge A) and then runs. POST /api/economy/orders//gold/challenge {expectedAddress:W,requestId:'judge-race-request-0001'}. Observed: 401 {error:'AUTH_REQUIRED'}. sessions.revoked_at is still NULL, the order is 'paid', and a following GET /api/me/economy?expected_address=W with the same cookie returns 200. Expected: 409 ORDER_ALREADY_PAID, or another non-auth 409. (b) Halt: same setup without challenge A; the wrapper runs UPDATE economy_chain_state SET halted_reason='REORG_DETECTED' just before preparing the challenge INSERT. Observed: 401 {error:'AUTH_REQUIRED'}, 0 challenge rows. The next challenge request with the same cookie returns 409 {error:'ECONOMY_HALTED'}. Expected: 409 ECONOMY_HALTED for the first request too. Merged from audit_economics da697bea. The concurrent-payment trigger (a) was added by the judge. ### 2. Low: Admin campaign startsMs/endsMs are validated with the server clock guard at(), so an administrator's 0, negative or non-numeric value is answered 503 INVALID_CLOCK (a server time fault) on both campai `world-source/server/world-gold.ts:208` ``` at(cmd.startsMs);at(cmd.endsMs);if(cmd.endsMs<=cmd.startsMs||!Number.isSafeInteger(cmd.version)||cmd.version<1||typeof cmd.stopped!=='boolean')fail('INVALID_CAMPAIGN'); ``` goldAdminCommand validates the client-supplied campaign window with at(cmd.startsMs);at(cmd.endsMs). at() is the server-clock sanity helper and throws Error('INVALID_CLOCK') for any value that is not a positive safe integer. POST /api/me/aimarket-campaign only checks Number.isSafeInteger (aimarket-campaign.ts:38), which accepts 0 and negatives. POST /api/gold/admin checks key names only (command() in world-gold-api.ts:20), which accepts strings. The remediation deliberately exempts INVALID_CLOCK from revalidation and classification on both routes, which re-throw it (world-gold-api.ts:78, aimarket-campaign.ts:40), and both outer catches answer 503 with body {error:'INVALID_CLOCK'}. The other bad window value (endsMs<=startsMs) gets 409 INVALID_CAMPAIGN. The result is that an input-validation error is reported as the server-time outage the L1/L2 contract reserves 503 INVALID_CLOCK for. The client and monitoring treat it as a retryable server fault. Because INVALID_CLOCK skips revalidation, a revoked admin sending startsMs:0 also gets 503 rather than 401. Only the owner wallets can reach this and nothing is written, because the error is thrown before the batch. Fix: validate startsMs/endsMs as positive safe integers and fail('INVALID_CAMPAIGN') before calling at(), so at() is used only for clock samples. Regression: startsMs 0, -5 and 'x' on both routes give 409 INVALID_CAMPAIGN (or 400) and never 503, and world_gold_campaigns stays empty. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. f=await fixture(); create an OWNER session. (1) POST /api/me/aimarket-campaign {expectedAddress:OWNER,requestId:,reason:'Bad start value',version:1,startsMs:0,endsMs:NOW+1000,stopped:false}. Observed 503 {error:'INVALID_CLOCK'}. (2) POST /api/gold/admin {expectedAddress:OWNER,requestId:,reason:'Bad start value',command:{action:'campaign',version:1,startsMs:-5,endsMs:NOW+1000,stopped:false}}. Observed 503 {error:'INVALID_CLOCK'}. (3) Same as (2) with startsMs:'x'. Observed 503 {error:'INVALID_CLOCK'}. Control: startsMs:NOW,endsMs:NOW-1 gives 409 {error:'INVALID_CAMPAIGN'}. The server clock (now:()=>NOW+2) was valid throughout and world_gold_campaigns has 0 rows. Expected for (1)-(3): 409 INVALID_CAMPAIGN or 400 BAD_REQUEST. From audit_permissions d3ee87af. ### 3. Info: Legacy order/challenge/pay catch exempts only INVALID_CLOCK, so the ledger's INVALID_SETTLEMENT_CLOCK (worker clock earlier than the order/challenge) becomes 401 when a logout races it, instead of sta `world-source/server/economy.ts:83` ``` }catch(cause){if(cause instanceof Error&&cause.message==='INVALID_CLOCK')throw cause;if(!await revalidateEconomySession(request,deps.db,session,clock))return error(401,'AUTH_REQUIRED');throw cause;} ``` The inner catch added for L1/L2 re-throws without revalidating only when cause.message==='INVALID_CLOCK'. The ledger raises a second clock-fault class, Error('INVALID_SETTLEMENT_CLOCK'), when the request's clock is earlier than the persisted order creation time or challenge issue time: economy-ledger.ts:241, 259, 276, 297 and 304. That happens when a different worker's clock lags the one that created the quote. Normally it is answered 503 ECONOMY_UNAVAILABLE. If the session is revoked after the final pre-write read, the catch revalidates, sees the lost session and answers 401 instead. The same server-side time fault is then classified by an unrelated race, against the objective's 'invalid or regressing time remains 503' and the 'never turn a failed clock into an auth error' comment in world-gold-api.ts. The GOLD API's analogous retryId check throws INVALID_CLOCK, which is exempt, so the two route families disagree for the same condition. Two faults have to coincide and nothing is written, so this is Info. Fix: exempt /^INVALID_(SETTLEMENT_)?CLOCK$/ in the economy.ts inner catch, or throw INVALID_CLOCK from the ledger for these checks. Regression: an earlier-than-order clock plus a post-read logout gives 503 on pay, challenge and order retry. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. f=await fixture(); await f.topup(); id=await f.quote('research') (created_ms=NOW); s=await f.challenge(id); create a session for W; deps.now=()=>NOW-1 (a worker 1 ms behind the quote). Control: POST /api/economy/orders//gold {expectedAddress:W,requestId:s.requestId,signature:s.signature} gives 503 {error:'ECONOMY_UNAVAILABLE'}: INVALID_SETTLEMENT_CLOCK at economy-ledger.ts:297. Repeat on a fresh fixture with 'revoke after read 2' (logout after the pre-write revalidation at economy.ts:70). Observed 401 {error:'AUTH_REQUIRED'}. Expected 503 in both cases. The book stays '10' in both. From audit_permissions 1e3868a1. ### 4. Info: Inventory write returns 409/403/503 without revalidating the session on its pre-batch checks and on a thrown batch; only the zero-change branch distinguishes lost authority `world-source/server/inventory.ts:112` ``` }catch(e){const code=e instanceof Error?e.message:'';return json(['BAD_REQUEST','INVALID_COMMAND'].includes(code)?400:503,{error:['BAD_REQUEST','INVALID_COMMAND','INVENTORY_CAPACITY'].includes(code)?code:'INVENTORY_UNAVAILABLE'});} ``` The L2 fix revalidates the session only when the UPDATE changed zero rows (inventory.ts:103-106). Other inventory failure paths answer without revalidating. (1) The pre-batch revision check (line 85), ITEM_NOT_AVAILABLE (line 92) and HOME_REQUIRED/HOME_UNAVAILABLE (lines 87, 97) run after the awaited homeState() chain lookup and read() that follow the single session read at line 80. (2) The outer catch (line 112) maps any thrown error, including a D1 fault from db.batch, to 503 INVENTORY_UNAVAILABLE. The quote, admin, campaign and legacy order/challenge/pay handlers revalidate on every non-clock failure. For the same state, a logout plus a DB fault answers 401 on those routes and 503 on /api/me/inventory. This is the family inconsistency the remediation set out to remove. The live-session SQL still blocks the write, so no arrangement is written and no private body is returned. Impact is classification only. A stale client revision is still a genuine conflict, so the 409 case is debatable. The thrown-batch case is the clearer gap. Fix: in the catch (except INVALID_CLOCK), and before the 409/403 prechecks once a session has been read, call revalidateEconomySession and return 401 if it fails. Keep 409 for a live session (the existing CAS test) and 503 for a live-session DB fault. Regression: add the pairs 'DB fault + logout -> 401' / 'DB fault + live -> 503' and 'stale revision + logout -> 401' / 'stale revision + live -> 409', with world_inventory_arrangements staying empty. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. home=async()=>({address:W,eligible:0,checkedAt:NOW+2,block:100}); create a session for W; POST /api/me/inventory {expectedAddress:W,revision:R,command:{type:'publish',enabled:false}}. (a) Revoke after read 1, f.db.batch=async()=>{throw Error('D1_ERROR: database is locked')}, R=0. Observed 503 {error:'INVENTORY_UNAVAILABLE'}; expected 401 {error:'AUTH_REQUIRED'}. Control: the same fault with no revoke also gives 503, which is correct. (b) Revoke after read 1, R=7 (stale). Observed 409 {error:'REVISION_CONFLICT'}; the same without revoke gives 409. Control: on POST /api/gold/quote the same 'logout plus thrown batch' state gives 401. Merged from audit_economics c735f92d and the inventory part of audit_permissions a698cc61. ### 5. Info: Private read routes answer 404/503 without revalidating after a logout during their awaits (report provider failure or not-found, admin order lookup not-found, state/legacy snapshot DB fault) `world-source/server/world-gold-report.ts:23` ``` }catch{return reply(503,{error:'REPORT_UNAVAILABLE'});} ``` The task scope includes all private read routes, but only their success paths revalidate the session. Error and not-found paths answer without checking it. GET /api/gold/orders/:id/report awaits the external provider.readReport(), the longest window. If the provider fails after a logout, the bare catch returns 503 REPORT_UNAVAILABLE, and 404 REPORT_NOT_FOUND (line 18) is also returned without revalidating. GET /api/gold/admin?order_id= returns 404 ORDER_NOT_FOUND without revalidating (world-gold-api.ts:55), so a request whose admin session was revoked mid-flight still learns whether an order id exists; its 200 path does revalidate. A DB fault in worldGoldSnapshot (/api/gold/state, /api/me/gold) or economyWalletSnapshot (/api/me/economy) after logout gives 503 GOLD_UNAVAILABLE / ECONOMY_UNAVAILABLE. No private body leaks and nothing is written. Impact is classification plus a one-bit order-existence answer to an admin who was authenticated when the request started, so this is Info. Fix: send these reads' not-found and catch paths through the same revalidate-then-classify step as the writes (INVALID_CLOCK stays 503), and add the read routes to the audit10 matrix, which today covers only writes. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. (1) f=await fixture(); await f.topup(); id=await f.service(); UPDATE world_gold_jobs SET state='delivered',result_json='{"provider":"aimarket-vps-v1","reportId":"r1","documentHash":"r1"}' WHERE order_id=id; create a session for W; revoke after read 1; handleWorldGoldReport(GET /api/gold/orders//report?expected_address=W,{db,now:()=>NOW+2,allow,provider:{readReport:async()=>{throw Error('down')}}}). Observed 503 {error:'REPORT_UNAVAILABLE'}; expected 401 AUTH_REQUIRED. (2) Create a session for OWNER; revoke after read 1; GET /api/gold/admin?expected_address=OWNER&order_id=0x'+'1'*64. Observed 404 {error:'ORDER_NOT_FOUND'}; expected 401. Merged from audit_economics 7719ea82 and the report part of audit_permissions a698cc61. ### 6. Info: Admin repair-topup / refund-service leave the world_gold_reconcile_errors row in place, so a credited order is still listed as an open failure with a stale retry deadline `world-source/server/world-gold.ts:214` ``` }else if(cmd.action==='repair-topup'){list.push(check(db,"EXISTS(SELECT 1 FROM world_gold_links l JOIN economy_orders o ON o.id=l.order_id WHERE o.id=? AND l.kind='topup' AND o.status='paid')",cmd.orderId),credit(db,cmd.orderId,'topup',now));} ``` reconcileWorldGold (cron and the owned HTTP retry) deletes the world_gold_reconcile_errors row in the same batch as a successful credit or refund (lines 86, 90), and the remediation document says 'successful credit/refund stays idempotent and clears the error'. The audited admin repair-topup (line 214) and refund-service (line 215) commands use the same credit() statement, but their batch never deletes the error row. After a capacity failure has recorded {code:GOLD_BALANCE_CAPACITY,retry_ms:T+300000,attempts:1}, a successful admin repair leaves that row forever. The order is no longer owed, so neither cron nor HTTP reconcile revisits it. GOLD is credited exactly once, and the I5 cooldown cannot produce a false 409 because the order has left both candidate sets. Impact is an operator-facing audit table that lists a resolved failure as open. Fix: add st(db,'DELETE FROM world_gold_reconcile_errors WHERE order_id=?',cmd.orderId) to the repair-topup and refund-service lists, a no-op when no row exists. Regression: the row count is 0 after an admin repair that follows a recorded capacity failure. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. f=await fixture(); await f.topup(); UPDATE economy_gold_accounts SET balance='9223372036854775800' WHERE wallet=W; id=await f.quote(); await f.paid(id); reconcileWorldGold(f.db,NOW) returns failures [GOLD_BALANCE_CAPACITY] and the row {code:'GOLD_BALANCE_CAPACITY',retry_ms:NOW+300000,attempts:1}. UPDATE economy_gold_accounts SET balance=0; f.admin({action:'repair-topup',orderId:id}) returns results [1,1,1,1,1,3] and the book becomes '10' (credited once). Observed: SELECT * FROM world_gold_reconcile_errors still returns that row unchanged. reconcileWorldGold(f.db,NOW+300001) returns processed 0, failures [] and the row is still present. Expected: the row is deleted together with the successful credit, as on the cron/HTTP path. From audit_flow e218724f. ### 7. Info: GOLD panel silently disables an enabled service product with serviceable:false: its only explanation is keyed to the global deliveryReady flag `world-source/src/world/WorldGoldPanel.tsx:66` ``` {data.deliveryReady!==true&&

{zh?'服務尚未接通，目前不接受新的服務扣點。':'Services are unavailable; new service payments are disabled.'}

}
{data.products.filter(p=>p.enabled).map(p=>

{p.title}

{p.kind==='topup'?`${p.embeo?economyTokenAmount(p.embeo):'—'} EMBEO → ${p.gold} GOLD`:`${p.gold} GOLD`}

v{p.version}
)}
``` The I4 change adds p.serviceable===false to the Create-order button's disabled condition. The role=status explanation on the same line is still rendered only when data.deliveryReady!==true. Suppose the installed provider declares a list with a result contract that does not cover an enabled historical service product, for example ['fortune'] while research:1 is enabled: the exact I4 scenario. The server then reports deliveryReady:true with serviceable:false for that product. The member sees an enabled-looking product card with a disabled button and no message, while other cards can be ordered. Server-side admission is authoritative (quote answers 503 SERVICE_DELIVERY_UNAVAILABLE), so no GOLD moves. This is a UI consistency gap. Fix: also render the status line, or a per-card note, when an enabled service product has serviceable===false. Regression: render WorldGoldPanel with deliveryReady:true and an enabled service product with serviceable:false, and assert a role=status notice is present. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. f=await fixture(); create a session for W; GET /api/gold/state?expected_address=W with deps.serviceProducts=['fortune']. Observed 200 with deliveryReady:true, products [['pack:1',enabled 1,serviceable true],['research:1',enabled 1,serviceable false]] and controls service enabled:1. Rendered with that state, line 66 shows the research card with a disabled 'Create order' button and no role=status paragraph, because data.deliveryReady===true. Expected: a visible notice that this service cannot currently be delivered. From audit_flow a9b5dcb5. ### 8. Info: Admin version-CAS conflicts (stale control/product/campaign version, repair of a non-eligible order) are answered 503 GOLD_UNAVAILABLE / CAMPAIGN_UNAVAILABLE, the same as a real database failure; the `world-source/server/aimarket-campaign.ts:45` ``` }catch(e){const code=e instanceof Error?e.message:'';return reply(code==='AUTH_REQUIRED'?401:code==='BAD_REQUEST'?400:['INVALID_CAMPAIGN','INVALID_REQUEST_ID','REASON_REQUIRED','IDEMPOTENCY_CONFLICT','ATOMIC_GUARD_FAILED'].includes(code)?409:503,{error:/^[A-Z][A-Z0-9_]{1,60}$/.test(code)?code:'CAMPAIGN_UNAVAILABLE'});} ``` goldAdminCommand checks every optimistic version and eligibility guard only inside the batch, through check() (an INSERT into world_gold_write_checks with CHECK(accepted=1)). Examples are control version=?, product version=MAX+1, campaign version=MAX+1, and repair-topup/refund-service eligibility. A stale version therefore aborts the batch with a raw SQLite CHECK message. That message does not match /^[A-Z][A-Z0-9_]{1,80}$/, so world-gold-api.ts:79 answers 503 GOLD_UNAVAILABLE and aimarket-campaign.ts:45 answers 503 CAMPAIGN_UNAVAILABLE. The campaign catch lists ATOMIC_GUARD_FAILED among its 409 codes, but no code path or migration raises it (grep finds it only in that list), so the intended 409 is unreachable. The remediation separates a genuine database fault (503) from a CAS conflict (409 for inventory) and lost authority (401). For admin commands, though, a CAS conflict is indistinguishable from a database outage. This matters in practice because the admin panel (WorldGoldPanel.tsx:42) sends the version from its last state fetch, and three owner wallets can act concurrently. The second admin to toggle gets 'service unavailable' instead of 'refresh and retry'. goldQuote has the same mapping: an admin disable or reprice between the quote's pre-check and its batch gives 503 instead of 409 PRODUCT_UNAVAILABLE/FEATURE_PAUSED. Nothing is written in any case, and only owner wallets can reach the admin routes, so this is Info. Fix: pre-check the version or eligibility before the batch and fail with a stable code (for example VERSION_CONFLICT or ATOMIC_GUARD_FAILED -> 409). Alternatively, on a CHECK failure with a valid session, re-read the guarded row and map it to 409. Regression: stale control, product and campaign versions on both routes give 409 and leave the rows unchanged; a real batch fault with a live session stays 503. **Reproduction** Harness for every reproduction below: node --test (Node 24.18) on an isolated copy of this tree with world-source's exact package-lock installed (npm ci), importing world-source/tests/world-gold-audit5-fixture.mjs (NOW=2026-10-18T00:00Z). Session row sessions(token_hash=sha256('z'*43),address=,chain_id=1,created_at=NOW-1,expires_at=NOW+3600000,wallet_type='EOA',verification_method='ECDSA'); requests go to https://imdember.com with origin https://imdember.com and cookie __Host-imd_session=<'z'*43>; deps {db,config,now:()=>NOW+2,allow:async()=>true,serviceReady:true,serviceProducts:['research']}. 'Revoke after read N' wraps db.prepare so that right after the Nth execution of 'SELECT address,expires_at,revoked_at,wallet_type,verification_method FROM sessions WHERE token_hash=?1' returns the live row, UPDATE sessions SET revoked_at=NOW+1 runs. This is the afterRead helper from tests/world-gold-audit10.test.mjs. f=await fixture(); create an OWNER session. POST /api/gold/admin {expectedAddress:OWNER,requestId:,reason:'Stale version test',command:C}. With C={action:'control',feature:'topup',version:5,enabled:false} (actual version 0): observed 503 {error:'GOLD_UNAVAILABLE'}. With C={action:'product',product:'pack',kind:'topup',title:'X',gold:'10',embeo:'7',enabled:true,version:1} (version 1 already exists): observed 503 GOLD_UNAVAILABLE. With C={action:'campaign',version:3,startsMs:NOW,endsMs:NOW+1000,stopped:false} (no campaign yet, next is 1): observed 503 GOLD_UNAVAILABLE. With C={action:'repair-topup',orderId:'0x'+'1'*64}: observed 503 GOLD_UNAVAILABLE. POST /api/me/aimarket-campaign {expectedAddress:OWNER,requestId:,reason:'Stale campaign',version:4,startsMs:NOW,endsMs:NOW+1000,stopped:false}: observed 503 {error:'CAMPAIGN_UNAVAILABLE'}. world_gold_controls stays [topup 1 v0, service 1 v0, mint 1 v0]. Expected: 409 with a stable conflict code, distinct from the 503 that a real D1 fault gives. Found by the judge. --- Judge's submission `65580e3e617ade883618f3dd474942dbf3163203c6ccecd07fdae59b6eae76f2`, accepted on the IdentityMD network. Acceptance means the report met the job's checks; it is not a guarantee that the code has no other defects.