feat: JobExecutionDTO read model; job detail stops reading mock data (PX-6)

[LamaSu]

PX-6 (product pack §7, gateway read-model lane). The live Jobs list drilled into a job detail page built from mock data, and the gateway's own job DTO reported completed as settled. This PR adds a typed read model for one job and makes the detail page a projection of it.

Stacked on #313 (it uses the canonical money map, classifyMoneyStatus). The PR base is master so CI runs. Until #313 merges, its 3 commits also show in this diff. This PR's own commits are 3ea0cd4e, 506b2dc2, 1a80846a and 562f0578.

What was wrong (at ac86a404)

• JobDetailPage read only mockJobs, jobMeta and mockEscrows, which are empty since mock-data was emptied, so every real job showed "Job not found". Its only content was a hard-coded evidence array, hard-coded DID, IPFS CID and Base/Solana tx hashes, and a "Load demo trace" fixture.
• job.populator.ts buildTimeline emitted a settled event for any completed job, so paid was inferred from completion on the server.
• In the job-row vocabulary, settled is written by mock settlement with no money moving, and escrows has no jobId, so the job↔escrow link has to be resolved.

GET /api/jobs/:jobId/execution → JobExecutionDTO (@pcc/spec, pcc.job-execution/v1)

The DTO has four independent axes. Each has an explicit enum, names its source, and carries the source's own timestamps. Axes never borrow meaning from each other.

Axis	Source	States
execution	gateway job row	pending, queued, dispatched, running, awaiting_handoff, paused, completed, failed, timed_out, cancelled, unknown, from one exact table covering every documented job vocabulary. An undocumented value is unknown, never success.
evidence	gateway evidence store	none / received / unavailable, with bundle and event counts and fabricated-by-design events counted by the canonical isFabricated. Received is not verified.
verification	capture verdicts	The outcome is not_available (no public verdict read exists). Capture checks are counted as capture checks only.
settlement	gateway escrow record (not a finalized chain read)	link linked / not_linked / ambiguous / unavailable; money states via #313's map; payout paid / refunded / not_paid / simulated / unknown

Payout rules:

