stash init --drizzle is the only flow still provisioning an EQL v2 database. A bare stash eql install and init for every other integration already default to v3.
packages/cli/src/commands/init/steps/install-eql.ts:103
eqlVersion: drizzle ? '2' : undefined,
The pin's stated reason — "the Drizzle migration path is v2-only" — stopped being true when stash eql migration --drizzle shipped (#690). skills/stash-drizzle/SKILL.md didn't just document the pin, it justified it with the same now-false claim.
The pin was causing the mismatch it appeared to prevent
Init installs stash-encryption, stash-drizzle and stash-cli into the customer's repo, and both content skills are fully v3 — they teach EncryptionV3, types.*, and public.eql_v3_*. So init --drizzle handed the customer's coding agent v3 guidance against a v2 database it had just provisioned. Every new Drizzle customer running stash init was being put on the generation slated for removal (#707).
Why it's more than flipping the flag
routeInstallPathForEqlVersion forces drizzle: false under v3, so a bare flag flip would have silently converted Drizzle projects to a direct install and lost their migration history. The fix routes init's Drizzle branch through eqlMigrationCommand({ drizzle: true, embedded: true }) — v3 SQL, still migration-first.
Fix
PR #705. Also fixes eql install --drizzle's rejection message, which was actively steering users to --eql-version 2. install-eql.test.ts goes from 5 tests to 11, including a regression guard on the v2 pin.
Follow-up (not in this PR)
generatePlaceholderClient emits v2 pattern comments and Encryption({ schemas: [] }) for all integrations, not just Drizzle — so Supabase and plain-Postgres init already ship a v3 database with a v2 placeholder client. Pre-existing and broader than this fix; self-contained (two string constants plus commands/schema/build.ts).
stash init --drizzleis the only flow still provisioning an EQL v2 database. A barestash eql installand init for every other integration already default to v3.The pin's stated reason — "the Drizzle migration path is v2-only" — stopped being true when
stash eql migration --drizzleshipped (#690).skills/stash-drizzle/SKILL.mddidn't just document the pin, it justified it with the same now-false claim.The pin was causing the mismatch it appeared to prevent
Init installs
stash-encryption,stash-drizzleandstash-cliinto the customer's repo, and both content skills are fully v3 — they teachEncryptionV3,types.*, andpublic.eql_v3_*. Soinit --drizzlehanded the customer's coding agent v3 guidance against a v2 database it had just provisioned. Every new Drizzle customer runningstash initwas being put on the generation slated for removal (#707).Why it's more than flipping the flag
routeInstallPathForEqlVersionforcesdrizzle: falseunder v3, so a bare flag flip would have silently converted Drizzle projects to a direct install and lost their migration history. The fix routes init's Drizzle branch througheqlMigrationCommand({ drizzle: true, embedded: true })— v3 SQL, still migration-first.Fix
PR #705. Also fixes
eql install --drizzle's rejection message, which was actively steering users to--eql-version 2.install-eql.test.tsgoes from 5 tests to 11, including a regression guard on the v2 pin.Follow-up (not in this PR)
generatePlaceholderClientemits v2 pattern comments andEncryption({ schemas: [] })for all integrations, not just Drizzle — so Supabase and plain-Postgres init already ship a v3 database with a v2 placeholder client. Pre-existing and broader than this fix; self-contained (two string constants pluscommands/schema/build.ts).