jobStages() classifies job nodes by state name, but the names it checks ('running', 'assigned', 'pending', ...) are not the ones api.imd.fun returns. The live GET /jobs/:id answer uses 'waiting' for a queued node and 'working' for the node in progress (terminal nodes are 'accepted', which is recognised). A 'working' node is neither done, failed nor running, so status() returns 'pending' for every stage while the swarm is actually building or auditing.

The Playwright test in web/tests/job5.spec.ts:128 only feeds the invented names 'running' and 'pending', so it passes against a shape the API never produces.

The result: with relayUrl set, the Hook page timeline shows Building and Audit panel as pending for the whole run and only flips to complete at the end, so the real stage names the job asked for are never shown in their active state.

Job 5 makes IMD the first and default pairing for type A, and body() sends pairWith:'imd', but the fee sentence of the objective is fixed text that names ETH as the pair currency. For an IMD-paired launch the body therefore contains an instruction that cannot be satisfied (there is no ETH side in a POND/IMD pool) and that contradicts the plane's own fixed fact for this pairing.

The live check does not refuse it (no blockers), so the user pays 0.5 IMD for a request whose fee rule is self-contradictory and whose interpretation is left to the builder. The same wording is in SPEC.md 5.1 (line 318), so resolving this needs an owner decision on the sentence for pairWith:'imd' (e.g. 'the pair currency (IMD) side'); the body shape itself is accepted and unchanged.

response.json() runs before the status check, so a non-JSON answer (a Cloudflare HTML error page for the Worker, an HTML 5xx from an intermediate proxy, or an empty body) throws a SyntaxError whose message is shown verbatim by useSwarmCheck/useOwnCode ('Unexpected token < in JSON at position 0') instead of the designed 'IMD could not finish this request (status)' text.

In useSwarmCheck this sets error, so the Launch gate reads 'Retry the free check before continuing', which is correct; the defect is only the message.

Fix shape: read text first and fall back to the status message when parsing fails.

Now: onReplaced assigns the confirmed cancellation hash and throws, but never marks it as a final failure. The catch saves it as pending. Check confirmation then rejects the successful self-transfer receipt for lacking an Approval event and preserves pending again. Approve, Launch and the payment-chain selector remain disabled.

Change to: Mark a confirmed cancelled approval as failed and allow a fresh approval; also let approval receipt recovery exit pending after a confirmed receipt proves the expected approval was not made. Preserve the pending lock for genuinely unknown receipts.

Why: The money path needs a usable failure/retry state. A transaction whose cancellation is confirmed is no longer pending, and checking its receipt must not trap the visitor forever.

Now: The twelve-block overlap only adds events. A request or completion removed from the canonical chain stays in records, rows and localStorage, so an orphaned request remains listed and an orphaned completion can keep a hook marked Live.

Change to: Reconcile each successfully reread overlap against canonical logs, removing orphaned requests and invalidating orphaned completions/results before hydrating and persisting the rows.

Why: The requested chain reads and money-path status must reflect actual Intake events; rereading a reorg window must be able to retract its former events.

Now: A successful /import is kept in Builder component state and silently fails to persist when sessionStorage is full. Continue to launch remains enabled. The Launch route remounts useOwnCode, loses the pinned source and sends the visitor back to resolve it again, creating an endless loop.

Change to: Retain the validated import record in module memory, keyed by relay/repo/commit, as useSwarmCheck already does for recentCheck, and hydrate that record on route changes when session persistence fails.

Why: Own-code repositories must resolve through /import before composing, and a successful resolution must survive the Builder-to-Launch navigation. A storage failure should not invalidate an already resolved source without warning.

Now: The displayed relative time is recalculated only when the launch id or updatedAt changes. Repeated successful /launches polls leave "just now" frozen indefinitely for the latest launch.

Change to: Refresh the relative-time text on every successful poll or a timer while keeping cast deduplication keyed separately to the launch id.

Why: The pond ticker names launches with their relative time; that visible age should continue to describe the returned timestamp as time passes.