@nateui/cli 0.0.3 → 0.0.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nateui/cli",
-  "version": "0.0.3",
+  "version": "0.0.4",
   "description": "NateUI CLI. Scaffolds and updates NateUI projects.",
   "type": "module",
   "bin": {

package/dist/chassis/nextjs/GENERATED.md

@@ -1,44 +0,0 @@
-# Generated tree
-
-Base tree produced 2026-09-04 with:
-
-```bash
-npx create-next-app@latest nateui-next --typescript --app --src-dir --import-alias "@/*" --tailwind --no-eslint --turbopack --use-pnpm --skip-install
-```
-
-create-next-app version resolved at generation time: 16.3.4 (`next` itself is pinned down to `16.2.6` in `package.json` afterward, per `code/package.json`).
-
-Flags beyond the work order's base command, and why:
-- `--tailwind` — gets a correct `postcss.config.mjs` + `@tailwindcss/postcss` devDependency for free; `globals.css` it writes is deleted and replaced by our copied stylesheet regardless.
-- `--no-eslint` — the target file manifest (`m2-packaging.md` §2) has no ESLint config; omit it at the source instead of stripping after.
-- `--turbopack` — current create-next-app default; only affects the `dev` script flag, not the file set.
-- `--use-pnpm` — makes the generator emit a `pnpm-workspace.yaml` (later overwritten with the proven `template-base` fix — see below) and stamp `packageManager` (dropped; not in the target manifest).
-- `--skip-install` — no need to install into the scratch dir; the real install happens in the throwaway acceptance-test copy.
-
-## Kept from the generator as-is
-`.gitignore`, `next-env.d.ts`, `next.config.ts` (byte-identical to `template-base`'s), `postcss.config.mjs` (also byte-identical to `template-base`'s), `tsconfig.json` (already clean — no `@/configs/*` CRM paths, no `useMenuActive` include; those only exist in `template-base`'s hand-edited `tsconfig.json`, which is why the work order says not to copy that file).
-
-## Hand-written, not from the generator
-`package.json` (dependency versions pinned from `code/package.json`, not the generator's auto-resolved latest), `pnpm-workspace.yaml` (see below), `src/app/layout.tsx`, `src/app/page.tsx`, `src/styles/base.css` + `src/styles/index.css` (copied, see the two notes below).
-
-## Stripped from the generator's output
-`AGENTS.md`, `CLAUDE.md`, `README.md` — current create-next-app scaffolds agent-instruction files and a generic README by default; none are in the target manifest and shipping an agent-instruction file inside a buyer's fresh app is actively wrong. `src/app/globals.css`, `src/app/favicon.ico`, `public/*.svg` — generator branding/demo content. `.git/` — the generator initializes a repo in the scratch dir; irrelevant, not copied.
-
-## pnpm-workspace.yaml note
-The work order and `m2-packaging.md` both say to use a key named `onlyBuiltDependencies`. That key does not appear anywhere in this repo and current `create-next-app --use-pnpm` does not write it either — it writes `allowBuilds: { sharp: false, unrs-resolver: false }`. `template-base`'s own `pnpm-workspace.yaml` (the file the spec cites as prior precedent for this exact bug) carries that plus `ignoredBuiltDependencies: [sharp, unrs-resolver]`. This chassis copies `template-base`'s proven content verbatim rather than the spec's literal (and apparently stale) key name. Flagged in the report back to the orchestrator.
-
-## src/styles/index.css note
-The work order and `m2-packaging.md` §1 both say `index.css` comes from `code/templates/template-base/typescript/nextjs/src/styles/` alongside `base.css`. That path has no `index.css` — only `base.css` lives there. `index.css` actually lives per-domain, at `code/templates/domains/<slug>/typescript/nextjs/src/styles/index.css`. It is byte-identical across `crm`, `project-management`, and `sales-inventory`; `ai-chat`'s carries extra CodeMirror syntax-color tokens on top (chat-specific, not core). Copied from `crm`'s, matching the path `m2-packaging.md`'s own Sources section cites. Flagged in the report back to the orchestrator.
-
-## @tailwindcss/typography — added, not in `m2-packaging.md`'s pinned-7 list
-`base.css` line 2 is `@plugin "@tailwindcss/typography";` — copied verbatim per the "never re-authored" rule, so the package it names must be a real dependency or `pnpm build` fails to resolve the plugin. `code/package.json` doesn't pin it (it isn't ecosystem source, it's Tailwind tooling). Version `^0.5.19` taken from `code/templates/domains/crm/typescript/nextjs/package.json` — the freshest real install of this exact package in the repo. `@tailwindcss/postcss` and `tailwindcss` both `^4`, matching what `create-next-app --tailwind` itself resolved.
-
-## "use client" — real finding, not a chassis-only quirk
-`src/app/page.tsx` needs `"use client"` at the top. Without it, `next build` fails: `Button` → `ConfigProvider.ts` / `InputGroup/context.ts` both call `createContext`/`useContext`, and App Router treats every file as a Server Component by default — `createContext` is Client-Component-only. Neither `Button.tsx` nor `ConfigProvider.ts` carries its own `"use client"` directive (unlike some `ui/` components — `Alert`, `Rate`, `AvatarGroup`, `Badge`, `Avatar` do; `Button`/`ConfigProvider`/`InputGroup`/`Spinner`/`Form` don't). `crm`'s own domain components follow the same pattern of marking the *consuming* file, not relying on the library leaf to self-mark (e.g. `_components/BoardCard.tsx`, `_components/ListGroup.tsx`), so marking `page.tsx` itself here follows existing repo convention rather than inventing one. Any buyer who renders an interactive/context-consuming `ui` component directly from a Server Component will hit the same error — this is a real, repo-wide `code/components/ui/` consumption gotcha under App Router, not something specific to this starting page. Worth the orchestrator/Architect knowing about; not fixed at the source here (out of scope).
-
-## Acceptance test (F2-equivalent, run by hand per the work order's "Done means")
-Built in a throwaway copy with `code/components/ui/{Button,ConfigProvider,Spinner,InputGroup}/` plus `code/components/ui/form/context.ts` (not the whole `Form/` folder — `InputGroup.tsx` and `Addon.tsx` both call `useForm` from `../Form/context`, which is a small, self-contained context file with no further dependencies; the rest of `Form/` — `Form.tsx`, `FormField.tsx`, `FormScope.tsx`, `constants.ts`, its own `index.tsx` — is not part of Button's actual closure) and `code/utils/class-names.ts`, layered into `src/components/ui/` and `src/utils/` respectively — never committed here, this chassis tree stays component-free per §1/§2 (the CLI's `init` fetches `components/ui/**` as a separate registry step; the chassis itself is deliberately not one of the ~8 files that carries it).
-1. `pnpm install` — exit 0.
-2. `pnpm build` — exit 0, after the `"use client"` fix above. First attempt (without it) failed with exactly the error described above.
-3. `pnpm dev`, loaded in-browser: button background `rgb(255, 255, 255)`, border `rgb(213, 215, 218)`, page background `rgb(250, 250, 250)`, font family resolves to `Inter` (via `next/font/google`) — resolving through the `--nui-*` tokens, not browser defaults or a grey box.
-4. `document.documentElement.classList.add('dark')` → body background flips to `rgb(10, 10, 10)`, button to `rgba(255, 255, 255, 0.04)`. Confirmed working.

package/dist/chassis/vite/GENERATED.md

@@ -1,46 +0,0 @@
-# Generated tree
-
-Base tree produced 2026-09-04 with:
-
-```bash
-npm create vite@latest nateui-vite -- --template react-ts --no-eslint --no-interactive
-```
-
-create-vite version resolved at generation time: 9.2.0.
-
-Flags beyond the work order's base command, and why:
-- `--no-eslint` — current create-vite's flag help text reads "use ESLint instead of Oxlint": the react-ts template now defaults to Oxlint as its linter, and this flag chooses between the two, not lint-vs-no-lint. There is no flag to omit a linter entirely. `.oxlintrc.json` and the `oxlint` devDependency + `lint` script it added were stripped afterward — not in the target manifest (`m2-packaging.md` §3) and not something the work order asked for.
-- `--no-interactive` — this session has no TTY; forces the prompts off instead of hanging.
-
-## Kept from the generator as-is
-`.gitignore`, `tsconfig.json` (root; project-references only, unchanged), `tsconfig.node.json`.
-
-## Hand-written, not from the generator
-`package.json` (dependency versions pinned from `code/package.json`, not the generator's auto-resolved latest), `tsconfig.app.json` (generator's base kept, `paths` added — see alias note), `vite.config.ts` (generator's base kept, `@tailwindcss/vite` + `resolve.alias` added), `index.html` (favicon link removed along with the favicon asset; title changed; Google Fonts `<link>` added for Inter — the `<link>` option from `m2-packaging.md` §3, not `@fontsource/inter`, to avoid an extra pinned dependency), `src/main.tsx` (generator's base kept, stylesheet import path changed to `@/styles/index.css`), `src/App.tsx` (counter demo replaced), `src/styles/base.css` + `src/styles/index.css` (copied, see the two notes in the Next.js chassis's own `GENERATED.md` — same content, same caveats, not repeated here).
-
-## Stripped from the generator's output
-`.oxlintrc.json` (see above), `README.md`, `src/App.css`, `src/index.css`, `src/assets/react.svg`, `src/assets/vite.svg`, `src/assets/hero.png`, `public/favicon.svg`, `public/icons.svg` — current create-vite's react-ts template ships a materially different demo than what the work order describes (a hero image + doc/social link sections wired to `public/icons.svg`, not just a spinning-logo counter) — all of it is generator branding/demo content regardless, stripped on the same "buyer must not find generator demo content" basis the work order states for the old template shape.
-
-## No src/vite-env.d.ts
-Current create-vite no longer generates this file. Its role — ambient `import.meta.env` / `ImportMetaEnv` types — is already covered by `tsconfig.app.json`'s `"types": ["vite/client"]`, which the generator does still write. Not hand-added; nothing to add.
-
-## Alias note
-`m2-packaging.md` §3 says the alias goes in "three places... vite.config.ts resolve.alias, plus paths in tsconfig.app.json and the root tsconfig.json if it carries compiler options." The generated root `tsconfig.json` carries no `compilerOptions` (it is a bare project-references file pointing at `tsconfig.app.json` / `tsconfig.node.json`), so per that same sentence's own conditional, only two places actually apply here: `vite.config.ts` and `tsconfig.app.json`. Both are done. `tsconfig.node.json` does not need the alias — nothing under it (just `vite.config.ts` itself) imports `@/*`.
-
-## pnpm-workspace.yaml — deliberately absent
-Not in `m2-packaging.md` §3's file list for this chassis (it is listed for the Next.js one, §2). Tested empirically rather than assumed either way: `pnpm install` against this chassis's exact dependency set (§ Acceptance test below) produced zero "ignored build scripts" warnings with no `pnpm-workspace.yaml` present at all — `sharp` and `unrs-resolver` never entered this dependency graph. Left out, matching the manifest. If a future dependency change pulls either package in transitively, re-check; the fix, if needed, is the Next.js chassis's `pnpm-workspace.yaml` content unchanged (framework-agnostic).
-
-## TypeScript strictness vs. `code/components/ui/` — real finding, not a chassis-only workaround
-`tsconfig.app.json` as generated sets `erasableSyntaxOnly: true` and `verbatimModuleSyntax: true`. Both are incompatible with existing, pervasive `code/components/ui/` patterns, not just the four components this chassis was tested against:
-- `erasableSyntaxOnly` rejects `code/components/ui/config-provider/config-provider.ts`'s `export enum SIZES {...}` — a real (non-`const`) enum compiles to runtime code, which this flag disallows.
-- `verbatimModuleSyntax` rejects `code/components/ui/inputGroup/index.tsx`'s `import _InputGroup, { InputGroupProps } from './InputGroup'` — `InputGroupProps` is a type, imported without `import type`.
-
-Both are generator defaults, not spec requirements — `m2-packaging.md` never mentions either flag. Turned off here rather than touched at the source: fixing `code/components/ui/` itself is out of this work order's scope (`code/` is shared ecosystem source, not part of "the two shells"), and either flag failing blocks `pnpm build` for **any** Vite consumer of `ui/**` that touches an enum or a bare type import, not just this chassis. Flagged in the report back to the orchestrator as a `code/components/ui/` finding worth a real fix (enum → `as const` object, `import` → `import type`) rather than a per-consumer tsconfig workaround.
-
-## Acceptance test (F2/F3-equivalent, run by hand per the work order's "Done means")
-Built in a throwaway copy with `code/components/ui/{Button,ConfigProvider,Spinner,InputGroup}/`, `code/components/ui/form/context.ts` (see the Next.js chassis's `GENERATED.md` for why `Form/context.ts` alone, not the whole `Form/` folder, belongs in Button's closure), and `code/utils/class-names.ts` layered into `src/components/ui/` and `src/utils/` respectively — never committed here, this chassis tree stays component-free per §1/§3.
-1. `pnpm install` — exit 0.
-2. `pnpm build` (`tsc -b && vite build`) — exit 0, after the tsconfig fix above.
-3. `pnpm dev`, loaded in-browser: button background `rgb(255, 255, 255)`, border `rgb(213, 215, 218)`, page background `rgb(250, 250, 250)` — resolving through the `--nui-*` tokens, not browser defaults or a grey box.
-4. `document.fonts.check('16px Inter')` → `true` — the `<link>`-tag Inter wiring actually loads the font, not just falls through the `--font-sans` stack to a system font.
-5. `document.documentElement.classList.add('dark')` → body background flips to `rgb(10, 10, 10)`, button to `rgba(255, 255, 255, 0.04)`. Confirmed working.