@endora-commerce/mod-payment-methods 0.100.0

package/dist/backend/services/payment-method-reconciler.js

@@ -0,0 +1,164 @@
+import { SalesChannel } from '@endora-commerce/platform/kernel';
+import { PaymentMethod } from '../entities/payment-method.entity.js';
+/**
+ * PaymentMethodReconciler (feature 034, FR-002) — the implementation behind
+ * `PaymentMethodSeedApi`, this module's published install surface
+ * (`../../ports/index.ts`, `createPaymentMethodSeeder` below).
+ *
+ * When a module contributes a payment adapter, it calls `ensureMethodForAdapter`
+ * from its **install hook** to create a configurable `payment_methods` row bound
+ * to that adapter — so installing a payment-method module surfaces an entry at
+ * `/payment-methods` with no core change. Idempotent and prune-safe: an existing
+ * row (matched by `code`) keeps its admin-edited configuration; the reconciler
+ * only fills a missing `adapter` link.
+ *
+ * The row and the adapter are contributed at **different moments, on purpose**.
+ * This row is durable state and is written once, at install; the adapter is an
+ * in-memory entry in a per-process table and is pushed from the contributing
+ * module's boot hook, on every composition (see `payment-adapter-registry.ts`).
+ * Neither waits for the other: a row whose `adapter` key nothing has contributed
+ * is simply not offered, and the registry is not read until a request reads it.
+ *
+ * **The `EntityManager` is a parameter of every method and is never held**
+ * (feature 134, FR-064; D-169). It used to be a constructor `emFactory`, which is
+ * the shape of a service resolved from a container — and the caller this class
+ * was written for has no container: `ModuleLifecycleContext` is
+ * `{ em, redis, log, module }` and `module:install` composes nothing (D-46). The
+ * hook's own `ctx.em` is therefore what every statement here runs on, handed in
+ * at the call, so the write lands in the transaction the orchestrator will
+ * commit or revert rather than on a fork of it.
+ *
+ * **It no longer touches sales-channel membership unconditionally (issue #96).**
+ * It used to call `bindToDefaultIfEmpty` for every row it created, and the four
+ * gateway modules called it from their plugin body on every composition — so a
+ * method an operator had deliberately unbound from every channel came back bound
+ * to Default at the next boot, and nothing said so. Binding belongs to the two
+ * seams that own the decision: the admin create path (a method an operator just
+ * created has to land somewhere) and the module's own seed (once, for the rows it
+ * creates). `bindToDefaultChannel` below is that second seam, and the caller
+ * guards it on `created === true`. "Unbound" is a state an operator is entitled
+ * to reach and to keep.
+ */
+export class PaymentMethodReconciler {
+    async ensureMethodForAdapter(em, adapterKey, defaults) {
+        // command-coverage-ignore: idempotent reconciliation of adapter-backed payment
+        // methods — a system-invariant repair, not an operator-initiated write.
+        const existing = await em.findOne(PaymentMethod, { code: defaults.code });
+        if (existing) {
+            // Prune-safe: never clobber admin configuration. Only backfill a
+            // missing adapter link (e.g. a legacy row predating this feature).
+            if (!existing.adapter) {
+                existing.adapter = adapterKey;
+                await em.persistAndFlush(existing);
+            }
+            return { row: recordOf(existing), created: false };
+        }
+        const row = em.create(PaymentMethod, {
+            code: defaults.code,
+            name: defaults.name,
+            kind: defaults.type,
+            adapter: adapterKey,
+            status: defaults.status ?? 'active',
+            additionalPrice: defaults.additionalPrice ?? '0',
+            statusOnPending: defaults.statusOnPending ?? 'new',
+            statusOnSuccess: defaults.statusOnSuccess ?? 'paid',
+            // Feature 085 (FR-003) — see the twin default in
+            // `commands/payment-method.commands.ts`. It is also what retires the five
+            // `*_failure_status_on_hold` migrations with no replacement: a fresh
+            // install through this seam can no longer produce the `'cancelled'` they
+            // exist to correct (`contracts/foreign-write-repair.md` §4).
+            statusOnFailure: defaults.statusOnFailure ?? 'on_hold',
+        });
+        await em.persistAndFlush(row);
+        return { row: recordOf(row), created: true };
+    }
+    /**
+     * The seed's channel binding — one membership row in the system-default
+     * channel, written against **this module's own** bridge table.
+     *
+     * Not through `SalesChannelMembershipService`, and the reason is structural
+     * rather than a preference: that service needs the `EventBus`, the audit port
+     * and the channel-bridge registry, and the registry is contributed from a boot
+     * hook. An install composes nothing, so at this seam it holds no registration
+     * for `'payment-method'` and `bridges.require` would refuse (FR-017) before the
+     * database was touched. `sales_channel_payment_methods` is this module's since
+     * `specs/120-migration-closure-bridge-ownership/` Phase 2 (D-226), so the
+     * statement is the owner's own and crosses no boundary — which is what FR-064
+     * buys by putting the writer here instead of in the seeding module.
+     *
+     * The channel itself is read through the kernel's own `SalesChannel` entity
+     * rather than in SQL — `api_keys` reads it the same way — because a raw
+     * `select … from "sales_channels"` from a module is a `check:module-boundary`
+     * finding against a kernel-owned table, and correctly so: the table is not
+     * this module's and the entity is the platform's published name for it.
+     *
+     * `em.execute` for the insert rather than `em.getConnection().execute`, so the
+     * statement runs inside the caller's transaction (issue #200). The bridge has
+     * no entity class — the kernel's membership service writes it in SQL too.
+     *
+     * **No system-default channel answers `false` rather than raising**, exactly as
+     * the delivery twin does and for the same measured reason: the default channel
+     * is created by `DefaultChannelReconciler` at **boot**, from `composeApp`, and
+     * `module:install` composes nothing (D-46), so a database that has been migrated
+     * and never booted has none. The seed migration this replaced degraded the same
+     * way, silently — its `cross join "sales_channels" where "system_default"`
+     * produced no rows and inserted no membership — so answering `false` is what
+     * keeps a fresh install and an upgraded one at the same row state in that state
+     * too. Raising instead **aborts the install**, and the hook is not inside a
+     * database transaction.
+     */
+    async bindToDefaultChannel(em, paymentMethodId) {
+        // command-coverage-ignore: install-time seed membership for a row this seam
+        // just created — a system-invariant write with no request and no actor.
+        const defaultChannel = await em.findOne(SalesChannel, { systemDefault: true });
+        if (!defaultChannel)
+            return false;
+        const inserted = await em.execute('insert into "sales_channel_payment_methods" ("sales_channel_id", "payment_method_id") ' +
+            'values (?, ?) on conflict ("sales_channel_id", "payment_method_id") do nothing ' +
+            'returning "payment_method_id"', [defaultChannel.id, paymentMethodId]);
+        return inserted.length > 0;
+    }
+    /**
+     * The hard-uninstall half. Channel memberships go with the row, and so does
+     * every vendor-owned row keyed on it — each gateway's
+     * `*_payment_method_rules` and `*_payment_method_org_disables` declare
+     * `references "payment_methods" ("id") on delete cascade`.
+     */
+    async removeMethodForAdapter(em, code) {
+        // command-coverage-ignore: hard-uninstall removal of an adapter-backed
+        // payment method — no request, no actor and nothing to attribute an audit
+        // entry to; the operator path is `commands/payment-method.commands.ts`.
+        const removed = await em.nativeDelete(PaymentMethod, { code });
+        return removed > 0;
+    }
+}
+/**
+ * The published record, mapped field by field rather than by handing the entity
+ * back (D-168/D-77): a caller reads values off it and cannot persist through it.
+ */
+function recordOf(row) {
+    return {
+        id: row.id,
+        code: row.code,
+        name: row.name,
+        kind: row.kind,
+        adapter: row.adapter,
+        status: row.status,
+        additionalPrice: row.additionalPrice,
+        statusOnPending: row.statusOnPending,
+        statusOnSuccess: row.statusOnSuccess,
+        statusOnFailure: row.statusOnFailure,
+    };
+}
+/**
+ * The runtime half of this module's install surface (feature 134, FR-064).
+ *
+ * A seeding module's `installHook` writes `createPaymentMethodSeeder()` and hands
+ * `ctx.em` to each call. The factory takes no arguments because the `em` belongs
+ * to the call and not to the seeder: one `em`, named at every statement, with no
+ * second source of truth for which transaction the write lands in.
+ */
+export function createPaymentMethodSeeder() {
+    return new PaymentMethodReconciler();
+}
+//# sourceMappingURL=payment-method-reconciler.js.map

