@supacloud/cli 0.65.1 → 0.66.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@supacloud/cli",
-  "version": "0.65.1",
+  "version": "0.66.0",
   "description": "Project-scoped CLI for SupaCloud users",
   "type": "module",
   "main": "./dist/index.js",
@@ -35,14 +35,14 @@
   },
   "dependencies": {
     "@sinclair/typebox": "^0.34.52",
-    "@supacloud/compiler": "^0.34.0",
-    "@supacloud/delivery": "0.7.0",
+    "@supacloud/compiler": "^0.36.0",
+    "@supacloud/delivery": "0.8.0",
     "@supacloud/db": "^0.2.0",
     "fflate": "^0.8.3",
     "typebox": "1.3.34"
   },
   "overrides": {
-    "@supacloud/delivery": "0.7.0"
+    "@supacloud/delivery": "0.8.0"
   },
   "devDependencies": {
     "@supacloud/elysia": "^0.23.1",

package/skills/supacloud-cli/SKILL.md

@@ -71,6 +71,14 @@ Use `db_diff` as an authoring aid, not as permission to bypass review:
 supacloud-cli supabase db_diff --schema public --name reconcile_public_schema
 ```
 
+For existing declarative SQL projects, `supabase db_schema_declarative_sync`
+generates without applying by default. Preserve the repository's schema authority
+and review the migration before any apply. `config_pull` previews official
+Supabase configuration, not SupaCloud Management settings. Native local stacks
+remain alpha and require `SUPACLOUD_ENABLE_NATIVE_STACK=1`; do not silently switch
+an existing Docker workflow. Lite drift pull writes drafts by default; only use
+`--baseline` for reviewed DDL already present in the live local state.
+
 For a database that was previously changed directly, stop further direct writes and follow the reconciliation workflow in [references/database-workflow.md](references/database-workflow.md). Do not push guessed historical migrations against a live database. After schema equivalence is proven, preview and record the baseline through:
 
 ```bash

package/skills/supacloud-cli/references/command-map.md

@@ -13,6 +13,12 @@ Load this reference when selecting a command surface or when a user asks an AI t
 | Read database rows or metadata | `database query` and database inspection actions | `SELECT`/read-only by default |
 | Create schema/function/RPC/trigger/RLS/index/grant/extension | `supabase migration_new`, then edit SQL | Never direct remote DDL |
 | Generate migration from local schema changes | `supabase db_diff` | Review generated SQL before use |
+| Generate migration from declarative SQL | `supabase db_schema_declarative_sync` | Defaults to no-apply; preserve an existing Drizzle/schema authority |
+| Capture declarative schema files | `supabase db_schema_declarative_generate` | Explicit DSN or upstream linked project; overwrite requires approval |
+| Pull official Supabase configuration | `supabase config_pull` | Preview by default; local write requires `dry_run=false` and `yes`; not SupaCloud settings |
+| Run the official local stack | `supabase stack_start`, `stack_prepare`, `stack_status`, `stack_stop` | Docker default; native alpha requires `SUPACLOUD_ENABLE_NATIVE_STACK=1` |
+| Remove the official local stack | `supabase stack_destroy` | Local data loss; requires `confirm_destroy` and `yes` |
+| Capture Lite drift | `lite db_diff`, `lite db_pull` | Draft outside migrations; only reviewed already-present DDL may use `baseline` |
 | Rebuild local database | `supabase db_reset` | Local only; preserve required seed behavior |
 | Inspect or back up a remote database | `supabase db_pull`, `migration_list`, `db_dump`, `gen_types` | Requires explicit PostgreSQL DSN; redact it |
 | Replay the release-canary fixture stage receipt | `release release_canary_fixture_stage_replay` | Dual-bind Management project context and that project's service-role application origin; accepts only the exact subject/request UUID pair and a strict idempotent receipt |
@@ -36,7 +42,8 @@ until a project-scoped context is resolved.
 - `status`: resolved context, Management API connectivity, authentication, and project reachability.
 - `project`: selected-project metadata, authoritative endpoint projection, health, logs, API keys/settings, background tasks, retry/cancel, DLQ, and background settings. `project list` deliberately redirects to `supacloud-admin`; cross-project enumeration is not a project CLI capability.
 - `database`: read/query, schema inspection, extensions, indexes, RLS, stats, migration push, controlled historical baseline, and SQL-file execution.
-- `supabase`: allowlisted official CLI adapter for migration authoring, local reset/diff, explicit-DSN inspection/backup/type generation, and SupaCloud-controlled migration push.
+- `supabase`: allowlisted official CLI adapter for initialization, declarative authoring, config pull, local stacks, reset/diff, explicit-DSN inspection/backup/type generation, and SupaCloud-controlled migration push.
+- `lite`: local-only Lite runtime, schema authoring and snapshot operations; never reinterpret PGlite state as a Postgres DSN.
 - `auth`: provider/configuration plus bounded user lookup and production-confirmed `magiclink`, `recovery`, or `invite` generation. Search/email/redirect inputs and returned action URLs are bounded and validated before use.
 - `storage`: buckets and object-management workflows.
 - `edge_functions`: list, atomically read one active or deleted identity with `get_config`, read immutable source, deploy, activate, configure, and delete Edge Functions. For every mutation, pass the `activation_id` read from the same `list` or `get_config` snapshot as `--expected-activation-id`; use `legacy` only for a never-created or listed legacy Function, not for a deleted slug with a tombstone UUID. Deploy and activate actions also require the non-negative observed version as `--expected-active-version`; use `absent` for a never-created slug or a `get_config` tombstone. Version `0` is a legacy version token and cannot be used as a source or activation target.

package/skills/supacloud-cli/references/database-workflow.md

@@ -32,6 +32,26 @@ Migration files are the durable source of truth. `supabase_migrations.schema_mig
 
 7. After explicit environment approval, apply and read back migration history.
 
+## Declarative authoring option
+
+Preserve the repository's existing schema authority. In a project already using
+declarative SQL, edit those files and run:
+
+```bash
+supacloud-cli supabase db_schema_declarative_sync --name <intent> --strict_coverage
+```
+
+The adapter defaults to no-apply. Review the generated migration, then use the
+same local verification and controlled remote push steps above. Do not introduce
+a second declarative source over Drizzle-generated schemas. Verify the installed
+official CLI supports this experimental command before changing project config.
+
+`supabase config_pull` previews official Supabase settings. Applying that local
+file requires `--dry_run=false --yes`; a configured context must match the
+requested project ref. Keep secrets and environment-specific changes out of
+commits. The adapter filters inherited credentials but does not sandbox upstream
+saved logins or dotenv files.
+
 ## Previously changed remote database
 
 Do not fabricate old migration files and immediately push them. Reconcile deliberately:
@@ -76,6 +96,15 @@ Do not fabricate old migration files and immediately push them. Reconcile delibe
 10. Never insert/update/delete `supabase_migrations.schema_migrations` via `database query`. If the controlled baseline action cannot represent the verified state, stop and request operator assistance.
 11. Run `supabase push --dry_run`; it should report no unintended pending historical migration. Read back migration history and affected objects.
 
+## Lite drift
+
+For Lite, `lite db_pull` writes drafts outside migrations and does not silently
+change the ledger. The explicit `--baseline` action records already-present
+reviewed DDL without replaying it. Stop on pending history, unsupported catalog
+drift or shadow replay mismatch. Retain `.sql.pending` files after an uncertain
+baseline and verify the ledger before publishing or retrying; never guess commit
+state or restart into captured DDL that has not been baselined.
+
 ## Functions, triggers, RLS, and grants
 
 These are schema objects even when business logic lives inside them. Keep them in migrations: