@incodetech/prizma-core-screens 0.1.0

package/dist/ScreenLayout.css

@@ -0,0 +1,469 @@
+/* ScreenLayout — THE archetype spacing layer (GUIDELINES.md §5, §6).
+ *
+ * Every spacing rule of the screen system lives HERE and only here; archetype
+ * and module screens compose these classes and never re-declare the values.
+ * Values are tokens; the recipes below were corrected against the Face Capture
+ * purple sections in the pilot (DEVIATIONS.md #8, #12) — the two rules that
+ * double-counted padding Core components already carry are gone.
+ */
+
+/* Content column: 24px horizontal padding, fills the shell. */
+/* The footer's total footprint: bottom offset + tag height + gap above it.
+ * Derived from the real Core token, so a tag resize propagates. */
+.prizma-screen-shell {
+  --pcs-footer-space: calc(
+    var(--prizma-spacing-16) + var(--prizma-tag-size-height) + var(--prizma-spacing-16)
+  );
+  /* Capture screens also carry the anchored control strip (shutter + help)
+   * between the frame and the footer. Reserving its footprint is what lets
+   * Core's capture frame — which FILLS whatever box the host gives it — shrink
+   * to fit instead of running under the controls. Owner: the frame may get
+   * smaller, that is not a constraint (2026-08-18).
+   * = footer space + the strip's own 8 offset + the 64 strip + 12 breathing. */
+  --pcs-capture-chrome-space: calc(
+    var(--pcs-footer-space) + var(--prizma-spacing-8) + var(--prizma-icon-size-3xl) +
+      var(--prizma-spacing-12)
+  );
+}
+
+.prizma-screen-layout__content {
+  display: flex;
+  flex-direction: column;
+  flex: 1;
+  min-height: 0;
+  padding-inline: var(--prizma-spacing-24);
+  padding-top: var(--prizma-spacing-24); /* nav → first content block */
+  /* Must be allowed to shrink: a taller stage (vertical ID / passport) used to
+   * overflow the fixed-height shell and push the anchored chrome out of view. */
+  min-height: 0;
+}
+
+/* Capture screens: the ring offset is NOT applied here. Core's capture
+ * components (PrizmaSelfieCapture / PrizmaIdCapture) carry the designed
+ * `padding: 40px 0` + `gap: 32` in their own root, pixel-exact against every
+ * module Figma file — the capture instance sits at nav-bottom + 0. Adding
+ * GUIDELINES §5's 40px on top pushed the ring 80px down. DEVIATIONS.md #12. */
+.prizma-screen-layout__content--capture {
+  padding-top: 0;
+}
+
+/* Screens with no logo nav (every module's `genericErrors` family — the nav and
+ * the verified tag are both absent there, so GUIDELINES §1's "tag is always the
+ * last child" does not hold). The status-bar reserve normally rides on
+ * `.prizma-screen-nav`; with no nav the content column carries it, via the same
+ * custom property so a host that draws its own chrome still overrides it once.
+ * DEVIATIONS.md #9. */
+.prizma-screen-layout__content--no-nav {
+  padding-top: calc(var(--pcs-status-bar, 47px) + var(--prizma-spacing-24));
+}
+
+/* ── Progress slot (archetype E) ─────────────────────────────────────────────
+ * The journey bar a form module draws between the logo nav and the title block.
+ * eKYC is the first consumer: all six of its form frames put a two-segment Core
+ * `PrizmaStepper` across the full content width there (page 1 blue + grey —
+ * 2101:7877 / 2101:8159 / 5849:60225; page 2 pale + blue — 5849:51109 /
+ * 5849:66890; page 2 loading both green — 5849:71925).
+ *
+ * Figma measures nav bottom → bar = Spacing/16 and bar → Title block =
+ * Spacing/24, so the column's own "nav → first content block" 24 is retuned to
+ * the 16 for the one column that actually carries a bar. BOTH offsets live here
+ * and nowhere else — a module never re-declares them (GUIDELINES §5), and the
+ * slot renders nothing when unused, so every existing screen is untouched.
+ * DEVIATIONS #EK-1. */
+.prizma-screen-layout__content:has(> .prizma-screen-layout__progress) {
+  padding-top: var(--prizma-spacing-16);
+}
+
+.prizma-screen-layout__progress {
+  flex-shrink: 0;
+  margin-bottom: var(--prizma-spacing-24); /* bar → title block */
+}
+
+/* THE GUTTER, for the archetypes that hang the slot off the SHELL.
+ *
+ * Only archetype E puts `progress` inside `.prizma-screen-layout__content`,
+ * which already carries the column's 24px `padding-inline`. C, F, G, A and H
+ * render it as a sibling of the content column instead, so anything in the slot
+ * ran full-bleed — edge to edge across the phone, ignoring the 24px gutter every
+ * other block on the screen respects. Camila caught it on the Error screens'
+ * "link copied" Snackbar (2026-09-03); Video Selfie's stepper has the same shape
+ * on the same five archetypes.
+ *
+ * Scoped to the DIRECT CHILD of the shell so archetype E is untouched — inside
+ * the content column the padding is already there, and adding it here would
+ * double it to 48. One rule, one place; no archetype re-declares the value
+ * (GUIDELINES §5). */
+.prizma-screen-shell > .prizma-screen-layout__progress {
+  padding-inline: var(--prizma-spacing-24);
+}
+
+/* Processing/result screens: fully centered column. */
+.prizma-screen-layout__content--centered {
+  align-items: center;
+  justify-content: center;
+  gap: var(--prizma-spacing-16);
+}
+
+/* The flexible middle (tutorial illustration area, form field stack). */
+.prizma-screen-layout__flex {
+  flex: 1;
+  min-height: 0;
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+}
+
+/* ── List archetype middle (archetype G) ─────────────────────────────────────
+ * A Core card/option list filling the space between the title block and the CTA
+ * band. NOT `__flex`, which centres AND shrink-wraps its child — that slot is
+ * for a centred illustration; a list must span the column and start at the top.
+ *
+ * The Spacing/24 is GUIDELINES §5's "title block → first content block", and it
+ * lives here so the eight screens that hand-built this pattern stop each
+ * declaring their own (they had 24 on the three ID screens and 32 on Document
+ * Capture's — DEVIATIONS #F-31). */
+.prizma-screen-layout__list {
+  flex: 1;
+  min-height: 0;
+  display: flex;
+  flex-direction: column;
+  padding-top: var(--prizma-spacing-24);
+}
+
+/* Bottom-anchored variant: `1-1-1-Document Chooser V2` hangs its option rows off
+ * the bottom of the middle instead of the top. */
+.prizma-screen-layout__list--end {
+  justify-content: flex-end;
+}
+
+/* Scrolling variant — the same release archetype E has as `scrollFields`.
+ * Video Selfie's Android settings walk-through draws TWO five-step lists plus a
+ * closing note; Figma gives that frame 1041px, and squeezed into the 844 shell
+ * the second list painted straight through the CTA and the anchored tag, with
+ * the last line clipped (owner QA 2026-08-19, measured ~57px of overlap).
+ * Letting the middle pan keeps the title, the CTA band and the tag still.
+ * Rows keep their intrinsic height for the same reason as #QS-1. */
+.prizma-screen-layout__list--scroll {
+  overflow-y: auto;
+  margin-bottom: var(--prizma-spacing-16);
+}
+
+.prizma-screen-layout__list--scroll > * {
+  flex-shrink: 0;
+}
+
+/* ── Review archetype middle (archetype H) ───────────────────────────────────
+ * The captured-media review pattern (GUIDELINES.md §6-H): a header block over a
+ * flexing media stage. Promoted here from the two Document Capture confirm
+ * screens, which hand-built these three offsets in `DocumentCaptureLayout.css`
+ * (`.document-capture-confirm-header`, `.document-capture-stage`,
+ * `.document-capture-band--offset`) — Wave 2, now the foundation's so every
+ * module's review screen stops re-declaring them (DEVIATIONS #REV-1).
+ *
+ * Header → media stage is Spacing/32 (Figma draws 32 on reviewPhoto / reviewFile
+ * / analyzing; the hand-nudged 24–40 on the other sections is Figma rounding —
+ * DEVIATIONS #DC-24). The header holds the Title OR, on `analyzing`, the loading
+ * bar; either way the gap below it is the same. */
+.prizma-screen-layout__review-header {
+  flex-shrink: 0;
+  margin-bottom: var(--prizma-spacing-32);
+}
+
+/* The media stage: a centred column that flexes into whatever the header
+ * leaves, so the captured still / file card sits in the middle at every screen
+ * height. Its own child gap is Spacing/16 (the file card → encrypted-notice gap
+ * on the upload variant; a no-op when the media is a single child). */
+.prizma-screen-layout__review-stage {
+  flex: 1 1 auto;
+  min-height: 0;
+  box-sizing: border-box;
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+  gap: var(--prizma-spacing-16);
+  width: 100%;
+}
+
+/* `analyzing` has no CTA band, so nothing supplies the Spacing/24 the band
+ * normally puts between the stage and the screen bottom — the stage carries it
+ * itself (Figma: the column ends at 630 of a 654 CONTENT frame). */
+.prizma-screen-layout__review-stage--flush {
+  margin-bottom: var(--prizma-spacing-24);
+}
+
+/* The `analyzing` loading bar is centred and capped at Figma's 164px instance
+ * width; Core's `PrizmaLoadingBar` is `width: 100%` and takes its cap from the
+ * host. 164 is absent from the spacing SOT — a documented literal, the same
+ * class as the file-card thumbnail (DEVIATIONS #DC-28, #REV-1). */
+.prizma-screen-layout__review-loading {
+  width: 164px; /* hardcoded — Figma Loading bar instance width; absent from the token SOT (DEVIATIONS #DC-28) */
+  max-width: 100%;
+  margin-inline: auto;
+}
+
+/* ── Non-status glyph slot ───────────────────────────────────────────────────
+ * Figma swaps arbitrary glyphs into the Title's icon slot (`Icon / Wi-Fi` on
+ * every module's noConnection, a question mark on ID Capture's common issues).
+ * Core's `PrizmaTitle.icon` allowlist is `status | spinner | none`
+ * (title.md §2.3), so the glyph is composed ABOVE the Title using the very same
+ * Title/Icon/Size the component applies to its own slot — icon from the
+ * canonical bank, no primitive invented. DEVIATIONS #10.
+ *
+ * Promoted here from three byte-identical module copies
+ * (`.face-capture-glyph`, `.id-capture-glyph`, `.document-capture-glyph`) —
+ * DEVIATIONS #DC-29 asked for exactly this. */
+.prizma-screen-layout__glyph {
+  display: flex;
+  width: 100%;
+  justify-content: center;
+}
+
+/* Mirrors `.prizma-title--left .prizma-title__icon-slot` so the glyph follows
+ * the same alignment override as the Title it belongs to. */
+.prizma-screen-layout__glyph--left {
+  justify-content: flex-start;
+}
+
+.prizma-screen-layout__glyph > svg {
+  display: block;
+  width: var(--prizma-title-icon-size);
+  height: var(--prizma-title-icon-size);
+}
+
+/* Ink: the two tones Figma uses for non-status glyphs. */
+.prizma-screen-layout__glyph--negative {
+  color: var(--prizma-icon-status-negative);
+}
+
+.prizma-screen-layout__glyph--neutral {
+  color: var(--prizma-icon-neutral-800);
+}
+
+/* The glyph → Title gap is Core's own Title/Icon → heading Spacing/16. On the
+ * centered column the flex `gap` already supplies it, so the margin is scoped to
+ * the plain column — one value, declared once, never in a module file. */
+.prizma-screen-layout__content:not(.prizma-screen-layout__content--centered)
+  > .prizma-screen-layout__glyph {
+  margin-bottom: var(--prizma-spacing-16);
+}
+
+/* Instruction text 32px below a bare capture stage. NOT for Core's capture
+ * components — they render their own instruction line (H4) at the designed
+ * offset via `feedbackText`. Use this only for a custom stage that carries no
+ * gap of its own. DEVIATIONS.md #12, #14. */
+.prizma-screen-layout__below-capture {
+  padding-top: var(--prizma-spacing-32);
+}
+
+/* ── CTA band ────────────────────────────────────────────────────────────────
+ * Core's own composition recipe (documented in prizma-core-web
+ * `Disclaimer.tsx`): disclaimer + button + tag stacked at a flat Spacing/16.
+ * Because `PrizmaDisclaimer` carries its own Spacing/12, that yields exactly
+ * the 28px disclaimer-text → CTA gap GUIDELINES §5 asks for — with no literal.
+ * The old `__disclaimer { padding-bottom: 28px }` double-counted it (40px).
+ * DEVIATIONS.md #8 (supersedes #5). */
+.prizma-screen-layout__band {
+  flex-shrink: 0;
+  display: flex;
+  flex-direction: column;
+  gap: var(--prizma-spacing-16);
+  /* No bottom padding: the anchored footer reserves its own space through
+   * `--pcs-footer-space` on the content column. */
+}
+
+.prizma-screen-layout__band .prizma-button {
+  width: 100%;
+}
+
+/* A band rendered as a direct shell child (ResultScreen) rather than inside the
+ * content column: it supplies its own gutters and clears the anchored footer. */
+/* CTA pair inside a band. `--row` pairs them side by side at the band's own
+ * Spacing/16 gap — ID Capture's review screen (Retake | Continue). Stacked is
+ * the default, so nothing else changes. */
+.prizma-screen-layout__band__ctas {
+  display: flex;
+  flex-direction: column;
+  gap: var(--prizma-spacing-16);
+}
+
+.prizma-screen-layout__band__ctas--row {
+  flex-direction: row;
+}
+
+.prizma-screen-layout__band__ctas--row .prizma-button {
+  flex: 1 1 0;
+  min-width: 0;
+}
+
+/* Band content above the buttons (Face Match's verdict Snackbar). The band's
+ * flat Spacing/16 plus this row's own 16 reaches the designed 32 to the CTA —
+ * the same idiom as the Disclaimer's 12 + 16 = 28 (DEVIATIONS #8, #FM-23). */
+.prizma-screen-layout__band__content {
+  display: flex;
+  justify-content: center;
+  padding-bottom: var(--prizma-spacing-16);
+}
+
+.prizma-screen-layout__band--result {
+  padding-inline: var(--prizma-spacing-24);
+  margin-bottom: var(--pcs-footer-space);
+}
+
+/* Review archetype (H): the stage flexes, so the Spacing/24 between it and the
+ * CTA row rides on the band as a top margin (Figma: the media `Container` ends
+ * at 550, the `bottom container` starts at 574). The band sits INSIDE the
+ * content column, which already carries the 24 gutters and reserves the footer
+ * via `--pcs-footer-space` — so unlike `--result` this variant adds only the
+ * top offset. Promoted from `.document-capture-band--offset` (DEVIATIONS #REV-1). */
+.prizma-screen-layout__band--review {
+  margin-top: var(--prizma-spacing-24);
+}
+
+/* Retained for screens that genuinely carry no tag; the anchored footer
+ * otherwise reserves the bottom space. */
+.prizma-screen-layout__band--bare {
+  padding-bottom: var(--prizma-spacing-24);
+}
+
+/* Full-width CTA row — for screens whose CTA is not part of a band. */
+.prizma-screen-layout__cta {
+  flex-shrink: 0;
+}
+.prizma-screen-layout__cta .prizma-button {
+  width: 100%;
+}
+
+/* ── Inline prompt with links ────────────────────────────────────────────────
+ * A line of body copy carrying one or more INLINE links — Phone Input's
+ * "Didn't receive the code? Resend code or Change phone number", and the same
+ * shape every other OTP-bearing module draws (Email Input, eKYC…).
+ *
+ * Core has no inline-link primitive: `PrizmaButton variant="tertiary-link"` is
+ * the right INK (underlined, `button/tertiary/text/default`) but size L is
+ * `width: 100%; min-height: 56px`, so it cannot sit inside a sentence. The
+ * recipe therefore lives here — built from Core's OWN tokens, inventing no
+ * palette — and is placed in the foundation rather than a module file because
+ * it is a cross-module pattern (DEVIATIONS #PI-10, #DC-29 precedent).
+ */
+.prizma-screen-layout__inline-prompt {
+  margin: 0;
+  text-align: center;
+  text-wrap: balance;
+  color: var(--prizma-text-body-500-secondary);
+  font-family: var(--prizma-body-family);
+  font-size: var(--prizma-body-m-regular-font-size);
+  font-weight: var(--prizma-body-m-regular-font-weight);
+  line-height: var(--prizma-body-m-regular-line-height);
+  letter-spacing: var(--prizma-body-m-regular-letter-spacing);
+}
+
+/* The link itself: a real <button> for semantics and keyboard support, drawn
+ * with the tertiary-link ink so it is visually identical to Core's link. */
+.prizma-screen-layout__inline-link {
+  display: inline;
+  margin: 0;
+  padding: 0;
+  border: none;
+  background: none;
+  cursor: pointer;
+  font: inherit;
+  color: var(--prizma-button-tertiary-text-default);
+  text-decoration: underline;
+}
+
+/* Core's tertiary-link drops the underline on hover; mirrored so the two
+ * behave identically. */
+.prizma-screen-layout__inline-link:hover {
+  text-decoration: none;
+}
+
+/* ── Footer (verified-by tag) ─────────────────────────────────────────────────
+ * ANCHORED to the shell, not flowed after the content. The owner's rule is
+ * absolute: where a tag exists it sits at exactly the same position on every
+ * screen — never higher, never lower (2026-08-18).
+ *
+ * Flowing it made the position depend on whatever came before: a band with its
+ * own padding gave 16, a bare content column gave 0, and the taller vertical-ID
+ * stage overflowed the shell and pushed the tag 62px BELOW the fold, where
+ * `overflow: hidden` ate it. Anchoring removes the whole class of bug.
+ *
+ * Screens reserve the footprint via `--pcs-footer-space` (derived from the real
+ * tag height token) so content can never sit under the tag. */
+.prizma-screen-layout__footer,
+.prizma-screen-layout__band__tag {
+  position: absolute;
+  left: 0;
+  right: 0;
+  bottom: var(--prizma-spacing-16);
+  display: flex;
+  justify-content: center;
+}
+
+/* Kept as a no-op alias: the anchor makes "pinned" the only behaviour. */
+.prizma-screen-layout__footer--pinned {
+  margin-top: 0;
+}
+
+/* Any screen carrying a footer reserves its space: 16 bottom + tag + 16 gap. */
+.prizma-screen-shell:has(.prizma-screen-layout__footer) .prizma-screen-layout__content,
+.prizma-screen-shell:has(.prizma-screen-layout__band__tag) .prizma-screen-layout__content {
+  padding-bottom: var(--pcs-footer-space);
+}
+
+/* …and capture screens reserve the strip on top of it, so the frame stops above
+ * the shutter/help row rather than sliding under it. */
+.prizma-screen-shell:has(.prizma-screen-layout__capture-strip) .prizma-screen-layout__content {
+  padding-bottom: var(--pcs-capture-chrome-space);
+}
+
+/* Camera screens built on the viewfinder surface (ID / Document stages) reserve
+ * the same chrome footprint on their content column. Without it, Core's poa
+ * frame — which has NO aspect lock and FILLS its box — grows to the full shell
+ * height and runs under the shutter/help strip (owner report 2026-08-18). The
+ * frame now fills only down to above the strip; aspect-locked ID frames are
+ * unaffected (they were already smaller than the space). */
+.prizma-screen-shell:has(.prizma-screen-layout__capture-strip) .prizma-viewfinder__content {
+  padding-bottom: var(--pcs-capture-chrome-space);
+}
+
+/* ── Capture control strip (shutter + help) ──────────────────────────────────
+ * ANCHORED like the footer. The strip used to sit in the content flow, so the
+ * help affordance moved with whatever was above it: 28px off the bottom on the
+ * landscape ID stages, 11px on the taller vertical-ID frame, 66px on Document
+ * Capture. The owner's rule is that it does not move with frame orientation
+ * (2026-08-18), so it is pinned once, above the footer's reserved space.
+ *
+ * Core ships `PrizmaCaptureManual` at a fixed 352 width, which overhangs the
+ * 342 content column and pushed the help icon 5px inside the 24 gutter on
+ * Document Capture. Constrained here to the column it is given — the Core-side
+ * request is logged (DEVIATIONS #DC-33). */
+.prizma-screen-shell .prizma-screen-layout__capture-strip {
+  position: absolute;
+  left: var(--prizma-spacing-24);
+  right: var(--prizma-spacing-24);
+  bottom: calc(var(--pcs-footer-space) + var(--prizma-spacing-8));
+  display: flex;
+  justify-content: center;
+}
+
+.prizma-screen-shell .prizma-screen-layout__capture-strip > .prizma-capture-manual {
+  width: 100%;
+  max-width: 100%;
+}
+
+/* ── Anchored-chrome layering ─────────────────────────────────────────────────
+ * The camera HUD bands lift themselves to `z-index: 1` so their copy paints
+ * above `PrizmaIdCapture`'s scrim (an absolutely positioned box-shadow that
+ * escapes the frame by design). The anchored chrome — verified-by tag, shutter
+ * and help affordance — must sit ABOVE that layer, or the band covers it: the
+ * owner reported the tag and help button hidden behind the overlay
+ * (2026-08-18). One step higher is enough; keep it here so module bands and the
+ * chrome are ordered in a single place. */
+.prizma-screen-shell .prizma-screen-layout__footer,
+.prizma-screen-shell .prizma-screen-layout__band__tag,
+.prizma-screen-shell .prizma-screen-layout__capture-strip {
+  z-index: 2;
+}
+

