feat(result-page): complete formal delivery and dashboard open flow for browser results

[jinyu918]

Summary

• Add stable URL-backed result_page payloads in the delivery layer. payload.url now points to the dashboard delivery route, and payload.path stays null to avoid workspace-file semantics.
• Wire browser/webpage result intents (page_read, page_search, structured_dom, browser_snapshot, browser_tabs_list) to default to result_page instead of bubble.
• Ensure agent.delivery.open returns open_action = result_page with a stable resolved_payload.url, even for historical or sparse records.
• Desktop shared open flow now recognizes dashboard-internal result-page URLs and routes them via requestDashboardTaskDeliveryOpen instead of opening an external browser tab.
• Add backend execution, RPC, orchestrator, and desktop contract test coverage. Update protocol/module docs and mark docs/work-priority-plan.md:244 as complete.

Risk

• The cross-contract coupling relies on the fixed prefix ./dashboard.html#/tasks/delivery/. Backend ResolveResultPageURL() and frontend isDashboardTaskDeliveryHref() must stay in sync if the route shape ever changes.
• delivery_result/resolved_payload still flow through map[string]any normalization. Schema drift remains possible if new fields are added without typed DTOs.
• The work-priority item mentions “页面解释”, while code/tests explicitly cover page_read, page_search, browser_snapshot. Reviewers may ask for clarification.

Test Notes

• Passed:
  • go test ./services/local-service/internal/delivery ./services/local-service/internal/execution ./services/local-service/internal/orchestrator
  • go test ./services/local-service/internal/execution ./services/local-service/internal/rpc
  • pnpm --dir apps/desktop typecheck
  • pnpm --dir apps/desktop lint
  • pnpm exec tsc -p tsconfig.dashboard-test.json
  • Targeted dashboard contract tests for result-page hrefs, shared open flow, and dashboard delivery navigation.
• Not run or blocked by pre-existing issues:
  • pnpm --dir apps/desktop test:dashboard blocked by an existing security-page style assertion.
  • pnpm --dir apps/desktop test:shell-ball blocked by FloatingPet.tsx TS7018 implicit any.
  • Full go test ./..., go vet ./..., staticcheck ./... not run in this iteration.

Reviewer Watchpoints

• services/local-service/internal/delivery/service.go
• services/local-service/internal/orchestrator/task_delivery.go
• services/local-service/internal/execution/service.go
• apps/desktop/src/features/dashboard/tasks/taskOutput.service.ts
• apps/desktop/src/features/dashboard/tasks/taskDeliveryNavigation.ts
• apps/desktop/src/app/dashboard/DashboardRoot.tsx

Closed #411

[fennoai]

One documentation accuracy issue is worth fixing; otherwise the result-page contract change looks coherent.

[codecov]

Codecov Report

❌ Patch coverage is 84.44444% with 14 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...cal-service/internal/orchestrator/task_delivery.go	81.48%	5 Missing and 5 partials ⚠️
...es/local-service/internal/presentation/messages.go	0.00%	2 Missing ⚠️
services/local-service/internal/rpc/stream_conn.go	71.42%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[jinyu918]

@xgopilot 现在看看还有什么问题

[jinyu918]

Findings

1. agent.delivery.open still falls back to task_detail for one important historical case: tasks that already persisted PreferredDelivery=result_page but do not have a first-class delivery_result row yet. In services/local-service/internal/orchestrator/task_delivery.go:73-89, the no-artifact_id path only reads latestAttemptDeliveryResultFromStorage(task) and then falls back to task.DeliveryResult. When storage returns nothing (services/local-service/internal/orchestrator/task_query_storage.go:744-750), buildDeliveryOpenResult(nil, nil, taskID) normalizes to task_detail, so the new result-page open flow is lost. The same gap also affects task detail hydration because agent.task.detail.get uses the same source (services/local-service/internal/orchestrator/task_query.go:95-100). That does not match the PR description of handling “historical or sparse records”.
2. The dashboard-internal result_page URL handling is not actually shared across all desktop resource openers yet. apps/desktop/src/features/dashboard/tasks/taskOutput.service.ts:176-191 correctly intercepts ./dashboard.html#/tasks/delivery/..., but note resources still classify result_page as a generic URL in apps/desktop/src/features/dashboard/notes/notePage.service.ts:234-235, and the executor there only allows http(s) URLs in apps/desktop/src/features/dashboard/notes/notePage.service.ts:838-844. Any note / todo related resource that now carries the formal payload.url shape will be blocked as an unsupported link instead of opening the dashboard delivery page. If the intent is a truly shared desktop open flow, this surface is still out of sync.

View job run

@xgopilot 对于你提的第一点，我已经修复了，不过第二点我觉得并未被本分支真正触发，不属于这次必须修的内容，所以我不认同把这件事定性成“这个 PR 还没把 shared desktop open flow 做完”，现在重新进行review一下，看看还有没有别的问题

[jinyu918]

@xgopilot 现在重新进行review一下，看看还有没有别的问题

[jinyu918]

@xgopilot 现在重新进行review一下，看看还有没有别的问题

[jinyu918]

@xgopilot 看看还有没有别的问题

[jinyu918]

@xgopilot 现在看看还有什么问题

[fennoai]

Findings

No new blocking issues found in this revision.

Notes

• I rechecked the previously reported gaps around sparse/historical result_page normalization and the waiting_input trace/audit false positives. In the current diff, those look addressed.
• I could not rerun the desktop contract suite here because pnpm is not installed in this environment.
• I started go test ./services/local-service/internal/delivery ./services/local-service/internal/orchestrator ./services/local-service/internal/rpc, but it did not return a final status in this session after dependency download and the internal/delivery package pass, so I cannot confirm the full three-package run from this environment.

View job run