package/dist/backend/services/payment-method-reconciler.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"payment-method-reconciler.js","sourceRoot":"","sources":["../../../src/backend/services/payment-method-reconciler.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,YAAY,EAAE,MAAM,kCAAkC,CAAC;AAOhE,OAAO,EAAE,aAAa,EAAE,MAAM,sCAAsC,CAAC;AAErE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsCG;AACH,MAAM,OAAO,uBAAuB;IAClC,KAAK,CAAC,sBAAsB,CAC1B,EAAiB,EACjB,UAAkB,EAClB,QAAmC;QAEnC,+EAA+E;QAC/E,wEAAwE;QACxE,MAAM,QAAQ,GAAG,MAAM,EAAE,CAAC,OAAO,CAAC,aAAa,EAAE,EAAE,IAAI,EAAE,QAAQ,CAAC,IAAI,EAAE,CAAC,CAAC;QAC1E,IAAI,QAAQ,EAAE,CAAC;YACb,iEAAiE;YACjE,mEAAmE;YACnE,IAAI,CAAC,QAAQ,CAAC,OAAO,EAAE,CAAC;gBACtB,QAAQ,CAAC,OAAO,GAAG,UAAU,CAAC;gBAC9B,MAAM,EAAE,CAAC,eAAe,CAAC,QAAQ,CAAC,CAAC;YACrC,CAAC;YACD,OAAO,EAAE,GAAG,EAAE,QAAQ,CAAC,QAAQ,CAAC,EAAE,OAAO,EAAE,KAAK,EAAE,CAAC;QACrD,CAAC;QAED,MAAM,GAAG,GAAG,EAAE,CAAC,MAAM,CAAC,aAAa,EAAE;YACnC,IAAI,EAAE,QAAQ,CAAC,IAAI;YACnB,IAAI,EAAE,QAAQ,CAAC,IAAI;YACnB,IAAI,EAAE,QAAQ,CAAC,IAAI;YACnB,OAAO,EAAE,UAAU;YACnB,MAAM,EAAE,QAAQ,CAAC,MAAM,IAAI,QAAQ;YACnC,eAAe,EAAE,QAAQ,CAAC,eAAe,IAAI,GAAG;YAChD,eAAe,EAAE,QAAQ,CAAC,eAAe,IAAI,KAAK;YAClD,eAAe,EAAE,QAAQ,CAAC,eAAe,IAAI,MAAM;YACnD,iDAAiD;YACjD,0EAA0E;YAC1E,qEAAqE;YACrE,yEAAyE;YACzE,6DAA6D;YAC7D,eAAe,EAAE,QAAQ,CAAC,eAAe,IAAI,SAAS;SACvD,CAAC,CAAC;QACH,MAAM,EAAE,CAAC,eAAe,CAAC,GAAG,CAAC,CAAC;QAC9B,OAAO,EAAE,GAAG,EAAE,QAAQ,CAAC,GAAG,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;IAC/C,CAAC;IAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAkCG;IACH,KAAK,CAAC,oBAAoB,CAAC,EAAiB,EAAE,eAAuB;QACnE,4EAA4E;QAC5E,wEAAwE;QACxE,MAAM,cAAc,GAAG,MAAM,EAAE,CAAC,OAAO,CAAC,YAAY,EAAE,EAAE,aAAa,EAAE,IAAI,EAAE,CAAC,CAAC;QAC/E,IAAI,CAAC,cAAc;YAAE,OAAO,KAAK,CAAC;QAElC,MAAM,QAAQ,GAAG,MAAM,EAAE,CAAC,OAAO,CAC/B,wFAAwF;YACtF,iFAAiF;YACjF,+BAA+B,EACjC,CAAC,cAAc,CAAC,EAAE,EAAE,eAAe,CAAC,CACrC,CAAC;QACF,OAAO,QAAQ,CAAC,MAAM,GAAG,CAAC,CAAC;IAC7B,CAAC;IAED;;;;;OAKG;IACH,KAAK,CAAC,sBAAsB,CAAC,EAAiB,EAAE,IAAY;QAC1D,uEAAuE;QACvE,0EAA0E;QAC1E,wEAAwE;QACxE,MAAM,OAAO,GAAG,MAAM,EAAE,CAAC,YAAY,CAAC,aAAa,EAAE,EAAE,IAAI,EAAE,CAAC,CAAC;QAC/D,OAAO,OAAO,GAAG,CAAC,CAAC;IACrB,CAAC;CACF;AAED;;;GAGG;AACH,SAAS,QAAQ,CAAC,GAAkB;IAClC,OAAO;QACL,EAAE,EAAE,GAAG,CAAC,EAAE;QACV,IAAI,EAAE,GAAG,CAAC,IAAI;QACd,IAAI,EAAE,GAAG,CAAC,IAAI;QACd,IAAI,EAAE,GAAG,CAAC,IAAI;QACd,OAAO,EAAE,GAAG,CAAC,OAAO;QACpB,MAAM,EAAE,GAAG,CAAC,MAAM;QAClB,eAAe,EAAE,GAAG,CAAC,eAAe;QACpC,eAAe,EAAE,GAAG,CAAC,eAAe;QACpC,eAAe,EAAE,GAAG,CAAC,eAAe;QACpC,eAAe,EAAE,GAAG,CAAC,eAAe;KACrC,CAAC;AACJ,CAAC;AAED;;;;;;;GAOG;AACH,MAAM,UAAU,yBAAyB;IACvC,OAAO,IAAI,uBAAuB,EAAE,CAAC;AACvC,CAAC"}

package/dist/backend/services/registry-singleton.d.ts

@@ -0,0 +1,16 @@
+import { PaymentAdapterRegistry } from './payment-adapter-registry.js';
+/**
+ * Process-wide PaymentAdapterRegistry (feature 034).
+ *
+ * The four gateway modules and `payments` import this instance directly and
+ * push their adapters into it from their `ctx.onBoot` hook, so the platform has
+ * exactly one table of adapters however many times it is composed. A module
+ * contributes only adapters it owns, and names itself when it does.
+ *
+ * The presence probe is wired here rather than in the class: this is the one
+ * instance that participates in the platform's lifecycle, and a registry a
+ * test builds for itself should keep answering about the adapters that test
+ * registered (issue #96).
+ */
+export declare const paymentAdapterRegistry: PaymentAdapterRegistry;
+//# sourceMappingURL=registry-singleton.d.ts.map

package/dist/backend/services/registry-singleton.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"registry-singleton.d.ts","sourceRoot":"","sources":["../../../src/backend/services/registry-singleton.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,sBAAsB,EAAE,MAAM,+BAA+B,CAAC;AAEvE;;;;;;;;;;;;GAYG;AACH,eAAO,MAAM,sBAAsB,wBAElC,CAAC"}

package/dist/backend/services/registry-singleton.js

