@incodetech/prizma-core-screens

SDK module screens — composed, responsive, brand-themeable React screens (Face Capture, ID Capture, Phone Input, …) built entirely from @incodetech/prizma-core-web components and @incodetech/prizma-core-tokens.

This package is the pattern/product tier of Prizma Core: screens are web-only compositions and deliberately do NOT enter the three-platform parity regime that governs prizma-core-web components.

What a screen is

• A pure, stateless React component: ({ strings, overrides?, onAction? }) => JSX.
• Copy always arrives via strings props — nothing hardcoded (i18n-ready).
• Styled with plain CSS bound to --prizma-* token variables; zero !important.
• Brand-reactive through applyPrizmaTheme({ seed }) from prizma-core-web — no bespoke theming layer.
• Dark mode via [data-prizma-theme='dark'], same as every Core component.
• Sizing: screens are authored at the 390×844 design reference and the HOST scales them to fit its container (transform: scale()), the way Studio's device frames and the hub's preview cards already work. Height is fluid and width grows/re-centers above 390, but layout never reflows below it — Core's fixed-width PrizmaTag (340) and PrizmaSelfieCapture (335) make ~388px a hard floor, and scaling means nothing ever clips. Owner decision 2026-08-17 (DEVIATIONS.md #17). Do NOT add fixed-width breakpoint variants of a screen.
• All visual assets (rings, silhouettes, frames) are inline SVG components — vector, tintable, no host-app public/ dependencies.

Structure

src/ is flat — scripts/exports-map.mjs globs top-level src/*.tsx and src/*.css to generate the package's exports map and aggregate stylesheet, so subfolders would be published as nothing. Files group by name prefix instead:

src/
  ScreenShell/ScreenNav + the archetype *Screen.tsx templates
                    the foundation: shell, nav, CTA/footer spacing, vignette
  ScreenLayout.css  THE archetype spacing layer (§5) — nothing else declares it
  <Module><X>Screen.tsx     one file per module screen, flat PascalCase
  <Module>Strings.ts        the module's copy contract (props, no English)
  <Module>Layout.css        module-only layout additions, if any
  flows.ts          per-module screen sequences (powers the FlowPlayer prototypes)
GUIDELINES.md       the compiled screen-construction rulebook (from Incode Studio)
DEVIATIONS.md       every guidelines-vs-design-system conflict and its resolution
FIGMA-SOURCES.md    the authoritative design file per SDK module

Rules for adding screens

1. Compose ONLY from src/foundation/ templates + prizma-core-web components
   • prizma-core-icons. Never invent a new primitive in a module folder.
2. Every capture screen composes Core's capture components — PrizmaSelfieCapture, or PrizmaIdCapture (mode="overlay", scrim) inside a dark ScreenShell. NEVER re-create a window, scrim, overlay geometry or encrypted row. The local CaptureOverlay / ViewfinderScreen are deprecated re-implementations kept only until the wave completes (DEVIATIONS #F-26).
3. Spacing/typography come from the archetype templates, never re-declared.
4. Where GUIDELINES.md and the Prizma design system disagree, the design system wins — and the conflict is logged in DEVIATIONS.md. Never silently.
5. Build only the screens inside the purple parent section of the module's Figma file.

Build

npm run build = tsc → dist/ + CSS/asset copy + exports-map & aggregate drift checks (same contract as prizma-core-web). Consumers import tokens once (@incodetech/prizma-core-tokens/css), then styles.css or per-screen sheets.

The build also stamps 'use client' onto every src/*.tsx-derived module in dist/, so screens import straight into a Next App Router page. flows.ts, types.ts and the *Strings.ts deliberately do NOT get it — they are data, and the build fails if one of them ends up carrying it. See prizma-core-web's README § React Server Components.