deepline 0.1.186 → 0.1.187

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/dist/index.d.mts CHANGED
@@ -866,9 +866,98 @@ interface PlayCheckResult {
866
866
  warnings?: string[];
867
867
  staticPipeline?: Record<string, unknown> | null;
868
868
  toolGetterHints?: PlayCheckToolGetterHint[];
869
+ /**
870
+ * Recognized trigger bindings parsed from the play source (`sqlListeners` /
871
+ * cron / webhook). Present only when the play declares at least one trigger,
872
+ * so an author can confirm the binding was recognized rather than silently
873
+ * dropped. Field names mirror the `definePlay` binding contract.
874
+ */
875
+ triggers?: PlayCheckTriggersSummary | null;
876
+ /**
877
+ * Structured, machine-actionable issues surfaced by the check. An ADDITIVE
878
+ * channel alongside `errors[]`: every `error`-severity issue is also present
879
+ * in `errors[]` (so string-level tooling keeps working), while an agent can
880
+ * read `code` / `validOptions` / `docsHint` to self-correct. `warning`
881
+ * severity issues do NOT make the check invalid.
882
+ */
883
+ issues?: PlayCheckIssue[];
884
+ /**
885
+ * Affirmative echo of what Deepline recognized — triggers, tools,
886
+ * datasets/columns, inputs, outputs — so a valid check reflects the parsed
887
+ * shape rather than a bare "ok".
888
+ */
889
+ recognized?: PlayCheckRecognizedSummary;
890
+ /**
891
+ * Human one-liner over {@link PlayCheckResult.recognized}, e.g.
892
+ * `1 trigger · 2 tools · 1 dataset · 14 columns`.
893
+ */
894
+ summary?: string;
869
895
  artifactHash?: string | null;
870
896
  graphHash?: string | null;
871
897
  }
