@dcs-tech/ui 0.2.0 → 0.4.0

package/dist/types/shared-logic/src/report/layout.d.ts

@@ -1,85 +0,0 @@
-/**
- * Report engine — template + data → a measured, unpaged document.
- *
- * Every table is expanded here (a flowing table becomes its heading, one band per row, its section
- * rows and its closing rows), every placeholder substituted, every cell wrapped to its column width,
- * and every height measured. What comes out is flat: a list of things with a `heightPt`. Pagination
- * then has no decisions left to make except where to break.
- *
- * THE ENGINE OWNS THE COLUMN WIDTHS. It resolves them once and hands them to the renderer. That
- * is the whole reason this can be trusted where the old generators could not: they guessed at
- * what pdfmake would do with `'auto'` and `'*'`, pdfmake disagreed, and the page overflowed.
- * A renderer given explicit point widths has nothing to disagree about.
- */
-import type { ColumnSpec, LayoutBand, LayoutDocument, PageConfig, ReportContext, ReportRegistry, ReportTemplate, TextStyle } from '../../../published/dcs-ui/src/publicTypes';
-import { type GroupKey, type TableRow } from './dataset';
-import { type FormatLookup } from './resolve';
-import type { ResolveScope } from './scope';
-/** Cell padding, points. Matches what the existing PDF formats use, so converted output lines up. */
-export declare const CELL_PAD_X = 8;
-export declare const CELL_PAD_Y = 4;
-/**
- * Added to an `auto` column's measured width.
- *
- * An auto column is sized to exactly its widest value, so that value sits ON the boundary — and
- * the engine's width table and pdfmake's font disagree by thousandths of a point (measured: 0.0009pt
- * for `52051110`, 0.036pt for bold digits). When pdfmake's number is the larger one it breaks the
- * word: `12617%` printed as `12617` over `%`, a whole extra line the plan never saw. One point is
- * thirty times the largest error measured and invisible on paper.
- */
-export declare const AUTO_COLUMN_SLACK_PT = 1;
-export declare const pageContentSize: (page: PageConfig) => {
-    widthPt: number;
-    heightPt: number;
-};
-/**
- * A column as it prints. An ordinary column is itself; a `groupColumns` column becomes one of these
- * per group value, sharing the spec and carrying the value it prints.
- */
-export interface PlacedColumn {
-    /** Unique among the printed columns: the spec's id, or `specId:groupKey`. */
-    id: string;
-    /** The template column it came from — what closing rows and heading groups name. */
-    sourceId: string;
-    spec: ColumnSpec;
-    group?: GroupKey;
-}
-export declare const expandColumns: (columns: ColumnSpec[], groupKeys: GroupKey[]) => PlacedColumn[];
-/**
- * Resolves declared widths to points: numbers as given, `auto` to the widest content it must
- * hold, `*` sharing what is left. When the total overruns, `auto` and `*` columns shrink
- * proportionally rather than the table running off the paper.
- */
-export declare const resolveColumnWidths: (columns: PlacedColumn[], rows: TableRow[], available: number, scope: ResolveScope, lookup: FormatLookup, tableHeaderStyle?: TextStyle, 
-/** Widest text anything else prints in each column — the rows closing a table. */
-alsoFits?: Array<number | undefined>) => number[];
-export interface LayoutOptions {
-    /**
-     * Room left unused at the foot of every page.
-     *
-     * The measurements here are close but not exact — pdfmake's own row height carries a ~0.02pt
-     * rounding, and text outside ASCII is shaped by a font no character table can predict. Packed
-     * to the very last point, a page that the engine believes fits by half a point spills, and the
-     * renderer silently adds a page. Reserving a line absorbs that.
-     *
-     * Defaults to one line, or three when the document contains non-ASCII text.
-     */
-    safetyGapPt?: number;
-}
-export interface LayoutResult {
-    document: LayoutDocument;
-    /** Re-resolves the page bands for a given page, so `%page.number%` can be filled in late. */
-    pageBandsFor: (number: number, count: number) => {
-        header: LayoutBand[];
-        footer: LayoutBand[];
-    };
-}
-/** Print options with the template's defaults under whatever the app passed. */
-export declare const resolveOptions: (template: ReportTemplate, given?: Record<string, unknown>) => Record<string, unknown>;
-/**
- * `%page.count%` cannot be known before pagination, and pagination cannot start without knowing
- * how tall the page bands are. The way out is that a page number never changes a band's HEIGHT —
- * so the page bands are measured once with placeholder values and re-resolved per page for
- * content. `pageBandsFor` is that second pass.
- */
-export declare const layoutDocument: (template: ReportTemplate, context: ReportContext, registry: ReportRegistry, options?: LayoutOptions) => LayoutResult;

