create-foldkit-app 0.22.2 → 0.23.1

package/README.md

@@ -39,7 +39,7 @@ The CLI prompts you for a project name, starter example, and package manager. Pa
 | `generative-art`         | Perlin-noise flow field with evolving particle trails, mouse vortex, and high-frequency Messages       |
 | `auth`                   | Authentication with Submodels, OutMessage, and protected routes                                        |
 | `shopping-cart`          | Complex state management with nested Models and routing                                                |
-| `checkout-machine`       | Experimental state machine checkout with guarded branches and edge Commands                            |
+| `state-machine`          | Experimental state machine checkout with guarded branches and edge Commands                            |
 | `pixel-art`              | Pixel editor with undo/redo, UI components, and localStorage persistence                               |
 | `websocket-chat`         | Managed resources with WebSocket integration                                                           |
 | `managed-resource-layer` | Layer-backed ManagedResource lifecycle with an Effect service                                          |

package/dist/examples.js

@@ -19,7 +19,7 @@ export const EXAMPLE_VALUES = [
     'generative-art',
     'auth',
     'shopping-cart',
-    'checkout-machine',
+    'state-machine',
     'pixel-art',
     'websocket-chat',
     'managed-resource-layer',
@@ -131,8 +131,8 @@ export const examples = [
         description: 'Complex state management with nested models and routing',
     },
     {
-        value: 'checkout-machine',
-        title: 'checkout-machine',
+        value: 'state-machine',
+        title: 'state-machine',
         description: 'Checkout workflow powered by the experimental state machine module with guarded branches and edge Commands',
     },
     {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-foldkit-app",
-  "version": "0.22.2",
+  "version": "0.23.1",
   "description": "Create Foldkit applications",
   "type": "module",
   "main": "./dist/index.js",

package/templates/base/AGENTS.md

@@ -52,7 +52,7 @@ Use `evo()` from `foldkit/struct` for immutable model updates. Never spread or `
 
 ### View
 
-Bind the `html` factory inside each view function with `const h = html<Message>()` (never at module level), then reach for `h.div`, `h.OnClick`, etc. off the returned record. Use `empty` (not `null`) for conditional rendering, `M.value().pipe(M.tagsExhaustive({...}))` for discriminated unions, and `Array.match` for lists that may be empty.
+Every view receives `h`, the typed Html builder, as its last parameter (`view: (model, h) => ...`; `Submodel.defineView` passes the child's own). Never construct a builder; reach for `h.div`, `h.OnClick`, etc. off the parameter, and give extracted view helpers an `h: HtmlBuilder<Message>` last parameter that callers thread through. Only where no builder is in scope, typically module scope, use `inertHtml` from `foldkit/html`, aliased `ih` so the two builders stay distinguishable. Use `h.empty` (not `null`) for conditional rendering, `M.value().pipe(M.tagsExhaustive({...}))` for discriminated unions, and `Array.match` for lists that may be empty.
 
 Keys are for mapped list items only: key each row by a stable Model identifier (`h.keyed('li')(item.id, [], [...])`), never by array position, and never derive a key from displayed data. Never key branches; the build gives each view function's output its own identity, so branch switches replace DOM automatically. When switching an inline same-tag ternary must reset DOM state, extract each arm into its own named view function.
 
@@ -74,7 +74,9 @@ Use uppercase section headers (`// MODEL`, `// MESSAGE`, `// INIT`, `// UPDATE`,
 
 ### Testing
 
-Test update functions with `foldkit/test`. Since update is pure, tests run without a runtime, DOM, or side effects. Use `Story.story` for update-level tests (send Messages, assert on Model and Commands) and `Scene.scene` for feature-level testing through the view with accessible locators.
+Test update functions with `foldkit/test`. Since update is pure, tests run without a runtime, DOM, or side effects. Use `story` for update-level tests (send Messages, assert on Model and Commands) and `scene` for feature-level testing through the view with accessible locators.
+
+Import the steps as named imports from `foldkit/story` or `foldkit/scene`: `import { Command, given, message, model, story } from 'foldkit/story'`. A test file needs only one of the two modules. If a single file ever tests both, import the namespaces instead (`import { Scene, Story } from 'foldkit'`) so `Story.given` and `Scene.given` stay distinguishable.
 
 Name each test file for its test style, beside the code under test: `story.test.ts` for the Story tests (which drive `update`) and `scene.test.ts` for the Scene tests (which drive the rendered view). The name describes how the test works, not a source file, so it stays correct whether `update` and `view` live in `main.ts` or in their own files. When one folder holds more than one test of a kind (sibling pages, component variants), prefix with the subject: `login.story.test.ts`. Scene tests always run from the root `update`/`view`, so a single root-level `scene.test.ts` is the right home even in a multi-page app. If the `repos/foldkit` subtree is available, study the `story.test.ts` and `scene.test.ts` files in `repos/foldkit/examples/`.