bitwrench 2.0.32 → 2.1.1

package/dist/sri.json

@@ -1,51 +1,59 @@
 {
-  "version": "2.0.32",
+  "version": "2.1.1",
   "algorithm": "sha384",
-  "generated": "2026-04-26",
+  "generated": "2026-07-15",
   "files": {
-    "bitwrench-bccl.cjs.js": "sha384-fm4zFar3/KSZQOnu2NcQvL2DYUPEF8/tUB9l41gvlGmck5X/5uTYFu2kNgaaA26q",
-    "bitwrench-bccl.cjs.min.js": "sha384-fEsank/EtCyR68QbgEUtH1psd1nkBb1VJLk45BEhEXPFls1toRUC2lZycYiy5hFc",
-    "bitwrench-bccl.esm.js": "sha384-wecVxRuSlMVtxfXy6SpvV3hXu8k7y/DISzM1E5IzaPTR2dBYDtYviHE97ozP2jv4",
-    "bitwrench-bccl.esm.min.js": "sha384-RSXcqzdjCGFG0F8Epk46vtkbNlmgakdbHq173zwsDJTHiQFEtrUbnzAeX7Pnl5l9",
-    "bitwrench-bccl.umd.js": "sha384-nS5TE4XMDoKVmCt8+yEwpZu18i2+V6QzT4nhOcLNIHtT+aE5oENbmzjvKHPgKpeu",
-    "bitwrench-bccl.umd.min.js": "sha384-N0MQ5cBPBi5gPbXEkbj9lj2fIS+HYJ9V/LJAdKJiCjK33Bo0/zseH46vXHhAIZTf",
-    "bitwrench-code-edit.cjs.js": "sha384-tuXJYkD/sqwV1GCmIuoP2o75V8XNZRCRqBKhCjYmUgg3QuZ3ZBtpPo23WjyddJvA",
-    "bitwrench-code-edit.cjs.min.js": "sha384-ngqdXykvURrYAUvEzwhZVdw8oSj7FOnL0qFY0JulD7aSAlfn5JFPZOHTXl0NhIK0",
-    "bitwrench-code-edit.es5.js": "sha384-XeXDSvblUT6/54AfgvVZvtGAeGz+cdxveRu/Aq1XXfPL0HgzkpnV09BnCVLXIiLW",
-    "bitwrench-code-edit.es5.min.js": "sha384-Tqju598rz/V9wjuUXb5RhUUPHI6eTE0JlUVUZM9DlIEQHmLCfGgaRRMyJfXQpsP9",
-    "bitwrench-code-edit.esm.js": "sha384-mtq5V7Ui3KGDryxGWU4Jqkj1r/L+U0nNXzbkp5QphkV0c8PHfrguQ0IvVVZkhwKu",
-    "bitwrench-code-edit.esm.min.js": "sha384-EZ8Uy2kOeTJivj9bSjXXIGiVHkoe5oVXGbsbf/1LxvuBz2WyyJnFo96Xcn8kYD7O",
-    "bitwrench-code-edit.umd.js": "sha384-9BonoA/PJugxXVfIKr8l/kihj7KvJI6xshuH42U66A9Az7rbVAZQ4s2JZnI6Gbrm",
-    "bitwrench-code-edit.umd.min.js": "sha384-1D3g7bae01at7MMizZlahUD5IHbNXzozrtePL8CPNa+UOAQeIhSpmCMW1lntGztu",
-    "bitwrench-debug.js": "sha384-5EkF/Cef5HDCw+yQ/AGJRDzMLFjwoJkdTByXC/o0Zsw/ap0ZT1Yc4Wr+sQCz1m6U",
-    "bitwrench-debug.min.js": "sha384-ZQPh4z4LD6ykxD5hCn9E4hUnyn35ZXa4FtF/dg8m93J/jmpG5VZNqNT6u5Y7sA6P",
-    "bitwrench-lean.cjs.js": "sha384-iDCwAaIs4NebdLE9S9S/GNNIMkWVAh00klHSVsdAX1gL0Y76xKw/tDX2lAjpbWO+",
-    "bitwrench-lean.cjs.min.js": "sha384-xZA3ZXEFVXHs6jrAtjUdJToCThXA6hj8zP247vn044FQBJ9ngNTIX14nUm1DK9A/",
-    "bitwrench-lean.es5.js": "sha384-75O3mZrFRf7n5d7DwrTMhxDL5DewH6uly/jvwahUF1dToVYtG2Iu3s/eofkHf0Pr",
-    "bitwrench-lean.es5.min.js": "sha384-Dai/3Rb6qXYvLirAwePAXrRnejdXm2xmupf0NbnyEYphkHPLL6J7dAQjWasCopHt",
-    "bitwrench-lean.esm.js": "sha384-SocmGevK+OW6CQqdahu4Qsg5+9c0DAsHwL9k9Y+zTvbjJSLF6CJeRnMJb7o5nkK7",
-    "bitwrench-lean.esm.min.js": "sha384-e6uhgikkdh1x/MOKiTD1mTYZ7tTU4NUJl0HCljYsnLP3yN+uTNx93ekhxmbYgfDh",
-    "bitwrench-lean.umd.js": "sha384-sOypmarFMiIbl+sC0CJusIUdUFN/j2WogkGvmGhoB8yC7XoBe/DKajRkF8RiWibi",
-    "bitwrench-lean.umd.min.js": "sha384-CTMjnWZhncKenL6e7Vk0wvNELUPkHqHl3YlvspR0n+7OParJqIEkPt1tGXhChMPy",
-    "bitwrench-util-css.cjs.js": "sha384-gerlRoXtra87zahLjt228sBeSPL2+nYGoLveS379diioI7MgwN1mTVuMb5RK1xaf",
-    "bitwrench-util-css.cjs.min.js": "sha384-C1zpPjlUL/R1xnIybV90VTNYl/F6j6F3TaPcPns7zfmkg+Xun+AkF5NKVRTlD1Cj",
-    "bitwrench-util-css.es5.js": "sha384-MDazdsxvfVUMjTQ/recckKIwTyefUEW/UKAvEgaqyW9Frj7R2WjiiHn4Ikjz9M22",
-    "bitwrench-util-css.es5.min.js": "sha384-coYGdR9MP/ldzY3/j+FQTb9UxbYNk2K806voG8PY5tHG9RU1bnrZqa6FouV7trD9",
-    "bitwrench-util-css.esm.js": "sha384-1yE/wlyGSSIu2yMlxdSHeA5U+0XNt50kqrCdOnUp5ph88tHMUv3MwxoBnetc2gCZ",
-    "bitwrench-util-css.esm.min.js": "sha384-tRB0z5KnuxWkkPq+qW7gJj2+SuOlXkc6hH3ip962GZsQGjgc4P9SsQTIed1IWbpw",
-    "bitwrench-util-css.umd.js": "sha384-HbFyByrgtpsOVL3lvZtse8fAqsQqLbU4Ow+Z7oEA+AiKHGxZaDuF+rznFH0J30+3",
-    "bitwrench-util-css.umd.min.js": "sha384-8UAqTLqrCHVr8s5/OS1qTp6DDskm/RxvBZ0xhsf12c9LIeuF7kMr8ZIXqN79scpk",
-    "bitwrench.cjs.js": "sha384-Ci2BIUNMP9Q7wl2w6+0HMO3eQL5AyMQl9YLAEEmB/Ja9c+RTMFlg+EZ1vbqJ1DOf",
-    "bitwrench.cjs.min.js": "sha384-B//xIia0t3lGcAU7c28ne9RSpov2OuOmAXynlmG5MR5gQUBejnTUhqAy36+ya51n",
-    "bitwrench.css": "sha384-SDv/NXaJpEnyfH1/lwbUjgUZXRrNM7JJrhkQeSIQrbr0bfp4UO3TaWI4OXCW1wYb",
-    "bitwrench.es5.js": "sha384-rQfMtRZJF51qE/N7OqBUYXUqgyROYNxsVUyZdc9/M6KH+IsSpafZvIDB86tExKV5",
-    "bitwrench.es5.min.js": "sha384-Y75wnUbt8MWe2v0SoVXWoQ84zVpMcaw6yOMdEjKLNuA4xQvrpxAHwz1zR3Cfd9rS",
-    "bitwrench.esm.js": "sha384-D62HkkwghT7OrRZf4ndEwdzmCJIJbWjuHoy2RLqDG0Edaoz2tJkJk5ZvbNK+Lm76",
-    "bitwrench.esm.min.js": "sha384-rSqI2lgJzv/V5Ij1jypuTU/AeQ8ba1NbM84tLMrP/wCEJnCiCrfNAOEagt2sSXB8",
-    "bitwrench.min.css": "sha384-4ymUTaU2kwrsPLCsEGReVJe2rGzsHkNG1BjrHB7EGAOqMK+SgRvaHPoYUFk7tXSE",
-    "bitwrench.umd.js": "sha384-uuSgbN2ItPiqasHNeGd3B99n0NWG0bvmLJHtGlUX+BxAAyPf7fV1V5Sr1Cpaac5v",
-    "bitwrench.umd.min.js": "sha384-lt/nabWEOxYufCHBZYnYPi6i2tKQLauBh/+1/QuMN9PCaXCzd5Ejrtw9TvBoixrO",
-    "bwserve.cjs.js": "sha384-mcUPopJ35fxJOI6/ctgHdC7BjQzpxgY4Omyr+KQRxbu0YX6f9o/A65oOwuG0VXjP",
-    "bwserve.esm.js": "sha384-bacd5UtYAlD1EbFny1eDfFF8Jg8Vr67TtyhMALN5rWdAMu9ubGOBVH+Z4RGxkiM/"
+    "bitwrench-bccl.cjs.js": "sha384-B0aQIxXhxcyrAlix+j4UC8K7oKG/dVwC0Oe1/wmqTEdn8b1KIfnl3b0uumIEguGc",
+    "bitwrench-bccl.cjs.min.js": "sha384-oE3RnWAqbgoD3hV8KMScq3IYNj8lhl5aqBgbPwqnSN18NygVuXxYgt4JgJ/P3a3a",
+    "bitwrench-bccl.esm.js": "sha384-Y4N70nFgy6szh6GDz5WakwlcFe1YdB0pm9qmhDT0vFgvEYK/AXtMeCkbRFZa4bKS",
+    "bitwrench-bccl.esm.min.js": "sha384-/u3kujGMJ2CgT0EiXEg3rs1PjIODUu0uP0pqxBpD9bjkFcgmd9uS/N3RpZ/Kl9eO",
+    "bitwrench-bccl.umd.js": "sha384-LwgwBffGNjOgw98QUogo1mvT+KIRkgfDchIBxm3cpObrFat8qXdw9vhk1fcLrYvd",
+    "bitwrench-bccl.umd.min.js": "sha384-RkYOxXKlcnZvfR1cqPK6dlszvtyIhJ0u4SKnjgdV7YmTmvEexVVrcHiYT+ZTJZ4o",
+    "bitwrench-code-edit.cjs.js": "sha384-5xtpD4Hdaxr2qBRbhFgwtBTPWQ9UGh1Vb9drHKMNmTs/HYYnEByhz+nf/Okv9ILi",
+    "bitwrench-code-edit.cjs.min.js": "sha384-jdom5FXkU52Y2dEZY+T6nghl403ARZDzJN5mrlwfcO88xTm3HIHohhb1GUfXV2py",
+    "bitwrench-code-edit.es5.js": "sha384-lZWGCR5cf7mDhoK1P+ZC8XdU7PBtg+ATnZ3FLCBqV1U8pi5KowozoXaUqlw5jHdb",
+    "bitwrench-code-edit.es5.min.js": "sha384-56hIGJN49aKfPphqK3jlHfLWiCk71nVTj3q82P3EOcmzvIS1ECGlD9e5CtaTCIIm",
+    "bitwrench-code-edit.esm.js": "sha384-MRKH7iiNKgtAA+QJPYppQpvIXnT8iU5jeD5+pOmcz9D9YC2UAMwNvi+tEmAKlD7S",
+    "bitwrench-code-edit.esm.min.js": "sha384-Oj5ZgB9aeUmKMGq4h+MqCvFpw6pyOTzzTaJXEZRQX1Z768fz8cweyjV68Fqtx9Xm",
+    "bitwrench-code-edit.umd.js": "sha384-JndphcsfDanAFd5WDfxm4Po/Y9Pe9iNoY4Bwiu2VcSHge1oWHkdCLxD9Q7IIy2U4",
+    "bitwrench-code-edit.umd.min.js": "sha384-R1LGH2VGWZFcnWN+HXrrGbJUUQOVvkoooeh9AqFyCbDVUBtbu/pSd2kbR/BMtFGW",
+    "bitwrench-debug.js": "sha384-tMsS8YNpnWx+t4DEZX6JoSoYFHA7SjlnjPROmOMQVn/CVFtQWl5yL66pF+bNLh/6",
+    "bitwrench-debug.min.js": "sha384-ClXhaom0UNWzEzMbq3oaahMjO87BNjFu+7rLEI/FRG7DZLtp2vzr2dINQXGEsuCz",
+    "bitwrench-lean.cjs.js": "sha384-cqGEqf6HhVCj042PoSCRWhcQdOkMN4livX/HwK8ChVHX6ub0WnWdKhcvvrajSabf",
+    "bitwrench-lean.cjs.min.js": "sha384-B7kFM0sE9tmkYGprcwG2j9/fy4j4RtsaTnXiulO0gY6dBm8GoEfniTITKNeVir60",
+    "bitwrench-lean.es5.js": "sha384-sN/rWICehichsCcBxMUwA2Crkuz4JcIu2hOIByXnNktG5dzeiwJTtHzcIo2GDFBe",
+    "bitwrench-lean.es5.min.js": "sha384-cupxyMkbBM35mP97l7v+65Pu9g1QxP6J7Hlh+7EsOsE+s0sJxuY4tnHD3zqs76GL",
+    "bitwrench-lean.esm.js": "sha384-meRyTgeHW04mZOTyWwHAo+PBgs2zYSQuxurJWUWBhNXRU7HHbmMT/d4aCo/ALWHj",
+    "bitwrench-lean.esm.min.js": "sha384-LIPDtrKXNP1FBwNwqyQWeLCJlvWkVbJDIsGqZqlVxwsGhidq64phTwKoXFrRv+Ad",
+    "bitwrench-lean.umd.js": "sha384-o6YpWpqHVxfqHlJ6snSDb9TgdynZoIfgG0C3+iaI1joZGe6JJGTkMkN5tEc1yGpH",
+    "bitwrench-lean.umd.min.js": "sha384-sZQ7rNCvzu6db3bFonVOkZRn3jQiIfSPBYh5nqrnZwf5sNYKiX4y/HCUg3uqXPPC",
+    "bitwrench-util-color.cjs.js": "sha384-xhNNGd3AcHdh93qURLsapQVDhkjvARGUCc7nyJ0w22g8exk48hQJaYkCaIz+D/to",
+    "bitwrench-util-color.cjs.min.js": "sha384-wV0yhsO7QMkeQ39yAacwRzaSJOELAbwKaYLyFUTSL94VBoNK1J5hcaK4kglabtdw",
+    "bitwrench-util-color.es5.js": "sha384-vr/EQBigtmIOxwXzEGmqUiMlMgGR7AlQySEgWuTFzW4X+0o1rAHBJb6+4J2BxrTN",
+    "bitwrench-util-color.es5.min.js": "sha384-jGAyJ7VONHCW5Mg002ehyDR9/7L84j5iDWj6HVXUTO1KZEUokY5pLAJgVP8Zd31u",
+    "bitwrench-util-color.esm.js": "sha384-veGQ0Sdn5YSUIGlcvJA5FCgzL5aRxLjYcNtWa1qe/8gJ0mg+AQrn4QRi9Ik2gLwG",
+    "bitwrench-util-color.esm.min.js": "sha384-z83iY/YxP+Vy4rh8b42lnI5VUcrRrypFEUnT0gfHLlqKZ0ecqa+liQfgTAjXR+c/",
+    "bitwrench-util-color.umd.js": "sha384-YIIeopsm4OKn6AIEelm10wEKsdQY4HRAzMT/QmYOg+j4BSHurT4mdClUGNpFgwPb",
+    "bitwrench-util-color.umd.min.js": "sha384-XTVxvWBmjZdZa+2jZPTqwTimVCahhHkUoe/7ek3P/v2dHhNqaIKlqDbctEJ38+u+",
+    "bitwrench-util-css.cjs.js": "sha384-JqkhxHMrnFcB2UvZp3XzO5d7V/6DJK8HYhAdMWIIcgHioKVbE6L4O8viVymCXwj8",
+    "bitwrench-util-css.cjs.min.js": "sha384-r35+UKdAKgJizYYRebm5g+7RVlNTSAbO9ikhRY1Nc7Kelc3JlZPJI1V0IYJWm51q",
+    "bitwrench-util-css.es5.js": "sha384-4camXftDKDboxTqDSi5sMCAIBLu1UbpsPYjxAYR9GghuY+iRAFJaq7En5OaQPyVM",
+    "bitwrench-util-css.es5.min.js": "sha384-qQ9eOtZu7mSAa2ItOPnHDk0M2En44Et9Rd7ndoNz1eFHNf7jqlEtBHBYw05ld/8E",
+    "bitwrench-util-css.esm.js": "sha384-m0Ws+mQPHrcrTo2xvfpAGbPrzECuGtcfU5VwpgtuVmgP/7v5/FEVIolWGEwL1XKe",
+    "bitwrench-util-css.esm.min.js": "sha384-J3h0/oEd2/KZOFT94+v34E/NEOUhzgk7tnNazCOguUYdz1zTJFxIC3tefejDW9Li",
+    "bitwrench-util-css.umd.js": "sha384-4njrao8h2lxvSNG1rwCnRjQnaN23FbqvNQuEe82H6Xao0L2KVI2AfLW5UJndlic6",
+    "bitwrench-util-css.umd.min.js": "sha384-V+0Jsx5PDdCkoay8w8durao03+LOtFfrR7tJvhX95h2YprM3Sh/yMmdouSymc2/N",
+    "bitwrench.cjs.js": "sha384-223vCHCMFpVn3ebcLzmDhmnjIqpaMe3AcISs02i4qGYbHmnMrnkQmfg95i+l1YSC",
+    "bitwrench.cjs.min.js": "sha384-PxbnuQGZgfdu9dtaP6BE1CVRMG8sfMm7rO5tZgFqhVBUDIfHAChGHcXkgB4U3w/N",
+    "bitwrench.css": "sha384-nVkVjZaSm8VMx6f0M+cVwaGdjADq/GCwvpO8i6459LBSzKVDb1ezutgwx29kGqd5",
+    "bitwrench.es5.js": "sha384-O/K7lCnuhPN4t2Eg2bK/1QRm6Yy3hV9MyaCmPullUzZCXs5LrYTIoLwJyxTUN86R",
+    "bitwrench.es5.min.js": "sha384-+nprbfrs5bAbX0e1wX0UhQTIV8c1uEUjN4GeW9aGknKOpSEjP7t+H8ATChzbJeBr",
+    "bitwrench.esm.js": "sha384-kESLl4JnEZ6sbx5cX1KkAvDZ4kZ7COx/qMT5RJ5MNc4Udq0zXhtRGigQEzi2fJmX",
+    "bitwrench.esm.min.js": "sha384-onhcbWZ1mZlwZHJhSAkU7sEiTvyA4bLFxK1zH7WJ7nquBZflmux1LBxTbZclE0XA",
+    "bitwrench.min.css": "sha384-V5byv/NexwbnyMfiTCjVcPPRQpGLP9Ui5DZDl7CnsMgjEpsWY1hG/5j0RpcyXtxS",
+    "bitwrench.umd.js": "sha384-d43Dw8mMBWUe3qKHTuIT8mE9Gch/LtTM+W7JtOT66+rx7MNfuwN/Bw1nWx1TDU7P",
+    "bitwrench.umd.min.js": "sha384-u/z67Z5XNXTdYWkiEdFZkzZ3MP2Y/irNuZiNDVCr64T1dw8htMANy9BibXaeZ3lR",
+    "bwserve.cjs.js": "sha384-0HhE53O4G/J631OQb+bpHNYKc4Th3tldIiXl/04IJhvzbX+ykaQMmujz+JpDrLjZ",
+    "bwserve.esm.js": "sha384-W7uLFtAgyaLhIpmC9mjWXQMQijvjoEhlKadxO6AxRwx7M16YKoVRH6f37kC8fxr3"
   }
 }

