Skip to content

Shared Site Rules

Purpose

This document defines the shared governing rules for the full Omnivoltaic front-end portfolio.

Use it for portfolio-wide standards only. Site-specific choices belong in docs/sites/. Metadata and headless-content contracts belong in docs/contracts/.

Site Portfolio

Family Current Scope Status
ISR-Sites marketing and public-facing Next.js ISR properties active
CRUD-Sites portal app, enterprise, admin panels, Odoo admin, selected legacy surfaces planned placeholder
Metric-Sites assets, diagnostics, avatar, telemetry, indexed business-data experiences planned placeholder

Current ISR-Sites

Site Canonical Path Delivery App
Omnivoltaic / dirac-uxi-isr/apps/isr/company
Off-Grid /off-grid dirac-uxi-isr/apps/isr/off-grid
Cross-Grid /cross-grid dirac-uxi-isr/apps/isr/cross-grid
Mobility /mobility dirac-uxi-isr/apps/isr/mobility
Productive /productive dirac-uxi-isr/apps/isr/productive

Potential extensions include country-specific marketing properties such as Omnivoltaic-Togo.

Governing Model

oves-sites is the governing authority for all front-end families in the portfolio.

The required model is:

  • metadata defines structure and UI behavior
  • headless content provides domain payloads through BFFs
  • downstream apps consume the contract rather than becoming the contract

Shared Navigation Rules

  • Use canonical path-based navigation under www.omnivoltaic.com.
  • Cross-site links must use canonical paths, not .pages.dev origins.
  • Shared header navigation should stay minimal and route-first.
  • Shared footer navigation should preserve cross-site discoverability, including links back to the Omnivoltaic hub.

Shared Page Families

Sites may expose page families only when the metadata model declares them.

Current ISR patterns include:

  • landing or root route
  • product collection and product detail routes
  • article collection and article detail routes
  • contact workflow routes when explicitly declared in intent

Future CRUD and Metrics families may add operational, record, dashboard, bot, or data-grid page families without changing the governing split between metadata and headless content.

Content Authority Rules

  • Products are authoritative in product-bff.
  • Articles and article collections are authoritative in article-bff.
  • Contact submissions are authoritative in the contact BFF flow.
  • Generated app JSON snapshots are deployable cache artifacts, not authored source-of-truth.
  • No actual domain data should be embedded into site metadata.
  • This repo must not describe local article markdown or local collection YAML as part of the operating content model.

Shared Experience Rules

  • Preserve brand consistency across all sites.
  • Preserve canonical URL behavior and one-page-one-canonical discipline.
  • Keep page composition decisions in site intent, not in app-side hardcoding.
  • Do not make direct site-app page edits to resolve intent, layout, or editorial issues. Correct the intent layer or scaffold translation instead.
  • Promote stable cross-site behavior into shared docs or contracts before expecting downstream reuse.

Delivery Contract

  • Delivery remains path-based and independently deployable per site.
  • Static export and ISR delivery are allowed implementation details downstream, but they do not change content authority.
  • If live BFF behavior and older local notes disagree, the live BFF contract wins.

Review Checklist

  • Does the page or route belong in governed metadata?
  • Does the domain object exist behind a BFF and get referenced instead of recopied?
  • Is any live data leaking into metadata?
  • Does the site use the correct family model: ISR-Sites, CRUD-Sites, or Metric-Sites?
  • Does the site use canonical paths and shared navigation/footer rules?
  • Does the change belong in shared guidance instead of a one-off site page?