@@ -0,0 +1,17 @@
+import { effectiveState } from '@endora-commerce/platform/kernel';
+import { PaymentAdapterRegistry } from './payment-adapter-registry.js';
+/**
+ * Process-wide PaymentAdapterRegistry (feature 034).
+ *
+ * The four gateway modules and `payments` import this instance directly and
+ * push their adapters into it from their `ctx.onBoot` hook, so the platform has
+ * exactly one table of adapters however many times it is composed. A module
+ * contributes only adapters it owns, and names itself when it does.
+ *
+ * The presence probe is wired here rather than in the class: this is the one
+ * instance that participates in the platform's lifecycle, and a registry a
+ * test builds for itself should keep answering about the adapters that test
+ * registered (issue #96).
+ */
+export const paymentAdapterRegistry = new PaymentAdapterRegistry(undefined, (moduleId) => effectiveState.isPresent(moduleId));
+//# sourceMappingURL=registry-singleton.js.map

package/dist/backend/services/registry-singleton.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"registry-singleton.js","sourceRoot":"","sources":["../../../src/backend/services/registry-singleton.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,cAAc,EAAE,MAAM,kCAAkC,CAAC;AAClE,OAAO,EAAE,sBAAsB,EAAE,MAAM,+BAA+B,CAAC;AAEvE;;;;;;;;;;;;GAYG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAG,IAAI,sBAAsB,CAAC,SAAS,EAAE,CAAC,QAAQ,EAAE,EAAE,CACvF,cAAc,CAAC,SAAS,CAAC,QAAQ,CAAC,CACnC,CAAC"}

package/dist/install/index.d.ts

@@ -0,0 +1,57 @@
+/**
+ * The **install surface** this module publishes: one factory, on a subpath whose
+ * declared meaning is foreign consumption (feature 134, FR-064;
+ * `module-package-layout.md` R11, D-251).
+ *
+ * A module that ships its own payment gateway seeds its `payment_methods` rows
+ * from its `installHook` through `createPaymentMethodSeeder()`, handing `ctx.em`
+ * to every call; the interface it returns is published type-only on this
+ * package's `./ports`. `autopay`, `paypal`, `payu`, `stripe`, `tpay` and the
+ * example deployment's `payment_gateway_fixture` are its six consumers today,
+ * and the fixture is the one that stays once wave 2 extracts the five.
+ *
+ * ## Why this is a subpath of its own rather than a line on `./backend`
+ *
+ * The delivery twin — `packages/modules/delivery_methods/src/install/index.ts` —
+ * carries the argument in full, with the emitted-graph measurement that decided
+ * it. **Wave 2 reuses that decision rather than retaking it**
+ * (`contracts/foreign-write-repair.md` §2, §8 item 2h). In three lines:
+ *
+ *  * **The npm edge coincides with a declared lifecycle dependency rather than
+ *    substituting for one.** All five gateways already declare
+ *    `dependencies: ['…', 'payment_methods', '…']` in their manifests, so the
+ *    lifecycle, the migration order and the operator's switch all know about
+ *    this edge; the npm declaration says the same thing a second way, in the
+ *    only vocabulary a published tarball has. That is what puts this seam
+ *    **inside** R4's reason rather than beside it.
+ *  * **`./backend` is deliberately discriminating and must stay so.**
+ *    `module-package-layout.md` R7: after D-168, *"every reach into
+ *    `<pkg>/backend` really is a wiring reach"*. A factory there would make one
+ *    subpath mean either "this consumer is wiring `payment_methods`", a real
+ *    Principle I violation, or "this consumer seeds its own rows through the
+ *    sanctioned surface" — two findings with opposite remedies behind one name,
+ *    multiplied by five gateways and a fixture.
+ *  * **The import is evaluated at every boot, and it is measured.**
+ *    `manifest-index.generated.ts` imports every module's manifest statically and
+ *    eagerly, in the server, the CLI and every worker — so a consumer's
+ *    `installHook` is *called* at install and its `import` is *loaded* at boot.
+ *    On the emitted artefact, walked the same way wave 1 walked the delivery
+ *    twin: `dist/backend/index.js` pulls **9 emitted files and 7 external
+ *    specifiers**, `@endora-commerce/platform/http` among them, where
+ *    `dist/install/index.js` pulls **3 and 4, with no HTTP layer** — this file,
+ *    the reconciler and the entity. `dist/ports/index.js` pulls **1 and 0**,
+ *    being `export {};`. The delivery twin's install subpath measures 3 and 4 as
+ *    well, which is what says the two seams cost the same.
+ *
+ * ## It is a pure re-export, and that is a rule
+ *
+ * No behaviour is added here and none may be. The install hook is **not** inside
+ * a database transaction — measured in wave 1: a hook that threw half-way left
+ * the first of two seeded rows behind and never wrote the second — so every
+ * behaviour placed on this path is a new partial-write surface. The write stays
+ * in `../backend/services/payment-method-reconciler.ts`, where its tests, its
+ * `command-coverage-ignore` classification and its Constitution XIII reasoning
+ * already live.
+ */
+export { createPaymentMethodSeeder } from '../backend/services/payment-method-reconciler.js';
+//# sourceMappingURL=index.d.ts.map

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

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/install/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH,OAAO,EAAE,yBAAyB,EAAE,MAAM,kDAAkD,CAAC"}

