@incodetech/prizma-core-screens 0.1.0

package/dist/PhoneInputVerifyScreen.d.ts

@@ -0,0 +1,41 @@
+import React from 'react';
+import { type PrizmaFormScreenProps } from './FormScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { PhoneInputCountry, PhoneInputStrings, PhoneInputVerifyState } from './PhoneInputStrings';
+import './ScreenLayout.css';
+import './PhoneInputLayout.css';
+export interface PhoneInputVerifyScreenProps extends Omit<PrizmaFormScreenProps, 'title' | 'subtitle' | 'ctaLabel' | 'verifiedLabel' | 'children' | 'navLabel'> {
+    /** Module copy — this screen reads the `verify` slice. */
+    strings: PhoneInputStrings;
+    /** Which purple `phoneNumber.verify.*` section to render. Default `default`. */
+    state?: PhoneInputVerifyState;
+    /** The selectable dial codes. Runtime data, not copy. */
+    countries?: PhoneInputCountry[];
+    /** Selected country `value`. Defaults to the first entry. */
+    country?: string;
+    /** The phone number as typed. Empty renders the placeholder (`default`). */
+    value?: string;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * Phone Input — the phone-entry screen, built on the Form archetype
+ * (GUIDELINES.md §6-E, `PrizmaFormScreen`).
+ *
+ * ONE screen for all five purple `phoneNumber.verify.*` sections
+ * (`default` / `countryCode` / `phonetyping` / `phoneFilled` / `loading`):
+ * measured against the 390 frames, they share an identical layout — nav → Title
+ * (H2 + H5) → Spacing/32 → the combined country-dropdown + phone-field row →
+ * CTA → tag — and differ ONLY in field content and CTA state, which is exactly
+ * what GUIDELINES §6-E means by "states are separate screens sharing the
+ * identical layout".
+ *
+ * Figma's `Input / Combined` is a dropdown + text field pair at Spacing/8, the
+ * dropdown hugging its content and the field filling the rest. Core ships both
+ * primitives (`PrizmaDropdown`, `PrizmaTextField`) at the designed 56px min
+ * height and `Border/Radius/small`, so the module layer contributes only the
+ * row that pairs them (`PhoneInputLayout.css`) — no primitive is re-implemented.
+ */
+export declare const PhoneInputVerifyScreen: React.ForwardRefExoticComponent<PhoneInputVerifyScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default PhoneInputVerifyScreen;

package/dist/PhoneInputVerifyScreen.js

@@ -0,0 +1,71 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaTextField } from '@incodetech/prizma-core-web/text-field';
+import { PrizmaDropdown } from '@incodetech/prizma-core-web/dropdown';
+import { PrizmaFormScreen } from './FormScreen';
+import './ScreenLayout.css';
+import './PhoneInputLayout.css';
+/** Figma's `countryCode` section draws the dropdown menu open over the form;
+ *  Core exposes that as the documentation-only `forceOpen` (a screen is one
+ *  static spec state, never a live interaction). */
+const DEFAULT_COUNTRIES = [
+    { value: 'RS', dialCode: '+381', label: 'Serbia', flag: '🇷🇸' },
+];
+/**
+ * Phone Input — the phone-entry screen, built on the Form archetype
+ * (GUIDELINES.md §6-E, `PrizmaFormScreen`).
+ *
+ * ONE screen for all five purple `phoneNumber.verify.*` sections
+ * (`default` / `countryCode` / `phonetyping` / `phoneFilled` / `loading`):
+ * measured against the 390 frames, they share an identical layout — nav → Title
+ * (H2 + H5) → Spacing/32 → the combined country-dropdown + phone-field row →
+ * CTA → tag — and differ ONLY in field content and CTA state, which is exactly
+ * what GUIDELINES §6-E means by "states are separate screens sharing the
+ * identical layout".
+ *
+ * Figma's `Input / Combined` is a dropdown + text field pair at Spacing/8, the
+ * dropdown hugging its content and the field filling the rest. Core ships both
+ * primitives (`PrizmaDropdown`, `PrizmaTextField`) at the designed 56px min
+ * height and `Border/Radius/small`, so the module layer contributes only the
+ * row that pairs them (`PhoneInputLayout.css`) — no primitive is re-implemented.
+ */
+export const PhoneInputVerifyScreen = forwardRef(({ strings, state = 'default', countries = DEFAULT_COUNTRIES, country, value, screenId = `phone-input-verify-${state}`, overrides, onAction, ...shell }, ref) => {
+    const selected = country ?? countries[0]?.value;
+    const options = countries.map((c) => ({
+        value: c.value,
+        // The closed field shows flag + dial code exactly as Figma draws it
+        // ("🇷🇸 +381"); the open menu row adds the country name.
+        label: [c.flag, c.dialCode].filter(Boolean).join(' '),
+    }));
+    // Figma treats the states as three distinct field treatments, not one:
+    // `loading` greys BOTH fields (the request is in flight and the form is
+    // inert) and puts the spinner in the CTA; `typing` draws the focused blue
+    // border with the caret and the clear affordance; everything else is a
+    // plain editable field on the default white surface. Core's read-only
+    // paints the DISABLED surface (owner definition 2026-07-12), so it is used
+    // for none of them — it would grey the resting states too (DEVIATIONS #PI-6).
+    const busy = state === 'loading';
+    const focused = state === 'typing';
+    return (_jsx(PrizmaFormScreen, { ref: ref, title: strings.verify.title, subtitle: strings.verify.subtitle, ctaLabel: strings.verify.ctaLabel, 
+        /* Figma's `loading` section swaps the CTA label for Core's spinner. */
+        ctaLoading: busy, ctaLoadingLabel: strings.verify.ctaLoadingLabel, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: overrides, onAction: onAction, ...shell, children: _jsxs("div", { className: "phone-input-combined", children: [_jsx(PrizmaDropdown, { className: "phone-input-combined__country", "aria-label": strings.verify.countryLabel, options: options, value: selected, searchable: true, searchPlaceholder: strings.verify.countrySearchPlaceholder, 
+                    /* The `countryCode` section IS the open-menu spec state. */
+                    forceOpen: state === 'countryCode', disabled: busy }), _jsx(PrizmaTextField, { className: [
+                        'phone-input-combined__number',
+                        /* Core's own static-focus modifier — the same mechanism the
+                           Dropdown exposes as `forceState`, which `PrizmaTextField` has
+                           no prop for yet (DEVIATIONS #PI-7). No styling is redeclared. */
+                        focused ? 'prizma-input-textfield--focused' : '',
+                    ]
+                        .filter(Boolean)
+                        .join(' '), type: "tel", inputMode: "tel", "aria-label": strings.verify.fieldLabel, placeholder: strings.verify.placeholder, 
+                    /* Uncontrolled: a screen is one static spec state, and `value`
+                       without `onChange` would either warn or force `readOnly`, whose
+                       disabled surface is exactly the grey Figma does NOT draw here. */
+                    defaultValue: value ?? '', disabled: busy, 
+                    /* Figma draws the clear ✕ only while the field is focused. */
+                    clearable: focused })] }) }));
+});
+PhoneInputVerifyScreen.displayName = 'PhoneInputVerifyScreen';
+export default PhoneInputVerifyScreen;

