@classytic/repo-core 0.23.0 → 0.24.0

package/dist/cleanup/types.d.mts

@@ -85,10 +85,27 @@ interface CleanupStepExecuteContext extends CleanupStepContext {
  * One preview line — maps 1:1 onto a host plan item. A business record class
  * (`'sales facts'`, `'journal entries'`), never a collection name.
  */
+/**
+ * What a step's `estimated` COUNTS. Absent ⇒ `'remove'`.
+ *
+ * `destructive: false` is NOT a substitute: it is true of both a protective
+ * guard (counts records it defends) and a projection rebuild (counts records it
+ * recomputes), and those mean opposite things in a "records to remove" headline.
+ * A guard reporting 173 protected journal entries once pushed that headline to
+ * 540 on a plan that removed 367 — a plausible, internally consistent, wrong
+ * number shown at the exact moment an operator authorises destruction.
+ */
+type CleanupStepDisposition = 'remove' | 'protect' | 'rebuild';
 interface CleanupStepEstimate {
   readonly resource: string;
   /** Estimated records this step would affect. */
   readonly estimated: number;
+  /**
+   * Whether `estimated` counts records REMOVED, PROTECTED, or REBUILT.
+   * Defaults to `'remove'`, so every existing purge step is unchanged and only
+   * a step that means something else has to say so.
+   */
+  readonly disposition?: CleanupStepDisposition | undefined;
   /** What this step RETAINS (e.g. `'measures kept, PII redacted'`). */
   readonly retained?: string | undefined;
   /**
@@ -147,6 +164,22 @@ interface CleanupStep {
    * recipe is destructive iff ANY of its steps is.
    */
   readonly destructive: boolean;
+  /**
+   * What this step IS, declared once — not merely what one estimate counted.
+   *
+   * Needed at the STEP because a caller has to know a step is protective
+   * WITHOUT running it. A host resolving an operator's exclusion list must
+   * refuse to switch a guard off, and asking `estimate()` to find out would mean
+   * running the counting queries for a line that is being taken out — and
+   * surfacing that line's blockers, so excluding a domain could still be refused
+   * because of it.
+   *
+   * `destructive: false` is not the same question: it is true of a guard AND of
+   * a projection rebuild, and a rebuild is perfectly reasonable to exclude.
+   *
+   * An estimate may restate it; absent everywhere ⇒ `'remove'`.
+   */
+  readonly disposition?: CleanupStepDisposition | undefined;
   /**
    * Projection / scaffolding rebuilds this step performs AFTER its cleanup —
    * surfaced in the preview's `rebuildActions` (e.g. `'rebuild sales rollup'`).
@@ -164,4 +197,4 @@ interface CleanupStep {
   verify?(ctx: CleanupStepContext): Promise<readonly CleanupStepCheck[]>;
 }
 //#endregion
-export { CleanupStep, CleanupStepCheck, CleanupStepContext, CleanupStepEstimate, CleanupStepExecuteContext, CleanupStepLogger, CleanupStepOutcome, CleanupStepProgress };
+export { CleanupStep, CleanupStepCheck, CleanupStepContext, CleanupStepDisposition, CleanupStepEstimate, CleanupStepExecuteContext, CleanupStepLogger, CleanupStepOutcome, CleanupStepProgress };

package/dist/tenant/index.d.mts

@@ -1,3 +1,3 @@
 import { ResolvedTenantConfig, TenantConfig, TenantFieldType, TenantStrategy } from "./types.mjs";
-import { DEFAULT_TENANT_CONFIG, resolveTenantConfig, resolveTenantField } from "./resolve.mjs";
-export { DEFAULT_TENANT_CONFIG, type ResolvedTenantConfig, type TenantConfig, type TenantFieldType, type TenantStrategy, resolveTenantConfig, resolveTenantField };
+import { DEFAULT_TENANT_CONFIG, assertNoLegacyTenantKeys, resolveTenantConfig, resolveTenantField } from "./resolve.mjs";
+export { DEFAULT_TENANT_CONFIG, type ResolvedTenantConfig, type TenantConfig, type TenantFieldType, type TenantStrategy, assertNoLegacyTenantKeys, resolveTenantConfig, resolveTenantField };

package/dist/tenant/index.mjs

@@ -1,2 +1,2 @@
-import { DEFAULT_TENANT_CONFIG, resolveTenantConfig, resolveTenantField } from "./resolve.mjs";
-export { DEFAULT_TENANT_CONFIG, resolveTenantConfig, resolveTenantField };
+import { DEFAULT_TENANT_CONFIG, assertNoLegacyTenantKeys, resolveTenantConfig, resolveTenantField } from "./resolve.mjs";
+export { DEFAULT_TENANT_CONFIG, assertNoLegacyTenantKeys, resolveTenantConfig, resolveTenantField };

package/dist/tenant/resolve.d.mts

@@ -28,5 +28,36 @@ declare function resolveTenantConfig(config?: TenantConfig | boolean): ResolvedT
  * scoping" and all return `false` — callers get one thing to branch on.
  */
 declare function resolveTenantField(config?: TenantConfig | boolean): string | false;
+/**
+ * Refuse a config that still carries a pre-consolidation tenant key.
+ *
+ * ## Why this belongs in repo-core and not in each kernel
+ *
+ * Kernels are migrating from a per-package tenant shape (`multiTenant`, plus a
+ * sibling `tenantFieldType` in some) onto {@link TenantConfig} under the key
+ * `tenant`. `@classytic/ledger` has landed; catalog, order, cart, crm, flow,
+ * party, review, transfer and yard have adopted the TYPE but still read
+ * `multiTenant`. Each of those is a future rename.
+ *
+ * The rename itself is trivial. What is not trivial is the failure mode when a
+ * CALLER misses it, because every one of these resolvers reads
+ * `resolveTenantConfig(config.tenant ?? false)`: an absent `tenant` resolves to
+ * `strategy: 'none'` — no tenant field, no tenant filter, every read spanning
+ * ALL tenants, no error, and figures that look plausible. A host that asked for
+ * tenancy gets none, silently.
+ *
+ * Nine packages each remembering to hand-roll that check is nine chances to
+ * forget, and the one that forgets is the one that ships the leak. So the guard
+ * lives beside the resolver every one of them already calls.
+ *
+ * Additive and non-breaking: nothing calls it until a package renames.
+ *
+ * @param config the raw, unresolved shape as the host supplied it
+ * @param pkg package name for the message (e.g. `'defineOrder'`)
+ * @param extra additional legacy keys this package is retiring, as
+ *   `[oldKey, newPath]` — pass `['tenantFieldType', 'tenant.fieldType']` when
+ *   the package carried a sibling field-type option.
+ */
+declare function assertNoLegacyTenantKeys(config: unknown, pkg: string, extra?: ReadonlyArray<readonly [string, string]>): void;
 //#endregion
-export { DEFAULT_TENANT_CONFIG, resolveTenantConfig, resolveTenantField };
+export { DEFAULT_TENANT_CONFIG, assertNoLegacyTenantKeys, resolveTenantConfig, resolveTenantField };

package/dist/tenant/resolve.mjs

@@ -71,5 +71,44 @@ function resolveTenantField(config) {
 	if (!resolved.enabled || resolved.strategy === "none") return false;
 	return resolved.tenantField;
 }
+/**
+* Refuse a config that still carries a pre-consolidation tenant key.
+*
+* ## Why this belongs in repo-core and not in each kernel
+*
+* Kernels are migrating from a per-package tenant shape (`multiTenant`, plus a
+* sibling `tenantFieldType` in some) onto {@link TenantConfig} under the key
+* `tenant`. `@classytic/ledger` has landed; catalog, order, cart, crm, flow,
+* party, review, transfer and yard have adopted the TYPE but still read
+* `multiTenant`. Each of those is a future rename.
+*
+* The rename itself is trivial. What is not trivial is the failure mode when a
+* CALLER misses it, because every one of these resolvers reads
+* `resolveTenantConfig(config.tenant ?? false)`: an absent `tenant` resolves to
+* `strategy: 'none'` — no tenant field, no tenant filter, every read spanning
+* ALL tenants, no error, and figures that look plausible. A host that asked for
+* tenancy gets none, silently.
+*
+* Nine packages each remembering to hand-roll that check is nine chances to
+* forget, and the one that forgets is the one that ships the leak. So the guard
+* lives beside the resolver every one of them already calls.
+*
+* Additive and non-breaking: nothing calls it until a package renames.
+*
+* @param config the raw, unresolved shape as the host supplied it
+* @param pkg package name for the message (e.g. `'defineOrder'`)
+* @param extra additional legacy keys this package is retiring, as
+*   `[oldKey, newPath]` — pass `['tenantFieldType', 'tenant.fieldType']` when
+*   the package carried a sibling field-type option.
+*/
+function assertNoLegacyTenantKeys(config, pkg, extra = []) {
+	if (config === null || typeof config !== "object") return;
+	const record = config;
+	const retired = [["multiTenant", "tenant"], ...extra];
+	for (const [key, became] of retired) {
+		if (record[key] === void 0) continue;
+		throw new Error(`${pkg}: \`${key}\` was renamed to \`${became}\`. It is REFUSED rather than ignored because ignoring it disables tenancy SILENTLY — no tenant field, no tenant filter, and every read spanning all tenants while returning plausible numbers. Move the value to \`tenant\` (\`tenant: false\` for a single-tenant deployment).`);
+	}
+}
 //#endregion
-export { DEFAULT_TENANT_CONFIG, resolveTenantConfig, resolveTenantField };
+export { DEFAULT_TENANT_CONFIG, assertNoLegacyTenantKeys, resolveTenantConfig, resolveTenantField };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@classytic/repo-core",
-  "version": "0.23.0",
+  "version": "0.24.0",
   "description": "Driver-agnostic repository primitives: hooks, Filter IR, operations, pagination, cache contract. Foundation for mongokit, sqlitekit, pgkit, and prismakit. Lean by design — no plugins ship here; each kit owns its own.",
   "type": "module",
   "sideEffects": false,