@mohasinac/appkit 4.14.0 → 4.15.0

package/dist/features/store-extensions/schemas/listing-template-form.js

@@ -0,0 +1,87 @@
+/*
+ * WHY: `/store/listing-templates/[id]/edit` was a wholly broken page. The route
+ *      it calls — `/api/store/listing-templates/[id]` — did not exist, while
+ *      `src/constants/api.ts` defined the endpoint, the edit page called it
+ *      three times (GET on load, PATCH on save, DELETE), and the list page
+ *      rendered an Edit button pointing straight at it. A seller clicking Edit
+ *      got a page that 404'd on load, on save and on delete.
+ *      Root Cause #37's dead-route shape, with a real page and a real button
+ *      in front of it.
+ * WHAT: One schema for the listing-template form AND the route that receives
+ *       it, so the two cannot drift.
+ *
+ * ## `defaults` stays open on purpose
+ *
+ * It is a JSON blob of per-listing-type field defaults — the whole point is
+ * that it holds whatever fields the target listing type has. `z.record()`
+ * rather than a named shape: modelling it would mean restating every listing
+ * type's field set here, and getting that wrong strips a seller's saved
+ * defaults on the next save (`z.object()` drops unknown keys). The page
+ * already `JSON.parse`s it and reports malformed JSON.
+ *
+ * EXPORTS:
+ *   listingTemplateFormSchema, listingTemplateCreateSchema,
+ *   listingTemplateUpdateSchema, type ListingTemplateFormValues
+ *
+ * @tag domain:store-extensions
+ * @tag layer:schema
+ * @tag pattern:none
+ * @tag access:isomorphic
+ * @tag consumers:store/listing-templates pages,/api/store/listing-templates
+ * @tag sideEffects:none
+ */
+import { z } from "zod";
+import { annotate } from "../../shell/field-ui-meta";
+import { LISTING_TEMPLATE_TYPES } from "./firestore";
+import { firestoreValueSchema } from "../../../schemas/firestore-value";
+/**
+ * Derived from the runtime array, never restated. A hand-written copy here
+ * would be the eleventh independent enumeration of this union — and the tenth
+ * had already drifted, which is how `art`/`stickers` came to be unsaveable as
+ * templates while `bundle` lingered.
+ */
+const listingTemplateTypeSchema = z.enum(LISTING_TEMPLATE_TYPES);
+/**
+ * 🛑 `annotate()` must be the OUTERMOST call on each field — it keys a WeakMap
+ * by schema instance and every zod wrapper returns a new one.
+ */
+export const listingTemplateFormSchema = z.object({
+    name: annotate(z.string().min(1, "Name is required").max(120, "Keep the name under 120 characters."), {
+        section: "basics", sectionLabel: "Template", sectionRequired: true,
+        quick: true, order: 1, row: "full",
+    }),
+    description: annotate(z.string().max(500, "Keep the description under 500 characters.").optional(), {
+        section: "basics", order: 2, row: "full",
+    }),
+    listingType: annotate(listingTemplateTypeSchema, {
+        section: "basics", quick: true, order: 3, row: "pair",
+    }),
+    // Typed as a Firestore value tree, not `unknown`: `unknown` does not satisfy
+    // `ListingTemplateDocument.defaults` (a `FirestoreDocument`), and casting at
+    // the repository call to paper over that would defeat the only type-level
+    // signal that the shapes agree.
+    defaults: annotate(z.record(firestoreValueSchema), {
+        section: "defaults", sectionLabel: "Default field values",
+        order: 1, row: "full", kind: "list",
+        help: "JSON applied to a new listing when this template is chosen.",
+    }),
+    isShared: annotate(z.boolean(), {
+        section: "visibility", sectionLabel: "Visibility", order: 1, row: "quarter",
+    }),
+    isActive: annotate(z.boolean(), {
+        section: "visibility", order: 2, row: "quarter",
+    }),
+});
+/**
+ * Create contract. `storeId`/`ownerId` are deliberately absent: the route sets
+ * both from the session, so a caller cannot create a template inside someone
+ * else's store by adding a field to the body.
+ */
+export const listingTemplateCreateSchema = listingTemplateFormSchema.partial({
+    description: true,
+    isShared: true,
+    isActive: true,
+    defaults: true,
+});
+/** Update contract — every field optional, and the same ownership fields absent. */
+export const listingTemplateUpdateSchema = listingTemplateFormSchema.partial();