package/dist/types/shared-logic/src/report/metrics.d.ts

@@ -1,62 +0,0 @@
-/**
- * Report engine — text metrics.
- *
- * Page layout is impossible without knowing how tall a paragraph will be, and that cannot be
- * guessed from a characters-per-line constant: an item description that wraps to three lines
- * costs one row in a count and three times the height on paper. Every hand-written PDF format in
- * this codebase got that wrong at least once.
- *
- * DUPLICATION, ON PURPOSE. `apps/web/client/.../PDF/pdfMeasure.ts` carries the same character
- * table and line-height constants and is LIVE — it powers the A4 format-1 pagination fix. It is
- * deliberately left alone rather than re-pointed here, so a change to the engine can never move
- * a shipped invoice. What is shared is ~15 lines of measured font data; the rest of that file
- * walks pdfmake nodes, which this engine never sees. If the numbers below are ever recalibrated,
- * recalibrate both and re-run `npm run pagination`.
- */
-export declare const PT_PER_MM: number;
-export declare const mmToPt: (mm: number) => number;
-/** Paper sizes in points, portrait. */
-export declare const PAPER_SIZES_PT: Record<string, {
-    width: number;
-    height: number;
-}>;
-export declare const containsNonAscii: (text: string) => boolean;
-/** Height of one printed line. A line holding any CODE2000 glyph takes that font's taller box. */
-export declare const lineHeight: (fontSize?: number, uni?: boolean) => number;
-export declare const textWidth: (text: string, fontSize?: number, bold?: boolean) => number;
-/**
- * Wraps the way a PDF renderer does.
- *
- * Two rules, both verified against rendered output:
- *
- * 1. A chunk that cannot fit on a line of its own IS broken, character by character. This is easy
- *    to get wrong in the safe-looking direction: `240.625` in a 32pt quantity column really does
- *    become two lines, and assuming it bled past the cell edge under-measured every numeric
- *    column narrow enough to matter.
- * 2. A line's trailing space does not count towards the limit, so a word that exactly fills the
- *    column still fits.
- */
-export interface WrapResult {
-    lines: string[];
-    /**
-     * True when shaped (non-ASCII) text had to be force-broken.
-     *
-     * It marks the one case a character-width model cannot predict: where a renderer may put its
-     * break is decided by the shaper, not by advance widths, and it is reliably LESS efficient
-     * than the theoretical minimum this computes. Callers measuring height add a line back.
-     */
-    forcedShapedBreak: boolean;
-}
-export declare const wrapToWidthDetailed: (text: string, maxWidth: number, fontSize?: number, bold?: boolean) => WrapResult;
-export declare const wrapToWidth: (text: string, maxWidth: number, fontSize?: number, bold?: boolean) => string[];
-/** Narrowest the text can be laid out without a chunk bleeding out. */
-export declare const minTextWidth: (text: string, fontSize?: number, bold?: boolean) => number;
-/**
- * Height of `text` wrapped to `maxWidth`, line by line, so a Tamil line costs its true box.
- *
- * One line is added back when shaped text had to be force-broken. That is not a fudge factor
- * sprayed over the page — it is attached to the single construct whose line count cannot be
- * derived from advance widths, and measured against rendered output it is what the renderer
- * actually costs. Without it a twelve-column Tamil report planned 38 pages and printed 47.
- */
-export declare const textHeight: (text: string, maxWidth: number, fontSize?: number, bold?: boolean) => number;

package/dist/types/shared-logic/src/report/migrate.d.ts

