Overview

Radarist design system

A source-based reference for building an agenda-centered planning product: foundations, reusable interfaces, interaction rules, and complete examples.

On this page

Foundations8 entries Components27 entries Patterns11 entries Applied screens7 entries Accessibility and content3 entries Implementation and maintenance5 entries

What this system supports

Radarist brings projects, next actions, and the time reserved for them into a daily agenda. Its interface must let people distinguish the work, understand the day, and make a small change without losing the surrounding context.

This pilot documents the local Radarist v3 implementation and adds explicit usage guidance around it. It is a retrospective reference, not evidence that a standalone design-system team or published component library previously existed.

System at a glance

System at a glance
Area	Current scope
Product status	Work in Progress
Source baseline	0103e2549959456c1e88b064697aa3c56261ecf9
Foundations	39 source CSS variables; explicit light and dark modes; system font stack
Implementation	Next.js, React, TypeScript, Tailwind CSS; planning components with server-action and API boundaries
Evidence	Actual repo components rendered in an isolated local snapshot with fictional records
Readiness	Documented implementation with measured findings and known gaps; no blanket accessibility or production-readiness claim

Design principles inferred from the implementation

Connect direction to time: keep a project’s next action visible inside the block of time allocated to it.
Preserve context: carry the same project identity across cards, agendas, detail views, and links.
Differentiate commitment: planned work, events, and time away have distinct structures and content.
Keep history legible: past days can be inspected while editing and task completion are locked.
Favor recovery: removing a block offers an Undo action rather than a silent permanent loss.

A useful first task

To add a project experience, begin with the semantic palette and layout rules. Use ProjectCard for the project overview, ProjectIdentityEditor for the title and appearance, TaskCheckbox for next actions, and the existing section navigation for supporting resources. Reserve time through RadarCalendar rather than constructing an unrelated calendar interaction.

How to read the evidence

Source references identify the exact files audited. Usage recommendations explain how a team should apply those implementations.
Component specimens arrange actual imported components with fixture props. Applied captures compose the actual project components in a local fixture harness. They are not redesigned approximations.
Settings forms can show local success feedback without persisting a real preference. A pictured state is not proof of a working backend.
Each known gap remains visible in the component or workflow it affects and in the readiness register.

Start here

Foundations explain the common visual decisions. Components explain individual contracts and states. Patterns explain complete tasks. Applied screens connect those parts back to the user experience. Implementation explains how to repeat the audit and captures without touching live data.