package/dist/features/store-extensions/schemas/moderation-review-form.d.ts

@@ -0,0 +1,49 @@
+import { z } from "zod";
+/**
+ * The statuses a human review can produce.
+ *
+ * `satisfies readonly ModerationStatus[]` is load-bearing: it is what stops
+ * this becoming an independent, drifting copy of the union.
+ */
+export declare const MODERATION_REVIEWER_STATUSES: readonly ["approved", "rejected"];
+/**
+ * 🛑 `annotate()` must be the OUTERMOST call on each field — it keys a WeakMap
+ * by schema instance and every zod wrapper returns a new one.
+ */
+export declare const moderationReviewFormSchema: z.ZodEffects<z.ZodObject<{
+    status: z.ZodEnum<["approved", "rejected"]>;
+    reason: z.ZodOptional<z.ZodString>;
+}, "strict", z.ZodTypeAny, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}>, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}>;
+export type ModerationReviewFormValues = z.infer<typeof moderationReviewFormSchema>;
+/**
+ * Route contract. Identical to the form contract — a review is a single
+ * atomic decision, so there is no partial variant.
+ */
+export declare const moderationReviewUpdateSchema: z.ZodEffects<z.ZodObject<{
+    status: z.ZodEnum<["approved", "rejected"]>;
+    reason: z.ZodOptional<z.ZodString>;
+}, "strict", z.ZodTypeAny, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}>, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}, {
+    status: "approved" | "rejected";
+    reason?: string | undefined;
+}>;

package/dist/features/store-extensions/schemas/moderation-review-form.js

@@ -0,0 +1,101 @@
+/*
+ * WHY: `PATCH /api/admin/moderation/[id]` spread the raw request body straight
+ *      into Firestore:
+ *
+ *          const body = await parseJsonBody<Record<string, JsonValue>>(request);
+ *          await moderationQueueRepository.update(id, { ...body, reviewerId, reviewedAt });
+ *
+ *      There was no Zod anywhere on this path — not on the route, not on
+ *      either of the two client surfaces that call it. Under `ROLES_ADMIN_MOD`
+ *      a caller could write ANY key onto a moderation record, including
+ *      `entityId`, `ownerId`, `submittedAt` or an invented one, and could set
+ *      `status` to any string at all — the real `ModerationStatus` union was
+ *      never consulted.
+ *
+ *      Two client surfaces call it and neither validated: the queue page's
+ *      inline Approve/Reject controls and `ModerationDetailActions`. Both let
+ *      a rejection be submitted with an EMPTY reason, so content could be
+ *      blocked with no record of why.
+ * WHAT: One schema shared by the route and both client surfaces.
+ *
+ * ## A reviewer may only set the two statuses a REVIEW produces
+ *
+ * `ModerationStatus` has four values, but `pending` is the initial state and
+ * `auto-approved` is what the system writes when nothing needed a human. A
+ * reviewer setting either by hand would be falsifying the record — so the
+ * settable set is the subset below, declared `satisfies readonly
+ * ModerationStatus[]` rather than restated, which makes a value outside the
+ * real union a COMPILE error instead of a filter that matches nothing
+ * (Recurrent Root Cause #33).
+ *
+ * ## `reviewerId` / `reviewedAt` are absent on purpose
+ *
+ * The route sets both from the session and the server clock. Accepting them
+ * here would let a caller attribute a review to somebody else, or backdate it.
+ *
+ * EXPORTS:
+ *   moderationReviewFormSchema, moderationReviewUpdateSchema,
+ *   MODERATION_REVIEWER_STATUSES, type ModerationReviewFormValues
+ *
+ * @tag domain:store-extensions,moderation
+ * @tag layer:schema
+ * @tag pattern:none
+ * @tag access:isomorphic
+ * @tag consumers:admin/moderation pages,/api/admin/moderation/[id]
+ * @tag sideEffects:none
+ */
+import { z } from "zod";
+import { annotate } from "../../shell/field-ui-meta";
+/**
+ * The statuses a human review can produce.
+ *
+ * `satisfies readonly ModerationStatus[]` is load-bearing: it is what stops
+ * this becoming an independent, drifting copy of the union.
+ */
+export const MODERATION_REVIEWER_STATUSES = [
+    "approved",
+    "rejected",
+];
+/**
+ * 🛑 `annotate()` must be the OUTERMOST call on each field — it keys a WeakMap
+ * by schema instance and every zod wrapper returns a new one.
+ */
+export const moderationReviewFormSchema = z
+    .object({
+    status: annotate(z.enum(MODERATION_REVIEWER_STATUSES), {
+        section: "review",
+        sectionLabel: "Review decision",
+        sectionRequired: true,
+        quick: true,
+        order: 1,
+        row: "pair",
+    }),
+    reason: annotate(z.string().max(500, "Keep the reason under 500 characters.").optional(), {
+        section: "review",
+        order: 2,
+        row: "full",
+        kind: "textarea",
+        help: "Required when rejecting — this is the record of why the media was blocked.",
+    }),
+})
+    // Unknown keys are a 400, not a silent drop. A plain `z.object()` would
+    // STRIP them, which is the quieter half of the same bug: the caller is told
+    // the write succeeded and the key it sent simply vanished.
+    .strict()
+    .superRefine((v, ctx) => {
+    // An approval needs no justification; a rejection does. Blocking someone's
+    // media with an empty `reason` leaves the owner, and the next reviewer,
+    // with no way to know what was wrong with it.
+    if (v.status === "rejected" && !v.reason?.trim()) {
+        ctx.addIssue({
+            code: z.ZodIssueCode.custom,
+            path: ["reason"],
+            message: "Give a reason for the rejection.",
+        });
+    }
+});
+/**
+ * Route contract. Identical to the form contract — a review is a single
+ * atomic decision, so there is no partial variant.
+ */
+export const moderationReviewUpdateSchema = moderationReviewFormSchema;

