@incodetech/prizma-core-screens 0.1.0

package/dist/NfcStrings.d.ts

@@ -0,0 +1,112 @@
+/** Which document's chip is being read. Drives artwork AND copy on every
+ *  family that has a passport/ID split (symbol · tutorial · tryAgain ·
+ *  commonIssues). */
+export type NfcDocumentType = 'passport' | 'id';
+/**
+ * Which common-issue row this is. The kind — not the copy — picks the row's
+ * canonical bank glyph (`NfcCommonIssuesScreen`), so a translated label never
+ * changes the icon. `passportTooFar` / `idTooFar` are two kinds rather than one
+ * because the bank draws the document itself in the glyph.
+ */
+export type NfcIssueKind = 'passportInCover' | 'passportTooFar' | 'idTooFar' | 'chipOtherPage' | 'phoneMoved' | 'phoneCover';
+export interface NfcIssueStrings {
+    /** Which glyph leads the row. */
+    kind: NfcIssueKind;
+    /** The row's single line of copy. */
+    label: string;
+}
+/** One title + subtitle pair. Used by every family that varies only in copy. */
+export interface NfcHeadingStrings {
+    title: string;
+    subtitle: string;
+}
+export interface NfcStrings {
+    /** "verified by" attribution copy for the footer tag. */
+    verifiedLabel: string;
+    /** Accessible name for the nav region. */
+    navLabel: string;
+    /** `nfc.symbol.{passport,id}` — "Is this symbol visible…?" */
+    symbol: {
+        passport: {
+            title: string;
+        };
+        id: {
+            title: string;
+        };
+        /** Filled primary. */
+        yesLabel: string;
+        /** Outlined secondary. */
+        noLabel: string;
+        /** Accessible name for the chip-location artwork. */
+        illustrationLabel: string;
+    };
+    /** `nfc.tutorial.{passport,id}` — the pre-scan instruction. */
+    tutorial: {
+        passport: NfcHeadingStrings;
+        id: NfcHeadingStrings;
+        ctaLabel: string;
+        illustrationLabel: string;
+    };
+    /**
+     * `nfc.scanning.*` — the Prizma layer that runs UNDER the platform's own NFC
+     * sheet: title block + progress bar. The sheet itself is OS chrome and is not
+     * a screen this package can build (see `NfcScanningScreen`).
+     *
+     * Two entries only. There is no `error` copy here: on the failure frames
+     * (`nfc.scanning.scanningerror` · `.androidscanningError`) the words "We
+     * couldn't scan the chip" belong to the OS sheet, and the Prizma layer behind
+     * it is still the `scanning` one.
+     */
+    scanning: {
+        scanning: NfcHeadingStrings;
+        done: NfcHeadingStrings;
+        /** The line under the bar ("Hold still.."). */
+        progressLabel: string;
+    };
+    /** `nfc.tryagain.*` — retry instructions, one per passport page + the ID. */
+    tryAgain: {
+        passport: NfcHeadingStrings;
+        firstPage: NfcHeadingStrings;
+        photoPage: NfcHeadingStrings;
+        backPage: NfcHeadingStrings;
+        id: NfcHeadingStrings;
+        /** Filled primary. */
+        ctaLabel: string;
+        /** Outlined secondary — opens the common-issues sheet. */
+        helpLabel: string;
+        illustrationLabel: string;
+    };
+    /** `nfc.commonissues.{id,passport}` — the help sheet. */
+    commonIssues: {
+        title: string;
+        ctaLabel: string;
+        /** Accessible name for the row list. */
+        listLabel: string;
+        /** Three rows on the ID sheet, five on the passport one. */
+        issues: Record<NfcDocumentType, NfcIssueStrings[]>;
+    };
+    /** `nfc.loading.default` — chip read, identity being verified. */
+    loading: NfcHeadingStrings;
+    /** `nfc.success.default` — the verdict. No button. */
+    success: {
+        title: string;
+    };
+    /** `nfc.error.{unable,generalerror}` — the two verdict errors. */
+    error: {
+        unable: NfcHeadingStrings & {
+            ctaLabel: string;
+        };
+        general: {
+            title: string;
+            ctaLabel: string;
+        };
+    };
+    /** `nfc.error.nfcsettings` — the "turn NFC on" dialog. */
+    settings: {
+        title: string;
+        subtitle: string;
+        ctaLabel: string;
+        /** Accessible name for the dialog. */
+        dialogLabel: string;
+    };
+}

