@supacloud/cli 0.29.0 → 0.31.0

package/README.md

@@ -142,6 +142,9 @@ supacloud-cli release postgrest_status --ref abc123
 supacloud-cli release postgrest_restart --ref abc123
 supacloud-cli release release_canary_fixture_stage_replay --ref abc123 \
   --subject <central-subject-uuid> --request_id <stage-request-uuid>
+supacloud-cli release release_canary_fixture_disable_replay --ref abc123 \
+  --fixture_id <fixture-uuid> --disable_request_id <disable-request-uuid> \
+  --issuer <issuer-url> --subject <central-subject-uuid>
 ```
 
 Backup creation reports success only after the CLI verifies exactly one new
@@ -171,6 +174,17 @@ reads the selected project's authoritative endpoint projection and requires the
 configured application origin to match its API origin or alias. Production
 confirmation is mandatory.
 
+`release_canary_fixture_disable_replay` performs one non-retried call to the
+fixed `fa_release_canary_fixture_disable` PostgREST RPC using the selected
+project's application service-role origin. Its receipt must contain exactly
+`fixtureId`, `state="disabled"`, and a boolean `idempotent`; both the first
+disable (`idempotent=false`) and same-request replay (`idempotent=true`) are
+valid. The CLI then calls the existing fixed
+`fa_release_canary_fixture_pending` RPC with only the exact issuer and subject
+query parameters and accepts only its authoritative JSON boolean `false`
+read-back. The fixture binding comes from the validated disable receipt before
+reporting success. Management endpoint projection is checked before and after.
+
 The legacy `.env` fallback is unclassified and therefore does not enable the
 production confirmation gate. Production automation must select a `prod` or
 `production` profile, or set `SUPACLOUD_ENV=production` together with a complete
@@ -218,6 +232,7 @@ supacloud-cli task_events inspect_webhook --ref abc123
 supacloud-cli database query --sql "select now()"
 supacloud-cli database query --ref abc123 --file ./queries/vector-search.sql
 supacloud-cli database migration_inventory --ref abc123
+supacloud-cli database lint_migrations --dir supabase/migrations
 supacloud-cli database push_migrations --ref abc123 --dir supabase/migrations --dry_run
 supacloud-cli supabase migration_new --name add_accounts
 supacloud-cli supabase db_diff --schema public --name add_accounts
@@ -263,6 +278,11 @@ it never empties a bucket. Mutation receipts bind `project_ref`, `bucket_id`,
 name with another version, or a local version with another name, before either
 dry-run reporting or apply can continue. This keeps the preview consistent with
 the server conflict that would otherwise occur after deployment starts.
+`push_migrations` requires canonical string migration identities; the narrower
+`baseline_migrations` compatibility path also accepts historical safe-integer
+versions and normalizes them before comparison. Repeated historical `cli_push`
+names are treated as generic labels; version and exact content remain the
+authority.
 Mutation failures use the release-control receipt schema and never include the
 server response body. `OUTCOME_UNKNOWN` requires a fresh migration inventory
 read before deciding whether a retry is safe. A migration push failure also
@@ -271,6 +291,43 @@ can reconcile a partially completed sequence without exposing SQL. Baseline
 success requires a bounded migration-inventory readback that confirms every
 requested version, name, baseline marker, and checksum.
 
+`database lint_migrations` is local-only and works without Management API
+credentials. Inspect one source with `--sql`, `--file`, or `--dir`; these inputs
+are mutually exclusive. `--strict` (or `--fail_on_high`) exits non-zero for HIGH
+findings, `--fail_on_medium` also fails on MEDIUM findings, and `--json` emits a
+structured report. The analyzer detects destructive DDL (`DROP TABLE`,
+`DROP COLUMN`, `TRUNCATE`, `RENAME`), table-locking risks, opaque `DO` blocks,
+procedural definitions/calls that require manual review, and statements that
+cannot run in the transactional migration executor. Empty migrations,
+unterminated strings/comments/dollar quotes, role or cluster management,
+external database access, server file/process access, transaction-boundary or
+session-identity control, advisory locks, public-schema rename/removal, and
+direct migration-ledger schema, table, recorder, or privilege mutation fail
+before the first remote migration write. Ledger indexes, triggers, rules,
+policies, comments, security labels, and table maintenance commands are covered
+by the same fail-closed rule. Top-level `COPY` is also rejected
+because the HTTP migration executor cannot provide a safe client stream and
+server-file targets cross the project boundary. Unicode-escaped identifiers
+(`U&"..."`) are rejected because the policy cannot safely canonicalize protected
+schema and ledger names. One matching outer `BEGIN`/`COMMIT` wrapper is removed
+because the platform owns the transaction.
+Adding a `NOT NULL` column is assessed per top-level `ALTER TABLE` subcommand;
+function-based defaults remain MEDIUM risk because they may rewrite the table.
+Dry-run exits non-zero for statements the transactional executor cannot apply,
+even when strict destructive-risk mode is not enabled.
+`CREATE/DROP INDEX CONCURRENTLY`, `VACUUM`, and other non-transactional work must
+run through an approved maintenance path outside `push_migrations`.
+
+Migration applications and DDL executions send PostgREST schema reload
+notifications (`NOTIFY pgrst_<ref>, 'reload schema'`) so schema changes become
+visible without a manual PostgREST restart. Responses distinguish `notified`
+from `notification_failed` and include `ddl_committed=true` when the platform
+can prove the DDL committed. Admin SQL with explicit transaction control or
+indirect `CALL`/`DO` execution omits `ddl_committed`; for
+`database create_table_rls`, a committed DDL batch followed by a failed reload
+returns `PARTIAL_SUCCESS` instead of claiming complete success or an unknown DDL
+outcome.
+
 `edge_functions deploy --path` bundles local TypeScript and dependencies with
 Bun and runs a local syntax check before upload. The Management API validates and
 normalizes the final server-side artifact against the multi-tenant Edge Runtime