@cubis/foundry 0.3.10 → 0.3.11

package/Ai Agent Workflow/skills/database-skills/skills/sqlite/references/local-first.md

@@ -1,5 +1,95 @@
-# SQLite Local-First
+# SQLite — Local-First Design
 
-- Fit for mobile, desktop, edge, and embedded services.
-- Design sync and conflict handling explicitly when multi-device.
-- Keep schema migrations deterministic.
+## When SQLite is the right fit
+
+SQLite is the right choice when:
+- Each user has their own private data (mobile app, desktop app, browser extension, edge function).
+- The application needs to work offline with local durability.
+- Data sync is done at the application layer, not the database layer.
+- Simplicity and zero-configuration matter.
+
+SQLite is **not** the right fit for:
+- High-concurrency write workloads with multiple simultaneous writers.
+- Data shared across multiple users in real-time (use Postgres or MySQL instead).
+- Analytics on large datasets (use ClickHouse or DuckDB instead).
+
+## Journal modes — choose WAL for mobile/desktop
+
+The default Rollback Journal blocks all reads during a write. Switch to WAL (Write-Ahead Log) for concurrent reads:
+
+```sql
+PRAGMA journal_mode = WAL;
+-- Persist across connections (set once after DB creation)
+```
+
+WAL mode allows:
+- Multiple simultaneous readers while a write is in progress.
+- Reads don't block writes; writes don't block reads.
+- Slightly better write performance for sequential inserts.
+
+Set `PRAGMA synchronous = NORMAL` with WAL (safe default, faster than `FULL`):
+```sql
+PRAGMA synchronous = NORMAL;
+```
+
+## Migration patterns
+
+Migrations must be deterministic and reversible. Use a migrations table to track applied versions:
+
+```sql
+CREATE TABLE IF NOT EXISTS _migrations (
+  id INTEGER PRIMARY KEY,
+  name TEXT NOT NULL,
+  applied_at TEXT NOT NULL DEFAULT (datetime('now'))
+);
+```
+
+Migration rules:
+- **Never modify an applied migration** — create a new one instead.
+- **Always test on real device storage** — SD cards, old iPhones, and constrained flash behave differently than dev machines.
+- **Include a down migration** (rollback SQL) alongside every up migration.
+- Run migrations inside a transaction so partial failure is safe:
+  ```sql
+  BEGIN;
+  -- migration SQL here
+  INSERT INTO _migrations (id, name) VALUES (3, 'add_notes_column');
+  COMMIT;
+  ```
+
+## Multi-device sync and conflict handling
+
+SQLite has no built-in sync. Design conflict handling explicitly before writing any app code.
+
+Common strategies:
+- **Last-write-wins (LWW)**: each row has `updated_at`. On sync, higher timestamp wins. Simple but loses concurrent edits.
+- **CRDTs**: use conflict-free replicated data types for counters, sets, and ordered lists. Complex but correct.
+- **Event sourcing**: store immutable event log, derive state. Sync events instead of rows.
+- **Vector clocks**: each device has a logical clock; merge based on causal ordering.
+
+Always include a `sync_id` (UUID, globally unique) and `device_id` on every synced row. Never rely on local SQLite `ROWID` or autoincrement as a sync key.
+
+## Offline-first checklist
+
+- [ ] WAL mode enabled on database open.
+- [ ] All writes go through a local queue that syncs when connectivity is available.
+- [ ] Conflict resolution strategy defined before writing sync logic.
+- [ ] Migrations run before any app reads/writes.
+- [ ] Migration history table exists.
+- [ ] UI shows sync status (pending, syncing, error).
+- [ ] Sync tested under: airplane mode, partial connectivity, app killed mid-sync.
+
+## Appropriate use cases
+
+| Use | Verdict |
+| --- | --- |
+| Mobile app local data | ✅ Excellent |
+| Desktop app settings and cache | ✅ Excellent |
+| Embedded IoT / edge data | ✅ Excellent |
+| Read-heavy web server cache | ✅ Good (read-only or low-write) |
+| Multi-user web app backend | ❌ Use Postgres |
+| High-concurrency writes | ❌ Use Postgres or MySQL |
+
+## Sources
+- SQLite appropriate uses: https://sqlite.org/whentouse.html
+- Atomic commit behavior: https://sqlite.org/atomiccommit.html
+- WAL mode: https://sqlite.org/wal.html