package/docs/README.md

@@ -10,6 +10,7 @@ These guides cover how to build UIs with bitwrench.
 | How do I build a page? | [Building a Website tutorial](tutorial-website.md) |
 | How does TACO work? | [TACO Format](taco-format.md) or [Thinking in Bitwrench](thinking-in-bitwrench.md) |
 | How do I add interactivity? | [State Management](state-management.md) |
+| How does a component actually work? | [Component Lifecycle Walkthrough](component-lifecycle.md) |
 | How do I theme my app? | [Theming](theming.md) |
 | I'm an LLM generating bitwrench code | [LLM Guide](llm-bitwrench-guide.md) |
 | How do I use bwmcp with an AI agent? | [bwmcp MCP Server](bitwrench-mcp.md) |
@@ -18,7 +19,7 @@ These guides cover how to build UIs with bitwrench.
 
 ## Start Here
 
-- **[Thinking in Bitwrench](thinking-in-bitwrench.md)** -- The complete guide to building with bitwrench. Covers TACO basics, styling (`bw.css`, `bw.s`, `bw.responsive`), composition, the three-level component model, events (and why `onclick` goes in `a:`, not `o.mounted`), bwserve, and common patterns. **Read this first.**
+- **[Thinking in Bitwrench](thinking-in-bitwrench.md)** -- The complete guide to building with bitwrench. Covers TACO basics, styling (`bw.css`, `bw.s`, `bw.responsive`), composition, the component model, events (and why `onclick` goes in `a:`, not `o.mounted`), bwserve, and common patterns. **Read this first.**
 - **[LLM Guide](llm-bitwrench-guide.md)** -- Compact single-file reference for AI-assisted development. All APIs, patterns, and rules in one document. Also useful as a quick-reference cheat sheet for humans.
 
 ## Guides
