Features

What the projectious.work design system provides to writers, designers, developers, and agents.

One contract, several consumers#

Design stance#

The system is disciplined, three-appearance, and quietly opinionated. It looks like infrastructure: readable, repairable, and free of decorative noise. Colour communicates meaning. Typography communicates role. Components remain ordinary enough to understand without learning a private visual language.

Included artifacts#

• Marketing header, hero, practice-area pillars, code showcase, convictions, closing action, and footer.
• Agent-console sidebar, top bar, pipeline list, status pills, run detail, terminal output, and system status bar.
• Six slide types at 1280 × 720.
• Logo variants, lockups, minimum-size and clear-space specimens.
• Core colours, complete ramps, semantics, type ramp, space, radii, elevation, breakpoints, icons, buttons, inputs, cards, tags, alerts, and accessibility.
• Dark and optional light syntax examples for Python, Rust, YAML, TOML, and LaTeX, plus terminal palette and status treatment.

Business card

The digital-first vCard, shared by QR code or link.

The primary format is digital — a vCard shared via QR code or direct link, not a printed card.

Paper stock#

The same card on white. This is the form to hand a printer when a physical card is required, and the one to reach for when the card will sit on a light surface it does not control — a conference badge holder, a scanned page, a slide.

Three things change, and nothing else does:

The wash does not survive the change of surface. At 12% on midnight it reads as a soft light source; at 12% on white it reads as a printing fault — an uneven patch of ink that a press will faithfully reproduce. So the accent moves to a rule down the leading edge, which is one line, prints cleanly at any size, and is the same device the signature uses.

The name, role, and contact rows keep their type sizes and weights exactly. Only their colours change, to the light-mode text steps: midnight-9 for the name, slate-9 for the role at 5.58:1, and slate-11 for the mono rows at 5.18:1.

Layout#

• Midnight surface, mark top-left, name in Plus Jakarta Sans 700.
• Role in Source Sans 3 400, in slate-dark-11.
• Contact rows in IBM Plex Mono at 11px — addresses and handles are data, and monospace makes them scannable and unambiguous.
• projectious.work always present.
• Accent used once, on the QR frame or the primary contact method.

Print fallback#

If a printed card is required:

• 85×55mm, matte stock.
• Single-colour midnight on uncoated white, or reversed white on midnight.
• Use the monochrome mark — no accent on press unless a spot colour is budgeted.
• Reserve clear space equal to half the mark’s height on every side; do not bleed the mark to the trim edge.

Handing colour to a printer#

The brand is defined in sRGB hex. Press is not sRGB, so a printed card needs the values converted — and the conversion is the vendor’s job, not a lookup table’s.

Give the printer the Lab values. They are device-independent: they describe the colour itself rather than one recipe for making it, so the vendor can hit them on whatever stock and profile the job actually runs on.

Do not guess a Pantone equivalent. If the job budgets a spot colour, give the vendor the Lab value and let them specify the closest ink; a Pantone number picked from a screen swatch is a different colour with an authoritative name on it.

Colour

Three 12-step scales, three appearances, semantic pairs, and the contrast rules that govern them.

The palette is three scales — midnight, orange, and slate — each expressed as a 12-step ramp in light and dark variants. Semantic aliases map those ramps into light, navy dark, and deep dark appearances. The step numbering follows the Radix convention, which assigns every step a role. Using a step outside its role is the single most common way to break the system.

Core colours#

These are the named aliases most projects reach for first. They are shortcuts into the scales, not a separate palette.

