@endora-commerce/platform 0.100.0

package/dist/db/configured-entities.d.ts

@@ -0,0 +1,74 @@
+import { type EntityClassLike } from '../packages/package-runtime.js';
+/**
+ * The entity classes this platform registers: the committed core registry the
+ * host supplies, plus every installed extension package's own (feature 080,
+ * T033 — D-106.2).
+ *
+ * The sibling of `configured-migrations.ts`, and async for the same reason: the
+ * committed registry is emitted by a source-text walk for the MikroORM entity
+ * decorator (`generate-composer.ts`), and compilation turns that decorator into
+ * a `__decorate([...])` call — so a published package contributes nothing to it
+ * and could not, whatever the generator did. Which packages an instance
+ * installed is a fact about the process (D-119/D-155), so the second half is
+ * read at runtime, through the package's own `./backend` export.
+ *
+ * ## The core half is **received**, not imported (`specs/110-instance-repository/` R7.4)
+ *
+ * `entities-registry.generated.ts` is a fact about *one repository's tree*, is
+ * host-owned (D-160.3), and the platform may not name a file in the tree that
+ * installs it (D-52/D-53). So it arrives as a parameter and this file knows
+ * nothing about where it came from. `backend/src/db/configured-entities.ts` is
+ * the binding that supplies it, and an instance writes the same three lines
+ * against its own index — the shape `registered-manifests.ts` took in
+ * `specs/115-lifecycle-container-move/` Phase 3.
+ *
+ * Memoisation stays with the binding for the same reason: how many times one
+ * process may ask is a fact about that process.
+ *
+ * It lives beside the migration seam rather than inside it because the two
+ * answer different questions to different readers — the ORM configuration is
+ * the only reader of the entity set, while the order has three — but both are
+ * one merge over the one discovery in `../packages/`.
+ *
+ * ## It is also where the tenancy chains are reconciled (feature 080, T049)
+ *
+ * Since D-169 a `@TransitivelyScoped` entity names its parent by class name
+ * rather than by importing the class, so a name that resolves to nothing is
+ * possible in a way it was not before — and a transitively scoped entity has no
+ * tenant column of its own, so that would leave it reachable with no tenant
+ * predicate at all (Principle XI, non-negotiable).
+ *
+ * This is the first moment the question can honestly be asked. The decorator
+ * cannot ask it: entity classes register in import order and a child is
+ * routinely imported before its parent. The line below is the instant after
+ * every classification decorator has run — the committed registry above plus
+ * every installed package's entities — and still before the ORM exists, so no
+ * query can have been issued under a chain that does not resolve. It throws
+ * `UnresolvableTenantParentError`, which stops the boot; there is deliberately
+ * no degraded mode, because the degraded mode is an untenanted read.
+ *
+ * Since T054(a) (D-170) it walks the whole chain rather than one hop, and
+ * refuses one that resolves at every step and grounds nowhere — a `global` or
+ * `rule` terminus, a cycle, a run of transitives reaching no keyed
+ * classification. It also emits an `info` line for a chain that terminates at a
+ * `customer`, which is legal and has a gap worth naming; the logger is passed
+ * from here because that is where the platform's destination is nameable, and
+ * `tenancy/` deliberately imports nothing from `kernel/`.
+ */
+export type ConfiguredEntity = EntityClassLike;
+/** What {@link configuredEntitiesFrom} needs from the host. */
+export interface EntityConfigurationInputs {
+    /**
+     * The committed core registry — `ALL_ENTITIES` in this repository's tree.
+     *
+     * Declared as the structural shape rather than imported, for
+     * `DiscoveredManifestEntry`'s reason: `tsc` holds the two together at the
+     * binding's call site, so an entity dropped from the generated array fails in
+     * the host's own type-check.
+     */
+    readonly coreEntities: readonly EntityClassLike[];
+    /** Selects the `node_modules` roots the package scan reads. */
+    readonly env?: NodeJS.ProcessEnv;
+}
+export declare function configuredEntitiesFrom(inputs: EntityConfigurationInputs): Promise<readonly ConfiguredEntity[]>;
+//# sourceMappingURL=configured-entities.d.ts.map

package/dist/db/configured-entities.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"configured-entities.d.ts","sourceRoot":"","sources":["../../src/db/configured-entities.ts"],"names":[],"mappings":"AAAA,OAAO,EAAyB,KAAK,eAAe,EAAE,MAAM,gCAAgC,CAAC;AAK7F;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAuDG;AACH,MAAM,MAAM,gBAAgB,GAAG,eAAe,CAAC;AAE/C,+DAA+D;AAC/D,MAAM,WAAW,yBAAyB;IACxC;;;;;;;OAOG;IACH,QAAQ,CAAC,YAAY,EAAE,SAAS,eAAe,EAAE,CAAC;IAClD,+DAA+D;IAC/D,QAAQ,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC,UAAU,CAAC;CAClC;AAED,wBAAsB,sBAAsB,CAC1C,MAAM,EAAE,yBAAyB,GAChC,OAAO,CAAC,SAAS,gBAAgB,EAAE,CAAC,CActC"}

package/dist/db/configured-entities.js

@@ -0,0 +1,20 @@
+import { discoverPackageSchema } from '../packages/package-runtime.js';
+import { assertTransitiveParentsResolve } from '../tenancy/org-scoped.decorator.js';
+import { platformLogger } from '../kernel/logging.js';
+import { PLATFORM_ENTITIES, mergeByIdentity } from './platform-schema.js';
+export async function configuredEntitiesFrom(inputs) {
+    const packages = await discoverPackageSchema(inputs.env ?? process.env);
+    const entities = [
+        // The platform's own six first (`specs/110-instance-repository/` T141).
+        // They are this package's, and an instance supplies `coreEntities: []` —
+        // which used to mean it registered none of them, so nothing mapped the
+        // tables its own migrations create. Where a host names them, as this
+        // repository's generated registry does by bare specifier, the merge is an
+        // identity de-duplication over the same class objects.
+        ...mergeByIdentity(PLATFORM_ENTITIES, inputs.coreEntities),
+        ...packages.flatMap((contribution) => contribution.entities),
+    ];
+    assertTransitiveParentsResolve(platformLogger());
+    return entities;
+}
+//# sourceMappingURL=configured-entities.js.map