@@ -27,7 +28,7 @@ These guides cover how to build UIs with bitwrench.
 |-------|-------------|
 | [Thinking in Bitwrench](thinking-in-bitwrench.md) | Design philosophy: why TACO exists, component model vs. DOM templates |
 | [TACO Format](taco-format.md) | The `{t, a, c, o}` object format that bitwrench uses for everything |
-| [State Management](state-management.md) | Three-level component model, reactive state, cross-component communication |
+| [State Management](state-management.md) | Component model, explicit stateful components, cross-component communication |
 | [Component Cheat Sheet](component-cheatsheet.md) | Scannable table of all components with capabilities and handles |
 | [Component Library](component-library.md) | All `make*()` functions with full signatures and examples |
 | [Routing](routing.md) | Client-side router: hash/history mode, route params, guards, pub/sub |
@@ -39,6 +40,7 @@ These guides cover how to build UIs with bitwrench.
 | [LLM Guide](llm-bitwrench-guide.md) | Compact single-file reference for AI-assisted development |
 | [TypeScript Usage Guide](bitwrench_typescript_usage.md) | Import patterns, typed configs, TACO types, tree-shaking |
 | [bwmcp MCP Server](bitwrench-mcp.md) | MCP server for AI agents: tool catalog, live rendering, screenshots |