package/dist/features/store-extensions/schemas/payout-method-form.d.ts

@@ -0,0 +1,153 @@
+import { z } from "zod";
+/**
+ * 🛑 `annotate()` must be the OUTERMOST call on each field — it keys a WeakMap
+ * by schema instance and every zod wrapper returns a new one.
+ */
+export declare const payoutMethodFormSchema: z.ZodEffects<z.ZodObject<{
+    type: z.ZodEnum<["upi", "bank", "card", "other"]>;
+    label: z.ZodString;
+    upiVpa: z.ZodOptional<z.ZodString>;
+    accountHolderName: z.ZodOptional<z.ZodString>;
+    accountNumber: z.ZodOptional<z.ZodString>;
+    ifscCode: z.ZodOptional<z.ZodString>;
+    bankName: z.ZodOptional<z.ZodString>;
+    isDefault: z.ZodBoolean;
+    isActive: z.ZodBoolean;
+}, "strip", z.ZodTypeAny, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}>, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}>;
+export type PayoutMethodFormValues = z.infer<typeof payoutMethodFormSchema>;
+/**
+ * Create contract. `sellerId`/`storeId` are absent on purpose — the route sets
+ * both from the session, so a caller cannot file a payout method against
+ * another seller by adding fields to the body.
+ */
+export declare const payoutMethodCreateSchema: z.ZodEffects<z.ZodObject<{
+    type: z.ZodEnum<["upi", "bank", "card", "other"]>;
+    label: z.ZodString;
+    upiVpa: z.ZodOptional<z.ZodString>;
+    accountHolderName: z.ZodOptional<z.ZodString>;
+    accountNumber: z.ZodOptional<z.ZodString>;
+    ifscCode: z.ZodOptional<z.ZodString>;
+    bankName: z.ZodOptional<z.ZodString>;
+    isDefault: z.ZodBoolean;
+    isActive: z.ZodBoolean;
+}, "strip", z.ZodTypeAny, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}>, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}, {
+    type: "card" | "other" | "upi" | "bank";
+    label: string;
+    isDefault: boolean;
+    isActive: boolean;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}>;
+/**
+ * Update contract.
+ *
+ * The per-type rules deliberately do NOT apply here: a PATCH may carry a
+ * single field (`isDefault`, say) and requiring the whole bank block on every
+ * partial update would make toggling the default impossible. The bounds still
+ * apply to whatever IS sent, and the create path is where completeness is
+ * enforced.
+ */
+export declare const payoutMethodUpdateSchema: z.ZodObject<{
+    type: z.ZodOptional<z.ZodEnum<["upi", "bank", "card", "other"]>>;
+    label: z.ZodOptional<z.ZodString>;
+    upiVpa: z.ZodOptional<z.ZodString>;
+    accountHolderName: z.ZodOptional<z.ZodString>;
+    accountNumber: z.ZodOptional<z.ZodString>;
+    ifscCode: z.ZodOptional<z.ZodString>;
+    bankName: z.ZodOptional<z.ZodString>;
+    isDefault: z.ZodOptional<z.ZodBoolean>;
+    isActive: z.ZodOptional<z.ZodBoolean>;
+}, "strict", z.ZodTypeAny, {
+    type?: "card" | "other" | "upi" | "bank" | undefined;
+    label?: string | undefined;
+    isDefault?: boolean | undefined;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    isActive?: boolean | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}, {
+    type?: "card" | "other" | "upi" | "bank" | undefined;
+    label?: string | undefined;
+    isDefault?: boolean | undefined;
+    accountHolderName?: string | undefined;
+    ifscCode?: string | undefined;
+    bankName?: string | undefined;
+    isActive?: boolean | undefined;
+    accountNumber?: string | undefined;
+    upiVpa?: string | undefined;
+}>;