package/dist/db/configured-entities.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"configured-entities.js","sourceRoot":"","sources":["../../src/db/configured-entities.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,qBAAqB,EAAwB,MAAM,gCAAgC,CAAC;AAC7F,OAAO,EAAE,8BAA8B,EAAE,MAAM,oCAAoC,CAAC;AACpF,OAAO,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AACtD,OAAO,EAAE,iBAAiB,EAAE,eAAe,EAAE,MAAM,sBAAsB,CAAC;AA2E1E,MAAM,CAAC,KAAK,UAAU,sBAAsB,CAC1C,MAAiC;IAEjC,MAAM,QAAQ,GAAG,MAAM,qBAAqB,CAAC,MAAM,CAAC,GAAG,IAAI,OAAO,CAAC,GAAG,CAAC,CAAC;IACxE,MAAM,QAAQ,GAAG;QACf,wEAAwE;QACxE,yEAAyE;QACzE,uEAAuE;QACvE,qEAAqE;QACrE,0EAA0E;QAC1E,uDAAuD;QACvD,GAAG,eAAe,CAAC,iBAAiB,EAAE,MAAM,CAAC,YAAY,CAAC;QAC1D,GAAG,QAAQ,CAAC,OAAO,CAAC,CAAC,YAAY,EAAE,EAAE,CAAC,YAAY,CAAC,QAAQ,CAAC;KAC7D,CAAC;IACF,8BAA8B,CAAC,cAAc,EAAE,CAAC,CAAC;IACjD,OAAO,QAAQ,CAAC;AAClB,CAAC"}

package/dist/db/configured-migrations.d.ts

