@nanisoft/prism-ui 0.13.0 → 0.16.0

package/dist/blocks/onboarding-01/onboarding.js

@@ -0,0 +1,182 @@
+'use client';
+import { jsx as _jsx, jsxs as _jsxs, Fragment as _Fragment } from "react/jsx-runtime";
+import { CtaLink } from '../../components/ui/cta-link.js';
+import { Metric } from '../../components/ui/metric.js';
+import { Section, SectionHeading } from '../../components/ui/section.js';
+import { Steps } from '../../components/ui/steps.js';
+import { cn } from '../../lib/utils.js';
+/**
+ * The mark each of the four states draws, and the shape before the colour.
+ *
+ * The four differ by shape before they differ by hue, for the reason `steps.tsx`
+ * states in full: a filled mint disc and a mint ring are the same picture narrowed
+ * to one channel, and a reader who cannot separate them is being told the same
+ * thing about two different steps. So `blocked` is the one mark that is not a disc
+ * at all, and a square in the alarm ink is findable in a column of circles by a
+ * reader who sees no colour whatsoever. The words beside the mark are the caller's
+ * and they are what actually carry the state; the mark is a faster read of the same
+ * fact, never the fact itself.
+ */
+const MARK = {
+    done: 'bg-primary border-primary',
+    current: 'bg-background border-brand-ink',
+    upcoming: 'bg-muted border-border',
+    blocked: 'rounded-sm bg-background border-destructive',
+};
+/**
+ * The state a step's mark is drawn from on the rail.
+ *
+ * Three values for four states, and `done` becomes `complete` because that is the
+ * word `Steps` uses for a step behind the reader. `blocked` carries the value the
+ * guard has already refused to reach rather than being absent, so the table is
+ * total over the four states and the lookup below needs no assertion to say that a
+ * blocked step is not on this rail: it is not, and if one arrives the run stopped
+ * before this table was read.
+ */
+const RAIL_STATE = {
+    done: 'complete',
+    current: 'current',
+    upcoming: 'upcoming',
+    blocked: 'current',
+};
+/**
+ * The step the rail is on, and the reason this Block picks it rather than asking.
+ *
+ * `Steps` requires exactly one current step and throws without one, and a setup is a
+ * place where that is genuinely absent: a setup the reader finished yesterday has no
+ * current step and a setup nobody has started has one that nobody declared. So the
+ * position is derived when the caller has not declared it: the first step that has
+ * not been done, and the last step when everything is done, which is the only
+ * position a finished rail can hold. The caller who has declared one gets it.
+ */
+function railCurrent(steps) {
+    const declared = steps.findIndex((step) => step.state === 'current');
+    if (declared !== -1)
+        return declared;
+    const firstOpen = steps.findIndex((step) => step.state === 'upcoming');
+    return firstOpen === -1 ? steps.length - 1 : firstOpen;
+}
+/**
+ * A setup checklist: the steps that are done, the one the reader is on, the one they
+ * are stuck on, and a figure that says how much is left.
+ *
+ * **A reader here is either on a first run or on a return visit, and the default
+ * form is the one for the return visit.** That is the whole argument for
+ * `checklist` being the default rather than the alternative: a reader who has been
+ * here once is looking for the one thing left, and a rail of numbered steps answers
+ * a question they are not asking. It shows the whole route, marks each step and
+ * draws a rule between them, which is a document about the order, and a document
+ * about the order is what a reader needs on a first run and is one screen too much
+ * on the second. So the default is a list of what is outstanding, where the one
+ * outstanding thing is findable in a glance, and `steps` is the rail for the first
+ * run.
+ *
+ * **`blocked` is a first-class state, and it is the decision this Block is most
+ * particular about.** A checklist that can only say done, and not done and next, is
+ * a checklist that will read as broken to a reader who is genuinely stuck: the step
+ * they are on looks exactly like the step they have not reached, and the honest
+ * reading of a setup that has not moved in a week is a broken product rather than a
+ * missing permission, a missing key or a colleague who has not got to it. A reader
+ * who believes the product is broken stops trusting the product, and they are not
+ * wrong to, so a Block that cannot say "you are blocked here" is answering that
+ * reader with a lie by omission. The mark is the one shape on this surface that is
+ * not a disc, so a reader who sees no colour at all still finds it, and the words
+ * beside it are the caller's because what a reader is waiting for is the
+ * product's own sentence about it.
+ *
+ * **The rail is `steps.tsx` for the `steps` form, because the rail is a Component
+ * and its three marks are already right.** A hand-drawn set of discs would be a
+ * second implementation of three things `Steps` has settled: that the states differ
+ * by shape before they differ by colour, that exactly one step carries
+ * `aria-current`, and that the rule between the steps carries how far along the
+ * reader is rather than a bar per step restating "done" once per step. The cost is
+ * the rail's own limitation rather than this Block's, and the run refuses it rather
+ * than dropping it: a rail has no room for a description, a control, a moment or a
+ * fourth state, so a step carrying any of those is a step the caller wants in the
+ * checklist, and the diagnostic says so.
+ *
+ * **The progress figure is `Metric`, and the sentence under it is the caller's.**
+ * `Metric` owns the arrangement a headline figure is read in, which puts the figure
+ * first and the name under it, and it owns the fact that a string figure is set in
+ * the mono face while a composed one is not. What it cannot do is name the figure,
+ * and the honest answer is that the name is `progressLabel`: "steps complete" is a
+ * claim about what a step is, and a checklist in a consumer's product may well be a
+ * checklist of deployments, of regions, or of approvals. So the figure is the count
+ * of what is done and the words under it are the caller's sentence, which is the
+ * same split `Waitlist01` makes about a position and for the same reason.
+ *
+ * **It is a client Component, and the reason is `onSelect` rather than any state of
+ * its own.** A handler is a function, a function is a piece of state, and state is a
+ * client module, so the directive is here. The cost is stated rather than hidden: a
+ * checklist that takes no `onSelect` is still a client Component, because the
+ * directive is a property of the module rather than of a call, and the alternative
+ * was a Block whose `onSelect` silently did nothing in a server render, which is
+ * worse than a client boundary nobody asked for.
+ */
+export function Onboarding01({ eyebrow, title, description, steps, onSelect, progressLabel, completion, variant = 'checklist', empty, headingLevel = 'h2', className, }) {
+    for (const step of steps) {
+        if (!step.stateLabel) {
+            throw new Error(`Onboarding01: the step "${step.id}" declares a state and no stateLabel, so the mark beside ` +
+                'it would be a shape with no sentence, and a shape a reader can only see is a state nobody can ' +
+                'act on. Pass the words your readers use for that state.');
+        }
+        if (step.href !== undefined && !step.hrefLabel) {
+            throw new Error(`Onboarding01: the step "${step.id}" carries an href with no hrefLabel, so the link would be ` +
+                'announced by its address, which is punctuation rather than a name. Pass the words that say ' +
+                'where it goes, or drop the href.');
+        }
+        if (variant === 'steps') {
+            if (step.state === 'blocked' || step.description !== undefined || step.action !== undefined || step.href !== undefined) {
+                throw new Error(`Onboarding01: the step "${step.id}" cannot be drawn on the rail, because a rail has no room ` +
+                    'for a description, a control or a destination, and because a step that is blocked is a fact ' +
+                    'about this run rather than a position in the order. Use the checklist form, which is the ' +
+                    'default and the one a reader on a return visit wants.');
+            }
+        }
+        else if (onSelect !== undefined && (step.action !== undefined || step.href !== undefined)) {
+            throw new Error(`Onboarding01: the step "${step.id}" carries an action or a destination and onSelect is set, so ` +
+                'the row would be a control with another control inside it. Put the action in the row you draw ' +
+                'yourself, or drop onSelect and let the steps be a list of what is outstanding.');
+        }
+    }
+    if (variant === 'steps') {
+        const currents = steps.filter((step) => step.state === 'current').length;
+        if (currents > 1) {
+            throw new Error(`Onboarding01: the steps declare ${currents} current steps, and a rail has one position. Two ` +
+                'current steps is a reader told they are in two places at once. Declare one.');
+        }
+    }
+    const done = steps.filter((step) => step.state === 'done').length;
+    const heading = (_jsx(SectionHeading, { as: headingLevel, align: "left", eyebrow: eyebrow, title: title, description: description }));
+    const progress = (_jsxs("div", { "data-slot": "onboarding-progress", className: "flex flex-col gap-2", children: [_jsx(Metric, { "data-slot": "onboarding-figure", value: done, label: progressLabel(done, steps.length) }), completion === undefined ? null : (_jsx("p", { "data-slot": "onboarding-completion", className: "text-muted-foreground text-pretty text-sm", children: completion }))] }));
+    if (steps.length === 0) {
+        return (_jsx(Section, { "data-slot": "onboarding-01", "data-variant": variant, "data-empty": "true", className: cn(className), children: _jsxs("div", { className: "flex flex-col gap-8", children: [heading, _jsx("div", { "data-slot": "onboarding-empty", className: "text-muted-foreground text-pretty text-sm", children: empty })] }) }));
+    }
+    /*
+      The rail's steps, and their states are the caller's whenever the caller
+      declared a position. A setup that reached a step out of band is real: a
+      connection approved in another tab, a region enabled by a colleague, a step
+      completed by hand last night. A rail derived from the order would draw a claim
+      the data contradicts, and the override is per step rather than a mode, so a
+      caller who has declared nothing still gets the derivation that cannot disagree
+      with itself.
+    */
+    const rail = steps.map((step) => ({
+        label: step.name,
+        ...(variant === 'steps' && steps.some((one) => one.state === 'current')
+            ? { state: RAIL_STATE[step.state] }
+            : null),
+    }));
+    return (_jsx(Section, { "data-slot": "onboarding-01", "data-variant": variant, className: cn(className), children: _jsxs("div", { className: "flex flex-col gap-10", children: [heading, progress, variant === 'steps' ? (_jsx("div", { "data-slot": "onboarding-rail", children: _jsx(Steps, { steps: rail, current: railCurrent(steps) }) })) : (_jsx("ol", { "data-slot": "onboarding-steps", className: "flex flex-col", children: steps.map((step) => {
+                        /*
+                          One row's content, built once and wrapped by whichever of the two
+                          arrangements the caller asked for. A row is either a control or a
+                          container and never both, and the guard above has already refused the
+                          shape that would have to be both, so these two branches can never
+                          disagree about what the row contains.
+                        */
+                        const content = (_jsxs(_Fragment, { children: [_jsx("span", { "data-slot": "onboarding-mark", "aria-hidden": "true", className: cn('mt-0.5 inline-block size-4 shrink-0 rounded-full border-2', MARK[step.state]) }), _jsxs("span", { className: "flex min-w-0 flex-1 flex-col gap-1", children: [_jsx("span", { "data-slot": "onboarding-name", className: cn('text-sm font-medium', step.state === 'upcoming' ? 'text-muted-foreground' : 'text-foreground'), children: step.name }), step.description === undefined ? null : (_jsx("span", { "data-slot": "onboarding-description", className: "text-muted-foreground text-pretty text-sm", children: step.description })), _jsx("span", { "data-slot": "onboarding-state", className: "text-muted-foreground text-xs", children: step.stateLabel })] })] }));
+                        return (_jsx("li", { "data-slot": "onboarding-step", "data-state": step.state, "data-step": step.id, className: "border-border border-b py-4 first:border-t", children: onSelect === undefined ? (_jsxs("div", { "data-slot": "onboarding-step-row", className: "flex w-full items-start gap-x-4 gap-y-2", children: [content, step.action === undefined ? null : (_jsx("div", { "data-slot": "onboarding-step-action", className: "flex shrink-0 items-center gap-2", children: step.action })), step.href === undefined || step.hrefLabel === undefined ? null : (_jsx(CtaLink, { "data-slot": "onboarding-step-link", href: step.href, size: "sm", variant: "ghost", className: "shrink-0 self-center", children: step.hrefLabel }))] })) : (_jsx("button", { "data-slot": "onboarding-step-button", type: "button", "aria-current": step.state === 'current' ? 'step' : undefined, onClick: () => onSelect(step.id), className: "focus-visible:ring-ring flex w-full items-start gap-x-4 rounded-sm text-left outline-none transition-colors duration-fast ease-out hover:bg-accent/50 focus-visible:ring-[3px]", children: content })) }, step.id));
+                    }) }))] }) }));
+}
+export default Onboarding01;

