@pgflow/dsl 0.0.5 → 0.0.6

package/__tests__/types/extract-flow-input.test-d.ts

@@ -1,71 +0,0 @@
-import { AnyFlow, ExtractFlowInput, Flow } from '../../src/index.ts';
-import { describe, it, expectTypeOf } from 'vitest';
-
-describe('ExtractFlowInput utility type', () => {
-  it('should correctly extract the input type from a flow with defined input', () => {
-    const flow = new Flow<{ userId: number; query: string }>({
-      slug: 'user_search_flow',
-    });
-
-    type FlowInput = ExtractFlowInput<typeof flow>;
-
-    expectTypeOf<FlowInput>().toMatchTypeOf<{
-      userId: number;
-      query: string;
-    }>();
-
-    // ensure it doesn't extract non-existent fields
-    expectTypeOf<FlowInput>().not.toMatchTypeOf<{
-      nonExistentField: number;
-    }>();
-  });
-
-  it('should work with AnyFlow', () => {
-    const anyFlow: AnyFlow = new Flow<{ data: string }>({ slug: 'any_flow' });
-
-    type ExtractedInput = ExtractFlowInput<typeof anyFlow>;
-
-    expectTypeOf<ExtractedInput>().toMatchTypeOf<any>();
-  });
-
-  it('should extract complex nested input types', () => {
-    const complexFlow = new Flow<{
-      user: {
-        id: number;
-        profile: {
-          name: string;
-          preferences: string[];
-        };
-      };
-      options: {
-        includeMeta: boolean;
-      };
-    }>({ slug: 'complex_input_flow' });
-
-    type ComplexInput = ExtractFlowInput<typeof complexFlow>;
-
-    expectTypeOf<ComplexInput>().toMatchTypeOf<{
-      user: {
-        id: number;
-        profile: {
-          name: string;
-          preferences: string[];
-        };
-      };
-      options: {
-        includeMeta: boolean;
-      };
-    }>();
-
-    // ensure it doesn't extract non-existent fields
-    expectTypeOf<ComplexInput>().not.toMatchTypeOf<{
-      user: {
-        nonExistentField: number;
-      };
-      options: {
-        nonExistentOption: string;
-      };
-      nonExistentInput: string;
-    }>();
-  });
-});

package/__tests__/types/extract-flow-steps.test-d.ts

@@ -1,74 +0,0 @@
-import { Flow, type ExtractFlowSteps } from '../../src/index.ts';
-import { describe, it, expectTypeOf } from 'vitest';
-
-describe('ExtractFlowSteps utility type', () => {
-  it('should correctly extract steps from a flow with defined input', () => {
-    const flow = new Flow<{ userId: number }>({ slug: 'user_flow' })
-      .step({ slug: 'fetchUser' }, () => ({ name: 'John', age: 30 }))
-      .step({ slug: 'fetchPosts', dependsOn: ['fetchUser'] }, () => [
-        { id: 1, title: 'Hello World' },
-        { id: 2, title: 'TypeScript is Fun' },
-      ]);
-
-    type Steps = ExtractFlowSteps<typeof flow>;
-
-    expectTypeOf<Steps>().toMatchTypeOf<{
-      fetchUser: { name: string; age: number };
-      fetchPosts: Array<{ id: number; title: string }>;
-    }>();
-
-    // ensure it doesn't extract non-existent fields
-    expectTypeOf<Steps>().not.toMatchTypeOf<{
-      nonExistentStep: number;
-    }>();
-  });
-
-  it('should work with AnyFlow to extract steps from a generic flow', () => {
-    const anyFlow = new Flow({ slug: 'any_flow' })
-      .step({ slug: 'step1' }, () => 42)
-      .step({ slug: 'step2' }, () => 'string value')
-      .step({ slug: 'step3' }, () => ({ complex: { nested: true } }));
-
-    type Steps = ExtractFlowSteps<typeof anyFlow>;
-
-    expectTypeOf<Steps>().toMatchTypeOf<{
-      step1: number;
-      step2: string;
-      step3: { complex: { nested: boolean } };
-    }>();
-
-    // ensure it doesn't extract non-existent fields
-    expectTypeOf<Steps>().not.toMatchTypeOf<{
-      nonExistentStep: number;
-    }>();
-  });
-
-  it('should handle empty steps correctly', () => {
-    const emptyFlow = new Flow({ slug: 'empty_flow' });
-    type Steps = ExtractFlowSteps<typeof emptyFlow>;
-
-    expectTypeOf<Steps>().toEqualTypeOf<Record<never, never>>();
-  });
-
-  it('should extract steps with primitive return types', () => {
-    const primitiveFlow = new Flow({ slug: 'primitive_flow' })
-      .step({ slug: 'numberStep' }, () => 123)
-      .step({ slug: 'stringStep' }, () => 'text')
-      .step({ slug: 'booleanStep' }, () => true)
-      .step({ slug: 'nullStep' }, () => null);
-
-    type Steps = ExtractFlowSteps<typeof primitiveFlow>;
-
-    expectTypeOf<Steps>().toMatchTypeOf<{
-      numberStep: number;
-      stringStep: string;
-      booleanStep: boolean;
-      nullStep: null;
-    }>();
-
-    // ensure it doesn't extract non-existent fields
-    expectTypeOf<Steps>().not.toMatchTypeOf<{
-      nonExistentStep: number;
-    }>();
-  });
-});

