[happy-v587]

Which issue or RFC does this PR close?

Closes #.

Rationale for this change

The Dashboard previously exposed Dream runs as a card grid without a readable task narrative, and offered no entry point for operators who need to wire up the cloud-native monitoring stack. This PR makes Dream task detail follow the actual execution order (Input → Processing → Output) and adds a static cloud-native monitoring guide so telemetry setup is documented where operators already work.

What changes are included in this PR?

• Dream run detail restructure: the Dream run detail view is extracted into its own component (dream-run-detail.html) and now follows Input, Processing, and Output in reading order. Input shows up to 20 authorized exact Artifact previews with identity and source references collapsed by default; the processing stage retains the recorded status, reason, error, timestamps and attempt count; output links to the recorded candidate or states explicitly that no new output was recorded. Unfinished tasks keep polling, and unselected sibling inputs no longer leak into the detail view.
• Cloud-native monitoring guide: a new static page under observation navigation (observability) covers managed Docker Compose deployment, Server telemetry settings, Grafana/Phoenix access, read-only verification and external platform connections, with bilingual (en/zh) content. The page keeps Dashboard authentication, requires no Scope or running monitoring stack, and performs no deployment actions.
• Type-scale consistency: processing detail sections now inherit one consistent font size so nested sections no longer mix competing scales.
• Bilingual documentation and labels: docs/en/development/dashboard.md, docs/zh/development/dashboard.md, and both label files gain the new sections and strings.

Are there any user-facing changes?

• The left navigation gains a "Cloud-native monitoring / 云原生监控" entry under Observation.
• Dream run detail pages present a new three-stage layout; there is no change to the underlying API or persisted formats.

How was this change tested?

• uv run pytest tests/test_dashboard_processing.py tests/test_dashboard_observation.py tests/test_dashboard_observability_guide.py -q — 47 passed.
• New regression assertions verify the Input → Processing → Output ordering, bounded input previews (unselected siblings excluded), collapsed references, candidate/no-output output stage, polling retention, and the new navigation entry.

AI usage statement

Implemented and validated with OpenCode (GLM model); code and tests were authored with AI assistance and reviewed by the human author.

[happy-v587]

UI 改动效果说明：#2371 (comment)

[hidb4ai]

Two Dashboard regressions reproduced against this commit with persisted SQLite data: the public Source reader crashes on missing save-time metadata, and Source rows attribute a sibling input's output to the wrong input. Details are inline.

[hidb4ai]

Re-reviewed 75c3911e25364c093820477fe721361a0c5575c8: the four reported Dashboard issues are fixed in the exercised read and navigation paths.

The merge gate is still red: cindy-package fails test_standalone_cindy_hooks_recall_capture_and_isolate_sessions[gateway] because the second session returns allow instead of rewrite; CI result fails consequently. The same test passes locally at this head using the pinned Cindy 0.1.115 gateway source and a real TCP/SQLite Server, so I have not established that this is a PR regression. Please investigate or rerun the failed job and obtain a green required CI result before merging.

[hireview001]

• Resolve merge conflicts with the target branch.

[happy-v587]

Addressed the outstanding gate items at aeba13c8:

• License headers: the 12 new dashboard component templates flagged by Check License Header (home-attention.html, home-processing.html, processing-coverage.html, processing-period-fields.html, processing-steps.html, processing-topic-status.html, runtime-configuration.html, topic-diagnosis.html, topic-retry-form.html, token-comparison.html, work-followup.html, usage-records.html) now carry the Apache-2.0 header. CI preflight passes on the new head.
• Merge conflicts: merge-tree against origin/master is clean and the PR reports MERGEABLE; no conflicting paths remain, so no rebase was required.
• cindy-package / test_standalone_cindy_hooks_recall_capture_and_isolate_sessions[gateway]: this run has not reached that job yet. It passed at this head locally per the earlier review, so I am waiting for the rerun result before treating it as a PR regression.

Inline review threads from the previous rounds are all resolved; the remaining blocker is a fresh approval plus the required checks finishing on the new head.

[happy-v587]

All required checks are green on 404e8bd0 (80 jobs completed, 0 failures, 60 passing checks, 21 skipped as not selected).

What changed since the last review:

• aeba13c8 restored the Apache-2.0 header on the 12 new dashboard component templates, so CI preflight passes.
• 5e8fb188 fixed tests/e2e/test_source_citation_locators.py::test_locators_survive_upgrade_reopen_http_and_mcp. The regression rewound pc_schema_revision to v1_5_0_003 but only dropped the table introduced by v1_5_0_004; with v1_5_0_005/v1_5_0_006 registered, their tables and indexes stayed installed and replaying the chain failed with index ix_pc_memory_processing_started already exists. The test now derives the tables to drop from the whole pending revision chain, so it keeps working as migrations are added. Reproduced locally before the fix and confirmed green after, plus tests/builtin/persistence (986 passed).
• 404e8bd0 is an empty retrigger commit: the earlier run failed tests (3.13, e2e) only on test_model_ingress_authentication_with_real_core_and_provider[advisory-responses] with httpx.RemoteProtocolError: Server disconnected without sending a response. That file is untouched by this PR and the same suite passed on 3.11, 3.12 and 3.14, so it was a flake; it passes on the rerun.