@@ -0,0 +1,199 @@
+import type { MigrationObject } from '@mikro-orm/core';
+import { type PackageSchemaContribution } from '../packages/package-runtime.js';
+import type { DiscoveredManifestEntry } from '../lifecycle/manifest-registry.js';
+import { type MigrationOrderDiagnostic, type MigrationOrigin, type MigrationRegistryEntry } from './migration-order.js';
+/**
+ * The migration order this platform runs, as a value — with no database in it.
+ *
+ * `mikro-orm.config.ts` computed this inline and nothing else could read it,
+ * because reading it meant importing that config, and **the config captures
+ * `DATABASE_URL` at import**: whichever database that variable names when the
+ * first import happens is the one the process migrates for the rest of its
+ * life. The test harness needs the order *before* it knows which database this
+ * run will migrate — issue #289 keys the migration template on it — so the
+ * ordering lives here, where it depends on the registry and the manifests and
+ * on nothing about a connection.
+ *
+ * ## Why it is a function, and an `async` one (feature 080, T033 / D-155.4)
+ *
+ * An installed extension package may ship migrations (D-106.2), and which
+ * packages an instance installed is a fact about *the process*, not about the
+ * tree — so the committed registries stay bare core and the package half is
+ * discovered at runtime (D-119, confirmed as D-155). Discovery reads
+ * `node_modules` and dynamically `import()`s each package's `./migrations`
+ * export, so the merged order can only be a promise.
+ *
+ * It is an **async factory rather than a promise-valued export**, and the
+ * difference is the defect this file was extracted to escape, one axis over: a
+ * promise created at import starts that `node_modules` scan in *every* process
+ * that touches this module — including one that only wanted `RegisteredMigration`
+ * as a type — and turns a discovery failure into an unhandled rejection in any
+ * process that imports without awaiting. A factory does nothing until somebody
+ * asks.
+ *
+ * The result is memoised for the process, because an instance's `node_modules`
+ * does not change while the platform runs and there are fourteen direct
+ * importers of the ORM config; fourteen call sites must not mean fourteen
+ * scans. {@link configuredMigrationsFrom} is the same merge with no discovery
+ * in it, for a caller that brings its own inputs.
+ *
+ * `orderMigrations` throws on a duplicate name, a duplicate per-module
+ * timestamp, an unscoped class name or an unknown module id — a loud,
+ * actionable failure by design, now raised on the first call rather than at
+ * import. A dependency *cycle* is a diagnostic instead, and reacting to it
+ * belongs to the readers: see the comment on the warning loop in
+ * `mikro-orm.config.ts`.
+ */
+/** A migration this platform runs, and which producer contributed it. */
+export interface RegisteredMigration {
+    /** The class name — what `mikro_orm_migrations` records. */
+    readonly name: string;
+    readonly origin: MigrationOrigin;
+}
+/**
+ * Re-exported, declared in `@endora-commerce/platform`.
+ *
+ * The orchestrator is the one caller that *asks* the question, and it lives in
+ * the platform, which may not name a file this application owns (D-52/D-53).
+ * So the shape is declared there and the **answer** — the merge of the
+ * committed core registry with whatever packages this instance installed — is
+ * built here, where the discovery is. One name for it either way.
+ */
+export type { MigrationOwnership } from '../lifecycle/services/migration-ownership.js';
+import type { MigrationOwnership } from '../lifecycle/services/migration-ownership.js';
+/** The result of merging every producer's migrations into one execution order. */
+export interface ConfiguredMigrations {
+    /** Assigned verbatim to `migrations.migrationsList`. */
+    readonly migrations: MigrationObject[];
+    /** The ordered set with each entry's origin. */
+    readonly registered: readonly RegisteredMigration[];
+    /** The class names, in execution order — what a migrated database records. */
+    readonly names: readonly string[];
+    readonly diagnostics: readonly MigrationOrderDiagnostic[];
+    /** Who owns what, for the lifecycle orchestrator's uninstall-revert. */
+    readonly ownership: MigrationOwnership;
+    /** The installed packages this order was merged from. Empty for bare core. */
+    readonly packages: readonly PackageSchemaContribution[];
+}
+/**
+ * The cross-cutting pseudo-module owning the platform's own migrations.
+ *
+ * Declared in `./platform-schema.ts`, beside the twelve migrations it owns, and
+ * re-exported here because five programs outside that file need the same
+ * literal — the scaffolder, the registry round-trip, the instance-order guard
+ * and the two merges below — and a second spelling of a module id is a second
+ * answer waiting to disagree. It moved when this file learned to read that one:
+ * a constant declared here and read back from there is an import cycle
+ * evaluated in whichever order a consumer happened to enter it.
+ */
+export { CORE_MODULE_ID } from './platform-schema.js';
+/**
+ * The committed core artefacts, **received** rather than imported
+ * (`specs/110-instance-repository/` R7.4, FR-014).
+ *
+ * `migrations-registry.generated.ts` and `manifest-index.generated.ts` are
+ * facts about *one repository's tree*, are host-owned (D-160.3, D-104) and stay
+ * bare core under every value of `DEPLOYMENT` — so the platform may not name
+ * either (D-52/D-53). `backend/src/db/configured-migrations.ts` is the binding
+ * that supplies them, and an instance writes the same two lines against its own
+ * artefacts.
+ */
+export interface CoreMigrationSources {
+    /** The committed migration registry — `MIGRATION_REGISTRY` in this tree. */
+    readonly coreEntries: readonly MigrationRegistryEntry[];
+    /**
+     * The generated manifest index this build ships — `DISCOVERED_MANIFESTS`.
+     *
+     * Declared structurally in `../lifecycle/manifest-registry.ts` for the reason
+     * given there: `tsc` holds the generated shape and this one together at the
+     * binding's call site.
+     */
+    readonly manifests: readonly DiscoveredManifestEntry[];
+}
+/**
+ * Build an ownership answer over an explicit registry and an explicit set of
+ * modules that registry is authoritative for.
+ *
+ * The covered set is **not** derived from the entries: a module that ships no
+ * migration is covered and owns none, and those are the two answers that must
+ * not be confused. It comes from the manifests the registry was built
+ * alongside, which is the only thing that knows a module exists at all.
+ */
+export declare function migrationOwnershipOf(entries: readonly MigrationRegistryEntry[], coveredModuleIds: Iterable<string>): MigrationOwnership;
+/**
+ * Ownership over the **committed core registry alone** — no discovery, no
+ * `node_modules`, nothing async.
+ *
+ * This is what a caller that never merged a package gets, and it is a
+ * declaration rather than a fallback: it says *"I was given the core registry,
+ * so I answer for core modules and for nothing else"*. Handed a package's
+ * module id it returns `null`, which the orchestrator refuses on — the right
+ * answer, because a core-only registry genuinely cannot enumerate a package's
+ * chain and reverting nothing would leave the package's table behind.
+ */
+export declare function committedMigrationOwnership(sources: CoreMigrationSources): MigrationOwnership;
+/**
+ * Merge one producer set into an execution order — the whole computation, with
+ * no discovery in it.
+ *
+ * Exported so a test can drive the merge over inputs it built itself, and so
+ * the discovery path below has nothing of its own to get wrong.
+ */
+export declare function configuredMigrationsFrom(inputs: {
+    readonly coreEntries: readonly MigrationRegistryEntry[];
+    readonly coreModuleDependencies: ReadonlyMap<string, readonly string[]>;
+    readonly packages: readonly PackageSchemaContribution[];
+    /**
+     * The frozen historical prefix, by identity. Defaults to the list
+     * `@endora-commerce/platform` publishes, which is what every real composition
+     * uses.
+     *
+     * It is a parameter for the reason the two inputs above are: so a guard can
+     * drive the real merge over a baseline it built itself.
+     * `test/unit/db/instance-migration-order.test.ts` computes the *unrepaired*
+     * membership predicate as a list and orders the same corpus with it, which is
+     * how the defect this feature closed stays measurable after the repair
+     * instead of becoming a sentence in a doc block.
+     */
+    readonly baseline?: readonly string[];
+}): ConfiguredMigrations;
+/**
+ * The committed core dependency map: `core`, plus every manifest the index
+ * holds.
+ *
+ * This is **the** derivation of the migration ordering graph — the one
+ * expression in this platform that turns manifests into the edges
+ * `orderMigrations` walks. D-44 §8 singles it out as the site most likely to be
+ * broken by a well-meaning later edit, because unioning `nonBindingDependencies`
+ * or `acknowledgedDependencies` into it is a two-word change that no type would
+ * catch and that buys a cross-module foreign key whose ordering claim lives in
+ * an array `fk-dependency-drift.test.ts` does not read.
+ *
+ * It is exported for the same reason {@link configuredMigrationsFrom} is: so a
+ * guard can drive the real derivation instead of reading its source text.
+ * `test/contract/_lifecycle/non-binding-dependencies.contract.test.ts` calls it
+ * over the live manifests and holds every entry to `manifest.dependencies`
+ * exactly, and traces the one `orderMigrations` call back to it through
+ * {@link discoverConfiguredMigrations}.
+ *
+ * That trace, and not a rule about callers, is what refuses a second ordering
+ * graph. This sentence used to read *"nothing in `src` calls it but
+ * {@link discoverConfiguredMigrations} — a second caller would be a second
+ * ordering graph"*, and it was already false when it was written: the host binds
+ * this function a second time so that its own tests can drive it over the
+ * generated index, and a second **caller** is neither necessary nor sufficient
+ * for a second **graph**. What the guard counts is calls of `orderMigrations`;
+ * what it follows is the input of the one call there may be.
+ */
+export declare function committedModuleDependencies(manifests: readonly DiscoveredManifestEntry[]): Map<string, readonly string[]>;
+/**
+ * This platform's migration order: the committed core registry the host
+ * supplies, merged with every installed package's `./migrations` export.
+ *
+ * `env` selects the `node_modules` roots (`ENDORA_INSTANCE_ROOT`). Memoisation
+ * is the binding's, not this file's: how many times one process may ask is a
+ * fact about that process, and a memo here would answer a second host's
+ * registry with the first one's order.
+ */
+export declare function discoverConfiguredMigrations(sources: CoreMigrationSources, env?: NodeJS.ProcessEnv): Promise<ConfiguredMigrations>;
+//# sourceMappingURL=configured-migrations.d.ts.map