package/Ai Agent Workflow/skills/database-skills/skills/sqlite/references/performance.md

@@ -1,5 +1,105 @@
-# SQLite Performance
+# SQLite — Performance Techniques
 
-- Use indexes for repeated filters.
-- Run ANALYZE after significant data shifts.
-- Profile query plans before adding complexity.
+## EXPLAIN QUERY PLAN
+
+Always check the planner before optimizing.
+
+```sql
+EXPLAIN QUERY PLAN
+SELECT * FROM orders WHERE user_id = 1 ORDER BY created_at DESC LIMIT 20;
+```
+
+Key output to read:
+- `SCAN orders` = full table scan — missing or unused index.
+- `SEARCH orders USING INDEX idx_orders_user (user_id=?)` = index seek — good.
+- `USE TEMP B-TREE FOR ORDER BY` = sort can't use the index — add a covering index with the sort column.
+
+## Index design
+
+SQLite uses B-tree indexes. Same leftmost-prefix rules as other SQL databases.
+
+```sql
+-- Equality first, sort last
+CREATE INDEX idx_orders_user_created ON orders (user_id, created_at DESC);
+
+-- Partial index for hot filtered subsets
+CREATE INDEX idx_orders_pending ON orders (user_id, created_at)
+WHERE status = 'pending';
+
+-- Covering index: include projected columns to avoid table fetch
+CREATE INDEX idx_orders_covering ON orders (user_id, status)
+-- SQLite doesn't have INCLUDE, so list all needed columns in the key
+```
+
+SQLite does not support `INCLUDE` columns — put all needed columns in the key if you want index-only reads.
+
+## Write performance — batch in transactions
+
+Every `INSERT`/`UPDATE`/`DELETE` outside a transaction is its own `fsync`. For bulk operations this is catastrophically slow.
+
+```sql
+-- BAD: 1000 individual fsyncs
+INSERT INTO logs VALUES (...);
+INSERT INTO logs VALUES (...);
+-- × 1000
+
+-- GOOD: one fsync
+BEGIN;
+INSERT INTO logs VALUES (...);
+INSERT INTO logs VALUES (...);
+-- × 1000
+COMMIT;
+```
+
+Rule of thumb: batch 100–10,000 rows per transaction. Benchmark for your hardware.
+
+## WAL and checkpoint tuning
+
+With WAL mode (see local-first.md), the WAL file grows until a checkpoint writes it back to the main DB file.
+
+```sql
+PRAGMA wal_autocheckpoint = 1000;   -- checkpoint after 1000 pages (default)
+-- Lower = more frequent checkpoints (less WAL growth, slightly more I/O)
+-- Higher = less frequent (better write throughput, larger WAL file)
+```
+
+Manual checkpoint before a backup:
+```sql
+PRAGMA wal_checkpoint(TRUNCATE);   -- flush WAL and truncate the file
+```
+
+## Memory and cache tuning
+
+```sql
+PRAGMA cache_size = -32000;    -- 32 MB page cache (negative = KB, default = 2MB)
+PRAGMA mmap_size = 268435456;  -- 256 MB memory-mapped I/O (faster reads on large DBs)
+PRAGMA temp_store = MEMORY;    -- keep temp tables in RAM instead of disk
+```
+
+Apply these after every `OPEN` — they are not persisted.
+
+## Seek pagination
+
+```sql
+-- BAD: OFFSET scans and discards N rows
+SELECT * FROM orders ORDER BY id LIMIT 20 OFFSET 10000;
+
+-- GOOD: seek on last seen id
+SELECT * FROM orders WHERE id > :last_seen_id ORDER BY id LIMIT 20;
+```
+
+## Connection management (multi-threaded apps)
+
+SQLite supports one writer at a time. For multi-threaded apps:
+- Use a single write connection with serialized writes.
+- Use a read connection pool (WAL mode allows concurrent readers).
+- Set `PRAGMA busy_timeout = 5000` to wait instead of failing immediately on a locked DB:
+  ```sql
+  PRAGMA busy_timeout = 5000;   -- wait up to 5s before returning SQLITE_BUSY
+  ```
+
+## Sources
+- EXPLAIN QUERY PLAN: https://sqlite.org/eqp.html
+- Query planner: https://sqlite.org/queryplanner.html
+- WAL mode: https://sqlite.org/wal.html
+- PRAGMA reference: https://sqlite.org/pragma.html

