synthos 0.10.1 → 0.11.1

package/dist/themes.js.map

@@ -1 +1 @@
-{"version":3,"file":"themes.js","sourceRoot":"","sources":["../src/themes.ts"],"names":[],"mappings":";;;;;;AAAA,gDAAwB;AACxB,mCAAsG;AAGzF,QAAA,aAAa,GAAG,CAAC,CAAC;AAO/B,SAAS,gBAAgB,CAAC,MAAqB;IAC3C,OAAO,cAAI,CAAC,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,QAAQ,CAAC,CAAC;AACnD,CAAC;AAED;;;;GAIG;AACH,SAAgB,kBAAkB,CAAC,QAAgB;IAC/C,IAAI,CAAC,QAAQ,CAAC,QAAQ,CAAC,MAAM,CAAC;QAAE,OAAO,SAAS,CAAC;IACjD,MAAM,cAAc,GAAG,QAAQ,CAAC,KAAK,CAAC,qBAAqB,CAAC,CAAC;IAC7D,IAAI,cAAc,EAAE;QAChB,OAAO,EAAE,IAAI,EAAE,cAAc,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,QAAQ,CAAC,cAAc,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,EAAE,CAAC;KAChF;IACD,OAAO,EAAE,IAAI,EAAE,QAAQ,CAAC,OAAO,CAAC,QAAQ,EAAE,EAAE,CAAC,EAAE,OAAO,EAAE,CAAC,EAAE,CAAC;AAChE,CAAC;AAPD,gDAOC;AAED;;;GAGG;AACH,KAAK,UAAU,oBAAoB,CAAC,MAAqB,EAAE,MAAc,EAAE,IAAY;IACnF,MAAM,EAAE,GAAG,MAAM,CAAC,eAAe,CAAC;IAClC,IAAI,CAAC,MAAM,EAAE,CAAC,aAAa,CAAC,MAAM,CAAC;QAAE,OAAO,SAAS,CAAC;IACtD,MAAM,KAAK,GAAG,MAAM,EAAE,CAAC,SAAS,CAAC,MAAM,CAAC,CAAC;IACzC,IAAI,IAAmD,CAAC;IACxD,KAAK,MAAM,CAAC,IAAI,KAAK,EAAE;QACnB,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;QACrC,IAAI,MAAM,IAAI,MAAM,CAAC,IAAI,KAAK,IAAI,EAAE;YAChC,IAAI,CAAC,IAAI,IAAI,MAAM,CAAC,OAAO,GAAG,IAAI,CAAC,OAAO,EAAE;gBACxC,IAAI,GAAG,EAAE,IAAI,EAAE,cAAI,CAAC,IAAI,CAAC,MAAM,EAAE,CAAC,CAAC,EAAE,OAAO,EAAE,MAAM,CAAC,OAAO,EAAE,CAAC;aAClE;SACJ;KACJ;IACD,OAAO,IAAI,CAAC;AAChB,CAAC;AAED;;GAEG;AACH,KAAK,UAAU,uBAAuB,CAAC,MAAc,EAAE,IAAY;IAC/D,IAAI,CAAC,MAAM,IAAA,qBAAa,EAAC,MAAM,CAAC;QAAE,OAAO,SAAS,CAAC;IACnD,MAAM,KAAK,GAAG,MAAM,IAAA,iBAAS,EAAC,MAAM,CAAC,CAAC;IACtC,IAAI,IAAmD,CAAC;IACxD,KAAK,MAAM,CAAC,IAAI,KAAK,EAAE;QACnB,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;QACrC,IAAI,MAAM,IAAI,MAAM,CAAC,IAAI,KAAK,IAAI,EAAE;YAChC,IAAI,CAAC,IAAI,IAAI,MAAM,CAAC,OAAO,GAAG,IAAI,CAAC,OAAO,EAAE;gBACxC,IAAI,GAAG,EAAE,IAAI,EAAE,cAAI,CAAC,IAAI,CAAC,MAAM,EAAE,CAAC,CAAC,EAAE,OAAO,EAAE,MAAM,CAAC,OAAO,EAAE,CAAC;aAClE;SACJ;KACJ;IACD,OAAO,IAAI,CAAC;AAChB,CAAC;AAEM,KAAK,UAAU,gBAAgB,CAAC,IAAY,EAAE,MAAqB;IACtE,MAAM,KAAK,GAAG,MAAM,oBAAoB,CAAC,MAAM,EAAE,gBAAgB,CAAC,MAAM,CAAC,EAAE,IAAI,CAAC,CAAC;IACjF,IAAI,KAAK;QAAE,OAAO,KAAK,CAAC,OAAO,CAAC;IAChC,KAAK,MAAM,MAAM,IAAI,MAAM,CAAC,oBAAoB,EAAE;QAC9C,MAAM,GAAG,GAAG,MAAM,uBAAuB,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC;QACxD,IAAI,GAAG;YAAE,OAAO,GAAG,CAAC,OAAO,CAAC;KAC/B;IACD,OAAO,CAAC,CAAC;AACb,CAAC;AARD,4CAQC;AAEM,KAAK,UAAU,aAAa,CAAC,IAAY,EAAE,MAAqB;IACnE,MAAM,EAAE,GAAG,MAAM,CAAC,eAAe,CAAC;IAElC,iDAAiD;IACjD,MAAM,SAAS,GAAG,cAAI,CAAC,IAAI,CAAC,gBAAgB,CAAC,MAAM,CAAC,EAAE,GAAG,IAAI,OAAO,CAAC,CAAC;IACtE,IAAI,MAAM,EAAE,CAAC,aAAa,CAAC,SAAS,CAAC,EAAE;QACnC,MAAM,GAAG,GAAG,MAAM,EAAE,CAAC,QAAQ,CAAC,SAAS,CAAC,CAAC;QACzC,OAAO,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC;KAC5C;IAED,2CAA2C;IAC3C,MAAM,WAAW,GAAG,MAAM,IAAA,yBAAiB,EAAC,MAAM,CAAC,oBAAoB,EAAE,GAAG,IAAI,OAAO,CAAC,CAAC;IACzF,IAAI,WAAW,EAAE;QACb,MAAM,GAAG,GAAG,MAAM,IAAA,gBAAQ,EAAC,WAAW,CAAC,CAAC;QACxC,OAAO,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC;KAC5C;IAED,OAAO,SAAS,CAAC;AACrB,CAAC;AAlBD,sCAkBC;AAEM,KAAK,UAAU,SAAS,CAAC,IAAY,EAAE,MAAqB;IAC/D,MAAM,EAAE,GAAG,MAAM,CAAC,eAAe,CAAC;IAElC,iDAAiD;IACjD,MAAM,KAAK,GAAG,MAAM,oBAAoB,CAAC,MAAM,EAAE,gBAAgB,CAAC,MAAM,CAAC,EAAE,IAAI,CAAC,CAAC;IACjF,IAAI,KAAK,EAAE;QACP,OAAO,MAAM,EAAE,CAAC,QAAQ,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;KACxC;IAED,8CAA8C;IAC9C,KAAK,MAAM,MAAM,IAAI,MAAM,CAAC,oBAAoB,EAAE;QAC9C,MAAM,GAAG,GAAG,MAAM,uBAAuB,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC;QACxD,IAAI,GAAG,EAAE;YACL,OAAO,MAAM,IAAA,gBAAQ,EAAC,GAAG,CAAC,IAAI,CAAC,CAAC;SACnC;KACJ;IAED,OAAO,SAAS,CAAC;AACrB,CAAC;AAlBD,8BAkBC;AAEM,KAAK,UAAU,UAAU,CAAC,MAAqB;IAClD,MAAM,EAAE,GAAG,MAAM,CAAC,eAAe,CAAC;IAClC,MAAM,KAAK,GAAG,IAAI,GAAG,EAAU,CAAC;IAEhC,yDAAyD;IACzD,MAAM,WAAW,GAAG,gBAAgB,CAAC,MAAM,CAAC,CAAC;IAC7C,IAAI,MAAM,EAAE,CAAC,aAAa,CAAC,WAAW,CAAC,EAAE;QACrC,MAAM,KAAK,GAAG,MAAM,EAAE,CAAC,SAAS,CAAC,WAAW,CAAC,CAAC;QAC9C,KAAK,MAAM,CAAC,IAAI,KAAK,EAAE;YACnB,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;YACrC,IAAI,MAAM;gBAAE,KAAK,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC;SACtC;KACJ;IAED,oDAAoD;IACpD,MAAM,YAAY,GAAG,MAAM,IAAA,4BAAoB,EAAC,MAAM,CAAC,oBAAoB,CAAC,CAAC;IAC7E,KAAK,MAAM,CAAC,IAAI,YAAY,EAAE;QAC1B,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;QACrC,IAAI,MAAM;YAAE,KAAK,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC;KACtC;IAED,OAAO,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,IAAI,EAAE,CAAC;AACpC,CAAC;AAtBD,gCAsBC;AAED;;GAEG;AACI,KAAK,UAAU,iBAAiB,CAAC,MAAqB;IACzD,MAAM,EAAE,GAAG,MAAM,CAAC,eAAe,CAAC;IAClC,MAAM,WAAW,GAAG,gBAAgB,CAAC,MAAM,CAAC,CAAC;IAC7C,IAAI,CAAC,MAAM,EAAE,CAAC,aAAa,CAAC,WAAW,CAAC;QAAE,OAAO,EAAE,CAAC;IAEpD,MAAM,YAAY,GAAG,MAAM,IAAA,4BAAoB,EAAC,MAAM,CAAC,oBAAoB,CAAC,CAAC;IAC7E,MAAM,UAAU,GAAG,MAAM,EAAE,CAAC,SAAS,CAAC,WAAW,CAAC,CAAC;IAEnD,2CAA2C;IAC3C,MAAM,eAAe,GAAG,IAAI,GAAG,EAAkB,CAAC;IAClD,KAAK,MAAM,CAAC,IAAI,YAAY,EAAE;QAC1B,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;QACrC,IAAI,MAAM,EAAE;YACR,MAAM,GAAG,GAAG,eAAe,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAClD,IAAI,MAAM,CAAC,OAAO,GAAG,GAAG;gBAAE,eAAe,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,EAAE,MAAM,CAAC,OAAO,CAAC,CAAC;SAC9E;KACJ;IAED,MAAM,aAAa,GAAG,IAAI,GAAG,EAAkB,CAAC;IAChD,KAAK,MAAM,CAAC,IAAI,UAAU,EAAE;QACxB,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;QACrC,IAAI,MAAM,EAAE;YACR,MAAM,GAAG,GAAG,aAAa,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;YAChD,IAAI,MAAM,CAAC,OAAO,GAAG,GAAG;gBAAE,aAAa,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,EAAE,MAAM,CAAC,OAAO,CAAC,CAAC;SAC5E;KACJ;IAED,MAAM,QAAQ,GAAa,EAAE,CAAC;IAC9B,KAAK,MAAM,CAAC,IAAI,EAAE,MAAM,CAAC,IAAI,eAAe,EAAE;QAC1C,MAAM,QAAQ,GAAG,aAAa,CAAC,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;QAC9C,IAAI,QAAQ,GAAG,MAAM,EAAE;YACnB,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;SACvB;KACJ;IACD,OAAO,QAAQ,CAAC;AACpB,CAAC;AAnCD,8CAmCC"}
+{"version":3,"file":"themes.js","sourceRoot":"","sources":["../src/themes.ts"],"names":[],"mappings":";;;;;;AAAA,mCAAsG;AACtG,gDAAwB;AAQxB;;;;GAIG;AACH,SAAgB,kBAAkB,CAAC,QAAgB;IAC/C,IAAI,CAAC,QAAQ,CAAC,QAAQ,CAAC,MAAM,CAAC;QAAE,OAAO,SAAS,CAAC;IACjD,MAAM,cAAc,GAAG,QAAQ,CAAC,KAAK,CAAC,qBAAqB,CAAC,CAAC;IAC7D,IAAI,cAAc,EAAE;QAChB,OAAO,EAAE,IAAI,EAAE,cAAc,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,QAAQ,CAAC,cAAc,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,EAAE,CAAC;KAChF;IACD,OAAO,EAAE,IAAI,EAAE,QAAQ,CAAC,OAAO,CAAC,QAAQ,EAAE,EAAE,CAAC,EAAE,OAAO,EAAE,CAAC,EAAE,CAAC;AAChE,CAAC;AAPD,gDAOC;AAED;;;GAGG;AACH,KAAK,UAAU,uBAAuB,CAAC,MAAc,EAAE,IAAY;IAC/D,IAAI,CAAC,MAAM,IAAA,qBAAa,EAAC,MAAM,CAAC;QAAE,OAAO,SAAS,CAAC;IACnD,MAAM,KAAK,GAAG,MAAM,IAAA,iBAAS,EAAC,MAAM,CAAC,CAAC;IACtC,IAAI,IAAmD,CAAC;IACxD,KAAK,MAAM,CAAC,IAAI,KAAK,EAAE;QACnB,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;QACrC,IAAI,MAAM,IAAI,MAAM,CAAC,IAAI,KAAK,IAAI,EAAE;YAChC,IAAI,CAAC,IAAI,IAAI,MAAM,CAAC,OAAO,GAAG,IAAI,CAAC,OAAO,EAAE;gBACxC,IAAI,GAAG,EAAE,IAAI,EAAE,cAAI,CAAC,IAAI,CAAC,MAAM,EAAE,CAAC,CAAC,EAAE,OAAO,EAAE,MAAM,CAAC,OAAO,EAAE,CAAC;aAClE;SACJ;KACJ;IACD,OAAO,IAAI,CAAC;AAChB,CAAC;AAEM,KAAK,UAAU,gBAAgB,CAAC,IAAY,EAAE,MAAqB;IACtE,KAAK,MAAM,MAAM,IAAI,MAAM,CAAC,oBAAoB,EAAE;QAC9C,MAAM,GAAG,GAAG,MAAM,uBAAuB,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC;QACxD,IAAI,GAAG;YAAE,OAAO,GAAG,CAAC,OAAO,CAAC;KAC/B;IACD,OAAO,CAAC,CAAC;AACb,CAAC;AAND,4CAMC;AAEM,KAAK,UAAU,aAAa,CAAC,IAAY,EAAE,MAAqB;IACnE,MAAM,WAAW,GAAG,MAAM,IAAA,yBAAiB,EAAC,MAAM,CAAC,oBAAoB,EAAE,GAAG,IAAI,OAAO,CAAC,CAAC;IACzF,IAAI,WAAW,EAAE;QACb,MAAM,GAAG,GAAG,MAAM,IAAA,gBAAQ,EAAC,WAAW,CAAC,CAAC;QACxC,OAAO,GAAG,CAAC,CAAC,CAAC,IAAI,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,SAAS,CAAC;KAC5C;IACD,OAAO,SAAS,CAAC;AACrB,CAAC;AAPD,sCAOC;AAEM,KAAK,UAAU,SAAS,CAAC,IAAY,EAAE,MAAqB;IAC/D,KAAK,MAAM,MAAM,IAAI,MAAM,CAAC,oBAAoB,EAAE;QAC9C,MAAM,GAAG,GAAG,MAAM,uBAAuB,CAAC,MAAM,EAAE,IAAI,CAAC,CAAC;QACxD,IAAI,GAAG,EAAE;YACL,OAAO,MAAM,IAAA,gBAAQ,EAAC,GAAG,CAAC,IAAI,CAAC,CAAC;SACnC;KACJ;IACD,OAAO,SAAS,CAAC;AACrB,CAAC;AARD,8BAQC;AAEM,KAAK,UAAU,UAAU,CAAC,MAAqB;IAClD,MAAM,KAAK,GAAG,IAAI,GAAG,EAAU,CAAC;IAChC,MAAM,YAAY,GAAG,MAAM,IAAA,4BAAoB,EAAC,MAAM,CAAC,oBAAoB,CAAC,CAAC;IAC7E,KAAK,MAAM,CAAC,IAAI,YAAY,EAAE;QAC1B,MAAM,MAAM,GAAG,kBAAkB,CAAC,CAAC,CAAC,CAAC;QACrC,IAAI,MAAM;YAAE,KAAK,CAAC,GAAG,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC;KACtC;IACD,OAAO,KAAK,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,IAAI,EAAE,CAAC;AACpC,CAAC;AARD,gCAQC"}

