@mohasinac/appkit 4.71.0 → 4.72.0

package/dist/_internal/server/features/parts/assembly.d.ts

@@ -1,126 +0,0 @@
-/** One component the assembly consumes. */
-export interface AssemblyComponent {
-    slotKey: string;
-    /** A part LISTING's id — a `ProductDocument`, not a `partGlossary` row. */
-    productId: string;
-    quantity: number;
-}
-export interface AssembleInput {
-    /** The store doing the assembly. Parts are `storeId`-scoped like any listing. */
-    storeId: string;
-    /** The complete-bey listing being created or restocked. */
-    targetProductId: string;
-    components: readonly AssemblyComponent[];
-    /** How many complete beys to build. */
-    units?: number;
-}
-export interface AssemblyResult {
-    targetProductId: string;
-    unitsBuilt: number;
-    /** Per component: what it had available, and what it has now. */
-    consumed: Array<{
-        productId: string;
-        before: number;
-        after: number;
-        taken: number;
-    }>;
-}
-/** The hard cap, matching the write schema's `.max(8)` on `assembledFrom`. */
-export declare const MAX_ASSEMBLY_COMPONENTS = 8;
-/**
- * 🛑 The fields read inside the transaction, named once.
- *
- * `availableQuantity` is the gate (see the header). `stockQuantity` is read
- * only so the reservation can be CARRIED FORWARD rather than discarded —
- * writing `availableQuantity` without adjusting `stockQuantity` by the same
- * amount would make `reserved` drift by exactly the units consumed, and
- * `resolveStockResync` would then hand those units back to the shelf on the
- * seller's next edit. That is A4's bug arriving through a new door.
- */
-interface StockSnapshot {
-    stockQuantity: number;
-    availableQuantity: number;
-    storeId?: string;
-}
-/** What a planner decided to write, before anything touches Firestore. */
-export interface StockWrite {
-    productId: string;
-    stockQuantity: number;
-    availableQuantity: number;
-}
-export interface AssemblyPlan {
-    writes: StockWrite[];
-    consumed: AssemblyResult["consumed"];
-    /** The complete-bey listing's own new figures. */
-    target: StockWrite;
-}
-/**
- * The whole decision, as a PURE function of the documents and the request.
- *
- * 🛑 Extracted because the arithmetic is the part most likely to be wrong and
- * the transaction is the part hardest to test. A fake Firestore cannot be
- * injected across an ESM namespace boundary — measured: `Object.defineProperty`
- * on the imported namespace throws, so a mock-based harness reported every
- * ordering assertion as green having executed none of them. Rather than
- * weaken the module with a test-only injection seam, the thing worth asserting
- * moved OUT of the transaction: which field gates the build, how the
- * reservation is carried, and what is refused.
- *
- * `direction` is `-1` for an assembly (components are consumed) and `+1` for a
- * part-out (components are produced), so there is ONE implementation of the
- * gate and the carry rather than two that must agree.
- */
-export declare function planAssembly(args: {
-    storeId: string;
-    /** The complete bey: consumed on part-out, produced on assembly. */
-    subject: {
-        productId: string;
-        doc: StockSnapshot | undefined;
-    };
-    components: ReadonlyArray<{
-        request: AssemblyComponent;
-        doc: StockSnapshot | undefined;
-    }>;
-    units: number;
-    /** -1 consumes the components (assemble); +1 produces them (part out). */
-    direction: -1 | 1;
-}): AssemblyPlan;
-/**
- * The input rules, shared by both directions so they cannot drift.
- *
- * Runs before any Firestore access, which is also why it is separable.
- */
-export declare function assertAssemblyInput(components: readonly AssemblyComponent[], units: number): void;
-/**
- * Build `units` copies of a complete bey, consuming its components.
- *
- * A thin shell over `planAssembly`: read everything, decide purely, write.
- *
- * Throws rather than partially succeeding —
- * - `ValidationError` — malformed, missing, or another store's listing.
- * - `ConflictError`   — a component does not have enough available. 409 and
- *   not 400: the request is well formed and the seller is not confused, the
- *   world changed under them, so the next action is to restock rather than to
- *   fix a field. Same distinction as removing a booked lottery slot.
- */
-export declare function assembleFromComponents(input: AssembleInput): Promise<AssemblyResult>;
-export interface PartOutInput {
-    storeId: string;
-    /** The complete bey being broken down. */
-    sourceProductId: string;
-    /** Which component listings receive the parts. */
-    components: readonly AssemblyComponent[];
-    units?: number;
-}
-/**
- * The inverse: decrement the bey, increment each component.
- *
- * 🛑 Spares arrive as whole beys too, so this is not a convenience — it is half
- * the workflow. Without it, "part out" would only work on beys this system
- * built, which is none of the current catalogue (GAP-10).
- *
- * Same planner, `direction: 1`. ONE implementation of the gate and the
- * reservation carry rather than two that must agree.
- */
-export declare function partOutToComponents(input: PartOutInput): Promise<AssemblyResult>;
-export {};

