Introduction

Every SignalOS client deployment needs its own customization - branding, extra columns, different workflows. A compiled npm package fights that: you end up wrapping components or forking the package. The pull model embraces it. You pull source, you own source. Customize freely; the registry tracks what you took and tells you when upstream moved.

npx shadcn@latest add @signalos/data-table   # source lands in YOUR app
npx signalos diff                            # has upstream changed? did we?
npx signalos update data-table               # take the new version, reviewed

Three tiers, each built on the one below - currently 34 components and 28 pages:

• Foundation - the design tokens (one CSS file: OKLCH colors, light/dark themes, Tailwind mapping) and curated shadcn primitives (button, input, select, …). Pulled automatically as dependencies; you never request them directly.
• Components - generic widgets: data tables, KPI tiles, charts, filter bars, app shell. Props in, events out; no fetching, no global state, no client names. Each owns its loading, empty, and error states.
• Pages - full screens composed from the widgets (login variants, dashboards, connectors, settings). Pull one, mount it in a route, wire your data.

Everything you can see on this site is public: live previews, props APIs, example code, markdown docs. The component source is gated - pulling requires a GitHub token that only members of the widget-consumers team can hold. Revoking team membership kills access instantly.