package/__tests__/types/getStepDefinition.test-d.ts

@@ -1,65 +0,0 @@
-import { Flow } from '../../src/index.ts';
-import { it, expectTypeOf, expect } from 'vitest';
-
-it('should correctly type step handlers when using getStepDefinition', () => {
-  const TestFlow = new Flow<{ url: string }>({ slug: 'test_flo' })
-    .step({ slug: 'root_a' }, (input) =>
-      [input.run.url, input.run.url].join(' ')
-    )
-    .step({ slug: 'root_b' }, (input) => input.run.url.length)
-    .step({ slug: 'merge', dependsOn: ['root_a', 'root_b'] }, (input) => {
-      return {
-        a_val: input.root_a,
-        b_val: input.root_b,
-      };
-    });
-
-  const root_a = TestFlow.getStepDefinition('root_a');
-
-  // Test root_a handler type
-  expectTypeOf(root_a.handler).toBeFunction();
-  expectTypeOf(root_a.handler).parameters.toMatchTypeOf<
-    [{ run: { url: string } }]
-  >();
-  expectTypeOf(root_a.handler).returns.toMatchTypeOf<
-    string | Promise<string>
-  >();
-
-  // Test root_b handler type
-  const root_b = TestFlow.getStepDefinition('root_b');
-  expectTypeOf(root_b.handler).toBeFunction();
-  expectTypeOf(root_b.handler).parameters.toMatchTypeOf<
-    [{ run: { url: string } }]
-  >();
-  expectTypeOf(root_b.handler).returns.toMatchTypeOf<
-    number | Promise<number>
-  >();
-
-  // Test merge handler type
-  const merge = TestFlow.getStepDefinition('merge');
-  expectTypeOf(merge.handler).toBeFunction();
-  expectTypeOf(merge.handler).parameters.toMatchTypeOf<
-    [
-      {
-        run: { url: string };
-        root_a: string;
-        root_b: number;
-      }
-    ]
-  >();
-  expectTypeOf(merge.handler).returns.toMatchTypeOf<
-    | {
-        a_val: string;
-        b_val: number;
-      }
-    | Promise<{
-        a_val: string;
-        b_val: number;
-      }>
-  >();
-
-  // Test that dependencies are correctly set
-  expect(root_a.dependencies).toEqual([]);
-  expect(root_b.dependencies).toEqual([]);
-  expect(merge.dependencies).toEqual(['root_a', 'root_b']);
-});