package/dist/_internal/server/features/parts/assembly.js

@@ -1,246 +0,0 @@
-import { unitOfWork } from "../../../../core/unit-of-work.js";
-import { PRODUCT_COLLECTION } from "../../../../features/products/schemas/firestore.js";
-import { getAdminDb } from "../../../../providers/db-firebase/index.js";
-import { serverLogger } from "../../../../monitoring/server-logger.js";
-import { ValidationError, ConflictError } from "../../../../errors/index.js";
-/** The hard cap, matching the write schema's `.max(8)` on `assembledFrom`. */
-export const MAX_ASSEMBLY_COMPONENTS = 8;
-const num = (v) => (typeof v === "number" && Number.isFinite(v) ? v : 0);
-/**
- * The whole decision, as a PURE function of the documents and the request.
- *
- * 🛑 Extracted because the arithmetic is the part most likely to be wrong and
- * the transaction is the part hardest to test. A fake Firestore cannot be
- * injected across an ESM namespace boundary — measured: `Object.defineProperty`
- * on the imported namespace throws, so a mock-based harness reported every
- * ordering assertion as green having executed none of them. Rather than
- * weaken the module with a test-only injection seam, the thing worth asserting
- * moved OUT of the transaction: which field gates the build, how the
- * reservation is carried, and what is refused.
- *
- * `direction` is `-1` for an assembly (components are consumed) and `+1` for a
- * part-out (components are produced), so there is ONE implementation of the
- * gate and the carry rather than two that must agree.
- */
-export function planAssembly(args) {
-    const { storeId, subject, components, units, direction } = args;
-    if (!subject.doc) {
-        throw new ValidationError(direction === -1
-            ? "The listing being assembled no longer exists."
-            : "The listing being parted out no longer exists.");
-    }
-    if (subject.doc.storeId && subject.doc.storeId !== storeId) {
-        throw new ValidationError("That listing belongs to another store.");
-    }
-    /*
-     * 🛑 On a PART-OUT the subject is what gets consumed, so it needs the same
-     * availability gate as a component: a bey with 2 in stock and 1 reserved can
-     * only have ONE parted out. On an assembly the subject only ever gains, so
-     * there is nothing to check.
-     */
-    const subjectAvailable = num(subject.doc.availableQuantity);
-    if (direction === 1 && subjectAvailable < units) {
-        throw new ConflictError(`Not enough available to part out: needs ${units}, has ${subjectAvailable}.`);
-    }
-    const consumed = [];
-    const writes = [];
-    for (const { request, doc } of components) {
-        if (!doc) {
-            throw new ValidationError(direction === -1
-                ? `A component is missing: ${request.productId}`
-                : `A destination component is missing: ${request.productId}`);
-        }
-        /*
-         * 🛑 Scoped to the caller's own store. An admin assembling from a seller's
-         * bins would be writing another store's inventory; the only legitimate
-         * version is `store-letitrip-official` using its OWN stock, which this
-         * already allows.
-         */
-        if (doc.storeId && doc.storeId !== storeId) {
-            throw new ValidationError(`A component belongs to another store: ${request.productId}`);
-        }
-        const delta = request.quantity * units * direction;
-        const available = num(doc.availableQuantity);
-        // 🛑 THE GATE, and it reads `availableQuantity` — see the file header.
-        if (direction === -1 && available < -delta) {
-            // 409, not 400: the request is well formed and the world changed.
-            // Figures in `data`, words in the client — see the part-out branch above.
-            throw new ConflictError(`component insufficient: needs ${-delta}, has ${available}`, "ASSEMBLY_INSUFFICIENT", { kind: "component", productId: request.productId, needs: -delta, has: available });
-        }
-        consumed.push({
-            productId: request.productId,
-            before: available,
-            after: available + delta,
-            taken: -delta,
-        });
-        writes.push({
-            productId: request.productId,
-            // Both fields move by the SAME amount, so an outstanding reservation is
-            // carried forward exactly rather than handed back to the shelf.
-            stockQuantity: Math.max(0, num(doc.stockQuantity) + delta),
-            availableQuantity: available + delta,
-        });
-    }
-    const subjectDelta = units * -direction;
-    return {
-        writes,
-        consumed,
-        target: {
-            productId: subject.productId,
-            stockQuantity: Math.max(0, num(subject.doc.stockQuantity) + subjectDelta),
-            availableQuantity: subjectAvailable + subjectDelta,
-        },
-    };
-}
-/**
- * The input rules, shared by both directions so they cannot drift.
- *
- * Runs before any Firestore access, which is also why it is separable.
- */
-export function assertAssemblyInput(components, units) {
-    if (!Number.isInteger(units) || units < 1 || units > 99) {
-        throw new ValidationError("Quantity must be a whole number between 1 and 99.");
-    }
-    if (components.length === 0) {
-        throw new ValidationError("An assembly needs at least one component.");
-    }
-    if (components.length > MAX_ASSEMBLY_COMPONENTS) {
-        throw new ValidationError(`An assembly may involve at most ${MAX_ASSEMBLY_COMPONENTS} components.`);
-    }
-    /*
-     * 🛑 Two entries for one product id would each be planned against the SAME
-     * read value and each subtract from it, so the second would silently
-     * overdraw. Refused rather than summed: a caller sending a product twice is
-     * describing something it does not mean, and summing would decide for them.
-     */
-    const seen = new Set();
-    for (const c of components) {
-        if (seen.has(c.productId)) {
-            throw new ValidationError("The same component appears twice. Combine it into one row with the total quantity.");
-        }
-        seen.add(c.productId);
-    }
-}
-/**
- * Build `units` copies of a complete bey, consuming its components.
- *
- * A thin shell over `planAssembly`: read everything, decide purely, write.
- *
- * Throws rather than partially succeeding —
- * - `ValidationError` — malformed, missing, or another store's listing.
- * - `ConflictError`   — a component does not have enough available. 409 and
- *   not 400: the request is well formed and the seller is not confused, the
- *   world changed under them, so the next action is to restock rather than to
- *   fix a field. Same distinction as removing a booked lottery slot.
- */
-export async function assembleFromComponents(input) {
-    const units = input.units ?? 1;
-    assertAssemblyInput(input.components, units);
-    const col = getAdminDb().collection(PRODUCT_COLLECTION);
-    return unitOfWork.runTransaction(async (tx) => {
-        // ── EVERY READ FIRST. Firestore requires it, and so does correctness. ──
-        const subjectRef = col.doc(input.targetProductId);
-        const componentRefs = input.components.map((c) => col.doc(c.productId));
-        const [subjectSnap, ...componentSnaps] = await tx.getAll(subjectRef, ...componentRefs);
-        const plan = planAssembly({
-            storeId: input.storeId,
-            subject: {
-                productId: input.targetProductId,
-                doc: subjectSnap.exists ? subjectSnap.data() : undefined,
-            },
-            components: input.components.map((request, i) => ({
-                request,
-                doc: componentSnaps[i].exists
-                    ? componentSnaps[i].data()
-                    : undefined,
-            })),
-            units,
-            direction: -1,
-        });
-        // ── WRITES ONLY AFTER EVERY READ ──────────────────────────────────────
-        const now = new Date();
-        for (const w of plan.writes) {
-            tx.update(col.doc(w.productId), {
-                stockQuantity: w.stockQuantity,
-                availableQuantity: w.availableQuantity,
-                updatedAt: now,
-            });
-        }
-        tx.update(subjectRef, {
-            stockQuantity: plan.target.stockQuantity,
-            availableQuantity: plan.target.availableQuantity,
-            assembledFrom: input.components.map((c) => ({ ...c })),
-            updatedAt: now,
-        });
-        serverLogger.info("assembleFromComponents", {
-            storeId: input.storeId,
-            targetProductId: input.targetProductId,
-            units,
-            components: plan.consumed.length,
-        });
-        return {
-            targetProductId: input.targetProductId,
-            unitsBuilt: units,
-            consumed: plan.consumed,
-        };
-    });
-}
-/**
- * The inverse: decrement the bey, increment each component.
- *
- * 🛑 Spares arrive as whole beys too, so this is not a convenience — it is half
- * the workflow. Without it, "part out" would only work on beys this system
- * built, which is none of the current catalogue (GAP-10).
- *
- * Same planner, `direction: 1`. ONE implementation of the gate and the
- * reservation carry rather than two that must agree.
- */
-export async function partOutToComponents(input) {
-    const units = input.units ?? 1;
-    assertAssemblyInput(input.components, units);
-    const col = getAdminDb().collection(PRODUCT_COLLECTION);
-    return unitOfWork.runTransaction(async (tx) => {
-        const subjectRef = col.doc(input.sourceProductId);
-        const componentRefs = input.components.map((c) => col.doc(c.productId));
-        const [subjectSnap, ...componentSnaps] = await tx.getAll(subjectRef, ...componentRefs);
-        const plan = planAssembly({
-            storeId: input.storeId,
-            subject: {
-                productId: input.sourceProductId,
-                doc: subjectSnap.exists ? subjectSnap.data() : undefined,
-            },
-            components: input.components.map((request, i) => ({
-                request,
-                doc: componentSnaps[i].exists
-                    ? componentSnaps[i].data()
-                    : undefined,
-            })),
-            units,
-            direction: 1,
-        });
-        const now = new Date();
-        for (const w of plan.writes) {
-            tx.update(col.doc(w.productId), {
-                stockQuantity: w.stockQuantity,
-                availableQuantity: w.availableQuantity,
-                updatedAt: now,
-            });
-        }
-        tx.update(subjectRef, {
-            stockQuantity: plan.target.stockQuantity,
-            availableQuantity: plan.target.availableQuantity,
-            updatedAt: now,
-        });
-        serverLogger.info("partOutToComponents", {
-            storeId: input.storeId,
-            sourceProductId: input.sourceProductId,
-            units,
-            components: plan.consumed.length,
-        });
-        return {
-            targetProductId: input.sourceProductId,
-            unitsBuilt: units,
-            consumed: plan.consumed,
-        };
-    });
-}

