@gallopsystems/agent-skills 1.18.0 → 1.19.0

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@gallopsystems/agent-skills",
3
- "version": "1.18.0",
3
+ "version": "1.19.0",
4
4
  "description": "Gallop Systems agent skills, symlinked into .claude/skills (Claude Code) and .agents/skills (Codex) on install.",
5
5
  "license": "UNLICENSED",
6
6
  "repository": {
@@ -159,3 +159,40 @@ The `"between"` operator looks like it should work but compiles to a tuple, whic
159
159
  .where((eb) => eb.betweenSymmetric("age", 65, 18)) // swaps bounds if needed
160
160
  ```
161
161
 
162
+ ### 9. Builder Argument Strings Are Column References, Not Literals
163
+
164
+ This bites hardest when converting raw `sql` to builders. In `eb.fn.coalesce`,
165
+ binary `eb(lhs, op, rhs)`, and most `eb.fn` calls, a bare string argument is
166
+ interpreted as a **column reference**, not a string value. So porting
167
+ `` sql`coalesce(status, 'pending')` `` naively produces a query that looks for a
168
+ column named `pending`:
169
+
170
+ ```typescript
171
+ // WRONG - 'pending' is read as a column name -> "column \"pending\" does not exist"
172
+ eb.fn.coalesce("status", "pending")
173
+
174
+ // RIGHT - wrap a literal default in eb.val() (parameterized) ...
175
+ eb.fn.coalesce("status", eb.val("pending"))
176
+ // ... or a typed sql`` literal when you need it inlined (e.g. inside GROUP BY)
177
+ eb.fn.coalesce("status", sql<string>`'pending'`)
178
+
179
+ // Number/boolean/null literals can use eb.lit (eb.lit rejects strings, see
180
+ // expression-builder.md):
181
+ eb.fn.coalesce("score", eb.lit(0))
182
+
183
+ // Coalescing two real COLUMNS is the case where bare strings are correct:
184
+ eb.fn.coalesce("preferred_name", "legal_name") // both are column refs
185
+ ```
186
+
187
+ A companion trap: when you feed a `sql`` fragment as the right-hand operand of a
188
+ typed operator (e.g. a full-text `@@`), the fragment must carry a type parameter
189
+ or it infers `unknown` and the operator overload rejects it:
190
+
191
+ ```typescript
192
+ // WRONG - RawBuilder<unknown> is not a valid operand -> TS2345
193
+ .where("search_vector", "@@", sql`to_tsquery('english', ${q})`)
194
+
195
+ // RIGHT - type the fragment so it satisfies the operator's operand type
196
+ .where("search_vector", "@@", sql<string>`to_tsquery('english', ${q})`)
197
+ ```
198
+