create-theokit 2.0.0 → 3.0.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-theokit",
-  "version": "2.0.0",
+  "version": "3.0.1",
   "type": "module",
   "description": "Scaffold a new TheoKit project",
   "repository": {

package/templates/default/dot-theokit/THEO.md

@@ -14,13 +14,20 @@ tone instruction in this file quietly makes `usePersonality` do nothing. Tone be
 
 ## Why this file is here and not at the root
 
-On the SDK this project installs (`^4.52.1`, which resolves to a 4.x), `.theokit/THEO.md` is the
-**only** path a `THEO.md` is read from — a copy at the project root is read by nothing, silently.
-
-`@theokit/sdk@5` adds a root `THEO.md` (`usetheokit/theokit-sdk#531`) at priority 55, so on that
-version both locations work and `.theokit/THEO.md` still wins a conflict. 5.x is currently published
-on the `next` channel only, so moving this file to the root would break it for anyone on the default
-install — which is why the scaffold keeps it here.
+This project installs `@theokit/sdk@^5.3.0`, where **both** locations work: 5.x added a root
+`THEO.md` (`usetheokit/theokit-sdk#531`) at priority 55, and `.theokit/THEO.md` at 60 still wins a
+conflict. The scaffold keeps the file here because it wins, not because the root is unreadable.
+
+That reason is new. This paragraph used to say the template pinned `^4.52.1` — where
+`.theokit/THEO.md` was the **only** path read and a root copy was silently ignored — and that 5.x
+was published on the `next` channel only, so moving the file would break the default install. Both
+halves expired: 5.5.0 is `latest`, and the template's pin moved to `^5.3.0` because every `.claude`
+parity surface this framework advertises is absent from 4.x. A scaffold that hands a new project an
+SDK delivering none of that, with nothing saying so, is the defect the pin change closes.
+
+The floor is 5.3 rather than 5.0 because the framework's persistence barrel re-exports six names that
+5.0.0 does not have — measured with controls, 1 of 7 at 5.0.0 and 7 of 7 from 5.3.0 — so the range had
+to name a version that can actually build it.
 
 Two more things worth knowing if you do move it once 5.x is stable:
 

package/templates/default/package.json.tmpl

@@ -16,9 +16,9 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "theokit": "^0.65.0",
+    "theokit": "^0.68.0",
     "@theokit/agents": "^12.1.0",
-    "@theokit/sdk": "^4.52.1",
+    "@theokit/sdk": "^5.3.0",
     "@theokit/ui": "^1.1.0",
     "@usetheo/ui": "^0.26.0",
     "lucide-react": "^0.469.0",

package/templates/default/pnpm-workspace.yaml

@@ -11,9 +11,15 @@
 allowBuilds:
   # The bundler behind `theokit dev` and `theokit build`; ships a platform binary.
   esbuild: true
-  # A native terminal, reached through @theokit/agents. Compiles or downloads a
-  # prebuild on install. A web-only app never opens one — see usetheokit/theokit#25
-  # if you would rather not pay for it.
+  # A native terminal. Compiles or downloads a prebuild on install, so it is the one
+  # entry here that costs real time — and a scaffolded app does NOT install it.
+  # Measured 2026-09-20 on a scaffold generated from this template: 0 occurrences in
+  # the generated pnpm-lock.yaml, out of 453 resolved packages, and pnpm raised no
+  # ERR_PNPM_IGNORED_BUILDS. It arrives only if you add a package that depends on it.
+  # An earlier version of this comment said it was "reached through @theokit/agents";
+  # that package declares no pty dependency, so the line is corrected rather than
+  # deleted — a wrong reason for a right entry is what sent the last reader looking
+  # in the wrong place (usetheokit/theokit#25).
   node-pty: true
   # Present only if you add them; harmless entries otherwise, and here so the
   # decision is already made the day you do.