package/dist/blocks/ops-checklist-01/index.d.ts

@@ -0,0 +1,3 @@
+export { OpsChecklist01, default } from './ops-checklist-01.js';
+export type { OpsChecklist01Check, OpsChecklist01Group, OpsChecklist01Props, OpsChecklist01Verdict, } from './ops-checklist-01.js';
+//# sourceMappingURL=index.d.ts.map

package/dist/blocks/ops-checklist-01/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../../src/blocks/ops-checklist-01/index.tsx"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAE,OAAO,EAAE,MAAM,oBAAoB,CAAA;AAM5D,YAAY,EACV,mBAAmB,EACnB,mBAAmB,EACnB,mBAAmB,EACnB,qBAAqB,GACtB,MAAM,oBAAoB,CAAA"}

package/dist/blocks/ops-checklist-01/index.js

@@ -0,0 +1 @@
+export { OpsChecklist01, default } from './ops-checklist-01.js';

package/dist/blocks/ops-checklist-01/ops-checklist-01.d.ts

@@ -0,0 +1,308 @@
+import type { ReactNode } from 'react';
+import { type HeadingLevel } from '../../components/ui/section.js';
+/**
+ * The four verdicts a check can come to, and the tone each one is drawn in.
+ *
+ * **Four, and the set is closed because a check's verdict is a judgement the caller
+ * makes about a threshold Prism does not have.** `pass` is the only state that means
+ * the estate is as it should be, so it is `success`. `fail` is the one a reader must
+ * not miss, so it is `destructive`. `warn` is the interesting one and it is `warning`
+ * rather than a fifth thing: it is the verdict a reader has to act on without
+ * stopping work, which is exactly the thing the warning tone has always meant in this
+ * system, and inventing a fourth state for it would be a colour a reader must learn
+ * and a word a maintainer must keep true. `skipped` is `neutral`, and it is in the
+ * list rather than absent, because a check a person could not run is a fact about the
+ * run and hiding it would make a runbook look complete when it is not.
+ *
+ * `skipped` being `neutral` rather than `destructive` is the decision most worth
+ * stating. A check that was skipped is not a check that failed, and drawing it in the
+ * tone that means a reader must not miss would train a reader to ignore that tone on
+ * the next run. The cost is that a runbook with forty skipped checks looks calm, and
+ * the words beside the dot are what say so.
+ */
+export type OpsChecklist01Verdict = 'pass' | 'fail' | 'warn' | 'skipped';
+/**
+ * One check a person performs, and everything they need to record about it: what it
+ * is, what the estate should read, what it actually read, what they concluded, and
+ * anything that qualifies the conclusion.
+ *
+ * **`name` is required and the rest is optional, and the reason is that a check with
+ * no name is a row nobody can refer to in a handover.** A runbook is read aloud in
+ * pairs on a rota, and "the thing on the third line" is not a reference. Everything
+ * else is optional because a person performing checks records different subsets: a
+ * check whose estate is healthy has no note, and a check on a system that does not
+ * exist yet has no expected reading at all.
+ */
+export type OpsChecklist01Check = {
+    /** The check's stable key within its group. */
+    id: string;
+    /**
+     * What the person checks, in the words the runbook uses.
+     *
+     * The identity of the row and the words a reader scans down a column looking for, so
+     * it is a short noun phrase rather than a sentence. "Certificates under 90 days" is
+     * a check; "We should check the certificates" is an instruction and belongs in the
+     * note.
+     */
+    name: string;
+    /**
+     * What this estate should read, if the check passes.
+     *
+     * A node, and drawn as passed, in the muted ink and in the first of the two cells.
+     * The honest expected reading is four different things across four NaniSoft
+     * estates: a count, a version, a duration and a threshold, and each of them is a
+     * sentence in the runbook's own vocabulary. A Block that printed "3 or fewer" would
+     * be deciding which unit an estate counts certificates in, and one that printed a
+     * comparison would be writing the arithmetic for a threshold the caller owns.
+     *
+     * A node rather than a string partly so the caller can compose their own column
+     * name into the value: this Block draws no words above either cell, because "Expected"
+     * and "Actual" are this system's reading of the word and every estate that reads a
+     * runbook aloud says something else. See the Block's JSDoc for what that costs.
+     */
+    expected?: ReactNode;
+    /**
+     * What the estate actually read when the check was performed.
+     *
+     * A node and a separate field, and **this is the whole of why a runbook is a
+     * two-cell check rather than a one-cell one.** A runbook is about the difference
+     * between what should be and what is, and a Block that rendered one of them was
+     * rendering half the check: a column of expected readings tells a reader what the
+     * runbook believes, a column of actual readings tells them what happened, and
+     * neither one alone answers the only question a person opening a runbook has, which
+     * is whether the estate is well. So the two are two cells, in that order, with the
+     * expected reading in the muted ink and the actual reading in the foreground, which
+     * is the order a person says them in.
+     *
+     * Omit it for a check nobody has run yet, and the cell draws nothing rather than
+     * carrying a placeholder, because a check nobody has run is a fact about the runbook
+     * worth showing and a dash would read as nothing left to do.
+     */
+    actual?: ReactNode;
+    /**
+     * What the person concluded, which is a judgement Prism cannot make.
+     *
+     * Required in the sense that a check with no verdict is a check that has not been
+     * performed, and the run refuses to imply otherwise: see the Block's JSDoc, which is
+     * the most important sentence in this file. A design system that computed pass or
+     * fail would be making a claim about an estate it cannot see, on thresholds it does
+     * not have, and the caller who owns the estate owns the threshold.
+     *
+     * Omit it for a check that is not yet done, and the row then carries no mark at
+     * all rather than a grey dot saying nothing happened.
+     */
+    verdict?: OpsChecklist01Verdict;
+    /**
+     * The words for the verdict, given the verdict.
+     *
+     * Required whenever `verdict` is set and the run fails without it, for the reason
+     * the Component JSDoc on `Status` gives at length: the tone is a colour and the
+     * words are the information, and a runbook is the worst place in a product for an
+     * English word, because it is the document a person reads at three in the morning
+     * and quotes to somebody else afterwards. Four estates between them use nine words
+     * for these four states, and a function of the verdict is what lets one of them
+     * say "green" and another say "passing" without this Block choosing.
+     */
+    verdictLabel?: (verdict: OpsChecklist01Verdict) => string;
+    /**
+     * Anything that qualifies the verdict: what was actually run, what was skipped and
+     * why, a ticket, a follow-up.
+     *
+     * A node and not a string, because a note on a runbook is a sentence in one case, a
+     * link to a ticket in the next and a list of three commands in the third, and a
+     * string prop would force the caller to flatten whichever of those it had. The
+     * Block draws it in the muted ink under the row and never truncates it, because a
+     * truncated note is a qualification removed and qualifications are the whole reason
+     * a runbook is not a status page.
+     */
+    note?: ReactNode;
+};
+/**
+ * One group of checks, and the caller's own name for the group.
+ *
+ * A group is a place a reader navigates to rather than a result they read, which is
+ * why a group title is a heading one step below the section and why the checks under
+ * it are the next level: a runbook read aloud on a rota is read group by group, and a
+ * reader who has learned the outline on one group has learned it for all of them.
+ */
+export type OpsChecklist01Group = {
+    /** The group's stable key. */
+    id: string;
+    /** The group's own name, which is also its card title. */
+    title: string;
+    /**
+     * One line under the group's name: what these checks are for, or which part of the
+     * estate they cover.
+     *
+     * A node and not a string, for the reason the category description on `help-01` and
+     * `directory-01` is a node: the honest line is sometimes a sentence and sometimes a
+     * list of the three systems in the group.
+     */
+    description?: ReactNode;
+    /** The checks in it, in the order they should be performed. */
+    checks: readonly OpsChecklist01Check[];
+};
+/**
+ * The props an OpsChecklist01 takes.
+ *
+ * Every string is a prop and the Block ships none: no check name, no expected reading,
+ * no actual reading, no verdict word, no note and not one column heading. A runbook
+ * with Prism's words in it would be a runbook for an estate Prism cannot see, which is
+ * the one thing a runbook is not.
+ */
+export type OpsChecklist01Props = {
+    /** The short line above the title, usually which estate this runbook is for. */
+    eyebrow?: ReactNode;
+    /**
+     * The heading.
+     *
+     * Required, and the reason is the one `inbox-01` and `intake-01` give: a list of
+     * checks with no heading is a column of check names a reader cannot name, and a
+     * reader who cannot name a region cannot navigate back to it.
+     */
+    title: ReactNode;
+    /** One supporting line under the heading, for the part the title cannot carry. */
+    description?: ReactNode;
+    /**
+     * The groups, in the order the checks should be performed.
+     *
+     * Order is the caller's, and the Block does not sort, because a runbook's order is
+     * a claim about what to look at first and re-ordering it would be second-guessing
+     * the person who wrote it with the estate in front of them.
+     */
+    groups: readonly OpsChecklist01Group[];
+    /**
+     * The figures across the whole run, drawn as metrics above the groups.
+     *
+     * **A label and a value and nothing else, and that is why this is a list of pairs
+     * rather than a set of props.** A runbook's summary is "9 of 12 passing" and "1
+     * failing" and "2 not run", and the sentence around each of those is the runbook's
+     * own: an estate that says "failing" and an estate that says "needs attention" are
+     * describing the same two checks differently. The figures are `Metric`s composed
+     * rather than redrawn, for the reason `About01` gives: `Metric` owns the
+     * arrangement a headline figure is read in, which puts the figure first and the name
+     * under it, and it owns the type-scale decision. What this Block does not pass is a
+     * `delta`, because a runbook is a snapshot of one run and a change against a previous
+     * run is a claim about a runbook the caller may not have.
+     */
+    summary?: readonly {
+        label: string;
+        value: ReactNode;
+    }[];
+    /**
+     * The caller's own sentence for a runbook with no checks in it.
+     *
+     * Required, and the reason is the one every list in this package states: a person
+     * who opened a runbook and found nothing in it is reading exactly one line, and
+     * that line is the most load-bearing sentence on the page. "Nothing to check" is a
+     * claim, and it is a different claim in an estate whose checks have not been written
+     * yet and in one where the query that fills the page is broken.
+     */
+    empty: ReactNode;
+    /**
+     * Heading level for the section heading. See `HeadingLevel`.
+     */
+    headingLevel?: HeadingLevel;
+    /**
+     * Layout only, exactly as on every Block. Changing a Prism-owned visual property
+     * from here is prohibited.
+     */
+    className?: string;
+};
+/**
+ * A runbook: a set of checks a person performs on an estate, each with a state, an
+ * expected reading, the reading that was taken, and a verdict.
+ *
+ * **It must not decide a verdict, and that is the most important sentence in this
+ * file.** A design system that computed pass or fail would be making a claim about an
+ * estate it cannot see, on thresholds it does not have. What counts as a warning is a
+ * decision about an estate's risk appetite, and four NaniSoft estates have four of
+ * them: one calls a certificate at 89 days a pass, one calls it a warning, and one has
+ * no certificates at all. The threshold belongs to the caller who owns the estate, and
+ * so does the reading that was taken. So the verdict is a prop, the tones are this
+ * system's, and the words are the caller's, and a Block that inferred a verdict from
+ * a comparison between two cells would be a design system asserting an infrastructure
+ * fact. The cost of the refusal is real and it is the right one: a caller with three
+ * checks whose verdicts are all derivable writes three calls, and a caller who wanted
+ * the arithmetic done for them reaches for their own data layer, which is the only
+ * place that can see the estate.
+ *
+  * **`expected` and `actual` are two cells rather than one, because a runbook is about
+  * the difference between what should be and what is.** A Block that rendered one of
+  * them was rendering half the check: a column of expected readings tells a reader what
+  * the runbook believes, a column of actual readings tells them what happened, and
+  * neither one alone answers the only question a person opening a runbook has, which
+  * is whether the estate is well. So the two are separate fields, in that order, with
+  * the expected reading in the muted ink and the actual reading in the foreground,
+  * which is the order a person says them in, and the two cells are the same shape so
+  * the eye compares them without either one being the odd one out. A caller who passes
+  * one and not the other gets one cell filled and one empty, and the empty one is the
+  * fact: a check nobody has run yet is worth showing rather than hiding behind a
+  * placeholder.
+  *
+  * **No column name is drawn above either cell, and that is a refusal with a real
+  * cost.** "Expected" and "Actual" are this system's reading of the word, and every
+  * estate that reads a runbook aloud says something else: "Wanted" and "Found", "Should
+  * be" and "Is", "Configured" and "Running". A Block that named them would be
+  * publishing one estate's vocabulary into every product that installs it, inside a
+  * design system rather than inside a product's copy, which is where a translation
+  * tool is least likely to look. So the two are told apart by ink and by position, the
+  * expected one always first, and a caller who wants the words composes them into the
+  * node, which is what a `ReactNode` is for. The cost is the honest one: a caller who
+  * does not compose them is left with two columns a reader tells apart by shade rather
+  * than by word, and the answer for a runbook that needs a real header row is
+  * `DataTable01`, which is that table with the caller's own cells and column names.
+  *
+
+ * **The four verdicts are mapped here and the words are the caller's, and the
+ * `skipped` tone is the decision worth naming.** `pass` is `success` because it is
+ * the only verdict that means the estate is as it should be. `fail` is `destructive`
+ * because it is the one a reader must not miss. `warn` is `warning` because it is the
+ * verdict a reader has to act on without stopping work, which is what the warning
+ * tone has always meant here, and giving it a fifth state would be a colour a reader
+ * must learn and a word a maintainer must keep true. And `skipped` is `neutral`, not
+ * `destructive`, because a check a person could not run is not a check that failed,
+ * and drawing it in the tone that means a reader must not miss would train a reader to
+ * ignore that tone on the next run. The cost is that a runbook with forty skipped
+ * checks looks calm, and the words beside the dot are the only thing that says
+ * otherwise, which is the trade this design makes everywhere.
+ *
+ * **`verdictLabel` is a function of the verdict and is required, for the reason
+ * every mark in this package states and the reason a runbook is the worst case of
+ * them.** A coloured dot is invisible to a reader who cannot separate the tones and
+ * unreadable to a screen reader whatever the tones are, and the document being read is
+ * the one a person quotes to somebody else afterwards. Four estates between them use
+ * nine words for these four states, so the prop is a function and there is no default
+ * to fall back on. A check with a verdict and no label throws rather than rendering a
+ * dot, and the message names the check and the group.
+ *
+ * **The summary is `Metric` composed and not redrawn, and the Block passes no
+ * `delta`.** A runbook's figures are read first and named under, which is the
+ * arrangement `Metric` owns along with the type-scale decision and the rule that a
+ * string figure is set in the mono face. What this Block declines to pass is a delta,
+ * because a runbook is a snapshot of one run and a change against the previous run is
+ * a claim about a runbook the caller may not keep. The `label` is a `string` and the
+ * `value` a `node`, which is the same split `About01`'s figures make: a label is
+ * scanned and a value is composed.
+ *
+ * **The group title is a heading one step below the section and the check names are
+ * headings one step below that, because a runbook has two levels of outline and both
+ * of them are used.** A person reading a rota aloud goes group by group and check by
+ * check, and a reader who has learned the outline on one group has learned it for all
+ * of them. So the groups are headings at `childLevel(headingLevel)` and the checks are
+ * headings at `childLevel(childLevel(headingLevel))`, both derived, so a runbook
+ * embedded one level deeper carries its whole outline with it. The cost is a
+ * five-level outline on a deeply nested page, and `childLevel` holds at `h6` rather
+ * than wrapping for exactly that reason.
+ *
+ * **It is a server Component: no hook, no state, no effect, no client code and no
+ * router.** A runbook is a document a person reads, not a surface they work, so
+ * there is nothing here for a reader to press. The cost of that choice is that the
+ * Block cannot record that a check was performed; whether a runbook is a document or a
+ * checklist a person ticks off in the page is a decision about the caller's product,
+ * and a caller who wants the ticking composes their own control in `note` or their own
+ * region beside this Block.
+ */
+export declare function OpsChecklist01({ eyebrow, title, description, groups, summary, empty, headingLevel, className, }: OpsChecklist01Props): import("react").JSX.Element;
+export default OpsChecklist01;
+//# sourceMappingURL=ops-checklist-01.d.ts.map

