@nanisoft/prism-ui 0.13.0 → 0.16.0

package/dist/blocks/user-profile-01/user-profile-01.js

@@ -0,0 +1,158 @@
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { Avatar, AvatarFallback, AvatarImage } from '../../components/ui/avatar.js';
+import { FactList } from '../../components/ui/fact-list.js';
+import { Section, SectionHeading } from '../../components/ui/section.js';
+import { Separator } from '../../components/ui/separator.js';
+import { cn } from '../../lib/utils.js';
+/**
+ * The initials a name produces, and the rule that produces them.
+ *
+ * Two letters from the first and last words, and the first two characters of a
+ * single word. It is the same rule `AvatarGroup`, `Team01` and `MemberList01` each
+ * apply, repeated rather than imported, and the boundary is the reason: that
+ * helper is private to its module, and exporting it would make a private
+ * derivation part of a published surface in order to save six lines in a Block.
+ * The cost is stated rather than hidden: four modules now carry this rule, so a
+ * change to it is a change in four places, and a caller who needs a case the rule
+ * does not cover composes `Avatar` themselves and passes their own node.
+ */
+function initialsOf(name) {
+    const words = name.trim().split(/\s+/).filter(Boolean);
+    const first = words[0];
+    if (first === undefined)
+        return '';
+    if (words.length === 1)
+        return first.slice(0, 2).toUpperCase();
+    return `${first.charAt(0)}${words[words.length - 1].charAt(0)}`.toUpperCase();
+}
+/**
+ * One person in full: a portrait where there is one, a name, a role, a biography,
+ * a set of facts, the caller's own controls, and room for the caller's own
+ * sections underneath.
+ *
+ * **This is a Block and not a Card, and not `MemberList01`, and the three facts
+ * that separate them are all about how many people are on the page and why the
+ * reader came.** A profile is one person in full and the reader arrived for them:
+ * they followed a link, they opened a record, they are looking at the one subject
+ * the page is about, and everything on it is about that person. A member list is
+ * many people and the reader is looking for one, which is the opposite reading
+ * order: the reader scans a column of names and stops at one, so a member list is
+ * optimised for scanning and a profile is optimised for reading. A card is a
+ * bounded group of related content, and a profile is not a group: it has one
+ * subject, and a subject in a frame reads as a set of facts about a thing rather
+ * than as the thing. The three are separately the right answers to three different
+ * pages, and a Block that blurred them would be a Block whose weight was wrong for
+ * whichever page used it.
+ *
+ * **The facts compose `FactList` rather than being drawn as a definition list
+ * here, and the reason is the empty case, quoted from the Component: "An empty
+ * list renders nothing rather than an empty frame, so a caller that has nothing to
+ * say does not get a bordered box with a title above it."** A profile is very
+ * often a person with three facts and also a person with none, and the second case
+ * is not a defect to be papered over with a placeholder row; it is a person whose
+ * whole profile is a name. `FactList` draws the real `<dl>` with the term before its
+ * answer, which is what a specification is and what a pair of columns is not, and
+ * it draws the hairlines and the alignment that a hand-rolled version gets subtly
+ * wrong. Writing a second definition list here would put a second answer to "how
+ * does a set of facts read" in one package, and the second answer is always the one
+ * that disagrees. The cost is stated rather than hidden: `FactList` keys its own
+ * rows by position, so a caller whose facts reorder between renders and who needs
+ * row identity composes the Component directly rather than passing them here.
+ *
+ * **The portrait is a slot and no mark is drawn in its place, because a fallback
+ * which is a person-shaped glyph is a claim about a person this system knows
+ * nothing about.** A silhouette says there is a person here, which is true, and it
+ * says it identically about every reader of every product that installs this
+ * Block, so a reader who has seen four of them has learned nothing about any of
+ * them. The fallback that ships is the person's own initials, derived from the
+ * caller's data by a rule this file repeats rather than imports, so a reader who
+ * cannot see the photograph still recognises the name printed beside it. Omit
+ * `avatar` entirely and nothing is drawn where the portrait would be, which is the
+ * honest state: a person the caller has no photograph of is still a person, and a
+ * grey disc is a claim that the absence is a gap.
+ *
+ * **The name is the section heading and not a line in the body, and that is the
+ * decision the rest of the Block follows from.** A page whose only subject is one
+ * person is a page a reader reaches by following a link and navigates away from by
+ * heading, so a name in a `span` is a name no reader can come back to. It also
+ * settles the arrangement: the name is at `headingLevel`, the role is the
+ * supporting line under it, and the facts are the answers to questions the reader
+ * did not arrive with, which is why they are a definition list and not more
+ * headings. The cost is that the section heading is the person's name, so a page
+ * with two profiles on it has two sections whose titles are people, and a
+ * consumer who wants a page titled by the product instead composes the profile
+ * inside their own `Section` rather than using this one.
+ *
+ * **`actions` and `tabs` are slots, and both are refused as anything else.** The
+ * controls that belong to a person rather than to the page are the caller's fact:
+ * follow, message, assign and remove are four different products' ideas, and a
+ * Block that drew one of them would be drawing a workflow. Tabs are worse, because
+ * a tab strip is a behaviour as much as a look: which sections exist, which one is
+ * showing, and what happens when the reader changes it are three decisions about
+ * the caller's application, and a Block that drew the strip would have to own all
+ * three for it to work. So the space is here, a rule is drawn above it, and
+ * `Tabs` is the caller's to compose. The cost is that this Block does not enforce
+ * a relationship between the two, and a caller who passes neither gets a profile
+ * with a facts list and nothing else, which is a valid page.
+ *
+ * **There is no motion in this Block, and the reason is worth stating because the
+ * absence is a decision rather than an oversight.** The first law of motion covers
+ * feedback, which is a response to something the reader did, and a profile has
+ * nothing the reader pressed: there is no control that opens, no panel that
+ * closes, and no row that changes state. The second law covers a cycle, which is a
+ * demonstration of a mechanism, and the test that decides which law a motion falls
+ * under is falsifiable: stop the animation, is the figure still true and still
+ * legible? There is no figure here at all, so the question does not arise, and a
+ * Block that answered it by animating the portrait in would be decoration wearing
+ * the costume of a demonstration, which is the thing the first law was written to
+ * exclude. The one place a transition could honestly go is the caller's own
+ * controls, and those are the caller's Components with their own motion already
+ * settled.
+ *
+ * It is a server Component: no hook, no state, no effect and no client code of its
+ * own. The portrait is `Avatar`, which is a client Component whose only client work
+ * is measuring whether an image has loaded, so a profile costs a consumer nothing
+ * in client JavaScript beyond that and a caller composing a client `actions` slot
+ * pays for the action rather than for the profile.
+ */
+export function UserProfile01({ name, role, bio, avatar, facts, actions, tabs, layout = 'header', headingLevel = 'h2', className, }) {
+    const beside = layout === 'header';
+    return (_jsx(Section, { "data-slot": "user-profile-01", className: cn(className), children: _jsxs("div", { "data-slot": "user-profile-01-body", "data-layout": layout, className: cn('flex flex-col gap-8', 
+            // The narrow arrangement is the one that needs a bound of its own, because
+            // the wide one is already inside the container `Section` owns. `max-w-*`
+            // is a bound token and not an arbitrary width, which is the whole of what
+            // the layout gate allows in this position.
+            beside ? null : 'max-w-measure-narrow'), children: [_jsxs("div", { "data-slot": "user-profile-01-head", className: cn('flex flex-col gap-6', beside ? 'sm:flex-row sm:items-start sm:gap-6' : 'items-start'), children: [avatar === undefined ? null : (
+                        /*
+                         * The portrait, and the only place in this Block a client Component is
+                         * composed. `size-20` rather than a size the caller chooses, because a
+                         * profile's portrait is the one image on the page and its size is part
+                         * of what a profile looks like rather than a fact about the person.
+                         * `AvatarImage` takes an empty `alt` because the name is printed beside
+                         * it in the same heading, so an `alt` repeating that name would be the
+                         * same string twice for a reader who meets the image first.
+                         */
+                        _jsxs(Avatar, { "data-slot": "user-profile-01-avatar", className: "size-20 shrink-0", children: [avatar.src === undefined ? null : _jsx(AvatarImage, { src: avatar.src, alt: "" }), _jsx(AvatarFallback, { className: "text-mono", children: initialsOf(avatar.name) })] })), _jsx(SectionHeading, { as: headingLevel, align: "left", title: name, description: role, className: "min-w-0 flex-1" })] }), bio === undefined ? null : (_jsx("p", { "data-slot": "user-profile-01-bio", className: "text-muted-foreground max-w-measure text-pretty text-sm", children: bio })), facts === undefined ? null : (
+                /*
+                 * The facts, composed and not derived. `FactList` renders nothing at all
+                 * for an empty list, which is the case this Block leans on hardest: a
+                 * person with no facts gets a name and a role and no box where facts
+                 * would have been. The mapping exists only because this Block's fact has
+                 * an `id` for the caller's data and `Fact` has no use for one.
+                 */
+                _jsx(FactList, { "data-slot": "user-profile-01-facts", facts: facts.map((fact) => ({ label: fact.label, value: fact.value })) })), actions === undefined ? null : (
+                /*
+                 * The caller's own controls, in a plain row with no role. A group role
+                 * here would be a group with no name and one more thing a reader has to
+                 * walk past, and the controls inside are the controls.
+                 */
+                _jsx("div", { "data-slot": "user-profile-01-actions", className: "flex flex-wrap items-center gap-3", children: actions })), tabs === undefined ? null : (
+                /*
+                 * The caller's own sections, under a rule rather than inside a strip.
+                 * The rule is decorative and says so by default, which is right: it
+                 * separates two blocks of the caller's own content and does not express
+                 * a separation a keyboard reader needs to know about.
+                 */
+                _jsxs("div", { "data-slot": "user-profile-01-sections", className: "flex flex-col gap-6", children: [_jsx(Separator, { "data-slot": "user-profile-01-rule" }), tabs] }))] }) }));
+}
+export default UserProfile01;

