@pellux/goodvibes-daemon 1.28.20 → 1.28.21

package/src/runtime/browser-checkout-seam-holder.ts

@@ -0,0 +1,55 @@
+/**
+ * browser-checkout-seam-holder.ts, holding a seam that arrives after its
+ * first reader is constructed.
+ *
+ * ── Why a holder, and not a constructor argument ──────────────────────────
+ *
+ * The SDK hands out a `BrowserCheckoutSeam` through `onBrowserCheckout`, a
+ * callback `composeDaemonBrowser` invokes once, synchronously, at the moment
+ * IT composes the browser. In this daemon that composition runs inside
+ * `attachWsOnlyGatewayVerbHandlers` (services.ts), which is called AFTER
+ * `createDaemonHandlerComposition` builds the payments handlers, because the
+ * ws-only verb groups need managers (disposal scope, workspace checkpoint
+ * manager, ...) that do not exist yet at the point payments is composed.
+ * Reordering the two would ripple across every other verb group that call
+ * builds, for one capability's benefit.
+ *
+ * So the payments composition cannot receive the seam as a constructor
+ * argument; it receives a GETTER, closed over this holder, and reads it at
+ * CALL time rather than at registration time. By the time any real invocation
+ * reaches `payments.checkout.begin`, the daemon has finished booting and
+ * `onBrowserCheckout` has already fired (or the composition is one where the
+ * browser was never buildable at all, `composeDaemonBrowser` returned null,
+ * homeDirectory absent, and the getter honestly keeps returning undefined
+ * forever, which the checkout handler already refuses on cleanly).
+ */
+import type { BrowserCheckoutSeam } from '@pellux/goodvibes-sdk/platform/control-plane';
+
+export interface BrowserCheckoutSeamHolder {
+  readonly get: () => BrowserCheckoutSeam | undefined;
+  readonly set: (seam: BrowserCheckoutSeam) => void;
+  /**
+   * Forgets the held seam. Call this from the browser's own disposal path
+   * (services.ts, registered on the SAME disposal scope the browser sessions
+   * teardown runs on), so a daemon that has started shutting its browser down
+   * cannot hand a checkout call a seam whose `driverFor`/`cardFieldGuard` point
+   * at an engine that is being (or has been) torn down. After this, `get()`
+   * returns `undefined` again, and `payments.checkout.begin`/`.fillCard` fall
+   * back to their ordinary "checkout is not available right now" 409 refusal,
+   * see checkout-handlers.ts, rather than reaching into a disposed engine.
+   */
+  readonly clear: () => void;
+}
+
+export function createBrowserCheckoutSeamHolder(): BrowserCheckoutSeamHolder {
+  let seam: BrowserCheckoutSeam | undefined;
+  return {
+    get: () => seam,
+    set: (received) => {
+      seam = received;
+    },
+    clear: () => {
+      seam = undefined;
+    },
+  };
+}

package/src/runtime/daemon-handler-composition.ts

@@ -20,6 +20,8 @@ import type { ConfigManager } from '@pellux/goodvibes-sdk/platform/config';
 import type { ClusterCoordinator } from '@pellux/goodvibes-sdk/platform/cluster';
 import type { GatewayMethodCatalog } from '@pellux/goodvibes-sdk/platform/control-plane';
 import type { SecretsManager } from '@pellux/goodvibes-sdk/platform/config';
+import type { ChannelDeliveryRouter } from '@pellux/goodvibes-sdk/platform/channels';
+import type { ProviderRegistry } from '@pellux/goodvibes-sdk/platform/providers';
 import { registerDaemonHandlers, type DaemonHandlerSurfaces } from '../daemon/handlers/index.ts';
 import type { HandlerContext, HandlerLogger } from '../daemon/handlers/context.ts';
 import { createDaemonCredentialStore } from '../daemon/handlers/credentials.ts';
@@ -31,6 +33,7 @@ import { registerRemoteSurface } from '../daemon/handlers/remote/index.ts';
 import { createPaymentsServices } from './payments-composition.ts';
 import { inboxPollerGate } from './cluster-composition.ts';
 import type { ShellPathService } from '@/runtime/index.ts';