@@ -1,77 +0,0 @@
-/**
- * Quoin — bringing a stored template up to the current schema.
- *
- * The ladder is empty today, and that is exactly why it exists now. The moment a customer saves a
- * template, its shape is frozen for every customer: any later change to a field name, a default,
- * or the meaning of a value has to be applied to documents already stored. Adding
- * the mechanism afterwards means writing it while also writing the first migration, against data
- * that is already in production.
- *
- * HOW TO ADD A STEP
- *   1. Change the types in `@pdfinvoice/shared-types`.
- *   2. Bump `REPORT_SCHEMA_VERSION`.
- *   3. Append a `{ to, describe, apply }` entry below whose `apply` takes the previous shape and
- *      returns the new one. It must be pure and total — it will run on documents you cannot see.
- *   4. Add a fixture of the OLD shape to the migration test. Never edit an existing fixture: it is
- *      the only remaining evidence of what that version looked like.
- *
- * `apply` MUST TOLERATE A PARTIAL TEMPLATE — a key it wants may be absent, and it must then leave
- * it absent rather than inventing one. This is not defensive coding: a stored customer template is
- * a DIFF against a shipped seed (§8), and the ladder runs on that diff ALONE, before it meets the
- * seed. Migrating after the merge would re-apply the step to seed keys that are already current.
- */
-import type { ReportTemplate } from '../../../published/dcs-ui/src/publicTypes';
-export interface MigrationStep {
-    /** The version this step produces. Steps run in ascending order of `to`. */
-    to: number;
-    /** One line, shown in logs so an upgrade is traceable. */
-    describe: string;
-    apply: (template: any) => any;
-}
-/**
- * Ordered oldest → newest. Empty while version 1 is the only version there has ever been.
- *
- * Example of what one looks like:
- *
- * ```ts
- * {
- *     to: 2,
- *     describe: 'columns.value may be a string or CellLine[]; wrap bare strings',
- *     apply: (t) => ({ ...t, columns: t.columns.map((c: any) =>
- *         typeof c.value === 'string' ? { ...c, value: [{ id: `${c.id}:l1`, content: c.value }] } : c) }),
- * }
- * ```
- */
-export declare const MIGRATIONS: MigrationStep[];
-/**
- * The version to assume when a stored diff carries none.
- *
- * Every write stamps one, so this only covers a document hand-edited in the console or written by
- * a build from before stamping existed. 1 is the only version there has ever been, and guessing
- * "current" instead would silently skip the whole ladder.
- */
-export declare const ASSUMED_SCHEMA_VERSION = 1;
-export interface MigrationResult {
-    template: ReportTemplate;
-    /** `describe` of each step applied, in order. Empty when the template was already current. */
-    applied: string[];
-}
-/**
- * Runs every step between the template's version and the current one.
- *
- * A template from the FUTURE — saved by a newer build — is refused rather than guessed at.
- * Silently downgrading it would quietly discard whatever the newer version added, and the
- * customer would have no way to tell.
- */
-export declare const migrateTemplate: (raw: unknown) => MigrationResult;
-/**
- * The same ladder, run over a stored DIFF rather than a whole template.
- *
- * `raw` is a `Partial<ReportTemplate>` with no `schemaVersion` of its own — the version lives on
- * the entry around it, so it is passed in. See the contract at the top of this file for why every
- * step has to survive the missing keys.
- */
-export declare const migrateTemplatePart: (raw: Partial<ReportTemplate>, from: number) => {
-    part: Partial<ReportTemplate>;
-    applied: string[];
-};

package/dist/types/shared-logic/src/report/paginate.d.ts