package/Ai Agent Workflow/skills/database-skills/skills/supabase/SKILL.md

@@ -1,15 +1,35 @@
 ---
 name: supabase
-description: Supabase/Postgres patterns for RLS, auth-aware schema, pooling, and safe migrations.
+description: Supabase/Postgres patterns for RLS, indexing, query optimization, pooling, and safe migrations.
 ---
 
 # Supabase
 
-Load references as needed:
+## Optimization workflow
+
+1. Confirm RLS policy shape and index policy predicates.
+2. Analyze query plans and use index advisor workflow.
+3. Choose proper connection mode (direct/session/transaction pooler).
+4. Use keyset pagination for heavy list endpoints.
+5. Include migration/rollback with version-awareness (managed vs self-hosted differences).
+
+## Indexing and RLS techniques
+
+- Index columns referenced by RLS policies.
+- Index join/filter columns used by API queries.
+- Remove redundant indexes that inflate write cost.
+
+## Pagination techniques
+
+- Prefer keyset pagination on stable, indexed sort columns.
+- Avoid blind offset scans on large tables.
+
+## Operational guardrails
+
+- Validate Supavisor mode based on runtime behavior.
+- Confirm compatibility when moving between managed and self-hosted environments.
+
+## References
+
 - `references/rls-auth.md`
 - `references/performance-operations.md`
-
-Key rules:
-- Enforce tenant/user boundaries with RLS.
-- Index policy predicates and hot query paths.
-- Validate policies in staging before production rollout.

package/Ai Agent Workflow/skills/database-skills/skills/supabase/references/performance-operations.md

@@ -1,5 +1,95 @@
-# Supabase Performance and Operations
+# Supabase — Query Performance and Connection Operations
 
-- Use pooled connections from app runtimes.
-- Track slow queries and remove N+1 behavior.
-- Keep migrations versioned and reversible.
+## Query optimization workflow
+
+1. Identify slow queries via Supabase Dashboard → Database → Query Performance (uses `pg_stat_statements`).
+2. Run `EXPLAIN (ANALYZE, BUFFERS)` on the slow query to read the actual plan.
+3. Check for: `Seq Scan` on large tables, `Sort` without index, high `Rows Removed by Filter` ratio.
+4. Add targeted index and re-test.
+
+```sql
+-- From the SQL editor in Supabase Dashboard
+EXPLAIN (ANALYZE, BUFFERS, FORMAT TEXT)
+SELECT * FROM orders WHERE user_id = 'abc' ORDER BY created_at DESC LIMIT 20;
+```
+
+## Database Advisors
+
+Supabase runs automated advisors that flag common issues. Check Dashboard → Database → Advisors for:
+- **Unused indexes**: indexes with zero scans — drop them.
+- **Unindexed foreign keys**: FKs without an index cause full scans on joins and cascades.
+- **Seq scans on large tables**: tables being full-scanned when an index would help.
+- **Bloated tables**: high dead tuple ratio — may need `VACUUM`.
+
+```sql
+-- Manual unused index check
+SELECT schemaname, relname, indexrelname, idx_scan
+FROM pg_stat_user_indexes
+WHERE idx_scan = 0 AND schemaname = 'public'
+ORDER BY relname;
+```
+
+## Connection modes and when to use each
+
+Supabase provides three connection methods:
+
+| Mode | How | Use for |
+| --- | --- | --- |
+| **Direct** | `postgresql://...` port 5432 | Long-lived connections (background jobs, migrations) |
+| **Transaction pooler** (PgBouncer) | Port 6543 | Serverless functions, edge functions, short-lived requests |
+| **Session pooler** | Port 5432 alt | When you need session-level features (prepared statements, `SET`) |
+
+**Serverless / Edge Functions**: always use the transaction pooler (6543). Direct connections from serverless cold starts exhaust Postgres connection limits fast.
+
+```ts
+// Supabase JS — uses transaction pooler automatically when using the client library
+const supabase = createClient(url, anonKey);
+
+// Direct connection for migrations / background jobs (Prisma, Drizzle, etc.)
+DATABASE_URL=postgresql://user:pass@db.xxx.supabase.co:5432/postgres
+// Transaction pooler for Prisma in serverless
+DATABASE_URL=postgresql://user:pass@db.xxx.supabase.co:6543/postgres?pgbouncer=true
+```
+
+## Prepared statements and pooling
+
+PgBouncer in transaction mode does **not** support prepared statements — they are per-session. If your ORM uses prepared statements (Prisma does by default):
+
+```
+# Prisma — disable prepared statements when using transaction pooler
+DATABASE_URL="...?pgbouncer=true&connection_limit=1"
+# Or in schema.prisma:
+datasource db {
+  url = env("DATABASE_URL")
+  directUrl = env("DIRECT_URL")  # direct connection for migrations
+}
+```
+
+## Realtime performance considerations
+
+Supabase Realtime uses Postgres logical replication. High-volume tables with Realtime enabled generate significant WAL traffic.
+
+- Enable Realtime only on tables that clients actually subscribe to.
+- Filter subscriptions as tightly as possible: `channel.on('postgres_changes', { filter: 'user_id=eq.123' }, ...)`.
+- Monitor replication slot lag in Dashboard → Database → Replication.
+
+## Extensions useful for performance
+
+```sql
+-- Query statistics (enabled by default in Supabase)
+SELECT * FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;
+
+-- Index usage stats
+SELECT * FROM pg_stat_user_indexes ORDER BY idx_scan ASC;
+
+-- Table bloat estimate
+SELECT relname, n_dead_tup, n_live_tup, last_autovacuum
+FROM pg_stat_user_tables
+ORDER BY n_dead_tup DESC;
+```
+
+## Sources
+- Query optimization guide: https://supabase.com/docs/guides/database/query-optimization
+- Database advisors: https://supabase.com/docs/guides/database/database-advisors
+- Connecting to Postgres (poolers): https://supabase.com/docs/guides/database/connecting-to-postgres
+- pg_stat_statements: https://www.postgresql.org/docs/current/pgstatstatements.html

