naro-cli 0.23.0 → 0.25.0

package/dist/commands/confirm.d.ts

@@ -8,5 +8,15 @@ export declare function cannotAsk(context: CommandContext): boolean;
  * Gate for destructive actions. Throws instead of silently returning so a
  * declined/unavailable confirmation is a real failure (exit 1, structured
  * JSON) — CI must never read "nothing happened" as success.
+ *
+ * What asks: removing or deleting something (`remove`, `delete`, `realtime
+ * tables remove`), and a change that reaches past the value typed — what
+ * production serves (`promote`, `rollback`, `cancel`), keys that stop working
+ * (`backend keys rotate`, `signing-key rotate`), a service turned off
+ * (`storage disable`), who can see the project (`protection disable`), or an
+ * address given up (`project set --subdomain`, `dns records update`). Adding
+ * or switching a setting whose value the person typed in full (`naro firewall
+ * add`, `naro flags on`) does not ask: MCP marks those destructive because no
+ * one watches its calls (PR #429 and #433 reviews).
  */
 export declare function confirmOrAbort(context: CommandContext, question: string): Promise<void>;

package/dist/commands/db-lint.d.ts

@@ -0,0 +1,16 @@
+import type { CommandContext } from "../context";
+export { DIAGNOSTICS_SQL, lintDatabase, POLICY_READ_SQL, POLICY_TABLE_PROBE, type DatabaseLint, } from "@next-deploy/sdk";
+/**
+ * `naro db lint [--json] [--strict]` — read-only diagnostics over the schema
+ * `GET /tables` describes and the checks D1 allows. The rules are the ones D1
+ * actually trips on (spec §17.3); there is no performance heuristic, because
+ * D1 keeps no execution statistics to base one on.
+ *
+ * A project with a backend also gets its row-level security checked: a table
+ * with no policy is a warning (the Data API refuses every request to it) and a
+ * policy that cannot work on today's schema is an error (spec P2-7b).
+ *
+ * The exit code is the point: an error fails the run so CI can gate on it, a
+ * warning does not unless `--strict` says it should.
+ */
+export declare function runDbLint(context: CommandContext): Promise<void>;

package/dist/deploy.d.ts

@@ -112,4 +112,6 @@ export interface DeployResult {
  * Shared by `naro deploy` and the MCP `deploy` tool.
  */
 export declare function deployDirectory(sourceDir: string, options: DeployOptions, log: (message: string) => void): Promise<DeployResult>;
+export { lintDatabase, type DatabaseLint } from "./commands/db-lint";
+export { readCapped } from "./functions/read-capped";
 export { assertFunctionsNode, deployFunctions, type DeployedFunction, type DeployFunctionsOptions, type DeployFunctionsResult, } from "./functions/deploy";

package/dist/deploy.js

@@ -4,20 +4,24 @@ import {
   deployDirectory,
   deployFunctions,
   eventsObserver,
+  lintDatabase,
   localDependencies,
   parseDotenv,
+  readCapped,
   readProjectEnv,
   slugify,
   workingTreeNotices
-} from "./chunk-ALK4VTL2.js";
+} from "./chunk-X5TUBMEU.js";
 import "./chunk-K3NQKI34.js";
 export {
   assertFunctionsNode,
   deployDirectory,
   deployFunctions,
   eventsObserver,
+  lintDatabase,
   localDependencies,
   parseDotenv,
+  readCapped,
   readProjectEnv,
   slugify,
   workingTreeNotices

package/dist/env-services.d.ts

@@ -0,0 +1,44 @@
+/**
+ * Which outside service the env keys a deploy is missing belong to, and where
+ * that service keeps their values.
+ *
+ * The deploy already works out the names it needs by scanning the source
+ * (`scanEnvReferences`), but a list of bare names only helps someone who
+ * already knows where each value comes from. The first thing anyone moving an
+ * existing app here hits is exactly that gap: the app talks to a Supabase
+ * project that is already running, and the deploy asks for
+ * `NEXT_PUBLIC_SUPABASE_URL` without saying it is asking for something they
+ * have in another browser tab.
+ *
+ * This only names the service and the screen its values are on. Nothing here
+ * reaches Supabase's API, stores a token or creates anything there — the
+ * values still arrive the way every other env var does, from `.env.local`
+ * with the user's consent or from `naro env add`.
+ */
+/** The key without that prefix. The longest match wins, so order is free. */
+export declare function bareEnvKey(key: string): string;
+/**
+ * The given keys that name a Supabase project, in the order given.
+ *
+ * Everything Supabase hands a project is `SUPABASE_*`: the project URL, the
+ * publishable and secret keys, the legacy `anon` and `service_role` keys, the
+ * JWT secret, the account's access token, the database password. Matching the
+ * prefix rather than a fixed list keeps a name we have not seen — Supabase
+ * renamed its keys once already — from dropping out. A name that merely
+ * contains the word (`MY_SUPABASE_URL`) is not one of theirs.
+ *
+ * Belonging to Supabase is not the same as being on one of the screens
+ * `envServiceHints` knows; that function decides which of these it can place.
+ */
+export declare function supabaseKeys(keys: readonly string[]): string[];
+/**
+ * Lines naming the service the missing keys belong to, to print under the
+ * "env var(s) needed" line. Empty when nothing is recognised, which is the
+ * common case — this adds to that line, it never replaces it.
+ *
+ * Adding a second service means another `supabaseKeys`-shaped filter and
+ * another branch here. It is deliberately not a table of services yet: the
+ * useful half of each entry is the screen its values are on, and that is
+ * prose we can only write for a dashboard we have actually checked.
+ */
+export declare function envServiceHints(keys: readonly string[]): string[];

package/dist/functions/read-capped.d.ts

@@ -0,0 +1 @@
+export { readCapped } from "@next-deploy/core";