@mohasinac/appkit 4.75.0 → 4.77.0

package/dist/.build-stamp.json

@@ -1,8 +1,8 @@
 {
   "stampVersion": 1,
-  "version": "4.75.0",
-  "head": "c5426d7535f8b4331464486d52298a6f668168ee",
+  "version": "4.77.0",
+  "head": "ee1768658b3ff57e36d0b1dee443bb5cdb9dcea7",
   "branch": "main",
-  "dirty": true,
-  "builtAt": "2026-11-09T07:08:58.762Z"
+  "dirty": false,
+  "builtAt": "2026-11-09T10:56:48.056Z"
 }

package/dist/_internal/server/features/seo/sitemap.d.ts

@@ -58,5 +58,37 @@ export interface SitemapOptions {
      * below exists to catch.
      */
     excludeSections?: readonly SitemapSection[];
+    /**
+     * Skip the SHOP's surface-visibility policy — for a host that OWNS the
+     * sections it is emitting.
+     *
+     * ## 🛑 Why this is necessary and not a loophole
+     *
+     * `keep()` below withholds any URL under a closed browse section, an
+     * unlisted listing-type route, or a `closedSurfacePrefix` derived from
+     * `siteSettings.disabledRoutes`. That is exactly right for the shop: a
+     * surface it has switched off must not be advertised.
+     *
+     * It is exactly WRONG for an extracted subdomain, and the reason is almost
+     * funny: the shop disables `/blog` **because the blog moved to
+     * `blogs.<domain>`**. The subdomain then reads the same settings document,
+     * sees `/blog` disabled, and withholds its own content.
+     *
+     * Measured on 2026-11-09, from the blogs build log:
+     *
+     *   sitemap: built  {"sections":{"blog":16},"total":0}
+     *
+     * Sixteen posts fetched, every one filtered out, and a valid empty
+     * `<urlset>` served with HTTP 200. The pages themselves rendered perfectly
+     * throughout — only the sitemap was gone.
+     *
+     * 🛑 It does NOT skip the section scope. `sections`/`excludeSections` still
+     * apply, so this cannot be used to make one host emit another's URLs. It
+     * only stops the SHOP's visibility flags from governing a host the shop does
+     * not serve.
+     *
+     * 🛑 Leave it UNSET on the shop. There, those flags are the whole point.
+     */
+    ownsSections?: boolean;
 }
-export declare function buildSitemap({ baseUrl, sections: only, excludeSections, }: SitemapOptions): Promise<MetadataRoute.Sitemap>;
+export declare function buildSitemap({ baseUrl, sections: only, excludeSections, ownsSections, }: SitemapOptions): Promise<MetadataRoute.Sitemap>;

package/dist/_internal/server/features/seo/sitemap.js

@@ -536,7 +536,7 @@ async function fetchScammerUrls(baseUrl) {
         return sitemapSectionFailed("scammer", err);
     }
 }
