@gallopsystems/agent-skills 1.12.0 → 1.13.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gallopsystems/agent-skills",
-  "version": "1.12.0",
+  "version": "1.13.0",
   "description": "Gallop Systems agent skills, symlinked into .claude/skills (Claude Code) and .agents/skills (Codex) on install.",
   "license": "UNLICENSED",
   "repository": {

package/plugins/doctl/skills/doctl/other-services.md

@@ -10,7 +10,9 @@ doctl databases ca <db-id>                                    # cluster CA certi
 
 - **The connection URI contains live credentials** — treat command output as a secret. Don't echo it into logs; pipe it directly to where it's needed.
 - **Check `Version`** and keep CI/local database versions in sync with production — a test suite running `postgres:15` against a pg-18 production cluster hides version-specific behavior.
-- Connections use port 25060 with `sslmode=require`. **TLS trap**: some clients (e.g. newer `pg-connection-string`) silently upgrade `require` to `verify-full`, which rejects DO's CA under the default trust store. Fix: supply the CA from `doctl databases ca <db-id>` explicitly, or configure ssl options in code rather than relying on the URI.
+- Connections use port 25060 with `sslmode=require`. **TLS trap**: some clients (e.g. `pg-connection-string` as bundled with `pg` >= 8.16) silently treat `require` as `verify-full`, which rejects DO's self-signed CA under the default trust store (`SELF_SIGNED_CERT_IN_CHAIN`). Two non-obvious parts:
+  - **An ssl option set in code does NOT override an `sslmode` already in the URI.** Passing `ssl: { rejectUnauthorized: false }` while the connection string still ends in `?sslmode=require` keeps failing — the URI's `sslmode` wins. The fix has to land in the URI itself: drop/replace `sslmode`, append `uselibpqcompat=true` (restores libpq semantics: encrypt but don't verify), or supply the CA from `doctl databases ca <db-id>` explicitly.
+  - **When you can't edit the URI** — specifically, when you bind App Platform's generated `${db.DATABASE_URL}` straight into an env var in the app spec, it always carries `?sslmode=require` and you don't author the string — append the param to the bound value: `value: ${db.DATABASE_URL}&uselibpqcompat=true`. This only applies to that bound-pipethrough case; if you declare the connection-string env var yourself, just put the right params (or none) in from the start and an in-code ssl option is enough.
 
 ## Spaces
 

package/plugins/kysely-postgres/skills/kysely-postgres/SKILL.md

@@ -964,6 +964,53 @@ await db.schema.createIndex("idx_order_user_id").on("order").column("user_id").e
 .addColumn("price", sql`numeric(10, 2)`)
 ```
 
+### Migration Ordering Is Append-Only — Out-of-Order Timestamps Break Prod Deploys
+
+Kysely's migrator enforces a **strict append-only ledger**: it refuses to run any
+unexecuted migration whose timestamp sorts *before* the last-executed one
+(throwing `Corrupted migrations: previously executed migration ... is missing`).
+This bites when two branches each add a migration, and the one that merges *second*
+carries the *earlier* timestamp:
+
+```
+branch A merges first  → 1700000200000_drop_thing      (runs in prod)
+branch B merges second → 1700000100000_add_table       (timestamp is EARLIER)
+                       → 1700000100001_add_column
+```
+
+Prod has already recorded `...200000_drop_thing` as executed. On the next deploy
+the `migrate` job sees two pending migrations that sort *before* it, throws
+"Corrupted migrations", and **exits non-zero**. If migrations run as a pre-deploy
+job (common on PaaS like DigitalOcean App Platform), the failed job fails the whole
+deploy and the platform **auto-rolls-back to the previous image** — so prod silently
+stays on stale code and every subsequent deploy fails the same way. A self-reinforcing
+loop that looks like a deploy/token problem but is really a migration-ledger problem.
+
+**Prevent it:** before merging a long-lived branch, check whether `main` has merged
+any migration with a *later* timestamp than yours. If so, regenerate your migration's
+timestamp so it sorts last (`migrate:make` again, or rename the file) **before it
+merges** — only safe while the migration has not yet run in any shared DB. Never
+re-stamp a migration that prod has already executed; that forces it to re-run.
+
+**Fix it once prod is wedged:** reconcile the ledger so the executed set is a clean
+*prefix* again, then let the normal strict migrate job run. Do **not** reach for
+`allowUnorderedMigrations: true` — it works (kysely-ctl spreads the `migrations`
+config into the `Migrator`), but it permanently weakens the ordering guard to paper
+over one bad state. Instead, surgically remove the prematurely-recorded row from the
+migration ledger table (default `kysely_migration`):
+
+```sql
+-- prod ledger has the later-timestamp migration recorded, blocking the two earlier ones
+DELETE FROM kysely_migration WHERE name = '1700000200000_drop_thing';
+```
+
+Now `add_table → add_column → drop_thing` are all pending in true timestamp order, and
+the next deploy's strict migrate job applies them cleanly. This only works when the
+removed migration is **idempotent to re-run** (e.g. a `dropTable`/`dropColumn` written
+with `ifExists`, so re-applying it after the others is a safe no-op). Verify the
+ledger is a contiguous prefix after the DELETE, and prefer letting the deploy's own
+migrate job re-apply rather than running migrations from a laptop against prod.
+
 ## Type Generation
 
 Use `kysely-codegen` to generate types from your database: