clivly 0.3.0-next.2 → 0.3.0-next.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -12,12 +12,15 @@ For the full integration path, including when to use `start()` versus
12
12
  ```bash
13
13
  npm install clivly
14
14
 
15
- npx clivly init # detect your Drizzle schema and print the config plan
16
- npx clivly init --write # write clivly.config.ts
17
- npx clivly ping # verify CLIVLY_API_KEY + reachability
18
- npx clivly doctor # verify clivly.config.ts end-to-end
15
+ npx clivly init # scaffold config, routes and .env, then pair this machine
16
+ npx clivly login # pair this machine and write your credentials to .env
17
+ npx clivly status # check your setup, step by step
18
+ npx clivly dev # tunnel localhost so remote sync can reach you
19
+ npx clivly push-schema # report your schema to Clivly without deploying
19
20
  ```
20
21
 
22
+ `ping` and `doctor` remain as aliases that run subsets of the `status` ladder.
23
+
21
24
  ## Imports
22
25
 
23
26
  `clivly` is the consolidated public package. The CLI remains available as
@@ -45,6 +48,87 @@ Kysely projects should use a hand-written `fetchPage` source for now.
45
48
  Use `--schema <path>` when your Drizzle schema is not in a common location or in
46
49
  `drizzle.config.ts`. Re-run with `--force` to overwrite an existing config.
47
50
 
51
+ First-class route scaffolding currently exists for:
52
+
53
+ - Next.js
54
+ - TanStack Start
55
+ - SvelteKit
56
+ - Remix
57
+ - Nuxt
58
+
59
+ Vue.js apps can still integrate Clivly, but they usually need a manual server
60
+ layer for the tick and verify routes unless they are using Nuxt.
61
+
62
+ When `init` finishes and `CLIVLY_API_KEY` is still empty, it hands you straight
63
+ into `clivly login` so you don't end up staring at a blank `.env`. That step is
64
+ interactive, so it is skipped automatically when there is no TTY or when `CI` is
65
+ set — and you can always turn it off yourself:
66
+
67
+ ```bash
68
+ npx clivly init --no-login # scaffold only; pair later with `clivly login`
69
+ npx clivly init --no-browser # pair, but print the URL instead of opening it
70
+ ```
71
+
72
+ ## `clivly login`
73
+
74
+ ```bash
75
+ npx clivly login [--force] [--rotate] [--api-url <url>] [--no-browser]
76
+ ```
77
+
78
+ Pairs this machine with a Clivly workspace and writes `CLIVLY_API_KEY` and
79
+ `CLIVLY_SYNC_TRIGGER_SECRET` into your project's `.env`. It creates a pairing
80
+ session, prints (and by default opens) an approval link, and waits while you
81
+ approve it in a signed-in browser. The approval link is always printed, so an
82
+ SSH or headless session can be approved by opening the link elsewhere.
83
+
84
+ - `--no-browser` — print the approval URL without opening a browser.
85
+ - `--force` — overwrite `.env` values that already have a real value. Without
86
+ it, existing values are kept and reported as skipped; an empty placeholder
87
+ (`CLIVLY_API_KEY=`) is always filled in.
88
+ - `--rotate` — rotate the workspace's remote-sync trigger secret instead of
89
+ revealing the current one. Your already-deployed host app will stop receiving
90
+ sync triggers until you redeploy it with the new secret.
91
+
92
+ Before anything is written, the CLI prints which workspace approved the pairing
93
+ and asks you to confirm. Declining writes nothing and exits non-zero. In a
94
+ non-interactive run (no TTY, or `CI` set) the workspace is still printed but
95
+ you are not prompted, so scripted pairing cannot hang.
96
+
97
+ The pairing endpoints are feature-flagged server-side
98
+ (`CLIVLY_CLI_PAIRING_ENABLED`); if the backend you point at has not enabled
99
+ them, `clivly login` says so and exits non-zero.
100
+
101
+ > **Running your own Clivly backend?** `CLIVLY_TRIGGER_SECRET_WRAPPING_KEY` (a
102
+ > 32-byte hex key) is a **hard production prerequisite** for pairing. The
103
+ > trigger secret is stored encrypted with it, so without the key set on the
104
+ > server, `clivly login` fails with a 500 at the moment it would hand over
105
+ > credentials. Set it before enabling `CLIVLY_CLI_PAIRING_ENABLED`.
106
+
107
+ ## `clivly status`
108
+
109
+ ```bash
110
+ npx clivly status [--verbose] [--config <path>]
111
+ ```
112
+
113
+ Walks your setup one rung at a time — credentials, config, schema, sources,
114
+ connectivity — and stops at the first thing that isn't ready, telling you what
115
+ to do about it. This is the command to reach for when something isn't working.
116
+
117
+ ## `clivly dev`
118
+
119
+ ```bash
120
+ npx clivly dev [--port <n>] [--api-url <url>] [--route-path <path>] [-- <cmd>]
121
+ ```
122
+
123
+ Opens a `cloudflared` tunnel to your local app and registers it with Clivly for
124
+ the length of the session, so remote sync can reach `localhost` while you
125
+ develop. Your dev server is detected from `package.json` scripts, or pass it
126
+ explicitly after `--`. Needs `cloudflared` on `PATH` and `CLIVLY_API_KEY` set.
127
+ The override is cleared when the process exits; remote sync is otherwise
128
+ deploy-only.
129
+
130
+ ## `clivly ping` / `clivly doctor`
131
+
48
132
  `clivly ping` reads `CLIVLY_API_KEY` from the environment, sends one heartbeat, and prints a clear ✅/❌ with the resolved org or the failure reason — so you can confirm a connection from the terminal without writing any code. Point it at a non-default backend with `--api-url <url>` (or `CLIVLY_API_URL`).