package/dist/db/configured-migrations.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"configured-migrations.d.ts","sourceRoot":"","sources":["../../src/db/configured-migrations.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,eAAe,EAAE,MAAM,iBAAiB,CAAC;AACvD,OAAO,EAEL,KAAK,yBAAyB,EAC/B,MAAM,gCAAgC,CAAC;AAExC,OAAO,KAAK,EAAE,uBAAuB,EAAE,MAAM,mCAAmC,CAAC;AACjF,OAAO,EAEL,KAAK,wBAAwB,EAC7B,KAAK,eAAe,EACpB,KAAK,sBAAsB,EAC5B,MAAM,sBAAsB,CAAC;AAO9B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAyCG;AAEH,yEAAyE;AACzE,MAAM,WAAW,mBAAmB;IAClC,4DAA4D;IAC5D,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,MAAM,EAAE,eAAe,CAAC;CAClC;AAED;;;;;;;;GAQG;AACH,YAAY,EAAE,kBAAkB,EAAE,MAAM,8CAA8C,CAAC;AACvF,OAAO,KAAK,EAAE,kBAAkB,EAAE,MAAM,8CAA8C,CAAC;AAEvF,kFAAkF;AAClF,MAAM,WAAW,oBAAoB;IACnC,wDAAwD;IACxD,QAAQ,CAAC,UAAU,EAAE,eAAe,EAAE,CAAC;IACvC,gDAAgD;IAChD,QAAQ,CAAC,UAAU,EAAE,SAAS,mBAAmB,EAAE,CAAC;IACpD,8EAA8E;IAC9E,QAAQ,CAAC,KAAK,EAAE,SAAS,MAAM,EAAE,CAAC;IAClC,QAAQ,CAAC,WAAW,EAAE,SAAS,wBAAwB,EAAE,CAAC;IAC1D,wEAAwE;IACxE,QAAQ,CAAC,SAAS,EAAE,kBAAkB,CAAC;IACvC,8EAA8E;IAC9E,QAAQ,CAAC,QAAQ,EAAE,SAAS,yBAAyB,EAAE,CAAC;CACzD;AAED;;;;;;;;;;GAUG;AACH,OAAO,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AAEtD;;;;;;;;;;GAUG;AACH,MAAM,WAAW,oBAAoB;IACnC,4EAA4E;IAC5E,QAAQ,CAAC,WAAW,EAAE,SAAS,sBAAsB,EAAE,CAAC;IACxD;;;;;;OAMG;IACH,QAAQ,CAAC,SAAS,EAAE,SAAS,uBAAuB,EAAE,CAAC;CACxD;AAED;;;;;;;;GAQG;AACH,wBAAgB,oBAAoB,CAClC,OAAO,EAAE,SAAS,sBAAsB,EAAE,EAC1C,gBAAgB,EAAE,QAAQ,CAAC,MAAM,CAAC,GACjC,kBAAkB,CAgBpB;AAOD;;;;;;;;;;GAUG;AACH,wBAAgB,2BAA2B,CAAC,OAAO,EAAE,oBAAoB,GAAG,kBAAkB,CAE7F;AAED;;;;;;GAMG;AACH,wBAAgB,wBAAwB,CAAC,MAAM,EAAE;IAC/C,QAAQ,CAAC,WAAW,EAAE,SAAS,sBAAsB,EAAE,CAAC;IACxD,QAAQ,CAAC,sBAAsB,EAAE,WAAW,CAAC,MAAM,EAAE,SAAS,MAAM,EAAE,CAAC,CAAC;IACxE,QAAQ,CAAC,QAAQ,EAAE,SAAS,yBAAyB,EAAE,CAAC;IACxD;;;;;;;;;;;OAWG;IACH,QAAQ,CAAC,QAAQ,CAAC,EAAE,SAAS,MAAM,EAAE,CAAC;CACvC,GAAG,oBAAoB,CAqDvB;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,wBAAgB,2BAA2B,CACzC,SAAS,EAAE,SAAS,uBAAuB,EAAE,GAC5C,GAAG,CAAC,MAAM,EAAE,SAAS,MAAM,EAAE,CAAC,CAKhC;AAED;;;;;;;;GAQG;AACH,wBAAsB,4BAA4B,CAChD,OAAO,EAAE,oBAAoB,EAC7B,GAAG,GAAE,MAAM,CAAC,UAAwB,GACnC,OAAO,CAAC,oBAAoB,CAAC,CAoB/B"}

package/dist/db/configured-migrations.js

