feat(dashboard): show existing explicit and Dream operation outcomes across artifact pages #2310

Feature description

Implementation sub-issue of #2130: present available explicit-operation and Dream evidence on applicable Artifact pages, including Skill, Prompt and Handoff, and the explicit/Dream paths of other families.

Use existing operation records and exact result references where available. Clearly state when asynchronous processing status is not applicable or when an outcome is unavailable.

Problem and proposed solution

Source-consumption positions cannot explain every Artifact path. A Skill derivation or Experience refinement can have a retained Dream run, while a synchronous generation path may have no retained asynchronous lifecycle. Prompt configuration/availability badges describe a different fact from an operation's outcome.

Inventory each supported path and adapt its existing read API or record into the parent's compact status section and details presentation. Reuse existing scoped Dream list/get reads for supported operations; inspect any other path's actual evidence before promising an outcome. Do not create new operation history to fill missing fields.

A Dream success can produce a pending Candidate rather than publish an Artifact. The view must preserve that distinction and use exact references for any result it displays.

Acceptance criteria

• Complete the family/path coverage matrix for explicit generation, supported Dream operations and Handoff outcomes. Record which paths have retained operation evidence, which have genuinely associated local observations, and where status is unavailable or inapplicable.
• Render bilingual status/details on applicable pages using bounded existing queries or links to existing records. Clearly distinguish a selected Artifact's exact operation/result from a separately labeled Scope-level recent operation.
• Associate evidence using the authorized Scope, actual operation and available exact references. Never label an unrelated latest Dream run as the selected Artifact's current status.
• Distinguish accepted/queued/running/terminal operation state, Candidate creation, Artifact publication and an explicitly known no-change outcome. Successful generation or Candidate creation must not be labeled as publication.
• Preserve historical outcomes and timestamps without treating an earlier failure as an unresolved current failure after later success. Local observations include coverage/freshness; after restart, unavailable local history stays unavailable.
• For paths without an asynchronous lifecycle, mark that dimension not applicable. Where a lifecycle/result may exist but cannot be inspected, report unavailable. Do not fabricate operation identities or introduce a universal state machine.
• Preserve selected-Scope and exact-record authorization. Use bounded pagination/filtering instead of scanning complete run history; failures in this section must not prevent independent Artifact reads. Any necessary public contract extension follows the RFC/generated OpenAPI workflow.
• Inspection must remain passive: no generation, readiness probes, approval, retry, cancel, resume, budget reset or business/processing-state writes.
• Verify queued/active/terminal Dream records, Candidate-only success, known no-change results, historical failure followed by success, absent/unobservable evidence, unrelated exact references, Scope isolation and partial read failure. Exercise the Dashboard behavior with controlled records rather than production model calls.
• Combine this slice with feat(dashboard): show passive Topic Memory processing status #2308 (Topic Memory) and feat(dashboard): show scoped Source-consumption progress for Memory, Profile and Experience #2309 (Source consumption) to verify feat(dashboard): show artifact processing status using existing evidence #2130's full cross-page acceptance. Document each supported/unavailable/inapplicable path and interpretation in both locales.

Alternatives considered

Applying Source cursors to explicit/Dream operations invents a lifecycle. Treating every successful Dream as publication hides pending review. Adding a new task ledger or complete history solely for the Dashboard expands the parent issue beyond its existing-evidence contract.

Additional context

Baseline: master bf2ac1fcd9223af7bbab97f8e8e39a269b07fee3, checked on 2026-10-30.

• Dream run and Candidate-reference models
• Existing scoped Dream reads
• Public API contract, including Dream list/get
• Current Prompt page
• Current Handoff page

Duplicate check: all 86 open issues and the changed-file lists of all 33 open PRs were checked. No open equivalent Dashboard implementation issue/PR was found. #2130 is the parent; #1984 covers broader outcome explanations and #2105 targets Desktop. #2270 proposes a durable Work Ledger but does not implement these Dashboard pages and is not required to display existing records. #2244 changes authorization imports only.

Coordinate read-boundary/presentation conventions with #2308 and #2309. Keep new recovery policy with #2128, diagnostic export outside this issue, and operation behavior at its owning service. Closing this slice can close #2130 only after the other slices and the parent's complete acceptance criteria are verified.