@@ -1,40 +0,0 @@
-/**
- * Report engine — dealing measured bands onto pages.
- *
- * By the time anything gets here every band has a height, so this makes exactly one kind of
- * decision: does the next band fit on this page. That is the whole of the bug the hand-written
- * formats kept having — they decided it from a row count, which cannot see a description that
- * wraps to three lines.
- *
- * Two rules beyond "does it fit":
- *
- * - `keepTogether` moves a band whole to the next page rather than splitting it. A totals block
- *   split across a page break is worse than a short page.
- * - A band taller than an entire page cannot be moved anywhere better, so it is SPLIT at a row
- *   boundary and continued. Without that, one 300-line description would loop forever or run off
- *   the paper — which is precisely what the old generators did before they were given
- *   continuation rows.
- *
- * Every flowing table gets, per page, what v1 gave only its one main grid:
- *
- * - its HEADING before its first row on the page (on later pages only when the table repeats it),
- *   and never a heading left alone at the foot of a page;
- * - its box CLOSED under its last row on the page — room for that line is reserved while dealing,
- *   so closing can never push a page over;
- * - empty rows FILLING the space under it, so the box runs down to what follows.
- *
- * And the page footer is ANCHORED to the foot of the page by a spacer, rather than floating up
- * under the last line of content.
- */
-import type { LayoutBand, LayoutDocument, PagedDocument } from '../../../published/dcs-ui/src/publicTypes';
-export interface PaginateOptions {
-    /**
-     * Re-resolves page header/footer for a given page, so `%page.number%` and `%page.count%` can
-     * be filled in once the count is known. `layoutDocument` returns exactly this function.
-     */
-    pageBandsFor?: (number: number, count: number) => {
-        header: LayoutBand[];
-        footer: LayoutBand[];
-    };
-}
-export declare const paginate: (doc: LayoutDocument, opts?: PaginateOptions) => PagedDocument;

package/dist/types/shared-logic/src/report/renderers/html.d.ts

@@ -1,29 +0,0 @@
-/**
- * Quoin — paged document → HTML.
- *
- * Two jobs, and they are the same job: it is what the designer previews, and it is what a browser
- * prints. Building the preview on this rather than on pdfmake means the designer needs no PDF
- * toolchain, redraws instantly on every keystroke, and shows the reader exactly the geometry the
- * engine computed — the same page boxes, the same column widths, the same wrapped lines.
- *
- * Pure, and returns a string: no DOM, no React, so it runs in a test and on a server.
- *
- * Everything is positioned from the numbers already in the document. Nothing here decides a width
- * or re-wraps a line — if the preview and the PDF ever disagree, the renderer is at fault, not
- * the engine.
- */
-import type { PagedDocument } from '../../../../published/dcs-ui/src/publicTypes';
-export interface HtmlRenderOptions {
-    /**
-     * Draw the page edges and a shadow. On for a designer preview, off when the output is going
-     * to a printer, which supplies its own paper.
-     */
-    pageChrome?: boolean;
-    /** Space between pages in a preview, in points. Ignored when `pageChrome` is false. */
-    pageGapPt?: number;
-    /** Wrap the pages in a full HTML document rather than a fragment. */
-    standalone?: boolean;
-    /** Extra CSS, appended last. */
-    css?: string;
-}
-export declare const renderToHtml: (doc: PagedDocument, options?: HtmlRenderOptions) => string;

package/dist/types/shared-logic/src/report/renderers/pdfmake.d.ts

@@ -1,45 +0,0 @@
-/**
- * Report engine — paged document → pdfmake docDefinition.
- *
- * Pure: a docDefinition is data, so this needs no pdfmake at build time and none at test time.
- * The app hands the result to the FileEngine, which owns the fonts and the blob.
- *
- * THE RENDERER MAKES NO LAYOUT DECISIONS. Widths arrive in points, text arrives already wrapped,
- * page breaks are already chosen. That is the point: every historic overflow in this codebase
- * came from a planner guessing what pdfmake would do with `'auto'` and `'*'` and pdfmake deciding
- * otherwise. Give pdfmake numbers and there is nothing left to disagree about.
- *
- * LINES ARE DRAWN ONLY WHERE THE LAYOUT PUT THEM. A table border adds height and width the planner
- * must count, and invisible height is the whole bug class this engine exists to remove. So nothing
- * here decides a line: a ruled row arrives with its `border` already in its measured height and its
- * cells' widths, and becomes a one-row table drawing exactly those lines. Every other table is drawn
- * with no lines at all.
- */
-import type { PagedDocument } from '../../../../published/dcs-ui/src/publicTypes';
-/** What pdfmake can and cannot do with this document, so callers can warn rather than discover. */
-export declare const PDFMAKE_CAPABILITIES: {
-    readonly italic: true;
-    readonly strike: true;
-    readonly colour: true;
-    /** pdfmake draws QR natively but has no barcode symbology — the value prints as text. */
-    readonly barcode: false;
-    readonly qr: true;
-    readonly image: true;
-};
-export interface PdfMakeRenderOptions {
-    /** Used only when the template draws no watermark of its own. */
-    watermark?: {
-        text: string;
-        opacity?: number;
-        color?: string;
-    };
-    defaultFontSize?: number;
-}
-/**
- * Turns a paged document into a docDefinition.
- *
- * Page bands are emitted INLINE, not through pdfmake's `header`/`footer` callbacks: the planner
- * already reserved their height in the content area, and pdfmake's callbacks draw into the page
- * margin, which would put them in a different place than the one that was measured.
- */
-export declare const renderToPdfMake: (doc: PagedDocument, opts?: PdfMakeRenderOptions) => any;