The light app background is midnight-1 (#f8f9fb), not white. White is the raised surface. Links use midnight-11, never the accent. Colour carries meaning: do not introduce bluish-purple gradients, rainbow categorisation, or decorative colour families.

Step roles#

Every scale uses the same twelve roles in the same order:

Midnight#

Midnight is the primary. It carries structure, text, and the calm end of the system. Step 9 (#1d3352) is the brand primary and is identical in every appearance.

Orange#

Orange is the accent. It marks the primary action, the active state, and little else. Step 9 (#e05232) is constant across appearances.

Slate#

Slate is the secondary — supporting text, borders, and neutral surfaces. Step 9 (#546a82) is the brand secondary and is constant across modes.

Terminal#

The dark terminal is the default and every colour in it is measured against midnight-dark-1. An optional light companion is available for explicitly light code and terminal panels; it is a separate measured palette, never an automatic colour-mode substitution. A terminal also needs six hues where the interface needs three, because programs have been writing to sixteen ANSI slots since long before this system existed.

So each terminal palette is a companion to the three interface scales rather than another scale: sixteen fixed ANSI slots plus chrome, derived from the ramps and measured against its own background.

Read the provenance column carefully. The bright ramp is the brand: where a hue already exists in the system, the bright slot takes that step verbatim. The normal ramp has no brand equivalent — the scales define one value per semantic role, not a dim and a bright — so each normal slot is its bright counterpart darkened until it reads a step back while still clearing the floor.

Magenta and cyan exist in neither half of the brand. They are here because a terminal requires them, and nowhere else.

Terminal chrome#

The accent gets no ANSI slot, because it is not semantic — it marks where you are. That, and the surfaces around the sixteen, live here.

Every non-background value clears 4.5:1 against the surface; the measured floor is 4.95:1. ANSI 0 bright is the one deliberate exception — programs use it for box drawing and rules, not for text.

Configuration for tmux, WezTerm, Kitty, Ghostty, iTerm2, and Zellij is on the Terminal theming page.

Contrast rules#

• Use semantic foreground roles for text. The fixed white token is valid on measured solid controls; screen copy uses the appearance’s foreground role.
• Step 9 is constant across modes. The solid accent does not shift when the theme changes.
• Body text targets 4.5:1, large text (≥24px, or ≥18.66px bold) targets 3:1.
• Verify against the actual surface. A step that passes on the app background may fail on an elevated panel.

Where an identity colour cannot carry text#

Being the brand colour does not make a value a legible background. White on orange-9 (#e05232) measures 3.87:1 — fine as a mark or a border, but below the floor for button labels. Rather than dilute the accent, the system adds a separate fill for that job:

The identity accent is never body text. Light-mode accent text uses orange-11 (#c04424); dark-mode accent text uses orange-dark-10 (accent-light, #ea7558). A solid control with a white label always uses accent-solid.

The same principle produced the code-comment token: when no existing step can do the job accessibly, name a new one rather than misuse a step.

Semantic colours are mode-specific#

The callout hues are tuned for dark text on tinted light backgrounds. Used as foregrounds on the dark app surface they fall below AA, so dark mode has its own set:

Use the matching -fg on a tint. Use --on-solid-* on a solid status fill: white in light, dark ink on the pale solids used by dark appearances. A muted page role is not automatically valid on a semantic tint.

Data visualisation#

A chart palette introduces no new colours. It is a set of rules for which existing steps may sit beside each other in a plot, and — more usefully — for when colour stops being the right tool.

Categorical: three series#

One step-9 solid per family, in that order. All three clear the 3:1 non-text contrast floor against a white plot area, so a bar or a line is visible without a border.

Assign them in order and keep the assignment stable across every chart in a deck or a dashboard: if midnight is “cloud” on slide four, it is “cloud” on slide nine. A series that changes colour between charts costs the reader more than a fourth series would have gained them.

There is no fourth series#

The palette stops at three, and extending it is the wrong fix. The step-6 tier is not an option: midnight-6 and slate-6 measure 1.03:1 against each other — the same colour, for practical purposes — and all three step-6 values sit at 1.8–2.0:1 against white, below the 3:1 floor for a mark you have to see.

When a chart has more than three categories, one of these is the answer:

• Group the tail. Rank the categories and collapse everything past the third into “Other”. If the fourth is genuinely interesting, it is the subject of its own chart.
• Small multiples. One chart per category, same axes, same scale. Reading eight small charts is faster than decoding an eight-colour legend.
• Direct labelling with one highlight. Draw every series in slate-7, draw the one being discussed in orange-9, and label it in place. This is the house style for a line chart in a deck — one idea per slide holds for charts too.
• Stop using colour. A ranked bar chart in a single colour, sorted by value, answers “which is biggest” better than any palette does.

Sequential and ordinal scales#

A magnitude scale uses one family, steps 3 through 8:

--midnight-3 → --midnight-4 → --midnight-5 → --midnight-6 → --midnight-7 → --midnight-8

Six levels, stepping evenly in luminance (each 1.06–1.40× its neighbour) — which is what makes the ramp readable as an ordered scale rather than as six colours.

Step 9 is not the top of that ramp. It is 3.87× darker than step 8, which is a jump the eye reads as a category boundary rather than one more level. Use it deliberately for exactly that: a four-bucket choropleth of 3 · 5 · 7 · 9, where the top bucket is meant to separate itself. Do not append it to a six-level heatmap.

Steps 3–7 are all below 3:1 against a white plot area, so a sequential fill needs an edge: give the plot a 1px slate-4 cell grid, or the reader loses the boundary between a light cell and the page.

For a diverging scale — where the middle is neutral and both ends are extreme — run midnight-8 → midnight-3 → orange-3 → orange-8, with --midnight-1 at the midpoint. Never build a diverging scale from success and danger: those hues carry a judgement, and “below average” is not “wrong”.

Chart furniture#

Numbers are set in IBM Plex Mono, right-aligned, for the same reason table numerics are: digits have to line up to be compared.

Three appearances#

Light, navy dark, and deep dark are equally supported. See Appearances for the derivative relationship, surface ladders, selection, elevation, and default-dark code and terminal surfaces.

Components

The component set as live specimens — buttons, inputs, cards, tables, navigation, feedback, overlays, and data display.

Every specimen on this page is live markup styled by the brand tokens, ported from the supplied preview cards. They follow their semantic token context — switch appearance and they remain legible with the documentation.

Measurements listed here are normative: a 40px input is 40px.

Buttons#

Five variants, three sizes. Plus Jakarta Sans 500, 6px radius, 200ms transitions.

Hover is structural across components: primary surfaces move to opacity:.88 and card borders move to midnight-7. Pressed controls remain at their hover state and never scale down. Do not lighten or darken a brand colour to create an interaction state.

Inputs#

Default height 40px (sm 32, lg 48). Source Sans 3 at 14px, a 1.5px semantic border, and the accent at 12% as the 3px focus halo.

Full rules — labels, validation, focus — are on Forms.

Cards#

Radius 9px, padding 16px 24px, 1px slate-5 border, flat at rest. shadow-1 is reserved for hover; nested controls step down one radius.

Transparency is restricted. Use backdrop blur only for dark-on-dark modal scrims and dark-panel inner cards, where the inner surface is rgba(255,255,255,.04). Do not put frosted glass on a light surface. Tags and badges use solid pale tints, never alpha overlays.

Tables#

Header cells use the overline style. Striping uses the subtle background step, never a border-only rule. Wide tables scroll inside their own container.

Table with search and filters#

A toolbar above the table carries the search field and filter chips. Active filters are shown as removable chips so the current view is always legible — never leave a filter applied with no visible indication.

Multi-level headers#

Grouped columns use a two-row header. The group row is centred over its span and separated by a vertical rule — the only place the system uses one.

Grouped rows and totals#

Row groups act as sub-headings inside the table. A totals row is separated by a 2px rule — heavier than the body rules, so it reads as a summary rather than another record.

Wide tables#

A wide table scrolls inside its own container, never the page, and pins its first column so the row identity stays visible while scrolling.

Navigation#

The navbar follows the colour mode: midnight-1 at 88% alpha in light, midnight-dark-1 at 88% in dark, both over a 12px backdrop blur so content scrolling underneath stays legible. It is separated by a 1px border, not a fill — the header is chrome, and a solid midnight band at the top of every page spends the brand’s darkest surface on navigation.

The active link carries a 2px accent-solid underline plus the high-emphasis text step. The underline is accent-solid rather than orange-9 because it sits directly against 13px text and is read as part of it.

This specimen mirrors .td-navbar — the header at the top of this page. Switch the theme and both change together.

Alerts and feedback#

Four semantic colours as a 4px left border on a tinted background. The hues are mode-specific — see Colour.

Modals and overlays#

Modal radius 13px with shadow-3; scrim is midnight at 40% alpha. Focus is trapped while open and restored to the trigger on close; Esc always closes.

Data display#

Code and terminal#

The code surface is dark by default. Use the complete light companion only for an explicitly light panel; never switch it automatically with interface mode. See Code.

Hugo

Apply the projectious.work brand through the supported Hugo theme, its public extension points, and site-owned content.

The supported Hugo implementation is projectious-work/brand-theme-hugo-vanilla. It is the reference shell for this documentation and the reusable starting point for other projectious.work sites. Use the theme’s layouts, tokens, components, and public extension points before adding site-local code.

This guide targets v0.3.2. Pin that release: a site should change its theme only in an intentional, reviewable update.

What the theme owns#

The theme implements the reusable documentation product rather than one particular site’s content.

Do not copy internal theme partials into a site. A copied internal file stops receiving fixes and silently becomes a fork.

Install and pin#

Use Hugo Modules and record the exact release in go.mod.

module github.com/projectious-work/example-site

go 1.25.0

require github.com/projectious-work/brand-theme-hugo-vanilla v0.3.2

module:
  imports:
    - path: github.com/projectious-work/brand-theme-hugo-vanilla

Fetch the module, then commit both module files.

hugo mod get github.com/projectious-work/brand-theme-hugo-vanilla@v0.3.2
hugo mod tidy

Run the development server from the Hugo source directory.

hugo server --disableFastRender

Configure the site#

The theme builds navigation from Hugo menus. Keep the public header short and stable; this site uses exactly five destinations.

menus:
  main:
    - name: Getting started
      pageRef: /getting-started
      weight: 10
    - name: Documentation
      pageRef: /docs
      weight: 20
    - name: Contributing
      pageRef: /contributing
      weight: 30
    - name: Downloads
      pageRef: /downloads
      weight: 40
    - name: Legal
      pageRef: /legal
      weight: 50

Use section indexes and page weights for the documentation hierarchy. Keep the header for global destinations; do not duplicate the entire documentation tree there.

Use the public content vocabulary#

Write ordinary Markdown first. Add a shortcode only when the content has a meaning Markdown cannot express, such as a labelled component specimen or a semantic callout. The theme exposes public shortcodes for its standard content patterns; see the theme’s reference implementation for current parameters and rendered examples.

Rules for site-local specimens:

1. Make the source understandable without relying on presentation alone.
2. Use semantic token names rather than copying colour literals into markup.
3. Show all appearances when colour or elevation changes meaningfully.
4. Keep keyboard order equal to DOM order.
5. Include the specimen’s intent and implementation rule in surrounding copy.
6. Prefer a local shortcode over enabling raw HTML throughout Markdown.

This documentation follows that model: colour scales, typography, controls, code, terminal chrome, layouts, and collateral are live translations of the design-system previews, not embedded screenshots of them.

Extend through supported hooks#

Version 0.3.2 provides public end-of-bundle hooks for site-owned assets.

layouts/
└── partials/
    └── hooks/
        ├── scripts-end.html
        └── styles-end.html

Compile a site stylesheet from the style hook:

{{- with resources.Get "scss/specimens.scss" -}}
  {{- $css := . | css.Sass | minify | fingerprint -}}
  <link rel="stylesheet" href="{{ $css.RelPermalink }}"
    integrity="{{ $css.Data.Integrity }}">
{{- end -}}

Load narrowly scoped behaviour from the script hook:

{{- with resources.Get "js/color-swatches.js" -}}
  {{- $js := . | minify | fingerprint -}}
  <script defer src="{{ $js.RelPermalink }}"
    integrity="{{ $js.Data.Integrity }}"></script>
{{- end -}}

Keep these hooks thin. They are integration points, not a place to recreate the theme pipeline.

Override deliberately#

The theme exposes a named main layout block and public partials for supported composition. Before overriding anything:

1. confirm Markdown, configuration, a shortcode, or a public hook cannot solve the requirement;
2. identify whether the target is documented as public;
3. copy the smallest possible unit;
4. add a comment naming the upstream version and reason;
5. re-audit the override on every theme update.

If several sites need the same override, propose it upstream. Repetition is evidence that the capability belongs in the theme.

Honour the appearance contract#

The brand has three appearances:

Do not derive one appearance by inverting another. Bind components to semantic roles and let each appearance provide its own values. Code and terminal specimens may also have explicit light variants; a code block is not required to stay dark merely because that was an older convention.

The initial inline appearance script must run before the first paint so the page does not flash in the wrong scheme. A visible control must remain keyboard operable, expose its current state, and persist the user’s choice.

Support every output#

The theme can render more than the browser page. Treat these as product surfaces, not build by-products.

Only enable outputs the site publishes, but test every enabled format in the release build.

Upgrade the theme#

Treat a theme update like a dependency change, not a cosmetic refresh.

hugo mod get github.com/projectious-work/brand-theme-hugo-vanilla@v0.3.2
hugo mod tidy
hugo mod graph

Then:

1. read the release notes and compare the module graph;
2. build from a clean destination;
3. review header, navigation, search, tables, callouts, code, and forms;
4. test light, navy, and deep appearances at narrow and wide widths;
5. test keyboard navigation, 200% zoom, reduced motion, and strong focus;
6. inspect print, Markdown, LLMS, and search-index outputs;
7. run link, contrast, and accessibility checks;
8. re-evaluate every site-local override.

Record the theme version in the site’s dependency and SBOM documentation. The Maintenance and SBOM pages define the repository-wide review and provenance expectations.

Acceptance checklist#

• Theme module is pinned to v0.3.2 and both module files are committed.
• Header contains Getting started, Documentation, Contributing, Downloads, and Legal in that order.
• Site additions use public hooks, blocks, partials, and shortcodes only.
• Light, navy, and deep appearances use semantic roles rather than inversion.
• Code and terminal examples include their defined light treatments.
• Tabler icons remain outline, 1.5px stroke, and use the approved size set.
• All enabled human and machine outputs build successfully.
• Narrow/wide, keyboard, zoom, motion, focus, contrast, and print checks pass.
• Local overrides have an owner, reason, and upstream-version review note.

Licensing

A split licence — brand assets are proprietary, code and tokens are MIT.

The repository carries two categories of intellectual property under different terms. The full text is in LICENSE.md; this page summarises it.

Brand assets — proprietary, source-available#

Everything representing the visual identity: logos, brand imagery, and the supplied design-system documents.

Document templates fall under these same terms: they embed brand identity (colours, fonts, tagline). You may use them as structural reference for your own templates, but not redistribute them with projectious.work branding intact.

Code, scripts, and tokens — MIT#

Source code, automation scripts, and configuration files (.py, .js, .sh, .json, .yaml) are MIT-licensed: use, copy, modify, merge, publish, distribute, sublicense, and sell, provided the copyright and permission notice travel with the software.

The design tokens — documented under Tokens — are in this category. The values are free to use; the marks are not.

What this means in practice#

For commercial inquiries or brand consent: info@projectious.work

Lockups

Four approved lockups, rendered live, and where each one belongs.

Four lockups are approved. Each has a defined context; using one outside its context is what makes a layout feel off-brand even when the colours are right.

All four are built with HTML and CSS rather than flattened artwork, so spacing comes from natural text flow and never needs re-kerning.

The four lockups#

On light and dark#

Every lockup has a light-surface and a dark-surface rendering. The mark’s inner cuts pick up the surface colour, so it never needs a plate or a knockout box.

The mark alone#

The mark may stand alone only where the wordmark is already established nearby — an app icon on a page that names the product, an avatar in a signed-in context, a favicon.

Minimum for the standalone mark is 16px. Below that the inner rings collapse; use a wordmark or a purpose-built favicon instead. Any lockup with a wordmark must be at least 24px high.

Product line#

Product names extend the wordmark with the same dot construction and flow.

Wordmark construction#

The separator between “projectious” and “work” is a dot in the mark’s own geometry, not a typed period. It takes slate on light surfaces and midnight-11 on dark. Spacing is handled by flex layout so the wordmark reflows naturally — do not hand-kern it or convert it to a static image.

Status treatments

Text-first maturity labels for truthful portfolio presentation.

Required pattern#

Every project presentation must show a status as text. Color, icons, position, and motion may reinforce the label but must never replace it.

Do not substitute broad claims such as “platform”, “production-ready”, or “enterprise” unless the owning repository publishes evidence for that claim. Prefer narrow artifact categories: CLI, process layer, applied research, prototype, library, or supporting asset.

Accessibility#

• Keep the full status label visible at all viewport sizes.
• Pair every color with the status-specific shape in the table.
• Use normal text contrast of at least 4.5:1 and large-text/UI contrast of at least 3:1.
• Test light and dark variants independently.
• Do not encode a status change with animation alone.

The source templates use high-contrast neutral text and reserve accent color for a supporting rule. Maintainers must rerun local validation after changing colors.

Project examples#

Examples are prompts for maintainers, not permanent factual claims. Confirm each status and limitation with the owning repository before publishing.

Composed patterns

How the components combine into whole screens — the page shell, the KPI row, and the primary/secondary split.

Components answers “what does a card look like”. This page answers the question after it: what does a whole screen look like when it is made only of those parts.

Nothing here is a new component. Every element below already exists on the components page; what is normative here is the arrangement — which regions a screen has, in what order, at what widths.

The page shell#

Three regions, always in this order in the DOM:

The sidebar is the only large midnight fill on the screen. It is the application’s frame, so it stays constant while the content region changes; a sidebar that re-renders per route reads as a page reload.

The header carries exactly one accent button. That is the whole quota for the screen — one accent per view — which is why the pattern places it here rather than leaving it to the content region to spend.

Below lg (1024px) the sidebar leaves and becomes the mobile navigation pattern; see Responsive.

On a light marketing or documentation shell, the header uses sentence-case navigation, the lowercase brand lockup, and one accent action on the right. The footer places the brand mark left and page metadata right in the caption style. Headers may stick; decorative elements and other page furniture may not.

The KPI row#

Directly under the header: four stat cards in a repeat(4, 1fr) grid, --space-4 gap.

Four, not three and not six. Three leaves a hole in a 12-column grid; six turns the row into a wall of numbers nobody reads. If there are five things worth measuring, the fifth one is not a KPI.

Each card is a pj-stat — the number first in Plus Jakarta Sans 800, its label under it in the overline style, then a delta line. The pj-stat carries its own border and radius, so it is not nested inside a pj-card; that would draw the box twice.

A delta states its direction in text or an arrow, not in colour. The default __delta is the success hue; a delta that is not good news takes an explicit colour, and a delta that is merely neutral takes the muted foreground rather than borrowing a semantic one.

Primary content and secondary panel#

Under the KPI row, a 1.5fr / 1fr split: the thing the page is about on the left, the thing that gives it context on the right.

• Primary is the record set — a table in a pj-table-shell, with its toolbar, filter chips, and pagination footer.
• Secondary is a pj-card holding a feed: a pj-timeline or pj-list of recent events, each with a status dot and a text label.

align-items: start, so the two panels are independent — the feed does not stretch to match a long table, and the table does not gain whitespace to match a short feed.

The split is 1.5fr / 1fr because the primary panel holds tabular data with four or more columns and the secondary holds one column of prose. An even 1fr / 1fr starves the table and pads the feed.

At md the ratio flattens to 1fr / 1fr; below md the secondary panel moves below the primary, in source order.

Reading the whole thing at once#

The supplied dashboard mockup is a client engagement dashboard built entirely from the parts above: page shell, KPI row, engagement table, agent-activity feed. Open it beside the components page and every element in it should be findable there.

The supplied mobile mockup is its narrow counterpart: the same system with the sidebar replaced by a tab bar and every region in one column.

Marketing page#

A marketing page uses the same tokens at a calmer editorial density. The designer’s UI kit composes seven regions: header, hero, practice pillars, code showcase, convictions, call to action, and footer. This condensed live translation keeps that sequence and hierarchy while allowing the documentation theme to own the surrounding page.

# Agent-validated deploy
policy: strict
agents: [auditor, deployer]
✓ 12 checks passed · 1.2s

The hero makes one claim, not a carousel of claims. The accent appears at decision points, the practice names remain joined by a middle dot, and the code panel stays an inset technical surface. At narrow widths the navigation disappears, pillars stack, and the showcase and call to action become one column; the source order already matches the reading order.

Density#

One pattern, two densities. The measurements on the components page are the comfortable density and are the default. A compact density exists for screens whose job is scanning many rows at once — an audit log, a run history:

Density changes padding and control height. It does not change type size, radius, or border weight — a compact table is the same table with less air, not a smaller one. Compact is never used on touch-primary surfaces, where the 44px floor applies regardless.

Appearances

Light, navy dark, and deep dark from one semantic token contract.

The system supports three appearances. They are not separate palettes and they do not permit component-specific colour forks.

With no explicit mode, the interface follows prefers-color-scheme. A dark preference resolves to navy dark. Deep dark is an explicit choice.

The specimen translates the designer’s shared three-way preview control into a simultaneous comparison: the component recipe stays identical while only its semantic token context changes.

Why navy is the default dark#

Deep dark begins at the bottom of the midnight ramp. Across a full interface, panels have little room to separate from the page and the result reads heavy. Navy begins higher. Raised surfaces remain visible, while a code panel can sit below the page tone and read as inset rather than as a hole.

Navy is a derivative of deep dark. It changes only midnight steps 1–5, surfaces, borders, and the neutral tag background. Orange, slate, text, status, terminal, and syntax roles remain the same.

Implementation#

<html data-theme="dark" data-focus="strong">
<!-- add data-surface="deep" only for the deep-dark appearance -->

• Components consume semantic tokens; they do not branch on appearance.
• orange-9 stays constant as the identity accent, but it is never body text.
• Light application pages use midnight-1, not white. White is raised.
• Elevation in dark uses an elevated surface step as well as a shadow.
• Solid status fills use --on-solid-*; the dark solids are light tints and cannot carry white text.
• Code remains on #131e2b and terminal output on #0e1720 in every page appearance.

Surface ownership#

An element that paints a deliberate dark slab—such as a marketing hero, terminal, modal, or footer—also establishes the appropriate foreground, secondary text, border, selection, and control tokens. It must not depend on the page appearance to make its contents readable.

Review contract#

Review every token-driven preview in light, navy dark, and deep dark. Then apply high contrast, strong focus, 200% text, loose spacing, reduced motion, and reduced transparency. A card that works in one screenshot has not passed.

Audio and video

Sonic identity and video production rules.

Audio identity#

Four defined cues. All are short, tonal, and mid-register — the audio equivalent of “slides into place, doesn’t bounce”.

Error is a single low note, not a buzz or a descending pair — it marks the event without scolding.

Video rules#

• Demos run at real time. No fast-forward, no speed ramps. If a step is slow, that is information the viewer needs.
• Transitions are a cut or a 200ms fade. No swoops, wipes, or 3D moves.
• All video uses midnight surfaces.
• Video never autoplays. Playback begins with a deliberate user action.
• Subtitles are always available.
• Export at 1080p minimum, 4K when possible.

Email signature

A signature that survives every mail client, carries the details business mail is required to carry, and stays quiet on a white message.

Email is not the web. Every value below is a literal, every layout is a table, and nothing depends on a stylesheet the client is free to discard.

Two forms are supplied:

The signature#

Both specimens are rendered on white, because that is where a signature actually lives. The surrounding page has a colour mode; a mail message generally does not.

One rule, and it is vertical#

A signature accumulates dividers as it accumulates fields — one under the name, another above the legal block, another before the disclaimer — and each reads as a section break in a message that is not sectioned. On a white background the result is a small form stapled to the bottom of a letter.

So there are no horizontal rules at all. One vertical accent rule runs down the left of the whole block: it marks the signature as a unit, ties it to the brand, and costs one line instead of four. Everything else is separated by space and by type size.

Fields#

Replace every [PLACEHOLDER]. Delete any row that does not apply — the block is built so that removing a row leaves no gap behind it.

What the law asks for#

A starting point, not legal advice — confirm against your own jurisdiction before shipping a signature.

Construction#

Declaring white three times is not belt-and-braces#

It is the difference between a signature that survives dark mode and one that does not, and it is the most common way this block breaks.

<table … bgcolor="#ffffff" style="…background:#ffffff;background-color:#ffffff;…">
  <tr bgcolor="#ffffff" style="background-color:#ffffff">
    <td bgcolor="#ffffff" style="background:#ffffff;background-color:#ffffff;…">

A client that repaints a message for dark mode works element by element: it looks at each one, decides whether it has a background it should keep, and inverts the rest. Declare white only on the <td> and the <table> around it has no background to keep — so the cell stays white while its own container is repainted dark. The result is a white island with a dark halo, or worse, the dark text inverted to light and then drawn on the white cell that was kept.

Every enclosing element that has a painted area needs the declaration, and each one needs it in both forms: the bgcolor attribute, which Outlook’s renderer prefers, and background-color, because several clients strip the background shorthand while keeping longhands.

Colours#

Three families, which is what a signature should have.

Before shipping a change#

• Send to Outlook (Windows), Gmail web, Apple Mail, and one mobile client.
• Reply to that message twice and check how the signature looks quoted inside a thread.
• Turn on the client’s dark mode and confirm the hierarchy still reads.
• Forward it, to confirm nothing depends on the original message’s styles.

Social previews

Repository artwork that states category and maturity plainly.

Content model#

Every 1280×640 preview contains only:

1. projectious.work organisation mark and name.
2. Project name.
3. One narrow artifact category.
4. One complete maturity label from the status vocabulary.
5. An optional short limitation, never a marketing claim.

Keep the status label intact and save a project-specific SVG beside its source. Examples demonstrate the content structure; they are not evidence of current maturity.

Export and validation#

Run:

bash scripts/validate-portfolio-assets.sh
bash scripts/export-portfolio-assets.sh

The export script uses resvg when available and otherwise leaves the SVG source as the canonical reusable asset. Commit generated PNGs only when a repository needs them.

Source and generated exports use this repository’s split license. The projectious.work name and marks remain subject to the trademark terms. Record any third-party typeface, icon, logo, or screenshot in the provenance inventory before use. The supplied templates contain no third-party logos or screenshots.

Terminal

The default dark and optional light projectious.work terminal palettes, plus configuration for tmux, WezTerm, Kitty, Ghostty, iTerm2, and Zellij.

This page is the source of truth for rendering the projectious.work brand in a terminal. It answers which sixteen colours the brand uses, which program owns each part of the result, and how to prove a configuration is conformant.

Real terminal and code chrome stays dark by default. The design system also defines an optional light companion for deliberately light specimens. It is a separate explicit choice—not a colour-mode response—and every value is measured against its own surface.

Implementation contract#

What owns what#

A terminal’s appearance is produced by two programs that do not overlap, and almost every “my theme is wrong” report is a confusion between them.

A multiplexer cannot fix a wrong ANSI palette, and an emulator cannot style a status bar. Configure the emulator first; a multiplexer theme applied over an unbranded emulator will look wrong no matter how carefully it is written.

Inputs and ownership#

Non-negotiable rules#

1. The default background is midnight-dark-1 (#0e1720). It does not follow page colour mode. A light terminal must explicitly select the companion set.
2. Every one of the fourteen non-background colours clears 4.5:1 against that surface. The measured floor for this palette is 4.95:1.
3. orange-9 (#e05232) is the cursor and the active marker. It is not a text colour in the palette, and it is never ANSI red — an error and the brand accent must not look alike.
4. Use IBM Plex Mono. Enable its ligatures only if the team has agreed to them; they change how operators read in diffs.
5. Dim text uses the dedicated comment token (#72889d), not ANSI bright black. Bright black is a border value here and fails text contrast on purpose.
6. Do not rely on colour alone for state. A red segment needs a word or glyph beside it.

The palette#

Sixteen colours#

The palette is defined in the Colour foundations and rendered here from the same source, so this page cannot state a value the foundations do not.

The bright ramp is the brand: where a hue already exists in the system, the bright slot takes that step verbatim. The normal ramp is derived from it — darkened until it reads a step back while still clearing the floor — and magenta and cyan exist in neither half of the brand. A normal-ramp value is a terminal value only: #e55b5b is the terminal’s red, not $danger (#a8261c).

Bright black is the one deliberate exception to the 4.5:1 floor: programs use it for box drawing and rules, not for text. If a program uses it for prose that is the program’s bug, and the fix is to configure the program — not to lighten the palette until unreadable text becomes readable.

The brand accent has no ANSI slot, because it is not a semantic colour: it marks where you are, which the chrome table covers.

Chrome#

Optional light companion#

The optional light terminal uses #f4f5f7 and a separately measured 16-slot ANSI palette. It is appropriate for a light-surface specimen or an environment whose operator has explicitly chosen a light terminal—not as an automatic response to the surrounding page.

Chrome uses foreground #142438, cursor #E05232, selection #dae2ec / #142438, dim text #5c6f82, status-bar surface #e6e8eb, and inactive pane border #adb2ba. The eight base tones clear 4.5:1; bright slots, the cursor, and UI chrome clear 3:1. Nothing switches to it automatically.

Syntax in the terminal#

An editor running inside a terminal paints code from the sixteen ANSI slots, not from a stylesheet. Since the syntax roles were reassigned by measured perceptual distance, seven of the nine now resolve to an ANSI slot exactly — so a file open in Helix, Neovim or Vim under this palette looks like the same file on the documentation site.

Strings and comments are the two that do not map. ANSI has no orange slot — orange is the brand’s accent family — and comments need a value dimmer than any slot provides while still clearing 4.5:1. An editor that supports truecolour should receive those values literally; one limited to sixteen colours should use bright red for strings and bright black for comments, accepting that the latter falls below the text floor.

tmux#

tmux styles its own chrome only. Everything inside a pane keeps the colours the emulator supplied, so configure the emulator first.

Required capability#

tmux must be told the terminal supports true colour, or every hex value silently degrades to the nearest of 256 approximations — which is the usual cause of a status bar that is “nearly right”.

# ~/.tmux.conf
set -g default-terminal "tmux-256color"
set -ga terminal-overrides ",*256col*:Tc"
set -ga terminal-overrides ",xterm-256color:Tc"

Verify with tmux info | grep -i Tc, or print a truecolour ramp inside tmux and check for banding.

Theme#

# ~/.tmux.conf — projectious.work

# Status bar
set -g status-style              "bg=#131e2b,fg=#c5daf0"
set -g status-left-length        32
set -g status-left               "#[bg=#e05232,fg=#0e1720,bold] #S #[bg=#131e2b,fg=#e05232]"
set -g status-right-length       80
set -g status-right              "#[fg=#7b8da3] %Y-%m-%d #[fg=#c5daf0]%H:%M "

# Windows — the active one is the single accent element in the bar
setw -g window-status-format         "#[fg=#7b8da3] #I #W "
setw -g window-status-current-format "#[bg=#e05232,fg=#0e1720,bold] #I #W "
setw -g window-status-activity-style "fg=#e0a92a"
setw -g window-status-bell-style     "fg=#e55b5b,bold"

# Panes
set -g pane-border-style        "fg=#7b8da3"
set -g pane-active-border-style "fg=#e05232"
set -g pane-border-status       top
set -g pane-border-format       " #{pane_index} #{pane_current_command} "

# Messages and the command prompt
set -g message-style       "bg=#131e2b,fg=#c5daf0"
set -g message-command-style "bg=#131e2b,fg=#e0a92a"

# Copy mode — selection matches the emulator's selection pair
setw -g mode-style "bg=#20354d,fg=#c5daf0"

# Popups (tmux 3.2+)
set -g popup-style        "bg=#131e2b,fg=#c5daf0"
set -g popup-border-style "fg=#e05232"

# Clock
setw -g clock-mode-colour "#8aacc8"

The active window is the only accent-filled element in the bar. Adding a second one — an accented session name and an accented window — removes the cue that tells you which window you are in.

Status-bar frameworks#

Many tmux setups do not write set -g status-* lines directly. A status-bar framework — tmux-powerkit, catppuccin/tmux, dracula/tmux and others — takes over status-format and re-renders it on its own schedule, overwriting anything set before it loads.

That is fine, and it does not need working around. Supply the framework with brand values through whatever palette hook it documents, rather than fighting it with set -g lines it will discard. The shape differs per framework; the values do not. A framework that reads an associative array, for example:

declare -gA THEME_COLORS=(
    [background]="#0E1720"
    [statusbar-bg]="#131E2B"
    [statusbar-fg]="#C5DAF0"
    [session-bg]="#E05232"
    [session-fg]="#0E1720"
    [window-active-base]="#E05232"
    [window-inactive-base]="#7B8DA3"
    [pane-border-active]="#E05232"
    [pane-border-inactive]="#7B8DA3"
    [error-base]="#E55B5B"
    [warning-base]="#E0A92A"
    [info-base]="#8AACC8"
)

Every value maps to a row in the tables above. Where a framework offers a slot the brand has no name for, resolve it from the palette rather than inventing a colour: a “modified” or “prefix” state is a warning, a “copy mode” state is informational, and both already have values.

If a framework exposes no palette hook at all, load the set -g block above after it — in tmux, later wins — and record the ordering dependency in the config, because a framework upgrade can silently reintroduce its own colours.

WezTerm#

WezTerm is configured in Lua, so the palette can be a table the rest of the config refers to.

-- ~/.config/wezterm/wezterm.lua
local wezterm = require("wezterm")

local pj = {
  bg        = "#0e1720",
  fg        = "#c5daf0",
  accent    = "#e05232",
  surface   = "#131e2b",
  selection = "#20354d",
  dim       = "#7b8da3",
}

return {
  font = wezterm.font_with_fallback({ "IBM Plex Mono", "Symbols Nerd Font Mono" }),
  font_size = 13.0,
  harfbuzz_features = { "calt=0", "liga=0" }, -- opt in to ligatures deliberately

  colors = {
    foreground    = pj.fg,
    background    = pj.bg,
    cursor_bg     = pj.accent,
    cursor_fg     = pj.bg,
    cursor_border = pj.accent,
    selection_bg  = pj.selection,
    selection_fg  = pj.fg,
    split         = pj.dim,

    ansi = {
      "#0e1720", "#e55b5b", "#3f9d74", "#c08a1e",
      "#6289b3", "#bd6d96", "#3f97a3", "#97a8b8",
    },
    brights = {
      "#2e4b68", "#f08b80", "#6cc090", "#e0a92a",
      "#8aacc8", "#d491b4", "#74c0c9", "#c5daf0",
    },

    tab_bar = {
      background = pj.surface,
      active_tab   = { bg_color = pj.accent,  fg_color = pj.bg,  intensity = "Bold" },
      inactive_tab = { bg_color = pj.surface, fg_color = pj.dim },
      inactive_tab_hover = { bg_color = pj.selection, fg_color = pj.fg },
      new_tab      = { bg_color = pj.surface, fg_color = pj.dim },
      new_tab_hover = { bg_color = pj.selection, fg_color = pj.fg },
    },
  },

  use_fancy_tab_bar = false,
  window_padding = { left = 12, right = 12, top = 8, bottom = 8 },
  inactive_pane_hsb = { saturation = 1.0, brightness = 1.0 },
}

Leave inactive_pane_hsb at 1.0. WezTerm’s default dims inactive panes, which silently pushes every measured value in them below the floor.

Kitty#

# ~/.config/kitty/kitty.conf — projectious.work

font_family      IBM Plex Mono
font_size        13.0
disable_ligatures always

background       #0e1720
foreground       #c5daf0
cursor           #e05232
cursor_text_color #0e1720
selection_background #20354d
selection_foreground #c5daf0
url_color        #8aacc8

# Normal
color0  #0e1720
color1  #e55b5b
color2  #3f9d74
color3  #c08a1e
color4  #6289b3
color5  #bd6d96
color6  #3f97a3
color7  #97a8b8

# Bright
color8  #2e4b68
color9  #f08b80
color10 #6cc090
color11 #e0a92a
color12 #8aacc8
color13 #d491b4
color14 #74c0c9
color15 #c5daf0

# Tabs — the active tab is the single accent element
tab_bar_style          powerline
tab_powerline_style    slanted
active_tab_background  #e05232
active_tab_foreground  #0e1720
active_tab_font_style  bold
inactive_tab_background #131e2b
inactive_tab_foreground #7b8da3
tab_bar_background     #131e2b

# Splits
active_border_color    #e05232
inactive_border_color  #7b8da3
window_padding_width   6

# Marks and bells
mark1_foreground #0e1720
mark1_background #e0a92a
bell_border_color #e55b5b

Kitty applies background_opacity before contrast is measured. Any value below 1.0 puts whatever is behind the window into every ratio on this page, so the palette is no longer measurable. Keep it at 1.0 for work that has to meet the floor.

Ghostty#

Ghostty reads a plain key = value file and supports named themes, so the palette is a separate file that the config selects. That is the idiomatic split: the theme file carries only colour, and the config carries everything else.

# ~/.config/ghostty/themes/projectious — colour only, nothing else
palette = 0=#0e1720
palette = 1=#e55b5b
palette = 2=#3f9d74
palette = 3=#c08a1e
palette = 4=#6289b3
palette = 5=#bd6d96
palette = 6=#3f97a3
palette = 7=#97a8b8
palette = 8=#2e4b68
palette = 9=#f08b80
palette = 10=#6cc090
palette = 11=#e0a92a
palette = 12=#8aacc8
palette = 13=#d491b4
palette = 14=#74c0c9
palette = 15=#c5daf0

background = #0e1720
foreground = #c5daf0

cursor-color = #e05232
cursor-text = #0e1720

selection-background = #20354d
selection-foreground = #c5daf0

# ~/.config/ghostty/config — projectious.work

theme = projectious

font-family = IBM Plex Mono
font-size = 13
font-feature = -liga
font-feature = -calt

cursor-style = block
cursor-opacity = 1

# The accent marks the focused split, and nothing else in the chrome.
split-divider-color = #7b8da3
unfocused-split-fill = #0e1720

window-padding-x = 6
window-padding-y = 6
window-padding-balance = true

link-url = true

theme also takes an absolute path, which is the better form for a config checked into a dotfiles repository: theme = /Users/you/dotfiles/ghostty/projectious.

Ghostty’s theme accepts a light:…,dark:… pair that follows the system appearance. Do not use that automatic pairing for the default configuration: dark is the product default. If a deliberately light terminal is required, configure the complete light companion palette as a separate named theme; do not mix its slots with the dark set. See Colour.

Four defaults have to be set explicitly, because each one moves rendered colour off the measured palette:

minimum-contrast = 1
background-opacity = 1
background-blur = false
unfocused-split-opacity = 1

Leaving unfocused-split-opacity at its default is the most common way this theme fails review: the split you are not looking at is the one you are reading a stack trace in.

Ghostty has no bold-brightening setting to disable — it renders bold as a bold face and leaves the colour alone, which is the behaviour the other emulators on this page need to be told to adopt.

Check the parsed result rather than the file, since an unknown key is skipped rather than reported:

ghostty +show-config | grep -E 'palette|background|foreground|contrast|opacity'
ghostty +validate-config

iTerm2#

iTerm2 stores colours as a plist of floating-point components, so hand-editing is error-prone. Generate the scheme instead:

#!/usr/bin/env python3
"""Emit projectious.iterm2colors — import via Settings ▸ Profiles ▸ Colors ▸
Color Presets ▸ Import. Regenerate rather than hand-editing the plist."""

PALETTE = {
    "Ansi 0":  "#0e1720", "Ansi 8":  "#2e4b68",
    "Ansi 1":  "#e55b5b", "Ansi 9":  "#f08b80",
    "Ansi 2":  "#3f9d74", "Ansi 10": "#6cc090",
    "Ansi 3":  "#c08a1e", "Ansi 11": "#e0a92a",
    "Ansi 4":  "#6289b3", "Ansi 12": "#8aacc8",
    "Ansi 5":  "#bd6d96", "Ansi 13": "#d491b4",
    "Ansi 6":  "#3f97a3", "Ansi 14": "#74c0c9",
    "Ansi 7":  "#97a8b8", "Ansi 15": "#c5daf0",
    "Background": "#0e1720", "Foreground": "#c5daf0",
    "Bold":       "#c5daf0", "Cursor":     "#e05232",
    "Cursor Text": "#0e1720", "Link":      "#8aacc8",
    "Selection":  "#20354d", "Selected Text": "#c5daf0",
    "Badge":      "#e05232", "Tab":        "#131e2b",
}

def component(value):
    return f"<real>{int(value, 16) / 255:.10f}</real>"

rows = []
for name, hex_value in PALETTE.items():
    h = hex_value.lstrip("#")
    rows.append(
        f"\t<key>{name} Color</key>\n\t<dict>\n"
        f"\t\t<key>Color Space</key>\n\t\t<string>sRGB</string>\n"
        f"\t\t<key>Red Component</key>\n\t\t{component(h[0:2])}\n"
        f"\t\t<key>Green Component</key>\n\t\t{component(h[2:4])}\n"
        f"\t\t<key>Blue Component</key>\n\t\t{component(h[4:6])}\n"
        f"\t\t<key>Alpha Component</key>\n\t\t<real>1</real>\n\t</dict>"
    )

print('<?xml version="1.0" encoding="UTF-8"?>')
print('<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" '
      '"http://www.apple.com/DTDs/PropertyList-1.0.dtd">')
print('<plist version="1.0">\n<dict>')
print("\n".join(rows))
print("</dict>\n</plist>")

python3 make-iterm-scheme.py > projectious.itermcolors
open projectious.itermcolors     # registers it as a preset

Two iTerm2 defaults have to be turned off, both under Settings ▸ Profiles ▸ Colors:

Zellij#

Zellij declares a named theme in KDL and paints its own UI from it.

// ~/.config/zellij/config.kdl
themes {
    projectious {
        fg      "#c5daf0"
        bg      "#0e1720"
        black   "#0e1720"
        red     "#e55b5b"
        green   "#3f9d74"
        yellow  "#c08a1e"
        blue    "#6289b3"
        magenta "#bd6d96"
        cyan    "#3f97a3"
        white   "#97a8b8"
        orange  "#e05232"
    }
}

theme "projectious"

pane_frames true
ui {
    pane_frames {
        rounded_corners true
        hide_session_name false
    }
}

Zellij’s orange slot is what it paints the active pane frame and the session name with, so it takes the brand accent. Its red/green/yellow slots drive mode indicators — locked, pane, resize — which is why they must be the semantic values and not decorative choices.

Zellij has no separate bright ramp: it derives emphasis from the ten names above. Programs running inside it still receive the emulator’s sixteen, so the bright half of the palette is not lost.

Verify#

Palette#

Print the sixteen slots and compare them against the table above:

for i in $(seq 0 15); do
  printf "\033[48;5;%dm  %3d  \033[0m" "$i" "$i"
  [ $(( (i + 1) % 8 )) -eq 0 ] && echo
done

Confirm true colour reaches the terminal — this must print a smooth ramp, not bands:

awk 'BEGIN{for(i=0;i<256;i++){printf "\033[48;2;%d;%d;%dm ", i, 90, 120}print "\033[0m"}'

States to review#

A terminal theme that only renders a prompt is not complete.

Release evidence#

• the emulator and multiplexer versions, and the config files changed;
• a screenshot of the sixteen-slot ramp beside the table on this page;
• git diff, a failing command, and a split-pane view captured at the working font size;
• confirmation that minimum-contrast, bold-brightening, and transparency settings are off;
• for a multiplexer, evidence that true colour survives inside a session.

Sources and upgrade boundary#

• tmux manual
• WezTerm colour configuration
• Kitty configuration
• Ghostty configuration reference
• iTerm2 documentation
• Zellij theme configuration

When a terminal is upgraded, re-print the sixteen-slot ramp before assuming the theme survived. Emulators change their default handling of bold, dim, and minimum contrast between releases more often than they change colour parsing, and each of those silently moves values off the measured palette.

Trademark

Guidelines for referring to projectious.work and using its marks.

The names, logos, and icons associated with projectious.work are its trademarks. Full text: TRADEMARK.md.

Not permitted#

• Using the logo as your own, or as part of your own logo.
• Using the brand name in a way that suggests partnership or official status without a signed agreement.
• Registering domain names, social handles, or app names that include the trademarks in a confusingly similar way.

Permitted#

1. Linking to the official website.
2. Press articles or blog posts about the project.
3. Technical documentation that refers to the tools.

These are nominative uses — referring to the thing by its name. They do not require permission, and they do not grant any broader licence.

Typography

Three families, three roles, a scalable reading-first ramp, and the font cuts required to preserve meaning.

Typography answers one question before it answers any aesthetic one: what kind of information is this?

• Plus Jakarta Sans is conviction. Use it for display, headings, navigation, buttons, and the wordmark.
• Source Sans 3 is clarity. Use it for running copy, interface labels, descriptions, and captions.
• IBM Plex Mono is precision. Use it for code, data, terminal output, versions, and machine identifiers.

Never mix those roles. If the text guides attention, use Jakarta. If it is read, use Source Sans. If it reports a system, use Plex Mono.

Families and required cuts#

The mono cuts are semantic, not optional polish. Keywords use 700, types use 600, functions use 500, and comments and decorators use italic. Omitting those files forces synthetic styles and removes the non-colour channel that keeps syntax structure legible in greyscale.

The ramp#

Every row is rendered in the family, size, weight, and line height it documents. It translates the supplied type-family, display, body, code, and scale preview cards into one responsive reference.

Every size resolves through --font-scale. The accessibility settings raise the entire ramp to 112.5%, 125%, 150%, or 200% without per-component overrides.

Rules#

• Tighten display tracking by -0.5px. Keep body tracking normal.
• Use positive tracking only for overline labels: 12 px, 600, uppercase, 0.08em.
• Use body large for standfirsts and body for sustained reading. Do not shrink prose to make a fixed box fit.
• Use at most two sizes on one slide.
• Keep system fallbacks, but never introduce a fourth brand family.
• Do not disable font-synthesis as a substitute for shipping the required files; ship the cuts the semantics require.

Usage

Clear space, minimum sizes, monochrome variants, and placing the mark on colour and photography.

Clear space#

Minimum clear space is 1× the icon height on all sides. Nothing — text, rules, image edges, other logos — enters that exclusion zone.

At a 40px mark, that is 40px of clear space in every direction. The zone scales with the mark, so it never needs recalculating per context.

Minimum sizes#

Below these sizes the petal cuts collapse into a smudge. If the space is smaller than the minimum, use a smaller variant rather than scaling one down.

Monochrome#

Four monochrome treatments are approved, for print, fax, embossing, and any single-colour reproduction:

The white-reversed variant uses slate for its inner lines rather than the background colour, so the petal structure stays visible. All petal structure must remain legible in every monochrome variant — a solid silhouette is not an approved treatment.

On colour#

The slate-5 threshold is the decision rule: measure the background, pick the side it falls on. On the accent, neither variant has enough separation on its own, which is why the ring exists.

On photography#

Never place the mark directly on an unmodified photograph. Apply a semi-transparent midnight backing — a shape, a scrim, or a gradient — so the mark sits on a controlled surface. The backing is part of the logo treatment, not an optional enhancement.

Watermark#

For background use, the mark may run as a watermark at 8–15% opacity. It renders as a uniform wash: no accent colour in watermark mode, since a single coloured element at low opacity reads as a printing error.

Favicons#

Icon-only, on a midnight tile, with 12% padding. Corner radius scales with size:

Email

A sendable message — the newsletter layout, its bulletproof button, and the constraints a signature does not have to solve.

The signature covers the block at the bottom of someone else’s message. This page covers the message itself: a full-width, sendable email with a header, sections, a call to action, and a footer.

Everything the signature page says about construction — tables, inline styles, web-safe stacks, literal hex, role="presentation" — applies here unchanged and is not repeated. What follows is what a whole message adds.

The supplied email mockup is the visual reference. Its HTML is self-contained, so it can be opened without a runtime or build step and translated into the sending tool’s template format.

Structure#

600px, centred on a neutral surround, in this order:

600px is the width every mail client can be relied on to render without horizontal scrolling, and it is the reason the message is not laid out on the 1100px measure. Below that, max-width:100% on the outer table lets the content reflow in a phone client.

Sections are numbered — 01 · agent pattern — in the accent, in the overline style. The number is the only ornament in the body: it gives a scanning reader a structure to skip through without a rule, an icon, or a background tint per section.

The preheader#

The first line of hidden text is what the inbox shows next to the subject line. It is not optional and it is not a repeat of the headline:

<div style="display:none;max-height:0;overflow:hidden;opacity:0;">
  Cloud · Agile · Agentic AI — this month: three agents worth stealing, and
  why generic SaaS is losing its edge.
</div>

Leave it out and the client fills the space with whatever text comes first, which is usually the wordmark followed by “View in browser”.

The bulletproof button#

A styled <a> is not a button in Outlook’s Word renderer: padding collapses and the fill shrinks to the text. So the call to action is built twice — a VML rectangle inside a mso conditional comment, and a table cell with bgcolor for everyone else.

<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml" href="https://…"
             style="height:44px;v-text-anchor:middle;width:220px;"
             arcsize="9%" fillcolor="#cc4528" strokecolor="#cc4528">
  <w:anchorlock/>
  <center style="color:#ffffff;font-family:Arial,sans-serif;font-size:14px;font-weight:bold;">
    Read the case study
  </center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<table role="presentation" cellpadding="0" cellspacing="0" border="0">
  <tr><td bgcolor="#cc4528" style="border-radius:6px;" align="center">
    <a href="https://…" target="_blank" style="display:block;padding:13px 26px;
       font-family:Arial,Helvetica,sans-serif;font-size:14px;font-weight:bold;
       color:#ffffff;text-decoration:none;mso-line-height-rule:exactly;">Read the case study</a>
  </td></tr>
</table>
<!--<![endif]-->

Three things are load-bearing:

• The fill is #cc4528, not #E05232. White on the identity accent is 3.87:1; on accent-solid it is 4.72:1. The same rule as solid controls in the interface, and email is where it matters most, because a mail client will not offer a hover state to compensate.
• 44px tall. A mail is read on a phone more often than not, so the touch floor is the binding constraint.
• arcsize="9%" approximates the 6px radius-md the HTML path sets. VML has no pixel radius; it takes a percentage of the shorter side.

One button per message. A second call to action does not add a second chance — it splits the first one.

Colour in a message#

The signature’s colour table holds, with two additions a whole message needs:

The accent appears as text in the overlines and as a fill on the one button — and #E05232 itself appears nowhere carrying text, in either role.

The footer is not decoration#

Commercial mail has to say who sent it, why it arrived, and how to stop it. Those three facts are the footer’s whole job:

• Who — the legal entity and its postal address.
• Why — one sentence: “Sent to you because you subscribed to Field notes.”
• How to stop — an unsubscribe link that works in one click and does not require signing in.

An unsubscribe that leads to a login screen is, in most of the jurisdictions on the signature page, not an unsubscribe.

Before sending#

• Send to Outlook (Windows), Gmail web, Apple Mail, and one mobile client. The VML path only exists for the first of those, so it only gets tested there.
• Check the preheader in the inbox list, not just in the opened message.
• Turn images off. The message must still make complete sense — which is why there are none in the layout to begin with.
• Turn dark mode on. Clients recolour aggressively; as with the signature, the hierarchy is carried by size and weight so it survives.
• Click the unsubscribe link from a logged-out browser.

Code

The default dark code surface, optional light-panel companion, and measured syntax roles.

Code blocks are dark by default#

Code blocks stay dark regardless of appearance. A code surface that flips with the theme forces the syntax palette to be designed twice and makes screenshots inconsistent between users. The surface is midnight-2 from the dark scale (#131e2b) in light, navy, and deep appearances. A deliberately light specimen may opt into the companion palette below; colour mode never switches a code block to it automatically.

The block you are reading is rendered by that rule:

// Agent pipeline definition
const pipeline = createPipeline({
  name: "validate-deploy",
  policy: "strict",
  agents: ["auditor", "deployer"],
});

Syntax theme#

For the default dark surface, every syntax value is read from the dark scale and contrast is measured against #131e2b. The optional light panel uses the separate light syntax set defined below.

Ten roles, not twenty-two tokens#

Editors do not describe code with six token types. The Language Server Protocol defines 22 semantic token types and 10 modifiers, and TextMate grammars — the model behind VS Code, Sublime Text, and most highlighters — define 11 root scopes with a deep sub-scope tree under each.

A theme should not answer that with twenty-two colours. Past roughly nine, hue stops being a signal: everything is coloured, so nothing is marked. The two scope vocabularies are therefore grouped into ten roles, and the modifiers are carried by weight and slant rather than by more hue.

Every role is an existing brand or terminal value. The expansion introduced no new colour — the terminal palette had already added the two hues, cyan and magenta, that a syntax theme needs and the three interface scales do not have.

Optional light-panel companion#

Use a light code panel only when the surrounding artifact specifically needs a light specimen. The surface is #f4f5f7; all ten roles are separately measured for a 4.5:1 floor. These tokens are companions, not mode-swapped aliases:

The base stylesheet paints every <pre> dark. Styling only a wrapper therefore leaves a dark rectangle over the intended light panel. The opt-in must neutralise the nested element explicitly:

.code--light {
  background: var(--terminal-light-surface);
  color: var(--syntax-plain-light);
}

.code--light pre {
  background: transparent;
  color: var(--syntax-plain-light);
  padding: 0;
}

Do not reuse the dark syntax values on this surface and do not make the light set the automatic counterpart of dark mode.

Modifiers are not colours#

LSP modifiers combine with any token type: ten modifiers against ten roles is a hundred states. Hue cannot carry that, so it does not try.

Why comments have a dedicated token#

Comments are the one syntax role with no scale step available to it. Steps 8–10 are border and solid-surface roles and are not held to text thresholds; step 11 is already spoken for by operators.

So code-comment (#7d90a3, 5.19:1) exists as a dedicated syntax token — the dimmest value that clears AA while staying visibly below operators. It is not a scale step and should not be treated as one.

Worked examples#

Each example below renders the same real, compilable-shaped fragment in the default dark palette and the optional light palette. The fragment is chosen to exercise as many of the ten roles as its language has. The coverage table after them records which roles each language actually reaches — several cannot reach all ten, and that is a property of the language, not a gap in the theme.

C#

/* Ring buffer — fixed capacity, no allocation after init. */
#include <stdint.h>
#define RING_CAP 256          // macro: a decorator-role token

typedef enum { RING_OK = 0, RING_FULL = 1 } ring_status_t;

typedef struct {
    uint8_t  data[RING_CAP];
    size_t   head, tail;
    _Bool    wrapped;
} ring_t;

static inline size_t ring_len(const ring_t *r) {
    return (r->head - r->tail) & (RING_CAP - 1);
}

static const char *RING_TAG = "ring\n";   // string literal

ring_status_t ring_push(ring_t *restrict r, uint8_t byte) {
    // Reject when one slot short of capacity, so head never meets tail.
    if (ring_len(r) == RING_CAP - 1) return RING_FULL;
    r->data[r->head++ & (RING_CAP - 1)] = byte;
    return RING_OK;
}

/* Ring buffer — fixed capacity, no allocation after init. */
#include <stdint.h>
#define RING_CAP 256          // macro: a decorator-role token

typedef enum { RING_OK = 0, RING_FULL = 1 } ring_status_t;

typedef struct {
    uint8_t  data[RING_CAP];
    size_t   head, tail;
    _Bool    wrapped;
} ring_t;

static inline size_t ring_len(const ring_t *r) {
    return (r->head - r->tail) & (RING_CAP - 1);
}

static const char *RING_TAG = "ring\n";   // string literal

ring_status_t ring_push(ring_t *restrict r, uint8_t byte) {
    // Reject when one slot short of capacity, so head never meets tail.
    if (ring_len(r) == RING_CAP - 1) return RING_FULL;
    r->data[r->head++ & (RING_CAP - 1)] = byte;
    return RING_OK;
}

C++#

// Policy-based cache. Types, templates, and a lambda.
#include <string>
#include <unordered_map>

namespace projectious::cache {

template <typename Key, typename Value>
class LruCache final {
public:
    explicit LruCache(std::size_t capacity) noexcept : capacity_{capacity} {}

    [[nodiscard]] auto get(const Key& key) const -> const Value* {
        const auto it = entries_.find(key);
        return it == entries_.end() ? nullptr : &it->second;
    }

    void put(Key key, Value value) {
        static constexpr auto kTag = "lru";  // string literal
        // Evict before insert so size never exceeds the capacity.
        if (entries_.size() >= capacity_) evict();
        entries_.emplace(std::move(key), std::move(value));
    }

private:
    void evict() noexcept { /* … */ }

    std::size_t capacity_{0};
    std::unordered_map<Key, Value> entries_{};
};

}  // namespace projectious::cache

// Policy-based cache. Types, templates, and a lambda.
#include <string>
#include <unordered_map>

namespace projectious::cache {

template <typename Key, typename Value>
class LruCache final {
public:
    explicit LruCache(std::size_t capacity) noexcept : capacity_{capacity} {}

    [[nodiscard]] auto get(const Key& key) const -> const Value* {
        const auto it = entries_.find(key);
        return it == entries_.end() ? nullptr : &it->second;
    }

    void put(Key key, Value value) {
        static constexpr auto kTag = "lru";  // string literal
        // Evict before insert so size never exceeds the capacity.
        if (entries_.size() >= capacity_) evict();
        entries_.emplace(std::move(key), std::move(value));
    }

private:
    void evict() noexcept { /* … */ }

    std::size_t capacity_{0};
    std::unordered_map<Key, Value> entries_{};
};

}  // namespace projectious::cache