package/dist/install/index.js

@@ -0,0 +1,57 @@
+/**
+ * The **install surface** this module publishes: one factory, on a subpath whose
+ * declared meaning is foreign consumption (feature 134, FR-064;
+ * `module-package-layout.md` R11, D-251).
+ *
+ * A module that ships its own payment gateway seeds its `payment_methods` rows
+ * from its `installHook` through `createPaymentMethodSeeder()`, handing `ctx.em`
+ * to every call; the interface it returns is published type-only on this
+ * package's `./ports`. `autopay`, `paypal`, `payu`, `stripe`, `tpay` and the
+ * example deployment's `payment_gateway_fixture` are its six consumers today,
+ * and the fixture is the one that stays once wave 2 extracts the five.
+ *
+ * ## Why this is a subpath of its own rather than a line on `./backend`
+ *
+ * The delivery twin — `packages/modules/delivery_methods/src/install/index.ts` —
+ * carries the argument in full, with the emitted-graph measurement that decided
+ * it. **Wave 2 reuses that decision rather than retaking it**
+ * (`contracts/foreign-write-repair.md` §2, §8 item 2h). In three lines:
+ *
+ *  * **The npm edge coincides with a declared lifecycle dependency rather than
+ *    substituting for one.** All five gateways already declare
+ *    `dependencies: ['…', 'payment_methods', '…']` in their manifests, so the
+ *    lifecycle, the migration order and the operator's switch all know about
+ *    this edge; the npm declaration says the same thing a second way, in the
+ *    only vocabulary a published tarball has. That is what puts this seam
+ *    **inside** R4's reason rather than beside it.
+ *  * **`./backend` is deliberately discriminating and must stay so.**
+ *    `module-package-layout.md` R7: after D-168, *"every reach into
+ *    `<pkg>/backend` really is a wiring reach"*. A factory there would make one
+ *    subpath mean either "this consumer is wiring `payment_methods`", a real
+ *    Principle I violation, or "this consumer seeds its own rows through the
+ *    sanctioned surface" — two findings with opposite remedies behind one name,
+ *    multiplied by five gateways and a fixture.
+ *  * **The import is evaluated at every boot, and it is measured.**
+ *    `manifest-index.generated.ts` imports every module's manifest statically and
+ *    eagerly, in the server, the CLI and every worker — so a consumer's
+ *    `installHook` is *called* at install and its `import` is *loaded* at boot.
+ *    On the emitted artefact, walked the same way wave 1 walked the delivery
+ *    twin: `dist/backend/index.js` pulls **9 emitted files and 7 external
+ *    specifiers**, `@endora-commerce/platform/http` among them, where
+ *    `dist/install/index.js` pulls **3 and 4, with no HTTP layer** — this file,
+ *    the reconciler and the entity. `dist/ports/index.js` pulls **1 and 0**,
+ *    being `export {};`. The delivery twin's install subpath measures 3 and 4 as
+ *    well, which is what says the two seams cost the same.
+ *
+ * ## It is a pure re-export, and that is a rule
+ *
+ * No behaviour is added here and none may be. The install hook is **not** inside
+ * a database transaction — measured in wave 1: a hook that threw half-way left
+ * the first of two seeded rows behind and never wrote the second — so every
+ * behaviour placed on this path is a new partial-write surface. The write stays
+ * in `../backend/services/payment-method-reconciler.ts`, where its tests, its
+ * `command-coverage-ignore` classification and its Constitution XIII reasoning
+ * already live.
+ */
+export { createPaymentMethodSeeder } from '../backend/services/payment-method-reconciler.js';
+//# sourceMappingURL=index.js.map