package/dist/types/shared-logic/src/report/resolve.d.ts

@@ -1,40 +0,0 @@
-/**
- * Report engine — turning template text into printed text.
- *
- * `%source.key%` substitution, per-placeholder formatting, and the `%agg.*%` calls. This is the
- * whole of the "language": there is no arithmetic, no conditionals inside text, no functions
- * beyond the fixed aggregates.
- */
-import type { PlaceholderFormat, PlaceholderFormats, ReportRegistry } from '../../../published/dcs-ui/src/publicTypes';
-import { type ResolveScope } from './scope';
-/**
- * A placeholder is `%<source>.<field>%` — the leading identifier and the dot are REQUIRED.
- *
- * Matching any `%...%` looked simpler and is wrong for a product non-developers author: "50% off,
- * GST% included" would be read as a placeholder called `off, GST` and reported as an error. Every
- * real placeholder has a dot (`row.x`, `page.x`, `agg.sum(row.x)`), so requiring one costs nothing
- * and makes a literal percent sign safe to type.
- */
-export declare const PLACEHOLDER: RegExp;
-/**
- * Field defaults from the registry, so a template that says nothing about formatting still gets
- * two decimals on money and `dd-mm-yyyy` on a date. Built once per table, not per placeholder.
- */
-export type FormatLookup = (path: string) => PlaceholderFormat | undefined;
-export declare const buildFormatLookup: (registry: ReportRegistry, rowSet?: string) => FormatLookup;
-export interface ResolveOptions {
-    /** Per-placeholder overrides authored on the segment or cell line. */
-    formats?: PlaceholderFormats;
-    /** Registry defaults. */
-    lookup?: FormatLookup;
-    /** A format for every placeholder with none of its own — a column's, a cell's. Beats the registry. */
-    format?: PlaceholderFormat;
-}
-/**
- * Substitutes every placeholder in `content`.
- *
- * An unresolvable placeholder renders as empty, not as the literal `%foo.bar%`. Printing the
- * token on a customer's invoice is worse than printing nothing, and validation is where a bad
- * path is supposed to be caught.
- */
-export declare const resolveText: (content: string, scope: ResolveScope, opts?: ResolveOptions) => string;

package/dist/types/shared-logic/src/report/scope.d.ts

@@ -1,52 +0,0 @@
-/**
- * Report engine — what a placeholder can see.
- *
- * Every `%a.b%` in a template, and every condition rule, is resolved against one of these. Keeping
- * the lookup in a single function is what makes the addressable surface knowable — and therefore
- * what makes a field picker and a validator possible at all.
- */
-export type ScopeRow = Record<string, unknown>;
-/** One gathered value of a grouping row — a colour of an item — as a placeholder sees it. */
-export interface GroupScope {
-    key: string;
-    label: string;
-    order: number;
-    /** The fields of the rows it gathered: summed where the table said so, otherwise first-seen. */
-    values: ScopeRow;
-    /** The lookup row that named it, when the table has a lookup. */
-    lookup?: ScopeRow;
-}
-export interface ResolveScope {
-    /** Scalar bags declared as `SourceDef`s: `%business.name%`. */
-    sources: Record<string, Record<string, unknown>>;
-    /** The current table row: `%row.total%`. */
-    row?: ScopeRow;
-    /** The current group value: `%group.label%`, `%group.qty%`, `%group.lookup.name%`. */
-    group?: GroupScope;
-    /** Filled by the layout engine: `%page.number%`, `%page.count%`. */
-    page?: {
-        number: number;
-        count: number;
-    };
-    /** Registry `computed` values, already evaluated: `%computed.isIgst%`. */
-    computed?: Record<string, unknown>;
-    /** Print options, defaults already applied: `%option.taxTable%`. */
-    options?: Record<string, unknown>;
-    /** Rows `agg.fn(row.x)` covers — a table's, or one section's. The layout engine narrows this. */
-    aggRows?: ScopeRow[];
-    /** Group values `agg.fn(group.x)` covers — one generated column's, across the table's rows. */
-    aggGroups?: ScopeRow[];
-    /** Every row set as passed, for `agg.fn(items.x)`. */
-    rowSets?: Record<string, ScopeRow[]>;
-}
-/** The rows an aggregate call covers in this scope. */
-export declare const aggregateRows: (over: string, scope: ResolveScope) => ScopeRow[];
-/**
- * `a.b` → value.
- *
- * Returns `undefined` for an unknown path rather than throwing: a template may legitimately name
- * a field the current context has no value for (a shipping address on an invoice with none), and
- * *formatting* decides what that prints as. Validation is what catches paths that can never
- * resolve — that is a different job, done once, not per render.
- */
-export declare const readPath: (path: string, scope: ResolveScope) => unknown;

