Design and writing

One site.
One visual language.

Sidecat’s website should make the product and its development easy to understand. Clarity, readable evidence and consistent navigation come first.

Typography

Use Public Sans for headings, navigation, body text and status labels. Its open shapes suit both short explanations and long technical documents. The variable Latin font is hosted with the site; no third-party font request is needed. Use the system monospace family only for code, commands and exact identifiers.

Body text starts at 16 pixels with 1.65 line height; long documents use 1.75. Ordinary prose stays within 72 characters per line. Use weight and size to express hierarchy. Headings use sentence case. Reserve all-caps text for an identifier that requires it.

Color

Use a light neutral background, dark readable text and teal for links and primary actions. Color has a purpose: selection, emphasis or status. State labels must also explain their meaning in words.

Paper
#f8faf9

Surface
#ffffff

Ink
#203532

Muted text
#536862

Accent
#075c52

Soft accent
#e7f1ed

Layout and navigation

All current pages use the shared SiteLayout.astro header, footer, page width and stylesheet. The wordmark is readable text with a small tail; do not squeeze text into an icon-sized box. The cat remains a supporting mascot.

The homepage introduces the product. The development section separates the contract, evolving guide, timestamped progress and trial evidence. Long Markdown documents use DocumentLayout.astro, with section links, a source download and content digest. Keep tables inside their own keyboard-accessible horizontal scroll region. The page itself must fit a narrow screen.

Use spacing and headings before adding boxes. Borders separate content; backgrounds identify a related region. Avoid decorative gradients, unnecessary shadows and unprompted motion. Layouts become a single column on small screens. Preserve visible focus, a skip link and reduced-motion behavior.

Writing and organization

Write for people and agents reading the same material. Each page should answer a clear question; headings should make its structure visible.

  • Lead with the answer. Explain the useful outcome before introducing internal terms.
  • Develop one idea at a time. Use short paragraphs, labeled sections, and lists for parallel points. Avoid strings of keywords that readers must interpret.
  • Keep needed detail. Define ambiguous terms and include examples that help a reader act. Remove repetition, background that does not affect the decision, and explanations that add no meaning.
  • Give reference material its own place. Keep entry pages short; link to protocol details, evidence, and history rather than repeating them.
  • Use one source. Render prose from its Markdown document. Generate structured formats from that source when a tool needs them.

Claims and review

Distinguish planned behavior, implemented code, an installed trial, and a qualified release. State observations and limits plainly. Review the whole changed passage for clarity and meaning; passing a build does not establish editorial quality.

The contract defines the required product. The development agreement defines delivery checks. The guide describes working arrangements, and progress reports current facts. Label history and proposals where readers encounter them.

Maintaining the system

Edit tokens and shared rules in static/styles.css. Prefer shared layouts to copied headers. When adding a page, check its title, description, navigation, links, narrow-screen behavior and keyboard access. Check changed charts or tables with real content, including long references and empty states.

Public Sans is distributed under the SIL Open Font License. The vendored Latin variable font comes from @fontsource-variable/public-sans version 5.3.0. Archive pages keep their historical content and use the same typography and palette.