package/dist/install/index.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/install/index.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAsDG;AACH,OAAO,EAAE,yBAAyB,EAAE,MAAM,kDAAkD,CAAC"}

package/dist/manifest.d.ts

@@ -0,0 +1,169 @@
+/**
+ * Payment Methods module — manifest backfill (Module Lifecycle, feature 018).
+ *
+ * Predates the lifecycle system; this manifest is the static record
+ * required so the module participates in the registry. No install /
+ * uninstall hook today — the module's schema is owned by earlier
+ * platform-wide migrations.
+ */
+export declare const manifest: {
+    id: string;
+    name: string;
+    version: string;
+    dependencies: string[];
+    description?: string | undefined;
+    acknowledgedDependencies?: {
+        moduleId: string;
+        port: string;
+        reason: string;
+    }[] | undefined;
+    nonBindingDependencies?: {
+        moduleId: string;
+        name: string;
+        kind: "contributes-to" | "degrades-without" | "refuses-without";
+        reason: string;
+        whenAbsent?: string | undefined;
+    }[] | undefined;
+    activation?: {
+        settingCode: string;
+        default: boolean;
+    } | {
+        nonDeactivatable: true;
+        reason: string;
+    } | undefined;
+    settings?: {
+        moduleCode: string;
+        groups: {
+            code: string;
+            name: string;
+            salesChannelCodes?: string[] | undefined;
+            isSystemProtected?: boolean | undefined;
+        }[];
+        settings: {
+            code: string;
+            name: string;
+            valueType: "string" | "number" | "boolean" | "json" | "string_list" | "secret" | "credential_ref";
+            defaultValue: unknown;
+            description?: string | undefined;
+            groupCode?: string | undefined;
+            previousDefaultValues?: unknown[] | undefined;
+            salesChannelCodes?: string[] | undefined;
+            enumOptions?: string[] | undefined;
+            configurationType?: string | undefined;
+            hidden?: boolean | undefined;
+        }[];
+    } | undefined;
+    i18n?: {
+        bundlesDir: string;
+    } | undefined;
+    docs?: false | {
+        dir: string;
+    } | undefined;
+    demo?: false | {
+        summary: string;
+        seed: (context: import("@endora-commerce/contracts").ModuleDemoContext<never>) => Promise<import("@endora-commerce/contracts").DemoSeedResult>;
+        reset: (context: import("@endora-commerce/contracts").ModuleDemoContext<never>) => Promise<import("@endora-commerce/contracts").DemoResetResult>;
+        after?: readonly string[] | undefined;
+        package?: string | undefined;
+    } | undefined;
+    actions?: {
+        id: string;
+        labelKey: string;
+        icon: "Plus" | "Sparkles" | "Settings" | "Search" | "Boxes" | "Layers" | "Menu" | "PlusCircle" | "PlusSquare" | "FilePlus" | "FolderPlus" | "Upload" | "FileUp" | "CloudUpload" | "Download" | "FileDown" | "FileText" | "BookOpen" | "Rss" | "Package" | "Tag" | "ShoppingCart" | "Receipt" | "CreditCard" | "Users" | "UserPlus" | "Inbox" | "ListChecks" | "ClipboardList" | "Image" | "Video" | "LayoutDashboard" | "PanelLeft" | "KeyRound" | "ShieldCheck" | "Edit" | "Archive" | "Box" | "Truck" | "CircleDollarSign" | "Activity" | "LineChart" | "Smartphone" | "Webhook" | "Scale" | "PlugZap" | "PercentDiamond" | "Newspaper" | "Languages" | "Eraser" | "Warehouse" | "TrendingDown" | "Bell" | "PackageOpen" | "Building2" | "Store" | "ClipboardCheck";
+        targetRoute: string;
+        keywords: string[];
+        weight: number;
+        descriptionKey?: string | undefined;
+        requiredPermission?: string | undefined;
+    }[] | undefined;
+    permissions?: {
+        code: string;
+        label: string;
+        module?: string | undefined;
+        description?: string | undefined;
+        requires?: string[] | undefined;
+    }[] | undefined;
+    transactionalEmails?: {
+        code: string;
+        name: string;
+        variables: {
+            key: string;
+            label: string;
+            sampleValue?: string | undefined;
+            description?: string | undefined;
+        }[];
+        description?: string | undefined;
+        group?: string | undefined;
+    }[] | undefined;
+    capabilities?: string[] | undefined;
+    exclusiveCapabilities?: {
+        key: string;
+        errorCode: string;
+    }[] | undefined;
+    errorCodes?: {
+        code: string;
+        tokens?: string[] | undefined;
+    }[] | undefined;
+    blocks?: {
+        name: string;
+        labelKey: string;
+        category: string;
+        contexts: ("invoice" | "email" | "cms" | "newsletter")[];
+        fields: Record<string, {
+            type: "number" | "object" | "array" | "uuid" | "text" | "textarea" | "select" | "radio" | "external" | "richtext";
+            label?: string | undefined;
+            required?: boolean | undefined;
+            options?: {
+                label: string;
+                value: string | number;
+            }[] | undefined;
+            refKind?: string | undefined;
+        }>;
+        descriptionKey?: string | undefined;
+        defaultProps?: Record<string, unknown> | undefined;
+        responsiveFields?: string[] | undefined;
+        previewIcon?: string | undefined;
+        weight?: number | undefined;
+    }[] | undefined;
+    blockCategories?: {
+        key: string;
+        titleKey: string;
+        contexts: ("invoice" | "email" | "cms" | "newsletter")[];
+        weight?: number | undefined;
+        visible?: boolean | undefined;
+    }[] | undefined;
+    env?: {
+        name: string;
+        describes: {
+            en: string;
+            pl: string;
+        };
+        requirement: {
+            kind: "required";
+        } | {
+            kind: "requiredWhen";
+            input: string;
+            equals: string;
+        } | {
+            kind: "optional";
+            without: {
+                en: string;
+                pl: string;
+            };
+        };
+        secret: boolean;
+        generable: boolean;
+        owner: {
+            kind: "platform";
+        } | {
+            kind: "application";
+            application: "admin" | "backend" | "storefront";
+        } | {
+            kind: "module";
+            moduleId: string;
+        };
+        consumers: ("admin" | "backend" | "storefront")[];
+        addressOf: "admin" | "backend" | "storefront" | null;
+    }[] | undefined;
+};
+//# sourceMappingURL=manifest.d.ts.map

