@ak--47/dungeon-master 1.6.1 → 1.6.2

package/CHANGELOG.md

@@ -2,6 +2,103 @@
 
 All notable changes to `@ak--47/dungeon-master`.
 
+## 1.6.2 — 2026-07-30
+
+### Fixed
+
+- **Running the same dungeon twice in one process no longer collapses the second
+  run.** `validateDungeonConfig` enriched in place — stamping `isStrictEvent` on
+  funnel-step events and `conversionWindowDays` / `_experiment` on funnels — and
+  `DUNGEON_MASTER` handed the pipeline a shallow spread, so those stamps landed on
+  the caller's own `events` / `funnels` arrays. For a file input that array belongs
+  to the ESM module cache, so run 2 got a config already enriched by run 1: every
+  event pre-promoted to strict, the catch-all funnel swept nothing, and event volume
+  collapsed (measured 317 → 0 on `dungeons/technical/simple.js`). The validator now
+  clones its input and enriches only what it returns; functions (`hook`,
+  `onProgress`, chance-bound prop thunks) are preserved by reference. Affects an
+  object config passed by a caller who reuses it, a file path run more than once in
+  a process, and an array of paths. Not affected: raw-text input (each call writes a
+  fresh temp module) and `scripts/run-many.mjs` (forks a child per dungeon). Pinned
+  by `tests/integration/config-isolation.test.js`.
+- **`verifyDungeon` now applies funnel config to path and JSON inputs.** It read
+  `conversionWindowDays` / `order` back off the caller's own `config`, which for a
+  string input has no `.funnels` at all — so every funnel check silently ran with
+  the default order and an unbounded window. It now reads
+  `result.validatedConfig.funnels`.
+- **`verifyDungeon`'s schema report is no longer spurious.** `validateSchema` also
+  ran against the raw input: a path input has no fields to derive an expected
+  schema from, and a v1.5.1 dungeon keeps `hasAndroidDevices` / `hasBrowser` under
+  `switches`, which `deriveExpectedSchema` only sees once flattened. Both produced
+  a wall of phantom `flagStamping` findings and a permanently false `report.pass`
+  (16 phantom findings on `dungeons/technical/experiments.js`; now 0). It now
+  validates against the config the run actually used.
+- **The 22 shipped `dungeons/vertical/*/*.verify.mjs` wrappers now thread VALIDATED
+  funnels** into `evaluateStories`. They passed `config.funnels` raw, so no funnel
+  story in any vertical had a conversion window — every vertical funnel resolves to
+  a 30- or 45-day `conversionWindowDays` that was being dropped. Pre-existing (these
+  scripts read shards off disk, so nothing ever enriched their config).
+  `validateDungeonConfig` is now exported from `@ak--47/dungeon-master/verify` for
+  exactly this.
+- **`verifyDungeon` throws on a multi-dungeon input** instead of silently verifying
+  `result[0]` and discarding the rest — which returned a green report for dungeons
+  nobody looked at. Call it once per dungeon.
+- **`tests/unit/dungeon-shapes.test.js` no longer asserts the lowercase-hyphen naming
+  convention against `dungeons/user/`.** That directory is gitignored per-machine
+  scratch space, so the check failed on whatever a given developer had checked out
+  locally and was unreproducible in CI. The convention still applies to the tracked
+  `technical/` and `vertical/` dungeons.
+
+### Added
+
+- **`result.validatedConfig`** — the enriched config the run actually used. Read
+  resolved values (`funnels[].conversionWindowDays`, `events[].isStrictEvent`, the
+  resolved dataset window) here now that the validator no longer writes them back to
+  the object you passed in. Two caveats, both documented on the type: credentials
+  are stripped (a Result gets logged), and it is **read-only** — validation is not
+  idempotent, so feeding it back into `DUNGEON_MASTER` grows the funnel set and
+  eventually yields an empty `sequence`. Re-run the original config instead.
+- **`verifyDungeon(config, checks, overrides)`** — an optional third argument,
+  merged into the dungeon before it runs exactly like `DUNGEON_MASTER`'s second
+  argument. Lets CI verify a production-scale dungeon at a small `numUsers` /
+  `numEvents` without editing it. The report also carries `validatedConfig`.
+- **`validateDungeonConfig`** re-exported from `@ak--47/dungeon-master/verify`, so a
+  standalone verify script that reads shards off disk can resolve funnel defaults
+  before calling `evaluateStories` / `applyFunnelDefaults`.
+- **`releaseConnections()`** exported from `lib/orchestrators/mixpanel-sender.js`,
+  for hosts that drive `mixpanel-import` directly and want the same pool teardown.
+
+### Changed
+
+- **`validateDungeonConfig` no longer mutates its input.** Enrichment lands only on
+  the returned object. If you called it directly and then read `isStrictEvent` /
+  `conversionWindowDays` back off the config you passed in, read the return value
+  instead (or `result.validatedConfig` after a run). Running a dungeon is
+  unaffected. This is the fix for the collapse bug above, so it ships on a patch.
+- **`mixpanel-import` bumped `^3.3.2` → `^3.5.1`.** Notable for dungeon-master:
+  - **Flat events past `epochEnd` no longer kill the entire import job.** The sender
+    sets `epochEnd: dayjs().unix()` and dungeon-master events are flat, which on
+    3.3.2 threw `Record has no properties object, cannot fix time` and failed the
+    whole batch; 3.5.1 counts the record as `outOfBounds` and carries on. Verified
+    directly against both versions.
+  - **India-region SCD imports go to `api-in`.** 3.3.2 routed `region: 'IN'` SCD
+    batches to `api-eu`.
+  - **The library no longer installs five process-global handlers**
+    (`unhandledRejection`, `uncaughtException`, `exit`, `SIGINT`, `SIGTERM`) as an
+    import side effect. **Hosts embedding dungeon-master will now crash on uncaught
+    exceptions and unhandled rejections instead of logging and continuing** — those
+    errors were always happening, only the reporting changes. Register your own
+    handlers to restore the old behavior. Upside: `user-loop`'s own SIGINT handler is
+    no longer preempted, so Ctrl+C cancellation works as designed.
+  - Prod-only `npm audit` for the dependency tree: 45 findings → 20 (critical 3 → 1).
+- **`sendToMixpanel` releases mixpanel-import's shared undici connection pools**
+  when it settles, so a host that runs occasional imports doesn't hold ingest
+  sockets open in between. Runs in a `finally`, guarded, and non-fatal; pools are
+  recreated on demand. The pools are process-global, so teardown is refcounted —
+  concurrent `DUNGEON_MASTER()` calls in one process won't close sockets out from
+  under each other.
+- **`engines.node` raised `>=18.0.0` → `>=20.20.0`**, matching what mixpanel-import
+  requires. The old floor had been wrong since 3.3.2 (which already wanted 20.18.1).
+
 ## 1.6.1 — 2026-07-08
 
 ### Fixed