package/migration-rules/v2-to-v3.md

@@ -100,50 +100,94 @@ All CSS rules targeting component selectors. The full list from v2 themes that a
 
 ---
 
-## 2. Shell Chrome Changes
+## 2. Shell Chrome Removal (iframe Viewer Panel)
 
-### Chat input
+### Overview
+
+In the iframe viewer panel architecture, **shell chrome is no longer part of page HTML**. The shell (toolbar, chat panel, loading overlay) lives in a parent frame (`required-pages/_shell/page.html`), and page content renders inside an `<iframe>`. Pages are pure content — they should not contain any shell markup.
+
+### What to remove from page HTML
+
+All of the following elements are now provided by the parent shell frame and must be removed from page HTML templates. The v2→v3 migration in `src/migrations.ts` strips every selector listed here via the `V2_SHELL_SELECTORS` table — keep that array in sync with this list.
+
+| Selector | What it is in v2 | Who provides it in v3 |
+|---|---|---|
+| `.shell-toolbar` | Toolbar div (builderToggle, pagesBtn, saveBtn, settingsBtn) | Parent shell frame |
+| `.chat-panel` | Header, `#chatMessages`, `#chatForm` with `#chatInput`, `.link-group`, inline chat history, `#defaultGreeting`, `#firstRunGreeting` | Parent shell frame |
+| `.chat-toggle` | Collapsed-chat toggle button | Parent shell frame (if kept) |
+| `#loadingOverlay` | Spinner overlay inside `.viewer-panel` | Parent shell frame (blueprint overlay) |
+| `<script id="idle-animation">` | v2 inline script declaring top-level `hideIdleAnimation`/`showIdleAnimation` | Parent shell frame (no-op stubs injected at serve time) |
+| `<script id="first-run-check">` | v2 inline script that toggles `#defaultGreeting`/`#firstRunGreeting` via `?firstRun=true` | Parent shell frame (greeting flow) |
+| `<script id="page-helpers">` | Legacy `/api/page-helpers.js?v=2` tag | Server re-injects the cache-busted v3 URL at serve time |
+| `<script id="page-script">` | Legacy `/api/page-script.js?v=2` tag | Server re-injects the cache-busted v3 URL at serve time |
+| `<script id="synthos-error-capture">` | Error-capture bootstrap | Server injects when needed |
 
-v2 used a single-line `<input>` with a separate submit button:
+The `first-run-check` script in particular MUST be stripped — it references `#defaultGreeting` and `#firstRunGreeting`, both of which live inside `.chat-panel`. Leaving it behind after the panel is removed produces spurious `missing-element` validator warnings.
+
+### Before (v2/early v3)
 
 ```html
-<!-- v2 -->
-<form action="/" method="POST" id="chatForm" data-locked="true">
-    <input type="text" class="chat-input" id="chatInput" name="message" placeholder="Type a message..." data-locked="true">
-    <button type="submit" class="chat-submit" data-locked="true">Send</button>
-</form>
+<body>
+    <div class="shell-toolbar" data-locked="true">
+        <!-- toolbar buttons -->
+    </div>
+    <div class="chat-panel" data-locked="true">
+        <div class="chat-header" data-locked="true">...</div>
+        <div class="chat-messages" id="chatMessages" data-locked="true">...</div>
+        <form action="/" method="POST" id="chatForm" data-locked="true">
+            <textarea class="chat-input" id="chatInput" ...></textarea>
+        </form>
+    </div>
+    <div class="viewer-panel" id="viewerPanel">
+        <!-- page content -->
+        <div id="loadingOverlay" class="loading-overlay"><div class="spinner"></div></div>
+    </div>
+    <script id="page-helpers" src="/api/page-helpers.js?v=3" data-locked="true"></script>
+    <script id="page-script" src="/api/page-script.js?v=3" data-locked="true"></script>
+</body>
 ```
 
-v3 replaces this with a multi-line `<textarea>`. The Send button is removed — submission is handled by the v3 page script (Enter to send, Shift+Enter for newline):
+### After (iframe-ready)
 
 ```html
-<!-- v3 -->
-<form action="/" method="POST" id="chatForm" data-locked="true">
-    <textarea class="chat-input" id="chatInput" name="message" rows="2" placeholder="Type a message..." data-locked="true"></textarea>
-</form>
+<body>
+    <div class="viewer-panel" id="viewerPanel">
+        <!-- page content only -->
+    </div>
+    <div id="instructions" style="display: none;" data-locked="true"></div>
+    <div id="thoughts" style="display: none;" data-locked="true"></div>
+</body>
 ```
 
-### Static script versions
+### Runtime safety net
 
-v3 pages reference the v3 static files. Update both script tags at the bottom of every page:
+The server's `stripShellMarkup()` function removes shell elements at serve time even if they're still present in the HTML source. It also injects hidden stub elements (`chatForm`, `chatInput`, `chatMessages`, `loadingOverlay`) so legacy inline scripts that reference these IDs don't crash with null-reference errors.
 
-```html
-<!-- v2 -->
-<script id="page-helpers" src="/api/page-helpers.js?v=2" data-locked="true"></script>
-<script id="page-script" src="/api/page-script.js?v=2" data-locked="true"></script>
+In addition, `stripShellMarkup()` removes the v2-legacy `<script id="idle-animation">` block and injects no-op `window.hideIdleAnimation` / `window.showIdleAnimation` globals. The v2 block declares those functions as top-level statements, which the server's `wrapInlineScriptsInIIFE` transform traps inside an IIFE — leaving cross-script call sites (e.g. `hideIdleAnimation()` in `#qb-app`) hitting `ReferenceError` and aborting the rest of the page boot. The stubs keep those call sites no-op-safe without having to rewrite each migrated page.
+
+However, source templates should be cleaned proactively — the runtime stripping is a fallback, not a substitute for clean templates.
+
+### Automated cleanup
 
-<!-- v3 -->
-<script id="page-helpers" src="/api/page-helpers.js?v=3" data-locked="true"></script>
-<script id="page-script" src="/api/page-script.js?v=3" data-locked="true"></script>
+Run the cleanup script to strip shell markup from all page templates:
+
+```bash
+node scripts/cleanup-shell-markup.mjs          # modify files
+node scripts/cleanup-shell-markup.mjs --dry-run # preview only
 ```
 
-### Migration rules for the LLM (shell chrome)
+This script processes all `page.html` files under `default-pages/` and `.synthos/pages/`, removing the 5 element types listed above.
+
+### Migration rules for the LLM
 
-When migrating a v2 page's shell chrome to v3:
+When creating or migrating pages:
 
-1. **Replace the chat input** — swap the `<input type="text">` + `<button>Send</button>` pair with a single `<textarea rows="2">` as shown above.
-2. **Update script versions** — change `?v=2` to `?v=3` on both `page-helpers.js` and `page-script.js`.
-3. **Do NOT touch** page-specific `<input>` elements inside `.viewer-panel` — the chat input change only applies to the shell's `#chatForm`.
+1. **Do NOT include** shell toolbar, chat panel, loading overlay, or page-helpers/page-script tags in page HTML
+2. **Do NOT include** chatForm submit handlers or chatInput event listeners — the shell handles all chat interaction
+3. **The `<body>` should start with** the `.viewer-panel` div containing only page content
+4. **Keep** `#instructions` and `#thoughts` divs (used for LLM context, not shell chrome)
+5. **Keep** page-specific inline scripts and styles — only remove shell-related code
+6. **If a page script references** `chatInput` or `chatForm` (e.g., tutorial link handlers), the runtime stubs prevent crashes, but ideally migrate these to use `window.__synthOSNavigateTo()` or `parent.postMessage()` via the page bridge
 
 ---
 
@@ -151,11 +195,11 @@ When migrating a v2 page's shell chrome to v3:
 
 ### Overview
 
-v2 pages rely on the v2 theme CSS for **all** styling — shell chrome, viewer layout, and page content. In v3, the theme CSS only provides FluentLM palette tokens. When migrating a v2 page to run under a v3 theme, we must **inline** the v2 styles that the page content depends on so it keeps its look.
+v2 pages reference legacy CSS tokens (`var(--bg-primary)`, `var(--accent-primary)`, `var(--text-primary)`, etc.) that v2 themes used to supply as hardcoded colors. In v3, themes only define FluentLM semantic tokens (`--bodyBackground`, `--themePrimary`, `--bodyText`, etc.). When migrating a v2 page, we inject a `<style id="v2-compat">` block that **aliases** each legacy v2 token onto the closest v3 semantic token — so the page inherits whatever v3 theme is active instead of being frozen on the old nebula-dusk palette.
 
 ### What the framework handles (NOT inlined)
 
-The shell chrome CSS (chat panel, modals, toggle, brainstorm, attachments, etc.) will be provided by a framework-level shell stylesheet. Pages do NOT need to carry these rules:
+The shell chrome CSS (chat panel, modals, toggle, brainstorm, attachments, etc.) is provided by the parent shell frame's stylesheet plus FluentLM. Pages do NOT need to carry these rules:
 
 - `.chat-panel`, `.chat-header`, `.chat-messages`, `.chat-message`, `.chat-message p`, `.chat-message p strong`, `.chat-message p code`
 - `.link-group`, `.link-group a`
@@ -170,124 +214,140 @@ The shell chrome CSS (chat panel, modals, toggle, brainstorm, attachments, etc.)
 - `.attach-btn`, `.attach-menu`, `.attach-menu-item`, `.attachment-pill*`
 - `.screenshot-overlay`, `.screenshot-rect`
 
-### What must be inlined into each migrated page
+The shell also injects the iframe viewport height chain (`html,body,.viewer-panel{height:100%;margin:0}`), so the compat block does NOT carry global resets or layout rules.
+
+### The v2 → v3 token mapping
+
+Each v2 token is aliased to a v3 **semantic** token (not a palette token). Semantic tokens are already defined per-theme and resolve correctly under light, dark, and high-contrast themes, so the mapping is theme-agnostic.
+
+#### Color tokens
+
+Backgrounds must alias to **semantic** role tokens (`--bodyBackground`, `--bodyStandoutBackground`, `--bodyBackgroundHovered`), not palette tokens (`--neutralPrimaryAlt`, `--neutralDark`, etc.). Palette tokens encode a FIXED color value and stay dark even under light themes — so a v2 page that used `--bg-secondary` / `--bg-tertiary` for component backgrounds renders as hard-coded black blobs under nebula-dawn, aurora-dawn, high-contrast-light, etc. if aliased to palette. Semantic tokens flip correctly across light/dark variants.
+
+| v2 token | → v3 binding | Fallback | Role |
+|---|---|---|---|
+| `--bg-primary` | `var(--bodyBackground, #ffffff)` | `#ffffff` | Main surface background (white in dawn, dark in dusk) |
+| `--bg-secondary` | `var(--defaultStateBackground, #faf9f8)` | `#faf9f8` | Component surface (near-white in dawn, darker in dusk) |
+| `--bg-tertiary` | `var(--bodyBackgroundHovered, #f3f2f1)` | `#f3f2f1` | Third distinct surface (light gray in dawn, mid-dark in dusk) |
+| `--accent-primary` | `var(--themePrimary, #0078d4)` | `#0078d4` | Active theme's primary brand color |
+| `--accent-secondary` | `var(--themeDarkAlt, #106ebe)` | `#106ebe` | Darker brand variant |
+| `--accent-tertiary` | `var(--themeSecondary, #2b88d8)` | `#2b88d8` | Lighter brand variant |
+| `--accent-glow` | `rgba(0,0,0,0.3)` | — | Subtle shadow; theme-neutral |
+| `--text-primary` | `var(--bodyText, #333333)` | `#333333` | Primary text color |
+| `--text-secondary` | `var(--bodySubtext, #605e5c)` | `#605e5c` | Secondary / subtitle text |
+| `--border-color` | `var(--bodyDivider, #edebe9)` | `#edebe9` | Borders, dividers, outlines |
 
-The following `<style>` block should be injected into the `<head>` of every migrated v2 page. It provides:
+**Why `--defaultStateBackground` for `--bg-secondary`:** That's the v3 token v3-authored pages use for component surfaces (cards, panels, tiles). It's defined in every shipped theme (dawn: `--neutralLighterAlt`, dusk: `--neutralDark`) and flips correctly. `--bodyStandoutBackground` resolves to the same values but `--defaultStateBackground` is the role-correct semantic choice.
 
-1. **v2 CSS custom properties** — so `var(--bg-primary)` etc. still resolve
-2. **Viewer panel** styles — layout, background, decorative pseudo-element
-3. **Global resets** — `*` box-sizing, `body` font/color/layout
-4. **Scrollbar theming** — custom scrollbar appearance
+**Why hex fallbacks:** If any v3 token doesn't resolve (theme CSS fails to load, token spelling mismatch, browser quirks in iframe context), the outer `var()` falls back to the hex. Without the fallback the whole declaration becomes `initial` and the property reverts to its CSS default (transparent for background, `canvasText` for color) — which can surface as black component backgrounds under some OS/browser combos. The light-mode fallbacks are safe under dusk because the outer `--bodyBackground` etc. DO resolve (to dark values) and the fallback never fires.
 