package/__tests__/types/step-input.test-d.ts

@@ -1,212 +0,0 @@
-import { Flow, type StepInput } from '../../src/index.ts';
-import { describe, it, expectTypeOf } from 'vitest';
-
-describe('StepInput utility type', () => {
-  describe('for a flow without steps', () => {
-    const emptyFlow = new Flow<{ userId: number }>({ slug: 'empty_flow' });
-    type NonExistentInput = StepInput<typeof emptyFlow, 'nonExistentStep'>;
-
-    it('should contain only run input for non-existent steps', () => {
-      expectTypeOf<NonExistentInput>().toMatchTypeOf<{
-        run: { userId: number };
-      }>();
-    });
-
-    it('should not allow extraneous keys', () => {
-      expectTypeOf<NonExistentInput>().not.toMatchTypeOf<{
-        nonExistentStep: any;
-      }>();
-    });
-  });
-
-  describe('for a flow with two root steps', () => {
-    const twoRootFlow = new Flow<{ baseInput: string }>({
-      slug: 'two_root_flow',
-    })
-      .step({ slug: 'step1' }, () => ({ result1: 42 }))
-      .step({ slug: 'step2' }, () => ({ result2: 'test' }));
-
-    describe('step1 input', () => {
-      type Step1Input = StepInput<typeof twoRootFlow, 'step1'>;
-
-      it('should only contain run input and not the other root step', () => {
-        expectTypeOf<Step1Input>().toMatchTypeOf<{
-          run: { baseInput: string };
-        }>();
-        expectTypeOf<Step1Input>().not.toMatchTypeOf<{
-          step2: { result2: string };
-        }>();
-      });
-
-      it('should not allow extraneous keys', () => {
-        expectTypeOf<Step1Input>().not.toMatchTypeOf<{
-          extraProperty: unknown;
-        }>();
-      });
-    });
-
-    describe('step2 input', () => {
-      type Step2Input = StepInput<typeof twoRootFlow, 'step2'>;
-
-      it('should only contain run input and not contain the other root step', () => {
-        expectTypeOf<Step2Input>().toMatchTypeOf<{
-          run: { baseInput: string };
-        }>();
-        expectTypeOf<Step2Input>().not.toMatchTypeOf<{
-          step1: { result1: number };
-        }>();
-      });
-
-      it('should not allow extraneous keys', () => {
-        expectTypeOf<Step2Input>().not.toMatchTypeOf<{
-          extraProperty: unknown;
-        }>();
-      });
-    });
-
-    it('should contain only run input if used for non-existent steps', () => {
-      type NonExistentInput = StepInput<typeof twoRootFlow, 'nonExistentStep'>;
-      expectTypeOf<NonExistentInput>().toMatchTypeOf<{
-        run: { baseInput: string };
-      }>();
-      expectTypeOf<NonExistentInput>().not.toMatchTypeOf<{
-        step1: any;
-      }>();
-      expectTypeOf<NonExistentInput>().not.toMatchTypeOf<{
-        step2: any;
-      }>();
-      expectTypeOf<NonExistentInput>().not.toMatchTypeOf<{
-        extraProperty: unknown;
-      }>();
-    });
-  });
-
-  describe('for a flow with root step and dependent steps', () => {
-    const dependentFlow = new Flow<{ userId: string }>({
-      slug: 'dependent_flow',
-    })
-      .step({ slug: 'rootStep' }, () => ({ data: 'root' }))
-      .step({ slug: 'dependent1', dependsOn: ['rootStep'] }, () => ({
-        child: 1,
-      }))
-      .step({ slug: 'dependent2', dependsOn: ['rootStep'] }, () => ({
-        child: 2,
-      }));
-
-    describe('rootStep input', () => {
-      type RootStepInput = StepInput<typeof dependentFlow, 'rootStep'>;
-
-      it('should only contain run input', () => {
-        expectTypeOf<RootStepInput>().toMatchTypeOf<{
-          run: { userId: string };
-        }>();
-      });
-
-      it('should not contain dependent1 step', () => {
-        expectTypeOf<RootStepInput>().not.toMatchTypeOf<{
-          dependent1: { child: number };
-        }>();
-      });
-
-      it('should not contain dependent2 step', () => {
-        expectTypeOf<RootStepInput>().not.toMatchTypeOf<{
-          dependent2: { child: number };
-        }>();
-      });
-
-      it('should not allow extraneous keys', () => {
-        expectTypeOf<RootStepInput>().not.toMatchTypeOf<{
-          extraProperty: unknown;
-        }>();
-      });
-    });
-
-    describe('dependent1 input', () => {
-      type Dependent1Input = StepInput<typeof dependentFlow, 'dependent1'>;
-
-      it('should contain run input and rootStep', () => {
-        expectTypeOf<Dependent1Input>().toMatchTypeOf<{
-          run: { userId: string };
-          rootStep: { data: string };
-        }>();
-      });
-
-      it('should not contain dependent2 step', () => {
-        expectTypeOf<Dependent1Input>().not.toMatchTypeOf<{
-          dependent2: { child: number };
-        }>();
-      });
-
-      it('should not allow extraneous keys', () => {
-        expectTypeOf<Dependent1Input>().not.toMatchTypeOf<{
-          extraProperty: unknown;
-        }>();
-      });
-    });
-
-    describe('dependent2 input', () => {
-      type Dependent2Input = StepInput<typeof dependentFlow, 'dependent2'>;
-
-      it('should contain run input and rootStep', () => {
-        expectTypeOf<Dependent2Input>().toMatchTypeOf<{
-          run: { userId: string };
-          rootStep: { data: string };
-        }>();
-      });
-
-      it('should not contain dependent1 step', () => {
-        expectTypeOf<Dependent2Input>().not.toMatchTypeOf<{
-          dependent1: { child: number };
-        }>();
-      });
-
-      it('should not allow extraneous keys', () => {
-        expectTypeOf<Dependent2Input>().not.toMatchTypeOf<{
-          extraProperty: unknown;
-        }>();
-      });
-    });
-  });
-
-  describe('for a flow with multiple dependencies', () => {
-    const complexFlow = new Flow<{ initial: boolean }>({
-      slug: 'complex_flow',
-    })
-      .step({ slug: 'step1' }, () => ({ val1: 'a' }))
-      .step({ slug: 'step2' }, () => ({ val2: 'b' }))
-      .step({ slug: 'step3', dependsOn: ['step1', 'step2'] }, () => ({
-        val3: 'c',
-      }));
-
-    describe('step3 input with multiple dependencies', () => {
-      type Step3Input = StepInput<typeof complexFlow, 'step3'>;
-
-      it('should contain run input and both dependencies', () => {
-        expectTypeOf<Step3Input>().toMatchTypeOf<{
-          run: { initial: boolean };
-          step1: { val1: string };
-          step2: { val2: string };
-        }>();
-      });
-
-      it('should not allow extraneous keys', () => {
-        expectTypeOf<Step3Input>().not.toMatchTypeOf<{
-          extraProperty: unknown;
-        }>();
-      });
-    });
-
-    it('should contain only run input for non-existent steps', () => {
-      type NonExistentInput = StepInput<typeof complexFlow, 'nonExistentStep'>;
-      expectTypeOf<NonExistentInput>().toMatchTypeOf<{
-        run: { initial: boolean };
-      }>();
-      expectTypeOf<NonExistentInput>().not.toMatchTypeOf<{
-        step1: { val1: string };
-      }>();
-      expectTypeOf<NonExistentInput>().not.toMatchTypeOf<{
-        step2: { val2: string };
-      }>();
-    });
-  });
-});