package/dist/features/store-extensions/schemas/payout-method-form.js

@@ -0,0 +1,155 @@
+/*
+ * WHY: A seller's payout method is where their money goes, and it was
+ *      validated at ZERO layers. Measured 2026-08-24:
+ *        · `store/payout-methods/new` — `accountNumber` and `ifscCode` are
+ *          bare <Input>s with no `required` and no pattern; `onSave` has no
+ *          validation at all and posts `form as Record<string, unknown>`.
+ *          Both default to `""`, so an empty bank payout method saved cleanly.
+ *        · `.../[id]/edit` — `onSave` has no validation either, and does not
+ *          even render the account-number/IFSC inputs.
+ *        · `POST /api/store/payout-methods` — `parseJsonBody` then `...body`
+ *          spread into `.create()`. No Zod.
+ *        · `PATCH .../[id]` — the raw body passed straight to `.update()`.
+ *          No Zod, no field filtering.
+ *      A payout method with a blank account number is not a validation nicety;
+ *      it is a payout that cannot be made, discovered at payout time.
+ * WHAT: One schema for the pages AND the routes.
+ *
+ * ## The rules are per TYPE, which is why this needs a superRefine
+ *
+ * A UPI method needs a VPA and no bank fields; a bank method needs an account
+ * number, an IFSC and a holder name and no VPA. Per-field `.min(1)` cannot
+ * express that — it would make every field mandatory for every type.
+ *
+ * The IFSC and UPI patterns are the ones already used by
+ * `SellerPayoutSettingsView` (`^[A-Z]{4}0[A-Z0-9]{6}$` and the VPA shape), not
+ * a second pair invented here — two regexes for one format is how they come to
+ * disagree about what a valid IFSC is.
+ *
+ * EXPORTS:
+ *   payoutMethodFormSchema, payoutMethodCreateSchema,
+ *   payoutMethodUpdateSchema, type PayoutMethodFormValues
+ *
+ * @tag domain:store-extensions
+ * @tag layer:schema
+ * @tag pattern:none
+ * @tag access:isomorphic
+ * @tag consumers:store/payout-methods pages,/api/store/payout-methods
+ * @tag sideEffects:none
+ */
+import { z } from "zod";
+import { annotate } from "../../shell/field-ui-meta";
+/** Same pattern `SellerPayoutSettingsView` enforces. */
+const IFSC_RE = /^[A-Z]{4}0[A-Z0-9]{6}$/;
+/** Same pattern `SellerPayoutSettingsView` enforces. */
+const UPI_VPA_RE = /^[\w.\-_]{2,256}@[a-zA-Z]{2,64}$/;
+/**
+ * 🛑 `annotate()` must be the OUTERMOST call on each field — it keys a WeakMap
+ * by schema instance and every zod wrapper returns a new one.
+ */
+export const payoutMethodFormSchema = z
+    .object({
+    type: annotate(z.enum(["upi", "bank", "card", "other"]), {
+        section: "method", sectionLabel: "Payout Method", sectionRequired: true,
+        quick: true, order: 1, row: "pair",
+    }),
+    label: annotate(z.string().min(1, "Give this method a name you'll recognise.").max(80), {
+        section: "method", quick: true, order: 2, row: "pair",
+    }),
+    upiVpa: annotate(z.string().max(256).optional(), {
+        section: "method", order: 3, row: "full",
+        help: "For UPI methods, e.g. name@bank.",
+    }),
+    accountHolderName: annotate(z.string().max(120).optional(), {
+        section: "bank", sectionLabel: "Bank Account", order: 1, row: "full",
+    }),
+    accountNumber: annotate(z.string().max(34).optional(), {
+        section: "bank", order: 2, row: "pair",
+    }),
+    ifscCode: annotate(z.string().max(11).optional(), {
+        section: "bank", order: 3, row: "pair",
+    }),
+    bankName: annotate(z.string().max(120).optional(), {
+        section: "bank", order: 4, row: "pair",
+    }),
+    isDefault: annotate(z.boolean(), {
+        section: "visibility", sectionLabel: "Visibility", order: 1, row: "quarter",
+    }),
+    isActive: annotate(z.boolean(), {
+        section: "visibility", order: 2, row: "quarter",
+    }),
+})
+    .superRefine((v, ctx) => {
+    const issue = (path, message) => ctx.addIssue({ code: z.ZodIssueCode.custom, path: [path], message });
+    /**
+     * "Required, and if present the right shape" — the same two-part check
+     * every one of these fields needs. One helper rather than a required
+     * branch plus a format branch per field, which is what turned this into
+     * an unreadable if/else chain.
+     */
+    const require = (path, raw, missing, format) => {
+        const value = raw?.trim() ?? "";
+        if (!value)
+            return issue(path, missing);
+        if (!format)
+            return;
+        const candidate = format.normalise ? format.normalise(value) : value;
+        if (!format.re.test(candidate))
+            issue(path, format.message);
+    };
+    // Per-type rules by lookup, not by branching. A new payout type adds an
+    // entry here rather than another arm of a chain.
+    const RULES = {
+        upi: () => require("upiVpa", v.upiVpa, "A UPI ID is required for a UPI payout method.", {
+            re: UPI_VPA_RE,
+            message: "Please enter a valid UPI ID, e.g. name@bank.",
+        }),
+        // These four are what make a payout actually possible. Every one of them
+        // could previously be left blank and saved.
+        bank: () => {
+            require("accountHolderName", v.accountHolderName, "The account holder's name is required.");
+            require("accountNumber", v.accountNumber, "An account number is required.", {
+                re: /^\d{6,18}$/,
+                message: "An account number is 6–18 digits.",
+            });
+            require("ifscCode", v.ifscCode, "An IFSC code is required.", {
+                re: IFSC_RE,
+                message: "Please enter a valid IFSC code, e.g. HDFC0001234.",
+                normalise: (x) => x.toUpperCase(),
+            });
+            require("bankName", v.bankName, "The bank name is required.");
+        },
+        // `card` and `other` carry no extra requirements today — the label is
+        // enough to identify them, and inventing rules for them would reject
+        // methods sellers can legitimately record.
+    };
+    RULES[v.type]?.();
+});
+/**
+ * Create contract. `sellerId`/`storeId` are absent on purpose — the route sets
+ * both from the session, so a caller cannot file a payout method against
+ * another seller by adding fields to the body.
+ */
+export const payoutMethodCreateSchema = payoutMethodFormSchema;
+/**
+ * Update contract.
+ *
+ * The per-type rules deliberately do NOT apply here: a PATCH may carry a
+ * single field (`isDefault`, say) and requiring the whole bank block on every
+ * partial update would make toggling the default impossible. The bounds still
+ * apply to whatever IS sent, and the create path is where completeness is
+ * enforced.
+ */
+export const payoutMethodUpdateSchema = z
+    .object({
+    type: z.enum(["upi", "bank", "card", "other"]).optional(),
+    label: z.string().min(1).max(80).optional(),
+    upiVpa: z.string().max(256).regex(UPI_VPA_RE, "Please enter a valid UPI ID.").optional(),
+    accountHolderName: z.string().max(120).optional(),
+    accountNumber: z.string().regex(/^\d{6,18}$/, "An account number is 6–18 digits.").optional(),
+    ifscCode: z.string().regex(IFSC_RE, "Please enter a valid IFSC code.").optional(),
+    bankName: z.string().max(120).optional(),
+    isDefault: z.boolean().optional(),
+    isActive: z.boolean().optional(),
+})
+    .strict();