package/dist/blocks/verify-email-01/index.d.ts

@@ -0,0 +1,3 @@
+export { VerifyEmail01, default } from './verify-email.js';
+export type { VerifyEmail01Help, VerifyEmail01Outcome, VerifyEmail01Props, VerifyEmail01Status, VerifyEmail01Target, } from './verify-email.js';
+//# sourceMappingURL=index.d.ts.map

package/dist/blocks/verify-email-01/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../src/blocks/verify-email-01/index.tsx"],"names":[],"mappings":"AAAA,OAAO,EAAE,aAAa,EAAE,OAAO,EAAE,MAAM,gBAAgB,CAAA;AAQvD,YAAY,EACV,iBAAiB,EACjB,oBAAoB,EACpB,kBAAkB,EAClB,mBAAmB,EACnB,mBAAmB,GACpB,MAAM,gBAAgB,CAAA"}

package/dist/blocks/verify-email-01/index.js

@@ -0,0 +1 @@
+export { VerifyEmail01, default } from './verify-email.js';

package/dist/blocks/verify-email-01/verify-email.d.ts

@@ -0,0 +1,262 @@
+import type { ReactNode } from 'react';
+import { type HeadingLevel } from '../../components/ui/section.js';
+/**
+ * The five things that can be true of a verification, and the whole design of the
+ * Block is that there are five of them and each one is a different screen.
+ *
+ * The names say what they select rather than what colour they draw. `checking` is
+ * progress, `verified` is a destination, `pending` is a wait, `failed` is a retry and
+ * `expired` is a request for a new link. Four of the five are states a reader has to
+ * act in, and only one of them is a sentence.
+ */
+export type VerifyEmail01Outcome = 'checking' | 'verified' | 'pending' | 'failed' | 'expired';
+/**
+ * Which of the five the verification is in, what the reader is told, and the short
+ * name of the state.
+ *
+ * **Required on the Block rather than optional on the arm, because on this screen the
+ * state is the screen.** There is no resting state a reader can see and no state this
+ * Block can reach on its own: the link is the proof, and the caller's server is what
+ * knows whether following it proved anything. A caller that renders this without
+ * saying where the verification has got to has drawn the frame and omitted the page.
+ *
+ * `stateLabel` is the short name beside the dot and `message` is the sentence, and
+ * the split is the same one `Status` argues for. With nothing passed for it the
+ * machine value is drawn instead, which is honest and rarely what was wanted: a
+ * product whose readers meet the word `pending` is a product that has not named its
+ * own states yet.
+ */
+export type VerifyEmail01Status = {
+    /** Which of the five the verification is in. Read by the Block for four things. */
+    state: VerifyEmail01Outcome;
+    /** The sentence for that state, in the product's own voice. */
+    message: ReactNode;
+    /** The short name of the state, beside the dot. Falls back to `state`. */
+    stateLabel?: string;
+};
+/**
+ * What is being verified, and the caller's own way to change it.
+ *
+ * The union is what makes the change control mean one thing: a control with words and
+ * no handler draws a button that does nothing, and a handler with no words draws a
+ * button a screen reader announces as "button" and a voice control user cannot say.
+ */
+export type VerifyEmail01Target = {
+    /**
+     * The identifier whose address is in question, drawn on the screen.
+     *
+     * Required, because a verification screen that does not say what is being verified
+     * is a screen where a reader with two addresses has no idea which one arrived. This
+     * is also the reason the screen has no code field: see the Block's JSDoc.
+     */
+    identifier: string;
+    /**
+     * What the caller's product calls the identifier.
+     *
+     * The words beside it rather than its accessible name, because the identifier is
+     * already on the page and is what a reader needs to compare against their own inbox
+     * before they press anything.
+     */
+    identifierLabel?: string;
+} & ({
+    /** The words on the control that opens the caller's own change surface. */
+    changeLabel: string;
+    /** Called with the identifier the reader chose. */
+    onChange: (identifier: string) => void;
+} | {
+    /** A change control with no words is a button nobody can find. */
+    changeLabel?: never;
+    /** A handler with no control is a call the caller cannot make. */
+    onChange?: never;
+});
+/**
+ * The route out for a reader this screen does not help, and where it goes.
+ *
+ * `message` and `label` are separate because they are separate jobs: the message is
+ * the sentence about why the reader is stuck and the label is what following the link
+ * does. A link labelled with the sentence is a link whose visible words do not say
+ * what activating it does, which is a link a voice control user cannot speak.
+ */
+export type VerifyEmail01Help = {
+    /** The sentence about why this screen is not helping, and what else exists. */
+    message: ReactNode;
+    /** The destination, in the `href` where the status bar and the context menu reach it. */
+    href: string;
+    /** The words on the link, and its accessible name. */
+    label: string;
+};
+/**
+ * The props a VerifyEmail01 takes. Every string in this Block is one of them.
+ *
+ * There is no field, no form and no value this Block holds, and that is the shape of
+ * the pattern rather than a limitation of it. The link is the proof; everything this
+ * screen does is report what happened and offer the caller's own next moves.
+ */
+export type VerifyEmail01Props = {
+    /** The short line above the title, usually which product this is. */
+    eyebrow?: ReactNode;
+    /**
+     * The heading.
+     *
+     * Required, because a screen that reports a security decision with no heading is a
+     * sentence in a page, and a reader who has just followed a link from their own inbox
+     * needs to be told which product is speaking before they trust it.
+     */
+    title: ReactNode;
+    /**
+     * What the reader is about to find out.
+     *
+     * **Required, and the difference from every other Block's description is the fact
+     * rather than an inconsistency.** The reader has just been told something was sent
+     * and has arrived here to find out whether it arrived. This is the one screen where
+     * that question has a definite answer and the reader cannot see the answer until the
+     * screen says it, so a frame that can ship without saying what it is about to say
+     * leaves a reader guessing from a tone and a sentence. What the answer says is the
+     * caller's, because what it means to have verified an address in their product is
+     * their fact.
+     */
+    description: ReactNode;
+    /** What is being verified, and the caller's way to verify something else. */
+    target: VerifyEmail01Target;
+    /**
+     * Called when the reader asks for the message to be sent again.
+     *
+     * Required, and the requirement is the design. A verification a reader cannot
+     * re-trigger is a verification that ends in a support ticket, so the control has to
+     * be on the screen and the words have to be the product's own.
+     */
+    onResend: () => void;
+    /** The words on the resend control. */
+    resendLabel: string;
+    /**
+     * The words the same control carries once a resend has been asked for.
+     *
+     * Required rather than optional, because which of the two the control shows is
+     * decided by the state and not by the caller: a state that can move into a resend
+     * cannot be known at the moment the props are written, and a control that keeps
+     * saying it will send the message while it is sending it has stopped agreeing with
+     * itself. See the Block's JSDoc for the exact rule.
+     */
+    resentLabel: string;
+    /**
+     * Whether a resend is in flight, which is also how the caller says one has happened.
+     *
+     * The two questions are the same question from where the reader is sitting: the one
+     * control on screen should either offer the resend or report that it is under way,
+     * and never do both at once.
+     */
+    resending?: boolean;
+    /**
+     * The words for the wait, drawn under the resend control once one has been asked
+     * for.
+     *
+     * A prop because the length of the wait is the caller's own rate limit. A Block that
+     * guessed it would be shipping one cooldown policy to every product that installs
+     * it, in a place no consumer can read it.
+     */
+    cooldownLabel?: string;
+    /** Where the verification has got to, in the caller's own words. */
+    status: VerifyEmail01Status;
+    /**
+     * The caller's own next moves, drawn under the resend control in every state.
+     *
+     * A slot rather than a set of named controls, because what a reader does next on this
+     * screen is a fact about the caller's product: open another inbox, sign in, contact
+     * an administrator, ask a colleague to resend.
+     */
+    actions?: ReactNode;
+    /** The route out for a reader this screen does not help. */
+    help?: VerifyEmail01Help;
+    /** Heading level for the section heading. @defaultValue 'h2' */
+    headingLevel?: HeadingLevel;
+    /**
+     * Layout only, exactly as on every Block. Changing a Prism-owned visual property
+     * from here is prohibited.
+     */
+    className?: string;
+};
+/**
+ * What is being verified, where it has got to, and the caller's own way to ask again.
+ *
+ * **The translation, because the pattern is not ours and the framing is.** A
+ * storefront publishes a confirm-your-email screen: the address it was sent to, a
+ * line that says to check your inbox, and a button that sends it again, and its
+ * purpose is to let a shopper reach an order history and a saved card. Prism's
+ * products observe a pipeline, capture a market, watch an estate and run agents, and a
+ * machine acting on behalf of a person is the whole subject, so this is the screen
+ * where a person proves they read what a machine sent them, because the address on
+ * file is the address an operator's actions will be attributed to. The composition is
+ * the storefront's and is unchanged: the address, the outcome, a resend. What is
+ * different is the standard, and that is the next paragraph.
+ *
+ * **What it assumes about the reader in front of it, because this is the screen where
+ * the cost of an assumption is highest.** It assumes they followed a link, that the
+ * link came from the product they expect, and that they are waiting. It refuses to
+ * assume they can tell from a sentence what has happened to them, and it refuses to
+ * assume they will read a tone correctly, or that they will try again patiently
+ * rather than immediately, or that they know the difference between the five states
+ * this screen can be in.
+ *
+ * **The five states are five screens and not five messages, and that is the design.**
+ * `checking` is progress: something is happening and the reader's job is to wait.
+ * `verified` is a destination: the work is finished and the reader's job is to leave.
+ * `pending` is a wait: nothing has gone wrong and the reader's job is to keep an eye
+ * on an inbox. `failed` is a retry: something the reader just did did not work.
+ * `expired` is a request for a new link: the one that arrived is dead and another is
+ * needed. A screen that drew any of these as a sentence in the middle of a form would
+ * be asking a reader to work out what has happened from a sentence, and a reader who
+ * cannot tell whether their address is verified will try again, and a second attempt
+ * on a verification is a second attempt on a machine's authorisation and eventually a
+ * lockout. So each state changes the arrangement: which indicator is drawn, whether
+ * the resend is offered, and how insistently the outcome is announced.
+ *
+ * **There is no code field on this screen, and the reason is one sentence: the link is
+ * the proof, and a field invites a reader to type a code they do not have.** A reader
+ * who arrives without the link has one action available to them and it is asking for
+ * another one, and a field in front of them invites them to type the six characters
+ * they can half remember from a text they did not read. Prisms that render a code
+ * field on a link-based verification are answering a product that sends codes.
+ *
+ * **`stateLabel` falls back to the machine value rather than to nothing, and the cost
+ * of that is named.** A dot with no name beside it is a colour a reader cannot read,
+ * and `Status` refuses to render one, so there has to be something. The machine value
+ * is the honest something: a product whose readers meet the word `pending` is a
+ * product that has not named its own states, and seeing its own key on the screen is
+ * a faster way to find that out than shipping it.
+ *
+ * **`resentLabel` is required and the rule that uses it is about the state rather than
+ * about the caller.** The resend control is drawn for a wait, a failure and an expiry,
+ * and withheld for progress and for the destination, because a control with nothing to
+ * do is a control a reader presses to find out what happens. While `resending` is
+ * true the control is disabled and carries `resentLabel`, because a control that keeps
+ * offering to do the thing it is currently doing has stopped agreeing with itself. The
+ * cooldown is the caller's own line beside it, because the length of the wait is a
+ * rate limit and a Block that guessed one would be shipping one policy to four
+ * products in a place no consumer can read it.
+ *
+ * **The announcement is assertive only for the two states where something the reader
+ * did did not work.** A confirmation and a wait are things a reader can take in order,
+ * and a progress reading is the last thing that should interrupt a sentence; a failure
+ * and an expiry are the answer to the thing they just clicked and nothing else
+ * follows, which is the case `LiveRegion` names as the one that interrupts.
+ *
+ * **There is no form, no `<form>` element and no value this Block holds, and the
+ * absence is the pattern.** The link carried the proof and the caller's server knows
+ * whether it proved anything, so the only things left to draw are what happened and
+ * the reader's own next moves. The change control is a `Button` rather than a dialog
+ * because where a new identifier is typed is a fact about the caller's product, and a
+ * Block that opened a dialog would have to own that field's label, its description and
+ * its sentences.
+ *
+ * It is a client Component, and the directive is unconditional even though it holds no
+ * state of its own. `onResend` and `onChange` are functions, a function is a piece of
+ * state, and state is a client module: a server Component cannot hand an event handler
+ * to a `<button>`, so a caller rendering this from a server Component gets a screen
+ * whose controls press and do nothing. The cost is a module in the client graph whose
+ * static arrangement would have shipped no JavaScript at all, and the price was judged
+ * worth paying for one boundary rather than a split where the reporting half is a
+ * server Component and the controls half is not.
+ */
+export declare function VerifyEmail01({ eyebrow, title, description, target, onResend, resendLabel, resentLabel, resending, cooldownLabel, status, actions, help, headingLevel, className, }: VerifyEmail01Props): import("react").JSX.Element;
+export default VerifyEmail01;
+//# sourceMappingURL=verify-email.d.ts.map