@@ -0,0 +1,181 @@
+import { discoverPackageSchema, } from '../packages/package-runtime.js';
+import { BASELINE_MIGRATIONS } from '../migrations/index.js';
+import { orderMigrations, } from './migration-order.js';
+import { CORE_MODULE_ID, PLATFORM_MIGRATION_ENTRIES, mergeByIdentity, } from './platform-schema.js';
+/**
+ * The cross-cutting pseudo-module owning the platform's own migrations.
+ *
+ * Declared in `./platform-schema.ts`, beside the twelve migrations it owns, and
+ * re-exported here because five programs outside that file need the same
+ * literal — the scaffolder, the registry round-trip, the instance-order guard
+ * and the two merges below — and a second spelling of a module id is a second
+ * answer waiting to disagree. It moved when this file learned to read that one:
+ * a constant declared here and read back from there is an import cycle
+ * evaluated in whichever order a consumer happened to enter it.
+ */
+export { CORE_MODULE_ID } from './platform-schema.js';
+/**
+ * Build an ownership answer over an explicit registry and an explicit set of
+ * modules that registry is authoritative for.
+ *
+ * The covered set is **not** derived from the entries: a module that ships no
+ * migration is covered and owns none, and those are the two answers that must
+ * not be confused. It comes from the manifests the registry was built
+ * alongside, which is the only thing that knows a module exists at all.
+ */
+export function migrationOwnershipOf(entries, coveredModuleIds) {
+    const covered = new Set(coveredModuleIds);
+    const byModule = new Map();
+    for (const entry of entries) {
+        const names = byModule.get(entry.moduleId);
+        if (names)
+            names.push(entry.cls.name);
+        else
+            byModule.set(entry.moduleId, [entry.cls.name]);
+    }
+    for (const names of byModule.values())
+        names.sort();
+    return {
+        coveredModuleIds: covered,
+        migrationNamesFor(moduleId) {
+            if (!covered.has(moduleId))
+                return null;
+            return byModule.get(moduleId) ?? [];
+        },
+    };
+}
+/** Every module id the committed core artefacts answer for, plus `core` itself. */
+function coreModuleIds(manifests) {
+    return [CORE_MODULE_ID, ...manifests.map((entry) => entry.id)];
+}
+/**
+ * Ownership over the **committed core registry alone** — no discovery, no
+ * `node_modules`, nothing async.
+ *
+ * This is what a caller that never merged a package gets, and it is a
+ * declaration rather than a fallback: it says *"I was given the core registry,
+ * so I answer for core modules and for nothing else"*. Handed a package's
+ * module id it returns `null`, which the orchestrator refuses on — the right
+ * answer, because a core-only registry genuinely cannot enumerate a package's
+ * chain and reverting nothing would leave the package's table behind.
+ */
+export function committedMigrationOwnership(sources) {
+    return migrationOwnershipOf(sources.coreEntries, coreModuleIds(sources.manifests));
+}
+/**
+ * Merge one producer set into an execution order — the whole computation, with
+ * no discovery in it.
+ *
+ * Exported so a test can drive the merge over inputs it built itself, and so
+ * the discovery path below has nothing of its own to get wrong.
+ */
+export function configuredMigrationsFrom(inputs) {
+    const entries = [
+        ...inputs.coreEntries,
+        ...inputs.packages.flatMap((contribution) => contribution.migrations),
+    ];
+    const moduleDependencies = new Map(inputs.coreModuleDependencies);
+    // A package's own module is a node in the graph like any other, so its chain
+    // lands at its topological position. Its `dependencies` are read from the
+    // manifest the package published; an id already in the map is a collision
+    // `assertNoPackageModuleIdCollisions` refused before anything got here.
+    //
+    // Until `specs/110-instance-repository/` T141 that first clause was a comment
+    // and not a fact: the fallback was `[]`, and it was unreachable in this
+    // repository because the committed index carries every module package. An
+    // instance has no index, so every module was a graph root and feature 081's
+    // per-module order became whichever order the tie-break produced.
+    for (const contribution of inputs.packages) {
+        if (!moduleDependencies.has(contribution.id)) {
+            moduleDependencies.set(contribution.id, contribution.dependencies);
+        }
+    }
+    const ordered = orderMigrations({
+        entries,
+        moduleDependencies,
+        baseline: inputs.baseline ?? BASELINE_MIGRATIONS,
+    });
+    const registryByName = new Map(entries.map((entry) => [entry.cls.name, entry]));
+    const registered = ordered.migrations.map((migration) => {
+        const entry = registryByName.get(migration.name);
+        if (entry === undefined) {
+            throw new Error(`[configured-migrations] "${migration.name}" is in the migration order but not in the ` +
+                `registry that order was computed from, so nothing here can say which producer it ` +
+                `came from. Whoever merges a second producer's migrations into this order must merge ` +
+                `their registry entries too — the test harness floors its template digest per origin.`);
+        }
+        return { name: migration.name, origin: entry.origin ?? 'core' };
+    });
+    return {
+        migrations: ordered.migrations,
+        registered,
+        names: registered.map((migration) => migration.name),
+        diagnostics: ordered.diagnostics,
+        ownership: migrationOwnershipOf(entries, [
+            ...inputs.coreModuleDependencies.keys(),
+            ...inputs.packages.map((contribution) => contribution.id),
+        ]),
+        packages: inputs.packages,
+    };
+}
+/**
+ * The committed core dependency map: `core`, plus every manifest the index
+ * holds.
+ *
+ * This is **the** derivation of the migration ordering graph — the one
+ * expression in this platform that turns manifests into the edges
+ * `orderMigrations` walks. D-44 §8 singles it out as the site most likely to be
+ * broken by a well-meaning later edit, because unioning `nonBindingDependencies`
+ * or `acknowledgedDependencies` into it is a two-word change that no type would
+ * catch and that buys a cross-module foreign key whose ordering claim lives in
+ * an array `fk-dependency-drift.test.ts` does not read.
+ *
+ * It is exported for the same reason {@link configuredMigrationsFrom} is: so a
+ * guard can drive the real derivation instead of reading its source text.
+ * `test/contract/_lifecycle/non-binding-dependencies.contract.test.ts` calls it
+ * over the live manifests and holds every entry to `manifest.dependencies`
+ * exactly, and traces the one `orderMigrations` call back to it through
+ * {@link discoverConfiguredMigrations}.
+ *
+ * That trace, and not a rule about callers, is what refuses a second ordering
+ * graph. This sentence used to read *"nothing in `src` calls it but
+ * {@link discoverConfiguredMigrations} — a second caller would be a second
+ * ordering graph"*, and it was already false when it was written: the host binds
+ * this function a second time so that its own tests can drive it over the
+ * generated index, and a second **caller** is neither necessary nor sufficient
+ * for a second **graph**. What the guard counts is calls of `orderMigrations`;
+ * what it follows is the input of the one call there may be.
+ */
+export function committedModuleDependencies(manifests) {
+    return new Map([
+        [CORE_MODULE_ID, []],
+        ...manifests.map((entry) => [entry.id, entry.manifest.dependencies ?? []]),
+    ]);
+}
+/**
+ * This platform's migration order: the committed core registry the host
+ * supplies, merged with every installed package's `./migrations` export.
+ *
+ * `env` selects the `node_modules` roots (`ENDORA_INSTANCE_ROOT`). Memoisation
+ * is the binding's, not this file's: how many times one process may ask is a
+ * fact about that process, and a memo here would answer a second host's
+ * registry with the first one's order.
+ */
+export async function discoverConfiguredMigrations(sources, env = process.env) {
+    return configuredMigrationsFrom({
+        // The platform's own twelve are merged in here rather than asked of the
+        // host (`specs/110-instance-repository/` T141). They are this package's
+        // schema, a client receives them by installing it, and an instance supplies
+        // `coreEntries: []` — which used to mean it ran none of them and died on
+        // the first module migration to touch a table `core_foundation_init`
+        // creates. Where a host does name them, as this repository's generated
+        // registry does by bare specifier, the merge is an identity de-duplication
+        // over the same objects and changes nothing; two objects of one name mean
+        // two copies of this package in one process (D-160.6), which survives as a
+        // duplicate name and is refused by `orderMigrations`' own rule.
+        coreEntries: mergeByIdentity(sources.coreEntries, PLATFORM_MIGRATION_ENTRIES, (entry) => entry.cls),
+        coreModuleDependencies: committedModuleDependencies(sources.manifests),
+        packages: await discoverPackageSchema(env),
+    });
+}
+//# sourceMappingURL=configured-migrations.js.map