package/dist/ScreenNav.css

@@ -0,0 +1,43 @@
+/* ScreenNav — logo header (GUIDELINES.md §3).
+ *
+ * The 390×844 design reference includes the OS status-bar area at the top of
+ * the screen; standalone hosts (hub frames, previews) have no device chrome,
+ * so the nav reserves that offset itself: `--pcs-status-bar` (default 47px —
+ * the reference status-bar height; hardcoded, no Core token). Hosts that DO
+ * own the chrome (a real phone viewport, a device frame that draws the status
+ * bar) set `--pcs-status-bar: 0px` — or `env(safe-area-inset-top)` on device.
+ * Below the offset: 12px gap, then the 44px nav row (GUIDELINES §3, §5).
+ *
+ * Core's PrizmaNavigation positions itself `fixed` (viewport-pinned on a real
+ * SDK page). Inside a composed screen the nav must occupy real flow space —
+ * the title block sits 24px below it — so the wrapper provides the 44px flow
+ * slot and the inner nav is made static within it.
+ */
+
+.prizma-screen-nav {
+  flex-shrink: 0;
+  margin-top: calc(var(--pcs-status-bar, 47px) + var(--prizma-spacing-12));
+  height: 44px; /* hardcoded — Studio nav row height (GUIDELINES §3); no Core token */
+  display: flex;
+  align-items: center;
+  justify-content: center;
+}
+
+.prizma-screen-nav .prizma-nav {
+  position: static;
+  width: 100%;
+}
+
+.prizma-screen-nav__custom-logo {
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  height: 100%;
+}
+
+.prizma-screen-nav__custom-logo > img,
+.prizma-screen-nav__custom-logo > svg {
+  max-height: 24px;
+  max-width: 120px;
+  object-fit: contain;
+}