package/Ai Agent Workflow/skills/database-skills/skills/supabase/references/rls-auth.md

@@ -1,5 +1,106 @@
-# Supabase RLS and Auth
+# Supabase — Row Level Security and Auth Performance
 
-- Keep policies simple and explicit.
-- Validate read and write paths for each role.
-- Avoid exposing privileged credentials client-side.
+## Enable RLS on every exposed table
+
+Any table exposed via the Supabase Data API (PostgREST) or Realtime must have RLS enabled. Without it, all authenticated users can access all rows.
+
+```sql
+ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
+ALTER TABLE orders FORCE ROW LEVEL SECURITY;  -- applies to table owner too
+```
+
+## Policy fundamentals
+
+A policy is a `WHERE` predicate automatically appended to every query on the table.
+
+```sql
+-- Users can only see their own orders
+CREATE POLICY "users can read own orders"
+  ON orders FOR SELECT
+  USING (user_id = auth.uid());
+
+-- Users can only insert rows for themselves
+CREATE POLICY "users can insert own orders"
+  ON orders FOR INSERT
+  WITH CHECK (user_id = auth.uid());
+
+-- Separate policies for read vs write
+-- SELECT: use USING()
+-- INSERT: use WITH CHECK()
+-- UPDATE: use both USING() (which rows to target) + WITH CHECK() (what values are allowed)
+-- DELETE: use USING()
+```
+
+## auth.uid() and auth.jwt()
+
+Supabase injects the authenticated user context via:
+- `auth.uid()` — UUID of the current user (`auth.users.id`).
+- `auth.jwt()` — full JWT payload as JSONB. Access claims: `auth.jwt() ->> 'role'`, `(auth.jwt() -> 'user_metadata') ->> 'org_id'`.
+
+```sql
+-- Role-based policy using JWT claims
+CREATE POLICY "admins can read all orders"
+  ON orders FOR SELECT
+  USING (auth.jwt() ->> 'user_role' = 'admin');
+
+-- Multi-tenant: org_id from metadata
+CREATE POLICY "org members can read org orders"
+  ON orders FOR SELECT
+  USING (org_id = (auth.jwt() -> 'user_metadata' ->> 'org_id')::uuid);
+```
+
+## Index policy predicate columns
+
+**RLS policies are evaluated per row.** If the policy predicate isn't indexed, every query scans the full table before filtering.
+
+```sql
+-- Policy uses user_id — must have an index on it
+CREATE INDEX idx_orders_user_id ON orders (user_id);
+
+-- Policy uses org_id — same rule
+CREATE INDEX idx_orders_org_id ON orders (org_id);
+```
+
+For composite queries: `(user_id, status)`, `(org_id, created_at)`.
+
+## Bypassing RLS for service-role operations
+
+Backend code using the `service_role` key bypasses RLS — useful for admin operations, but dangerous if leaked. Never expose `service_role` to client code.
+
+```sql
+-- Explicitly bypass RLS in a function running as superuser
+CREATE FUNCTION admin_get_all_orders()
+RETURNS SETOF orders
+SECURITY DEFINER  -- runs as function owner (bypasses RLS)
+SET search_path = public
+LANGUAGE sql AS $$
+  SELECT * FROM orders;
+$$;
+```
+
+## Measuring policy overhead
+
+```sql
+-- Compare query time with and without RLS
+EXPLAIN (ANALYZE, BUFFERS)
+SELECT * FROM orders WHERE status = 'pending' LIMIT 20;
+
+-- Check if planner inlines auth.uid() correctly (it should appear in the plan)
+```
+
+Benchmark list endpoints that have RLS policies after every policy change — policy complexity directly impacts query time.
+
+## Common RLS mistakes
+
+| Mistake | Fix |
+| --- | --- |
+| No policy defined but RLS enabled | Default deny — no rows returned; add explicit policies |
+| Policy predicate column not indexed | Add index on policy column |
+| Using `auth.uid()` in `WITH CHECK` but not `USING` | UPDATE policy needs both |
+| Relying solely on app-layer filtering | Always enforce with RLS even if app also filters |
+| `service_role` key used in client | Switch to `anon` or `authenticated` key with RLS |
+
+## Sources
+- Row Level Security: https://supabase.com/docs/guides/database/postgres/row-level-security
+- Supabase auth helpers: https://supabase.com/docs/guides/auth
+- PostgreSQL RLS docs: https://www.postgresql.org/docs/current/ddl-rowsecurity.html

