From 5af2399e3ba884b1dfff004b6f1027615f2c5c51 Mon Sep 17 00:00:00 2001
From: Alex Groleau <agroleau@teampalmtree.com>
Date: Thu, 11 Jun 2026 20:40:27 -0400
Subject: [PATCH] fixed issue with filter generation where filters or
 conditions are used internally

---
 GEMINI.md                      | 1 +
 fixtures/filter.json           | 2 +-
 src/database/compile/filter.rs | 4 +++-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/GEMINI.md b/GEMINI.md
index 7c58efb..ae3961a 100644
--- a/GEMINI.md
+++ b/GEMINI.md
@@ -175,6 +175,7 @@ In the Punc architecture, filters are automatically synthesized, strongly-typed
 
 *   **Conditions**: A condition schema is the contract defining the mathematical operations allowed on a primitive field. For example, a `string.condition` allows `$eq`, `$ne`, `$gt`, `$gte`, `$lt`, `$lte`, `$of` (IN), and `$nof` (NOT IN). 
     *   **Enum Conditions**: When JSPG synthesizes an enum, it dynamically generates an `<enum>.condition` (e.g., `address_kind.condition`). This strongly-typed condition perfectly mirrors the operations of a `string.condition`, but strictly limits the arrays and inputs of `$eq`, `$ne`, `$of`, and `$nof` to the exact variations defined by that Enum. This context ensures that UI generators know exactly when to render `<Select>` dropdowns instead of generic `<Text>` boxes.
+    *   **Pre-compiled Condition and Filter Mapping**: To prevent redundant double-wrapping of search structures, any schema property whose type is already a `.condition` or `.filter` type (such as `"string.condition"` or `"$kind.filter"`) maps directly to itself during filter synthesis rather than receiving a redundant `.filter` suffix.
 *   **Filters**: A filter schema (e.g., `person.filter`) is an object containing condition properties used to filter entities. It natively supports structural composition:
     *   **Inherited Properties**: Filters automatically inherit all valid database columns from their base type schema, immediately converting them to their respective `.condition` schemas.
     *   **Relational Proxies**: If a table has a foreign key to another table, the filter automatically generates a proxy property pointing to the related entity's filter (e.g., the `person` filter automatically gains an `organization` property that points to `organization.filter`), allowing infinitely deep nested queries natively.
diff --git a/fixtures/filter.json b/fixtures/filter.json
index 625e50b..5ce1415 100644
--- a/fixtures/filter.json
+++ b/fixtures/filter.json
@@ -466,7 +466,7 @@
                 },
                 "filter": {
                   "type": [
-                    "$kind.filter.filter",
+                    "$kind.filter",
                     "null"
                   ]
                 },
diff --git a/src/database/compile/filter.rs b/src/database/compile/filter.rs
index 6a05772..7820901 100644
--- a/src/database/compile/filter.rs
+++ b/src/database/compile/filter.rs
@@ -159,7 +159,9 @@ impl Schema {
       },
       "null" => None,
       custom => {
-        if db.enums.contains_key(custom) {
+        if custom.ends_with(".condition") || custom.ends_with(".filter") {
+          Some(vec![custom.to_string()])
+        } else if db.enums.contains_key(custom) {
           Some(vec![format!("{}.condition", custom)])
         } else {
           // Assume anything else is a Relational cross-boundary that already has its own .filter dynamically built