package/dist/types/shared-logic/src/report/storage.d.ts

@@ -1,112 +0,0 @@
-/**
- * Quoin — seeds, diffs, and the settings document.
- *
- * A shipped format is a SEED: a `ReportTemplate` that lives in code. What a customer saves is the
- * DIFFERENCE from that seed, keyed by template id in one settings document, the way every settings
- * document here is written. Two things follow, and they are the whole point (`docs/REPORT_ENGINE.md` §8):
- *
- *   - A seed can be improved and the improvement reaches every customer who did not touch that
- *     part of it. Ship a better totals block; a shop that only moved its logo gets the better one.
- *   - "this customer wants the lorry number under the address" is a field in the database, not a file in the
- *     repository. No format is ever forked again.
- *
- * GRANULARITY IS THE WHOLE TOP-LEVEL KEY, and that is a decision rather than a shortcut. `bands`
- * and `columns` are arrays: an element-wise diff would have to answer "the seed grew a band at
- * index 2 — where does the customer's edit at index 2 go?", and every answer is a guess. So a
- * customer who edits one band owns `bands` from then on and stops receiving seed changes to it,
- * while `page`, `dataset` and the rest keep flowing. Coarse and predictable beats clever and
- * occasionally wrong, for data nobody can inspect once it is out there.
- *
- * Pure: this decides what to write, the app writes it. `buildTemplateEntry` is handed a `clear()`
- * factory so a removed key can be a delete sentinel without this file ever
- * knowing what the database is.
- */
-import type { ReportTemplate, ReportTemplatesStoredMap, StoredReportTemplate } from '../../../published/dcs-ui/src/publicTypes';
-/** Where the templates document lives, relative to the business root. */
-export declare const REPORT_TEMPLATES_SETTINGS_DOC = "REPORTTEMPLATES";
-/**
- * The template keys a diff may carry.
- *
- * `id` is the map key and `schemaVersion` is the entry's, so neither is diffable — a second copy
- * of either is free to disagree with the first. `registry` is excluded on purpose: pointing a
- * customer's diff at a different data source is not a tweak of the shipped format, it is a
- * different report, and it would leave every band reading fields that no longer exist.
- */
-export declare const DIFFABLE_TEMPLATE_KEYS: readonly ["name", "description", "page", "options", "bands"];
-export type DiffableTemplateKey = typeof DIFFABLE_TEMPLATE_KEYS[number];
-export interface TemplateDiff {
-    /** Keys that differ from the seed, with the customer's value. */
-    set: Partial<ReportTemplate>;
-    /**
-     * Keys the customer has put back to the seed's value. Only meaningful against what is already
-     * stored — a merge write leaves a reverted value in place forever unless it is cleared.
-     */
-    clear: DiffableTemplateKey[];
-}
-/**
- * What differs between a template and its seed.
- *
- * With no seed there is nothing to compare against, so everything diffable is `set` — a standalone
- * template is stored whole. `previous` is what the document already holds, and decides which
- * reverted keys are worth clearing: clearing a key that was never stored writes a delete sentinel
- * for nothing.
- */
-export declare const diffTemplate: (current: ReportTemplate, seed: ReportTemplate | null | undefined, previous?: Partial<ReportTemplate>) => TemplateDiff;
-export interface EntryOptions {
-    /**
-     * Produces the value that removes a field. The app passes its database's field-delete sentinel; a test
-     * passes anything it likes. This is how a pure module writes a delete.
-     */
-    clear: () => unknown;
-    /** Merged into the entry — `updatedts`, `createdts`, whatever the app stamps. */
-    stamp?: Record<string, unknown>;
-    /** Defaults to the previous entry's value, then to true. */
-    active?: boolean;
-}
-/**
- * The entry to merge into the settings document under this template's id.
- *
- * Nested rather than flattened: `name` is both a template key and the obvious name for a piece of
- * entry metadata, and one of those collisions is all it takes to lose a customer's title.
- */
-export declare const buildTemplateEntry: (current: ReportTemplate, seed: ReportTemplate | null | undefined, previous: StoredReportTemplate | undefined, options: EntryOptions) => Record<string, unknown>;
-export interface TemplateLoadProblem {
-    templateId: string;
-    message: string;
-    /** true when the seed was rendered instead, false when the template is unusable. */
-    usedSeed: boolean;
-}
-export interface LoadedTemplate {
-    id: string;
-    template: ReportTemplate;
-    /** The seed it follows, if any. */
-    seed?: string;
-    active: boolean;
-    /** false for a shipped seed nobody has edited. */
-    customised: boolean;
-}
-/**
- * One stored entry resolved against its seed.
- *
- * NEVER THROWS. A settings document is customer data that no build ever sees; one entry written by
- * a newer app, or hand-edited in the console, must not take the whole picker down. A seeded entry
- * that cannot be resolved falls back to its seed — a shop that has just upgraded should get the
- * shipped format, not a blank page — and a standalone one is reported and dropped.
- */
-export declare const resolveStoredTemplate: (id: string, entry: StoredReportTemplate | undefined, seed: ReportTemplate | null | undefined) => {
-    template: ReportTemplate | null;
-    problem?: TemplateLoadProblem;
-};
-/**
- * Every template the app can offer: the shipped seeds, plus whatever the customer has stored.
- *
- * The union, not one or the other. A seed with no entry is offered as shipped; an entry with no
- * seed is a template the customer authored; an entry naming a seed that no longer exists is
- * reported rather than dropped silently, because that is a format someone is still printing.
- */
-export declare const loadReportTemplates: (stored: ReportTemplatesStoredMap | undefined, seeds: Record<string, ReportTemplate>) => {
-    templates: LoadedTemplate[];
-    problems: TemplateLoadProblem[];
-};
-/** Active templates only, in name order — what a picker should show. */
-export declare const activeReportTemplates: (loaded: LoadedTemplate[]) => LoadedTemplate[];