package/dungeons/vertical/ai-platform/ai-platform.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './ai-platform.js';
 
 const PREFIX = process.argv[2] || 'verify-ai-platform';
@@ -51,12 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the H9 story carries its own explicit
-// 336-hour conversion window (2x the generative window, covering the
-// stretched support), so no funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/community/community.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './community.js';
 
 const PREFIX = process.argv[2] || 'verify-community';
@@ -51,13 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the H8/H9 emulator stories carry their
-// own explicit conversion window (48h Content Creation generative window ×
-// the 1.25 free-tier stretch = 60h, covering the stretched support), so no
-// funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/crypto/crypto.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './crypto.js';
 
 const PREFIX = process.argv[2] || 'verify-crypto';
@@ -63,7 +63,9 @@ const runSql = async (sql) => {
 // assemble chains across unscaled clones and collapse the read.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/dating/dating.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './dating.js';
 
 const PREFIX = process.argv[2] || 'verify-dating';
@@ -51,13 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the H9 stories carry their own explicit
-// conversion window (24h Match Flow generative window × the 1.4 max stretch
-// factor = 33.6h, covering the stretched support), so no funnel-default
-// threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/devtools/devtools.verify.mjs

@@ -18,7 +18,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './devtools.js';
 
 const PREFIX = process.argv[2] || 'verify-devtools';
@@ -58,7 +58,9 @@ const runSql = async (sql) => {
 // semantics, not cross-event SQL (greedy MIN→MIN picks flatten it).
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/ecommerce/ecommerce.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './ecommerce.js';
 
 const PREFIX = process.argv[2] || 'verify-ecommerce';
@@ -51,11 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the H8 story carries its own explicit
-// 75-minute pairing window in SQL, so no funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/education/education.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './education.js';
 
 const PREFIX = process.argv[2] || 'verify-education';
@@ -51,16 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the emulator stories carry their own
-// explicit conversion windows (H7/H9: 86.4h = 48h generative × the 1.8 free
-// TTC stretch, on the 2-step enrolled→cert read; the 4-step doc funnel would
-// break because H9's annual ×0.5 compression can move a cert before the
-// interior quiz step). H10 pairs in SQL anchored at funnel ENTRY (first
-// 'discussion posted' at/after $experiment_started, conversion within 12h of
-// entry) because the exp→entry lag is arm-dependent.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/fintech/fintech.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './fintech.js';
 
 const PREFIX = process.argv[2] || 'verify-fintech';
@@ -51,11 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — every timeToConvert story carries an
-// explicit conversionWindowMs, so no funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/fitness/fitness.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './fitness.js';
 
 const PREFIX = process.argv[2] || 'verify-fitness';
@@ -51,12 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the H9 stories carry their own explicit
-// conversion window (48h generative window × the 1.25 max stretch factor,
-// covering the stretched support), so no funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/food-delivery/food-delivery.verify.mjs

@@ -18,7 +18,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './food-delivery.js';
 
 const PREFIX = process.argv[2] || 'verify-food-delivery';
@@ -60,7 +60,9 @@ const runSql = async (sql) => {
 // confounds a raw emulator read would inherit.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/gaming/gaming.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './gaming.js';
 
 const PREFIX = process.argv[2] || 'verify-gaming';
@@ -51,11 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — every timeToConvert story carries an
-// explicit conversionWindowMs, so no funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/healthcare/healthcare.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './healthcare.js';
 
 const PREFIX = process.argv[2] || 'verify-healthcare';
@@ -51,13 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the H8/H9 stories carry their own
-// explicit conversion windows (derived from the funnel's generative window
-// × the max H9 stretch factor, covering the stretched support), so no
-// funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/insurance-application/insurance-application.verify.mjs

@@ -18,7 +18,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './insurance-application.js';
 
 const PREFIX = process.argv[2] || 'verify-insurance-application';
@@ -59,7 +59,9 @@ const runSql = async (sql) => {
 // because H5 pins approvals to firstStart + target + [0,4h) by construction.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/logistics/logistics.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './logistics.js';
 
 const PREFIX = process.argv[2] || 'verify-logistics';
@@ -51,14 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the emulator stories carry their own
-// explicit conversion windows (H8: 48h Integration Setup treated arm, 336h
-// Supplier Management placebo; H10: 93.6h = 72h Onboarding generative
-// window × the 1.3 small-business stretch, covering the stretched support),
-// so no funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/marketplace/marketplace.verify.mjs

@@ -18,7 +18,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './marketplace.js';
 
 const PREFIX = process.argv[2] || 'verify-marketplace';
@@ -59,7 +59,9 @@ const runSql = async (sql) => {
 // windows admit cross-instance chains that contaminate the fast tail.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/media/media.verify.mjs

@@ -18,7 +18,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './media.js';
 
 const PREFIX = process.argv[2] || 'verify-media';
@@ -59,7 +59,9 @@ const runSql = async (sql) => {
 // vs cross-session) and flips on sampling noise.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/real-estate/real-estate.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './real-estate.js';
 
 const PREFIX = process.argv[2] || 'verify-real-estate';
@@ -51,16 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — H10's emulator stories carry their own
-// conversion window: 31.2h = 24h generative Tour Funnel TTC × the 1.3
-// Standard-tier stretch, so the stretched support is fully covered. The
-// PRIMARY read is the 2-step view→tour-scheduled pair; the doc's 3-step read
-// (…→offer submitted) stays as a directional secondary because H4/H6 offer
-// clones at random timestamps collide with the greedy third-step pick and
-// attenuate the ratio toward 1 (see the H10 story narrative).
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/sass/sass.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './sass.js';
 
 const PREFIX = process.argv[2] || 'verify-sass';
@@ -59,7 +59,9 @@ const runSql = async (sql) => {
 // a slow organic tail that dilutes the segment medians.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/social/social.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './social.js';
 
 const PREFIX = process.argv[2] || 'verify-social';
@@ -61,7 +61,9 @@ const runSql = async (sql) => {
 // across 1h-24h windows.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/streaming/streaming.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './streaming.js';
 
 const PREFIX = process.argv[2] || 'verify-streaming';
@@ -60,7 +60,9 @@ const runSql = async (sql) => {
 // campaign cohort without needing hashFloat in SQL.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/support-desk/support-desk.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './support-desk.js';
 
 const PREFIX = process.argv[2] || 'verify-support-desk';
@@ -60,7 +60,9 @@ const runSql = async (sql) => {
 // > 30 min) and split by role without needing hashFloat.
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/dungeons/vertical/travel/travel.verify.mjs

@@ -17,7 +17,7 @@ import path from 'node:path';
 import readline from 'node:readline';
 import { execFile } from 'node:child_process';
 import { promisify } from 'node:util';
-import { buildIdentityMap, evaluateStories, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
+import { buildIdentityMap, evaluateStories, validateDungeonConfig, VERDICT_RANK } from '@ak--47/dungeon-master/verify';
 import config, { stories } from './travel.js';
 
 const PREFIX = process.argv[2] || 'verify-travel';
@@ -51,13 +51,11 @@ const runSql = async (sql) => {
 	return stdout.trim() ? JSON.parse(stdout) : [];
 };
 
-// funnels passed raw (unvalidated) — the H8/H9 emulator stories carry their
-// own explicit conversion windows (72h Onboarding; 48h Search to Book
-// generative window × the 1.25 budget/leisure stretch = 60h, covering the
-// stretched support), so no funnel-default threading is needed
 const results = await evaluateStories(stories, events, {
 	profiles,
-	funnels: config.funnels,
+	// funnel defaults (conversionWindowDays, order) resolve on the VALIDATED
+	// config — the dungeon was not run in this process, so validate here.
+	funnels: validateDungeonConfig({ ...config, token: '' }).funnels,
 	identityMap: buildIdentityMap(profiles),
 	runSql,
 });

package/index.js

@@ -20,7 +20,7 @@ import { extractComments } from './lib/core/extract-comments.js';
 
 // Orchestrators
 import { userLoop } from './lib/orchestrators/user-loop.js';
-import { sendToMixpanel, collectWrittenFiles } from './lib/orchestrators/mixpanel-sender.js';
+import { sendToMixpanel, collectWrittenFiles, releaseConnections } from './lib/orchestrators/mixpanel-sender.js';
 // Generators
 import { makeAdSpend } from './lib/generators/adspend.js';
 import { makeMirror } from './lib/generators/mirror.js';
@@ -291,6 +291,12 @@ async function runDungeon(config) {
 			eventCount: context.getStoredEventCount(),
 			userCount: context.getUserCount(),
 			profilesPushed,
+			// v1.6.2: the enriched config this run actually used. `validateDungeonConfig`
+			// no longer writes back to the caller's object, so consumers that need
+			// resolved values (`funnels[].conversionWindowDays`, `events[].isStrictEvent`,
+			// the resolved dataset window) read them here. `verifyDungeon` depends on this.
+			// Credentials are stripped — a Result is a thing hosts log.
+			validatedConfig: redactCredentials(validatedConfig),
 			...(progressSummary.updates > 0 || progressSummary.errors > 0 ? { progress: progressSummary } : {})
 		};
 
@@ -560,6 +566,26 @@ async function flushStorageToDisk(storage, config) {
 	}
 }
 
+/**
+ * Shallow copy of the validated config with every credential removed, for the
+ * `validatedConfig` field on a Result.
+ *
+ * A Result is a thing hosts log, serialize, and attach to CI artifacts. Before
+ * v1.6.2 it carried no credentials at all, and surfacing the resolved config
+ * shouldn't quietly change that: the run object holds `token`, `serviceAccount`,
+ * `serviceSecret` and `projectId` both flattened and under `credentials`.
+ * @param {import('./types').Dungeon} validated
+ * @returns {import('./types').Dungeon}
+ */
+function redactCredentials(validated) {
+	if (!validated || typeof validated !== 'object') return validated;
+	const safe = { ...validated };
+	for (const key of ['token', 'serviceAccount', 'serviceSecret', 'projectId', 'credentials']) {
+		delete safe[key];
+	}
+	return safe;
+}
+
 /**
  * Extract file information from storage containers
  * @param {import('./types').Storage} storage - Storage object
@@ -604,4 +630,7 @@ function extractStorageData(storage) {
 // ES Module exports
 export default DUNGEON_MASTER;
 export { parseJSONDungeon, validateDungeonShape, loadFromFile, loadFromText, dungeonToJSON, extractComments };
+// v1.6.2: pool teardown is automatic when the last import settles; exported for hosts
+// that drive `mixpanel-import` themselves and want the same cleanup.
+export { releaseConnections };
 

package/lib/core/config-validator.js

@@ -407,13 +407,31 @@ function resolveDevicesPerUser(config) {
 }
 
 /**
- * Validates and enriches a dungeon configuration object
+ * Validates and enriches a dungeon configuration object.
+ *
+ * **Does not mutate its input** (as of v1.6.2). Enrichment lands only on the
+ * returned object. Callers that need the enriched `events` / `funnels` must read
+ * the return value — reading them back off the object they passed in worked
+ * before v1.6.2 and no longer does.
+ *
  * @param {Partial<Dungeon>} config - Raw configuration object
  * @returns {Dungeon} Validated and enriched configuration
  */
 export function validateDungeonConfig(config) {
 	const chance = u.getChance();
 
+	// v1.6.2: own our input. Enrichment below writes through to the caller's
+	// nested objects otherwise — `isStrictEvent` onto `events[i]`,
+	// `conversionWindowDays` / `_experiment` onto `funnels[j]`. For a dungeon
+	// loaded from a file those arrays belong to the ESM module cache, so a second
+	// run in the same process was handed a config already enriched by the first:
+	// every event pre-promoted to strict, the catch-all funnel swept nothing, and
+	// event volume collapsed. Enrichment is also not idempotent — re-validating an
+	// already-validated config rebuilds the funnel set incorrectly.
+	// deepClone keeps functions by reference, so `hook`, `onProgress` and
+	// chance-bound prop thunks survive.
+	config = u.deepClone(config);
+
 	// v1.5.1 (TODO #8): merge `switches` / `identity` / `credentials`
 	// sub-objects into top-level keys. New shape is preferred; old top-level
 	// keys still honored for back-compat with a verbose-gated warning. The

package/lib/orchestrators/mixpanel-sender.js

@@ -10,14 +10,64 @@ import { comma, rm } from "ak-tools";
 import * as u from "../utils/utils.js";
 import mp from "mixpanel-import";
 
+export { collectWrittenFiles };
+
+/**
+ * Count of `sendToMixpanel` calls currently in flight in this process.
+ *
+ * `mp.destroy()` tears down mixpanel-import's PROCESS-GLOBAL undici pools, so a
+ * run that finishes while another is still importing would close the sockets out
+ * from under it — surfacing as `UND_ERR_CLOSED`, which mixpanel-import does not
+ * retry. Only the last run out turns off the lights.
+ */
+let _inFlightImports = 0;
+
+/**
+ * Release mixpanel-import's shared undici connection pools, if no import is still
+ * running. dungeon-master is a library — a host process that runs occasional
+ * imports shouldn't hold ingest sockets open in between. Pools are lazily
+ * re-created, so a later run is unaffected.
+ *
+ * Called automatically when the last in-flight import settles; exported so a host
+ * that drives `mixpanel-import` directly can force the same cleanup. Note the
+ * refcount only sees imports that go through `sendToMixpanel` — a host running its
+ * own `mixpanel-import` job concurrently with a dungeon run can still have its
+ * pools closed underneath it.
+ * @returns {Promise<boolean>} true if pools were torn down.
+ */
+export async function releaseConnections() {
+	// `destroy` only exists on mixpanel-import >= 3.5.1.
+	if (_inFlightImports > 0 || typeof mp.destroy !== 'function') return false;
+	try {
+		await mp.destroy();
+		return true;
+	} catch (err) {
+		// Never fail a completed import over socket cleanup.
+		log(`  !! connection pool cleanup failed: ${err.message}\n`);
+		return false;
+	}
+}
+
 /**
  * Sends the data to Mixpanel
  * @param {Context} context - Context object containing config, storage, etc.
  * @returns {Promise<Object>} Import results for all data types
  */
-export { collectWrittenFiles };
-
 export async function sendToMixpanel(context) {
+	_inFlightImports++;
+	try {
+		return await _sendToMixpanel(context);
+	} finally {
+		_inFlightImports--;
+		await releaseConnections();
+	}
+}
+
+/**
+ * @param {Context} context
+ * @returns {Promise<Object>}
+ */
+async function _sendToMixpanel(context) {
 	const { config, storage } = context;
 	const {
 		adSpendData,

package/lib/verify/index.js

@@ -11,6 +11,12 @@
 
 export { emulateBreakdown } from './emulate-breakdown.js';
 export { verifyDungeon } from './verify-dungeon.js';
+// v1.6.2: exposed on the verify surface so a standalone verify script — one that
+// reads shards off disk instead of running the dungeon — can resolve funnel
+// defaults (`conversionWindowDays`, `order`) before handing funnels to
+// `evaluateStories` / `applyFunnelDefaults`. Use the RETURN value; it does not
+// enrich the config you pass in.
+export { validateDungeonConfig } from '../core/config-validator.js';
 export { deriveExpectedSchema, validateSchema } from './schema-validator.js';
 export {
 	evaluateFunnel,

package/lib/verify/verify-dungeon.js

@@ -59,9 +59,10 @@ function findMatchingFunnel(funnels, steps) {
  * args object — the input is not mutated. Extracted from `verifyDungeon` in
  * v1.6 so the story runner (P3.3) reuses the exact same threading.
  * @param {Object} breakdownArgs - Args destined for `emulateBreakdown`.
- * @param {Array<Object>} funnels - VALIDATED dungeon funnels (`validateDungeonConfig`
- *   mutates funnels in place, so post-run `config.funnels` carries resolved
- *   `conversionWindowDays` / `order`).
+ * @param {Array<Object>} funnels - VALIDATED dungeon funnels — i.e. the funnels off
+ *   `validateDungeonConfig`'s RETURN value (post-1.6.2 it no longer enriches the
+ *   caller's object), which carry resolved `conversionWindowDays` / `order`. A run
+ *   result exposes them as `result.validatedConfig.funnels`.
  * @param {Array<Object>} [profiles] - User profiles, threaded into `timeToConvert`.
  * @returns {Object}
  */
@@ -113,20 +114,44 @@ export function applyFunnelDefaults(breakdownArgs, funnels, profiles) {
 /**
  * @param {Object} config - Dungeon config (or path; passed straight to DUNGEON_MASTER).
  * @param {VerifyCheck[]} checks
- * @returns {Promise<{ pass: boolean, results: Array<{ name: string, pass: boolean, detail?: string, rows?: Array<Object> }>, schemaReport: Object }>}
+ * @param {Object} [overrides] - v1.6.2: merged into the dungeon before it runs, same as
+ *   `DUNGEON_MASTER`'s second argument. Lets CI verify a production-scale dungeon at a
+ *   small `numUsers` / `numEvents` without editing it.
+ * @returns {Promise<{ pass: boolean, results: Array<{ name: string, pass: boolean, detail?: string, rows?: Array<Object> }>, schemaReport: Object, validatedConfig: Object }>}
  */
-export async function verifyDungeon(config, checks) {
+export async function verifyDungeon(config, checks, overrides) {
 	if (!checks || !checks.length) throw new Error('verifyDungeon: at least one check required');
-	let result = await DUNGEON_MASTER(config);
-	if (Array.isArray(result)) result = result[0];
+	let result = await DUNGEON_MASTER(config, overrides);
+	if (Array.isArray(result)) {
+		// v1.6.2: an array input runs N dungeons but checks are written against ONE
+		// schema, and we used to silently verify `result[0]` and throw the rest away —
+		// a green report for dungeons that were never looked at. Call verifyDungeon
+		// per dungeon instead.
+		if (result.length !== 1) {
+			throw new Error(
+				`verifyDungeon: got ${result.length} dungeons, but checks apply to one. ` +
+				`Call verifyDungeon once per dungeon.`
+			);
+		}
+		result = result[0];
+	}
 	const events = Array.isArray(result.eventData) ? result.eventData : Array.from(result.eventData);
 	const profiles = Array.isArray(result.userProfilesData) ? result.userProfilesData : Array.from(result.userProfilesData);
-	const schemaReport = validateSchema(events, config);
+	// v1.6.2: schema-check against the config the run actually used. `config` may be a
+	// PATH STRING (no fields at all → every property reads as unexpected), and even for
+	// an object input a v1.5.1 dungeon keeps `hasAndroidDevices` / `hasBrowser` under
+	// `switches`, which `deriveExpectedSchema` only reads once flattened.
+	const schemaReport = validateSchema(events, result.validatedConfig || config);
 	const ctx = { events, profiles, schemaReport };
 	const results = [];
-	// `validateDungeonConfig` mutates funnels in place — by the time we read here,
-	// `conversionWindowDays` is populated and `order` is the validated value.
-	const validatedFunnels = (config && Array.isArray(config.funnels)) ? config.funnels : [];
+	// v1.6.2: read the funnels off the run's `validatedConfig` — `conversionWindowDays`
+	// and the resolved `order` live there. Before 1.6.2 we read them back off the
+	// caller's own `config`, relying on `validateDungeonConfig` enriching in place;
+	// that also meant a path/JSON input (no `.funnels` on the string) silently got an
+	// empty funnel list and thus an unbounded conversion window. Both are fixed here.
+	const validatedFunnels = Array.isArray(result?.validatedConfig?.funnels)
+		? result.validatedConfig.funnels
+		: (config && Array.isArray(config.funnels)) ? config.funnels : [];
 	for (const check of checks) {
 		try {
 			const breakdownArgs = applyFunnelDefaults(check.breakdown, validatedFunnels, profiles);
@@ -138,5 +163,7 @@ export async function verifyDungeon(config, checks) {
 		}
 	}
 	const pass = results.every(r => r.pass) && schemaReport.pass;
-	return { pass, results, schemaReport };
+	// v1.6.2: hand back the enriched config the run used, so callers can read
+	// resolved funnel/event values without re-validating.
+	return { pass, results, schemaReport, validatedConfig: result.validatedConfig };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@ak--47/dungeon-master",
-	"version": "1.6.1",
+	"version": "1.6.2",
 	"description": "generate fancy datasets",
 	"type": "module",
 	"main": "index.js",
@@ -33,7 +33,7 @@
 		"HOOKS.md"
 	],
 	"engines": {
-		"node": ">=18.0.0"
+		"node": ">=20.20.0"
 	},
 	"publishConfig": {
 		"access": "public"
@@ -87,7 +87,7 @@
 		"dotenv": "^16.4.5",
 		"hyparquet-writer": "^0.6.1",
 		"mixpanel": "^0.18.0",
-		"mixpanel-import": "^3.3.2",
+		"mixpanel-import": "^3.5.1",
 		"p-limit": "^3.1.0",
 		"pino": "^9.0.0",
 		"pino-pretty": "^11.0.0",
@@ -108,4 +108,4 @@
 			"tmp/"
 		]
 	}
-}
+}

package/scripts/verify-stories.mjs

@@ -176,7 +176,8 @@ if (inMemory) {
 
 	// Funnel auto-threading reads VALIDATED funnel fields (conversionWindowDays,
 	// order). The dungeon was not run in this process, so validate the config
-	// here — validateDungeonConfig resolves those defaults in place.
+	// here and use the RETURN value — as of v1.6.2 validateDungeonConfig does not
+	// enrich the object you hand it.
 	const validated = validateDungeonConfig({ ...config, token: '' });
 	const identityMap = buildIdentityMap(profiles);
 

package/types.d.ts

@@ -1324,6 +1324,21 @@ export type Result = {
      * so `userProfilesData.length - profilesPushed` = dropped profile count.
      */
     profilesPushed?: number;
+    /**
+     * v1.6.2: the enriched config this run actually used. `validateDungeonConfig`
+     * no longer writes back to the object you passed in, so resolved values —
+     * `funnels[].conversionWindowDays`, `events[].isStrictEvent`, the resolved
+     * dataset window — must be read here rather than off your own config.
+     *
+     * READ-ONLY. Do NOT feed this back into `DUNGEON_MASTER` — validation is not
+     * idempotent (each pass appends to the funnel set, eventually producing an
+     * empty `sequence`), and the object carries engine scratch fields. Re-run the
+     * ORIGINAL config instead.
+     *
+     * Credentials (`token`, `serviceAccount`, `serviceSecret`, `projectId`,
+     * `credentials`) are stripped — a Result is a thing hosts log.
+     */
+    validatedConfig?: Dungeon;
     /** Progress callback summary. Only present when `onProgress` was provided. */
     progress?: ProgressSummary;
 };