package/dist/NfcStrings.js

@@ -0,0 +1,7 @@
+// NFC — every string the module's screens render.
+//
+// Screens are pure presentational components (GUIDELINES.md §9): no English is
+// baked into a screen file, so the whole module is translated by swapping this
+// one object. Mirrors the module's Figma localization columns (🇺🇸 US · 🇪🇸 ES ·
+// 🇵🇹 PT) on `dlEkkopentyypbxlYjDWTZ`, page `19971:96836`.
+export {};

package/dist/NfcSuccessScreen.d.ts

@@ -0,0 +1,28 @@
+import React from 'react';
+import { type PrizmaProcessingScreenProps } from './ProcessingScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { NfcStrings } from './NfcStrings';
+import './ScreenLayout.css';
+export interface NfcSuccessScreenProps extends Omit<PrizmaProcessingScreenProps, 'status' | 'title' | 'subtitle' | 'verifiedLabel' | 'navLabel'> {
+    /** Module copy — this screen reads the `success` slice. */
+    strings: NfcStrings;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * NFC — "Identity successfully verified", the module's positive verdict.
+ * Purple section `nfc.success.default` (19975:109249).
+ *
+ * Archetype C, not F: the section draws NO button (the flow advances on its
+ * own), and §6-F reserves C for exactly the pure no-CTA case — the same split
+ * Email Input's success takes while Phone Input's, which does draw a button,
+ * sits on F (#EI-4).
+ *
+ * Figma draws the check as a filled green disc; Core renders the single-colour
+ * OUTLINE mark from the icon bank (icon-outline sweep, owner 2026-07-28), so
+ * this screen shows the outline — the module Figma is one sweep behind, exactly
+ * as recorded for every other module's status marks (#15, #DC-34).
+ */
+export declare const NfcSuccessScreen: React.ForwardRefExoticComponent<NfcSuccessScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default NfcSuccessScreen;

package/dist/NfcSuccessScreen.js

@@ -0,0 +1,22 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaProcessingScreen, } from './ProcessingScreen';
+import './ScreenLayout.css';
+/**
+ * NFC — "Identity successfully verified", the module's positive verdict.
+ * Purple section `nfc.success.default` (19975:109249).
+ *
+ * Archetype C, not F: the section draws NO button (the flow advances on its
+ * own), and §6-F reserves C for exactly the pure no-CTA case — the same split
+ * Email Input's success takes while Phone Input's, which does draw a button,
+ * sits on F (#EI-4).
+ *
+ * Figma draws the check as a filled green disc; Core renders the single-colour
+ * OUTLINE mark from the icon bank (icon-outline sweep, owner 2026-07-28), so
+ * this screen shows the outline — the module Figma is one sweep behind, exactly
+ * as recorded for every other module's status marks (#15, #DC-34).
+ */
+export const NfcSuccessScreen = forwardRef(({ strings, screenId = 'nfc-success', overrides, onAction, ...shell }, ref) => (_jsx(PrizmaProcessingScreen, { ref: ref, status: "success", title: strings.success.title, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: overrides, onAction: onAction, ...shell })));
+NfcSuccessScreen.displayName = 'NfcSuccessScreen';
+export default NfcSuccessScreen;

package/dist/NfcSymbolScreen.d.ts

@@ -0,0 +1,39 @@
+import React from 'react';
+import { type PrizmaListScreenProps } from './ListScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { NfcDocumentType, NfcStrings } from './NfcStrings';
+import './ScreenLayout.css';
+export interface NfcSymbolScreenProps extends Omit<PrizmaListScreenProps, 'title' | 'subtitle' | 'children' | 'ctaLabel' | 'secondaryCtaLabel' | 'linkLabel' | 'verifiedLabel' | 'navLabel'> {
+    /** Module copy — this screen reads the `symbol` slice. */
+    strings: NfcStrings;
+    /** Which purple section: `nfc.symbol.passport` or `nfc.symbol.id`. */
+    documentType?: NfcDocumentType;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * NFC — "Is this symbol visible on your passport cover / on the front or back
+ * of your ID?", the gate that decides whether the chip flow can run at all.
+ * Purple sections `nfc.symbol.passport` (19974:74431) and `nfc.symbol.id`
+ * (19978:116624).
+ *
+ * Built on the List archetype (GUIDELINES.md §6-G, `PrizmaListScreen`) rather
+ * than the Tutorial one, because the frames TOP-align the title at the nav's
+ * Spacing/24 and hang the artwork under it — which is exactly what G's middle
+ * slot does — while archetype A's `__flex` centres its illustration in the
+ * whole middle and would drop the title ~84px. G's slot is a generic middle,
+ * not a list-only slot; the class name is the only thing that says otherwise.
+ *
+ * The artwork is Core's own `PrizmaIllustrationNfcLocation` — the "where is the
+ * chip" companion from the same Figma section as the scan animation — so
+ * nothing is inlined here (GUIDELINES §10).
+ *
+ * ONE thing Figma draws that this screen does not: the two answers side by
+ * side, "No" left and "Yes" right. Archetype G has no `ctaOrientation` (only F
+ * does, #F-33), and a screen never declares its own button layout, so the pair
+ * stacks — primary "Yes" above secondary "No", which is the standing order rule
+ * (#GEO-1). Reported as an archetype gap rather than worked around.
+ */
+export declare const NfcSymbolScreen: React.ForwardRefExoticComponent<NfcSymbolScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default NfcSymbolScreen;

package/dist/NfcSymbolScreen.js

@@ -0,0 +1,32 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaIllustrationNfcLocation } from '@incodetech/prizma-core-web/illustration-nfc-scan';
+import { PrizmaListScreen } from './ListScreen';
+import './ScreenLayout.css';
+/**
+ * NFC — "Is this symbol visible on your passport cover / on the front or back
+ * of your ID?", the gate that decides whether the chip flow can run at all.
+ * Purple sections `nfc.symbol.passport` (19974:74431) and `nfc.symbol.id`
+ * (19978:116624).
+ *
+ * Built on the List archetype (GUIDELINES.md §6-G, `PrizmaListScreen`) rather
+ * than the Tutorial one, because the frames TOP-align the title at the nav's
+ * Spacing/24 and hang the artwork under it — which is exactly what G's middle
+ * slot does — while archetype A's `__flex` centres its illustration in the
+ * whole middle and would drop the title ~84px. G's slot is a generic middle,
+ * not a list-only slot; the class name is the only thing that says otherwise.
+ *
+ * The artwork is Core's own `PrizmaIllustrationNfcLocation` — the "where is the
+ * chip" companion from the same Figma section as the scan animation — so
+ * nothing is inlined here (GUIDELINES §10).
+ *
+ * ONE thing Figma draws that this screen does not: the two answers side by
+ * side, "No" left and "Yes" right. Archetype G has no `ctaOrientation` (only F
+ * does, #F-33), and a screen never declares its own button layout, so the pair
+ * stacks — primary "Yes" above secondary "No", which is the standing order rule
+ * (#GEO-1). Reported as an archetype gap rather than worked around.
+ */
+export const NfcSymbolScreen = forwardRef(({ strings, documentType = 'passport', screenId = `nfc-symbol-${documentType}`, overrides, onAction, ...shell }, ref) => (_jsx(PrizmaListScreen, { ref: ref, title: strings.symbol[documentType].title, ctaLabel: strings.symbol.yesLabel, secondaryCtaLabel: strings.symbol.noLabel, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: overrides, onAction: onAction, ...shell, children: _jsx(PrizmaIllustrationNfcLocation, { type: documentType, ariaLabel: strings.symbol.illustrationLabel }) })));
+NfcSymbolScreen.displayName = 'NfcSymbolScreen';
+export default NfcSymbolScreen;

package/dist/NfcTryAgainScreen.d.ts

@@ -0,0 +1,53 @@
+import React, { type ReactNode } from 'react';
+import { type PrizmaListScreenProps } from './ListScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { NfcStrings } from './NfcStrings';
+import './ScreenLayout.css';
+/**
+ * Which retry instruction to show. The four passport values are the pages a
+ * passport read walks through — `nfc.tryagain.passport` (the cover),
+ * `.passportfirstpage`, `.passportphotopage`, `.passportbackpage` — and `id` is
+ * the single-surface ID section.
+ */
+export type NfcTryAgainStep = 'passport' | 'firstPage' | 'photoPage' | 'backPage' | 'id';
+export interface NfcTryAgainScreenProps extends Omit<PrizmaListScreenProps, 'title' | 'subtitle' | 'children' | 'ctaLabel' | 'secondaryCtaLabel' | 'linkLabel' | 'verifiedLabel' | 'navLabel'> {
+    /** Module copy — this screen reads the `tryAgain` slice. */
+    strings: NfcStrings;
+    /** Which purple section to render. Default `passport`. */
+    step?: NfcTryAgainStep;
+    /** Replace Core's NFC artwork. */
+    illustration?: ReactNode;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * NFC — the retry instructions: "Let's try again" for the cover, then one
+ * screen per passport page ("Scan the first page" / "the photo page" / "the
+ * back page"), plus the ID's own. Purple sections `nfc.tryagain.*`
+ * (22469:40368), five in all.
+ *
+ * ONE screen for all five: they draw the identical skeleton — title block →
+ * document artwork filling the middle → Help + Try again — and differ only in
+ * the instruction, so five files would have been five chances to drift. The
+ * artwork is Core's `PrizmaIllustrationNfcScan`, frozen (`animated={false}`)
+ * because these sections draw the document at rest, not the scan loop.
+ *
+ * Archetype G (`PrizmaListScreen`) for the same reason as `NfcSymbolScreen`:
+ * the frames top-align the title at Spacing/24 under the nav and hang the
+ * artwork below it.
+ *
+ * TWO things Figma draws that this screen does not, both reported rather than
+ * worked around:
+ * - **The page-position dots.** Every passport section carries a 52 × 7 row of
+ *   four dots under the artwork, marking which page is being read. Core ships
+ *   no pagination/dots primitive — `PrizmaStepper` is a journey stepper with
+ *   labelled segments and icons, a different thing — and GUIDELINES §10 forbids
+ *   inventing one. The step is still legible: each section's title names the
+ *   page. **Core request: a dots/page-indicator primitive.**
+ * - **Help | Try again side by side.** Archetype G has no `ctaOrientation`
+ *   (only F does, #F-33), so the pair stacks: primary "Try again" above
+ *   secondary "Help", per the standing order rule (#GEO-1).
+ */
+export declare const NfcTryAgainScreen: React.ForwardRefExoticComponent<NfcTryAgainScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default NfcTryAgainScreen;

package/dist/NfcTryAgainScreen.js

@@ -0,0 +1,45 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaIllustrationNfcScan } from '@incodetech/prizma-core-web/illustration-nfc-scan';
+import { PrizmaListScreen } from './ListScreen';
+import './ScreenLayout.css';
+/** Which document each step belongs to — picks the artwork. */
+const DOCUMENT_BY_STEP = {
+    passport: 'passport',
+    firstPage: 'passport',
+    photoPage: 'passport',
+    backPage: 'passport',
+    id: 'id',
+};
+/**
+ * NFC — the retry instructions: "Let's try again" for the cover, then one
+ * screen per passport page ("Scan the first page" / "the photo page" / "the
+ * back page"), plus the ID's own. Purple sections `nfc.tryagain.*`
+ * (22469:40368), five in all.
+ *
+ * ONE screen for all five: they draw the identical skeleton — title block →
+ * document artwork filling the middle → Help + Try again — and differ only in
+ * the instruction, so five files would have been five chances to drift. The
+ * artwork is Core's `PrizmaIllustrationNfcScan`, frozen (`animated={false}`)
+ * because these sections draw the document at rest, not the scan loop.
+ *
+ * Archetype G (`PrizmaListScreen`) for the same reason as `NfcSymbolScreen`:
+ * the frames top-align the title at Spacing/24 under the nav and hang the
+ * artwork below it.
+ *
+ * TWO things Figma draws that this screen does not, both reported rather than
+ * worked around:
+ * - **The page-position dots.** Every passport section carries a 52 × 7 row of
+ *   four dots under the artwork, marking which page is being read. Core ships
+ *   no pagination/dots primitive — `PrizmaStepper` is a journey stepper with
+ *   labelled segments and icons, a different thing — and GUIDELINES §10 forbids
+ *   inventing one. The step is still legible: each section's title names the
+ *   page. **Core request: a dots/page-indicator primitive.**
+ * - **Help | Try again side by side.** Archetype G has no `ctaOrientation`
+ *   (only F does, #F-33), so the pair stacks: primary "Try again" above
+ *   secondary "Help", per the standing order rule (#GEO-1).
+ */
+export const NfcTryAgainScreen = forwardRef(({ strings, step = 'passport', illustration, screenId = `nfc-try-again-${step}`, overrides, onAction, ...shell }, ref) => (_jsx(PrizmaListScreen, { ref: ref, title: strings.tryAgain[step].title, subtitle: strings.tryAgain[step].subtitle, ctaLabel: strings.tryAgain.ctaLabel, secondaryCtaLabel: strings.tryAgain.helpLabel, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: overrides, onAction: onAction, ...shell, children: illustration ?? (_jsx(PrizmaIllustrationNfcScan, { type: DOCUMENT_BY_STEP[step], animated: false, ariaLabel: strings.tryAgain.illustrationLabel })) })));
+NfcTryAgainScreen.displayName = 'NfcTryAgainScreen';
+export default NfcTryAgainScreen;

package/dist/NfcTutorialScreen.d.ts

@@ -0,0 +1,33 @@
+import React, { type ReactNode } from 'react';
+import { type PrizmaTutorialScreenProps } from './TutorialScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { NfcDocumentType, NfcStrings } from './NfcStrings';
+import './ScreenLayout.css';
+export interface NfcTutorialScreenProps extends Omit<PrizmaTutorialScreenProps, 'title' | 'subtitle' | 'ctaLabel' | 'illustration' | 'verifiedLabel' | 'navLabel'> {
+    /** Module copy — this screen reads the `tutorial` slice. */
+    strings: NfcStrings;
+    /** Which purple section: `nfc.tutorial.passport` or `nfc.tutorial.id`. */
+    documentType?: NfcDocumentType;
+    /** Replace Core's NFC artwork (hosts that ship their own document art). */
+    illustration?: ReactNode;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * NFC — "Let's scan your passport chip" / "Read the chip on the ID", the
+ * instruction screen the CTA starts the read from. Purple sections
+ * `nfc.tutorial.passport` (19974:80984) and `nfc.tutorial.id` (19978:115144),
+ * on the Tutorial archetype (GUIDELINES.md §6-A).
+ *
+ * The centrepiece is Core's `PrizmaIllustrationNfcScan` — the looping
+ * phone-approaches-the-chip composition whose Figma frames ARE the two
+ * `iOS Animation` / `Android Animation` layers these sections draw. The screen
+ * supplies no artwork of its own.
+ *
+ * This is also what the four `nfc.scanning.*ready` sections show: they are this
+ * exact screen with the platform's NFC sheet presented over it, so they need no
+ * screen of their own (see `NfcScanningScreen`).
+ */
+export declare const NfcTutorialScreen: React.ForwardRefExoticComponent<NfcTutorialScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default NfcTutorialScreen;

package/dist/NfcTutorialScreen.js

@@ -0,0 +1,24 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaIllustrationNfcScan } from '@incodetech/prizma-core-web/illustration-nfc-scan';
+import { PrizmaTutorialScreen } from './TutorialScreen';
+import './ScreenLayout.css';
+/**
+ * NFC — "Let's scan your passport chip" / "Read the chip on the ID", the
+ * instruction screen the CTA starts the read from. Purple sections
+ * `nfc.tutorial.passport` (19974:80984) and `nfc.tutorial.id` (19978:115144),
+ * on the Tutorial archetype (GUIDELINES.md §6-A).
+ *
+ * The centrepiece is Core's `PrizmaIllustrationNfcScan` — the looping
+ * phone-approaches-the-chip composition whose Figma frames ARE the two
+ * `iOS Animation` / `Android Animation` layers these sections draw. The screen
+ * supplies no artwork of its own.
+ *
+ * This is also what the four `nfc.scanning.*ready` sections show: they are this
+ * exact screen with the platform's NFC sheet presented over it, so they need no
+ * screen of their own (see `NfcScanningScreen`).
+ */
+export const NfcTutorialScreen = forwardRef(({ strings, documentType = 'passport', illustration, screenId = `nfc-tutorial-${documentType}`, overrides, onAction, ...shell }, ref) => (_jsx(PrizmaTutorialScreen, { ref: ref, title: strings.tutorial[documentType].title, subtitle: strings.tutorial[documentType].subtitle, ctaLabel: strings.tutorial.ctaLabel, illustration: illustration ?? (_jsx(PrizmaIllustrationNfcScan, { type: documentType, ariaLabel: strings.tutorial.illustrationLabel })), verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: overrides, onAction: onAction, ...shell })));
+NfcTutorialScreen.displayName = 'NfcTutorialScreen';
+export default NfcTutorialScreen;

package/dist/PermissionsAllowScreen.d.ts

@@ -0,0 +1,44 @@
+import React from 'react';
+import { type PrizmaResultScreenProps } from './ResultScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { PermissionsStrings } from './PermissionsStrings';
+import './ScreenLayout.css';
+export interface PermissionsAllowScreenProps extends Omit<PrizmaResultScreenProps, 'status' | 'title' | 'subtitle' | 'glyph' | 'ctaLabel' | 'linkLabel' | 'verifiedLabel' | 'navLabel'> {
+    /** Family copy — this screen reads the `allow` slice. */
+    strings: PermissionsStrings;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * Permissions — "Allow Incode to access your camera", built on the Result
+ * archetype (GUIDELINES.md §6-F, `PrizmaResultScreen`).
+ *
+ * Figma: `1-3-2-id-allow-camera` of the `Permissions` section
+ * (qGJjfL4O0JSjz1x4tOjJn8, 3:1193). The sibling of
+ * `PermissionsRequiredScreen`, and the reason they are two screens rather than
+ * one with a variant: this frame states the ask in a centred title + supporting
+ * line, that one argues it with a list of reasons hung under the title. Result
+ * centres its column, List hangs it from the top — different archetypes, so
+ * different screens.
+ *
+ * `1-3-2-id-allow-camera-quit-process` is the SAME screen with an iOS confirm
+ * alert layered over it — an OS surface, not a second Prizma screen (see
+ * `PermissionsStrings.ts`).
+ *
+ * `showHeader={false}` keeps the section's logo-free chrome (the flow has not
+ * started) with the nav row still reserved.
+ *
+ * TWO things Figma draws that this screen does not, both reported rather than
+ * worked around:
+ * - **The filled amber disc.** Core renders the canonical OUTLINE warning mark
+ *   (icon-outline sweep, DEVIATIONS #15).
+ * - **"Quit process" above the CTA.** Archetype F renders its tertiary link
+ *   BELOW the button stack (`ResultScreen.tsx`), so this screen ships inverted
+ *   against its frame. The archetype owns the order and no screen re-declares
+ *   it — F needs a `ctaOrder` slot alongside the `ctaOrientation` it already
+ *   has, exactly as Geolocation escalated for the same reason. Borrowing
+ *   `bandContent` to fake the position is the workaround #VS-17 rejected.
+ */
+export declare const PermissionsAllowScreen: React.ForwardRefExoticComponent<PermissionsAllowScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default PermissionsAllowScreen;

package/dist/PermissionsAllowScreen.js

@@ -0,0 +1,38 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { PrizmaResultScreen } from './ResultScreen';
+import './ScreenLayout.css';
+/**
+ * Permissions — "Allow Incode to access your camera", built on the Result
+ * archetype (GUIDELINES.md §6-F, `PrizmaResultScreen`).
+ *
+ * Figma: `1-3-2-id-allow-camera` of the `Permissions` section
+ * (qGJjfL4O0JSjz1x4tOjJn8, 3:1193). The sibling of
+ * `PermissionsRequiredScreen`, and the reason they are two screens rather than
+ * one with a variant: this frame states the ask in a centred title + supporting
+ * line, that one argues it with a list of reasons hung under the title. Result
+ * centres its column, List hangs it from the top — different archetypes, so
+ * different screens.
+ *
+ * `1-3-2-id-allow-camera-quit-process` is the SAME screen with an iOS confirm
+ * alert layered over it — an OS surface, not a second Prizma screen (see
+ * `PermissionsStrings.ts`).
+ *
+ * `showHeader={false}` keeps the section's logo-free chrome (the flow has not
+ * started) with the nav row still reserved.
+ *
+ * TWO things Figma draws that this screen does not, both reported rather than
+ * worked around:
+ * - **The filled amber disc.** Core renders the canonical OUTLINE warning mark
+ *   (icon-outline sweep, DEVIATIONS #15).
+ * - **"Quit process" above the CTA.** Archetype F renders its tertiary link
+ *   BELOW the button stack (`ResultScreen.tsx`), so this screen ships inverted
+ *   against its frame. The archetype owns the order and no screen re-declares
+ *   it — F needs a `ctaOrder` slot alongside the `ctaOrientation` it already
+ *   has, exactly as Geolocation escalated for the same reason. Borrowing
+ *   `bandContent` to fake the position is the workaround #VS-17 rejected.
+ */
+export const PermissionsAllowScreen = forwardRef(({ strings, screenId = 'permissions-allow', showHeader = false, overrides, onAction, ...shell }, ref) => (_jsx(PrizmaResultScreen, { ref: ref, showHeader: showHeader, status: "warning", title: strings.allow.title, subtitle: strings.allow.subtitle, ctaLabel: strings.allow.ctaLabel, linkLabel: strings.allow.quitLabel, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: overrides, onAction: onAction, ...shell })));
+PermissionsAllowScreen.displayName = 'PermissionsAllowScreen';
+export default PermissionsAllowScreen;

package/dist/PermissionsBrowserStepsScreen.d.ts

@@ -0,0 +1,42 @@
+import React from 'react';
+import { type PrizmaListScreenProps } from './ListScreen';
+import type { PrizmaScreenActionHandler, PrizmaScreenOverrides } from './types';
+import type { PermissionsBrowser, PermissionsStrings } from './PermissionsStrings';
+import './ScreenLayout.css';
+export interface PermissionsBrowserStepsScreenProps extends Omit<PrizmaListScreenProps, 'status' | 'title' | 'subtitle' | 'children' | 'ctaLabel' | 'linkLabel' | 'verifiedLabel' | 'navLabel'> {
+    /** Family copy — this screen reads the `browserSteps` slice. */
+    strings: PermissionsStrings;
+    /** Which browser's steps to show. Default `safariIos`. */
+    browser?: PermissionsBrowser;
+    screenId?: string;
+    overrides?: PrizmaScreenOverrides;
+    onAction?: PrizmaScreenActionHandler;
+}
+/**
+ * Permissions — "Follow the next steps to allow Incode to access your camera",
+ * built on the List archetype (GUIDELINES.md §6-G, `PrizmaListScreen`).
+ *
+ * Figma: `1-4-2-id` of the `Permissions` section, plus the four
+ * `Android browsers` frames of the Web full-flow board (4:8159 — Chrome,
+ * Firefox, Samsung Internet, Opera). ONE screen for all five: they draw the
+ * identical skeleton — title block → a step list filling the middle → the
+ * refresh CTA — and differ only in the rows, because re-enabling the camera is
+ * a different journey in each browser. Five files would have been five chances
+ * to drift.
+ *
+ * The rows are Core's `PrizmaCardListCommonIssues` verbatim; only the leading
+ * glyph is chosen here, from the canonical bank (see `STEP_ICONS`).
+ *
+ * The title block is LEFT-aligned for this whole family. Every frame starts the
+ * two-line headline flush at the gutter over left-led step rows; a centred
+ * headline above a left-aligned list reads as a mistake. The screen therefore
+ * DEFAULTS the archetype's own `align` override to `left` rather than declaring
+ * any alignment of its own, and a host that passes `overrides.align` still wins.
+ *
+ * One thing Figma draws that this screen does not: **mixed weight inside a
+ * row.** Figma bolds the actionable fragment ("Tap **Three dots** in the top
+ * right"); Core's row `title` is a plain `string`, so the sentence renders in
+ * one weight. Core request already open from Geolocation: a `ReactNode` title.
+ */
+export declare const PermissionsBrowserStepsScreen: React.ForwardRefExoticComponent<PermissionsBrowserStepsScreenProps & React.RefAttributes<HTMLDivElement>>;
+export default PermissionsBrowserStepsScreen;

package/dist/PermissionsBrowserStepsScreen.js

@@ -0,0 +1,86 @@
+'use client';
+import { jsx as _jsx } from "react/jsx-runtime";
+import { forwardRef } from 'react';
+import { IconArrowLeft, IconCamera, IconFolderFileOpen, IconLock, IconLockCheck, IconMobilePhone, IconNumberedList, IconTextAi, } from '@incodetech/prizma-core-icons';
+import { PrizmaCardListCommonIssues } from '@incodetech/prizma-core-web/card-list';
+import { PrizmaListScreen } from './ListScreen';
+import './ScreenLayout.css';
+/**
+ * Step kind → canonical bank glyph. ONE map, in one place, for the same reason
+ * Geolocation's exists (`GeolocationBrowserStepsScreen`) and Document Capture's
+ * before it (DEVIATIONS #DC-23): Figma leads every row with OS/browser chrome
+ * the Prizma bank does not ship — a ⋮ overflow menu, a gear tile, a permission
+ * toggle, Safari's "AA" control and each browser's own logo on the last row.
+ * Shipping those would mean inventing primitives and bundling brand rasters,
+ * both forbidden (rule 1, GUIDELINES §10), so each row takes the nearest
+ * canonical glyph:
+ *
+ *   settings    → IconLock            site settings sit behind the address-bar lock
+ *   browser     → IconTextAi          Safari's "AA" is the address-bar text control
+ *   menu        → IconNumberedList    the ⋮ overflow opens a menu list
+ *   permissions → IconLockCheck       a granted permission
+ *   camera      → IconCamera          exact
+ *   toggle      → IconLockCheck       the Allow/Ask switch
+ *   device      → IconMobilePhone     the device's Settings app
+ *   apps        → IconFolderFileOpen  the app list / app drawer
+ *   return      → IconArrowLeft       "return here and refresh" (Figma draws the
+ *                                     browser's own logo — never bundled)
+ *
+ * This is the SAME substitution table Geolocation already escalated to the
+ * owner, extended by `camera`/`toggle`/`browser` for this family. Mint the
+ * glyphs or bless the substitutions — one decision covers both families.
+ */
+const STEP_ICONS = {
+    settings: _jsx(IconLock, { size: "m" }),
+    browser: _jsx(IconTextAi, { size: "m" }),
+    menu: _jsx(IconNumberedList, { size: "m" }),
+    permissions: _jsx(IconLockCheck, { size: "m" }),
+    camera: _jsx(IconCamera, { size: "m" }),
+    toggle: _jsx(IconLockCheck, { size: "m" }),
+    device: _jsx(IconMobilePhone, { size: "m" }),
+    apps: _jsx(IconFolderFileOpen, { size: "m" }),
+    return: _jsx(IconArrowLeft, { size: "m" }),
+};
+/**
+ * Permissions — "Follow the next steps to allow Incode to access your camera",
+ * built on the List archetype (GUIDELINES.md §6-G, `PrizmaListScreen`).
+ *
+ * Figma: `1-4-2-id` of the `Permissions` section, plus the four
+ * `Android browsers` frames of the Web full-flow board (4:8159 — Chrome,
+ * Firefox, Samsung Internet, Opera). ONE screen for all five: they draw the
+ * identical skeleton — title block → a step list filling the middle → the
+ * refresh CTA — and differ only in the rows, because re-enabling the camera is
+ * a different journey in each browser. Five files would have been five chances
+ * to drift.
+ *
+ * The rows are Core's `PrizmaCardListCommonIssues` verbatim; only the leading
+ * glyph is chosen here, from the canonical bank (see `STEP_ICONS`).
+ *
+ * The title block is LEFT-aligned for this whole family. Every frame starts the
+ * two-line headline flush at the gutter over left-led step rows; a centred
+ * headline above a left-aligned list reads as a mistake. The screen therefore
+ * DEFAULTS the archetype's own `align` override to `left` rather than declaring
+ * any alignment of its own, and a host that passes `overrides.align` still wins.
+ *
+ * One thing Figma draws that this screen does not: **mixed weight inside a
+ * row.** Figma bolds the actionable fragment ("Tap **Three dots** in the top
+ * right"); Core's row `title` is a plain `string`, so the sentence renders in
+ * one weight. Core request already open from Geolocation: a `ReactNode` title.
+ */
+export const PermissionsBrowserStepsScreen = forwardRef(({ strings, browser = 'safariIos', screenId = `permissions-browser-steps-${browser}`, showHeader = false, overrides, onAction, ...shell }, ref) => {
+    const slice = strings.browserSteps.browsers[browser];
+    /* Family default, not a local re-declaration: the archetype already owns a
+       left variant, so the screen only picks which of ITS variants this family
+       uses. An explicit `overrides.align` from the host still wins. */
+    const alignedOverrides = {
+        ...overrides,
+        align: overrides?.align ?? 'left',
+    };
+    return (_jsx(PrizmaListScreen, { ref: ref, showHeader: showHeader, title: strings.browserSteps.title, subtitle: slice?.label, ctaLabel: strings.browserSteps.ctaLabel, verifiedLabel: strings.verifiedLabel, navLabel: strings.navLabel, screenId: screenId, overrides: alignedOverrides, onAction: onAction, ...shell, children: _jsx(PrizmaCardListCommonIssues, { items: (slice?.steps ?? []).map((step) => ({
+                icon: STEP_ICONS[step.kind],
+                title: step.label,
+                showSubtitle: false,
+            })) }) }));
+});
+PermissionsBrowserStepsScreen.displayName = 'PermissionsBrowserStepsScreen';
+export default PermissionsBrowserStepsScreen;