• Payout reads the job's own milestone, matched by step.
• The whole-escrow status is used only when the escrow has no milestones at all, so a sibling step's release never pays this job.
• A mock-escrow-* escrow is simulated, never paid.
• More than one candidate record (escrow or milestone) is ambiguous, and nothing is chosen.
• A failed source read is unavailable with a generic error. It is never an empty list or a default.
• asOf is the READ time (render-provenance contract #2222/#2232).
• Same auth gate as GET /api/jobs/:jobId. Under TENANT_ENFORCE, a job belonging to another tenant returns 404.

Also

• The legacy timeline now emits completed for completed. A row that itself says settled is still echoed.
• JobDTO rows carry executionPhase, read on the server, so the list never re-derives it.
• GET /api/jobs keeps { jobs } and adds collection-v1 items (for the closed IR, #2231), total (all matching jobs, not the page length), offset, limit, hasMore and asOf.
• Dashboard: JobDetailPage renders only the DTO.
  • Payment is green only for a gateway-classified paid, and recorded amounts are labeled "recorded".
  • A 404 shows "Job not found"; any other failure shows "unavailable" with a retry.
  • A failed refresh keeps the last read and marks it stale.
  • The page polls until the job reaches a terminal phase.
  • An "Inspect raw record" section keeps ids and raw statuses available.
  • useJobs now throws on an off-schema response instead of returning []. ApiError keeps the HTTP status.
• JobsPage belongs to the shell lane (PX-3) and is not changed here.

Tests

• @pcc/spec: 832/832 (8 new).
• Gateway: 3017 passed, 6 skipped, 0 failed at the pushed head (36 new: 34 read-model plus 2 populator).
• Dashboard: 238/238 (15 new), and tsc -b && vite build is clean.
• Negative tests, one per rule:
  • completed with no record is not paid;
  • a job row that says settled is not paid;
  • funded plus completed is not_paid;
  • a refund is never paid;
  • an unknown money status is never paid;
  • a mock escrow is never paid;
  • sibling releases never pay this job;
  • ambiguous escrows or milestones choose nothing;
  • evidence is never verification;
  • a failed read is unavailable and leaks no internal detail;
  • missing timestamps stay null;
  • tenant isolation holds;
  • the dashboard never paints a non-paid payout green and never imports fixtures.
• Mutation check: 16/16 red. Each rule above was broken on purpose and the suite failed each time.

Not in this PR (tracked)

• Two more read routes still infer settlement from completion: GET /api/settlement/:jobId (settled = completed) and GET /api/jobs/:jobId/settlement (completed → "settled", plus a paidAmount that holds the escrow total or quote). These are money-semantics routes, so the fix goes on a separate branch for cross-family review.
• KernelDetailPage still reads mock data, the same continuity break for kernels.
• Registering this route in the closed-IR BIND_POLICY follows feat(genui-b): closed render IR + promotion - modern-port of #272 and the 6 orphaned promotion commits #344/feat(genui-b): derived render-state provenance - source-assigned class, freshness, no regression (PX-4; depends on #344) #348.

Revision 2 (6c88956b..7e6071b6): answers the cross-family review (coord-watch #2477, astra: DO-NOT-SHIP)

Finding	Fix	Proof
P1-1: the resolver took the first unique lookup as proof of the job→escrow link	Every recorded identifier (session escrow address, session CWM, job CWM) is looked up in full, with cardinality checked. Several rows for one identifier → ambiguous. Identifiers naming different escrows, an escrow contradicting a session identifier, or a session that records no escrow → conflicting. The job CWM links alone only when the job has no session.	Reviewer's counterexample; address duplicates; session address vs job CWM; session address with no row; session CWM contradicting the escrow
P1-2: zero milestones meant a whole-escrow payout	An escrow with no milestone rows → payout unknown. There is no whole-escrow fallback at all.	Every escrow status with [] milestones → unknown
P1-3: a released milestone beat the escrow's own status	reconcilePayout(milestone, escrow). Released + refunded/disputed/slashed/expired/unrecognized → unknown; unreleased or refunded + all-released → unknown. Both carry the settlement_records_conflict notice. Paid/refunded carry payoutConfirmation: "record_only". statusObservedAt: null because the record stores no status time.	Full milestone × escrow table
P1-4: secondary badges bypassed the simulation guard	Escrow and milestone statuses are neutral record text built from the DTO's classification and prefixed "Simulated:" on mock escrows. Only the payout badge can be green.	Every canonical money status × simulated renders gray; a page-source ratchet forbids re-classification
P1-5: no object authorization (IDOR)	authorizeJobRead runs before any axis is read, whatever TENANT_ENFORCE says. It allows a valid X-Admin-Key (constant-time compare, no dev bypass), the kernel operator, or the recorded buyer. Anonymous → 401; anyone else → 404.	Anonymous, stranger, operator, buyer, admin and wrong admin key, each under both TENANT_ENFORCE settings
P2: polling stopped at the terminal phase	Polling never stops: 15s while running, 60s after. Freshness is also age-based: a read older than two intervals shows as stale.	Freshness tests; hook-source ratchet
Legacy lie	The JobDetailDTO timeline no longer emits settled from a job row (mock settlement writes it).	Populator test
Design #2510	No work phase uses a success or animated chip.	View test

Authorization limits (stated in the code). The principal is the API key's operatorId; a proven identity is board N2 (gateway lane). The only record of the buyer is the negotiation session's userAgentId. Jobs submitted without a session record no buyer, so for those only the operator and admins can read.

Tests at 7e6071b6:

• spec 832/832
• gateway 3039 passed, 6 skipped, 0 failed
• dashboard 248/248; tsc -b && vite build clean

Mutation check: 17/17 red. Each of the rules above was broken on purpose, and the suite failed every time. The initial run left two guards uncaught; I added tests that isolate them. Secret scan: 0 findings.

Revision 3 (7e6071b6..513b933a): carries #313's fix, and "paid" is no longer reachable from gateway records

• Merge 7ec16196: brings in fix(ui-kit,dashboard,spec): one canonical money-status map - no refund/allocated/unknown as settled-green #313's fixed head a813c013 (steward #2688, genui #2743). The merge applied cleanly. feat: JobExecutionDTO read model; job detail stops reading mock data (PX-6) #353 no longer carries the old 506f437e code on its own.
• 513b933a: adapts the payout axis to fix(ui-kit,dashboard,spec): one canonical money-status map - no refund/allocated/unknown as settled-green #313's map, following steward ruling #2490 (settlement tone comes only from authoritative money state).
  • Every bare word is now a non-green tone. Reconciling by tone would have turned a recorded release into not_paid, which is false. So the payout reads the gateway's escrow words exactly.
  • reported_released is a new payout state: this job's milestone record says released, and the escrow record does not contradict it. It carries payoutConfirmation: "record_only", is gray, and says it is not confirmed. On a V-next escrow, "released" can mean allocated, not paid out.
  • paid is reserved for an authoritative settlement read model: a V-next lifecycle or receipt that classifySettlementRecord shows as released. No gateway escrow record produces it. A test sweeps every word pair of the money map to check this. That answers the open review question ("can payout be paid when this job's money was not released?"): no.
  • A milestone saying completed is ambiguous, so it is unknown. Conflicts are unchanged.
• Evidence:
  • Gateway 3042 passed / 6 skipped / 0 failed; spec 861; dashboard 249, tsc -b clean.
  • Mutation check on the new rule: 5/5 red.
  • Secret scan of the range: 0 findings.

🤖 Generated with Claude Code

https://claude.ai/code/session_01A2ZvsqsAb7jC7AC8Viisqn