package/Ai Agent Workflow/skills/database-skills/skills/vitess/SKILL.md

@@ -1,15 +1,35 @@
 ---
 name: vitess
-description: Vitess and sharded MySQL planning, VSchema, routing, and online schema migration concerns.
+description: Vitess sharding strategy, VSchema/vindex design, routing, and scale operations.
 ---
 
 # Vitess
 
-Load references as needed:
+## Primary focus
+
+- Choose a strong primary vindex.
+- Keep hot queries shard-local.
+- Minimize cross-shard joins and transactions.
+
+## Optimization workflow
+
+1. Identify dominant access patterns and routing keys.
+2. Design VSchema/vindex for locality and balanced distribution.
+3. Validate routing/fan-out behavior on critical queries.
+4. Use seek pagination anchored on routing key and tie-breaker.
+5. Stage topology/resharding changes with rollback checkpoints.
+
+## Pagination techniques
+
+- Prefer shard-aware keyset pagination.
+- Avoid broad fan-out + offset combinations.
+
+## Operational guardrails
+
+- Treat resharding as staged production operation.
+- Monitor fan-out, replica lag, and failover behavior during topology changes.
+
+## References
+
 - `references/sharding-routing.md`
 - `references/operational-safety.md`
-
-Key rules:
-- Model entity ownership before keyspace/shard strategy.
-- Avoid cross-shard patterns unless explicitly required.
-- Plan online schema changes with observability checkpoints.

package/Ai Agent Workflow/skills/database-skills/skills/vitess/references/operational-safety.md

@@ -1,5 +1,105 @@
-# Vitess Operational Safety
+# Vitess — Online DDL and Operational Safety
 