package/dist/db/configured-migrations.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"configured-migrations.js","sourceRoot":"","sources":["../../src/db/configured-migrations.ts"],"names":[],"mappings":"AACA,OAAO,EACL,qBAAqB,GAEtB,MAAM,gCAAgC,CAAC;AACxC,OAAO,EAAE,mBAAmB,EAAE,MAAM,wBAAwB,CAAC;AAE7D,OAAO,EACL,eAAe,GAIhB,MAAM,sBAAsB,CAAC;AAC9B,OAAO,EACL,cAAc,EACd,0BAA0B,EAC1B,eAAe,GAChB,MAAM,sBAAsB,CAAC;AA+E9B;;;;;;;;;;GAUG;AACH,OAAO,EAAE,cAAc,EAAE,MAAM,sBAAsB,CAAC;AA0BtD;;;;;;;;GAQG;AACH,MAAM,UAAU,oBAAoB,CAClC,OAA0C,EAC1C,gBAAkC;IAElC,MAAM,OAAO,GAAG,IAAI,GAAG,CAAC,gBAAgB,CAAC,CAAC;IAC1C,MAAM,QAAQ,GAAG,IAAI,GAAG,EAAoB,CAAC;IAC7C,KAAK,MAAM,KAAK,IAAI,OAAO,EAAE,CAAC;QAC5B,MAAM,KAAK,GAAG,QAAQ,CAAC,GAAG,CAAC,KAAK,CAAC,QAAQ,CAAC,CAAC;QAC3C,IAAI,KAAK;YAAE,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC;;YACjC,QAAQ,CAAC,GAAG,CAAC,KAAK,CAAC,QAAQ,EAAE,CAAC,KAAK,CAAC,GAAG,CAAC,IAAI,CAAC,CAAC,CAAC;IACtD,CAAC;IACD,KAAK,MAAM,KAAK,IAAI,QAAQ,CAAC,MAAM,EAAE;QAAE,KAAK,CAAC,IAAI,EAAE,CAAC;IACpD,OAAO;QACL,gBAAgB,EAAE,OAAO;QACzB,iBAAiB,CAAC,QAAgB;YAChC,IAAI,CAAC,OAAO,CAAC,GAAG,CAAC,QAAQ,CAAC;gBAAE,OAAO,IAAI,CAAC;YACxC,OAAO,QAAQ,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,EAAE,CAAC;QACtC,CAAC;KACF,CAAC;AACJ,CAAC;AAED,mFAAmF;AACnF,SAAS,aAAa,CAAC,SAA6C;IAClE,OAAO,CAAC,cAAc,EAAE,GAAG,SAAS,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,CAAC;AACjE,CAAC;AAED;;;;;;;;;;GAUG;AACH,MAAM,UAAU,2BAA2B,CAAC,OAA6B;IACvE,OAAO,oBAAoB,CAAC,OAAO,CAAC,WAAW,EAAE,aAAa,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC,CAAC;AACrF,CAAC;AAED;;;;;;GAMG;AACH,MAAM,UAAU,wBAAwB,CAAC,MAiBxC;IACC,MAAM,OAAO,GAA6B;QACxC,GAAG,MAAM,CAAC,WAAW;QACrB,GAAG,MAAM,CAAC,QAAQ,CAAC,OAAO,CAAC,CAAC,YAAY,EAAE,EAAE,CAAC,YAAY,CAAC,UAAU,CAAC;KACtE,CAAC;IACF,MAAM,kBAAkB,GAAG,IAAI,GAAG,CAAC,MAAM,CAAC,sBAAsB,CAAC,CAAC;IAClE,6EAA6E;IAC7E,0EAA0E;IAC1E,0EAA0E;IAC1E,wEAAwE;IACxE,EAAE;IACF,8EAA8E;IAC9E,wEAAwE;IACxE,0EAA0E;IAC1E,4EAA4E;IAC5E,kEAAkE;IAClE,KAAK,MAAM,YAAY,IAAI,MAAM,CAAC,QAAQ,EAAE,CAAC;QAC3C,IAAI,CAAC,kBAAkB,CAAC,GAAG,CAAC,YAAY,CAAC,EAAE,CAAC,EAAE,CAAC;YAC7C,kBAAkB,CAAC,GAAG,CAAC,YAAY,CAAC,EAAE,EAAE,YAAY,CAAC,YAAY,CAAC,CAAC;QACrE,CAAC;IACH,CAAC;IAED,MAAM,OAAO,GAAG,eAAe,CAAC;QAC9B,OAAO;QACP,kBAAkB;QAClB,QAAQ,EAAE,MAAM,CAAC,QAAQ,IAAI,mBAAmB;KACjD,CAAC,CAAC;IAEH,MAAM,cAAc,GAAG,IAAI,GAAG,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,IAAI,EAAE,KAAK,CAAU,CAAC,CAAC,CAAC;IACzF,MAAM,UAAU,GAA0B,OAAO,CAAC,UAAU,CAAC,GAAG,CAAC,CAAC,SAAS,EAAE,EAAE;QAC7E,MAAM,KAAK,GAAG,cAAc,CAAC,GAAG,CAAC,SAAS,CAAC,IAAI,CAAC,CAAC;QACjD,IAAI,KAAK,KAAK,SAAS,EAAE,CAAC;YACxB,MAAM,IAAI,KAAK,CACb,4BAA4B,SAAS,CAAC,IAAI,6CAA6C;gBACrF,mFAAmF;gBACnF,sFAAsF;gBACtF,sFAAsF,CACzF,CAAC;QACJ,CAAC;QACD,OAAO,EAAE,IAAI,EAAE,SAAS,CAAC,IAAI,EAAE,MAAM,EAAE,KAAK,CAAC,MAAM,IAAI,MAAM,EAAE,CAAC;IAClE,CAAC,CAAC,CAAC;IAEH,OAAO;QACL,UAAU,EAAE,OAAO,CAAC,UAAU;QAC9B,UAAU;QACV,KAAK,EAAE,UAAU,CAAC,GAAG,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,IAAI,CAAC;QACpD,WAAW,EAAE,OAAO,CAAC,WAAW;QAChC,SAAS,EAAE,oBAAoB,CAAC,OAAO,EAAE;YACvC,GAAG,MAAM,CAAC,sBAAsB,CAAC,IAAI,EAAE;YACvC,GAAG,MAAM,CAAC,QAAQ,CAAC,GAAG,CAAC,CAAC,YAAY,EAAE,EAAE,CAAC,YAAY,CAAC,EAAE,CAAC;SAC1D,CAAC;QACF,QAAQ,EAAE,MAAM,CAAC,QAAQ;KAC1B,CAAC;AACJ,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;GA2BG;AACH,MAAM,UAAU,2BAA2B,CACzC,SAA6C;IAE7C,OAAO,IAAI,GAAG,CAA4B;QACxC,CAAC,cAAc,EAAE,EAAE,CAAC;QACpB,GAAG,SAAS,CAAC,GAAG,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,CAAC,KAAK,CAAC,EAAE,EAAE,KAAK,CAAC,QAAQ,CAAC,YAAY,IAAI,EAAE,CAAU,CAAC;KACpF,CAAC,CAAC;AACL,CAAC;AAED;;;;;;;;GAQG;AACH,MAAM,CAAC,KAAK,UAAU,4BAA4B,CAChD,OAA6B,EAC7B,MAAyB,OAAO,CAAC,GAAG;IAEpC,OAAO,wBAAwB,CAAC;QAC9B,wEAAwE;QACxE,wEAAwE;QACxE,4EAA4E;QAC5E,yEAAyE;QACzE,qEAAqE;QACrE,uEAAuE;QACvE,2EAA2E;QAC3E,0EAA0E;QAC1E,2EAA2E;QAC3E,gEAAgE;QAChE,WAAW,EAAE,eAAe,CAC1B,OAAO,CAAC,WAAW,EACnB,0BAA0B,EAC1B,CAAC,KAAK,EAAE,EAAE,CAAC,KAAK,CAAC,GAAG,CACrB;QACD,sBAAsB,EAAE,2BAA2B,CAAC,OAAO,CAAC,SAAS,CAAC;QACtE,QAAQ,EAAE,MAAM,qBAAqB,CAAC,GAAG,CAAC;KAC3C,CAAC,CAAC;AACL,CAAC"}