898
+ /** Severity of a {@link PlayCheckIssue}. `error` fails the check; `warning` does not. */
899
+ type PlayCheckIssueSeverity = 'error' | 'warning';
900
+ /**
901
+ * One structured, machine-actionable issue surfaced by `deepline plays check`.
902
+ * Mirrors the server-side `PlayCheckIssue` contract. `code` is a stable machine
903
+ * code from a closed server-side set; `validOptions` enumerates the valid values
904
+ * (tool ids / stream keys / columns / operators) so an agent self-corrects by
905
+ * reading the structure instead of brute-forcing the compiler.
906
+ */
907
+ interface PlayCheckIssue {
908
+ code: string;
909
+ severity: PlayCheckIssueSeverity;
910
+ message: string;
911
+ path?: string;
912
+ hint?: string;
913
+ validOptions?: string[];
914
+ docsHint?: string;
915
+ }
916
+ /**
917
+ * Affirmative "here's what Deepline recognized" echo returned alongside a
918
+ * check's issues. Field names reuse the public play binding contract.
919
+ */
920
+ interface PlayCheckRecognizedSummary {
921
+ triggers?: PlayCheckTriggersSummary;
922
+ tools?: string[];
923
+ datasets?: {
924
+ name: string;
925
+ columns?: string[];
926
+ }[];
927
+ inputs?: string[];
928
+ outputs?: string[];
929
+ }
930
+ /**
931
+ * One recognized SQL-listener trigger echoed back by {@link DeeplineClient.checkPlayArtifact}.
932
+ */
933
+ interface PlayCheckSqlListenerTrigger {
934
+ id: string;
935
+ tool?: string;
936
+ stream?: string;
937
+ operations: string[];
938
+ /**
939
+ * The recognized `sqlListeners.where` row filter, echoed back so an author can
940
+ * confirm Deepline bound it. Mirrors the server `StoredSqlListenerWhere` shape
941
+ * (`before` / `after` maps of column → operator filter). Absent when the
942
+ * listener declares no `where`.
943
+ */
944
+ where?: {
945
+ before?: Record<string, Record<string, unknown>>;
946
+ after?: Record<string, Record<string, unknown>>;
947
+ };
948
+ }
949
+ /**
950
+ * Concise summary of the trigger bindings the server recognized for a play.
951
+ * Only present triggers are populated.
952
+ */
953
+ interface PlayCheckTriggersSummary {
954
+ sqlListeners?: PlayCheckSqlListenerTrigger[];
955
+ cron?: {
956
+ schedule: string;
957
+ timezone?: string;
958
+ };
959
+ webhook?: true;
960
+ }
872
961
  interface PlayCheckToolGetterHint {
873
962
  toolId: string;
874
963
  lists: Array<{
@@ -2845,9 +2934,16 @@ type PreviousCell<Value = unknown> = {
2845
2934
  /**
2846
2935
  * Optional trigger bindings for a play.
2847
2936
  *
2848
- * Plays can be triggered by webhooks (with HMAC signature verification)
2849
- * or cron schedules. Bindings are declared as the third argument to
2850
- * {@link definePlay}.
2937
+ * A play can be triggered three ways, declared as the third argument to
2938
+ * {@link definePlay}:
2939
+ * - `webhook` — an inbound HTTP call (with optional HMAC signature verification);
2940
+ * - `cron` — a schedule; or
2941
+ * - `sqlListeners` — a **monitor**: the play runs whenever a monitor writes a new
2942
+ * row to its output stream. This is how you build a play "on top of" a monitor
2943
+ * (e.g. run enrichment every time a watched company posts a new job). Each
2944
+ * listener binds to a monitor tool id + one of its output stream keys (see
2945
+ * `deepline monitors available <id>` for a tool's streams and row columns).
2946
+ * The changed row is delivered to the handler as the listener event's `after`.
2851
2947
  *
2852
2948
  * @example Webhook with HMAC verification
2853
2949
  * ```typescript
@@ -2869,6 +2965,20 @@ type PreviousCell<Value = unknown> = {
2869
2965
  * });
2870
2966
  * ```
2871
2967
  *
2968
+ * @example Monitor-triggered (run a play on a monitor's output)
2969
+ * ```typescript
2970
+ * definePlay('on-new-job-opening', handler, {
2971
+ * sqlListeners: [
2972
+ * {
2973
+ * id: 'jobs',
2974
+ * tool: 'tamradar.company_radar',
2975
+ * stream: 'company_job_openings',
2976
+ * operations: ['INSERT'],
2977
+ * },
2978
+ * ],
2979
+ * });
2980
+ * ```
2981
+ *
2872
2982
  * @sdkReference runtime 030
2873
2983
  */
2874
2984
  type PlayBindings = {
package/dist/index.d.ts CHANGED
@@ -866,9 +866,98 @@ interface PlayCheckResult {
866
866
  warnings?: string[];
867
867
  staticPipeline?: Record<string, unknown> | null;
868
868
  toolGetterHints?: PlayCheckToolGetterHint[];
869
+ /**
870
+ * Recognized trigger bindings parsed from the play source (`sqlListeners` /
871
+ * cron / webhook). Present only when the play declares at least one trigger,
872
+ * so an author can confirm the binding was recognized rather than silently
873
+ * dropped. Field names mirror the `definePlay` binding contract.
874
+ */
875
+ triggers?: PlayCheckTriggersSummary | null;
876
+ /**
877
+ * Structured, machine-actionable issues surfaced by the check. An ADDITIVE
878
+ * channel alongside `errors[]`: every `error`-severity issue is also present
879
+ * in `errors[]` (so string-level tooling keeps working), while an agent can
880
+ * read `code` / `validOptions` / `docsHint` to self-correct. `warning`
881
+ * severity issues do NOT make the check invalid.
882
+ */
883
+ issues?: PlayCheckIssue[];
884
+ /**
885
+ * Affirmative echo of what Deepline recognized — triggers, tools,
886
+ * datasets/columns, inputs, outputs — so a valid check reflects the parsed
887
+ * shape rather than a bare "ok".
888
+ */
889
+ recognized?: PlayCheckRecognizedSummary;
890
+ /**
891
+ * Human one-liner over {@link PlayCheckResult.recognized}, e.g.
892
+ * `1 trigger · 2 tools · 1 dataset · 14 columns`.
893
+ */
894
+ summary?: string;
869
895
  artifactHash?: string | null;
870
896
  graphHash?: string | null;
871
897
  }
898
+ /** Severity of a {@link PlayCheckIssue}. `error` fails the check; `warning` does not. */
899
+ type PlayCheckIssueSeverity = 'error' | 'warning';
900
+ /**
901
+ * One structured, machine-actionable issue surfaced by `deepline plays check`.
902
+ * Mirrors the server-side `PlayCheckIssue` contract. `code` is a stable machine
903
+ * code from a closed server-side set; `validOptions` enumerates the valid values
904
+ * (tool ids / stream keys / columns / operators) so an agent self-corrects by
905
+ * reading the structure instead of brute-forcing the compiler.
906
+ */
907
+ interface PlayCheckIssue {
908
+ code: string;
909
+ severity: PlayCheckIssueSeverity;
910
+ message: string;
911
+ path?: string;
912
+ hint?: string;
913
+ validOptions?: string[];
914
+ docsHint?: string;
915
+ }
916
+ /**
917
+ * Affirmative "here's what Deepline recognized" echo returned alongside a
918
+ * check's issues. Field names reuse the public play binding contract.
919
+ */
920
+ interface PlayCheckRecognizedSummary {
921
+ triggers?: PlayCheckTriggersSummary;
922
+ tools?: string[];
923
+ datasets?: {
924
+ name: string;
925
+ columns?: string[];
926
+ }[];
927
+ inputs?: string[];
928
+ outputs?: string[];
929
+ }
930
+ /**
931
+ * One recognized SQL-listener trigger echoed back by {@link DeeplineClient.checkPlayArtifact}.
932
+ */
933
+ interface PlayCheckSqlListenerTrigger {
934
+ id: string;
935
+ tool?: string;
936
+ stream?: string;
937
+ operations: string[];
938
+ /**
939
+ * The recognized `sqlListeners.where` row filter, echoed back so an author can
940
+ * confirm Deepline bound it. Mirrors the server `StoredSqlListenerWhere` shape
941
+ * (`before` / `after` maps of column → operator filter). Absent when the
942
+ * listener declares no `where`.
943
+ */
944
+ where?: {
945
+ before?: Record<string, Record<string, unknown>>;
946
+ after?: Record<string, Record<string, unknown>>;
947
+ };
948
+ }
949
+ /**
950
+ * Concise summary of the trigger bindings the server recognized for a play.
951
+ * Only present triggers are populated.
952
+ */
953
+ interface PlayCheckTriggersSummary {
954
+ sqlListeners?: PlayCheckSqlListenerTrigger[];
955
+ cron?: {
956
+ schedule: string;
957
+ timezone?: string;
958
+ };
959
+ webhook?: true;
960
+ }
872
961
  interface PlayCheckToolGetterHint {
873
962
  toolId: string;
874
963
  lists: Array<{
@@ -2845,9 +2934,16 @@ type PreviousCell<Value = unknown> = {
2845
2934
  /**
2846
2935
  * Optional trigger bindings for a play.
2847
2936
  *
2848
- * Plays can be triggered by webhooks (with HMAC signature verification)
2849
- * or cron schedules. Bindings are declared as the third argument to
2850
- * {@link definePlay}.
2937
+ * A play can be triggered three ways, declared as the third argument to
2938
+ * {@link definePlay}:
2939
+ * - `webhook` — an inbound HTTP call (with optional HMAC signature verification);
2940
+ * - `cron` — a schedule; or
2941
+ * - `sqlListeners` — a **monitor**: the play runs whenever a monitor writes a new
2942
+ * row to its output stream. This is how you build a play "on top of" a monitor
2943
+ * (e.g. run enrichment every time a watched company posts a new job). Each
2944
+ * listener binds to a monitor tool id + one of its output stream keys (see
2945
+ * `deepline monitors available <id>` for a tool's streams and row columns).
2946
+ * The changed row is delivered to the handler as the listener event's `after`.
2851
2947
  *
2852
2948
  * @example Webhook with HMAC verification
2853
2949
  * ```typescript
@@ -2869,6 +2965,20 @@ type PreviousCell<Value = unknown> = {
2869
2965
  * });
2870
2966
  * ```
2871
2967
  *
2968
+ * @example Monitor-triggered (run a play on a monitor's output)
2969
+ * ```typescript
2970
+ * definePlay('on-new-job-opening', handler, {
2971
+ * sqlListeners: [
2972
+ * {
2973
+ * id: 'jobs',
2974
+ * tool: 'tamradar.company_radar',
2975
+ * stream: 'company_job_openings',
2976
+ * operations: ['INSERT'],
2977
+ * },
2978
+ * ],
2979
+ * });
2980
+ * ```
2981
+ *
2872
2982
  * @sdkReference runtime 030
2873
2983
  */
2874
2984
  type PlayBindings = {
package/dist/index.js CHANGED
@@ -422,10 +422,10 @@ var SDK_RELEASE = {
422
422
  // 0.1.154 removes the short-lived generated enrich StepOptions recompute
423
423
  // fields shipped in 0.1.153.
424
424
  // 0.1.175 ships loud `deepline enrich` empty-waterfall reporting.
425
- version: "0.1.186",
425
+ version: "0.1.187",
426
426
  apiContract: "2026-06-dataset-handle-results-hard-cutover",
427
427
  supportPolicy: {
428
- latest: "0.1.186",
428
+ latest: "0.1.187",
429
429
  minimumSupported: "0.1.53",
430
430
  deprecatedBelow: "0.1.53",
431
431
  commandMinimumSupported: [
package/dist/index.mjs CHANGED
@@ -352,10 +352,10 @@ var SDK_RELEASE = {
352
352
  // 0.1.154 removes the short-lived generated enrich StepOptions recompute
353
353
  // fields shipped in 0.1.153.
354
354
  // 0.1.175 ships loud `deepline enrich` empty-waterfall reporting.
355
- version: "0.1.186",
355
+ version: "0.1.187",
356
356
  apiContract: "2026-06-dataset-handle-results-hard-cutover",
357
357
  supportPolicy: {
358
- latest: "0.1.186",
358
+ latest: "0.1.187",
359
359
  minimumSupported: "0.1.53",
360
360
  deprecatedBelow: "0.1.53",
361
361
  commandMinimumSupported: [
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "deepline",
3
- "version": "0.1.186",
3
+ "version": "0.1.187",
4
4
  "description": "Deepline SDK + CLI — B2B data enrichment powered by durable cloud execution",
5
5
  "license": "MIT",
6
6
  "repository": {