package/dist/blocks/verify-email-01/verify-email.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"verify-email.d.ts","sourceRoot":"","sources":["../../../src/blocks/verify-email-01/verify-email.tsx"],"names":[],"mappings":"AAEA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,OAAO,CAAA;AAMtC,OAAO,EAA2B,KAAK,YAAY,EAAE,MAAM,6BAA6B,CAAA;AAKxF;;;;;;;;GAQG;AACH,MAAM,MAAM,oBAAoB,GAC5B,UAAU,GACV,UAAU,GACV,SAAS,GACT,QAAQ,GACR,SAAS,CAAA;AAEb;;;;;;;;;;;;;;;GAeG;AACH,MAAM,MAAM,mBAAmB,GAAG;IAChC,mFAAmF;IACnF,KAAK,EAAE,oBAAoB,CAAA;IAC3B,+DAA+D;IAC/D,OAAO,EAAE,SAAS,CAAA;IAClB,0EAA0E;IAC1E,UAAU,CAAC,EAAE,MAAM,CAAA;CACpB,CAAA;AAED;;;;;;GAMG;AACH,MAAM,MAAM,mBAAmB,GAAG;IAChC;;;;;;OAMG;IACH,UAAU,EAAE,MAAM,CAAA;IAClB;;;;;;OAMG;IACH,eAAe,CAAC,EAAE,MAAM,CAAA;CACzB,GAAG,CACA;IACE,2EAA2E;IAC3E,WAAW,EAAE,MAAM,CAAA;IACnB,mDAAmD;IACnD,QAAQ,EAAE,CAAC,UAAU,EAAE,MAAM,KAAK,IAAI,CAAA;CACvC,GACD;IACE,kEAAkE;IAClE,WAAW,CAAC,EAAE,KAAK,CAAA;IACnB,kEAAkE;IAClE,QAAQ,CAAC,EAAE,KAAK,CAAA;CACjB,CACJ,CAAA;AAED;;;;;;;GAOG;AACH,MAAM,MAAM,iBAAiB,GAAG;IAC9B,+EAA+E;IAC/E,OAAO,EAAE,SAAS,CAAA;IAClB,yFAAyF;IACzF,IAAI,EAAE,MAAM,CAAA;IACZ,sDAAsD;IACtD,KAAK,EAAE,MAAM,CAAA;CACd,CAAA;AAED;;;;;;GAMG;AACH,MAAM,MAAM,kBAAkB,GAAG;IAC/B,qEAAqE;IACrE,OAAO,CAAC,EAAE,SAAS,CAAA;IACnB;;;;;;OAMG;IACH,KAAK,EAAE,SAAS,CAAA;IAChB;;;;;;;;;;;OAWG;IACH,WAAW,EAAE,SAAS,CAAA;IACtB,6EAA6E;IAC7E,MAAM,EAAE,mBAAmB,CAAA;IAC3B;;;;;;OAMG;IACH,QAAQ,EAAE,MAAM,IAAI,CAAA;IACpB,uCAAuC;IACvC,WAAW,EAAE,MAAM,CAAA;IACnB;;;;;;;;OAQG;IACH,WAAW,EAAE,MAAM,CAAA;IACnB;;;;;;OAMG;IACH,SAAS,CAAC,EAAE,OAAO,CAAA;IACnB;;;;;;;OAOG;IACH,aAAa,CAAC,EAAE,MAAM,CAAA;IACtB,oEAAoE;IACpE,MAAM,EAAE,mBAAmB,CAAA;IAC3B;;;;;;OAMG;IACH,OAAO,CAAC,EAAE,SAAS,CAAA;IACnB,4DAA4D;IAC5D,IAAI,CAAC,EAAE,iBAAiB,CAAA;IACxB,gEAAgE;IAChE,YAAY,CAAC,EAAE,YAAY,CAAA;IAC3B;;;OAGG;IACH,SAAS,CAAC,EAAE,MAAM,CAAA;CACnB,CAAA;AAwGD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiFG;AACH,wBAAgB,aAAa,CAAC,EAC5B,OAAO,EACP,KAAK,EACL,WAAW,EACX,MAAM,EACN,QAAQ,EACR,WAAW,EACX,WAAW,EACX,SAAiB,EACjB,aAAa,EACb,MAAM,EACN,OAAO,EACP,IAAI,EACJ,YAAmB,EACnB,SAAS,GACV,EAAE,kBAAkB,+BAgLpB;AAED,eAAe,aAAa,CAAA"}

