vince/dimensionlab-website
1
0
Fork 0
Code Issues 5 Pull requests Projects Releases Packages Wiki Activity Actions

Umbrella: System overview homepage dashboard #1

New issue
Open
opened 2026-06-18 15:17:16 +02:00 by vince · 0 comments
vince commented 2026-06-18 15:17:16 +02:00
Owner
Copy link

Goal

Build Dimension Lab's website as a one-page, dense brutalist System Overview dashboard and turn it into the foundation for a proper Homepage competitor.

This is not a Homepage customization and should not depend on Homepage runtime, Homepage frontend code, or Homepage config as the product architecture.

Product direction

The product should be an agent-configurable dashboard runtime:

  1. Renderer / look-and-feel tier

    • Owns layout, typography, grid structure, reusable components, visual states, responsiveness, and interactions.
    • Must not contain Dimension Lab service names, metric labels, URLs, descriptions, host names, thresholds, status copy, or operational values.

  2. Dashboard model tier

    • A versioned, validated, JSON-serializable dashboard document is the canonical source of truth.
    • The model describes dashboard metadata, layout, service groups, telemetry cards, status bars, datasource references, status rules, icons, links, and display units.
    • YAML/JSON files may exist as optional import/export formats, but they are not the primary architecture.

  3. Agent configuration tier

    • AI agents configure dashboards through safe, typed operations instead of editing raw files.
    • Operations should be narrow and validated, such as create_dashboard, add_section, add_service, add_metric_card, connect_datasource, set_status_rule, arrange_item, preview_changes, publish_changes, and rollback_revision.
    • Every write should validate, preview cleanly, and create a revision that can be rolled back.

Design reference

System overview dashboard reference

Library baseline

  • App/runtime: SvelteKit + TypeScript + Vite.
  • Model/schema: @sinclair/typebox as the source for TypeScript-compatible JSON Schema, with ajv for runtime validation.
  • Persistence: drizzle-orm + SQLite first, with migrations and a practical path to Postgres later.
  • Agent diffs/previews: RFC 6902 JSON Patch-compatible diffs for preview and repair loops.
  • Icons: Iconify-style icon identifiers in model data, rendered by Iconify in the UI layer.
  • Charts/sparklines: uPlot where real time-series rendering is needed; tiny native SVG is acceptable only for simple static sparkline presentation components.
  • Component review: Storybook for isolated review of every content-free UI component and state variant.
  • Tests/QA: vitest, playwright, msw, and accessibility checks.
  • MCP: @modelcontextprotocol/sdk only after the internal agent-safe API is stable.
  • Avoid as first-version dependencies: Homepage runtime, large UI kits, Tailwind as the main design layer, Redux-style state stores, heavy chart suites, and YAML as the runtime source of truth.

Architecture requirements

  • Build a real one-page SvelteKit/TypeScript website/app, not a marketing landing page and not a Homepage skin.
  • Keep the presentation tier content-free and reusable.
  • Keep Dimension Lab-specific content in dashboard model data, seed data, persistence, or documentation only.
  • Use a schema-backed dashboard model as the contract between renderer, persistence, datasource adapters, and agents.
  • Provide validation errors and preview diffs that AI agents can use to repair failed edits.
  • Support optional JSON/YAML import/export later without making flat files the source of truth.
  • Treat datasource integrations as adapters that normalize values into the dashboard model/rendering pipeline.
  • Make the layout responsive without losing the desktop command-center feel.
  • Add accessible contrast, keyboard navigation, loading/error/empty states, and reduced-motion behavior.

PR-sized child issues

  • #2 Scaffold SvelteKit product runtime
  • #3 Define versioned dashboard model and validation
  • #4 Add persistence, migrations, and rollback for dashboard models
  • #5 Build agent-safe dashboard configuration API
  • #6 Build content-free brutalist design system
  • #7 Render dashboards from the validated model
  • #8 Add datasource adapters for telemetry and status
  • #9 Add optional import and export for dashboard models
  • #10 Add visual QA, accessibility, and release checks
  • #11 Create initial Dimension Lab dashboard model seed
  • #12 Expose dashboard configuration as MCP-ready tools
  • #13 Add Storybook component explorer for dashboard UI

Recommended implementation order

  1. #2 Scaffold SvelteKit product runtime.
  2. #3 Define versioned dashboard model and validation.
  3. #4 Add persistence, migrations, and rollback for dashboard models.
  4. #6 Build content-free brutalist design system.
  5. #13 Add Storybook component explorer for dashboard UI.
  6. #11 Create initial Dimension Lab dashboard model seed.
  7. #7 Render dashboards from the validated model.
  8. #8 Add datasource adapters for telemetry and status.
  9. #5 Build agent-safe dashboard configuration API.
  10. #9 Add optional import and export for dashboard models.
  11. #12 Expose dashboard configuration as MCP-ready tools.
  12. #10 Add visual QA, accessibility, and release checks.