package/dist/_internal/server/features/parts/buildable.d.ts

@@ -1,47 +0,0 @@
-/** Part listings read per store. The same cap the assembly drawer uses. */
-export declare const BUILDABLE_HOLDINGS_LIMIT = 50;
-/**
- * Candidate models considered. A seller holding common Metal-era parts can
- * reach several hundred compositions through `usedBy`; this bounds the second
- * `getAll` and the answer is truncated rather than partial-and-silent.
- */
-export declare const BUILDABLE_CANDIDATE_LIMIT = 60;
-export interface BuildableSlot {
-    slotKey: string;
-    slotLabel: string;
-    partName: string;
-    partId?: string;
-    /** The colourway THIS model needs, when the corpus distinguishes one. */
-    expectedColourway?: string;
-    /** Complete units this slot alone could supply. */
-    buildable: number;
-}
-export interface BuildableModel {
-    compositionId: string;
-    name: string;
-    /** The named-model category, when the generator joined one. */
-    categoryId?: string;
-    /**
-     * How many COMPLETE units are buildable — the MINIMUM across slots, never a
-     * sum or an average: a bey missing one tip is not 80% of a bey.
-     */
-    buildable: number;
-    slots: BuildableSlot[];
-    /** Slot labels supplying zero. Named, because that is the shopping list. */
-    blockedBy: string[];
-}
-export interface BuildableResult {
-    models: BuildableModel[];
-    /** Distinct part listings considered. */
-    holdings: number;
-    /** A cap was hit, so the answer is a floor rather than the whole truth. */
-    truncated: boolean;
-}
-/**
- * What this store can build right now.
- *
- * Sorted by `buildable` descending and then by how close a blocked model is to
- * complete, so the useful answer ("you are one Spin Track away") is near the
- * top rather than buried under everything that is fully blocked.
- */
-export declare function listBuildableModels(storeId: string): Promise<BuildableResult>;

