Public site design task

Use this task with Claude Design to generate the first public website mockups for lightmetrics.dev. The output is a design reference for a later Astro implementation, not production source code.

Pipeline Role

Claude Design output is an upstream mockup bundle. It may use standalone HTML, CSS, JavaScript, React artifact code, external fonts, or prototype-only dependencies if that helps the design review. The production site must later translate approved screens into Astro components, layouts, and content pipelines. Do not treat generated dependencies, local mock data, or prototype interaction code as production constraints.

After the mockup is generated, the repository workflow is:

1. Archive the Claude Design handoff bundle under design-artifacts/claude-design/lightmetrics-public-site-YYYY-MM-DD.tar.gz.
2. Record the archive path, size, SHA-256, source task commit, and notable contents in docs/design-artifacts.md.
3. Review desktop and mobile screenshots for text fitting, layout overlap, and claim accuracy against repository docs.
4. Use the approved mockup as the reference for WEB-02 Astro implementation.

The generated artifact URL is a capability link. Do not put it in Git.

Files To Read Or Upload

Use these files as source material:

• README.md
• docs/README.md
• docs/limitations.md
• docs/PLAN.md
• docs/gantt-data.json

Optional context:

• docs/design.md for architecture details
• docs/quickstart.md for the current local demo flow
• docs/install.md for the current source-built install boundary

Do not use AGENTS.md, REVIEW.md, private agent procedure text, local tokens, or unpublished conversation context as public website content.

Project Context

Lightmetrics is a pre-production, self-hosted telemetry path for small fleets. It is not a hosted SaaS product and should not have pricing, signup, account, or enterprise-sales flows.

Current direction:

• a small Rust host agent
• one Rust collector process for ingest, live reads, disk cache, object-storage writes, and rollups
• Cap’n Proto batch serialization over HTTPS POST
• local durable agent queue and collector spool
• metrics, logs, and alerts ingest
• Prometheus-compatible metrics API subset for stock Grafana
• bounded JSON APIs for logs and alerts
• private built-in console for operational debugging and fleet visibility
• optional filesystem or S3-compatible object storage

Important limitations to keep visible:

• Lightmetrics is pre-production.
• Host telemetry covers capped Linux aggregate/per-core CPU, memory, load, queue-filesystem, network bytes, agent process CPU/RSS metrics, and bounded process enumeration without command-line argument labels; non-Linux host APIs and broader host coverage remain planned.
• Prometheus compatibility is intentionally narrow.
• Rollup workers, production service units, admin workflows, and several console surfaces remain partial or planned.
• Grafana support means stock Grafana querying Lightmetrics as a Prometheus data source. There is no custom Grafana plugin.
• Planned roadmap items are not product commitments.

Task

Create static public website mockups for lightmetrics.dev.

The site should explain what Lightmetrics is, what currently works, what remains planned, and how developers can evaluate it locally. It should also expose public documentation and a public roadmap/Gantt view.

The target audience is technical: developers, operators, and maintainers evaluating a small, owned telemetry path. The tone should be precise, restrained, and implementation-aware. Avoid vague marketing language.

Required Pages

Produce a responsive mockup covering these pages. A single HTML artifact with view switching is acceptable, but each page must be easy to inspect independently.

1. Landing page

   • first viewport clearly signals Lightmetrics
   • concise description of the project and current maturity
   • current-capability section that distinguishes implemented, partial, and planned behavior
   • compact architecture visual showing agent, collector, spool, object storage, private APIs, built-in console, and Grafana through Prometheus API
   • quickstart entry points linking to docs
   • limitations callout linked to the limitations page or docs section
   • roadmap preview linked to the public Gantt page
   • GitHub/source link placeholder

2. Documentation index

   • grouped navigation for current guides, design/reference docs, generated planning artifacts, and planned guides
   • visible status labels such as Current, Partial, Reference, Generated, and Planned
   • source links back to repository docs
   • no private agent procedure content

3. Representative documentation page

   • use the quickstart or architecture as the representative page
   • include a persistent docs navigation pattern
   • include code blocks, command blocks, callouts, and previous/next navigation
   • mark pre-production limits and partial behavior where relevant
   • show how planned guides appear without pretending they are complete

4. Public roadmap and Gantt page

   • consume the concepts from docs/gantt-data.json
   • show task status, priority, dependencies, estimated versus completed work, and task detail disclosure
   • include filters for status, priority, and workstream
   • include a clear note that estimates are planning artifacts, not commitments
   • prefer a static, inspectable representation over a backend-dependent widget
   • do not depend on docs/gantt-data.js; that wrapper exists only for the repository’s local file:// Gantt viewer

5. Limitations or status page

   • summarize current unsupported, partial, and operator-dependent behavior
   • link each limitation back to its source area or roadmap context
   • keep the page factual rather than apologetic

Design Direction

• Build a technical project website, not a SaaS landing page.
• Keep the first viewport direct and useful: project identity, status, primary navigation, and a real architecture or roadmap visual.
• Use visual assets that reveal the product shape: architecture diagram, roadmap preview, console/Grafana/API callouts, or code/terminal surfaces. Avoid generic stock images and purely decorative abstract art.
• Use a restrained palette with more than one functional accent color. Avoid a single-hue blue/purple gradient theme.
• Keep cards to repeated items, docs lists, callouts, and roadmap task rows. Do not nest cards.
• Use predictable docs navigation, tabs, filters, chips, tables, and disclosure panels.
• Text must fit at desktop and mobile widths without overlapping or clipping.
• Use icons only where they clarify navigation, state, or actions.
• The website may look polished, but it must not overstate maturity.

Content Rules

• Do not claim Lightmetrics is production-ready.
• Do not claim full host metrics are implemented.
• Do not claim full Prometheus compatibility.
• Do not claim rollups, admin workflows, package managers, or production service units are complete.
• Do not imply a hosted service, paid plan, signup flow, managed cloud offering, or public API service.
• Label planned and partial features clearly.
• Use Lightmetrics vocabulary from the docs: agent, collector, batch, boot ID, sequence range, local queue, local spool, accepted manifest, raw blob, object-store lag, duplicate, identity conflict, partial query, rollup lag, logs, alerts, histogram buckets, Prometheus API, Grafana, and dashboard definition.

Technical Constraints

• Provide a primary HTML entry point for review.
• A multi-file Claude Design bundle is acceptable.
• Do not require a backend.
• Keep JavaScript limited to mocked navigation, filters, disclosure, and page state.
• Use semantic HTML and accessible form controls.
• Use sample data only where needed to demonstrate layout and states.
• Keep external dependencies acceptable for a prototype but do not present them as required production dependencies.
• Include enough responsive behavior for desktop and mobile review.

Handoff Notes To Include In The Artifact

Include a short README or visible notes section that states:

• this is a Claude Design reference artifact
• production implementation target is Astro on Cloudflare Pages
• static Astro output should build to dist
• Cloudflare custom-domain work is gated and not part of the mockup
• generated prototype dependencies are not production constraints
• the public Gantt should use docs/gantt-data.json, not docs/gantt-data.js

Review Criteria

The mockup will be reviewed for:

• accuracy against README.md, docs/limitations.md, and docs/PLAN.md
• clear implemented, partial, planned, and gated status treatment
• usefulness for a future Astro component/content implementation
• docs navigation quality
• roadmap/Gantt readability
• mobile and desktop layout quality
• no overlapping text or clipped controls
• no private/internal procedure leaks
• no SaaS, signup, pricing, or hosted-service implications