-#### Inline style block (nebula-dusk)
+#### Layout constants (kept as literals)
+
+These values are layout geometry, not theme color — they stay fixed across themes:
+
+| v2 token | Value |
+|---|---|
+| `--header-min-height` | `58px` |
+| `--header-padding-vertical` | `14px` |
+| `--header-padding-horizontal` | `20px` |
+| `--header-line-height` | `1.25` |
+
+#### The full compat block
 
 ```html
 <style id="v2-compat">
-/* --- v2 CSS Custom Properties (nebula-dusk) --- */
+/* --- v2 → v3 token aliases ---
+   Each legacy v2 var resolves to a v3 SEMANTIC token (role-based) so the page
+   re-themes automatically between light and dark variants. Do NOT use palette
+   tokens (--neutralDark, --neutralPrimaryAlt, etc.) here — those encode a
+   FIXED color value and stay dark under light themes, producing hard-coded
+   black backgrounds on v2 pages.
+
+   Component-surface tokens use --defaultStateBackground / --defaultHoverBackground
+   (the v3 tokens v3 pages use for card/panel surfaces) instead of the
+   body*Background tokens. Every alias has a hex fallback so the compat block
+   still produces sensible light defaults even if the theme CSS fails to load
+   or a token isn't defined (otherwise the chain resolves to `initial` and
+   backgrounds go transparent). Header geometry stays literal because it's
+   layout, not color. */
 :root {
-    --bg-primary: #1a1a2e;
-    --bg-secondary: #16213e;
-    --bg-tertiary: #0f0f23;
-    --accent-primary: #667eea;
-    --accent-secondary: #764ba2;
-    --accent-tertiary: #f093fb;
-    --accent-glow: rgba(138,43,226,0.3);
-    --text-primary: #e0e0e0;
-    --text-secondary: #b794f6;
-    --border-color: rgba(138,43,226,0.3);
+    --bg-primary:       var(--bodyBackground, #ffffff);
+    --bg-secondary:     var(--defaultStateBackground, #faf9f8);
+    --bg-tertiary:      var(--bodyBackgroundHovered, #f3f2f1);
+
+    --accent-primary:   var(--themePrimary, #0078d4);
+    --accent-secondary: var(--themeDarkAlt, #106ebe);
+    --accent-tertiary:  var(--themeSecondary, #2b88d8);
+    --accent-glow:      rgba(0,0,0,0.3);
+
+    --text-primary:     var(--bodyText, #333333);
+    --text-secondary:   var(--bodySubtext, #605e5c);
+
+    --border-color:     var(--bodyDivider, #edebe9);
+
     --header-min-height: 58px;
     --header-padding-vertical: 14px;
     --header-padding-horizontal: 20px;
     --header-line-height: 1.25;
 }
+</style>
+```
 
-/* --- Global Reset --- */
-* {
-    margin: 0;
-    padding: 0;
-    box-sizing: border-box;
-}
+### Legacy color mapping (hardcoded RGB / hex → theme tokens)
 
-body {
-    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
-    background: linear-gradient(135deg, var(--bg-primary) 0%, var(--bg-secondary) 50%, var(--bg-tertiary) 100%);
-    color: var(--text-primary);
-    height: 100vh;
-    display: flex;
-}
+v2 pages were hand-matched to the v2 nebula-dusk palette and are full of literal `rgba(102,126,234,0.15)`, `#dc3545`, etc. Under a v3 light theme those colors stand out as dark purple-blue/red blobs because they never existed as variables — they were baked directly into the CSS. The migration therefore also rewrites these specific numeric triples (and their hex equivalents) in the full HTML output (covers `<style>` blocks, inline `style=""` attrs, and color strings inside JS template literals).
 
-/* --- Viewer Panel --- */
-.viewer-panel {
-    flex: 1;
-    min-width: 0;
-    padding: 20px 20px 20px 44px;
-    background: linear-gradient(135deg, rgba(22,33,62,0.9) 0%, rgba(15,15,35,0.95) 100%);
-    display: flex;
-    flex-direction: column;
-    justify-content: center;
-    align-items: center;
-    box-shadow: inset 0 0 60px rgba(75,0,130,0.15);
-    position: relative;
-    overflow: hidden;
-}
+| v2 hardcoded color | Source in v2 | → v3 binding |
+|---|---|---|
+| `rgba(102,126,234,*)` / `#667eea` | `--accent-primary` (purple-blue) | `var(--themePrimary)` |
+| `rgba(118,75,162,*)` / `#764ba2` | `--accent-secondary` | `var(--themeDarkAlt)` |
+| `rgba(138,43,226,*)` / `#8a2be2` | `--accent-glow` (blueviolet) | `var(--themeDarker)` |
+| `rgba(75,0,130,*)` / `#4b0082` | indigo inset-shadow | `var(--themeDarker)` |
+| `rgba(240,147,251,*)` / `#f093fb` | magenta accent | `var(--themeSecondary)` |
+| `rgba(183,148,246,*)` / `#b794f6` | light purple | `var(--themeTertiary)` |
+| `rgba(26,26,46,*)` / `#1a1a2e` | `--bg-primary` | `var(--bodyBackground)` |
+| `rgba(22,33,62,*)` / `#16213e` | `--bg-secondary` | `var(--bodyStandoutBackground)` |
+| `rgba(15,15,35,*)` / `#0f0f23` | `--bg-tertiary` | `var(--bodyBackgroundHovered)` |
+| `rgba(220,53,69,*)` / `#dc3545` | Bootstrap danger red | `var(--red)` |
+| `rgba(40,167,69,*)` / `#28a745` | Bootstrap success green | `var(--green)` |
+| `rgba(255,193,7,*)` / `#ffc107` | Bootstrap warning yellow | `var(--yellow)` |
+| `rgba(0,0,0,*)` | Black shadows | *(unchanged — theme-neutral)* |
 
-.viewer-panel::before {
-    content: '';
-    position: absolute;
-    top: -50%;
-    left: -50%;
-    width: 200%;
-    height: 200%;
-    background: radial-gradient(ellipse at center, rgba(138,43,226,0.05) 0%, transparent 70%);
-    animation: nebula-pulse 8s ease-in-out infinite;
-    pointer-events: none;
-}
+**How alpha is preserved:** `rgba(R,G,B,A)` is rewritten to `color-mix(in srgb, var(--token) A*100%, transparent)`, which is widely supported in modern browsers (since 2023). Solid `rgb(R,G,B)` / `rgba(R,G,B,1)` / bare hex collapse to `var(--token)` directly.
 