package/dist/manifest.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"manifest.d.ts","sourceRoot":"","sources":["../src/manifest.ts"],"names":[],"mappings":"AAuBA;;;;;;;GAOG;AACH,eAAO,MAAM,QAAQ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAsHnB,CAAC"}

package/dist/manifest.js

@@ -0,0 +1,145 @@
+import { defineModuleManifest } from '@endora-commerce/contracts';
+/**
+ * The demo data this module owns (feature 113, T220 — contract §1.3).
+ *
+ * A typed `const` rather than an inline object literal: declared inline the
+ * parameter infers from the schema and is `never`, so the author loses
+ * `context.ctx: ModuleContext`.
+ *
+ * Both bodies are reached by a **relative `await import()`** (§1.4), in
+ * `cliCommands.run`'s shape and for `cliCommands`' reason: a manifest is loaded
+ * by every process that composes the platform and by the check scripts that
+ * import the generated index, so a demo body imported at the top of this file
+ * would be a service graph pulled into all of them. It needs no `exports`
+ * subpath and no `files` entry (§1.5).
+ */
+const demo = {
+    summary: 'A bank transfer and a credit-limit method, so the demo shop can be paid for.',
+    seed: async (context) => (await import('./backend/demo/seed.js')).seedDemo(context),
+    reset: async (context) => (await import('./backend/demo/reset.js')).resetDemo(context),
+};
+/**
+ * Payment Methods module — manifest backfill (Module Lifecycle, feature 018).
+ *
+ * Predates the lifecycle system; this manifest is the static record
+ * required so the module participates in the registry. No install /
+ * uninstall hook today — the module's schema is owned by earlier
+ * platform-wide migrations.
+ */
+export const manifest = defineModuleManifest({
+    id: 'payment_methods',
+    name: 'Payment Methods',
+    description: 'Payment method definitions and per-channel availability.',
+    version: '1.0.0',
+    // `auth` owns the `requireAdmin` port the admin routes are gated by; the
+    // edge became real with the conversion (feature 072, T097).
+    // `organizations` since feature 072 (T138): the public method list is
+    // filtered by the caller's per-Organization allow-list, which this module
+    // reads through `organizationRestrictionPort`. The edge existed before as a
+    // root-supplied closure and was therefore invisible to the manifest.
+    dependencies: ['auth', 'organizations'],
+    /**
+     * D-44 — a real port edge deliberately kept out of `dependencies`, because
+     * the owner disappearing is a state this module handles.
+     */
+    nonBindingDependencies: [
+        {
+            moduleId: 'payments',
+            name: 'paymentReadPort',
+            kind: 'degrades-without',
+            whenAbsent: 'a payment method cannot be deleted, only set inactive',
+            reason: 'The delete-guard (feature 034, FR-003) asks how many payment attempts still point at ' +
+                'the method an operator is deleting. Until feature 075 it asked in raw SQL against ' +
+                '`payments`\' own table, which named no import specifier and so crossed the boundary ' +
+                'invisibly (D-87). `degrades-without` rather than `dependencies`: `payments` declares ' +
+                'this module, so declaring it back would close a cycle, and acknowledging the edge ' +
+                'would keep the bind and make `payments.enabled` unusable in every shop that takes ' +
+                'money. `backend.ts` asks `effectiveState.isPresent` before resolving the port, and ' +
+                'the Command refuses the delete with a 409 naming the reason rather than deleting a ' +
+                'method whose references nobody could count.',
+        },
+    ],
+    /**
+     * The module's own authority (2026-08-28).
+     *
+     * All six admin routes used to enforce `catalog:read` / `catalog:write`, so
+     * whoever could edit a product could read the payment-method configuration
+     * and rewrite it — which methods a checkout offers, their surcharge, and
+     * which order status each payment outcome moves an order to. Both codes were
+     * real, declared and enforced, so the permission inventory's two directions
+     * were clean over the site and `check:action-route-permissions` found the
+     * palette action in perfect agreement with its target: they both said
+     * `catalog:read`.
+     *
+     * A pair and no third code, spelled `<module id>:<read|write>` like the five
+     * gateway modules, `returns` and `invoices`. A prefix that is not its owner's
+     * id is the mistake `PERMISSION_CATALOGUE` comments on twice
+     * (`integrations:manage`, `audit_log:read`), both frozen because they are
+     * persisted in role rows; getting it right on a code that does not exist yet
+     * is free. The codes stay here rather than in `PERMISSION_CATALOGUE`, which
+     * is for codes spanning modules — this module owns these outright.
+     *
+     * No data migration: see
+     * `test/contract/payment_methods/permission-authority.test.ts`.
+     */
+    permissions: [
+        { code: 'payment_methods:read', label: 'View payment methods' },
+        { code: 'payment_methods:write', label: 'Configure payment methods' },
+    ],
+    settings: {
+        moduleCode: 'payment_methods',
+        groups: [{ code: 'payment_methods', name: 'Payment methods' }],
+        settings: [
+            {
+                // Feature 073 — the operator's activation control. Platform-wide.
+                code: 'payment_methods.enabled',
+                name: 'Payment methods enabled',
+                // Same missing consequence as its delivery twin: with no method to
+                // pick, order placement answers "Payment method is not active" and no
+                // order can be completed at all. Switching this off is a different act
+                // from switching `payments` off — that one withdraws the adapters the
+                // methods are configured against — and both end the same way for a
+                // buyer, so both descriptions have to say so.
+                description: 'Switches the payment-method catalog on or off: the admin screens that define methods and their per-channel availability, and the public list a checkout picks from. With no method to pick, checkout cannot be completed and the shop stops taking orders. Nothing is dropped — every method, its channel bindings, its per-organization allow-list and the payments already taken against it stay in the database, and the catalog returns exactly as configured when you switch it back on.',
+                groupCode: 'payment_methods',
+                valueType: 'boolean',
+                defaultValue: true,
+            },
+        ],
+    },
+    // Feature 073, Amendment A1 (Constitution XVII) — deactivatable, because the
+    // reason it used to give does not hold. "The platform cannot take an order"
+    // rests on an edge that is not in the graph: `orders` declares `addresses`,
+    // `api_keys`, `carts`, `credit_limits`, `organizations`, `promotions`,
+    // `settings` and `transactional_emails`, and neither this module nor
+    // `delivery_methods`. The dependents that do declare it — `payments`,
+    // `quick_order`, and the four provider modules — fail closed when it is off,
+    // which is the intended meaning of switching a payment catalog off.
+    demo,
+    activation: { settingCode: 'payment_methods.enabled', default: true },
+    i18n: { bundlesDir: 'i18n' },
+    docs: { dir: 'docs' },
+    // Feature 076 (D-83 item 8) — a standing Principle XVI gap, closed here
+    // because this change is what starts sending operators to `/payment-methods`
+    // from four gateway screens. The module owned a real admin route and declared
+    // no palette action at all.
+    //
+    // `targetRoute` is the landing route **plain**: the action route regex rejects
+    // a query string, so the gateway screens' `?highlight=<code>` deep link is an
+    // in-page anchor rather than a second action. `payment_methods:read` is what
+    // gates `GET /api/v1/admin/payment-methods`, so the palette never advertises
+    // a 403.
+    actions: [
+        {
+            id: 'open-payment-methods',
+            labelKey: 'actions.openPaymentMethods.label',
+            descriptionKey: 'actions.openPaymentMethods.description',
+            icon: 'CreditCard',
+            targetRoute: '/payment-methods',
+            requiredPermission: 'payment_methods:read',
+            keywords: ['payment', 'method', 'availability', 'checkout', 'płatność', 'metoda'],
+            weight: 150,
+        },
+    ],
+});
+//# sourceMappingURL=manifest.js.map