package/dist/blocks/verify-email-01/verify-email.js

@@ -0,0 +1,190 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
+import { Button } from '../../components/ui/button.js';
+import { Card } from '../../components/ui/card.js';
+import { CtaLink } from '../../components/ui/cta-link.js';
+import { LiveRegion } from '../../components/ui/live-region.js';
+import { Section, SectionHeading } from '../../components/ui/section.js';
+import { Spinner } from '../../components/ui/spinner.js';
+import { Status } from '../../components/ui/status.js';
+import { cn } from '../../lib/utils.js';
+/**
+ * The tone each state takes, taken from `StatusTone` rather than invented.
+ *
+ * **`neutral` is the tone that asserts least, and `pending` is the state that gets
+ * it.** A reader who has just followed a link is in the middle of an action they took
+ * and the honest reading of the next two seconds is that nothing has gone wrong. A
+ * destructive dot on a wait is a claim about the reader's account made by a colour,
+ * before any evidence exists, and the reader who believes it is the one who goes and
+ * looks for the problem somewhere else.
+ *
+ * The other four are chosen because each is a different kind of fact. `checking` is
+ * work in progress, so it borrows the informational tone. `verified` is the only
+ * success this screen has, so it takes the success role. `expired` is not a failure:
+ * the link died, the reader's address may be perfectly good, and the thing they have
+ * to do about it is ask for a new one, so it takes the warning role rather than the
+ * destructive one. `failed` is the only destructive state, because it is the only one
+ * where something the reader just did did not work.
+ */
+const STATE_TONE = {
+    checking: 'info',
+    verified: 'success',
+    pending: 'neutral',
+    failed: 'destructive',
+    expired: 'warning',
+};
+/**
+ * The three states a reader can be asked for another message from, and the two they
+ * cannot.
+ *
+ * A progress reading and a destination have nothing to resend, and a control with
+ * nothing to do is a control a reader presses to find out what happens. So the
+ * resend is drawn for a wait, a failure and an expiry, which are the three states
+ * where a second message is the reader's next move.
+ */
+const RESENDABLE = ['pending', 'failed', 'expired'];
+/** Whether a caller passed a word that is not there. Read about the value, not the type. */
+function blank(value) {
+    return value === undefined || value.trim() === '';
+}
+/**
+ * The six refusals, checked before anything is drawn so a caller's mistake is one
+ * diagnostic in a console rather than a nameless control on the screen where a reader
+ * has just followed a link from their own inbox and is waiting to find out whether it
+ * worked.
+ */
+function assertVerify(input) {
+    const { target, status, resendLabel, resentLabel, help } = input;
+    if (blank(target.identifier)) {
+        throw new Error('VerifyEmail01: the target declares no identifier, so the screen would report the state of a verification ' +
+            'without saying what is being verified, and a reader with two addresses has no way to know which one ' +
+            'arrived. Pass the identifier the caller\'s own product prints.');
+    }
+    if ((target.changeLabel === undefined) !== (target.onChange === undefined) ||
+        (target.onChange !== undefined && blank(target.changeLabel))) {
+        throw new Error('VerifyEmail01: the target was passed one half of its change control, so the screen would either offer ' +
+            'a button that does nothing or call a handler no control can reach, and a button with no words is ' +
+            'announced as "button" and cannot be spoken by a voice control. Pass changeLabel and onChange ' +
+            'together, or neither.');
+    }
+    if (blank(resendLabel) || blank(resentLabel)) {
+        throw new Error('VerifyEmail01: the resend control is missing one of its two labels. A control with no name is announced ' +
+            'as a button, and this is the one control on the screen a reader reaches who cannot get into their ' +
+            'account. Pass both labels in your own language.');
+    }
+    if (status.stateLabel !== undefined && blank(status.stateLabel)) {
+        throw new Error('VerifyEmail01: stateLabel was passed with no words, so the dot beside it would be a colour with no name ' +
+            'beside it, which is exactly the thing a Status refuses to render. Pass the name of the state or ' +
+            'nothing.');
+    }
+    if (help !== undefined && blank(help.label)) {
+        throw new Error(`VerifyEmail01: the help link to ${JSON.stringify(help.href)} declares no label, so the anchor accessible ` +
+            'name would be its destination, which a screen reader reads as a run of characters and a mouse reader ' +
+            'cannot copy. Pass the sentence that says what following it does.');
+    }
+}
+/**
+ * What is being verified, where it has got to, and the caller's own way to ask again.
+ *
+ * **The translation, because the pattern is not ours and the framing is.** A
+ * storefront publishes a confirm-your-email screen: the address it was sent to, a
+ * line that says to check your inbox, and a button that sends it again, and its
+ * purpose is to let a shopper reach an order history and a saved card. Prism's
+ * products observe a pipeline, capture a market, watch an estate and run agents, and a
+ * machine acting on behalf of a person is the whole subject, so this is the screen
+ * where a person proves they read what a machine sent them, because the address on
+ * file is the address an operator's actions will be attributed to. The composition is
+ * the storefront's and is unchanged: the address, the outcome, a resend. What is
+ * different is the standard, and that is the next paragraph.
+ *
+ * **What it assumes about the reader in front of it, because this is the screen where
+ * the cost of an assumption is highest.** It assumes they followed a link, that the
+ * link came from the product they expect, and that they are waiting. It refuses to
+ * assume they can tell from a sentence what has happened to them, and it refuses to
+ * assume they will read a tone correctly, or that they will try again patiently
+ * rather than immediately, or that they know the difference between the five states
+ * this screen can be in.
+ *
+ * **The five states are five screens and not five messages, and that is the design.**
+ * `checking` is progress: something is happening and the reader's job is to wait.
+ * `verified` is a destination: the work is finished and the reader's job is to leave.
+ * `pending` is a wait: nothing has gone wrong and the reader's job is to keep an eye
+ * on an inbox. `failed` is a retry: something the reader just did did not work.
+ * `expired` is a request for a new link: the one that arrived is dead and another is
+ * needed. A screen that drew any of these as a sentence in the middle of a form would
+ * be asking a reader to work out what has happened from a sentence, and a reader who
+ * cannot tell whether their address is verified will try again, and a second attempt
+ * on a verification is a second attempt on a machine's authorisation and eventually a
+ * lockout. So each state changes the arrangement: which indicator is drawn, whether
+ * the resend is offered, and how insistently the outcome is announced.
+ *
+ * **There is no code field on this screen, and the reason is one sentence: the link is
+ * the proof, and a field invites a reader to type a code they do not have.** A reader
+ * who arrives without the link has one action available to them and it is asking for
+ * another one, and a field in front of them invites them to type the six characters
+ * they can half remember from a text they did not read. Prisms that render a code
+ * field on a link-based verification are answering a product that sends codes.
+ *
+ * **`stateLabel` falls back to the machine value rather than to nothing, and the cost
+ * of that is named.** A dot with no name beside it is a colour a reader cannot read,
+ * and `Status` refuses to render one, so there has to be something. The machine value
+ * is the honest something: a product whose readers meet the word `pending` is a
+ * product that has not named its own states, and seeing its own key on the screen is
+ * a faster way to find that out than shipping it.
+ *
+ * **`resentLabel` is required and the rule that uses it is about the state rather than
+ * about the caller.** The resend control is drawn for a wait, a failure and an expiry,
+ * and withheld for progress and for the destination, because a control with nothing to
+ * do is a control a reader presses to find out what happens. While `resending` is
+ * true the control is disabled and carries `resentLabel`, because a control that keeps
+ * offering to do the thing it is currently doing has stopped agreeing with itself. The
+ * cooldown is the caller's own line beside it, because the length of the wait is a
+ * rate limit and a Block that guessed one would be shipping one policy to four
+ * products in a place no consumer can read it.
+ *
+ * **The announcement is assertive only for the two states where something the reader
+ * did did not work.** A confirmation and a wait are things a reader can take in order,
+ * and a progress reading is the last thing that should interrupt a sentence; a failure
+ * and an expiry are the answer to the thing they just clicked and nothing else
+ * follows, which is the case `LiveRegion` names as the one that interrupts.
+ *
+ * **There is no form, no `<form>` element and no value this Block holds, and the
+ * absence is the pattern.** The link carried the proof and the caller's server knows
+ * whether it proved anything, so the only things left to draw are what happened and
+ * the reader's own next moves. The change control is a `Button` rather than a dialog
+ * because where a new identifier is typed is a fact about the caller's product, and a
+ * Block that opened a dialog would have to own that field's label, its description and
+ * its sentences.
+ *
+ * It is a client Component, and the directive is unconditional even though it holds no
+ * state of its own. `onResend` and `onChange` are functions, a function is a piece of
+ * state, and state is a client module: a server Component cannot hand an event handler
+ * to a `<button>`, so a caller rendering this from a server Component gets a screen
+ * whose controls press and do nothing. The cost is a module in the client graph whose
+ * static arrangement would have shipped no JavaScript at all, and the price was judged
+ * worth paying for one boundary rather than a split where the reporting half is a
+ * server Component and the controls half is not.
+ */
+export function VerifyEmail01({ eyebrow, title, description, target, onResend, resendLabel, resentLabel, resending = false, cooldownLabel, status, actions, help, headingLevel = 'h2', className, }) {
+    assertVerify({ target, status, resendLabel, resentLabel, help });
+    const busy = resending || status.state === 'checking';
+    const resendable = RESENDABLE.includes(status.state);
+    /*
+     * The ring is drawn only when the caller supplied the words to name it, and the
+     * reason is `Spinner`'s own: a busy indicator with no name is an animation, and an
+     * animation is nothing to a reader who cannot see it. So `checking` falls back to
+     * the informational dot rather than to an unnamed ring, which is the same fact
+     * reported in a way that needs no name.
+     */
+    const working = status.state === 'checking';
+    return (_jsx(Section, { "data-slot": "verify-email-01", className: cn(className), children: _jsxs("div", { "data-slot": "verify-email-01-body", className: "flex flex-col gap-10", children: [_jsx(SectionHeading, { as: headingLevel, align: "left", eyebrow: eyebrow, title: title, description: description }), _jsxs(Card, { "data-slot": "verify-email-01-card", className: "max-w-measure-narrow gap-0 px-6", children: [_jsxs("div", { "data-slot": "verify-email-01-target", className: "flex flex-col gap-2", children: [target.identifierLabel === undefined ? null : (_jsx("span", { "data-slot": "verify-email-01-target-label", className: "text-muted-foreground text-xs font-medium tracking-wide uppercase", children: target.identifierLabel })), _jsxs("div", { className: "flex flex-wrap items-start justify-between gap-x-4 gap-y-2", children: [_jsx("span", { "data-slot": "verify-email-01-identifier", className: "min-w-0 text-sm font-medium break-all", children: target.identifier }), target.changeLabel === undefined ? null : (
+                                        /*
+                                          The caller's way to verify something else. A `Button` and not a
+                                          `CtaLink` because this does not navigate: it opens whatever surface
+                                          the caller's product uses to take a new identifier, and a control that
+                                          changes nothing about the address on screen is not a link to
+                                          somewhere.
+                                        */
+                                        _jsx(Button, { "data-slot": "verify-email-01-change", type: "button", variant: "ghost", size: "sm", onClick: () => target.onChange?.(target.identifier), children: target.changeLabel }))] })] }), _jsxs("div", { "data-slot": "verify-email-01-state", "data-state": status.state, className: "border-border flex flex-col gap-2 rounded-lg border px-4 py-3", children: [working && status.stateLabel !== undefined ? (_jsx(Spinner, { "data-slot": "verify-email-01-spinner", label: status.stateLabel, size: "sm" })) : (_jsx(Status, { "data-slot": "verify-email-01-status-label", tone: STATE_TONE[status.state], label: status.stateLabel ?? status.state, size: "sm" })), _jsx(LiveRegion, { "data-slot": "verify-email-01-status", politeness: status.state === 'failed' || status.state === 'expired' ? 'assertive' : 'polite', busy: busy, className: cn('text-sm text-pretty', status.state === 'failed' ? 'text-destructive font-medium' : ''), children: status.message })] }), _jsxs("div", { "data-slot": "verify-email-01-actions", className: "flex flex-col items-start gap-3", children: [resendable ? (_jsx(Button, { "data-slot": "verify-email-01-resend", type: "button", variant: "outline", onClick: onResend, disabled: resending, children: resending ? resentLabel : resendLabel })) : null, !resending || cooldownLabel === undefined ? null : (_jsx("p", { "data-slot": "verify-email-01-cooldown", className: "text-muted-foreground text-xs", children: cooldownLabel })), actions === undefined ? null : (_jsx("div", { "data-slot": "verify-email-01-next", className: "flex w-full flex-col gap-2", children: actions }))] })] }), help === undefined ? null : (_jsxs("div", { "data-slot": "verify-email-01-help", className: "flex max-w-measure-narrow flex-col items-start gap-2", children: [_jsx("p", { className: "text-muted-foreground text-sm text-pretty", children: help.message }), _jsx(CtaLink, { href: help.href, variant: "ghost", size: "sm", children: help.label })] }))] }) }));
+}
+export default VerifyEmail01;

package/dist/blocks/waitlist-01/index.d.ts

@@ -0,0 +1,3 @@
+export { Waitlist01, default } from './waitlist.js';
+export type { Waitlist01Props, Waitlist01Position, Waitlist01Referral, Waitlist01Status, WaitlistValue, } from './waitlist.js';
+//# sourceMappingURL=index.d.ts.map

package/dist/blocks/waitlist-01/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../src/blocks/waitlist-01/index.tsx"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,OAAO,EAAE,MAAM,YAAY,CAAA;AAKhD,YAAY,EACV,eAAe,EACf,kBAAkB,EAClB,kBAAkB,EAClB,gBAAgB,EAChB,aAAa,GACd,MAAM,YAAY,CAAA"}