package/dist/ScreenNav.d.ts

@@ -0,0 +1,26 @@
+import React, { type ComponentPropsWithoutRef, type ReactNode } from 'react';
+import './ScreenNav.css';
+export interface PrizmaScreenNavProps extends ComponentPropsWithoutRef<'header'> {
+    /** Custom brand logo (e.g. an <img> of the client logo). Rendered centered,
+     *  contained to the logo box (GUIDELINES.md §3: height 24 / max-width 120 /
+     *  object-fit contain — enforced by CSS). Default: the Incode wordmark via
+     *  PrizmaNavigation. */
+    logo?: ReactNode;
+    /** Accessible name for the nav region (i18n — no baked-in English). */
+    navLabel?: string;
+    /**
+     * Render the nav's BOX but not its contents. The header is hidden on capture
+     * screens, and removing it outright would pull every element up — the owner's
+     * requirement is that spacing stays identical whether or not the logo shows
+     * (2026-08-18). So the 44px row and its status-bar offset are still reserved;
+     * only the logo disappears, and the row leaves the a11y tree.
+     */
+    reserved?: boolean;
+}
+/**
+ * ScreenNav — the logo header of every SDK screen.
+ * Sits 12px below the top of the shell (the host frame owns the OS status
+ * bar), logo centered, no back/close buttons (GUIDELINES.md §3).
+ */
+export declare const PrizmaScreenNav: React.ForwardRefExoticComponent<PrizmaScreenNavProps & React.RefAttributes<HTMLElement>>;
+export default PrizmaScreenNav;