package/dist/features/store-extensions/schemas/report-create-form.d.ts

@@ -0,0 +1,25 @@
+import { z } from "zod";
+/**
+ * 🛑 `annotate()` must be the OUTERMOST call on each field — it keys a WeakMap
+ * by schema instance and every zod wrapper returns a new one.
+ */
+export declare const reportCreateSchema: z.ZodObject<{
+    entityType: z.ZodEnum<[import("./firestore").ReportEntityType, ...import("./firestore").ReportEntityType[]]>;
+    entityId: z.ZodString;
+    reason: z.ZodEnum<[import("./firestore").ReportReason, ...import("./firestore").ReportReason[]]>;
+    detail: z.ZodString;
+    evidenceUrls: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
+}, "strict", z.ZodTypeAny, {
+    reason: import("./firestore").ReportReason;
+    entityId: string;
+    entityType: import("./firestore").ReportEntityType;
+    detail: string;
+    evidenceUrls?: string[] | undefined;
+}, {
+    reason: import("./firestore").ReportReason;
+    entityId: string;
+    entityType: import("./firestore").ReportEntityType;
+    detail: string;
+    evidenceUrls?: string[] | undefined;
+}>;
+export type ReportCreateValues = z.infer<typeof reportCreateSchema>;

package/dist/features/store-extensions/schemas/report-create-form.js

