create-smoodly-app 0.0.36 → 0.0.37

package/README.md

@@ -4,7 +4,7 @@
 
 A fresh Next.js app with the Smoodly admin mounted at `/admin`, a Supabase
 project holding the schema, `.env.local` written, and a first editor who can
-sign in. Spec: `docs/superpowers/specs/2026-09-04-create-smoodly-app-design.md`.
+sign in.
 
 ## What it asks
 
@@ -41,202 +41,3 @@ Every prompt has a flag, so CI can run it: `--supabase local|hosted`, `--locales
 `SMOODLY_EDITOR_PASSWORD`), `--skip-link`, `--yes`. `--help` lists them.
 A hidden `--smoodly-dep <spec>` overrides the `smoodly` dependency written into
 `package.json`; CI points it at the packed tarball.
-
-## How it is built
-
-`templates/lorem`, `templates/lorem-intl`, `templates/blank` and
-`templates/blank-intl` are all generated by `scripts/build-template.ts`.
-The Lorem Co. pair comes from `examples/site` — the multilingual layout —
-plus the five single-language files under `variants/lorem/single/`. The
-blank pair (spec 2026-09-11) takes only the content-free glue from the
-example (`smoodly/server.ts`, `ops.ts`, `admin.tsx`, `richtext.tsx`, the
-admin route files, next-intl's files) and everything with content from
-`variants/blank/{common,single,intl}/`. Each template also gets a generated
-`package.json` (with `smoodly` pinned to this package's version),
-`tsconfig`, `next.config`, README, `AGENTS.md`, a `CLAUDE.md` that imports
-it, and the one migration (`coreTablesSQL` + the starter's collection
-views). Two exact-line transforms turn the example's glue (locale config,
-`href`) into the single-language one; a drifted example fails the build
-rather than silently shipping stale copies. Every template gets a check
-tsconfig beside it; `npm run typecheck` runs `tsc` over all four
-(`typecheck:templates`), so hand-kept files cannot drift silently. All
-four templates are git-ignored and rebuilt by `npm run build`.
-
-`src/plan.ts` turns answers into steps; `src/run.ts` executes them with
-injected `exec`, fs and Supabase client so the sequence and every fallback
-message are unit-tested. `src/prompts.ts` is the only interactive code.
-The CLI has no runtime dependency on `smoodly`.
-
-    npm test          # unit tests (template build, planner, runner, editor)
-    npm run typecheck # tsc, then the four templates
-    npm run build     # templates + esbuild bundle → dist/index.js
-
-Walked 2026-09-06: both templates scaffolded against the repo's local stack
-in hosted mode, `tsc`, `next build` and `/admin` 200 for each; the
-multilingual one with `--locales en,de`.
-
-Walked 2026-09-11: blank multilingual scaffolded in local mode with
-`--locales en,fr` from the built CLI, `next build`, `/` and `/fr` seeded
-with the Text section and the site footer line, the admin listing Home,
-Posts and the Site item, a post with a Button element published and
-served at `/posts/<slug>` in both locales; blank single-language
-scaffolded in hosted mode against the repo stack and `next build` only.
-
-## Follow-ups (logged 2026-09-28, fresh-install proof of 0.0.30)
-
-Walked 2026-09-28: `npx create-smoodly-app@0.0.30 proof-0030 --supabase
-local --yes --editor-email …` from the published package, in a scratch
-directory beside three running stacks (the new one took the `563xx`
-block). `smoodly` 0.0.30 installed, `tsc` and `next build` clean, `/`,
-`/posts`, `/posts/<slug>`, `/company/about-us` and `/admin` 200, the
-admin document's `<html lang="en">` present, the editor signed in, an
-SEO title edit saved and published and served on `/`. Found:
-
-- **Local mode left Realtime out (0.0.26–0.0.30).** `LOCAL_START_ARGS`
-  excluded `realtime` from before the concurrency spec, whose presence
-  channel and `saved` events ride it; the admin retried the WebSocket
-  forever (a console error per attempt) and a local install had no
-  presence or stale-page notice. CI's repo stack already kept Realtime.
-  Fixed 2026-09-28: the list no longer excludes it; restarted with the new
-  flags, a script signed in as the editor joined `space:<id>` and saw both
-  open admin tabs tracked on Home. The live job does not catch this
-  (it requests `/admin` once, no browser); an existing local install
-  restarts with `supabase stop && supabase start -x imgproxy,edge-runtime,logflare,vector,supavisor`.
-- **The Lorem home's custom-section CTA linked `/articles`**, a 404 —
-  the articles collection lives at `/posts`. `examples/site/scripts/seed.ts`
-  hardcoded the href; fixed 2026-09-28 to `paths(locale).articles` like
-  every other starter link (Finnish gets its own segment too).
-- **`--editor-email` without `SMOODLY_EDITOR_PASSWORD` fails late.** The
-  check lives in `askEditorWith`, which runs after the copy, install,
-  `git init` and `supabase start`, so the run stops at `ensureEditor`
-  with a half-made app. It has to be late for hosted mode (the email may
-  name an existing Auth user, no password needed), but a local stack is
-  always fresh, so local mode could refuse up front. Fixed 2026-09-28:
-  `resolveAnswers` refuses local `--editor-email` without the variable
-  before anything is written (the built CLI exits 1, no directory made);
-  hosted keeps the late check.
-
-## Follow-ups (logged 2026-09-25, docs walk)
-
-- **Single-language `/admin` had no root `<html>` (0.0.15–0.0.20).** The
-  variant's `app/(smoodly)/admin/layout.tsx` re-exported `AdminLayout`,
-  which renders a `<div>`; that only worked while the site had a
-  top-level `app/layout.tsx`, and 0.0.15 moved the site into `app/(site)`.
-  `next dev` showed two errors on the first visit to `/admin`: "Missing
-  <html> tags in the root layout" and, from the client-rendered tree, the
-  theme boot's "Encountered a script tag while rendering React component".
-  Found walking the Getting started guide on a fresh `lorem` install of
-  0.0.20. Fixed 2026-09-25: the variant layout wraps `AdminLayout` in
-  `<html><body>` like the example's; both errors gone in the walk. CI's
-  live job only checks `/admin` for a 200, which this passed; an assertion
-  on the dev overlay (or on `<html>` in the served document) would have
-  caught it.
-
-## Follow-ups (logged 2026-09-11)
-
-- **Blank single-language is typechecked, never built by CI.** The live
-  job scaffolds lorem single (hosted), lorem intl and blank intl (local).
-  A fourth stack costs ~2 minutes; add it if blank single ever breaks in
-  a way `tsc` cannot see (a runtime import, a missing file at a path
-  Next reads).
-- **The guide inside the package.** `AGENTS.md` is generated per scaffold
-  and frozen at install time. Once its text settles, ship it in the
-  `smoodly` package (`smoodly/AGENTS.md`) and have the scaffold's copy
-  point there, so it tracks the package version.
-
-## Follow-ups (logged 2026-09-06)
-
-- Local mode on a fresh multilingual install (0.0.5, 2026-09-06) failed at
-  `supabase start` with `supabase_storage_<app> container is not ready:
-  unhealthy` — the storage container logged `Started Successfully` and the
-  CLI still stopped the stack. Five local stacks (57 containers) were
-  sharing 7.8 GB of Docker memory at the time, the same pressure that
-  made the repo's live suites flake on 2026-09-05. Smoodly never uses
-  storage, so the CLI could start the app's stack with
-  `supabase start -x storage-api,imgproxy,edge-runtime,logflare,vector,realtime`
-  (the container names `supabase start --help` lists; CI already excludes
-  most of these for the repo stack), and the "Finish by hand" text could
-  mention `supabase stop` on other projects. Retried the same day with
-  the other four stacks stopped (`supabase stop --project-id <name>`):
-  `npx create-smoodly-app@0.0.5 --supabase local --locales en,fi --yes`
-  came up with every container healthy, storage included, and the app
-  built and served `/admin` 200, `/` and `/fi` 404 — so the cause is
-  memory pressure, not the CLI. Fixed the same day: `run.ts` starts the
-  app's stack with `-x storage-api,imgproxy,edge-runtime,logflare,vector,realtime,supavisor`
-  (`LOCAL_START_ARGS`), and the "Finish by hand" text carries the same
-  flags. Kept: db, kong, auth, PostgREST, Studio and pg-meta, mailpit.
-  Storage is back in the local stack since the media library
-  (2026-09-08); the health-check flake is a Docker memory problem, see
-  the repo's memory note.
-- **A non-interactive run without `--locales` needs `--yes`.** The
-  "Multilingual site?" prompt is asked whenever `--locales` is absent, and
-  with no TTY (a CI step, stdin at EOF) the CLI exits 13 having created
-  nothing — "Detected unsettled top-level await". CI's hosted-mode e2e step
-  hit this; both e2e steps now pass a flag that settles the question
-  (`--yes` for single-language, `--locales en,de` for the multilingual one).
-  A prompt that treated EOF as its default value would need no flag.
-- **The next-intl template inherits next-intl's `localeDetection`
-  default**, which redirects an unprefixed URL to the visitor's preferred
-  locale *keeping the source locale's slugs* — on a site with translated
-  slugs that redirect lands on a 404 (`/company/about-us` →
-  `/fi/company/about-us` for a Finnish browser). Recorded in
-  `examples/site/README.md` under "Multilingual (2026-09-06)". Fixed the
-  same day: `i18n/routing.ts` in the example — and so in the generated
-  `templates/next-intl` — sets `localeDetection: false`, so the English
-  URL stays English for a Finnish browser and the visitor picks a
-  language through the site's own switcher.
-
-## Follow-ups (logged 2026-09-05)
-
-- Text prompts drop `@` when the terminal sends Option as Meta (macOS,
-  Finnish/Nordic layouts put `@` on Option+2): the terminal emits `ESC 2` and
-  Node's readline discards meta-keys, so nothing reaches the prompt.
-  Reproduced against `@clack/prompts` 1.7.0 with a scripted stdin. Not
-  fixable from prompt options; documented under "What it asks" with the
-  paste / `--editor-email` workaround. Revisit if clack exposes a key hook.
-- Fresh installs printed a `NOTICE ... does not exist, skipping` for every
-  `drop trigger/policy if exists` in the migration (fixed 2026-09-05: the
-  migration opens with `set client_min_messages = warning`).
-
-## Follow-ups (logged 2026-09-04)
-
-- The port probe binds `0.0.0.0` (a loopback-only bind coexists with a Docker-published port on macOS), so macOS may prompt once to allow `node` incoming connections during local mode; either answer is fine.
-- Windows: `exec` passes `shell: true` on win32 (needed for the `.cmd` shims)
-  but does not quote arguments, so a project name or path containing a space
-  or `&` breaks. Quote the args when the shell is on, or resolve the `.cmd`
-  path and drop `shell`. Untested on Windows.
-- Hosted mode, manual run against a real hosted project with new-format keys
-  (done 2026-09-05, throwaway project, `sb_secret_` + `sb_publishable_`):
-  `db push` of the template migration printed no NOTICE, the CLI listed and
-  created the first editor through the GoTrue admin API with the secret key
-  as the sole `apikey`, the `members` row landed with role `admin`, `next
-  build` passed, `/admin` served the shell, and a password sign-in with the
-  publishable key returned a session. Caveat: the link step ran by hand with
-  an explicit `--project-ref` (see the next-but-one item); the CLI's own
-  `supabase link` was not driven interactively.
-- Supabase CLI 2.78.1 prints `sb_secret_` keys masked (middle dots) from
-  `supabase projects api-keys`; 2.116.0 needs `--reveal`. A user who copies
-  the key from the CLI rather than the dashboard gets "Invalid API key" at
-  the editor step. Worth a hint in the "Finish by hand" text.
-- `listUsers` reads one page of 200 Auth users when offering an existing user
-  to make the first editor. Fine for a fresh project, wrong for a populated one.
-- `supabase link` ran without `--project-ref`, so the CLI opened the
-  project picker, which preselects the account's first project; `db push`
-  follows the link, so one Enter would push Smoodly's schema into whichever
-  project sorts first (seen 2026-09-05 during the hosted run, caught before
-  the push). Fixed 2026-09-05: `projectRef` (src/env.ts) takes the ref from
-  the typed URL's first host label and the link step and every fallback
-  line pass it. Seen again 2026-09-05 from the published 0.0.3: a URL typed
-  without `https://` gave no ref (the picker opened) and then failed
-  `ensureEditor` with supabase-js's "Invalid supabaseUrl". Fixed the same
-  day: `normalizeProjectUrl` (src/env.ts) adds the scheme and refuses
-  non-URLs at the prompt and for `--url`; a URL with no ref (custom domain)
-  never offers the link, and `run` throws rather than run a bare
-  `supabase link`.
-- The `--yes` flag defaults to local mode; with the Supabase CLI absent that
-  stops with the install message rather than falling through to hosted.
-- Captured `exec` output is stdout only; stderr streams straight through, so
-  `git init` hints and the Supabase CLI's update notice appear between the
-  prompt lines.
-- The "Local" option is still offered in the select when the Supabase CLI is
-  absent, and only bails afterwards; the spec wants the check before the prompt.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-smoodly-app",
-  "version": "0.0.36",
+  "version": "0.0.37",
   "description": "Create a Smoodly site: a fresh Next.js app with the admin mounted, a Supabase schema, an env file and a first editor.",
   "license": "MIT",
   "repository": {

package/templates/blank/package.json

@@ -14,7 +14,7 @@
     "next": "^16.3.4",
     "react": "^19",
     "react-dom": "^19",
-    "smoodly": "0.0.36"
+    "smoodly": "0.0.37"
   },
   "devDependencies": {
     "@next/env": "^16.3.4",

package/templates/blank-intl/package.json

@@ -14,7 +14,7 @@
     "next": "^16.3.4",
     "react": "^19",
     "react-dom": "^19",
-    "smoodly": "0.0.36",
+    "smoodly": "0.0.37",
     "next-intl": "^4.14.2"
   },
   "devDependencies": {

package/templates/lorem/package.json

@@ -14,7 +14,7 @@
     "next": "^16.3.4",
     "react": "^19",
     "react-dom": "^19",
-    "smoodly": "0.0.36"
+    "smoodly": "0.0.37"
   },
   "devDependencies": {
     "@next/env": "^16.3.4",

package/templates/lorem-intl/package.json

@@ -14,7 +14,7 @@
     "next": "^16.3.4",
     "react": "^19",
     "react-dom": "^19",
-    "smoodly": "0.0.36",
+    "smoodly": "0.0.37",
     "next-intl": "^4.14.2"
   },
   "devDependencies": {