package/dist/ScreenNav.js

@@ -0,0 +1,13 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaNavigation } from '@incodetech/prizma-core-web/navigation';
+import './ScreenNav.css';
+/**
+ * ScreenNav — the logo header of every SDK screen.
+ * Sits 12px below the top of the shell (the host frame owns the OS status
+ * bar), logo centered, no back/close buttons (GUIDELINES.md §3).
+ */
+export const PrizmaScreenNav = forwardRef(({ logo, navLabel, reserved = false, className, ...rest }, ref) => (_jsx("header", { ref: ref, "aria-hidden": reserved || undefined, className: ['prizma-screen-nav', className ?? ''].filter(Boolean).join(' '), ...rest, children: reserved ? null : logo ? (_jsx("span", { className: "prizma-screen-nav__custom-logo", children: logo })) : (_jsx(PrizmaNavigation, { showIncodeLogo: true, "aria-label": navLabel })) })));
+PrizmaScreenNav.displayName = 'PrizmaScreenNav';
+export default PrizmaScreenNav;

package/dist/ScreenShell.css

@@ -0,0 +1,130 @@
+/* ScreenShell — root of every SDK screen.
+ *
+ * Tokens only (no :root block here — the consumer imports
+ * @incodetech/prizma-core-tokens/css once). Design reference 390×844; the
+ * shell fills whatever box the host gives it and exposes a size container so
+ * descendants scale with `cqw` capped at reference pixels.
+ */
+
+.prizma-screen-shell {
+  display: flex;
+  flex-direction: column;
+  position: relative;
+  width: 100%;
+  height: 100%;
+  overflow: hidden;
+  background: var(--prizma-surface-neutral-0);
+  font-family: var(--prizma-body-family);
+  color: var(--prizma-text-body-800-primary);
+  container-type: size;
+  container-name: pcs-screen;
+  /* The shell must be the containing block for `position: fixed` descendants —
+   * Core's PrizmaNavigation pins itself to the viewport (correct on a real
+   * device, wrong inside an embedded screen frame) — and must clip descendant
+   * painting (the CaptureOverlay scrim is a 2000px box-shadow). `contain:
+   * layout paint` does both without forcing a composited layer the way
+   * `transform` would. */
+  contain: layout paint;
+}
+
+/* Camera viewfinder screens — always a dark stage regardless of theme.
+ * The camera surface itself is supplied by the screen (image or live feed). */
+.prizma-screen-shell--dark {
+  background: var(--prizma-surface-neutral-900-static);
+  color: var(--prizma-text-body-0-static);
+}
+
+/* -------------------------------------------------------------------------
+   A theme PIN is a MODE pin, not a BRAND reset.
+
+   The finding (Core Lab explorations canvas, 2026-08-31). Two cards, same
+   `themeSeed` #7C3AED: `face-capture-tutorial` went fully purple, but on
+   `face-capture-capturing-alignFace` the footer tag — the brand badge and the
+   Incode wordmark — stayed #0054FF. Nothing in Tag or Logo is hardcoded: Tag
+   binds Icon/Brand/500 Static, Logo binds Surface/Brand/500, and both DID
+   re-skin on the tutorial. What differs is the pin.
+
+   A scoped brand (Core Lab's per-card seed, and equally a host that scopes
+   `applyPrizmaTheme`'s output to a subtree instead of `:root`) is delivered as
+   inherited CSS custom properties on an ANCESTOR. `theme` above stamps
+   `data-prizma-theme` on THIS element — and `@incodetech/prizma-core-tokens/
+   themes/light.css` is the FULL token set, not a delta the way themes/dark.css
+   is, because it has to be able to out-cascade an ancestor's dark. So the pin
+   re-declared all 48 brand-derived vars on the exact element the seed was
+   inheriting through, and everything below it fell back to canonical blue.
+   Only the tag showed it on that screen because PrizmaSelfieCapture paints no
+   brand ink at all — on a pinned screen carrying a Button the CTA was blue too.
+
+   The fix: hand the brand back to the scope above, for the light pin only
+   (dark.css is a delta and never touches these). Custom properties accept the
+   CSS-wide keywords, so `inherit` reaches past the pin's own declaration, and
+   `.prizma-screen-shell[data-prizma-theme='light']` (0,2,0) outranks the
+   sheet's `[data-prizma-theme='light']` (0,1,0) regardless of import order.
+
+   ONLY the tokens whose derived value is IDENTICAL in the light and dark maps
+   are listed (core/theming/derive.mjs — the `*Static` family plus
+   textAccentBrand / borderBrand500 / iconBrand500Static, and the component
+   tokens that are pure aliases of those). That is what makes `inherit` safe:
+   the ancestor carries whichever map its own mode resolved in, and for these
+   the two maps agree, so a purple card inside a DARK board still lands the
+   right purple on a light-pinned stage. Without a seed above, they inherit the
+   canonical value and this block is a no-op.
+
+   ⚠️ Known gap, deliberately left: the mode-DEPENDENT brand tokens
+   (surfaceBrand50, textAccentOnBrand, textLink*, borderBrandOnNeutral,
+   iconBrandOnNeutral, and their aliases — halos, snackbar neutral, links) keep
+   the pin's canonical value. They are AA-gated against the mode's background
+   or flip ramp stop, so inheriting a dark-derived value onto a light-pinned
+   stage would either invert them or silently drop Core's contrast guarantee.
+   Fixing those properly needs the scope above to publish BOTH maps; that is a
+   theming-contract change, not a stylesheet one.
+
+   ⚠️ PARITY: this is the WEB half only. Android and iOS ship the same pinned-
+   light capture screens and the same scoped-theme story, so the same bug is
+   very likely there under whatever their pin mechanism is. Flagged for those
+   owners — not touched here (core/ is source of truth for three platforms and
+   the ports are Cami's lane).
+   ------------------------------------------------------------------------- */
+.prizma-screen-shell[data-prizma-theme='light'] {
+  /* Semantics whose light and dark stops are the same colour. */
+  --prizma-surface-brand-400-static: inherit;
+  --prizma-surface-brand-500-static: inherit;
+  --prizma-surface-brand-600-static: inherit;
+  --prizma-surface-brand-700-static: inherit;
+  --prizma-text-accent-brand: inherit;
+  --prizma-border-brand-500: inherit;
+  --prizma-icon-brand-500-static: inherit;
+
+  /* Component tokens that are pure aliases of the seven above
+     (COMPONENT_ALIASES in core/theming/derive.mjs). */
+  --prizma-button-primary-border-default: inherit;
+  --prizma-button-primary-border-hover: inherit;
+  --prizma-button-primary-border-pressed: inherit;
+  --prizma-button-primary-surface-default: inherit;
+  --prizma-button-primary-surface-hover: inherit;
+  --prizma-button-primary-surface-pressed: inherit;
+  --prizma-button-secondary-border-default: inherit;
+  --prizma-button-secondary-border-hover: inherit;
+  --prizma-button-secondary-border-pressed: inherit;
+  --prizma-button-secondary-text-default: inherit;
+  --prizma-button-secondary-text-hover: inherit;
+  --prizma-button-secondary-text-pressed: inherit;
+  --prizma-button-tertiary-text-default: inherit;
+  --prizma-button-spinner-secondary-arc: inherit;
+  --prizma-checkbox-surface-selected: inherit;
+  --prizma-radio-button-surface-selected: inherit;
+  --prizma-toggle-switch-surface-primary-on: inherit;
+  --prizma-illustration-surface-accent: inherit;
+  --prizma-illustration-ring-start: inherit;
+
+  /* Mode-flipping in the canonical map, but a LIGHT pin means the LIGHT stop —
+     which for each of these IS ramp 500, i.e. the Static sibling re-inherited
+     just above. Reading it back through var() is what keeps the Logo wordmark
+     the seed's brand instead of the dark map's #ffffff-on-white.
+       surfaceBrand500      light 500 / dark #ffffff  (Logo, Stepper past-active)
+       surfaceBrandIndicator light 500 / dark 400     (+ its two aliases) */
+  --prizma-surface-brand-500: var(--prizma-surface-brand-500-static);
+  --prizma-surface-brand-indicator: var(--prizma-surface-brand-500-static);
+  --prizma-spinner-surface-primary: var(--prizma-surface-brand-500-static);
+  --prizma-loading-bar-fill-in-flight: var(--prizma-surface-brand-500-static);
+}