package/dist/types/shared-logic/src/report/validate.d.ts

@@ -1,28 +0,0 @@
-/**
- * Quoin — is this template coherent?
- *
- * Templates are edited by people who are not developers, so a mistake must arrive as a sentence,
- * not as a blank cell on a customer's invoice. That is the whole reason this exists: without it,
- * `%party.mobil%` is indistinguishable from a party with no mobile number — both print nothing.
- *
- * It runs in two places, and both matter:
- *   - in the designer, so a template cannot be SAVED broken;
- *   - before rendering, because a template that was valid can be invalidated later by the
- *     registry changing underneath it — a field renamed, a row set dropped.
- *
- * Errors mean the document will be wrong. Warnings mean it will probably look wrong. Nothing here
- * throws: a caller decides whether to refuse, to warn, or to render anyway.
- */
-import type { ReportRegistry, ReportTemplate } from '../../../published/dcs-ui/src/publicTypes';
-export type IssueSeverity = 'error' | 'warning';
-export interface ValidationIssue {
-    severity: IssueSeverity;
-    /** Dotted path to the offending part, e.g. `bands[2].blocks[0].columns[3].value`. */
-    at: string;
-    message: string;
-}
-export declare const validateTemplate: (template: ReportTemplate, registry: ReportRegistry) => ValidationIssue[];
-/** True when nothing would render wrong. Warnings do not block. */
-export declare const isTemplateValid: (issues: ValidationIssue[]) => boolean;
-/** One-per-line summary, for a console or a toast. */
-export declare const formatIssues: (issues: ValidationIssue[]) => string;