Rationale: first establish the app runtime, model contract, and persistence. Then build/review the visual component system in isolation, add the Dimension Lab seed data, wire the renderer, add live data, expose agent configuration, and finish with release-quality QA.

Design notes

  • This should feel like an operational control surface, not a marketing landing page.
  • Favor dense full-width bands and grid sections over soft cards.
  • Keep edges sharp, typography compact, and status hierarchy obvious.
  • Use real Dimension Lab service names and useful operational data only through model/seed data.
  • Treat the look-and-feel layer as reusable product code that could render a different environment from a different model.

Open questions

  • What exact dashboard model shape should v1 expose for telemetry, services, status bars, layout, and datasources?
  • Should the first persistence layer be SQLite only, or SQLite with an easy path to Postgres later?
  • Which metrics should be wired to Prometheus/Grafana/node exporters versus configured or placeholder values for the first pass?
  • Which services must be clickable on day one?
  • Should weather and system stats be fetched server-side, client-side, or omitted until live data is available?
  • What is the first agent integration target: internal API only, MCP server, or both?
## Goal Build Dimension Lab's website as a one-page, dense brutalist **System Overview** dashboard and turn it into the foundation for a proper Homepage competitor. This is not a Homepage customization and should not depend on Homepage runtime, Homepage frontend code, or Homepage config as the product architecture. ## Product direction The product should be an agent-configurable dashboard runtime: 1. **Renderer / look-and-feel tier** - Owns layout, typography, grid structure, reusable components, visual states, responsiveness, and interactions. - Must not contain Dimension Lab service names, metric labels, URLs, descriptions, host names, thresholds, status copy, or operational values. 2. **Dashboard model tier** - A versioned, validated, JSON-serializable dashboard document is the canonical source of truth. - The model describes dashboard metadata, layout, service groups, telemetry cards, status bars, datasource references, status rules, icons, links, and display units. - YAML/JSON files may exist as optional import/export formats, but they are not the primary architecture. 3. **Agent configuration tier** - AI agents configure dashboards through safe, typed operations instead of editing raw files. - Operations should be narrow and validated, such as `create_dashboard`, `add_section`, `add_service`, `add_metric_card`, `connect_datasource`, `set_status_rule`, `arrange_item`, `preview_changes`, `publish_changes`, and `rollback_revision`. - Every write should validate, preview cleanly, and create a revision that can be rolled back. ## Design reference ![System overview dashboard reference](https://git.dimensionlab.net/attachments/39e9396a-a4cc-4110-aadd-633bda94cd03) ## Library baseline - App/runtime: SvelteKit + TypeScript + Vite. - Model/schema: `@sinclair/typebox` as the source for TypeScript-compatible JSON Schema, with `ajv` for runtime validation. - Persistence: `drizzle-orm` + SQLite first, with migrations and a practical path to Postgres later. - Agent diffs/previews: RFC 6902 JSON Patch-compatible diffs for preview and repair loops. - Icons: Iconify-style icon identifiers in model data, rendered by Iconify in the UI layer. - Charts/sparklines: `uPlot` where real time-series rendering is needed; tiny native SVG is acceptable only for simple static sparkline presentation components. - Component review: Storybook for isolated review of every content-free UI component and state variant. - Tests/QA: `vitest`, `playwright`, `msw`, and accessibility checks. - MCP: `@modelcontextprotocol/sdk` only after the internal agent-safe API is stable. - Avoid as first-version dependencies: Homepage runtime, large UI kits, Tailwind as the main design layer, Redux-style state stores, heavy chart suites, and YAML as the runtime source of truth. ## Architecture requirements - Build a real one-page SvelteKit/TypeScript website/app, not a marketing landing page and not a Homepage skin. - Keep the presentation tier content-free and reusable. - Keep Dimension Lab-specific content in dashboard model data, seed data, persistence, or documentation only. - Use a schema-backed dashboard model as the contract between renderer, persistence, datasource adapters, and agents. - Provide validation errors and preview diffs that AI agents can use to repair failed edits. - Support optional JSON/YAML import/export later without making flat files the source of truth. - Treat datasource integrations as adapters that normalize values into the dashboard model/rendering pipeline. - Make the layout responsive without losing the desktop command-center feel. - Add accessible contrast, keyboard navigation, loading/error/empty states, and reduced-motion behavior. ## PR-sized child issues - [ ] #2 Scaffold SvelteKit product runtime - [ ] #3 Define versioned dashboard model and validation - [ ] #4 Add persistence, migrations, and rollback for dashboard models - [ ] #5 Build agent-safe dashboard configuration API - [ ] #6 Build content-free brutalist design system - [ ] #7 Render dashboards from the validated model - [ ] #8 Add datasource adapters for telemetry and status - [ ] #9 Add optional import and export for dashboard models - [ ] #10 Add visual QA, accessibility, and release checks - [ ] #11 Create initial Dimension Lab dashboard model seed - [ ] #12 Expose dashboard configuration as MCP-ready tools - [ ] #13 Add Storybook component explorer for dashboard UI ## Recommended implementation order 1. #2 Scaffold SvelteKit product runtime. 2. #3 Define versioned dashboard model and validation. 3. #4 Add persistence, migrations, and rollback for dashboard models. 4. #6 Build content-free brutalist design system. 5. #13 Add Storybook component explorer for dashboard UI. 6. #11 Create initial Dimension Lab dashboard model seed. 7. #7 Render dashboards from the validated model. 8. #8 Add datasource adapters for telemetry and status. 9. #5 Build agent-safe dashboard configuration API. 10. #9 Add optional import and export for dashboard models. 11. #12 Expose dashboard configuration as MCP-ready tools. 12. #10 Add visual QA, accessibility, and release checks. Rationale: first establish the app runtime, model contract, and persistence. Then build/review the visual component system in isolation, add the Dimension Lab seed data, wire the renderer, add live data, expose agent configuration, and finish with release-quality QA. ## Design notes - This should feel like an operational control surface, not a marketing landing page. - Favor dense full-width bands and grid sections over soft cards. - Keep edges sharp, typography compact, and status hierarchy obvious. - Use real Dimension Lab service names and useful operational data only through model/seed data. - Treat the look-and-feel layer as reusable product code that could render a different environment from a different model. ## Open questions - What exact dashboard model shape should v1 expose for telemetry, services, status bars, layout, and datasources? - Should the first persistence layer be SQLite only, or SQLite with an easy path to Postgres later? - Which metrics should be wired to Prometheus/Grafana/node exporters versus configured or placeholder values for the first pass? - Which services must be clickable on day one? - Should weather and system stats be fetched server-side, client-side, or omitted until live data is available? - What is the first agent integration target: internal API only, MCP server, or both?
codex-clipboard-d1e22f89-486e-42e8-b0fe-745a1e4e733c.png
1.3 MiB
vince added the
umbrella
 label 2026-06-18 15:17:16 +02:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