package/dist/ProcessingScreen.d.ts

@@ -0,0 +1,42 @@
+import React, { type ReactNode } from 'react';
+import { type PrizmaScreenShellProps } from './ScreenShell';
+import type { PrizmaScreenActionHandler, PrizmaScreenChromeProps, PrizmaScreenOverrides } from './types';
+import './ScreenLayout.css';
+export type PrizmaProcessingStatus = 'loading' | 'success' | 'error' | 'warning';
+export interface PrizmaProcessingScreenProps extends Omit<PrizmaScreenShellProps, 'dark' | 'title'>, PrizmaScreenChromeProps {
+    /** `loading` renders the spinner slot; the rest render the status icon. */
+    status: PrizmaProcessingStatus;
+    /**
+     * An optional block between the logo nav and the content — a journey stepper.
+     * Video Selfie draws Core's `PrizmaStepper` on EVERY screen of the flow, not
+     * just its camera stages, and it is the only chrome that tells the steps
+     * apart; the archetypes had a slot on E alone, so the rest of the module shed
+     * it (owner-reported 2026-08-19). Takes a `ReactNode` so the module supplies
+     * Core's own component — no primitive invented, and both offsets live once in
+     * `ScreenLayout.css` (`.prizma-screen-layout__progress`). Omit it and nothing
+     * renders, so every existing consumer is byte-identical. DEVIATIONS #VS-4.
+     */
+    progress?: ReactNode;
+    /** H2 status line ("Processing…", "Verification complete"). */
+    title: string;
+    /** Optional supporting copy below the title. */
+    subtitle?: string;
+    /** "verified by" attribution copy for the footer tag. */
+    verifiedLabel: string;
+    navLabel?: string;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * Archetype C — Processing (GUIDELINES.md §6-C).
+ *
+ * This is the PURE case: a centered spinner or status mark with no CTA. As soon
+ * as a result screen needs a button, use `PrizmaResultScreen` — the missing CTA
+ * band here is what made three modules hand-build the same skeleton.
+ * Nav → fully centered column (icon/spinner + title via Core's PrizmaTitle
+ * slot) → tag pinned to the bottom. Used by every `*-uploading`,
+ * `*-processing`, `*-success` and `*-verified` screen.
+ */
+export declare const PrizmaProcessingScreen: React.ForwardRefExoticComponent<PrizmaProcessingScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default PrizmaProcessingScreen;

package/dist/ProcessingScreen.js

@@ -0,0 +1,21 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaTitle } from '@incodetech/prizma-core-web/title';
+import { PrizmaTag } from '@incodetech/prizma-core-web/tag';
+import { PrizmaScreenShell } from './ScreenShell';
+import { PrizmaScreenNav } from './ScreenNav';
+import './ScreenLayout.css';
+/**
+ * Archetype C — Processing (GUIDELINES.md §6-C).
+ *
+ * This is the PURE case: a centered spinner or status mark with no CTA. As soon
+ * as a result screen needs a button, use `PrizmaResultScreen` — the missing CTA
+ * band here is what made three modules hand-build the same skeleton.
+ * Nav → fully centered column (icon/spinner + title via Core's PrizmaTitle
+ * slot) → tag pinned to the bottom. Used by every `*-uploading`,
+ * `*-processing`, `*-success` and `*-verified` screen.
+ */
+export const PrizmaProcessingScreen = forwardRef(({ progress, status, title, subtitle, verifiedLabel, navLabel, screenId, showHeader = true, showFooter = true, overrides, onAction, ...shell }, ref) => (_jsxs(PrizmaScreenShell, { ref: ref, ...shell, children: [_jsx(PrizmaScreenNav, { reserved: !showHeader, logo: overrides?.logo, navLabel: navLabel }), progress ? (_jsx("div", { className: "prizma-screen-layout__progress", children: progress })) : null, _jsx("div", { className: "prizma-screen-layout__content prizma-screen-layout__content--centered", children: _jsx(PrizmaTitle, { variant: "centered", title: title, showSubtitle: Boolean(subtitle), subtitle: subtitle, icon: status === 'loading' ? { type: 'spinner' } : { type: 'status', status } }) }), showFooter ? (_jsx("div", { className: "prizma-screen-layout__footer", children: _jsx(PrizmaTag, { label: verifiedLabel }) })) : null] })));
+PrizmaProcessingScreen.displayName = 'PrizmaProcessingScreen';
+export default PrizmaProcessingScreen;