-export async function buildSitemap({ baseUrl, sections: only, excludeSections, }) {
+export async function buildSitemap({ baseUrl, sections: only, excludeSections, ownsSections = false, }) {
     /*
      * Which sections this host emits. See `SitemapOptions.sections` for why a
      * host must be able to answer this at all.
@@ -697,6 +697,12 @@ export async function buildSitemap({ baseUrl, sections: only, excludeSections, }
      */
     const closedPrefixes = closedSurfacePrefixes(settings);
     const keep = (entry) => {
+        /*
+         * A host that OWNS its sections is not governed by the shop's visibility
+         * flags — see `ownsSections`. The section scope above still applies.
+         */
+        if (ownsSections)
+            return true;
         const path = entry.url.startsWith("http")
             ? new URL(entry.url).pathname
             : entry.url;

package/dist/features/events/actions/event-actions.d.ts

@@ -1,9 +1,3 @@
-/**
- * Event Domain Actions (appkit/features/events)
- *
- * Business logic for event CRUD, status changes, entries, and public access.
- * Auth, rate-limiting, and input validation are handled by the calling server action.
- */
 import type { JsonValue } from "../../../schemas/types";
 import type { EventDocument, EventEntryDocument, EventEntryMedia } from "../schemas";
 import type { EventStatus } from "../types";

package/dist/features/events/actions/event-actions.js

@@ -1,3 +1,4 @@
+import { resolveEntryApproval } from "../schemas/firestore.js";
 /**
  * Event Domain Actions (appkit/features/events)
  *
@@ -510,11 +511,43 @@ export async function enterEvent(eventId, input, user, request) {
      * pool — that is the moderation path, not a standing review queue of every
      * entrant.
      */
-    const autoApprove = event.type === "poll" ||
+    /*
+     * ⚠ LEGACY FALLBACK ONLY — do not add a type to this expression.
+     *
+     * This was the whole decision until 2026-11-09, and it is `event.type ===`
+     * branching: the exact shape the governing principle calls a defect. It also
+     * meant a new type could not choose — `contest` is absent, so contest
+     * entries were moderated by accident, and changing that needed a release.
+     *
+     * It survives ONLY so events already in the database behave exactly as they
+     * did. `resolveEntryApproval` consults it last. A NEW type declares its
+     * default in `event-types-seed-data.ts`; a single event overrides with
+     * `entryApproval` on its own row. Delete this once every type has a default.
+     */
+    const legacyAutoApprove = event.type === "poll" ||
         event.type === "feedback" ||
         eventType === "giveaway" ||
         (event.type === "survey" &&
             !event.surveyConfig?.entryReviewRequired);
+    /*
+     * The event's own setting wins, then the type's default, then the legacy
+     * expression. Anything unrecognised resolves to MODERATED — fail closed, so
+     * newer config against an older deploy cannot start publishing unreviewed
+     * user content.
+     */
+    /*
+     * ⚠ The TYPE-level default is passed as `undefined` for now. The precedence
+     * chain is built for three levels — event row, then type default, then the
+     * legacy expression — and `event-types-seed-data.ts` is where a type's
+     * default belongs, beside the `ruleSets` it already carries.
+     *
+     * Reading it here needs the type definition loaded at this point, which this
+     * action does not currently do. Stated rather than faked: the EVENT-level
+     * override the owner asked for works completely; the type-level default is
+     * the next step and slots into the middle argument with no other change.
+     */
+    const approvalMode = resolveEntryApproval(event, undefined, legacyAutoApprove);
+    const autoApprove = approvalMode === "auto";
     const reviewStatus = autoApprove ? "approved" : "pending";
     const entry = await eventEntryRepository.createEntry({
         eventId: resolvedEventId,

package/dist/features/events/schemas/firestore.d.ts

@@ -124,6 +124,38 @@ export interface EventDocument extends BaseDocument {
      */
     isPinned?: boolean;
     /** Test-data flag — set on the shared admin-seeded test event; swept by testDataCleanup. */
+    /**
+     * Who may publish an entry: nobody (`"moderated"`) or the entrant
+     * (`"auto"`). Set ON THE EVENT, per owner 2026-11-09.
+     *
+     * ## 🛑 This replaces a hardcoded type switch
+     *
+     * `enterEvent` decided this with:
+     *
+     *   const autoApprove =
+     *     event.type === "poll" || event.type === "feedback" ||
+     *     eventType === "giveaway" ||
+     *     (event.type === "survey" && !surveyConfig?.entryReviewRequired);
+     *
+     * That is `event.type === …` branching, which the governing principle names
+     * as a defect rather than a safeguard: *"a mechanism never asks what TYPE is
+     * this — it asks what CAPABILITY does this have"*. It also meant a NEW event
+     * type could not choose: `contest` is absent from that list, so contest
+     * entries were moderated by accident rather than by decision, and changing
+     * it would have required an appkit release.
+     *
+     * Now it is a value on the row. A moderated photo contest and an
+     * auto-approving one are two seed rows, not two code paths.
+     *
+     * 🛑 OPEN union, deliberately — `(string & {})` keeps autocomplete while
+     * allowing a mode this release has never heard of. `resolveEntryApproval`
+     * treats anything unknown as MODERATED, which is the fail-closed direction:
+     * an unrecognised setting must not publish unreviewed user content.
+     *
+     * Unset falls back to the type's default, then to the legacy expression, so
+     * no existing event changes behaviour. See `resolveEntryApproval`.
+     */
+    entryApproval?: EntryApprovalMode;
     isTestData?: boolean;
     /** When isTestData, the cutoff after which testDataCleanup deletes this doc. */
     testDataExpiresAt?: Date;
@@ -492,4 +524,35 @@ export declare const eventQueryHelpers: {
     readonly withRaffle: () => readonly ["hasRaffle", "==", true];
     readonly raffleNotYetDrawn: () => readonly ["raffleWinnerUserId", "==", null];
 };
+/**
+ * How an event decides whether a submitted entry is published immediately.
+ *
+ * 🛑 OPEN, not a closed enum. The platform ships two modes; a deployment
+ * that needs a third ("auto below N entries", "auto for verified buyers")
+ * writes its own slug and a resolver rule rather than waiting for a release.
+ */
+export type EntryApprovalMode = "auto" | "moderated" | (string & {});
+/**
+ * Resolve the approval mode for one entry submission.
+ *
+ * Order, most specific first:
+ *   1. `event.entryApproval`      — this event's own decision
+ *   2. `typeDefault`              — the event TYPE's default, from seed config
+ *   3. the legacy expression      — see below
+ *
+ * 🛑 FAILS CLOSED. Anything not recognised as `"auto"` resolves to
+ * moderated. An unknown mode arriving from newer config against an older
+ * deploy must not start publishing unreviewed user content — degrading to a
+ * review queue is recoverable, publishing is not.
+ *
+ * ⚠ The third fallback is a MIGRATION PATH, not a design. It reproduces the
+ * hardcoded type switch this field replaced so that events already in the
+ * database keep behaving exactly as they did. It should be deleted once every
+ * event type declares its own default in `event-types-seed-data.ts`.
+ */
+export declare function resolveEntryApproval(event: {
+    entryApproval?: EntryApprovalMode;
+    type?: string;
+    surveyConfig?: unknown;
+}, typeDefault?: EntryApprovalMode, legacyAutoApprove?: boolean): "auto" | "moderated";
 export {};

package/dist/features/events/schemas/firestore.js

@@ -140,3 +140,27 @@ export const eventQueryHelpers = {
     withRaffle: () => ["hasRaffle", "==", true],
     raffleNotYetDrawn: () => ["raffleWinnerUserId", "==", null],
 };
+/**
+ * Resolve the approval mode for one entry submission.
+ *
+ * Order, most specific first:
+ *   1. `event.entryApproval`      — this event's own decision
+ *   2. `typeDefault`              — the event TYPE's default, from seed config
+ *   3. the legacy expression      — see below
+ *
+ * 🛑 FAILS CLOSED. Anything not recognised as `"auto"` resolves to
+ * moderated. An unknown mode arriving from newer config against an older
+ * deploy must not start publishing unreviewed user content — degrading to a
+ * review queue is recoverable, publishing is not.
+ *
+ * ⚠ The third fallback is a MIGRATION PATH, not a design. It reproduces the
+ * hardcoded type switch this field replaced so that events already in the
+ * database keep behaving exactly as they did. It should be deleted once every
+ * event type declares its own default in `event-types-seed-data.ts`.
+ */
+export function resolveEntryApproval(event, typeDefault, legacyAutoApprove) {
+    const chosen = event.entryApproval ?? typeDefault;
+    if (chosen !== undefined)
+        return chosen === "auto" ? "auto" : "moderated";
+    return legacyAutoApprove ? "auto" : "moderated";
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mohasinac/appkit",
-  "version": "4.75.0",
+  "version": "4.77.0",
   "license": "MIT",
   "publishConfig": {
     "access": "public"