package/dist/db/index.d.ts

@@ -0,0 +1,54 @@
+/**
+ * `./db` — the ORM configuration, the migration ordering and the bootstrap,
+ * and the platform's twelfth subpath (`specs/110-instance-repository/` T116,
+ * FR-013).
+ *
+ * ## What is on it
+ *
+ * Everything between a committed registry and an open `MikroORM`: the naming
+ * strategy Principle VI is enforced by, the order a migration corpus runs in,
+ * the two merges that fold an installed package's entities and migrations into
+ * the committed core ones, the configuration itself, the cached bootstrap and
+ * the four migration verbs.
+ *
+ * It reads no artefact. The two committed registries and the generated manifest
+ * index are facts about *one repository's tree* (D-160.3, D-104), so they arrive
+ * as parameters — R7.4, FR-014, the pattern `registered-manifests.ts` took one
+ * directory over. What is left in `backend/src/db/` is exactly that supply: the
+ * generated files themselves, five bindings that hand them over, and the
+ * `migrate.ts` entry point four `package.json` scripts name.
+ *
+ * ## Why the platform carries it
+ *
+ * A client's schema is the platform's, not the client's: the tables, the order
+ * they are created in and the strategy that names their columns are what makes
+ * an installed module's migration apply cleanly, and a tree that could edit any
+ * of them is a tree whose next `pnpm update` is a merge. `../migrations/`
+ * carries the platform's own twelve migrations for the same reason and is the
+ * other half of this answer.
+ *
+ * ## Why no module may name it
+ *
+ * D-160.14's third state, for `./composition`'s own reason. This is the code
+ * that decides which entity classes the ORM registers and which migrations run
+ * at all, so a module that could name it could configure — and eventually
+ * re-order — its siblings' schema. It is declared by the `exports` map and
+ * carried by no published barrel, so `node` and `tsc` resolve it for the host
+ * and the test kit, and `check:platform-surface` answers a module's reach into
+ * it with `host-internal-subpath`. A module reaches its own schema through its
+ * own `./migrations` subpath and its entities through `./backend`; neither
+ * needs this one.
+ *
+ * The barrel names every symbol explicitly rather than re-exporting a
+ * directory: `check:platform-surface` exits 2 on an `export *`, because a
+ * wildcard makes the published set a property of whatever the files happen to
+ * declare rather than of a decision anybody took.
+ */
+export { PluralizingNamingStrategy, pluralize, toSnakeCase, } from './pluralizing-naming-strategy.js';
+export { BASELINE_THROUGH, findModuleCycles, historicalBaselineOrder, MigrationOrderError, orderMigrations, type MigrationClass, type MigrationOrderDiagnostic, type MigrationOrderErrorCode, type MigrationOrderResult, type MigrationOrigin, type MigrationRegistryEntry, type OrderMigrationsInput, } from './migration-order.js';
+export { configuredEntitiesFrom, type ConfiguredEntity, type EntityConfigurationInputs, } from './configured-entities.js';
+export { committedMigrationOwnership, committedModuleDependencies, configuredMigrationsFrom, discoverConfiguredMigrations, migrationOwnershipOf, CORE_MODULE_ID, type ConfiguredMigrations, type CoreMigrationSources, type MigrationOwnership, type RegisteredMigration, } from './configured-migrations.js';
+export { mikroOrmConfigFrom, type OrmConfigurationInputs, } from './mikro-orm.config.js';
+export { createOrmBootstrap, type OrmBootstrap } from './orm.js';
+export { runMigrationCommand, type MigrationCommandIo } from './migrate.js';
+//# sourceMappingURL=index.d.ts.map

package/dist/db/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/db/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AAEH,OAAO,EACL,yBAAyB,EACzB,SAAS,EACT,WAAW,GACZ,MAAM,kCAAkC,CAAC;AAE1C,OAAO,EACL,gBAAgB,EAChB,gBAAgB,EAChB,uBAAuB,EACvB,mBAAmB,EACnB,eAAe,EACf,KAAK,cAAc,EACnB,KAAK,wBAAwB,EAC7B,KAAK,uBAAuB,EAC5B,KAAK,oBAAoB,EACzB,KAAK,eAAe,EACpB,KAAK,sBAAsB,EAC3B,KAAK,oBAAoB,GAC1B,MAAM,sBAAsB,CAAC;AAE9B,OAAO,EACL,sBAAsB,EACtB,KAAK,gBAAgB,EACrB,KAAK,yBAAyB,GAC/B,MAAM,0BAA0B,CAAC;AAElC,OAAO,EACL,2BAA2B,EAC3B,2BAA2B,EAC3B,wBAAwB,EACxB,4BAA4B,EAC5B,oBAAoB,EACpB,cAAc,EACd,KAAK,oBAAoB,EACzB,KAAK,oBAAoB,EACzB,KAAK,kBAAkB,EACvB,KAAK,mBAAmB,GACzB,MAAM,4BAA4B,CAAC;AAEpC,OAAO,EACL,kBAAkB,EAClB,KAAK,sBAAsB,GAC5B,MAAM,uBAAuB,CAAC;AAE/B,OAAO,EAAE,kBAAkB,EAAE,KAAK,YAAY,EAAE,MAAM,UAAU,CAAC;AAEjE,OAAO,EAAE,mBAAmB,EAAE,KAAK,kBAAkB,EAAE,MAAM,cAAc,CAAC"}