@@ -0,0 +1,79 @@
+/*
+ * WHY: `POST /api/reports` — the surface any signed-in user files an abuse
+ *      report through — spread the raw request body into Firestore:
+ *
+ *          const body = await parseJsonBody<Record<string, JsonValue>>(request);
+ *          await reportsRepository.create({ ...body, reporterId, reporterEmail, status: "pending" });
+ *
+ *      Nothing was checked. Two distinct consequences:
+ *
+ *      1. An EMPTY report could be filed. `entityType`, `entityId`, `reason`
+ *         and `detail` are what make a report actionable and none was
+ *         required, so a row could reach the moderation queue naming nothing
+ *         and describing nothing.
+ *      2. A reporter could set fields that belong to the REVIEWER — a body
+ *         carrying `assignedTo`, `resolution` or `resolvedAt` was written
+ *         verbatim, so a user could file a report that already claimed to be
+ *         resolved by a named admin.
+ *
+ *      `status` was pinned server-side, which is the only reason (2) was not
+ *      worse than it is.
+ *
+ * WHAT: The create contract. Four required fields, evidence optional, and
+ *       nothing a reviewer owns.
+ *
+ * ## `reporterId` / `reporterEmail` / `status` are absent on purpose
+ *
+ * The route sets all three. Accepting `reporterId` would let one user file a
+ * report in another's name, which is a way to weaponise the abuse queue rather
+ * than a validation nicety.
+ *
+ * EXPORTS: reportCreateSchema, type ReportCreateValues
+ *
+ * @tag domain:store-extensions,reports
+ * @tag layer:schema
+ * @tag pattern:none
+ * @tag access:isomorphic
+ * @tag consumers:/api/reports
+ * @tag sideEffects:none
+ */
+import { z } from "zod";
+import { annotate } from "../../shell/field-ui-meta";
+import { REPORT_ENTITY_TYPES, REPORT_REASONS } from "./firestore";
+/**
+ * 🛑 `annotate()` must be the OUTERMOST call on each field — it keys a WeakMap
+ * by schema instance and every zod wrapper returns a new one.
+ */
+export const reportCreateSchema = z
+    .object({
+    entityType: annotate(z.enum(REPORT_ENTITY_TYPES), {
+        section: "target",
+        sectionLabel: "What are you reporting?",
+        sectionRequired: true,
+        quick: true,
+        order: 1,
+        row: "pair",
+    }),
+    entityId: annotate(z.string().min(1, "Tell us which item this is about."), {
+        section: "target",
+        quick: true,
+        order: 2,
+        row: "pair",
+    }),
+    reason: annotate(z.enum(REPORT_REASONS), {
+        section: "detail",
+        sectionLabel: "Why",
+        sectionRequired: true,
+        quick: true,
+        order: 1,
+        row: "pair",
+    }),
+    detail: annotate(z
+        .string()
+        .min(10, "Please describe the problem in at least 10 characters.")
+        .max(5000, "Keep the description under 5000 characters."), { section: "detail", quick: true, order: 2, row: "full", kind: "textarea" }),
+    // Capped: an unbounded array on a user-writable document is a way to grow
+    // one row past what a list read can afford (Rule #6).
+    evidenceUrls: annotate(z.array(z.string().url("Each piece of evidence must be a URL.")).max(10).optional(), { section: "detail", order: 3, row: "full", kind: "list" }),
+})
+    .strict();