Documentation hub

A site handbook for shared content, design rules, and release-ready public pages.

This documentation is about how OpenCorex is structured and maintained. It explains how content flows through the site, where the design language lives, and what to verify before shipping an update.

Overview

The public site is structured as a shared content system, not a collection of isolated pages.

Most public copy, project metadata, and recurring section content live in one module so homepage highlights, project detail cards, and documentation references stay in sync as the platform evolves.

Quick start

Install dependencies

Use the existing package manager lockfile and run the local dev server before making layout changes.

Edit shared content

Update the canonical content module first whenever multiple pages reuse the same story or metadata.

Review in context

Check navigation, page flow, and footer handoff so the whole site feels coordinated after each change.

Core commands
pnpm install
pnpm dev
pnpm build
pnpm lint
Key files
app/
  (client)/
    (home)/page.tsx
    about/page.tsx
    contribute/page.tsx
    projects/page.tsx
    team/page.tsx
  docs/
components/common/
lib/site-content.ts
app/globals.css

Content model

How projects, working groups, and documentation are structured from one shared source of truth.

Centralized content data
Typed collections
Reusable page sections

Design system

The visual rules behind spacing, surfaces, navigation, and responsive behavior across the site.

Brand color tokens
Card hierarchy
Responsive layout patterns

Editorial standards

A lightweight content voice guide for public pages, labels, and supporting documentation.

Plain-language copy
Short paragraphs
Specific calls to action

Release flow

What to check before shipping updates so visual polish does not come at the cost of stability.

Local verification
Responsive review
Metadata and link checks

Support paths

Where to direct questions, security concerns, and contributor requests without creating dead ends.

Maintainer email
Security contact
Community channel routing

Cookies and storage

OpenCorex stores only the minimum needed to remember cookie consent.

The site uses a small consent cookie and a matching local storage record so the cookie banner does not reappear on every page load after a visitor makes a choice. We do not use this storage for advertising or behavioral profiling in the current public site.

opencorex_cookie_consent

Cookie

180 days

Stores whether the visitor accepted or declined the cookie banner.

opencorex_cookie_preferences

Local storage

Until cleared by the visitor

Keeps the visitor's most recent cookie consent decision on this device.

Quality gates

Design quality

Accessible contrast

Intentional spacing

Clear hierarchy

Consistent interaction states

Code quality

Typed data structures

Reusable sections

Build-ready pages

No unnecessary runtime fetches

Content quality

Specific messaging

Short paragraphs

Actionable labels

Honest, non-inflated claims

Release quality

Responsive review

Link checks

Metadata updates

Visible follow-up notes

Release checklist

Keep sections readable on small screens before polishing desktop details.
Prefer plain language over internal jargon whenever content faces the public.
Pair visual changes with spacing, contrast, and keyboard-flow checks.
Keep content in shared data structures when multiple pages depend on it.
Document follow-up work clearly instead of hiding unfinished assumptions in the UI.

Support paths

Route public questions, maintainer contact, and security concerns through the right channel.