package/__tests__/types/step-output.test-d.ts

@@ -1,55 +0,0 @@
-import { Flow, type StepOutput } from '../../src/index.ts';
-import { describe, it, expectTypeOf } from 'vitest';
-
-describe('StepOutput utility type', () => {
-  it('should correctly extract the output type of a step', () => {
-    const flow = new Flow<{ input: string }>({ slug: 'step_output_test' })
-      .step({ slug: 'step1' }, () => ({ value: 42, text: 'hello' }))
-      .step({ slug: 'step2', dependsOn: ['step1'] }, () => ({ flag: true }))
-      .step({ slug: 'step3' }, () => 'plain string');
-
-    type Step1Output = StepOutput<typeof flow, 'step1'>;
-
-    expectTypeOf<Step1Output>().toMatchTypeOf<{
-      value: number;
-      text: string;
-    }>();
-
-    type Step2Output = StepOutput<typeof flow, 'step2'>;
-    expectTypeOf<Step2Output>().toMatchTypeOf<{ flag: boolean }>();
-
-    type Step3Output = StepOutput<typeof flow, 'step3'>;
-    expectTypeOf<Step3Output>().toMatchTypeOf<string>();
-
-    type NonExistentOutput = StepOutput<typeof flow, 'nonExistentStep'>;
-    expectTypeOf<NonExistentOutput>().toMatchTypeOf<never>();
-  });
-
-  it('should work with complex nested types', () => {
-    const complexFlow = new Flow<{ id: number }>({
-      slug: 'complex_flow',
-    }).step({ slug: 'complexStep' }, () => ({
-      data: {
-        items: [
-          { id: 1, name: 'Item 1' },
-          { id: 2, name: 'Item 2' },
-        ],
-        metadata: {
-          count: 2,
-          lastUpdated: '2023-01-01',
-        },
-      },
-    }));
-
-    type ComplexStepOutput = StepOutput<typeof complexFlow, 'complexStep'>;
-    expectTypeOf<ComplexStepOutput>().toMatchTypeOf<{
-      data: {
-        items: Array<{ id: number; name: string }>;
-        metadata: {
-          count: number;
-          lastUpdated: string;
-        };
-      };
-    }>();
-  });
-});

package/brainstorming/condition/condition-alternatives.md

@@ -1,219 +0,0 @@
-## Brainstorming Alternatives to JSON Containment `@>` for Step Conditions
-
-Below are various ideas for how to define and evaluate “conditions” on a step’s input, while still satisfying the constraints you outlined. Each approach aims to remain statically typed, only match the step’s input, be serializable to JSON, and avoid implementing a new DSL or separate custom operators.
-
----
-
-### 1. Use PostgreSQL JSONPath Evaluations
-Postgres supports JSONPath queries via functions like [`jsonb_path_exists`](https://www.postgresql.org/docs/current/functions-json.html#FUNCTIONS-SQLJSON-PATH). You could store the JSONPath expression in a JSON object and then evaluate it against the step’s combined input at runtime:
-
-```sql
--- Step condition data stored as JSON:
--- e.g. { "type": "jsonpath", "expression": "$.website.content ? (@ like_regex \"^Hello.*\")" }
-
-SELECT jsonb_path_exists(
-  payload, 
-  condition->>'expression'
-);
-```
-
-**Characteristics**  
-- **Statically typed**: You can maintain a TypeScript type that restricts which property paths are valid, for example with a string-literal type for domain-specific JSONPath expressions.  
-- **Single function**: PostgreSQL has a single function to evaluate arbitrary JSONPath expressions, so you don’t need to manually implement each comparison.  
-- **JSON-based**: The condition can be stored as JSON with a `"jsonpath"` key.  
-- **No raw SQL**: The `"expression"` is still a string, but the actual caller is the built-in `jsonb_path_exists`, which means you do not need to craft dynamic SQL.
-
-**Downsides**  
-- Complex textual JSONPath expressions can be tricky to type-check at compile time unless you build advanced TS generics.  
-
----
-
-### 2. Embed a “Condition Schema” with Built-in Operators
-You can store a small “condition schema” (like an AST) in JSON, referencing the step’s typed properties. A single Postgres function interprets that schema and performs the check. The schema might look like:
-
-```json
-{
-  "type": "comparison",
-  "lhsPath": ["website", "contentLength"],
-  "operator": "gt",
-  "rhsValue": 1000
-}
-```
-
-Then at runtime:
-
-```sql
--- Hypothetical function: 
--- `evaluate_condition(payload JSONB, condition JSONB) RETURNS bool`
--- that interprets the "operator" string and does the check without separate DSL code.
-
-SELECT evaluate_condition(payload, condition);
-```
-
-**Characteristics**  
-- **Statically typed**: In TypeScript, you can ensure `lhsPath` only references valid properties of the known input shape.  
-- **Single function**: All operators (`gt`, `eq`, `like`, etc.) are recognized by a single evaluator function inside Postgres.  
-- **JSON-based**: The entire condition is a JSON object.  
-- **No re-implementing operators**: You do need to parse `condition->>'operator'` but only in one place. Any new operator is recognized by the single function’s branching logic.  
-
-**Downsides**  
-- The internal function that interprets `operator` must handle each operator branch. However, that is one single location, and you don’t need a sprawling DSL – just a small piece of code.  
-
----
-
-### 3. Storing an Array of “Partial Objects” to Match with `@>` 
-Instead of a single containment check, you could chain multiple partial objects in an array, each of which must match:
-
-```json
-[
-  { "website": { "status": 200 } },
-  { "run": { "isInternal": true } }
-]
-```
-
-Then your condition means “the step’s input must contain all keys from both listed partial objects.” You could combine them as a single structure inside TS or keep them separate. Evaluating is done in Postgres via multiple `@>` calls:
-
-```sql
-SELECT payload @> condition_item
-FROM jsonb_array_elements(condition) AS condition_item
-```
-
-**Characteristics**  
-- **Statically typed**: TypeScript can ensure the partial objects only contain valid paths from your input shape.  
-- **Extremely simple**: Reuses Postgres’s built-in `@>` for partial matching.  
-- **Chaining**: Must pass all partials.  
-- **JSON-based**: No custom SQL or DSL.  
-
-**Downsides**  
-- This only gives you “containment” checks. More advanced comparisons like numeric ranges or `LIKE` patterns aren’t well supported out of the box.  
-- No direct way to handle “not equals” or more sophisticated conditions without reintroducing new fields.  
-
----
-
-### 4. Evaluate Conditions via JSON Schema (Using `is_jsonb_valid`) 
-You can represent certain conditions as a subset of [JSON Schema](https://json-schema.org/) (or a homegrown schema approach). Then store that schema as JSON. A single function in Postgres can validate the “payload” against that schema:
-
-```json
-{
-  "type": "object",
-  "properties": {
-    "website": {
-      "type": "object",
-      "properties": {
-        "status": { "enum": [200, 201] }
-      },
-      "required": ["status"]
-    }
-  },
-  "required": ["website"]
-}
-```
-
-Then use a Postgres extension or a custom function to do a JSON Schema validation:
-
-```sql
-SELECT is_jsonb_valid(payload, condition_schema);
-```
-
-**Characteristics**  
-- **Statically typed**: You can restrict the JSON Schema to only describe your known shape so it can’t mention nonexistent keys.  
-- **Featureful**: JSON Schema has a wide array of constraints (enum, minLength, pattern, etc.).  
-- **No manual operator code**: The library handles it.  
-- **JSON-based**: The schema is stored as JSON.  
-
-**Downsides**  
-- Requires a JSON Schema validator that runs inside Postgres or as part of your application logic. Specialized operators are needed if you want it fully inside PG.  
-- Some performance overhead for complex schemas.  
-
----
-
-### 5. Combine Paths + Operator + Value, Using Runtime “SQL Expression” Generation WITHOUT Exposing SQL
-Use a TS type that enforces a limited set of operators as strings. The condition remains in JSON form:
-
-```ts
-type AllowedOperator = '>' | '<' | '=' | 'LIKE';
-type ConditionPart = {
-  path: string[];  // e.g. ["website", "status"]
-  operator: AllowedOperator;
-  compareValue: string | number;
-};
-```
-
-**In JSON**:
-```json
-{
-  "path": ["website", "status"],
-  "operator": ">",
-  "compareValue": 199
-}
-```
-
-You can store multiple ConditionParts, interpret them in a single function, and convert them to a safe, typed expression. For example:
-
-```sql
--- Pseudocode
-PERFORM safe_evaluate(payload, condition);
-```
-
-**Characteristics**  
-- **Statically typed**: TS ensures `path` only references known fields, `operator` is in an allowed set, etc.  
-- **Single function**: You do not manually code for each operator in the DSL. You do one parse logic in `safe_evaluate(...)`.  
-- **No raw SQL strings**: The “operator” is a typed string, not user-supplied free text; you escape or map it carefully so you don’t run insecure dynamic SQL.  
-- **JSON-based**: Clear JSON serialization.  
-
-**Downsides**  
-- Does require a small “mapping table” from the typed `AllowedOperator` to the actual Postgres operator.  
-- Only covers the operators you’ve enumerated; custom logic might require expansions to the typed list.  
-
----
-
-### 6. Rely on Built-In Comparisons of JSON Path Query with `vars` 
-Another variant of the JSONPath idea: `jsonb_path_exists` can be passed external variables. You’d store the JSONPath expression plus a dictionary of variables in your condition. Example:
-
-```json
-{
-  "expression": "$.website.status ? (@ == $statusVal)",
-  "vars": { "statusVal": 200 }
-}
-```
-
-At runtime:
-
-```sql
-SELECT jsonb_path_exists(
-  payload,
-  condition->>'expression',
-  condition->'vars'
-);
-```
-
-**Characteristics**  
-- **Statically typed**: In TS, you can ensure that `vars` align with the expression’s placeholders, tying them to the known step input shape.  
-- **Single function**: Again, calls the built-in JSONPath mechanism.  
-- **No custom DSL**: The only “DSL” is standard JSONPath strings.  
-
-**Downsides**  
-- You still rely on textual quoting inside the JSONPath expression. That can be type-safe in TS if you codify it carefully.  
-
----
-
-### Balancing Statically Typed Constraints with JSON Storage
-
-All of the above illustrate slightly different ways to store a typed “match rule” in JSON. Whichever approach you choose, the key is to:
-
-1. **Enforce at compile time** (TypeScript) that only valid property paths and operators can appear in the condition object.  
-2. **Serialize the condition object as JSON** for storing in the database.  
-3. **Use a single “evaluation function” in Postgres** (or the existing built-in JSONPath / partial matching) so you don’t re-implement each operator as a standalone DSL.  
-
-This lets you stay flexible but also safe and maintainable.
-
----
-
-### Final Thoughts
-
-- **For simple presence checks**: Using partial object matching with `@>` is already a good minimal solution, but it can’t handle numeric comparisons or negations without manual expansions.  
-- **For advanced logic**: Harnessing JSONPath (`jsonb_path_exists`) or a small “comparison schema” can yield more expressive power without building a custom DSL.  
-- **TypeScript Generics**: You can generate path-literal types from your known input shape, ensuring you never store an invalid path in the condition.  
-- **Single Evaluation**: Keep a single place in Postgres that does the real check. This means you don’t have to maintain multiple code paths or define new DSL operators every time.  
-
-These strategies collectively satisfy all the “non-negotiable” points, while allowing you to encode robust dynamic conditions in a typed manner and store them as JSON for runtime.