+import type { BrowserCheckoutSeamHolder } from './browser-checkout-seam-holder.ts';
 
 export interface DaemonHandlerCompositionOptions {
   readonly gatewayMethods: GatewayMethodCatalog;
@@ -46,6 +49,15 @@ export interface DaemonHandlerCompositionOptions {
    * composition root; the poller is never started outside it.
    */
   readonly clusterCoordinator: ClusterCoordinator;
+  /**
+   * Where `payments.checkout.*` reads the browser-checkout seam, filled later
+   * by services.ts's own `onBrowserCheckout`. See
+   * runtime/browser-checkout-seam-holder.ts and payments-composition.ts's
+   * header for why this has to be a getter rather than the seam itself.
+   */
+  readonly checkoutSeam: BrowserCheckoutSeamHolder['get'];
+  readonly channelDeliveryRouter: Pick<ChannelDeliveryRouter, 'deliver'>;
+  readonly providerRegistry: Pick<ProviderRegistry, 'getCurrentModel' | 'getForModel'>;
 }
 
 export function createDaemonHandlerComposition(
@@ -77,8 +89,9 @@ export function createDaemonHandlerComposition(
     registerDrafts: (ctx) => registerDraftMethods(ctx),
     // The payment stores need a path resolver and a daemon-scoped secret writer,
     // neither of which is on HandlerContext, so they are built here and the
-    // provider only carries the teardown. See payments-composition.ts for which
-    // verbs this attaches and which two it deliberately leaves refusing.
+    // provider only carries the teardown. See payments-composition.ts for the
+    // full checkout composition (address store, notifier, merchant judge,
+    // browser-checkout seam).
     registerPayments: () => createPaymentsServices({
       gatewayMethods: options.gatewayMethods,
       configManager: options.configManager,
@@ -99,17 +112,21 @@ export function createDaemonHandlerComposition(
       // (inboxPollerGate). It is the right answer once there is something to
       // elect over, and today there is not: ClusterConsumerGate.start() is
       // specified to not resolve until consumption has actually begun, and this
-      // composition has no payments consumer to start, checkout is unattached.
-      // Registering a gate whose start() does nothing would put a fake consumer
-      // in the election and in `cluster status`.
+      // composition has no payments consumer to start it. Checkout is now
+      // wired (payments.checkout.begin/.fillCard), but registering a gate whose
+      // start() does nothing would STILL put a fake consumer in the election and
+      // in `cluster status`; a real election is a separate piece of work, left
+      // for a later pass, not something wiring the checkout pair itself needed.
       //
-      // So the honest reading of the topology: clustering off means this is the
-      // only node, and it is trivially the one that would spend; clustering on
-      // means no payments election has been held and this node cannot claim to
-      // have won it. False on every node is also the safe direction, checkPaymentGates
-      // refuses on false. Wiring payments.checkout.* is what should replace this
-      // with a real gate and holdsSurface().
+      // So the honest reading of the topology stays what it was: clustering off
+      // means this is the only node, and it is trivially the one that would
+      // spend; clustering on means no payments election has been held and this
+      // node cannot claim to have won it. False on every node is also the safe
+      // direction, checkPaymentGates refuses on false.
       isPaymentsLeader: () => !options.clusterCoordinator.enabled,
+      checkoutSeam: options.checkoutSeam,
+      channelDeliveryRouter: options.channelDeliveryRouter,
+      providerRegistry: options.providerRegistry,
     }).unregister,
     registerRemote: (ctx) => registerRemoteSurface(ctx, { manager: options.distributedRuntime }),
   });

package/src/runtime/payments-composition.ts

@@ -31,44 +31,67 @@
  *     time" for a card;
  *   - the purchase audit ledger beside the card file.
  *
- * ── The budget ledger is in-process, and that is a statement ──────────────
+ * ── The budget ledger is durable ──────────────────────────────────────────
  *
- * `BudgetLedger` is constructed empty here and never persisted. That is correct
- * ONLY while checkout is unattached: the sole writer of a spend record is the
- * checkout flow, so there is nothing to persist, and a state file nothing writes
- * would be decoration. It stops being correct the moment `payments.checkout.begin`
- * is wired, and the failure would be silent and expensive, a daemon restarted at
- * noon would hand back a daily budget it had already spent. Making this ledger
- * durable is part of wiring checkout.
+ * `BudgetLedger` used to be constructed empty here and never persisted, correct
+ * only while checkout stayed unattached (the sole writer of a spend record was
+ * the checkout flow, so there was nothing to persist). Now that checkout is
+ * wired below, `DurableBudgetLedger`
+ * (daemon/handlers/payments/budget-store.ts) is used instead: it loads its
+ * state from `payments-budget.json` beside the card and purchase files at
+ * construction and writes back after every reservation, commit and release, so
+ * a daemon restarted mid-day does not hand back a budget it already spent.
  *
- * ── What is NOT composed ──────────────────────────────────────────────────
+ * ── The checkout pair, over the sdk 2.0.19 browser-checkout seam ──────────
  *
- * `payments.checkout.begin` and `payments.checkout.fillCard` stay unattached and
- * keep answering 501. They need a `CheckoutPageDriver` over an open browser
- * page, and this composition has no way to obtain one: the SDK builds its
- * browser engine inside `registerGatewayVerbGroups`
- * (control-plane/routes/browser-composition.ts), hands back only the
- * `BrowserGatewayService` slice, which exposes no page handle and no
- * `fillSecret`, and constructs it with no `cardFieldGuard`, which its own
- * secret-fill path refuses without. There is also no adapter anywhere from a
- * browser session to a `CheckoutPageDriver`. Writing one here would put the
- * card-into-page seam in this repository, and card-material.ts is explicit that
- * exactly one module in the platform may produce card material. So the two verbs
- * refuse honestly instead.
+ * `payments.checkout.begin`/`.fillCard` need a `CardMaterialRedactor` bound to
+ * the SAME browser engine the `browser.*` verbs drive, and this daemon does not
+ * build that engine, `composeDaemonBrowser` does (control-plane/routes/
+ * browser-composition.ts), inside `registerGatewayVerbGroups`, which THIS
+ * composition runs before (see runtime/services.ts). `checkoutSeam` is
+ * therefore a GETTER, not a value: services.ts passes `onBrowserCheckout` to
+ * `attachWsOnlyGatewayVerbHandlers` wired to fill the SAME holder this getter
+ * reads (runtime/browser-checkout-seam-holder.ts), and `register.ts`'s checkout
+ * handlers read it fresh on every call rather than once at composition time.
+ *
+ * The rest of `PaymentsGatewayServiceImpl`'s dependencies this composition owns
+ * outright: `configBackedAddressStore` reads the shipping/billing addresses the
+ * owner profile already writes into `payments.*Address.*` config keys (see
+ * that module's header for the exact defect this closes), and
+ * `channelBackedPaymentNotifier`/`createProviderBackedMerchantJudgeModel` adapt
+ * this daemon's channel router and provider registry to the ports the SDK
+ * declares. The untrusted-content ledger is the SAME process-wide singleton the
+ * browser composition binds its engine to (`getProcessUntrustedContentLedger`),
+ * never a private one, for the reason browser-composition.ts's header gives:
+ * a private ledger would make cross-capability derivation invisible.
+ *
+ * `channelBackedPaymentNotifier`'s own header names the one piece deliberately
+ * left for a later pass: no live inbound-reply correlation, so every purchase
+ * settles on the windows' own silence rules rather than an early answer. That
+ * is a scoped, disclosed gap, not a silent one.
  */
 import { controlPlaneStorePath } from '@pellux/goodvibes-sdk/platform/control-plane';
 import type { GatewayMethodCatalog } from '@pellux/goodvibes-sdk/platform/control-plane';
-import { BudgetLedger, readCvvHandling } from '@pellux/goodvibes-sdk/platform/payments';
-import type { PaymentsConfigReader } from '@pellux/goodvibes-sdk/platform/payments';
+import { createModelMerchantJudge, readCvvHandling } from '@pellux/goodvibes-sdk/platform/payments';
+import type { BudgetLedger, PaymentsConfigReader } from '@pellux/goodvibes-sdk/platform/payments';
+import { getProcessUntrustedContentLedger } from '@pellux/goodvibes-sdk/platform/security';
 import type { ConfigManager, SecretsManager } from '@pellux/goodvibes-sdk/platform/config';
+import type { ChannelDeliveryRouter } from '@pellux/goodvibes-sdk/platform/channels';
+import type { ProviderRegistry } from '@pellux/goodvibes-sdk/platform/providers';
 import type { ShellPathService } from '@/runtime/index.ts';
 import {
   DaemonCardStore,
   DaemonPurchaseLedger,
+  DurableBudgetLedger,
+  channelBackedPaymentNotifier,
+  configBackedAddressStore,
+  createProviderBackedMerchantJudgeModel,
   registerPaymentsMethods,
+  type CheckoutComposition,
   type PaymentsSecretStore,
 } from '../daemon/handlers/payments/index.ts';
 import { GOODVIBES_DAEMON_SURFACE_ROOT } from '../config/surface.ts';
+import type { BrowserCheckoutSeamHolder } from './browser-checkout-seam-holder.ts';
 
 export interface PaymentsCompositionOptions {
   readonly configManager: ConfigManager;
@@ -83,6 +106,12 @@ export interface PaymentsCompositionOptions {
    * gates.ts: on a clustered install the wrong answer is a double-spend.
    */
   readonly isPaymentsLeader: () => boolean;
+  /** Where the checkout pair reads the browser-checkout seam; see this file's header. */
+  readonly checkoutSeam: BrowserCheckoutSeamHolder['get'];
+  /** Delivers a purchase notice; the SAME router every other channel send in this daemon uses. */
+  readonly channelDeliveryRouter: Pick<ChannelDeliveryRouter, 'deliver'>;
+  /** Judges an unfamiliar merchant's recourse through the currently configured model. */
+  readonly providerRegistry: Pick<ProviderRegistry, 'getCurrentModel' | 'getForModel'>;
 }
 
 export interface PaymentsServices {
@@ -118,8 +147,13 @@ function livePaymentsConfig(configManager: ConfigManager): PaymentsConfigReader
 /**
  * Build the payment stores and bind the answerable verbs to them.
  *
- * Constructing this touches no disk: both stores read lazily and write only when
- * a verb asks them to, so composing a runtime in a test creates no files.
+ * The card and purchase stores read lazily and write only when a verb asks
+ * them to, so composing either by itself creates no file activity. The budget
+ * ledger is different: `DurableBudgetLedger`'s constructor reads
+ * `payments-budget.json` synchronously to load today's pools
+ * (daemon/handlers/payments/budget-store.ts), so constructing the result of
+ * THIS function does touch disk, once, for that one file, before any verb is
+ * ever called.
  */
 export function createPaymentsServices(options: PaymentsCompositionOptions): PaymentsServices {
   const config = livePaymentsConfig(options.configManager);
@@ -131,13 +165,23 @@ export function createPaymentsServices(options: PaymentsCompositionOptions): Pay
   const purchases = new DaemonPurchaseLedger({
     filePath: controlPlaneStorePath(options.shellPaths, GOODVIBES_DAEMON_SURFACE_ROOT, 'payments-purchases.json'),
   });
-  const budget = new BudgetLedger();
+  const budget = new DurableBudgetLedger(
+    controlPlaneStorePath(options.shellPaths, GOODVIBES_DAEMON_SURFACE_ROOT, 'payments-budget.json'),
+  );
+  const checkout: CheckoutComposition = {
+    seam: options.checkoutSeam,
+    addresses: configBackedAddressStore(config),
+    notifier: channelBackedPaymentNotifier(config, options.channelDeliveryRouter),
+    merchantJudge: createModelMerchantJudge(createProviderBackedMerchantJudgeModel(options.providerRegistry)),
+    untrusted: getProcessUntrustedContentLedger(),
+  };
   const unregister = registerPaymentsMethods(options.gatewayMethods, {
     cards,
     purchases,
     budget,
     config,
     isPaymentsLeader: options.isPaymentsLeader,
+    checkout,
   });
   return { cards, purchases, budget, unregister };
 }

package/src/runtime/services.ts

@@ -56,6 +56,7 @@ import { createTriggerServices } from './trigger-services.ts';
 import { createWorkstreamServices } from '@pellux/goodvibes-sdk/platform/orchestration';
 import { wireFleetNeedsInputPush } from './fleet-needs-input-push.ts';
 import { createDaemonHandlerComposition } from './daemon-handler-composition.ts';
+import { createBrowserCheckoutSeamHolder } from './browser-checkout-seam-holder.ts';
 import { createDevicePostureServices } from './device-posture-composition.ts';
 // Re-exported so the daemon entrypoint reaches the housekeeping sweep through
 // the same module it already imports the runtime graph from. `installDevicePosture`
@@ -387,9 +388,17 @@ export function createRuntimeServices(options: RuntimeServicesOptions): RuntimeS
   const { clusterGroup, clusterCoordinator } = createClusterServices({
     configManager, shellPaths, secretsManager,
   });
+  // ONE router, not two (a second built from the same four arguments would
+  // differ from the one replies leave through). Moved up from its original
+  // spot near the ws-only verb options (still consumed there): the payments
+  // composition below needs it too.
+  const channelDeliveryRouter = deliveryManager.getDeliveryRouter();
   // Daemon handler surfaces (see daemon-handler-composition.ts); the inbox
   // poller registers itself with the coordinator rather than starting eagerly,
   // and the payments family stops being a cataloged 501 facade there.
+  // browserCheckoutSeam fills once `onBrowserCheckout` fires below, after this
+  // composition; read lazily, per call. See browser-checkout-seam-holder.ts.
+  const browserCheckoutSeam = createBrowserCheckoutSeamHolder();
   const daemonHandlers = createDaemonHandlerComposition({
     gatewayMethods,
     secretsManager,
@@ -399,6 +408,7 @@ export function createRuntimeServices(options: RuntimeServicesOptions): RuntimeS
     shellPaths,
     distributedRuntime,
     clusterCoordinator,
+    checkoutSeam: browserCheckoutSeam.get, channelDeliveryRouter, providerRegistry,
   });
 
   // Remote runners and the sandboxes tool calls are confined to; see
@@ -426,12 +436,7 @@ export function createRuntimeServices(options: RuntimeServicesOptions): RuntimeS
   const policyRuntimeState = new PolicyRuntimeState();
   const fileCache = new FileStateCache();
   const projectIndex = new ProjectIndex(workingDirectory);
-  // ONE router, not two. This was a second ChannelDeliveryRouter built from the
-  // same four arguments AutomationDeliveryManager builds its own from, so the
-  // router the gateway verbs held and the router replies actually leave through
-  // were different objects, and a delivery strategy registered on one was
-  // invisible to the other. The manager's is the one that replies; it is the one.
-  const channelDeliveryRouter = deliveryManager.getDeliveryRouter();
+  // channelDeliveryRouter now built earlier, near clusterCoordinator above.
   const processManager = new ProcessManager();
   // The phase/work-item orchestration engine, constructed before the process
   // registry so its fleet nodes (workstream/phase/work-item) can be folded in
@@ -533,6 +538,7 @@ export function createRuntimeServices(options: RuntimeServicesOptions): RuntimeS
     // is what let these stores write to the unscoped orphan directory.
     surfaceRoot: GOODVIBES_DAEMON_SURFACE_ROOT,
     homeDirectory, emailServiceDeps, describeEmailConfigProblem, processRegistry,
+    onBrowserCheckout: browserCheckoutSeam.set,
     // The registration-gated surface, not the raw manager: an explicit create in
     // an unregistered workspace refuses with something actionable.
     workspaceCheckpointManager: checkpointing.gatewayManager,
@@ -564,6 +570,7 @@ export function createRuntimeServices(options: RuntimeServicesOptions): RuntimeS
     disposal: disposalScope.registry,
     ...wireFleetNeedsInputPush({ registry: processRegistry, runtimeBus: options.runtimeBus, sessionBroker }),
   });
+  disposalScope.registry.add('browser checkout seam holder', () => browserCheckoutSeam.clear()); // newer than 'browser sessions' above, so runs first
   // A loopback fetch that isn't allow-listed asks once through the approval
   // broker; "allow for this project" persists and later fetches never ask. Built
   // once and shared with the tool registry so both ask alike.