package/dist/QualifiedSignatureAcceptScreen.d.ts

@@ -0,0 +1,71 @@
+import React from 'react';
+import { type PrizmaFormScreenProps } from './FormScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { QualifiedSignatureAcceptState, QualifiedSignatureAcceptVariant, QualifiedSignatureStrings, QualifiedSignatureTerm } from './QualifiedSignatureStrings';
+import './ScreenLayout.css';
+import './QualifiedSignatureLayout.css';
+export interface QualifiedSignatureAcceptScreenProps extends Omit<PrizmaFormScreenProps, 'title' | 'subtitle' | 'ctaLabel' | 'ctaDisabled' | 'ctaLoading' | 'ctaLoadingLabel' | 'linkLabel' | 'linkContent' | 'verifiedLabel' | 'children' | 'navLabel'> {
+    /** Module copy — this screen reads the `accept` slice its `variant` names. */
+    strings: QualifiedSignatureStrings;
+    /** Which reading of the section to render. Default `accept`. */
+    variant?: QualifiedSignatureAcceptVariant;
+    /** Which purple state to render. Default `default`. */
+    state?: QualifiedSignatureAcceptState;
+    /** The consent clauses. Runtime data — the QTSP writes them, not the module. */
+    terms: QualifiedSignatureTerm[];
+    /** The document being signed, shown in the row above the clauses. Runtime
+     *  data from the upload step, so it stays out of `strings`. */
+    filename?: string;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * Qualified Signature — accept the terms and sign, built on the Form archetype
+ * (GUIDELINES.md §6-E, `PrizmaFormScreen`).
+ *
+ * Figma: the purple `QSign.AcceptSign.{default,selectedCheckox,loadingsign}`
+ * sections in BOTH parent groups — the generic five-clause reading ("Accept and
+ * sign" / "Finish signing") and the partner two-clause one ("Review and sign" /
+ * "Sign" + the certificate-application link). Six purple states, one screen:
+ * they share an identical skeleton and differ only in clause set, copy, tick
+ * state and CTA treatment, which is exactly what §6-E means by "states are
+ * separate screens sharing the identical layout".
+ *
+ * WHY ARCHETYPE E AND NOT G. The middle is a stack of Core `PrizmaCheckbox`
+ * CONTROLS — real form inputs the signer must operate before the CTA unlocks —
+ * not a card/option list, and the screen's whole point is the three CTA
+ * treatments (disabled → enabled → in-flight) that archetype G has no slots for
+ * (`PrizmaListScreen` offers neither `ctaDisabled` nor `ctaLoading`; that gap is
+ * reported, not worked around). E owns both, plus the `linkContent` slot the
+ * partner variant's link needs. Measured, the two archetypes want the same
+ * rhythm here anyway: Figma's `middle container` is Title → Spacing/32 → the
+ * document row, which is `FormScreen.css`'s title → fields offset to the pixel
+ * (DEVIATIONS #PI-2), and the row → clause-stack gap is the field stack's own
+ * Spacing/16.
+ *
+ * Four things are deliberate:
+ *
+ * 1. The document row is Core's `PrizmaCardDocumentContainer` — the Figma layer
+ *    is literally an instance of `Card / Document Container`, filename plus a
+ *    tertiary-link action. Nothing is hand-rolled.
+ * 2. Each clause is Core's `PrizmaCheckbox size="L"` (the consent container),
+ *    fed `segments` so the fourth Incode clause carries BOTH its inline links —
+ *    "Terms of Use" and "Privacy Policy" — as Core's own `<a>`s. That is the
+ *    #PI-10 rule (a sentence carrying links is not one button) satisfied by a
+ *    Core API rather than by the foundation's inline recipe.
+ * 3. `loading` greys the clauses through Core's own `disabled` treatment
+ *    (`Surface/Neutral/50` container + disabled ink + inert links) and swaps the
+ *    CTA label for Core's spinner via `ctaLoading` — the spinner belongs to the
+ *    BUTTON, never to a control (DEVIATIONS #PI-5).
+ * 4. The partner link rides `linkContent`, not `linkLabel`, so it can grey with
+ *    the rest of the form on `loading` (archetype E's `linkLabel` has no
+ *    disabled path) while staying a distinct `secondary` action — the CURP
+ *    #CURP-2 idiom.
+ *
+ * The nav draws no close ✕: every purple section in this file puts one at the
+ * nav's right, and GUIDELINES §3 stands — the Figma files are the side that is
+ * wrong (standing ruling, DEVIATIONS #PI-9).
+ */
+export declare const QualifiedSignatureAcceptScreen: React.ForwardRefExoticComponent<QualifiedSignatureAcceptScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default QualifiedSignatureAcceptScreen;

package/dist/QualifiedSignatureAcceptScreen.js

@@ -0,0 +1,86 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaCardDocumentContainer } from '@incodetech/prizma-core-web/card';
+import { PrizmaCheckbox } from '@incodetech/prizma-core-web/checkbox';
+import { PrizmaButton } from '@incodetech/prizma-core-web/button';
+import { PrizmaFormScreen } from './FormScreen';
+import './ScreenLayout.css';
+import './QualifiedSignatureLayout.css';
+/**
+ * Qualified Signature — accept the terms and sign, built on the Form archetype
+ * (GUIDELINES.md §6-E, `PrizmaFormScreen`).
+ *
+ * Figma: the purple `QSign.AcceptSign.{default,selectedCheckox,loadingsign}`
+ * sections in BOTH parent groups — the generic five-clause reading ("Accept and
+ * sign" / "Finish signing") and the partner two-clause one ("Review and sign" /
+ * "Sign" + the certificate-application link). Six purple states, one screen:
+ * they share an identical skeleton and differ only in clause set, copy, tick
+ * state and CTA treatment, which is exactly what §6-E means by "states are
+ * separate screens sharing the identical layout".
+ *
+ * WHY ARCHETYPE E AND NOT G. The middle is a stack of Core `PrizmaCheckbox`
+ * CONTROLS — real form inputs the signer must operate before the CTA unlocks —
+ * not a card/option list, and the screen's whole point is the three CTA
+ * treatments (disabled → enabled → in-flight) that archetype G has no slots for
+ * (`PrizmaListScreen` offers neither `ctaDisabled` nor `ctaLoading`; that gap is
+ * reported, not worked around). E owns both, plus the `linkContent` slot the
+ * partner variant's link needs. Measured, the two archetypes want the same
+ * rhythm here anyway: Figma's `middle container` is Title → Spacing/32 → the
+ * document row, which is `FormScreen.css`'s title → fields offset to the pixel
+ * (DEVIATIONS #PI-2), and the row → clause-stack gap is the field stack's own
+ * Spacing/16.
+ *
+ * Four things are deliberate:
+ *
+ * 1. The document row is Core's `PrizmaCardDocumentContainer` — the Figma layer
+ *    is literally an instance of `Card / Document Container`, filename plus a
+ *    tertiary-link action. Nothing is hand-rolled.
+ * 2. Each clause is Core's `PrizmaCheckbox size="L"` (the consent container),
+ *    fed `segments` so the fourth Incode clause carries BOTH its inline links —
+ *    "Terms of Use" and "Privacy Policy" — as Core's own `<a>`s. That is the
+ *    #PI-10 rule (a sentence carrying links is not one button) satisfied by a
+ *    Core API rather than by the foundation's inline recipe.
+ * 3. `loading` greys the clauses through Core's own `disabled` treatment
+ *    (`Surface/Neutral/50` container + disabled ink + inert links) and swaps the
+ *    CTA label for Core's spinner via `ctaLoading` — the spinner belongs to the
+ *    BUTTON, never to a control (DEVIATIONS #PI-5).
+ * 4. The partner link rides `linkContent`, not `linkLabel`, so it can grey with
+ *    the rest of the form on `loading` (archetype E's `linkLabel` has no
+ *    disabled path) while staying a distinct `secondary` action — the CURP
+ *    #CURP-2 idiom.
+ *
+ * The nav draws no close ✕: every purple section in this file puts one at the
+ * nav's right, and GUIDELINES §3 stands — the Figma files are the side that is
+ * wrong (standing ruling, DEVIATIONS #PI-9).
+ */
+export const QualifiedSignatureAcceptScreen = forwardRef(({ strings, variant = 'accept', state = 'default', terms, filename, screenId = `qualified-signature-accept-${variant}-${state}`, className, overrides, onAction, ...shell }, ref) => {
+    const copy = variant === 'certificate' ? strings.accept.certificate : strings.accept.accept;
+    // Figma's three states as two axes: whether the clauses are ticked, and
+    // whether the signature is being created. `default` leaves the CTA in Core's
+    // disabled surface because nothing is accepted yet; `selected` releases it;
+    // `loading` makes the whole form inert.
+    const busy = state === 'loading';
+    const ticked = state !== 'default';
+    return (_jsxs(PrizmaFormScreen, { ref: ref, className: ['qualified-signature-accept', className].filter(Boolean).join(' '), title: copy.title, subtitle: copy.subtitle, ctaLabel: copy.ctaLabel, ctaDisabled: !ticked, ctaLoading: busy, ctaLoadingLabel: copy.ctaLoadingLabel, 
+        /* The clause stack pans inside the column — the archetype owns this now
+           (`--scroll`), so the module declares no overflow of its own. #QS-1 */
+        scrollFields: true, linkContent: copy.linkLabel ? (_jsx(PrizmaButton, { variant: "tertiary-link", size: "L", 
+            /* Figma greys the link while the signature is created. */
+            disabled: busy, onClick: () => onAction?.({ type: 'secondary', screenId }), children: copy.linkLabel })) : undefined, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: overrides, onAction: onAction, ...shell, children: [filename ? (
+            /* `Card / Document Container` — Core's own horizontal filename +
+               tertiary-action row. `actionDisabled` follows the clauses and the
+               link into Core's disabled treatment on `loading`, so nothing on the
+               frame stays tappable while the signature is created (Core gained the
+               prop 2026-08-19 for exactly this; the composed Button already had
+               the `--prizma-button-tertiary-text-disabled` path, the row just had
+               no way to reach it).
+  
+               REPORTED DELTA: the generic `loadingsign` frame REMOVES the "View"
+               action outright while the partner's `loading` frame greys it. Two
+               Figma readings of one inert state; Core models inert as disabled,
+               so both take the greyed treatment and the removal is logged. */
+            _jsx(PrizmaCardDocumentContainer, { filename: filename, actionLabel: strings.accept.viewLabel, actionDisabled: busy, onAction: () => onAction?.({ type: 'tertiary', screenId }) })) : null, _jsx("div", { className: "qualified-signature-terms", role: "group", "aria-label": strings.accept.termsLabel, children: terms.map((term) => (_jsx(PrizmaCheckbox, { size: "L", name: term.id, value: term.id, checked: ticked, disabled: busy, segments: term.segments }, term.id))) })] }));
+});
+QualifiedSignatureAcceptScreen.displayName = 'QualifiedSignatureAcceptScreen';
+export default QualifiedSignatureAcceptScreen;

package/dist/QualifiedSignatureDocumentScreen.d.ts

@@ -0,0 +1,62 @@
+import React, { type ReactNode } from 'react';
+import { type PrizmaListScreenProps } from './ListScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { QualifiedSignatureDocumentVariant, QualifiedSignatureStrings } from './QualifiedSignatureStrings';
+import './ScreenLayout.css';
+import './QualifiedSignatureLayout.css';
+export interface QualifiedSignatureDocumentScreenProps extends Omit<PrizmaListScreenProps, 'status' | 'title' | 'subtitle' | 'glyph' | 'children' | 'listAlign' | 'disclaimer' | 'ctaLabel' | 'secondaryCtaLabel' | 'linkLabel' | 'verifiedLabel' | 'navLabel'> {
+    /** Module copy — this screen reads the `document` slice its `variant` names. */
+    strings: QualifiedSignatureStrings;
+    /** Which full-surface document section to render. Default `document`. */
+    variant?: QualifiedSignatureDocumentVariant;
+    /**
+     * The document itself. HOST-supplied content, never module copy — the rendered
+     * contract page on `document` (an `<img>` / `<canvas>` of the PDF) and the
+     * certificate-application text on `terms`. Same slot contract the capture
+     * screens use for `camera` (GUIDELINES §10).
+     */
+    body?: ReactNode;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * Qualified Signature — the two full-surface document screens, built on the List
+ * archetype (GUIDELINES.md §6-G, `PrizmaListScreen`).
+ *
+ * Figma:
+ * - `document` — `QSign.AcceptSign.viewdoc` (10196:67381 / the partner's
+ *   6120:34074): the contract behind the accept screen's "View" action. CONTENT
+ *   = nav 8→52 · a 342-wide page filling 68→660 · the Tag at 676.
+ * - `terms`    — `QSign.T&C` (11130:43690): the certificate application form
+ *   behind the partner variant's link. A left-aligned heading over a 13 575-tall
+ *   block of legal text WITH ITS OWN SCROLL INDICATOR — Figma is explicit that
+ *   this surface scrolls.
+ *
+ * Archetype G is the fit: its `__list` middle is "content filling the space
+ * between the title block and the CTA band", which is exactly what a document
+ * page is, and both sections carry no CTA at all so the band never renders. The
+ * body is allowed to scroll inside that middle — one module rule RELEASING an
+ * overflow constraint, declaring no spacing or size, the same idiom as CURP's
+ * taller-than-844 form (DEVIATIONS #CURP-1).
+ *
+ * THREE deltas from the frames, all reported rather than worked around:
+ * 1. Both sections draw a back chevron at the nav's left (and `terms` replaces
+ *    the logo row with a chevron + heading bar). GUIDELINES §3 stands: SDK
+ *    screens carry no dismiss or back affordance — the standing ruling of
+ *    DEVIATIONS #PI-9, which is not re-litigated per module.
+ * 2. `viewdoc` draws NO heading. GUIDELINES §4 is explicit that every screen has
+ *    exactly one H2, and archetype G has no title-less path, so the screen
+ *    carries one and the Figma frame is the side to change. (An archetype
+ *    request for an optional title — a pure content viewer — is logged.)
+ * 3. `terms` draws neither the logo nor the tag. The owner rule wins over Figma
+ *    for attribution chrome (#PI-8, #F-30, #F-34), so both variants keep the
+ *    header and the footer and nothing shifts between states.
+ *
+ * `terms` is LEFT-aligned, as Figma draws it: a centred heading over a
+ * left-aligned wall of legal text reads as a mistake. The alignment rides the
+ * sanctioned `overrides.align` path (types.ts) — nothing is re-styled here — and
+ * an explicit host override still wins. The #GEO-2 precedent.
+ */
+export declare const QualifiedSignatureDocumentScreen: React.ForwardRefExoticComponent<QualifiedSignatureDocumentScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default QualifiedSignatureDocumentScreen;

package/dist/QualifiedSignatureDocumentScreen.js

@@ -0,0 +1,56 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaListScreen } from './ListScreen';
+import './ScreenLayout.css';
+import './QualifiedSignatureLayout.css';
+/**
+ * Qualified Signature — the two full-surface document screens, built on the List
+ * archetype (GUIDELINES.md §6-G, `PrizmaListScreen`).
+ *
+ * Figma:
+ * - `document` — `QSign.AcceptSign.viewdoc` (10196:67381 / the partner's
+ *   6120:34074): the contract behind the accept screen's "View" action. CONTENT
+ *   = nav 8→52 · a 342-wide page filling 68→660 · the Tag at 676.
+ * - `terms`    — `QSign.T&C` (11130:43690): the certificate application form
+ *   behind the partner variant's link. A left-aligned heading over a 13 575-tall
+ *   block of legal text WITH ITS OWN SCROLL INDICATOR — Figma is explicit that
+ *   this surface scrolls.
+ *
+ * Archetype G is the fit: its `__list` middle is "content filling the space
+ * between the title block and the CTA band", which is exactly what a document
+ * page is, and both sections carry no CTA at all so the band never renders. The
+ * body is allowed to scroll inside that middle — one module rule RELEASING an
+ * overflow constraint, declaring no spacing or size, the same idiom as CURP's
+ * taller-than-844 form (DEVIATIONS #CURP-1).
+ *
+ * THREE deltas from the frames, all reported rather than worked around:
+ * 1. Both sections draw a back chevron at the nav's left (and `terms` replaces
+ *    the logo row with a chevron + heading bar). GUIDELINES §3 stands: SDK
+ *    screens carry no dismiss or back affordance — the standing ruling of
+ *    DEVIATIONS #PI-9, which is not re-litigated per module.
+ * 2. `viewdoc` draws NO heading. GUIDELINES §4 is explicit that every screen has
+ *    exactly one H2, and archetype G has no title-less path, so the screen
+ *    carries one and the Figma frame is the side to change. (An archetype
+ *    request for an optional title — a pure content viewer — is logged.)
+ * 3. `terms` draws neither the logo nor the tag. The owner rule wins over Figma
+ *    for attribution chrome (#PI-8, #F-30, #F-34), so both variants keep the
+ *    header and the footer and nothing shifts between states.
+ *
+ * `terms` is LEFT-aligned, as Figma draws it: a centred heading over a
+ * left-aligned wall of legal text reads as a mistake. The alignment rides the
+ * sanctioned `overrides.align` path (types.ts) — nothing is re-styled here — and
+ * an explicit host override still wins. The #GEO-2 precedent.
+ */
+export const QualifiedSignatureDocumentScreen = forwardRef(({ strings, variant = 'document', body, screenId = `qualified-signature-document-${variant}`, overrides, onAction, ...shell }, ref) => {
+    const copy = variant === 'terms' ? strings.document.terms : strings.document.document;
+    // The legal wall is left-aligned in Figma; the contract page keeps the
+    // archetype's centred default. An explicit `overrides.align` still wins.
+    const alignedOverrides = {
+        ...overrides,
+        align: overrides?.align ?? (variant === 'terms' ? 'left' : 'centered'),
+    };
+    return (_jsx(PrizmaListScreen, { ref: ref, title: copy.title, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: alignedOverrides, onAction: onAction, ...shell, children: _jsx("div", { className: "qualified-signature-document", children: body }) }));
+});
+QualifiedSignatureDocumentScreen.displayName = 'QualifiedSignatureDocumentScreen';
+export default QualifiedSignatureDocumentScreen;