caracms 0.8.2 → 0.8.3

package/README.md

@@ -369,7 +369,7 @@ export default defineSite({
   (caracms.config.ts), but CARACMS_CLOUD_KEY isn't set. Make a key for it in
   app.caracms.com." (the build fails; a running server's `/admin` answers 503 with it, and
   the public site keeps serving). It never falls back to the self-hosted variables.
-  `astro dev` without a key is local mode, as always.
+  `astro dev` is local mode, with or without the key (see [working locally](#working-locally)).
 - **`'self-hosted'`**: the site's own variables, as [the variables](#the-variables) list
   them. A `CARACMS_CLOUD_KEY` beside them is ignored the same way.
 - **Not set** (a site from before caracms 0.8.0): the key decides, and setting it beside
@@ -538,11 +538,13 @@ has been replaced.
 laptop, a colleague's, a client's developer, a staging deploy. Each gets **its own key**
 for the site, labelled ("Rich's laptop", "staging") in app.caracms.com, so revoking one
 never touches the live site. Leave `CARACMS_CLOUD_URL` unset: images render from
-`img.caracms.cloud` and the library lists the site's real folder. A cloud key turns
-`astro dev` into live mode on the site's real repo, as the App's variables do. Uploads
+`img.caracms.cloud` and the library lists the site's real folder. `astro dev` stays in
+local mode, editing the files on disk: live mode on a laptop never points at the site's
+real repo, so the key alone never turns it on (the App's variables still do). Uploads
 from a laptop land in the real folder and count towards its storage, which is harmless:
 nothing is overwritten or deleted, and nothing is live until it's published.
-`CARACMS_CLOUD_URL` is only for working on CaraCMS Cloud itself, against its dev deployment.
+`CARACMS_CLOUD_URL` is only for working on CaraCMS Cloud itself, against its dev deployment;
+with it, `astro dev` is live on that deployment's throwaway repos.
 
 ### Behind Cloudflare
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "caracms",
-  "version": "0.8.2",
+  "version": "0.8.3",
   "description": "A visual CMS for Astro sites, with content in git.",
   "license": "MIT",
   "type": "module",

package/skills/caracms-adopt/SKILL.md

@@ -115,7 +115,7 @@ is the exception (section 4).
 **Images need credentials** in the site's `.env` (never committed). On CaraCMS Cloud
 that's `CARACMS_CLOUD_KEY` alone: a key labelled for this laptop, made in
 app.caracms.com (`caracms-hosting` → section 1); it shows, imports and uploads images,
-and makes `astro dev` live on the site's real repo. Self-hosted, it's the media
+and `astro dev` still edits the files on disk. Self-hosted, it's the media
 variables: `CARACMS_MEDIA_URL` (imgproxy's origin), `IMGPROXY_KEY`, `IMGPROXY_SALT` and
 `S3_BUCKET` to show images, plus `S3_ENDPOINT`, `S3_REGION`, `S3_ACCESS_KEY_ID` and
 `S3_SECRET_ACCESS_KEY` to import and upload them. Without them `astro dev` draws a

package/skills/caracms-hosting/SKILL.md

@@ -81,8 +81,9 @@ npx caracms init --cloud --write    # writes services: 'cloud' and the rest
 **One key per place the site runs**, each labelled in app.caracms.com: "Railway" for
 the host, "Rich's laptop" for a laptop's `.env`, "staging" for a staging deploy.
 Revoking one never touches the others. Leave `CARACMS_CLOUD_URL` unset (it's only for
-working on CaraCMS Cloud itself). On a laptop a cloud key makes `astro dev` live on the
-site's real repo and folder; without one, `astro dev` edits content on disk as always.
+working on CaraCMS Cloud itself). On a laptop `astro dev` edits content on disk, with or
+without a key; the key shows, imports and uploads images in the site's real folder. Only
+the key with `CARACMS_CLOUD_URL` (the cloud's dev deployment) makes `astro dev` live.
 
 **A production build needs the key.** With `services: 'cloud'` and no
 `CARACMS_CLOUD_KEY`, `astro build` (and `pnpm build` on a laptop, which is a production

package/src/live/mode.ts

@@ -1,8 +1,11 @@
 /**
  * Which mode the editor runs in, read from the environment (M4 Decision 1).
  *
- * - **Local mode**: `astro dev` with no GitHub credentials (`CARACMS_CLOUD_KEY`,
- *   `GITHUB_APP_ID` or `CARACMS_GITHUB_TOKEN`). M3's editor, files on disk.
+ * - **Local mode**: `astro dev` with no GitHub credentials (`GITHUB_APP_ID` or
+ *   `CARACMS_GITHUB_TOKEN`). M3's editor, files on disk. `CARACMS_CLOUD_KEY` alone stays
+ *   local (caracms-cloud: live mode on a laptop never points at a client's repo); the key
+ *   is still the images', clips' and forms' credential there. Only the key with
+ *   `CARACMS_CLOUD_URL` (the cloud's dev deployment, throwaway repos only) is live in dev.
  * - **Live mode**: whenever a credential is configured, and **always on a production
  *   server**. It needs one GitHub credential (a fine-grained token, or the App's
  *   `GITHUB_APP_ID` and `GITHUB_APP_PRIVATE_KEY`; runs-anywhere Decisions 3–4), the repo
@@ -208,7 +211,9 @@ export function readMode(env: Env = process.env, production = env.NODE_ENV === '
 	// Never GITHUB_TOKEN (Decision 4): the gh CLI and GitHub Actions export it.
 	const ghToken = get('CARACMS_GITHUB_TOKEN');
 	const cloudKey = get('CARACMS_CLOUD_KEY');
-	if (!production && !memory && !get('GITHUB_APP_ID') && !ghToken && !cloudKey) return { kind: 'local' };
+	// A laptop's key is the production cloud's, so the site's real repo: dev stays local unless CARACMS_CLOUD_URL names another cloud.
+	const devCloud = cloudKey && get('CARACMS_CLOUD_URL');
+	if (!production && !memory && !get('GITHUB_APP_ID') && !ghToken && !devCloud) return { kind: 'local' };
 
 	const missing: string[] = [];
 	const problems: string[] = [];