@boboddy/sdk 0.5.0 → 0.5.2

package/dist/definitions/validation/json-schema-paths.d.ts

@@ -43,3 +43,32 @@ export declare function enumeratePaths(node: JsonSchemaNode, root: JsonSchemaNod
  * `$ref`s are resolved against the root.
  */
 export declare function resolveSourcePath(schema: JsonSchemaNode, sourcePath: string): PathResolution;
+/**
+ * The type vocabulary a schema node is reduced to. `"integer"` (a JSON
+ * Schema refinement Zod emits for `z.number().int()`) collapses into
+ * `"number"`; anything the schema doesn't pin to exactly one of these is
+ * `"unknown"`.
+ */
+export type SchemaType = "string" | "number" | "boolean" | "object" | "array" | "null" | "unknown";
+/**
+ * Reduces a JSON Schema node to its top-level type, per `SchemaType`.
+ *
+ * Follows the same `$ref` / `anyOf` / `oneOf` / `allOf` flattening
+ * `resolveSourcePath` uses, so a `$ref` is resolved against `root` (default:
+ * `node` itself — pass the document root explicitly when `node` came from
+ * deeper inside it). Returns `"unknown"` — never a guess — when: the schema
+ * is absent (`{}`, e.g. `z.unknown()`) or a boolean schema (`true` / `false`);
+ * a `$ref` fails to resolve; or the branches disagree on type (a union of
+ * a string and a number, say). A false "this is definitely a string" is
+ * worse than an honest "unknown" here, same bias as path resolution.
+ */
+export declare function resolveSchemaType(node: JsonSchemaNode, root?: JsonSchemaNode): SchemaType;
+/**
+ * The type `sourcePath` resolves to within `schema` — `"unknown"` whenever
+ * the path doesn't provably resolve to a single node (indeterminate or
+ * invalid) or the node it resolves to doesn't pin down a single type.
+ *
+ * Pass the step's `resultSchemaJson` as `schema`; `$ref`s are resolved
+ * against it as the document root, matching `resolveSourcePath`.
+ */
+export declare function resolvePathType(schema: JsonSchemaNode, sourcePath: string): SchemaType;

package/dist/definitions/validation/validate-definition-specs.d.ts

@@ -1,5 +1,6 @@
 import { type PipelineDefinitionSpec } from "../pipelines/define-pipeline";
 import type { StepDefinitionSpec } from "../steps/define-step";
+import { type DefinitionValidationIssue } from "./validation-issue";
 export type DefinitionSpecSet = {
     readonly pipelines: readonly PipelineDefinitionSpec[];
     readonly steps: readonly StepDefinitionSpec[];
@@ -12,32 +13,20 @@ export type ValidateDefinitionSpecsOptions = {
      */
     readonly knownPipelineKeys?: readonly string[];
 };
-export type DefinitionValidationIssue = {
-    readonly check: "signal-source-path" | "route-target" | "signal-binding" | "health-check-mcp-server" | "health-check-double-qualified";
-    readonly message: string;
-    /**
-     * The pipeline this issue belongs to, when the check is pipeline-scoped
-     * (`route-target`/`signal-binding`) — absent for step-only checks
-     * (`signal-source-path`/`health-check-*`), which have no pipeline
-     * context of their own. Required before the designer (Phase 5) can
-     * attach an error to the right graph node.
-     */
-    readonly pipelineKey?: string;
-    /** The node this issue is about, when pipeline-scoped. */
-    readonly nodeKey?: string;
-    /**
-     * A second, related node this issue is about — e.g. `signal-binding`'s
-     * producer node, when different from `nodeKey`'s consumer. Absent when
-     * the issue is about a single node, or when the "other end" isn't a
-     * node in this pipeline at all (`route-target`'s target is a different
-     * *pipeline*, not a node).
-     */
-    readonly targetNodeKey?: string;
-};
 /**
  * Runs every offline check over a batch of definitions and returns the issues
  * found, in check order. An empty array means the batch is clean.
  */
 export declare function validateDefinitionSpecs(specs: DefinitionSpecSet, options?: ValidateDefinitionSpecsOptions): DefinitionValidationIssue[];
-/** `validateDefinitionSpecs`, but throws a single aggregated error. */
+/**
+ * `validateDefinitionSpecs`, but throws a single aggregated error.
+ *
+ * Only counts and lists `severity: "error"` issues — `"warning"`-tier issues
+ * (`binding-type-mismatch`) and `"info"`-tier issues (`binding-target-field`'s
+ * unbound-field-name sub-check) never block a push and are silently dropped
+ * from both the header count and the body here. They're still present in
+ * `validateDefinitionSpecs`'s own return value for any caller that wants to
+ * surface them (e.g. the designer, in a later phase); this is the one entry
+ * point whose whole job is "should this push be blocked."
+ */
 export declare function assertValidDefinitionSpecs(specs: DefinitionSpecSet, options?: ValidateDefinitionSpecsOptions): void;

package/dist/definitions/validation/validate-input-bindings.d.ts

@@ -0,0 +1,7 @@
+import { type PipelineDefinitionSpec } from "../pipelines/define-pipeline";
+import type { StepDefinitionSpec } from "../steps/define-step";
+import { type DefinitionValidationIssue } from "./validation-issue";
+declare function checkUnboundRequiredInputs(pipelines: readonly PipelineDefinitionSpec[], stepsByKey: Map<string, readonly StepDefinitionSpec[]>): DefinitionValidationIssue[];
+declare function checkBindingTargetFields(pipelines: readonly PipelineDefinitionSpec[], stepsByKey: Map<string, readonly StepDefinitionSpec[]>): DefinitionValidationIssue[];
+declare function checkBindingTypeCompatibility(pipelines: readonly PipelineDefinitionSpec[], stepsByKey: Map<string, readonly StepDefinitionSpec[]>): DefinitionValidationIssue[];
+export { checkBindingTargetFields, checkBindingTypeCompatibility, checkUnboundRequiredInputs, };

package/dist/definitions/validation/validation-issue.d.ts

@@ -0,0 +1,52 @@
+export type DefinitionValidationIssue = {
+    readonly check: "signal-source-path" | "route-target" | "signal-binding" | "health-check-mcp-server" | "health-check-double-qualified" | "unbound-required-input" | "binding-target-field" | "binding-type-mismatch";
+    /**
+     * Whether this issue blocks a push. The 4 original checks are all
+     * unconditionally `"error"`, matching their implicit all-blocking
+     * behavior before this field existed. `"binding-type-mismatch"` is a
+     * `"warning"`-tier check — a resolved type disagreement is worth
+     * surfacing but, per §4's own bias, never provably a runtime failure the
+     * way an unresolved binding or a missing required input is.
+     * `"binding-target-field"`'s "unbound field name isn't a declared
+     * `additionalInput`" sub-check is `"info"`-tier — passing extra context
+     * a step doesn't declare as an `additionalInput` is allowed (the value is
+     * just dropped), so it's worth surfacing for awareness but never rises to
+     * even a warning. Only `assertValidDefinitionSpecs` treats these tiers
+     * differently: it blocks a push on `"error"` alone.
+     */
+    readonly severity: "error" | "warning" | "info";
+    readonly message: string;
+    /**
+     * The pipeline this issue belongs to, when the check is pipeline-scoped
+     * (`route-target`/`signal-binding`/the three Phase 2 binding checks) —
+     * absent for step-only checks (`signal-source-path`/`health-check-*`),
+     * which have no pipeline context of their own. Required before the
+     * designer (Phase 5) can attach an error to the right graph node.
+     */
+    readonly pipelineKey?: string;
+    /** The node this issue is about, when pipeline-scoped. */
+    readonly nodeKey?: string;
+    /**
+     * A second, related node this issue is about — e.g. `signal-binding`'s
+     * producer node, when different from `nodeKey`'s consumer. Absent when
+     * the issue is about a single node, or when the "other end" isn't a
+     * node in this pipeline at all (`route-target`'s target is a different
+     * *pipeline*, not a node).
+     */
+    readonly targetNodeKey?: string;
+    /**
+     * The specific `parallel` branch this issue is about, when `nodeKey`
+     * names a `parallel` node — one of that node's `branches` keys. Set only
+     * by the three Phase 2 binding checks (`unbound-required-input`/
+     * `binding-target-field`/`binding-type-mismatch`) when the
+     * `BindingContext` they're walking is a `parallel` branch's own bindings
+     * (`bindingContexts`' `ctx.branchKey`), not the node's own bindings.
+     * Absent for every other check, and absent for those three checks' own
+     * non-`parallel` (`step`/`fanOut`/`loop`) cases — without this, issues
+     * from two different branches of the same `parallel` node are
+     * indistinguishable by branch.
+     */
+    readonly branchKey?: string;
+};
+/** Formats a path list for an error message, capped so it stays readable. */
+export declare function listPaths(paths: readonly string[], limit?: number): string;

package/dist/generated/types.gen.d.ts

@@ -4814,6 +4814,7 @@ export type PostApiPipelineDefinitionsData = {
                 [key: string]: unknown;
             } | unknown;
         }>;
+        entryNodeKey?: string;
     };
     path?: never;
     query?: never;
@@ -5260,6 +5261,7 @@ export type PutApiPipelineDefinitionsData = {
                 [key: string]: unknown;
             } | unknown;
         }>;
+        entryNodeKey?: string;
     };
     path?: never;
     query?: never;