-@keyframes nebula-pulse {
-    0%,100% { opacity: 0.5; transform: scale(1); }
-    50% { opacity: 1; transform: scale(1.1); }
-}
+**Hex boundary safety:** hex replacements are guarded by `(?<![0-9a-fA-F])` / `(?![0-9a-fA-F])` lookarounds, so `#667eea` inside an 8-digit `#667eeaff` is not split.
 
-.viewer-panel.full-viewer {
-    padding: 0;
-}
+**Result:** the same migrated page now renders with the active theme's primary color where there used to be baked purple-blue, and with the shared red/green/yellow tokens for danger/success/warning instead of Bootstrap's literals. Switching between nebula-dawn, aurora-dusk, high-contrast-light, etc. re-themes the page automatically.
 
-/* --- Scrollbar --- */
-::-webkit-scrollbar { width: 10px; height: 10px; }
-::-webkit-scrollbar-track { background: rgba(15,15,35,0.6); border-radius: 10px; }
-::-webkit-scrollbar-thumb {
-    background: linear-gradient(180deg, var(--accent-primary) 0%, var(--accent-secondary) 50%, var(--accent-tertiary) 100%);
-    border-radius: 10px;
-    border: 2px solid rgba(15,15,35,0.6);
-    box-shadow: 0 0 10px var(--accent-glow);
-}
-::-webkit-scrollbar-thumb:hover {
-    background: linear-gradient(180deg, var(--accent-tertiary) 0%, var(--accent-secondary) 50%, var(--accent-primary) 100%);
-    box-shadow: 0 0 15px rgba(240,147,251,0.5);
-}
-::-webkit-scrollbar-corner { background: rgba(15,15,35,0.6); }
-* { scrollbar-width: thin; scrollbar-color: var(--accent-secondary) rgba(15,15,35,0.6); }
-</style>
-```
+### Migration rules (runtime)
 
-### Migration rules for the LLM
+The v2→v3 migration is applied automatically by `migrateV2toV3` in `src/migrations.ts`. It:
 
-When migrating a v2 page to v3:
+1. **Injects the `<style id="v2-compat">` block** into `<head>` as the first child. Idempotent — skipped if a block with `id="v2-compat"` is already present. Runs AFTER `postProcessV2` (which strips `:root` rules from style blocks), not before — otherwise the block's aliases get shredded silently.
 
-1. **Inject the `<style id="v2-compat">` block** into `<head>` as the first child (before any other styles or scripts). This preserves the v2 look while running under a v3 theme.
+2. **Remaps hardcoded v2-palette RGB/hex colors** throughout the HTML per the table above. Runs LAST so the compat block (which uses a theme-neutral `rgba(0,0,0,0.3)` for `--accent-glow`) is in the output but untouched by the remap (the rule table intentionally excludes `0,0,0`).
 
-2. **Do NOT modify** existing page content, classes, or inline styles inside `.viewer-panel`. The v2-compat block ensures all `var()` references continue to resolve.
+3. **Does NOT modify** existing page structure, classes, or non-color inline styles inside `.viewer-panel`. The page's own CSS keeps working — its `var(--bg-primary)` / `var(--accent-primary)` / etc. now resolve through the aliases to whatever the active v3 theme provides, and literal colors get remapped to shared tokens.
 
-3. **Do NOT convert** v2 class names to FluentLM `flm-*` classes. That's a separate opt-in redesign, not part of version migration.
+4. **Does NOT convert** v2 class names to FluentLM `flm-*` classes. That's a separate opt-in redesign (see §4), not part of version migration.
 
-4. **Do NOT remove** any existing `<style>` blocks the page already has. The v2-compat block supplements, it doesn't replace.
+5. **Does NOT remove** any existing `<style>` blocks the page already has. The compat block supplements them, it doesn't replace.
 
-### Per-theme compat blocks
+### What migrated pages look like under different v3 themes
 
-Each v2 theme needs its own compat block because the CSS variable values and hardcoded colors differ. The block above is for **nebula-dusk**. When migrating:
+Because the compat block aliases to semantic tokens AND the legacy color remap routes literals through shared tokens, the same migrated page renders differently under each theme:
 
-- Use the compat block matching the theme the page was originally built under
-- If the original theme is unknown, default to **nebula-dusk** (the system default)
+- **nebula-dusk** — purple primary, dark neutrals
+- **nebula-dawn** — purple primary, light neutrals *(previously looked broken — now themes correctly)*
+- **aurora-dawn** — aurora accent, light neutrals
+- **cosmos-dusk** — cosmos primary, dark neutrals
+- **high-contrast-light / dark** — high-contrast palette
+
+### Known limitations
+
+- **Non-palette hex colors** (e.g. `#fafafa`, `#cccccc`, or any hex not in the rule table) are left as-is. If a page uses an unusual color, add it to the rule table in `src/migrations.ts`.
+- **Color-named literals** (`purple`, `red`, `black`) are not remapped. These are rare in v2 pages but, if present, would need a separate named-color rule.
+- **Gradients** that combine remapped colors work correctly (each stop is rewritten independently), but the aesthetic may shift — a `linear-gradient(purple → indigo)` that was two v2 accent colors now becomes a gradient between `themePrimary` and `themeDarker`, which reads correctly under any theme but may not match the original nebula-dusk glow exactly.
 
 ---
 