Merge state: MERGEABLE, merge-tree against the current origin/master is clean (the branch is 5 commits behind but has no conflicting paths). All inline review threads are resolved.

The remaining blocker is the outstanding CHANGES_REQUESTED from the review on 4bc3bd4, whose four Dashboard findings are already fixed per the follow-up review. A fresh approval is needed to merge.

[hidb4ai]

One current-head regression remains in feedback editing: saving a change to another field clears the existing reason from the latest feedback. Reproduction and required behavior are inline.

[happy-v587]

Rebased onto the current master and all required checks are green again on bd54aff0 (80 jobs completed, 0 failures, 60 passing checks, 21 skipped as not selected).

The branch had drifted 13 commits behind and desktop/VALIDATION.md, desktop/src-tauri/src/connections/compatibility.json, desktop/src-tauri/src/transport/operations.json, desktop/ui/src/generated/operations.ts and src/powercontext/server/dashboard/navigation.py conflicted.

Resolution:

• navigation.py: kept both sides. Master's new /dashboard/home return target stays, and this branch's /dashboard/notes reading route is added to the allowed set.
• desktop/VALIDATION.md: kept every qualification record from both sides; no historical record was dropped or rewritten.
• compatibility.json: kept all 65 master records and appended this branch's three records rather than picking one side.
• operations.ts / operations.json: regenerated from the merged openapi/powercontext.yaml instead of hand-merging hashes. I first verified the replication against master's committed output — both files reproduce byte for byte from master's contract — so the regeneration is the same code path pnpm --dir desktop generate uses. The only changes are the new contract digest and the new memory.processing feature contract.
• api.d.ts: regenerated the same way.

Merging master changed the HTTP contract digest, so the previously qualified record no longer matched and make contract-test failed. I ran a real qualification rather than relabeling: built the wheel from bd54aff0, built server_probe at Rust 1.95.0, and ran desktop/tests/real_server.py --product-qualification sqlite-dashboard-74082534-v1. All four SQLite modes passed (anonymous loopback, Bearer, HTTPS with explicit CA/base path, injected-provider/enforced) using the normal ConnectionManager without ci-fixtures; all 816 packaged runtime files match the recorded Git commit bytes. The record and a Server 74082534 Dashboard protocol qualification section are in desktop/VALIDATION.md. make contract-test is 68 passed.

merge-tree against origin/master is clean and the PR is MERGEABLE.

The only remaining blocker is the outstanding CHANGES_REQUESTED from the review on 4bc3bd4. Its four Dashboard findings were fixed in earlier commits, and every inline thread is resolved. A fresh approval is needed to merge.

[happy-v587]

Fixed in c1ca71c2.

The feedback editor's textarea had no value, so the form always submitted an empty reason even when the record already carried one. Changing only Adoption therefore wrote a new feedback record with reason: "" while the historical row kept its text — exactly the reported behavior.

The editor now prefills from the saved reason. An explicit clear still submits an empty value, so clearing remains possible.

Regression: test_editing_feedback_keeps_the_saved_reason_unless_cleared in tests/test_dashboard_usage.py. It reproduces through the Dashboard HTTP routes with persisted SQLite data, asserts the textarea carries the saved reason, edits only Adoption, and verifies both the rendered page and the two persisted pc_context_usage_feedback payloads still hold the reason; it then asserts an explicit clear still works. I confirmed the test fails against the unfixed template (assert '' == 'Used the region, but the deployment check still failed.') and passes with the fix. tests/test_dashboard_usage.py is 23 passed.

The review thread is resolved. The full CI suite is running on the new head.

[happy-v587]

Both P2 threads are addressed in c7492133 (and c328f926 for the Desktop contract requalification).

1. The alert and its destination now count the same statuses.
inputs_failed is seen_inputs - succeeded_inputs - pending_inputs, so it covers failed, cancelled, and conflict. The failure links previously asked only for status=failed, which opened an empty list whenever the attempt was cancelled or conflicted.

• list_scope_memory_processing now accepts a repeated status parameter (style: form, explode: true), following the existing tag precedent on list_artifacts; duplicates and unknown values are rejected, and the signed cursor binds the whole selection.
• The Dashboard uses one navigation token, run_status=unsuccessful, which requests all three statuses on both the Processing page and Home.
• memory.processing is bumped to 1.1 for the changed request surface.

2. Home's all-history alert opens an all-history range.
Home counts with processing_summary(all_time=True), but its detail link inherited Home's default 7-day window, so an older failure was counted and then hidden.

• The summary endpoint accepts an explicit all_time=true (rejects combining it with since/until) and reports since: null.
• The Processing page gained an all window for attempts; the alert links carry processing_period=all with no start/end, and the summary caption and period picker handle the unbounded range.

Regression coverage: tests/test_dashboard_processing.py::test_failure_navigation_reaches_every_unsuccessful_attempt (fails before the fix in both dimensions) and tests/e2e/test_memory_processing_records.py::test_home_alert_opens_the_same_all_history_range_it_counted. Both review threads are resolved.

🤖 Generated with Claude Code