feat: theming, layouts, dialog confirmation. (#5)

Author: knightedcodemonkey

.husky/pre-commit

@@ -0,0 +1,2 @@
+#!/usr/bin/env sh
+npm exec lint-staged

.husky/pre-push

@@ -0,0 +1,4 @@
+#!/usr/bin/env sh
+set -e
+npm run lint
+npm run build:esm

.prettierignore

@@ -0,0 +1,2 @@
+node_modules
+dist

README.md

@@ -1,6 +1,6 @@
 # @knighted/develop
 
-A small in-browser playground for experimenting with `@knighted/jsx` and `@knighted/css`.
+Compiler-as-a-Service (at the edge of your browser) with `@knighted/jsx` and `@knighted/css`.
 
 > ⚠️ Early project status: this package is pre-`1.0.0` and still actively evolving.
 

docs/article.md

@@ -0,0 +1,75 @@
+# Forget The Build Step: Building A Compiler-as-a-Service Playground
+
+In modern frontend development, we have normalized a heavy local setup cost. Want JSX and modern CSS dialects? Install a large dependency graph, start a dev server, and wait for transpilation loops before you can really iterate.
+
+I wanted to test a different path: what if we removed the terminal from the inner loop?
+
+That experiment became @knighted/develop, a browser-native playground that treats your tab as a real-time compiler host.
+
+## The Core Idea
+
+Most playgrounds rely on a backend build service. @knighted/develop flips that model:
+
+- JSX compilation and execution happen in the browser.
+- CSS transforms (including CSS Modules, Less, and Sass) run in the browser.
+- Compilers are loaded on demand from CDN sources.
+
+The result is a development loop that feels direct: type, compile, render, repeat.
+
+## The Stack Behind It
+
+Two libraries power the runtime:
+
+- @knighted/jsx: JSX that resolves to real DOM nodes.
+  - No virtual DOM requirement.
+  - You can use declarative JSX and imperative DOM APIs in the same flow.
+- @knighted/css: A browser-capable CSS compiler pipeline.
+  - Supports native CSS, CSS Modules, Less, and Sass.
+  - Uses WASM-backed tooling for modern transforms.
+
+Under the hood, the app leans on CDN resolution and lazy loading, so it fetches compiler/runtime pieces only when a mode needs them.
+
+## Why "Compiler-as-a-Service"?
+
+Compiler-as-a-Service here does not mean a remote build cluster.
+
+It means the service boundary is split between:
+
+- global CDN infrastructure (module and WASM delivery), and
+- the user device (actual compilation and execution).
+
+If you switch into Sass mode, the browser loads Sass support. If you stay in native CSS mode, it does not pay that cost. The compiler behaves like an on-demand service, but the work stays local to the tab.
+
+## What This Enables
+
+- Fast feedback loops
+  - Rendering updates track edits with minimal overhead.
+- Mixed declarative and imperative workflows
+  - Useful for low-level UI experiments and DOM-heavy component prototypes.
+- Isolation testing with ShadowRoot
+  - Toggle encapsulation to verify style boundary behavior.
+- Zero install inner loop
+  - Open a page and start building.
+
+## Why This Matters
+
+The point is not to replace every production build pipeline.
+
+The point is to prove a stronger baseline: modern browsers are now capable enough to host substantial parts of the authoring and compile cycle directly, without defaulting to local toolchain setup for every experiment.
+
+For prototyping and component iteration, that changes the cost model dramatically.
+
+## Try It
+
+- Live playground: https://knightedcodemonkey.github.io/develop/
+- Source repository: https://github.com/knightedcodemonkey/develop
+
+## Notes For Publishing
+
+If you post this on Medium (or similar), include a short screen recording that shows:
+
+- switching style modes (CSS -> Modules -> Less -> Sass),
+- toggling ShadowRoot on and off, and
+- immediate preview updates while typing.
+
+That visual sequence communicates the Compiler-as-a-Service model faster than any architecture diagram.

docs/next-steps.md

@@ -2,22 +2,10 @@
 
 Focused follow-up work for `@knighted/develop`.
 
-1. **Grid-first header/layout cleanup**
-   - Refactor panel header layout to use CSS Grid as the primary layout mechanism.
-   - Reduce wrapper rows where possible and place controls explicitly in grid areas.
-   - Preserve existing semantics and accessibility behavior while simplifying structure.
-   - Validate desktop/mobile breakpoints and keep visual behavior parity.
-
-2. **Style isolation behavior docs**
+1. **Style isolation behavior docs**
    - Document ShadowRoot on/off behavior and how style isolation changes in light DOM mode.
    - Clarify that light DOM preview can inherit shell styles and include recommendations for scoping.
 
-3. **Preview UX polish**
+2. **Preview UX polish**
    - Keep tooltip affordances for mode-specific behavior.
    - Continue tightening panel control alignment and spacing without introducing extra markup.
-
-4. **Theming (light + dark)**
-   - Keep the existing dark mode as the baseline and add a first-class light theme.
-   - Move key colors to semantic CSS variables and define both theme palettes.
-   - Ensure component panels, controls, editor chrome, preview shell, and tooltips all have complete light-mode coverage.
-   - Verify contrast/accessibility across both themes and preserve visual hierarchy parity.