49
133
 
50
134
  ```bash
@@ -22,7 +22,20 @@ const TABLE_PATTERNS = [
22
22
  "attendees",
23
23
  "people",
24
24
  "members",
25
- "contacts"
25
+ "contacts",
26
+ "students",
27
+ "pupils",
28
+ "learners",
29
+ "patients",
30
+ "subscribers",
31
+ "donors",
32
+ "guests",
33
+ "residents",
34
+ "tenants",
35
+ "applicants",
36
+ "candidates",
37
+ "leads",
38
+ "prospects"
26
39
  ]
27
40
  },
28
41
  {
@@ -21,7 +21,20 @@ const TABLE_PATTERNS = [
21
21
  "attendees",
22
22
  "people",
23
23
  "members",
24
- "contacts"
24
+ "contacts",
25
+ "students",
26
+ "pupils",
27
+ "learners",
28
+ "patients",
29
+ "subscribers",
30
+ "donors",
31
+ "guests",
32
+ "residents",
33
+ "tenants",
34
+ "applicants",
35
+ "candidates",
36
+ "leads",
37
+ "prospects"
25
38
  ]
26
39
  },
27
40
  {
package/drizzle.cjs CHANGED
@@ -1,5 +1,5 @@
1
1
  Object.defineProperty(exports, Symbol.toStringTag, { value: "Module" });
2
- const require_drizzle_meta = require("./drizzle-meta-CM5M73Z4.cjs");
2
+ const require_drizzle_meta = require("./drizzle-meta-BVR1qiyu.cjs");
3
3
  let drizzle_orm = require("drizzle-orm");
4
4
  let drizzle_orm_pg_core = require("drizzle-orm/pg-core");
5
5
  //#region ../sdk/src/drizzle.ts
package/drizzle.d.cts CHANGED
@@ -1,4 +1,4 @@
1
- import { d as SyncSource, t as NamespaceIntrospector } from "./namespace-probe-BtS0nXcr.cjs";
1
+ import { d as SyncSource, t as NamespaceIntrospector } from "./namespace-probe-CcYne5Je.cjs";
2
2
  import { Table } from "drizzle-orm";
3
3
 
4
4
  //#region ../sdk/src/drizzle.d.ts
package/drizzle.d.mts CHANGED
@@ -1,4 +1,4 @@
1
- import { d as SyncSource, t as NamespaceIntrospector } from "./namespace-probe-CYMie-BI.mjs";
1
+ import { d as SyncSource, t as NamespaceIntrospector } from "./namespace-probe-DjWzU9gG.mjs";
2
2
  import { Table } from "drizzle-orm";
3
3
 
4
4
  //#region ../sdk/src/drizzle.d.ts
package/drizzle.mjs CHANGED
@@ -1,4 +1,4 @@
1
- import { t as DRIZZLE_META } from "./drizzle-meta-1z6Apnt-.mjs";
1
+ import { t as DRIZZLE_META } from "./drizzle-meta-DpMKataU.mjs";
2
2
  import { asc, getTableColumns, getTableName, sql } from "drizzle-orm";
3
3
  import { getTableConfig } from "drizzle-orm/pg-core";
4
4
  //#region ../sdk/src/drizzle.ts