package/dist/db/index.js

@@ -0,0 +1,54 @@
+/**
+ * `./db` — the ORM configuration, the migration ordering and the bootstrap,
+ * and the platform's twelfth subpath (`specs/110-instance-repository/` T116,
+ * FR-013).
+ *
+ * ## What is on it
+ *
+ * Everything between a committed registry and an open `MikroORM`: the naming
+ * strategy Principle VI is enforced by, the order a migration corpus runs in,
+ * the two merges that fold an installed package's entities and migrations into
+ * the committed core ones, the configuration itself, the cached bootstrap and
+ * the four migration verbs.
+ *
+ * It reads no artefact. The two committed registries and the generated manifest
+ * index are facts about *one repository's tree* (D-160.3, D-104), so they arrive
+ * as parameters — R7.4, FR-014, the pattern `registered-manifests.ts` took one
+ * directory over. What is left in `backend/src/db/` is exactly that supply: the
+ * generated files themselves, five bindings that hand them over, and the
+ * `migrate.ts` entry point four `package.json` scripts name.
+ *
+ * ## Why the platform carries it
+ *
+ * A client's schema is the platform's, not the client's: the tables, the order
+ * they are created in and the strategy that names their columns are what makes
+ * an installed module's migration apply cleanly, and a tree that could edit any
+ * of them is a tree whose next `pnpm update` is a merge. `../migrations/`
+ * carries the platform's own twelve migrations for the same reason and is the
+ * other half of this answer.
+ *
+ * ## Why no module may name it
+ *
+ * D-160.14's third state, for `./composition`'s own reason. This is the code
+ * that decides which entity classes the ORM registers and which migrations run
+ * at all, so a module that could name it could configure — and eventually
+ * re-order — its siblings' schema. It is declared by the `exports` map and
+ * carried by no published barrel, so `node` and `tsc` resolve it for the host
+ * and the test kit, and `check:platform-surface` answers a module's reach into
+ * it with `host-internal-subpath`. A module reaches its own schema through its
+ * own `./migrations` subpath and its entities through `./backend`; neither
+ * needs this one.
+ *
+ * The barrel names every symbol explicitly rather than re-exporting a
+ * directory: `check:platform-surface` exits 2 on an `export *`, because a
+ * wildcard makes the published set a property of whatever the files happen to
+ * declare rather than of a decision anybody took.
+ */
+export { PluralizingNamingStrategy, pluralize, toSnakeCase, } from './pluralizing-naming-strategy.js';
+export { BASELINE_THROUGH, findModuleCycles, historicalBaselineOrder, MigrationOrderError, orderMigrations, } from './migration-order.js';
+export { configuredEntitiesFrom, } from './configured-entities.js';
+export { committedMigrationOwnership, committedModuleDependencies, configuredMigrationsFrom, discoverConfiguredMigrations, migrationOwnershipOf, CORE_MODULE_ID, } from './configured-migrations.js';
+export { mikroOrmConfigFrom, } from './mikro-orm.config.js';
+export { createOrmBootstrap } from './orm.js';
+export { runMigrationCommand } from './migrate.js';
+//# sourceMappingURL=index.js.map

package/dist/db/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/db/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AAEH,OAAO,EACL,yBAAyB,EACzB,SAAS,EACT,WAAW,GACZ,MAAM,kCAAkC,CAAC;AAE1C,OAAO,EACL,gBAAgB,EAChB,gBAAgB,EAChB,uBAAuB,EACvB,mBAAmB,EACnB,eAAe,GAQhB,MAAM,sBAAsB,CAAC;AAE9B,OAAO,EACL,sBAAsB,GAGvB,MAAM,0BAA0B,CAAC;AAElC,OAAO,EACL,2BAA2B,EAC3B,2BAA2B,EAC3B,wBAAwB,EACxB,4BAA4B,EAC5B,oBAAoB,EACpB,cAAc,GAKf,MAAM,4BAA4B,CAAC;AAEpC,OAAO,EACL,kBAAkB,GAEnB,MAAM,uBAAuB,CAAC;AAE/B,OAAO,EAAE,kBAAkB,EAAqB,MAAM,UAAU,CAAC;AAEjE,OAAO,EAAE,mBAAmB,EAA2B,MAAM,cAAc,CAAC"}

package/dist/db/migrate.d.ts

@@ -0,0 +1,21 @@
+import type { MikroORM } from '@mikro-orm/postgresql';
+/**
+ * The four migration verbs, as a function of an open ORM.
+ *
+ * The **entry point** stays in the application — `backend/src/db/migrate.ts`,
+ * which `db:fresh`, `migration:up`, `migration:down` and `migration:pending`
+ * spawn and which production runs as `node dist/db/migrate.js up`. That split is
+ * `specs/115-lifecycle-container-move/contracts/operator-half.md` §1.1's, one
+ * surface over: a path a `package.json` script names is an operator-facing
+ * address, so it stays where the operator's documentation says it is, while the
+ * verbs behind it are the platform's and every instance runs the same four.
+ *
+ * It writes to injected streams and returns an exit code rather than calling
+ * `process.exit`, so the entry point owns the process and this owns the work.
+ */
+export interface MigrationCommandIo {
+    readonly out: (line: string) => void;
+    readonly err: (line: string) => void;
+}
+export declare function runMigrationCommand(orm: MikroORM, command: string, io: MigrationCommandIo): Promise<number>;
+//# sourceMappingURL=migrate.d.ts.map

package/dist/db/migrate.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"migrate.d.ts","sourceRoot":"","sources":["../../src/db/migrate.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,QAAQ,EAAE,MAAM,uBAAuB,CAAC;AAEtD;;;;;;;;;;;;;GAaG;AACH,MAAM,WAAW,kBAAkB;IACjC,QAAQ,CAAC,GAAG,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IACrC,QAAQ,CAAC,GAAG,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;CACtC;AAED,wBAAsB,mBAAmB,CACvC,GAAG,EAAE,QAAQ,EACb,OAAO,EAAE,MAAM,EACf,EAAE,EAAE,kBAAkB,GACrB,OAAO,CAAC,MAAM,CAAC,CA2CjB"}