Skip to content

OVES Sites

Purpose: Website design intents and specifications for Omnivoltaic's user-facing sites.

Scope: Forms stage of content lifecycle (Seed → Forms → Apps)

Overview

This repository houses the design intents, content specifications, and page layouts for all Omnivoltaic websites. These documents serve as "source code" for site architecture - update these intents first, then implement in actual applications.

Relationship to Other Repos

  • oves-sites (this repo) - Website design intents and specifications (Forms)
  • oves-decks - Presentation deck intents + apps (Forms + Apps merged)
  • dirac-uxi - All user-facing web application implementations (Apps)
  • content-workflow - Content lifecycle frameworks and workflows

Documentation Structure

Shared Resources

Foundation document for all sites: - Brand assets and design tokens - Default header/footer patterns - Typography, spacing, accessibility standards - Shared components and guidelines

Sites

Individual site design intents: - Omnivoltaic Corporate Hub ✅ - Mobility 🚧 Placeholder - Off-Grid Energy 🚧 Placeholder - Cross-Grid 🚧 Placeholder - Productive Use 🚧 Placeholder

Products

Product-domain information intents: - Products Domain - Retrieval Intents - Mutation Intents - Property Intents - Product Collection Intents

Articles

Article-domain information intents: - Articles Domain - Article Object Intents - Article Collection Intents - CMS Persistence Workflow - Publish and Sync Procedure

Contracts

Canonical contract references: - Canonical Pattern For CMS/BFF

Using This Repository

For Content Strategists

  1. Define page layouts and content structure here
  2. Specify blocks, sections, and content flow
  3. Document navigation and information architecture

For Developers

  1. Reference these intents when building sites in dirac-uxi
  2. Implement specified blocks and layouts
  3. Update intents when discovering better patterns

For Designers

  1. Use shared resources as design system foundation
  2. Specify visual treatments and brand applications
  3. Define responsive behavior and interactions

Content Developer Checklist (when preparing a change)

  1. Confirm the target site and page(s) in docs/sites/<site>.md are up to date and capture the intended change.
  2. For articles, prepare content using the current BFF marketing article schema as a guide (fields such as articleKey, slug, title, subtitle, heroImage, publishedAt, author, body).
  3. Place or update the article document under docs/articles (optionally grouped by site), keeping metadata aligned with the BFF schema and body written in Markdown.
  4. Review copy, tone, and imagery against docs/shared/all-sites.md (brand, theme, and SEO/accessibility guidelines).
  5. When ready for implementation, explicitly request a deployment by saying “rebuild site X”, where X is the site identifier (e.g. omnivoltaic, company, mobility).
  6. After deployment, verify the live site reflects the updated intents and article content.

Implementation Workflow

  1. Author intents in oves-sites (Forms stage)
  2. CMO/content owners define site structure, page list, and content/layout intents here first.

  3. No content or layout change should be made directly in app repos (e.g. dirac-uxi) unless it is already reflected in these intents.

  4. Implement apps in dirac-uxi (Apps stage)

  5. Developers use docs/shared/all-sites.md plus docs/sites/*.md as the source of truth when building apps under dirac-uxi/apps/isr (e.g. omnivoltaic, company, mobility, off-grid, productive).

  6. The architecture may evolve (single multi-tenant app vs per-site apps), but all implementations must remain aligned with this repo as the design/content authority.

  7. Deploy as ISR/static marketing sites

  8. Next.js apps use static generation + ISR, keeping most pages effectively static with controlled refresh.

  9. This matches the current requirement: “ISR and relatively static at this stage.”

  10. Content sources: current vs future

  11. Future state: All content ultimately lives in a headless CMS, surfaced through BFF APIs into the apps, while oves-sites continues to define structure, page intents, and narrative guidelines.

  12. Current interim:

    • Product data may already come from CMS via BFFs in certain apps.
    • Article content is authored locally in this repo (e.g. docs/articles/...) and treated as the source for the article pages until CMS integration is complete.

  13. Event-based propagation of changes

  14. Changes in oves-sites do not automatically update live sites.
  15. A content owner or developer must explicitly trigger an update (e.g. “rebuild site X”) to propagate new intents into the corresponding app and deployment.

For detailed documentation, refer to docs.omnivoltaic.com/oves-sites