package/dist/types/shared-logic/src/ui/cellRules.logic.d.ts

@@ -1,67 +0,0 @@
-import type { CellRule, ConditionContext, EditableTableColumnDefinition } from '../../../published/dcs-ui/src/publicTypes';
-/**
- * Cell validation, decided purely.
- *
- * The table asks three questions and this answers all three without touching the DOM:
- * is THIS cell valid, is this ROW valid, and may a new row be created? Keeping it here is
- * what lets the same rules run in a test, in the API, or in a future mobile port — and it
- * is the reason a rule is `Condition`-shaped rather than a bespoke callback: a consumer
- * who already writes `disabled: { key: 'x', equals: 1 }` writes a rule the same way.
- */
-export interface ResolvedRule {
-    valid: boolean;
-    /** The first failing rule's message. */
-    message?: string;
-    severity: 'block' | 'warn';
-}
-/**
- * A cell's rules, in order; the first failure wins.
- *
- * `when` decides whether a rule APPLIES before `valid` decides whether it PASSES — that
- * split is what makes "min qty, but only when the item is stocked" expressible without a
- * second rule list.
- */
-export declare function resolveCellRules<T>(rules: Array<CellRule<T>> | undefined, rowData: T, defaultData: T, context?: ConditionContext): ResolvedRule;
-/** One column's rules, resolved for one row. */
-export declare function resolveColumnRules<T>(column: EditableTableColumnDefinition<T> | undefined, rowData: T, defaultData: T, rowIndex: number, cellindex: number, tableDataKey?: string): ResolvedRule;
-export interface RowRuleFailure {
-    cellindex: number;
-    message: string;
-    severity: 'block' | 'warn';
-}
-/** Every failing cell in a row, so a caller can report or jump to the first one. */
-export declare function resolveRowRules<T>(columns: Array<EditableTableColumnDefinition<T>>, rowData: T, defaultData: T, rowIndex: number, tableDataKey?: string): {
-    valid: boolean;
-    blocked: boolean;
-    failures: RowRuleFailure[];
-};
-/**
- * Is this row still empty?
- *
- * Compared against `defaultData`, not against "falsy": a Qty that defaults to 0 and a
- * checkbox that defaults to false are BLANK, while a 0 typed into a field whose default is
- * `''` is not. The row's own key is ignored — it is generated, never typed.
- */
-export declare function isRowBlank<T extends Record<string, any>>(row: T | undefined, defaultData: T, rowKey?: string): boolean;
-export interface CreateRowPolicy {
-    fixedRows?: boolean;
-    allowWhenBlankRow?: boolean;
-    allowWhenInvalid?: boolean;
-}
-export interface CreateRowDecision {
-    allowed: boolean;
-    /** Why not — for a message, and for tests that assert the REASON, not just the refusal. */
-    reason?: 'fixedRows' | 'blankRow' | 'invalidRow' | 'consumer';
-    /** The row a blocked caller should go to instead: the blank one, or the invalid one. */
-    focusRowIndex?: number;
-}
-/**
- * May a row be created right now?
- *
- * The default answers "not while a blank row is waiting" — holding Enter at the end of a
- * table used to append one empty row per press. Each half is a prop, because a table that
- * is a scratchpad may genuinely want the blanks.
- */
-export declare function canCreateRow<T extends Record<string, any>>(rows: T[], defaultData: T, policy: CreateRowPolicy, rowRules?: (rowIndex: number) => {
-    blocked: boolean;
-}, rowKey?: string): CreateRowDecision;

package/dist/types/shared-logic/src/ui/columnOrder.logic.d.ts

@@ -1,12 +0,0 @@
-/**
- * Merges a user's saved column order with the current config order.
- *
- * A column added to a report after the user saved their order is not in `saved`. It must
- * land where the config puts it — right after its nearest preceding config neighbour that
- * the user still has — not at the far right. Appending was the old behaviour, and it left
- * every new column stranded at the end until the user reordered or reset.
- *
- * Saved keys are kept in the user's order, including keys the config no longer has (the
- * table ignores them; dropping them here would silently rewrite the user's saved state).
- */
-export declare function mergeColumnOrder(saved: readonly string[], config: readonly string[]): string[];