@@ -479,3 +539,101 @@ Games that use `<canvas>` typically size to the viewer panel via JavaScript (`vi
 - Custom fonts (e.g. Google Fonts `<link>` tags) — keep as-is
 - CDN library imports (e.g. html2canvas) — keep as-is
 - Inline `style=` attributes on game elements (e.g. `style="display: none;"` on overlays) — preserve exactly
+
+---
+
+## 7. Chat History Migration (iframe Viewer Panel)
+
+### Overview
+
+In the iframe viewer panel architecture, chat history is stored as a separate JSON file (`chat-history.json`) alongside each page, instead of being embedded as `<div class="chat-message">` elements inside the page HTML. This decouples chat state from page content and enables the shell/content iframe split.
+
+### What changed
+
+| Before | After |
+|--------|-------|
+| Chat messages embedded in `#chatMessages` div inside page HTML | Chat messages stored in `<pagesFolder>/pages/<name>/chat-history.json` |
+| Server extracts history by scraping `.chat-message` elements with cheerio | Server reads `chat-history.json` directly |
+| `appendChatReply()` / `appendChatError()` inject HTML into page | Shell.js displays messages in the parent frame |
+| `newBuild` detected by counting `.chat-message` elements | `newBuild` detected by `history.length === 0` |
+
+### File format
+
+`chat-history.json` is a JSON array of `ChatMessage` objects:
+
+```json
+[
+  { "role": "user", "content": "Make the header blue" },
+  { "role": "assistant", "content": "I've updated the header background to blue." }
+]
+```
+
+An empty array `[]` means no chat history (new or freshly saved page).
+
+### Migration steps for existing pages
+
+1. **Check for embedded chat messages** — look for `#chatMessages .chat-message` elements in `page.html`
+
+2. **Extract messages** — for each `.chat-message` div:
+   - Parse the role from `<strong>User:</strong>` or `<strong>SynthOS:</strong>` prefix
+   - Strip HTML tags to get plain text content
+   - Map to `{ role: 'user' | 'assistant', content: string }`
+
+3. **Write `chat-history.json`** — save the extracted array to `<pageFolder>/chat-history.json`
+   - If no chat messages are found, write `[]`
+   - If the page only has the default welcome message (`Welcome! How can I help you?`), write `[]` (the welcome is handled by shell.js)
+
+4. **Strip chat markup from page HTML** (optional) — remove `#chatMessages` content and `.chat-panel` div from the page HTML. The iframe viewer panel strips shell markup automatically via `stripShellMarkup()`, so this step is cosmetic cleanup.
+
+### Legacy fallback
+
+The GET handler in `usePageRoutes.ts` has a legacy fallback: if `chat-history.json` doesn't exist, it extracts messages from the page HTML using `extractChatMessages()`. This ensures pre-migration pages still work. Once all pages are migrated, this fallback can be removed.
+
+### What to create for new pages
+
+New pages (both default templates and user-created) should ship with an empty `chat-history.json`:
+
+```json
+[]
+```
+
+This prevents the legacy fallback from running and establishes the page as using the new format from the start.
+
+### Pages that don't need migration
+
+- **Required pages** (`required-pages/`) — system pages like `builder`, `settings`, `pages` are loaded fresh each time and don't accumulate chat history
+- **Pages with no chat markup** — if the page HTML has no `#chatMessages` div or no `.chat-message` elements, just create an empty `chat-history.json`
+- **Pages already migrated** — if `chat-history.json` already exists, skip
+
+### Lifecycle
+
+| Event | Chat history behavior |
+|-------|----------------------|
+| **New page created** | `chat-history.json` created with `[]` |
+| **User sends message** | User + assistant messages appended to array |
+| **Page saved** | `chat-history.json` cleared (reset to `[]`) |
+| **Page undo** | Last user + assistant pair popped from array |
+| **Page copied** | `chat-history.json` is NOT copied (new page starts fresh) |
+| **Page deleted** | `chat-history.json` deleted with the page folder |
+
+---
+
+## 8. Migration Greeting
+
+### Overview
+
+Pages upgraded by `POST /api/pages/:name/upgrade` (the UI "migrate to v3" action) get an auto-assigned `greeting` on `page.json` so the shell's first assistant message after migration tells the user what happened and invites them to report breakage.
+
+### Behavior
+
+- Any migration from `pageVersion < 3` to the current `PAGE_VERSION` assigns a generic greeting onto the page metadata **only if** the page does not already carry a user-authored greeting (`metadata.greeting` is empty/whitespace).
+- The greeting is stored on `page.json` as the `greeting` field. The shell renders it as the first assistant message via `injectShellInit` (see `src/service/usePageRoutes.ts`).
+- The actual greeting text lives in `MIGRATED_PAGE_GREETING` in `src/service/useApiRoutes.ts`. Keep updates colocated there — the migration-rules doc does not repeat the copy.
+
+### Why not inline it into the HTML?
+
+The v3 chat-history architecture (§7) keeps greeting text out of page HTML entirely — it lives on `page.json` and is rendered by the shell, not embedded as a `<div class="chat-message">` in the page body. Adding it to HTML during migration would immediately be stripped by `stripShellMarkup()` at serve time.
+
+### Overriding the greeting later
+
+Users can change the greeting through the page definition editor. Whatever they save into `metadata.greeting` replaces the auto-assigned text permanently.

package/package.json

@@ -2,7 +2,7 @@
     "name": "synthos",
     "author": "Steven Ickman",
     "description": "The Hyper-Personalized App Builder That Turns Everyone into a Programmer.",
-    "version": "0.10.1",
+    "version": "0.11.1",
     "license": "MIT",
     "keywords": [
         "synthos",
@@ -21,6 +21,7 @@
     "dependencies": {
         "@a2a-js/sdk": "^0.3.10",
         "@anthropic-ai/sdk": "^0.75.0",
+        "acorn": "^8.16.0",
         "adm-zip": "^0.5.16",
         "cheerio": "^1.2.0",
         "express": "^4.19.2",
@@ -45,6 +46,7 @@
         "typescript": "^4.2.3"
     },
     "scripts": {
+        "prebuild": "rimraf dist tsconfig.tsbuildinfo",
         "build": "tsc -b",
         "clean": "rimraf dist tsconfig.tsbuildinfo node_modules",
         "start": "node ./bin/synthos.js start",
@@ -60,8 +62,10 @@
         "default-themes",
         "static-files",
         "required-pages",
+        "starters",
         "service-connectors",
         "migration-rules",
+        "scripts",
         "tests"
     ]
 }