tutuca 0.9.66 → 0.9.67

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tutuca",
-  "version": "0.9.66",
+  "version": "0.9.67",
   "type": "module",
   "description": "Zero-dependency SPA framework with immutable state and virtual DOM",
   "main": "./dist/tutuca.js",

package/skill/tutuca/core.md

@@ -332,11 +332,19 @@ Explicit field types via `classFromData`:
 
 ```js
 fields: {
-  count: { type: "int", defaultValue: 10 },     // text/int/float/bool/list/map/omap/set/any
-  child: { component: "Item", args: { ... } },  // nested component instance
+  count: { type: "int", defaultValue: 10 },       // text/int/float/bool/list/map/omap/set/any
+  child: { component: "Item", args: { ... } },    // deferred reference by name
+  child2: Item.make({ name: "" }),                // direct default if Item is in scope
 }
 ```
 
+The `{ component, args }` form is for when the referenced component is **not
+available** at field-definition time (forward reference, circular import).
+`component` must be the component **name as a string** — passing the class
+itself is a common mistake and is flagged by lint code
+`COMP_FIELD_BAD_SHAPE`. When the component class **is** in scope, prefer
+`ComponentName.make({...})` as the default value — no string indirection.
+
 ## Methods as Predicates & Computed Values
 
 A no-arg method called via `$name` is invoked and its return value is

package/skill/tutuca/testing.md

@@ -98,10 +98,11 @@ Comp.input.handlerName.call(comp, arg1, arg2, /* … */);
 You can call each one directly with `.call(comp, ...)`, but in practice
 you want to test them as a pipeline: filter + loop-data + enrichment
 together produce a list of bindings the view sees. Use
-`collectIterBindings` from `tutuca/dev` for that:
+`collectIterBindings` for that — a functional implementation only ships
+in the `tutuca-dev` build; the core `tutuca` build exports a no-op stub:
 
 ```js
-import { collectIterBindings } from "tutuca/dev";
+import { collectIterBindings } from "tutuca";
 
 const c = MyComp.make({ items: [...] });
 const r = collectIterBindings(MyComp, c, c.items, {

package/skill/tutuca-source/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: tutuca-source
+description: The bundled framework source (`dist/tutuca.ext.js`) wrapped as a skill so the agent can grep it. Use only when debugging — to confirm what the framework actually does, trace an error from the framework, or find the implementation of a method you saw in a stack trace. Always reach for `grep_skill_files` first, then `load_skill_file` with `startLine`/`endLine` to read a window around a hit. Not for component-authoring guidance — use the `tutuca` skill for that.
+---
+
+<!-- This file is generated by scripts/build-skill.js. Do not edit. -->
+
+# Tutuca source
+
+The bundled framework that ships to users — the ESM at `dist/tutuca.ext.js`.
+This skill exposes it as one file (`tutuca.ext.js`) so the agent can read
+the implementation when needed.
+
+## How to read it
+
+- It is **one large file** (~3.8K lines). Loading it whole will flood your
+  context — always `grep_skill_files("tutuca-source", "<pattern>")` first,
+  then `load_skill_file("tutuca-source", "tutuca.ext.js", { startLine, endLine })`
+  to pull a small window around a match.
+- It is the **bundled** output: ESM, not minified, no source map. Class and
+  function names match the original sources; comments do not survive.
+
+## When to use
+
+- A `lint_component` / `render_component` result mentions a framework
+  function or error string you don't recognise — grep for it.
+- A component crashes inside the framework — grep the error message or the
+  framework function in the stack trace.
+- A behavior is surprising and you want to confirm exactly what the framework
+  does, not what the docs say it does.
+
+**Don't** use this skill for *how to write* tutuca components — that's the
+`tutuca` skill. Reach here only when you need to read the implementation.