+| [drift-lint](drift-lint.md) | Maintainer tool: keeps docs/examples consistent with the shipped API |
 
 ## Tutorials
 
@@ -47,6 +49,7 @@ These guides cover how to build UIs with bitwrench.
 | [Building a Website](tutorial-website.md) | Build a complete landing page from scratch |
 | [Server App with bwserve](tutorial-bwserve.md) | Build a Streamlit-style server-driven dashboard |
 | [ESP32 Embedded](tutorial-embedded.md) | ESP32 IoT dashboard with C/C++ macros |
+| [Component Lifecycle Walkthrough](component-lifecycle.md) | Stats card: define, create, mount, update, unmount — every phase of a v2.1 component |
 
 ## Interactive Docs
 
@@ -72,7 +75,7 @@ The library provides four things:
 
 1. **A rendering engine** that turns objects into HTML or DOM
 2. **A component library** of ready-made UI elements
-3. **A reactivity system** that updates the DOM when state changes
+3. **An explicit update model** — components live on the DOM element itself (`el.bw` methods, slots, `el._bw_state`), and updates happen when you call them (`el.bw.method()`, `bw.update()`, `bw.refresh()`)
 4. **A client-side router** that maps URLs to views with guards and pub/sub
 
 Everything else -- styling, theming, event handling, server communication -- builds on these pieces.