package/dist/_internal/server/features/parts/buildable.js

@@ -1,159 +0,0 @@
-/*
- * WHY: D13's last item — "which complete beys can I build RIGHT NOW from the
- *      parts I hold", answered server-side for one store.
- *
- * 🛑 THE DEFECT THIS IS SHAPED AROUND (I9). Matching a composition slot on
- *    `partGlossaryId` alone reports *"you can build an L-Drago Guardian
- *    S130MB"* when the only Metal Ball on the shelf is the Poison Zurafa's
- *    transparent-black one. One glossary row, same mould, same weight, same
- *    stats — two physical units that are not interchangeable and differ wildly
- *    in value, with no stat to tell them apart. A confident, specific, wrong
- *    answer with no error, discovered by the seller holding the wrong part.
- *
- *    So every match goes through `satisfiesSlot`, which keys on
- *    **(partGlossaryId, colourway)** and refuses a colour-unknown holding for a
- *    slot that names a colour — "unknown" is not evidence of the right colour.
- *
- * 🛑 THREE ROUND TRIPS, FLAT IN THE NUMBER OF PARTS HELD (Rule #6). The naive
- *    shape is one `getModelsUsingPart` per held part, which is N reads for a
- *    seller with N distinct parts. Instead: one bounded listing read, one
- *    `getAll` over the held glossary rows (whose `usedBy` the generator already
- *    wrote), one `getAll` over the candidate compositions. A seller with 3
- *    parts and a seller with 40 cost the same.
- *
- * @tag domain:parts
- * @tag layer:server-data
- * @tag access:server-only
- * @tag sideEffects:firestore-read
- */
-import { normalizeError } from "../../../../errors/normalize.js";
-import { serverLogger } from "../../../../monitoring/server-logger.js";
-import { getAdminDb } from "../../../../providers/db-firebase/index.js";
-import { MODEL_COMPOSITION_COLLECTION, PART_GLOSSARY_COLLECTION, } from "../../../../features/parts/schemas/firestore.js";
-import { matchSlotToHoldings, } from "../../../../features/parts/utils/colourway-match.js";
-import { ANY_STATUS, listPublicProducts } from "../products/list-public.js";
-/** Part listings read per store. The same cap the assembly drawer uses. */
-export const BUILDABLE_HOLDINGS_LIMIT = 50;
-/**
- * Candidate models considered. A seller holding common Metal-era parts can
- * reach several hundred compositions through `usedBy`; this bounds the second
- * `getAll` and the answer is truncated rather than partial-and-silent.
- */
-export const BUILDABLE_CANDIDATE_LIMIT = 60;
-/** Slots that carry no glossary id cannot be matched and are not required. */
-function requiredSlots(comp) {
-    return (comp.slots ?? []).filter((s) => typeof s.partId === "string" && s.partId.length > 0);
-}
-/**
- * What this store can build right now.
- *
- * Sorted by `buildable` descending and then by how close a blocked model is to
- * complete, so the useful answer ("you are one Spin Track away") is near the
- * top rather than buried under everything that is fully blocked.
- */
-export async function listBuildableModels(storeId) {
-    const empty = { models: [], holdings: 0, truncated: false };
-    if (!storeId)
-        return empty;
-    try {
-        const db = getAdminDb();
-        /* 1 — the seller's own part listings, through the SHARED query. */
-        const listing = await listPublicProducts({
-            storeId,
-            status: ANY_STATUS,
-            page: 1,
-            pageSize: BUILDABLE_HOLDINGS_LIMIT,
-        });
-        const holdings = (listing?.items ?? [])
-            .filter((row) => typeof row.partGlossaryId === "string")
-            .map((row) => ({
-            productId: String(row.id),
-            partGlossaryId: String(row.partGlossaryId),
-            availableQuantity: typeof row.availableQuantity === "number" ? row.availableQuantity : 0,
-            ...(typeof row.colourway === "string" ? { colourway: row.colourway } : {}),
-        }))
-            // A listing with nothing available cannot contribute to a build, and
-            // keeping it would make `blockedBy` name a part the seller "has".
-            .filter((h) => h.availableQuantity > 0);
-        if (holdings.length === 0) {
-            return { ...empty, truncated: listing?.truncated === true };
-        }
-        /* 2 — one `getAll` over the held glossary rows for their `usedBy`. */
-        const heldIds = [...new Set(holdings.map((h) => h.partGlossaryId).filter((id) => !!id))];
-        const glossaryCol = db.collection(PART_GLOSSARY_COLLECTION);
-        const partSnaps = await db.getAll(...heldIds.map((id) => glossaryCol.doc(id)));
-        const candidateIds = new Set();
-        for (const snap of partSnaps) {
-            if (!snap.exists)
-                continue;
-            for (const id of snap.data()?.usedBy ?? []) {
-                if (id)
-                    candidateIds.add(id);
-            }
-        }
-        if (candidateIds.size === 0) {
-            return { models: [], holdings: holdings.length, truncated: listing?.truncated === true };
-        }
-        const candidates = [...candidateIds];
-        const truncatedCandidates = candidates.length > BUILDABLE_CANDIDATE_LIMIT;
-        const take = truncatedCandidates ? candidates.slice(0, BUILDABLE_CANDIDATE_LIMIT) : candidates;
-        /* 3 — one `getAll` over those compositions. */
-        const compCol = db.collection(MODEL_COMPOSITION_COLLECTION);
-        const compSnaps = await db.getAll(...take.map((id) => compCol.doc(id)));
-        const models = [];
-        for (const snap of compSnaps) {
-            if (!snap.exists)
-                continue;
-            const comp = { id: snap.id, ...snap.data() };
-            const slots = requiredSlots(comp);
-            // A composition with no resolvable slot cannot be judged; claiming it is
-            // buildable from zero requirements would be the worst possible answer.
-            if (slots.length === 0)
-                continue;
-            const matched = slots.map((s) => {
-                const m = matchSlotToHoldings({
-                    // `SlotRequirement` is deliberately narrow: the matcher's whole
-                    // input is the (part, colourway) pair, so nothing else about the
-                    // slot can accidentally influence a match.
-                    ...(s.partId ? { partId: s.partId } : {}),
-                    ...(s.expectedColourway ? { expectedColourway: s.expectedColourway } : {}),
-                }, holdings);
-                return {
-                    slotKey: String(s.slotKey),
-                    slotLabel: s.slotLabel,
-                    partName: s.partName,
-                    ...(s.partId ? { partId: s.partId } : {}),
-                    ...(s.expectedColourway ? { expectedColourway: s.expectedColourway } : {}),
-                    buildable: m.buildable,
-                };
-            });
-            models.push({
-                compositionId: comp.id,
-                name: comp.name,
-                ...(comp.categoryId ? { categoryId: comp.categoryId } : {}),
-                buildable: Math.min(...matched.map((m) => m.buildable)),
-                slots: matched,
-                blockedBy: matched.filter((m) => m.buildable === 0).map((m) => m.slotLabel),
-            });
-        }
-        models.sort((a, b) => b.buildable - a.buildable ||
-            a.blockedBy.length - b.blockedBy.length ||
-            a.name.localeCompare(b.name));
-        return {
-            models,
-            holdings: holdings.length,
-            truncated: listing?.truncated === true || truncatedCandidates,
-        };
-    }
-    catch (err) {
-        const e = normalizeError(err);
-        /*
-         * Fails CLOSED-but-loud: an empty list with `truncated: true`, so a caller
-         * renders "we could not work this out" rather than the much worse
-         * "you can build nothing" — which a seller holding a full set would read as
-         * a bug in their inventory (Root Cause #59's lesson, applied to a rollup).
-         */
-        serverLogger.warn("listBuildableModels failed", { storeId, error: e.message });
-        return { models: [], holdings: 0, truncated: true };
-    }
-}

