@hogsend/core 0.13.2 → 0.16.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hogsend/core",
-  "version": "0.13.2",
+  "version": "0.16.0",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -32,7 +32,7 @@
     "drizzle-orm": "^0.45.2",
     "iana-db-timezones": "^0.3.0",
     "zod": "^4.4.3",
-    "@hogsend/db": "^0.13.2"
+    "@hogsend/db": "^0.16.0"
   },
   "devDependencies": {
     "@types/node": "latest",

package/src/types/journey-context.ts

@@ -107,11 +107,29 @@ export interface WaitForEventOptions {
   timeout: DurationObject;
   /** Optional observability label written to `currentNodeId` while waiting. */
   label?: string;
+  /**
+   * Look BACK this far before waiting forward. The wait is normally
+   * forward-looking (only events pushed after it is established match), which
+   * leaves a gap: an event landing between two waits — or between a send and
+   * its wait — is never seen. With `lookback`, recent `user_events` matching
+   * (user, event) are checked first; a hit resolves immediately with
+   * `{ timedOut: false, properties }`. Keep the window tight (just the gap it
+   * covers, e.g. `hours(1)` between back-to-back waits) so a stale answer
+   * isn't mistaken for a fresh one.
+   */
+  lookback?: DurationObject;
 }
 
 export interface WaitForEventResult {
   /** `true` when the `timeout` elapsed first; `false` when the event fired. */
   timedOut: boolean;
+  /**
+   * The matched event's properties, present (best-effort) when the event
+   * branch fired and the pushed payload carried them. Scalars only — that is
+   * all the ingest pipeline puts on the wire. Branch on these to react to the
+   * answer (e.g. an in-email NPS score) without a separate history lookup.
+   */
+  properties?: Record<string, string | number | boolean | null>;
 }
 
 export interface JourneyContext {

package/src/types/journey.ts

@@ -1,6 +1,44 @@
+import type { CriteriaBuilder } from "../conditions/builder.js";
 import type { DurationObject } from "../duration.js";
 import type { PropertyCondition } from "./conditions.js";
 
+/**
+ * The builder surface available to a journey `where` function — property
+ * terminals only. Trigger/exit conditions evaluate against the TRIGGERING
+ * event's properties; counts, windows, and engagement belong in bucket
+ * criteria or `ctx.history`, not here.
+ */
+export type JourneyWhereBuilder = Pick<CriteriaBuilder, "prop">;
+
+/**
+ * Authoring form of `trigger.where` / `exitOn[].where`: the stored data form
+ * (`PropertyCondition[]`), or a builder function resolved ONCE at
+ * `defineJourney` time into the byte-identical POJOs —
+ * `where: (b) => b.prop("score").lte(6)`. The function never executes
+ * per-user, so conditions stay introspectable data everywhere downstream
+ * (registry, admin routes, Studio).
+ */
+export type JourneyWhere =
+  | PropertyCondition[]
+  | ((b: JourneyWhereBuilder) => PropertyCondition | PropertyCondition[]);
+
+/**
+ * What `defineJourney` ACCEPTS. The stored {@link JourneyMeta} (registry,
+ * schema, HTTP) keeps plain `PropertyCondition[]` — only the authoring
+ * surface widens.
+ */
+export interface JourneyMetaInput
+  extends Omit<JourneyMeta, "trigger" | "exitOn"> {
+  trigger: {
+    event: string;
+    where?: JourneyWhere;
+  };
+  exitOn?: Array<{
+    event: string;
+    where?: JourneyWhere;
+  }>;
+}
+
 export interface JourneyMeta {
   id: string;
   name: string;