package/dist/blocks/ops-checklist-01/ops-checklist-01.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"ops-checklist-01.d.ts","sourceRoot":"","sources":["../../../src/blocks/ops-checklist-01/ops-checklist-01.tsx"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,OAAO,CAAA;AAGtC,OAAO,EAIL,KAAK,YAAY,EAClB,MAAM,6BAA6B,CAAA;AAIpC;;;;;;;;;;;;;;;;;;;GAmBG;AACH,MAAM,MAAM,qBAAqB,GAAG,MAAM,GAAG,MAAM,GAAG,MAAM,GAAG,SAAS,CAAA;AAUxE;;;;;;;;;;;GAWG;AACH,MAAM,MAAM,mBAAmB,GAAG;IAChC,+CAA+C;IAC/C,EAAE,EAAE,MAAM,CAAA;IACV;;;;;;;OAOG;IACH,IAAI,EAAE,MAAM,CAAA;IACZ;;;;;;;;;;;;;;OAcG;IACH,QAAQ,CAAC,EAAE,SAAS,CAAA;IACpB;;;;;;;;;;;;;;;;OAgBG;IACH,MAAM,CAAC,EAAE,SAAS,CAAA;IAClB;;;;;;;;;;;OAWG;IACH,OAAO,CAAC,EAAE,qBAAqB,CAAA;IAC/B;;;;;;;;;;OAUG;IACH,YAAY,CAAC,EAAE,CAAC,OAAO,EAAE,qBAAqB,KAAK,MAAM,CAAA;IACzD;;;;;;;;;;OAUG;IACH,IAAI,CAAC,EAAE,SAAS,CAAA;CACjB,CAAA;AAED;;;;;;;GAOG;AACH,MAAM,MAAM,mBAAmB,GAAG;IAChC,8BAA8B;IAC9B,EAAE,EAAE,MAAM,CAAA;IACV,0DAA0D;IAC1D,KAAK,EAAE,MAAM,CAAA;IACb;;;;;;;OAOG;IACH,WAAW,CAAC,EAAE,SAAS,CAAA;IACvB,+DAA+D;IAC/D,MAAM,EAAE,SAAS,mBAAmB,EAAE,CAAA;CACvC,CAAA;AAED;;;;;;;GAOG;AACH,MAAM,MAAM,mBAAmB,GAAG;IAChC,gFAAgF;IAChF,OAAO,CAAC,EAAE,SAAS,CAAA;IACnB;;;;;;OAMG;IACH,KAAK,EAAE,SAAS,CAAA;IAChB,kFAAkF;IAClF,WAAW,CAAC,EAAE,SAAS,CAAA;IACvB;;;;;;OAMG;IACH,MAAM,EAAE,SAAS,mBAAmB,EAAE,CAAA;IACtC;;;;;;;;;;;;;OAaG;IACH,OAAO,CAAC,EAAE,SAAS;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,SAAS,CAAA;KAAE,EAAE,CAAA;IACxD;;;;;;;;OAQG;IACH,KAAK,EAAE,SAAS,CAAA;IAChB;;OAEG;IACH,YAAY,CAAC,EAAE,YAAY,CAAA;IAC3B;;;OAGG;IACH,SAAS,CAAC,EAAE,MAAM,CAAA;CACnB,CAAA;AA2BD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6FG;AACH,wBAAgB,cAAc,CAAC,EAC7B,OAAO,EACP,KAAK,EACL,WAAW,EACX,MAAM,EACN,OAAO,EACP,KAAK,EACL,YAAmB,EACnB,SAAS,GACV,EAAE,mBAAmB,+BA+NrB;AAED,eAAe,cAAc,CAAA"}