package/docs/app-patterns.md

@@ -139,24 +139,24 @@ var app = bwserve.create({ port: 7902 });
 var count = 0;
 
 app.page('/', function(client) {
-  client.render('#app', {
+  client.mount('#app', {
     t: 'div', c: [
       { t: 'h1', c: 'Server Counter' },
       { t: 'span', a: { id: 'val' }, c: '0' },
-      { t: 'button', a: { 'data-bw-action': 'inc' }, c: '+1' }
+      { t: 'button', a: { class: 'bw_act_inc' }, c: '+1' }
     ]
   });
 
   client.on('inc', function() {
     count++;
-    client.patch('val', String(count));
+    client.patch('val', { text: String(count) });
   });
 });
 
 app.listen();
 ```
 
-**State flow:** Browser requests `/` => server returns HTML shell. Shell opens SSE => server sends TACO via `client.render()`. User clicks `data-bw-action` => browser POSTs to server. Server calls `client.patch()` => browser updates. All state stays on the server. See [bwserve.md](bwserve.md).
+**State flow:** Browser requests `/` => server returns HTML shell. Shell opens SSE => server sends TACO via `client.mount()`. User clicks a `bw_act_*` classed element => browser POSTs to server. Server calls `client.patch()` => browser updates. All state stays on the server. See [bwserve.md](bwserve.md).
 
 ---
 
@@ -189,7 +189,8 @@ bw.DOM('#app', { t: 'div', c: [
   }})
 ]});
 
-// Poll the device -- re-render readings section each cycle
+// Quick prototype: poll + full re-render. For production, use SSE
+// with bw.patch() instead -- see tutorial-embedded.md for the SSE version.
 setInterval(function() {
   fetch('/api/sensors').then(function(r) { return r.json(); })
     .then(function(data) {
@@ -244,7 +245,7 @@ Each output is self-contained with bitwrench embedded inline. No CDN, no toolcha
 |----------|---------|---------|
 | Monitoring dashboard, admin panel | Single-Page Dashboard | `bw.pub/sub`, `bw.DOM()`, `makeStatCard` |
 | Multi-view app with URL navigation | Multi-Page SPA | `bw.router()`, `bw.navigate()` |
-| Server owns all logic (internal tool, LLM UI) | bwserve Server-Driven | `client.render()`, `client.patch()` |
+| Server owns all logic (internal tool, LLM UI) | bwserve Server-Driven | `client.mount()`, `client.patch()` |
 | Microcontroller or constrained device | Embedded / IoT | `bw.DOM()`, `fetch()` polling or SSE |
 | Documentation, blog, project pages | Static Site (bwcli) | `bwcli`, `--theme`, `--standalone` |
 | Prototype or quick one-off | Single-Page Dashboard | One HTML file, no build step |

package/docs/bitwrench-for-wasm.md

@@ -52,7 +52,7 @@ Each boundary crossing has overhead: type marshaling, memory copying, function d
 
 ### An alternative: batch the boundary
 
-A different approach is to cross the boundary **once per render, not once per DOM operation.** The WASM module builds a TACO object (a JSON-serializable data structure) and sends it across the boundary as a single message. The JS-side library materializes the entire tree in one shot using `bw.createDOM()` or `bw.DOM()`.
+A different approach is to cross the boundary **once per render, not once per DOM operation.** The WASM module builds a TACO object (a JSON-serializable data structure) and sends it across the boundary as a single message. The JS-side library materializes the entire tree in one shot using `bw.create()` or `bw.DOM()`.
 
 ```
 WASM side                           JS side (bitwrench)
@@ -72,7 +72,7 @@ Serialize to JSON string            |
 
 100 elements = 1 crossing, not 300+. The DOM operations happen inside JS where they're native function calls with zero marshaling overhead.
 
-For incremental updates, the same principle applies. Instead of diffing an entire virtual tree across the boundary, the WASM module sends a targeted patch message: `{type: 'patch', target: '#counter', content: '42'}`. One crossing, one DOM mutation.
+For incremental updates, the same principle applies. Instead of diffing an entire virtual tree across the boundary, the WASM module sends a targeted patch message: `{v: 1, type: 'patch', ref: '#counter', text: '42'}`. One crossing, one DOM mutation.
 
 ---
 
@@ -117,7 +117,7 @@ The fourth key, `o:`, contains JavaScript-specific concerns: lifecycle hooks (`m
 
 For WASM, this split is a natural fit: the **specification** (what to render) crosses the boundary as data, while the **behavior** (DOM event handling, lifecycle management) stays in JS where DOM access is native.
 
-For cases where the WASM module needs to define behavior, bwserve provides `register` and `call` -- send a function string once, invoke it by name later. This keeps the boundary thin while allowing the WASM side to install client-side logic when needed.
+For cases where the WASM module needs to invoke client-side behavior, bwserve provides `call` -- invoke a named built-in function (e.g., `scrollTo`, `focus`, `download`). Code-bearing verbs (`register`, `exec`) were removed in v2.1; client-side logic should be pre-installed via the JS glue or BCCL component handles.
 
 ---
 
@@ -127,19 +127,18 @@ bwserve is bitwrench's server-driven UI protocol. It was originally designed for
 
 ### The protocol
 
-Nine message types. Five for DOM operations, three for code execution, one for component dispatch:
+All messages are stamped with `v: 1`. The v2.1 protocol has the following verb set (code-bearing verbs `exec`, `register`, and `query` were removed):
 
 | Type | What it does | Example |
 |------|-------------|---------|
-| `replace` | Replace element subtree | `{type:'replace', target:'#app', node:{t:'div', c:'Hello'}}` |
-| `patch` | Update text or attributes | `{type:'patch', target:'counter', content:'42'}` |
-| `append` | Add child element | `{type:'append', target:'#list', node:{t:'li', c:'New'}}` |
-| `remove` | Delete element | `{type:'remove', target:'#old'}` |
-| `batch` | Multiple operations | `{type:'batch', ops:[...]}` |
-| `register` | Send named function | `{type:'register', name:'scroll', body:'function(s){...}'}` |
-| `call` | Invoke function by name | `{type:'call', name:'scroll', args:['#chat']}` |
-| `exec` | Run arbitrary JS | `{type:'exec', code:'document.title="Hi"'}` |
-| `message` | Component dispatch | `{type:'message', target:'#card', action:'setTitle', data:'New'}` |
+| `mount` | Mount TACO at selector | `{v:1, type:'mount', ref:'#app', taco:{t:'div', c:'Hello'}}` |
+| `patch` | Update text or attributes (discriminated fields) | `{v:1, type:'patch', ref:'counter', text:'42'}` |
+| `append` | Add child element | `{v:1, type:'append', ref:'#list', taco:{t:'li', c:'New'}}` |
+| `remove` | Delete element | `{v:1, type:'remove', ref:'#old'}` |
+| `batch` | Multiple operations | `{v:1, type:'batch', ops:[...]}` |
+| `call` | Invoke a named built-in function | `{v:1, type:'call', name:'scrollTo', args:['#chat']}` |
+| `message` | Component dispatch | `{v:1, type:'message', ref:'#card', action:'setTitle', data:'New'}` |
+| `listen` | Subscribe to a pub/sub topic | `{v:1, type:'listen', topic:'bw:lifecycle'}` |
 
 ### The full loop
 
@@ -148,12 +147,12 @@ WASM Module (application)           Browser (display server)
 -------------------------           -----------------------
 State + logic                       bitwrench + bwserve client
   |                                   |
-  |-- replace: full render -------->  bw.apply() -> bw.DOM()
+  |-- mount: full render ---------->  bw.apply() -> bw.mount()
   |-- patch: targeted update ------>  bw.apply() -> bw.patch()
   |-- call: scroll, focus, etc. --->  bw.apply() -> invoke function
   |-- batch: multiple ops --------->  bw.apply() -> sequential
   |                                   |
-  <-- event: {target, type, data} --  subscribed listener fires
+  <-- event: {ref, type, data} ----  subscribed listener fires
   <-- screenshot: PNG buffer -------  html2canvas -> POST-back
 ```
 
@@ -292,7 +291,7 @@ WASM server binary                  Browser
   |                                   |
   |-- GET / -> HTML shell ---------->|
   |-- GET /bw/events -> SSE -------->|
-  |-- SSE: replace/patch/etc ------->| bw.apply() -> DOM
+  |-- SSE: mount/patch/etc -------->| bw.apply() -> DOM
   |<-- POST /bw/return/action -------|
   |<-- POST /bw/return/screenshot ---|
 ```
@@ -319,16 +318,16 @@ use serde_json::json;
 
 fn render_dashboard(state: &AppState) -> String {
     json!({
-        "t": "div", "a": {"class": "bw-container"}, "c": [
+        "t": "div", "a": {"class": "bw_container"}, "c": [
             {"t": "h1", "c": &state.title},
-            {"t": "div", "a": {"class": "bw-row"}, "c": [
+            {"t": "div", "a": {"class": "bw_row"}, "c": [
                 stat_card("Users", &state.users.to_string(), "primary"),
                 stat_card("Revenue", &format!("${}", state.revenue), "success"),
                 stat_card("Orders", &state.orders.to_string(), "info")
             ]},
             {"t": "button", "a": {
                 "id": "refresh-btn",
-                "class": "bw-btn bw-btn-primary"
+                "class": "bw_bccl_btn bw_primary"
             }, "c": "Refresh"}
         ]
     }).to_string()
@@ -336,9 +335,9 @@ fn render_dashboard(state: &AppState) -> String {
 
 fn stat_card(label: &str, value: &str, variant: &str) -> serde_json::Value {
     json!({
-        "t": "div", "a": {"class": format!("bw-stat-card bw-stat-card-{}", variant)}, "c": [
-            {"t": "div", "a": {"class": "bw-stat-card-value"}, "c": value},
-            {"t": "div", "a": {"class": "bw-stat-card-label"}, "c": label}
+        "t": "div", "a": {"class": format!("bw_bccl_stat_card bw_{}", variant)}, "c": [
+            {"t": "div", "a": {"class": "bw_bccl_stat_card_value"}, "c": value},
+            {"t": "div", "a": {"class": "bw_bccl_stat_card_label"}, "c": label}
         ]
     })
 }
@@ -372,22 +371,22 @@ pub fn div(attrs: Value, children: Vec<Value>) -> Value {
 pub fn button(label: &str, id: &str) -> Value {
     json!({
         "t": "button",
-        "a": {"id": id, "class": "bw-btn bw-btn-primary"},
+        "a": {"id": id, "class": "bw_bccl_btn bw_primary"},
         "c": label
     })
 }
 
-// bwserve protocol messages
-pub fn msg_replace(target: &str, node: Value) -> Value {
-    json!({"type": "replace", "target": target, "node": node})
+// bwserve v2.1 protocol messages (all stamped v:1)
+pub fn msg_mount(r: &str, taco: Value) -> Value {
+    json!({"v": 1, "type": "mount", "ref": r, "taco": taco})
 }
 
-pub fn msg_patch(target: &str, content: &str) -> Value {
-    json!({"type": "patch", "target": target, "content": content})
+pub fn msg_patch(r: &str, text: &str) -> Value {
+    json!({"v": 1, "type": "patch", "ref": r, "text": text})
 }
 
 pub fn msg_batch(ops: Vec<Value>) -> Value {
-    json!({"type": "batch", "ops": ops})
+    json!({"v": 1, "type": "batch", "ops": ops})
 }
 ```
 
@@ -397,7 +396,7 @@ With this helper:
 use taco::*;
 
 fn render(state: &AppState) -> String {
-    msg_replace("#app", div(
+    msg_mount("#app", div(
         json!({"class": "container"}),
         vec![
             text("h1", &state.title),
@@ -487,14 +486,14 @@ Standard JSON in C requires escaping every double quote:
 
 ```c
 // Standard JSON -- escape nightmare
-char msg[] = "{\"type\":\"patch\",\"target\":\"temp\",\"content\":\"23.5 C\"}";
+char msg[] = "{\"v\":1,\"type\":\"patch\",\"ref\":\"temp\",\"text\":\"23.5 C\"}";
 ```
 
 Bitwrench's r-prefix format uses single quotes:
 
 ```c
 // r-prefix relaxed JSON -- natural C strings
-char msg[] = "r{'type':'patch','target':'temp','content':'23.5 C'}";
+char msg[] = "r{'v':1,'type':'patch','ref':'temp','text':'23.5 C'}";
 ```
 
 `bw.parseJSONFlex()` on the browser side converts single quotes to double quotes before parsing. The `r` prefix signals the format.
@@ -505,16 +504,16 @@ char msg[] = "r{'type':'patch','target':'temp','content':'23.5 C'}";
 #include <stdio.h>
 #include <string.h>
 
-// Simple TACO builder macros for fixed-size buffers
-#define BW_PATCH(buf, target, content) \
+// Simple TACO builder macros for fixed-size buffers (v2.1 wire protocol)
+#define BW_PATCH(buf, ref, text) \
     snprintf(buf, sizeof(buf), \
-        "r{'type':'patch','target':'%s','content':'%s'}", \
-        target, content)
+        "r{'v':1,'type':'patch','ref':'%s','text':'%s'}", \
+        ref, text)
 
-#define BW_REPLACE(buf, target, taco) \
+#define BW_MOUNT(buf, ref, taco) \
     snprintf(buf, sizeof(buf), \
-        "r{'type':'replace','target':'%s','node':%s}", \
-        target, taco)
+        "r{'v':1,'type':'mount','ref':'%s','taco':%s}", \
+        ref, taco)
 
 // TACO builders
 #define TACO_TEXT(buf, tag, text) \
@@ -557,11 +556,11 @@ const char* render() {
     float temp = read_sensor();
 
     snprintf(buf, sizeof(buf),
-        "r{'type':'replace','target':'#app','node':"
+        "r{'v':1,'type':'mount','ref':'#app','taco':"
         "{'t':'div','c':["
             "{'t':'h1','c':'Sensor Dashboard'},"
             "{'t':'p','a':{'id':'temp'},'c':'%.1f C'},"
-            "{'t':'button','a':{'id':'toggle-btn','class':'bw-btn'},"
+            "{'t':'button','a':{'id':'toggle-btn','class':'bw_bccl_btn'},"
                 "'c':'Toggle LED'}"
         "]}}", temp);
 
@@ -601,7 +600,7 @@ AI models typically output structured data -- JSON, function calls, tool use. TA
 {"t": "div", "c": [
   {"t": "h2", "c": "Analysis Results"},
   {"t": "p", "c": "Found 3 anomalies in the dataset."},
-  {"t": "div", "a": {"class": "bw-card"}, "c": [
+  {"t": "div", "a": {"class": "bw_bccl_card"}, "c": [
     {"t": "h3", "c": "Anomaly #1"},
     {"t": "p", "c": "Temperature spike at 14:32 UTC"}
   ]},
@@ -619,7 +618,7 @@ bwserve's screenshot capability closes the loop. The AI generates UI, the browse
 AI Model (WASM)                     Browser
 -----------                         -------
 Generate TACO spec                  |
-  |-- replace: render UI -------->  bw.DOM() -> visible page
+  |-- mount: render UI ---------->  bw.apply() -> visible page
   |                                 |
   |-- screenshot request -------->  html2canvas -> capture
   <-- PNG image data -------------|
@@ -629,7 +628,7 @@ Evaluate screenshot                 |
    text overflow? wrong layout?)    |
   |                                 |
 Generate refined TACO spec          |
-  |-- replace: updated UI ------->  bw.DOM() -> improved page
+  |-- mount: updated UI --------->  bw.apply() -> improved page
 ```
 
 bwserve implements `client.screenshot()` for this purpose -- it sends a `call` message that triggers `html2canvas` on the client, which captures the DOM to a canvas, converts to PNG, and POSTs the image data back to the server. The server resolves a Promise with the image buffer.
@@ -673,10 +672,10 @@ fn agent_step(state: &AgentState) -> Vec<Value> {
     let mut messages = vec![];
 
     // Main content area -- task-specific UI
-    messages.push(msg_replace("#main", render_task_ui(&state.current_task)));
+    messages.push(msg_mount("#main", render_task_ui(&state.current_task)));
 
     // Sidebar -- agent's reasoning visible to user
-    messages.push(msg_replace("#sidebar", render_reasoning_log(&state.log)));
+    messages.push(msg_mount("#sidebar", render_reasoning_log(&state.log)));
 
     // Status bar -- progress and controls
     messages.push(msg_patch("status", &format!(
@@ -730,7 +729,7 @@ One patch message, one DOM mutation. The WASM module communicates what it alread
 
 Desktop UI toolkits (MFC, Swing, Qt, Cocoa) used targeted updates rather than tree diffing. In MFC, `SetWindowText("New Title")` repainted the control's title. In Swing, `label.setText("43")` updated one label. In Qt, signal-slot connections trigger specific updates. The application tracked what changed and told the framework directly.
 
-bitwrench follows the same pattern: `el.bw.setTitle('New')` updates one component, `bw.patch('#counter', '43')` updates one element, `client.patch('counter', '43')` sends one message. The application (or the WASM module) is the source of truth about what changed.
+bitwrench follows the same pattern: `el.bw.setTitle('New')` updates one component, `bw.patch('#counter', '43')` updates one element, `client.patch('counter', {text: '43'})` sends one message. The application (or the WASM module) is the source of truth about what changed.
 
 React's diffing approach solved a real problem -- in large JS applications with shared mutable state, manually tracking dependencies is error-prone. Whether that tradeoff applies to a given WASM application depends on the application's complexity and state management approach.
 
@@ -740,7 +739,7 @@ If your WASM module genuinely doesn't know what changed -- for example, if it re
 
 1. Diff the **data** in WASM (compare old state to new state)
 2. Emit targeted patches for what changed
-3. Or, for small enough UIs, just re-render with `replace` -- `bw.DOM()` is fast enough for most subtrees
+3. Or, for small enough UIs, just re-render with `mount` -- `bw.DOM()` is fast enough for most subtrees
 
 Diffing data in WASM (where you have typed structs and linear memory) is cheaper than diffing virtual DOM trees in JS (where everything is heap-allocated objects with GC pressure).
 
@@ -762,7 +761,7 @@ These are the most direct alternatives. They run a component framework inside WA
 | Accessibility | Manual | Browser-native (real HTML) |
 | Server rendering | Framework-specific SSR | bw.html() or bwserve |
 | Learning curve | Rust + framework | Rust + TACO (4 keys) |
-| Bundle size | ~200KB+ (framework + app) | ~40KB (bitwrench) + app WASM |
+| Bundle size | ~200KB+ (framework + app) | ~45KB (bitwrench) + app WASM |
 
 The fundamental difference is where the component model lives. Yew/Leptos/Dioxus place it in WASM (Rust macros, reactive primitives, virtual DOM). The bitwrench approach places it in JS (TACO rendering, CSS generation, component handles) and uses JSON as the interface between the application language and the renderer.
 
@@ -770,7 +769,7 @@ The fundamental difference is where the component model lives. Yew/Leptos/Dioxus
 
 | Concern | Blazor | bitwrench + WASM |
 |---------|--------|------------------|
-| Runtime payload | 2-5MB (.NET in WASM) | ~40KB (bitwrench) |
+| Runtime payload | 2-5MB (.NET in WASM) | ~45KB (bitwrench) |
 | Component model | Razor templates (.NET) | TACO JSON |
 | DOM access | JS interop bridge | Batched via bw.apply() |
 | Language | C# only | Any (Rust, C, C++, Go, ...) |
@@ -786,7 +785,7 @@ Blazor bundles a language runtime in WASM. The bitwrench approach does not requi
 | Backend | Native process (Rust/Node) | WASM (in-browser or server) |
 | Frontend | You write JS/React/Vue | TACO from any language |
 | Distribution | App store / download | Link sharing |
-| Bundle size | 10-100MB+ | Page weight (~40KB + WASM) |
+| Bundle size | 10-100MB+ | Page weight (~45KB + WASM) |
 
 Tauri and Electron are designed for desktop application distribution. If the UI can be served as a web page, the packaging and distribution step is not needed -- the tradeoff is losing native OS integration (system tray, menus, file system access without permissions).
 
@@ -811,8 +810,8 @@ Canvas-based approaches bypass the browser's built-in UI capabilities. Generatin
 
 - Browser-native UI (real HTML/CSS) from any language that produces JSON
 - Batched boundary crossing -- one message per render, not one per DOM op
-- 9-verb protocol (bwserve) for remote UI control including screenshots
-- ~40KB client library with 30+ components, CSS generation, theming
+- Structured protocol (bwserve, v:1 stamped) for remote UI control including screenshots
+- ~45KB client library with 30+ components, CSS generation, theming
 - No build step on the JS side
 - Same application code can target in-page WASM, Worker, or native server
 - Browser capabilities preserved: accessibility, text selection, CSS layout, forms
@@ -823,7 +822,7 @@ Canvas-based approaches bypass the browser's built-in UI capabilities. Generatin
 
 - **No automatic change detection.** You must know what changed and say so. (This is usually trivial in WASM where you just ran the mutation.)
 - **No type-safe TACO builder in Rust/C** -- you're building JSON. A helper crate/header can add convenience, but there's no compile-time guarantee that your TACO is valid. (bitwrench is lenient -- invalid fields are silently ignored.)
-- **No client-side routing from WASM.** The browser-side `bw.router()` exists for JS, but a WASM server would manage navigation via bwserve's `replace` messages.
+- **No client-side routing from WASM.** The browser-side `bw.router()` exists for JS, but a WASM server would manage navigation via bwserve's `mount` messages.
 - **No two-way data binding.** User events come back as structured messages (element ID, event type, value). You update your state and send a patch. This is the expected pattern for a boundary architecture.
 - **No animation primitives from WASM.** CSS animations and transitions work (they're in the browser), but you'd define them via `bw.css()` on the JS side or in a stylesheet, not from WASM.
 

package/docs/bitwrench-mcp.md

@@ -222,7 +222,7 @@ This costs about 200 tokens. Always call it first.
 ### Step 2: Learn (Optional but Recommended)
 
 If you have not used bitwrench before, call `bitwrench_guide`. This is the
-full tutorial (about 4000 tokens). It covers TACO nesting, the three-level
+full tutorial (about 4000 tokens). It covers TACO nesting, the
 component model, events, CSS/theming, all component categories, debugging,
 bwserve, routing, and API reference tables.
 
@@ -299,7 +299,7 @@ If using live rendering:
 ```
 screenshot({})           // see what the browser shows
 screenshot({selector: '.bw_stat_card:first-child'})  // zoom in on one element
-query_dom({code: 'document.querySelectorAll(".bw_card").length'})  // count cards
+query_dom({code: 'bw.$(\'.bw_bccl_card\').length'})  // count cards
 ```
 
 Evaluate the screenshot, decide what to change, and call `render_live` again.