codex/remove-prompts-site-item
codex/use-host-deploy-runner
codex/document-forgejo-runner-deploy-option
codex/forgejo-actions-auto-deploy
codex/fix-initial-stale-health-summary
codex/dashboard-sse-events
codex/dashboard-batch-tiles
codex/dashboard-observability
codex/dashboard-adaptive-hydration
codex/dashboard-last-known-tiles
codex/dashboard-service-snapshot
codex/dashboard-tile-cache
codex/dashboard-hydration-scheduler
codex/dashboard-client-lifecycle
codex/fix-website-container-build
codex/independent-tile-hydration
codex/ui-submodule
codex/turbo-env-inputs
codex/ui-prop-type-exports
codex/turbo-ui-entrypoints
codex/turbo-package-exports
codex/turbo-pruned-container
codex/turbo-ui-filetree
codex/turbo-package-boundaries
codex/turbo-idiomatic-workspace
codex/turbo-component-library
codex/console-visual-system
codex/brutalist-theme-toggle
codex/light-mode-toggle
codex/react-migration
codex/agent-config-tier
codex/dashboard-type-balance
codex/dense-bookmark-dividers
codex/issue-1-observability-dashboard
codex/decorative-style-primitives
codex/issue-10-mvp-qa-gate
codex/issue-7-model-renderer
codex/issue-11-dimension-lab-seed
codex/issue-13-storybook
codex/issue-6-design-system
codex/issue-4-dashboard-persistence
codex/issue-3-dashboard-model
codex/issue-2-sveltekit-runtime
No results found.
Labels
Clear labels   
agent

AI-agent configuration surface and tool contracts

  
architecture

Product architecture and core technical decisions

  
backend

Server runtime, persistence, and APIs

  
frontend

Frontend UI, renderer, and visual system work

  
quality

Testing, accessibility, QA, and release readiness

  
telemetry

Metrics, health checks, status, and datasource integrations

  
umbrella

Tracks a multi-part design/build initiative

No labels
agent
architecture
backend
frontend
quality
telemetry
umbrella
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: vince/dimensionlab-website#1
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?