package/dist/_internal/server/features/parts/data.d.ts

@@ -1,65 +0,0 @@
-import { type PartGlossaryDocument, type ModelCompositionDocument, type PartSlot } from "../../../../features/parts/schemas/firestore";
-/** The bucket cap. 87 is the largest real classification, so this clears it. */
-export declare const PART_SLOT_PAGE_SIZE = 120;
-/** One part, by `(slot, code|name)` — the only key this collection has. */
-export declare const getPartByKey: (slot: PartSlot, codeOrName: string) => Promise<PartGlossaryDocument | null>;
-/**
- * The models that use a part, hydrated.
- *
- * 🛑 `getAll` over the ids the part ALREADY carries, not a query. `usedBy` is
- * written by the generator, so this is one round trip for N ids with no index
- * and no scan — and it is bounded by how many models actually use the part
- * (measured max: 20).
- */
-export declare const getModelsUsingPart: (partId: string) => Promise<ModelCompositionDocument[]>;
-/** One model's composition, by the corpus doc id. */
-export declare const getCompositionById: (id: string) => Promise<ModelCompositionDocument | null>;
-/**
- * Hydrate the glossary rows a composition's slots point at, so a model page can
- * link each slot and show its weight.
- *
- * ONE `getAll` for every slot — a per-slot read would be five round trips on a
- * page that already has its own.
- */
-export declare const getPartsForComposition: (compositionId: string) => Promise<Map<string, PartGlossaryDocument>>;
-/**
- * Compositions for a named-model CATEGORY.
- *
- * 🛑 ONE INDEXED EQUALITY on `categoryId`, joined at SEED-GENERATION time.
- *
- * The first version queried `searchTxt` on `modelComposition` — a field that
- * collection does not have, so it would have matched NOTHING while looking
- * like a working read. The two id spaces genuinely disagree
- * (`gen1-plastic-dragoon-f` vs `category-dragoon-f`), so a join is required;
- * doing it in the generator makes it deterministic, reviewable in the
- * committed seed, and one equality here instead of a name query.
- *
- * Measured: **210 of 259** compositions join. The join is on the normalised
- * name, and on the name with its parenthetical expansion removed — the corpus
- * titles HMS beys `Aero Knight MS (Aero Knight Metal Sky)` where the category
- * is "Aero Knight MS", and without that second form only 150 matched.
- *
- * 🛑 A non-match leaves `categoryId` unset and this returns `[]`, so the model
- * page shows no composition. That is honest: a fuzzy match could attach
- * ANOTHER bey's parts, and a wrong part list is worse than none. Reconciling
- * the remaining 49 is E3's job.
- */
-export declare const getCompositionsForCategory: (categoryId: string) => Promise<ModelCompositionDocument[]>;
-/**
- * Every part in one classification, alphabetical.
- *
- * 🛑 ONE equality on `slot`, bounded. The biggest bucket is 87 rows (attack
- * rings) and the smallest 4 (armour) — measured, not assumed — so a page size
- * of 120 shows every one of them today without a pager, and `truncated` tells
- * the view to stop claiming a total the moment that stops being true.
- *
- * Firestore needs no composite index for one equality plus an `orderBy` on
- * the SAME field it is already keyed by document id within… except it does
- * for `(slot ==, name asc)`. So the sort is applied IN MEMORY: 87 rows is
- * nothing to sort, and a declared index that exists only to order a bucket
- * this small is an index to deploy, wait on, and remember.
- */
-export declare const listPartsBySlot: (slot: PartSlot) => Promise<{
-    parts: PartGlossaryDocument[];
-    truncated: boolean;
-}>;