Relationships
#4523 Native interactive report views in the dashboard, with scoped workflow refresh
Opened by jpisgeek · 11/8/2026
Native interactive report views in the Swamp dashboard
Problem and working example
Swamp behaviors and workflows already produce useful versioned state and HTML, but opening an HTML artifact in the dashboard data viewer can present a block of source text rather than a readable report. A person using the dashboard from a phone wants to inspect observations, filter them, and press a named refresh button without handling an admin token or deploying a separate web application.
Our working Swamp Quest flow is the proving example: scheduled lightweight system checks, public leaderboard ranks (all-time, week, day and streak), actual schedule state, recent workflow outcomes and run/version evidence in one report. The report includes filters and a Refresh live status button that runs an input-free Swamp workflow and then reloads the new snapshot. It also displays a bounded season window; the workflows pause when that window ends. Points are observations, not attributed to individual runs without evidence.
The deployed prototype uses a small adapter beside the existing dashboard. That proved the report and refresh flow, but native support would remove the need for users to maintain hosting glue. No machine addresses, tokens or household configuration are part of the proposed extension contract.
Proposal
Add an opt-in, versioned report-view registration surface for extensions:
- An extension declares a view ID, title, supported schema version, and the exact Swamp resource/report supplying its data. The dashboard discovers only installed declarations and data the viewer can read.
- Render structured data through a supported component contract, or render an HTML artifact in an explicitly isolated view. Keep a source/download view available. Never execute arbitrary extension HTML in the privileged dashboard origin.
- Allow local filters without starting workflows. Show producer observation time, stale/unavailable state, data versions and workflow run IDs.
- Register optional named actions, such as Refresh live status, bound by the operator to an exact workflow with fixed, validated inputs. Buttons do not select arbitrary commands, shells, provider operations or workflows.
- Use the existing authenticated session and enforce read/run grants on every request. A view-only user may read; a user with the exact refresh grant may press that button. Neither requires admin, vault-read or token-management access. Keep server credentials out of the page.
- Return real workflow evidence and status, including failure, cancellation, refusal, suspension and approval requirements. Reload data only after the refreshed snapshot is available. Add duplicate-click/idempotency handling.
The package @jpisgeek/dashboard-report-view provides a portable renderer,
structured snapshot schema, filters, refresh button, and a fetch-handler factory
for an existing host. It starts no server, creates no schedules and does not
claim that native dashboard registration already exists. Its host callbacks must
implement authenticated Swamp reads and the one configured refresh workflow. It
is a reference for the proposed contract, not a core patch.
Practical uses beyond Quest
- Fleet monitoring: Swamp Server runs system-check behaviors for
mac-mini,mac-studioand other configured workers; reports show observed memory, disk, service state, stale checks and run evidence. Worker routing and thresholds belong to the operator's workflows. - Maintenance readiness and rebuild prerequisites.
- Backup-verification evidence and missing or stale proof.
- Workflow outcome and exception reports with a controlled refresh action.
A future replacement server can reuse the same report contract. No future server rebuild, migration or fleet enrollment is part of this feature request.
Acceptance checks
A phone user can open a readable report, filter it locally, run an authorized refresh and see its evidence. A read-only viewer cannot refresh. Unrelated workflows, admin APIs and credentials remain inaccessible. Missing/stale data never appears healthy or freshly observed. Scripts cannot escape the view's isolation. An extension without a view keeps existing dashboard behavior.
Duplicate and related work check
Searched the Lab for dashboard, HTML, rendered, interactive report, dashboard extension, custom dashboard, HTML report, interactive, preview and custom view. No matching generic registration feature was found in the returned results. Related work reviewed:
- #2595: shipped data/report deep links; addresses navigation, not reusable interactive view registration.
- #4154 and #4155: a specific agent-sessions contract and dashboard page; useful precedent for data-driven view discovery.
- #4459 and #4474: integration workflow actions; reuse those authorization/audit primitives rather than inventing another action permission system.
This requests a Swamp CLI/serve/dashboard capability, not a fix to this locally owned extension and not a Swamp Club website feature.
Published reference
Source: https://github.com/jpisgeek/slog-bog/tree/main/dashboard-report-view
Package: @jpisgeek/dashboard-report-view, initial public version 2026.11.08.1.
Independent release review passed; ten tests cover escaping, filtering, controlled refresh, authorization denials and error handling. This is a reference adapter and proposal, not a claim that core dashboard support has shipped.
Open
No activity in this phase yet.
jpisgeek commented 11/9/2026, 11:26:49 AM
Field-tested prototype update — 2026-11-09
The Quest report is now working substantially better in day-to-day use. Owner testing includes the MacBook Air and phone browsers Safari and Orion.
The deployed prototype now provides:
- A persistent Quest report entry beside the native dashboard, plus a same-tab return to dashboard home.
- Readable memory/disk units, observation ages, explicit stale/unknown states, local filters, and expandable run/version evidence.
- Refresh live status bound to one named, input-free Swamp workflow. It waits for completion and reloads the resulting snapshot. Duplicate clicks and refusal/busy/failure feedback are handled.
- View/refresh access without admin rights or copying a token into the phone. Temporary setup credentials were revoked and their local files removed after deployment.
An integration lesson worth carrying into the native feature
Isolated endpoint checks missed a real navigation failure in our temporary adapter. After a dashboard asset opened a persistent HTTP connection, later Quest requests on that connection bypassed the adapter's first-request dispatcher and reached the upstream as an unknown route. The report could open once, then return “Not found” after navigating away and back.
We reproduced and corrected that adapter bug by closing ordinary forwarded HTTP connections after their response while preserving WebSocket upgrades. We also normalized same-origin path-only and full-URL request targets and added canonical entry redirects. These are fixes to our prototype adapter, not a report of a Swamp core defect.
Verification now covers the complete sequence:
dashboard → JavaScript/CSS assets → Quest → dashboard → assets → Quest → refresh → reloaded snapshot
- 27 focused prototype tests pass, covering routing, controls, data contracts, connection handling, byte-preserved bodies, and WebSocket pass-through.
- Automated HTTP journeys pass from two host contexts; native dashboard WebSocket upgrade returns 101, and the scoped refresh creates a newer versioned snapshot.
- Owner browser testing supplements those automated checks; automated visual browser QA is not being claimed.
What this adds to the proposal
A native report-view contract should include a discoverable navigation entry, stable full-page/deep links, return/back navigation, and an authorized named-action bridge. Acceptance tests should exercise the full asset/navigation/action journey, including connection reuse, rather than only checking that each URL returns 200. Freshness must remain tied to observations, and local age/filter updates must not silently start workflows.
Swamp Quest remains the proving flow: useful scheduled machine checks, public leaderboard observations, schedule state, and run evidence in one view. The same mechanism can support fleet checks, maintenance readiness, and recovery-evidence reports.
The public reference remains @jpisgeek/dashboard-report-view version 2026.11.08.1, with source on GitHub. That release provides the reusable renderer and existing-host handler; these deployment-specific relay fixes are prototype evidence, not a claim that native dashboard registration or a new package release has shipped.
Sign in to post a ripple.