-- Stage schema changes and monitor replication lag.
-- Include fallback plan for routing or migration regressions.
-- Verify SLA metrics after each rollout phase.
+## Online DDL strategies
+
+Vitess manages schema changes as tracked, non-blocking, revertible migrations. This is the **only recommended approach** for production schema changes.
+
+Set DDL strategy per session or globally:
+```sql
+SET @@ddl_strategy = 'vitess';
+```
+
+| Strategy | Description |
+| --- | --- |
+| `vitess` (**recommended**) | VReplication-based. Non-blocking, revertible, failover-safe. |
+| `online` | Alias for `vitess`. |
+| `mysql` | Native MySQL DDL managed by Vitess scheduler. Blocking depends on the DDL. |
+| `direct` | Unmanaged — direct DDL to MySQL. Not trackable. Avoid in production. |
+
+## Running a migration
+
+```sql
+SET @@ddl_strategy = 'vitess';
+ALTER TABLE orders ADD COLUMN notes TEXT;   -- returns migration UUID immediately
+```
+
+```bash
+vtctldclient ApplySchema --ddl-strategy "vitess" \
+  --sql "ALTER TABLE orders ADD COLUMN notes TEXT" commerce
+```
+
+## Migration lifecycle
+
+```
+queued → ready → running → complete
+                         ↘ failed
+         ↘ cancelled
+```
+
+## Monitor and control migrations
+
+```sql
+SHOW VITESS_MIGRATIONS;                                         -- all migrations
+SHOW VITESS_MIGRATIONS LIKE '<uuid>';                           -- specific migration
+```
+
+Key columns to watch: `migration_status`, `progress`, `started_timestamp`, `completed_timestamp`, `message`.
+
+```sql
+ALTER VITESS_MIGRATION '<uuid>' CANCEL;    -- cancel pending
+ALTER VITESS_MIGRATION '<uuid>' RETRY;     -- retry failed
+ALTER VITESS_MIGRATION '<uuid>' COMPLETE;  -- complete a postponed migration
+ALTER VITESS_MIGRATION '<uuid>' LAUNCH;    -- launch a postponed migration
+REVERT VITESS_MIGRATION '<uuid>';          -- revert a completed migration (non-destructive)
+```
+
+## Key DDL strategy flags
+
+Append flags to strategy string:
+```sql
+SET @@ddl_strategy = 'vitess --postpone-completion --allow-concurrent';
+```
+
+| Flag | Effect |
+| --- | --- |
+| `--postpone-launch` | Queue migration but don't start automatically |
+| `--postpone-completion` | Run migration but don't cut over — you control timing |
+| `--allow-concurrent` | Allow multiple migrations to run simultaneously |
+| `--declarative` | Provide desired `CREATE TABLE`; Vitess computes the ALTER |
+| `--prefer-instant-ddl` | Use MySQL INSTANT DDL when possible |
+| `--singleton` | Only one migration on this table at a time |
+
+## Declarative migrations
+
+Supply the desired schema; Vitess computes the diff and runs the minimal ALTER:
+```sql
+SET @@ddl_strategy = 'vitess --declarative';
+CREATE TABLE demo (id BIGINT UNSIGNED NOT NULL, status VARCHAR(32), PRIMARY KEY (id));
+```
+
+## Throttling and failover safety
+
+- The **tablet throttler** automatically slows migrations when replication lag is high.
+  Enable: `vtctldclient UpdateThrottlerConfig --enable <keyspace>`
+- VReplication-based migrations **auto-resume** after primary reparenting (new primary must come up within 10 min).
+
+## Operational guardrails
+
+- **Stage topology and resharding changes** in maintenance windows; keep blast radius small per operation.
+- **Watch fan-out and replication lag** as release gates — do not proceed if lag is elevated.
+- **Prepare explicit rollback procedures per shard move**: `MoveTables SwitchTraffic --reverse`, then `MoveTables Complete` on the old keyspace.
+- Validate with `VDiff` before completing table moves: `vtctldclient VDiff <keyspace> <workflow>`.
+- Test resharding end-to-end on staging with production-like data volume before production.
+
+## Best practices
+
+1. Always use `vitess` strategy in production — never `direct`.
+2. Use `--postpone-completion` for critical tables to control cut-over timing precisely.
+3. Enable the tablet throttler to prevent replication lag buildup.
+4. Use declarative migrations for desired-state schema management.
+5. Monitor all running migrations with `SHOW VITESS_MIGRATIONS` before and after deployments.
+
+## Sources
+- Online DDL guide: https://vitess.io/docs/user-guides/schema-changes/
+- VReplication reference: https://vitess.io/docs/reference/vreplication/
+- Release notes / lifecycle: https://vitess.io/docs/releases/