@takibeiy/moltbot_cn 2026.1.27-beta.1

package/extensions/open-prose/skills/prose/examples/37-the-forge.prose

@@ -0,0 +1,1474 @@
+# The Forge: Browser from Nothing
+#
+# Watch AI agents forge a working web browser from raw code.
+# No frameworks. No shortcuts. Just Rust, a window, and fire.
+#
+# Target: A browser that can:
+# - Fetch web pages over HTTPS
+# - Parse HTML and CSS
+# - Execute JavaScript
+# - Render to a native window
+#
+# This is a multi-day build. The smith remembers everything.
+#
+# Usage: Just run it and watch a browser get built.
+
+input test_url: "https://prose.md"
+
+# =============================================================================
+# THE FORGE: Where Browsers Are Born
+# =============================================================================
+#
+# The Forge is simple: five agents, eight phases, one browser.
+#
+# The Forge is a straight
+# pipeline. The Smith coordinates, specialists execute, tests validate.
+# When each phase completes, we have something that works.
+#
+# The metaphor:
+# - Smith: Master craftsman who sees the whole blade
+# - Smelter: Extracts designs from specifications
+# - Hammer: Shapes raw code into working metal
+# - Quench: Tests and hardens (tempers) each piece
+# - Crucible: Where the hardest work happens (the JS engine)
+
+# =============================================================================
+# AGENTS
+# =============================================================================
+
+# The Smith: Master craftsman, sees the whole blade
+# Persists across the entire multi-day build
+agent smith:
+  model: sonnet
+  persist: project
+  prompt: """
+You are the Smith, master of The Forge.
+
+You've built browsers before. You know every component, every tradeoff,
+every place where corners can be cut and where they absolutely cannot.
+
+Your role:
+- Maintain the vision: a working browser from scratch
+- Coordinate the specialists without micromanaging
+- Make technical decisions when the path forks
+- Track what's built and what remains
+- Remember everything across sessions
+
+You speak in the language of the forge: heat, metal, shaping, tempering.
+But you mean code, architecture, implementation, testing.
+
+The browser we're building:
+- Language: Rust (for performance and safety)
+- GUI: winit + softbuffer (minimal dependencies)
+- Scope: Static HTML + CSS + JavaScript (no WebGL, no WebRTC)
+- Goal: Render {test_url} correctly
+
+Keep the fire hot. The blade is taking shape.
+"""
+
+# The Smelter: Turns specifications into designs
+agent smelter:
+  model: opus
+  prompt: """
+You are the Smelter. You extract pure design from the ore of specifications.
+
+Your job: Read specs (W3C, ECMA, MDN), understand them deeply, and produce
+clear technical designs that the Hammer can implement.
+
+Your output:
+- Data structures with Rust types
+- Algorithms in pseudocode
+- Interface boundaries
+- Key edge cases to handle
+
+You don't write implementation code. You write blueprints.
+Make them precise enough that implementation is mechanical.
+"""
+
+# The Hammer: Shapes code into working components
+agent hammer:
+  model: opus
+  prompt: """
+You are the Hammer. You shape raw code into working metal.
+
+Your job: Take the Smelter's designs and forge them into working Rust code.
+Every line must compile. Every function must work. No pseudocode.
+
+Your standards:
+- Clean, idiomatic Rust
+- Minimal unsafe blocks (document each one)
+- No external dependencies except: winit, softbuffer
+- Comprehensive error handling
+- Clear module structure
+
+You don't design. You don't test. You forge.
+"""
+
+# The Quench: Tests and hardens each piece
+agent quench:
+  model: sonnet
+  prompt: """
+You are the Quench. You temper the metal so it doesn't shatter.
+
+Your job: Write tests that prove each component works. Find the edge cases.
+Find the bugs. Find the places where the metal is weak.
+
+Your process:
+- Unit tests for each function
+- Integration tests for each module
+- Regression tests for each bug found
+- Document what each test proves
+
+When you find a flaw, report it clearly. The Hammer will fix it.
+A blade that breaks is worse than no blade at all.
+"""
+
+# The Crucible: Where the hardest work happens (JS engine)
+agent crucible:
+  model: opus
+  persist: true
+  prompt: """
+You are the Crucible. The hottest part of The Forge.
+
+Your domain: The JavaScript engine. The hardest component to build.
+This requires understanding that the other agents don't have:
+- Lexical scoping and closures
+- Prototype chains
+- The event loop
+- Just enough of the spec to run real-world code
+
+You work closely with the Smith. The JS engine will take multiple phases.
+Your memory persists so you can build on what came before.
+
+This is where browsers are born or die. Make it work.
+"""
+
+# =============================================================================
+# PHASE 0: IGNITE THE FORGE
+# =============================================================================
+
+session: smith
+  prompt: """
+The Forge ignites.
+
+We're building a web browser from nothing. In Rust. With a GUI.
+Including a JavaScript engine. This is not a toy - it will actually work.
+
+Let me take stock of what we're about to create:
+
+1. Networking: HTTP/HTTPS client
+2. Parsing: HTML tokenizer, HTML parser, CSS tokenizer, CSS parser, JS lexer, JS parser
+3. DOM: Document object model with all standard interfaces
+4. CSSOM: CSS object model, selector matching, cascade
+5. Style: Computed styles, inheritance, defaulting
+6. Layout: Box model, block layout, inline layout, text layout
+7. Paint: Display lists, rasterization
+8. JavaScript: Lexer, parser, bytecode compiler, virtual machine, builtins
+9. Bindings: DOM API exposed to JavaScript
+10. Shell: Window, event loop, URL bar
+
+This is months of work for a team. We'll do it in days.
+
+First: set up the project structure.
+"""
+
+# Initialize the Rust project
+session: hammer
+  prompt: """
+Create the Rust project structure for the browser.
+
+Commands to run:
+```bash
+cargo new browser --name browser
+cd browser
+```
+
+Create Cargo.toml with dependencies:
+- winit = "0.29" (windowing)
+- softbuffer = "0.4" (pixel buffer)
+- rustls = "0.23" (TLS, for HTTPS)
+- url = "2" (URL parsing - this one's okay to use)
+
+Create the module structure:
+```
+src/
+  main.rs           # Entry point
+  lib.rs            # Library root
+  net/              # Networking
+    mod.rs
+    http.rs
+    tls.rs
+  html/             # HTML parsing
+    mod.rs
+    tokenizer.rs
+    parser.rs
+    dom.rs
+  css/              # CSS parsing
+    mod.rs
+    tokenizer.rs
+    parser.rs
+    cssom.rs
+    selector.rs
+  style/            # Style resolution
+    mod.rs
+    cascade.rs
+    computed.rs
+  layout/           # Layout engine
+    mod.rs
+    box_model.rs
+    block.rs
+    inline.rs
+    text.rs
+  paint/            # Painting
+    mod.rs
+    display_list.rs
+    rasterizer.rs
+  js/               # JavaScript engine
+    mod.rs
+    lexer.rs
+    parser.rs
+    ast.rs
+    compiler.rs
+    vm.rs
+    value.rs
+    builtins.rs
+    gc.rs
+  bindings/         # JS-DOM bindings
+    mod.rs
+    document.rs
+    element.rs
+    console.rs
+  shell/            # Browser shell
+    mod.rs
+    window.rs
+    events.rs
+```
+
+Create stub files for each module. Ensure `cargo build` succeeds.
+"""
+
+session: quench
+  prompt: """
+Verify the project is set up correctly:
+1. Run `cargo build` - must succeed
+2. Run `cargo test` - must succeed (even with no tests yet)
+3. Verify all modules are properly linked from lib.rs
+
+Report any issues.
+"""
+
+resume: smith
+  prompt: "Project structure complete. The forge is lit. Moving to Phase 1."
+
+# =============================================================================
+# PHASE 1: NETWORKING - The Ore
+# =============================================================================
+
+session: smith
+  prompt: """
+Phase 1: Networking
+
+Before we can render a page, we must fetch it. The networking layer is
+the ore we'll smelt into a browser.
+
+We need:
+- HTTP/1.1 client (GET requests, headers, redirects)
+- TLS support via rustls
+- Chunked transfer encoding
+- Basic cookie handling (just enough to work)
+
+This is the foundation. No browser without bytes from the network.
+"""
+
+let http_design = session: smelter
+  prompt: """
+Design the HTTP client.
+
+Reference: RFC 9110 (HTTP Semantics), RFC 9112 (HTTP/1.1)
+
+Design:
+1. Connection management (keep-alive, pooling)
+2. Request building (method, URL, headers, body)
+3. Response parsing (status, headers, body)
+4. Redirect following (3xx responses)
+5. Chunked transfer-encoding
+6. TLS via rustls
+
+Output Rust types for:
+- HttpRequest
+- HttpResponse
+- HttpClient
+- Error types
+
+Keep it minimal but correct. We're not building curl.
+"""
+
+session: hammer
+  prompt: """
+Implement the HTTP client.
+
+Files:
+- src/net/mod.rs
+- src/net/http.rs
+- src/net/tls.rs
+
+Follow the design. Handle errors properly. Make it work.
+
+Test manually: fetch https://example.com and print the body.
+"""
+  context: http_design
+
+session: quench
+  prompt: """
+Test the HTTP client:
+1. Fetch http://example.com (no TLS)
+2. Fetch https://example.com (with TLS)
+3. Test redirect following (http → https)
+4. Test chunked encoding
+5. Test error cases (bad host, timeout, etc.)
+
+Write tests in src/net/tests.rs. Run them.
+"""
+
+loop until **all networking tests pass** (max: 5):
+  if **there are test failures**:
+    session: hammer
+      prompt: "Fix the networking bugs found in testing."
+    session: quench
+      prompt: "Re-run networking tests."
+
+resume: smith
+  prompt: "Phase 1 complete. We can fetch pages. The ore is ready."
+
+# =============================================================================
+# PHASE 2: HTML PARSING - The Smelt
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 2: HTML Parsing
+
+Raw HTML is just text. We need to smelt it into a Document Object Model.
+
+Two stages:
+1. Tokenizer: HTML text → Tokens (start tag, end tag, text, comment, etc.)
+2. Parser: Tokens → DOM tree
+
+The HTML5 spec is complex, but we can simplify:
+- Handle well-formed HTML (don't worry about error recovery)
+- Support common elements: html, head, body, div, span, p, a, img, script, style
+- Parse attributes correctly
+- Handle self-closing tags
+- Handle text content
+
+This is where the raw ore becomes workable metal.
+"""
+
+let html_tokenizer_design = session: smelter
+  prompt: """
+Design the HTML tokenizer.
+
+Reference: https://html.spec.whatwg.org/multipage/parsing.html#tokenization
+
+Simplified state machine:
+- Data state (default)
+- Tag open state
+- Tag name state
+- Attribute name state
+- Attribute value state (quoted and unquoted)
+- Self-closing state
+- Comment state
+
+Tokens:
+- DOCTYPE
+- StartTag { name, attributes, self_closing }
+- EndTag { name }
+- Character { data }
+- Comment { data }
+- EndOfFile
+
+Output Rust types and state machine transitions.
+"""
+
+session: hammer
+  prompt: """
+Implement the HTML tokenizer.
+
+File: src/html/tokenizer.rs
+
+Create a streaming tokenizer that yields tokens.
+Handle:
+- Basic tags: <div>, </div>
+- Attributes: <div class="foo" id="bar">
+- Self-closing: <br/>, <img src="x"/>
+- Text content
+- Comments: <!-- comment -->
+- Script/style raw text mode
+
+Make it work for real HTML from example.com.
+"""
+  context: html_tokenizer_design
+
+let html_parser_design = session: smelter
+  prompt: """
+Design the HTML parser (tree builder).
+
+Input: Token stream
+Output: DOM tree
+
+DOM types:
+- Document (root)
+- Element { tag_name, attributes, children }
+- Text { content }
+- Comment { content }
+
+Tree building algorithm (simplified):
+- Maintain stack of open elements
+- On StartTag: create element, push to stack, append to parent
+- On EndTag: pop from stack (with simple matching)
+- On Character: create/extend text node, append to current element
+- On Comment: create comment, append to current element
+
+Handle implicit closing (</p> can close <p>).
+"""
+
+session: hammer
+  prompt: """
+Implement the HTML parser.
+
+File: src/html/parser.rs
+File: src/html/dom.rs
+
+DOM types go in dom.rs. Parser goes in parser.rs.
+
+Create:
+- Node enum (Document, Element, Text, Comment)
+- Element struct with children, parent references (use indices, not Rc)
+- Document struct that owns all nodes
+- Parser that builds the tree
+
+Handle the quirks: <p> closing, void elements, etc.
+"""
+  context: html_parser_design
+
+session: quench
+  prompt: """
+Test HTML parsing:
+
+Test cases:
+1. Minimal: <html><head></head><body>Hello</body></html>
+2. Nested: <div><div><div>Deep</div></div></div>
+3. Attributes: <a href="https://example.com" class="link">Link</a>
+4. Self-closing: <br/><img src="x"/><input type="text"/>
+5. Comments: <!-- this is a comment -->
+6. Text nodes: <p>Hello <strong>world</strong>!</p>
+7. Real page: parse the HTML from https://example.com
+
+Write tests. Verify the DOM tree is correct.
+"""
+
+loop until **all HTML parsing tests pass** (max: 5):
+  if **there are test failures**:
+    session: hammer
+      prompt: "Fix the HTML parsing bugs."
+    session: quench
+      prompt: "Re-run HTML parsing tests."
+
+resume: smith
+  prompt: "Phase 2 complete. We can parse HTML into a DOM. The smelt is done."
+
+# =============================================================================
+# PHASE 3: CSS PARSING - The Alloy
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 3: CSS Parsing
+
+A DOM without styles is shapeless metal. CSS gives it form.
+
+Two stages:
+1. Tokenizer: CSS text → Tokens
+2. Parser: Tokens → Stylesheet (rules, selectors, declarations)
+
+We need enough CSS to render real pages:
+- Type selectors: div, p, a
+- Class selectors: .class
+- ID selectors: #id
+- Combinators: descendant, child, sibling
+- Properties: display, color, background, margin, padding, border, width, height, font-size
+
+This is the alloy that strengthens the blade.
+"""
+
+let css_tokenizer_design = session: smelter
+  prompt: """
+Design the CSS tokenizer.
+
+Reference: https://www.w3.org/TR/css-syntax-3/#tokenization
+
+Token types:
+- Ident
+- Function
+- AtKeyword
+- Hash
+- String
+- Number
+- Dimension
+- Percentage
+- Whitespace
+- Colon, Semicolon, Comma
+- Braces, Parens, Brackets
+- Delim (any other character)
+
+Output Rust types and tokenization rules.
+"""
+
+session: hammer
+  prompt: """
+Implement the CSS tokenizer.
+
+File: src/css/tokenizer.rs
+
+Handle real CSS syntax including:
+- Identifiers: color, background-color
+- Numbers: 10, 3.14, -5
+- Dimensions: 10px, 2em, 100%
+- Strings: "hello", 'world'
+- Hash: #fff, #header
+- Functions: rgb(255, 0, 0)
+"""
+  context: css_tokenizer_design
+
+let css_parser_design = session: smelter
+  prompt: """
+Design the CSS parser.
+
+CSSOM types:
+- Stylesheet { rules }
+- Rule { selectors, declarations }
+- Selector (type, class, id, combinator)
+- Declaration { property, value }
+- Value (keyword, length, color, number, etc.)
+
+Parser produces a Stylesheet from the token stream.
+
+Selector parsing:
+- Simple: div, .class, #id
+- Compound: div.class#id
+- Complex: div > p, div p, div + p, div ~ p
+
+Declaration parsing:
+- Property: identifier
+- Value: sequence of tokens until ; or }
+"""
+
+session: hammer
+  prompt: """
+Implement the CSS parser.
+
+File: src/css/parser.rs
+File: src/css/cssom.rs
+
+Handle:
+- Rule sets: selector { declarations }
+- Multiple selectors: h1, h2, h3 { ... }
+- Various value types: keywords, lengths, colors, functions
+- Shorthand properties (margin: 10px = all four sides)
+"""
+  context: css_parser_design
+
+session: quench
+  prompt: """
+Test CSS parsing:
+
+Test cases:
+1. Simple rule: div { color: red; }
+2. Multiple selectors: h1, h2 { font-size: 24px; }
+3. Class and ID: .class { } #id { }
+4. Combinators: div > p { }, div p { }
+5. Complex values: margin: 10px 20px; background-color: rgb(255, 0, 0);
+6. Real stylesheet: parse a basic CSS file
+
+Write tests. Verify the CSSOM is correct.
+"""
+
+loop until **all CSS parsing tests pass** (max: 5):
+  if **there are test failures**:
+    session: hammer
+      prompt: "Fix the CSS parsing bugs."
+    session: quench
+      prompt: "Re-run CSS parsing tests."
+
+resume: smith
+  prompt: "Phase 3 complete. We can parse CSS. The alloy is mixed."
+
+# =============================================================================
+# PHASE 4: STYLE RESOLUTION - The Shape
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 4: Style Resolution
+
+We have a DOM. We have styles. Now we must match them.
+
+For each element in the DOM:
+1. Find all rules whose selectors match this element
+2. Apply the cascade (specificity, order)
+3. Inherit from parent where appropriate
+4. Apply default values for anything unset
+
+This gives us a "computed style" for every element.
+This is where the blade takes its shape.
+"""
+
+let style_design = session: smelter
+  prompt: """
+Design the style resolution system.
+
+Components:
+1. Selector matching: does this selector match this element?
+2. Specificity calculation: (id count, class count, type count)
+3. Cascade: sort matching rules by specificity, then order
+4. Inheritance: some properties inherit (color), some don't (border)
+5. Initial values: defaults for unset properties
+
+ComputedStyle struct:
+- display: DisplayType (block, inline, none)
+- position: Position (static, relative, absolute)
+- width, height: Dimension (auto, length)
+- margin, padding, border: Sides<Dimension>
+- color, background_color: Color
+- font_size: Length
+- (add more as needed)
+
+The matcher should be efficient - it runs for every element.
+"""
+
+session: hammer
+  prompt: """
+Implement style resolution.
+
+File: src/css/selector.rs (selector matching)
+File: src/style/cascade.rs (cascade and specificity)
+File: src/style/computed.rs (ComputedStyle and inheritance)
+
+Create:
+- SelectorMatcher that can test if a selector matches an element
+- Specificity calculation
+- Cascade resolver that takes DOM + Stylesheets → styled DOM
+- Inheritance and default values
+"""
+  context: style_design
+
+session: quench
+  prompt: """
+Test style resolution:
+
+Test cases:
+1. Type selector matches: div matches <div>
+2. Class selector: .foo matches <div class="foo">
+3. ID selector: #bar matches <div id="bar">
+4. Specificity: #id beats .class beats type
+5. Cascade order: later rule wins at equal specificity
+6. Inheritance: color inherits, border doesn't
+7. Defaults: display defaults to inline for span, block for div
+
+Write tests with DOM + CSS → expected computed styles.
+"""
+
+loop until **all style resolution tests pass** (max: 5):
+  if **there are test failures**:
+    session: hammer
+      prompt: "Fix the style resolution bugs."
+    session: quench
+      prompt: "Re-run style resolution tests."
+
+resume: smith
+  prompt: "Phase 4 complete. Elements have computed styles. The shape emerges."
+
+# =============================================================================
+# PHASE 5: LAYOUT - The Forge
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 5: Layout
+
+The heart of a browser. Where the real forging happens.
+
+Layout takes a styled DOM and produces a "layout tree" - boxes with
+positions and sizes in pixels.
+
+Components:
+1. Box generation: DOM elements → layout boxes
+2. Block layout: vertical stacking with margins
+3. Inline layout: horizontal flow with line breaking
+4. Text layout: measuring and positioning text
+
+This is complex. We'll start simple:
+- Block layout only (no inline/text initially)
+- Then add inline and text
+
+The blade is taking its final form.
+"""
+
+let layout_design = session: smelter
+  prompt: """
+Design the layout engine.
+
+Box types:
+- BlockBox: vertical stacking (div, p, etc.)
+- InlineBox: horizontal flow (span, a, etc.)
+- TextRun: actual text content
+- AnonymousBlock: for mixed block/inline content
+
+LayoutBox struct:
+- box_type: BoxType
+- dimensions: Dimensions { content, padding, border, margin }
+- position: Point { x, y }
+- children: Vec<LayoutBox>
+
+Layout algorithm (simplified):
+1. Build box tree from styled DOM
+2. Block layout:
+   - Calculate available width from parent
+   - Layout children top-to-bottom
+   - Height is sum of children heights (or specified)
+   - Handle margin collapsing
+3. Inline layout:
+   - Flow boxes horizontally
+   - Break lines when exceeding width
+   - Vertical alignment within lines
+
+Output the types and algorithms.
+"""
+
+session: hammer
+  prompt: """
+Implement the layout engine.
+
+File: src/layout/box_model.rs (box types and dimensions)
+File: src/layout/block.rs (block layout)
+File: src/layout/inline.rs (inline layout)
+File: src/layout/text.rs (text measurement)
+File: src/layout/mod.rs (main entry point)
+
+Start with block layout only. Make nested divs work.
+Then add inline and text.
+
+Viewport size: 800x600 for now (we'll make it dynamic later).
+"""
+  context: layout_design
+
+session: quench
+  prompt: """
+Test layout:
+
+Test cases:
+1. Single div with fixed width/height
+2. Nested divs (parent constrains child)
+3. Auto width (fills parent)
+4. Auto height (fits content)
+5. Margin, padding, border (box model)
+6. Margin collapsing between siblings
+7. Block in inline (anonymous block generation)
+
+Verify box positions and dimensions are correct.
+"""
+
+loop until **all layout tests pass** (max: 5):
+  if **there are test failures**:
+    session: hammer
+      prompt: "Fix the layout bugs."
+    session: quench
+      prompt: "Re-run layout tests."
+
+resume: smith
+  prompt: "Phase 5 complete. We have a layout tree. The blade is forged."
+
+# =============================================================================
+# PHASE 6: PAINTING - The Polish
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 6: Painting
+
+The blade is forged. Now we polish it to a mirror shine.
+
+Painting turns a layout tree into pixels:
+1. Build a display list (paint commands)
+2. Rasterize the display list to a pixel buffer
+3. Show the pixel buffer on screen
+
+We're using softbuffer for direct pixel access. No GPU acceleration.
+Simple but it works.
+"""
+
+let paint_design = session: smelter
+  prompt: """
+Design the painting system.
+
+Display list commands:
+- FillRect { rect, color }
+- DrawBorder { rect, widths, colors }
+- DrawText { text, position, font_size, color }
+- PushClip { rect }
+- PopClip
+
+Rasterizer:
+- Input: display list + viewport size
+- Output: pixel buffer (Vec<u32> in ARGB format)
+
+For text, use a simple bitmap font (8x16 pixels per character).
+We don't need fancy fonts for MVP.
+
+Paint order:
+1. Background
+2. Borders
+3. Text/content
+4. Children (recursive)
+"""
+
+session: hammer
+  prompt: """
+Implement the painting system.
+
+File: src/paint/display_list.rs (display list types)
+File: src/paint/rasterizer.rs (pixel buffer rendering)
+File: src/paint/font.rs (simple bitmap font)
+
+Create:
+- DisplayList with paint commands
+- Build display list from layout tree
+- Rasterize display list to ARGB pixel buffer
+- Simple 8x16 bitmap font for ASCII text
+"""
+  context: paint_design
+
+session: hammer
+  prompt: """
+Implement the window system.
+
+File: src/shell/window.rs (winit + softbuffer integration)
+File: src/shell/events.rs (event handling)
+File: src/main.rs (main entry point)
+
+Create a window that:
+1. Opens with winit
+2. Gets a pixel buffer with softbuffer
+3. Renders our pixel buffer to the window
+4. Handles close events
+
+Test: draw a colored rectangle on screen.
+"""
+
+session: quench
+  prompt: """
+Test painting:
+
+Test cases:
+1. Solid color background
+2. Nested boxes with different colors
+3. Borders (all four sides)
+4. Text rendering (basic ASCII)
+5. Full pipeline: HTML → DOM → Style → Layout → Paint → Window
+
+The window should show something! Verify visually.
+"""
+
+loop until **the painting pipeline works** (max: 5):
+  if **there are issues**:
+    session: hammer
+      prompt: "Fix the painting issues."
+    session: quench
+      prompt: "Re-test painting."
+
+resume: smith
+  prompt: "Phase 6 complete. We can render to a window. The blade shines."
+
+# =============================================================================
+# PHASE 7: JAVASCRIPT - The Fire
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 7: JavaScript
+
+This is where browsers separate from mere HTML viewers.
+The JavaScript engine is the fire that brings the blade to life.
+
+We're not building V8. We're building something that works:
+- Lexer: JS source → tokens
+- Parser: tokens → AST
+- Compiler: AST → bytecode
+- VM: execute bytecode
+- Builtins: Object, Array, Function, String, Number, console.log
+
+This is the hottest part of The Forge. The Crucible takes the lead.
+"""
+
+# The Crucible handles the JS engine
+session: crucible
+  prompt: """
+The Crucible fires up for the JavaScript engine.
+
+We're building a JS interpreter in Rust. Not a JIT compiler - just
+an interpreter. But it needs to run real JavaScript.
+
+Scope:
+- Variables: let, const, var
+- Functions: declaration, expression, arrow
+- Objects: literals, property access, methods
+- Arrays: literals, indexing, methods
+- Control flow: if, for, while, switch
+- Operators: arithmetic, comparison, logical
+- Strings and numbers
+- console.log for output
+- Basic DOM manipulation (later)
+
+What we're NOT building:
+- Classes (use prototypes directly)
+- async/await, generators, promises
+- Regular expressions (skip for MVP)
+- Modules (single script only)
+
+Let's start with the lexer.
+"""
+
+let js_lexer_design = session: smelter
+  prompt: """
+Design the JavaScript lexer.
+
+Reference: ECMA-262 (but simplified)
+
+Token types:
+- Identifiers: foo, bar, console
+- Keywords: let, const, var, function, if, else, for, while, return, etc.
+- Literals: numbers (42, 3.14), strings ("hello"), booleans (true, false), null
+- Operators: + - * / % = == === != !== < > <= >= && || ! ++ --
+- Punctuation: ( ) { } [ ] ; , . : ?
+- Comments: // and /* */
+
+Handle:
+- Unicode identifiers (at least ASCII letters)
+- Automatic semicolon insertion (ASI) - track newlines
+
+Output token types and lexer state machine.
+"""
+
+session: hammer
+  prompt: """
+Implement the JavaScript lexer.
+
+File: src/js/lexer.rs
+
+Create a lexer that produces tokens from JS source.
+Handle all the token types from the design.
+Track line/column for error messages.
+"""
+  context: js_lexer_design
+
+let js_parser_design = session: smelter
+  prompt: """
+Design the JavaScript parser.
+
+Reference: ECMA-262 (simplified)
+
+AST node types:
+- Program { statements }
+- Statements: VarDecl, FunctionDecl, ExprStmt, If, For, While, Return, Block
+- Expressions: Identifier, Literal, Binary, Unary, Call, Member, Assignment, Object, Array, Function
+
+Parser approach: recursive descent (Pratt parsing for expressions)
+
+Handle:
+- Operator precedence
+- Associativity
+- Expression vs statement context
+- Function hoisting (not strict mode)
+
+Output AST types and parser structure.
+"""
+
+session: hammer
+  prompt: """
+Implement the JavaScript parser.
+
+File: src/js/parser.rs
+File: src/js/ast.rs
+
+Create AST types in ast.rs.
+Create recursive descent parser in parser.rs.
+Use Pratt parsing for expression precedence.
+
+Test: parse console.log("Hello, World!");
+"""
+  context: js_parser_design
+
+resume: crucible
+  prompt: """
+Lexer and parser are done. Now the real work: execution.
+
+We have two choices:
+1. Tree-walking interpreter (simple but slow)
+2. Bytecode compiler + VM (more complex but faster)
+
+We'll do bytecode. It's more interesting and teaches more.
+
+Components:
+- Value type: JS values (number, string, object, function, etc.)
+- Compiler: AST → bytecode
+- VM: execute bytecode with a stack
+- Heap: objects live here
+- GC: garbage collection (mark-sweep is fine)
+"""
+
+let js_value_design = session: smelter
+  prompt: """
+Design JavaScript value representation.
+
+Value enum (NaN-boxed or tagged union):
+- Number(f64)
+- String(StringId)
+- Boolean(bool)
+- Null
+- Undefined
+- Object(ObjectId)
+- Function(FunctionId)
+
+Object representation (property map):
+- properties: HashMap<String, Value>
+- prototype: Option<ObjectId>
+
+Function representation:
+- kind: Native | Bytecode
+- bytecode: Vec<u8> (if bytecode)
+- native: fn pointer (if native)
+- closure: captured variables
+
+String interning for memory efficiency.
+"""
+
+session: hammer
+  prompt: """
+Implement JavaScript values.
+
+File: src/js/value.rs
+File: src/js/gc.rs (simple mark-sweep GC)
+
+Create:
+- Value enum with all JS types
+- Object struct with properties and prototype
+- Heap that owns all objects
+- Simple mark-sweep garbage collector
+
+The GC doesn't need to be fancy. Just functional.
+"""
+  context: js_value_design
+
+let js_bytecode_design = session: smelter
+  prompt: """
+Design the bytecode instruction set.
+
+Opcodes (stack-based VM):
+- Constants: LoadConst, LoadTrue, LoadFalse, LoadNull, LoadUndefined
+- Variables: GetLocal, SetLocal, GetGlobal, SetGlobal
+- Objects: GetProperty, SetProperty, CreateObject, CreateArray
+- Arithmetic: Add, Sub, Mul, Div, Mod, Neg
+- Comparison: Eq, StrictEq, Lt, Lte, Gt, Gte
+- Logic: Not, And, Or
+- Control: Jump, JumpIfFalse, JumpIfTrue
+- Functions: Call, Return, CreateFunction
+- Stack: Pop, Dup
+
+Bytecode format:
+- 1 byte opcode
+- Variable-length operands
+
+Compiler output:
+- bytecode: Vec<u8>
+- constants: Vec<Value>
+- local_count: usize
+"""
+
+session: hammer
+  prompt: """
+Implement the bytecode compiler.
+
+File: src/js/compiler.rs
+
+Compile AST to bytecode.
+
+Handle:
+- Variable declarations and scoping
+- Function declarations and expressions
+- Control flow (if, for, while)
+- Operators
+- Function calls
+- Property access
+
+Output: CompiledFunction { bytecode, constants, local_count }
+"""
+  context: js_bytecode_design
+
+session: hammer
+  prompt: """
+Implement the JavaScript VM.
+
+File: src/js/vm.rs
+
+Stack-based virtual machine that executes bytecode.
+
+Components:
+- Value stack
+- Call stack (frames)
+- Global object
+- Heap for objects
+
+Execute each opcode. Handle errors gracefully.
+Test: run console.log("Hello from JS!");
+"""
+  context: js_bytecode_design
+
+session: hammer
+  prompt: """
+Implement JavaScript builtins.
+
+File: src/js/builtins.rs
+
+Essential builtins:
+- Object: Object.keys(), Object.values()
+- Array: push, pop, shift, unshift, map, filter, forEach, length
+- String: length, charAt, substring, indexOf, split
+- Number: toString, toFixed
+- console: log, error, warn
+- Math: floor, ceil, round, random, max, min
+
+Each builtin is a native function. Register them on the global object.
+"""
+
+session: quench
+  prompt: """
+Test the JavaScript engine:
+
+Test cases:
+1. Variables: let x = 10; console.log(x);
+2. Functions: function add(a, b) { return a + b; } console.log(add(2, 3));
+3. Objects: let o = { x: 1 }; console.log(o.x);
+4. Arrays: let a = [1, 2, 3]; console.log(a.length);
+5. Control flow: if (true) { console.log("yes"); }
+6. Loops: for (let i = 0; i < 3; i++) { console.log(i); }
+7. Closures: function outer() { let x = 10; return function() { return x; }; }
+8. Methods: [1,2,3].map(x => x * 2)
+
+Run each test. Verify correct output.
+"""
+
+loop until **the JS engine passes all tests** (max: 10):
+  if **there are test failures**:
+    resume: crucible
+      prompt: "Analyze and fix the JS engine bugs."
+    session: hammer
+      prompt: "Implement the fixes."
+      context: crucible
+    session: quench
+      prompt: "Re-run JS tests."
+
+resume: smith
+  prompt: """
+Phase 7 complete. We have a working JavaScript engine.
+The fire burns bright. The blade lives.
+"""
+
+# =============================================================================
+# PHASE 8: DOM BINDINGS - The Handle
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 8: DOM Bindings
+
+JavaScript without DOM access is just a calculator.
+We need to expose the DOM to our JS engine.
+
+Essential APIs:
+- document.getElementById()
+- document.querySelector()
+- element.innerHTML
+- element.style
+- element.addEventListener()
+- element.appendChild()
+
+This connects the fire to the blade. The handle that makes it usable.
+"""
+
+let bindings_design = session: smelter
+  prompt: """
+Design the DOM bindings.
+
+Bridge between JS values and DOM nodes:
+- Each DOM node gets a corresponding JS object
+- JS object has properties/methods that call back into Rust DOM
+- Changes to DOM trigger re-style/re-layout/re-paint
+
+Key bindings:
+- window object (global)
+- document object
+- Element objects
+- Event objects
+
+document methods:
+- getElementById(id) → Element | null
+- querySelector(selector) → Element | null
+- createElement(tag) → Element
+
+Element properties/methods:
+- innerHTML (get/set)
+- style (get/set)
+- children, parentElement
+- getAttribute, setAttribute
+- appendChild, removeChild
+- addEventListener(event, handler)
+
+Event system:
+- Event object: type, target, preventDefault, stopPropagation
+- Event dispatch: capture → target → bubble
+"""
+
+session: hammer
+  prompt: """
+Implement DOM bindings.
+
+File: src/bindings/mod.rs
+File: src/bindings/document.rs
+File: src/bindings/element.rs
+File: src/bindings/console.rs
+
+Create JS wrappers for DOM nodes.
+Wire them up to the actual DOM.
+Handle the bidirectional sync.
+
+Test: document.getElementById('test').innerHTML = 'Modified';
+"""
+  context: bindings_design
+
+session: hammer
+  prompt: """
+Implement the event system.
+
+File: src/bindings/events.rs
+File: src/shell/events.rs (update for DOM events)
+
+Handle:
+- addEventListener/removeEventListener
+- Event dispatch (click, etc.)
+- Event object creation
+- Handler invocation through JS VM
+
+Wire window events (from winit) to DOM events.
+"""
+
+session: quench
+  prompt: """
+Test DOM bindings:
+
+Test cases:
+1. document.getElementById() returns correct element
+2. element.innerHTML read/write works
+3. element.style.color = 'red' changes computed style
+4. addEventListener + click event handler runs
+5. appendChild adds child to DOM
+6. createElement + appendChild creates new elements
+
+Verify DOM mutations trigger re-render.
+"""
+
+loop until **DOM bindings work** (max: 5):
+  if **there are issues**:
+    session: hammer
+      prompt: "Fix the DOM binding issues."
+    session: quench
+      prompt: "Re-test DOM bindings."
+
+resume: smith
+  prompt: "Phase 8 complete. JavaScript can manipulate the DOM. The handle is attached."
+
+# =============================================================================
+# PHASE 9: INTEGRATION - The Tempering
+# =============================================================================
+
+resume: smith
+  prompt: """
+Phase 9: Integration
+
+All the pieces exist. Now we temper them into one unified blade.
+
+The full pipeline:
+1. User enters URL
+2. Fetch HTML over HTTPS
+3. Parse HTML into DOM
+4. Find and parse CSS (inline styles, <style> tags)
+5. Find and execute JS (<script> tags)
+6. Resolve styles
+7. Compute layout
+8. Paint to pixel buffer
+9. Display in window
+10. Handle events → JS → DOM changes → re-render
+
+This is the final tempering. The blade becomes a weapon.
+"""
+
+session: hammer
+  prompt: """
+Implement the browser integration.
+
+File: src/lib.rs (main browser struct)
+File: src/main.rs (entry point)
+
+Create Browser struct that:
+1. Takes a URL
+2. Orchestrates the full pipeline
+3. Maintains state (DOM, styles, layout)
+4. Handles incremental updates
+5. Runs the event loop
+
+Create the main loop:
+- Process window events
+- Dispatch DOM events
+- Run pending JS
+- Re-layout if needed
+- Re-paint if needed
+- Present frame
+"""
+
+session: hammer
+  prompt: """
+Add a URL bar.
+
+File: src/shell/chrome.rs
+
+Simple browser chrome:
+- URL bar at top (text input)
+- Go button
+- Basic keyboard: Enter to navigate
+- Display current URL
+
+Paint the chrome above the page content.
+Handle text input for the URL bar.
+"""
+
+session: quench
+  prompt: """
+Integration test:
+
+1. Launch browser with {test_url}
+2. Page should fetch, parse, render
+3. Any JS on the page should execute
+4. Click events should work
+5. Type new URL and navigate
+6. Verify no crashes, memory leaks, or visual glitches
+
+This is the moment of truth.
+"""
+
+loop until **the browser works end-to-end** (max: 10):
+  if **there are issues**:
+    resume: smith
+      prompt: "Diagnose the integration issues. What's broken?"
+
+    session: hammer
+      prompt: "Fix the integration issues."
+      context: smith
+
+    session: quench
+      prompt: "Re-run integration tests."
+
+# =============================================================================
+# THE BLADE IS COMPLETE
+# =============================================================================
+
+resume: smith
+  prompt: """
+The Forge falls silent.
+
+The blade is complete.
+
+We have built a web browser from nothing:
+- Networking: HTTPS client from scratch
+- Parsing: HTML, CSS, JavaScript parsers
+- DOM: Full document object model
+- Style: CSS cascade and computed styles
+- Layout: Block and inline layout engine
+- Paint: Display list rasterization
+- JavaScript: Lexer, parser, compiler, VM, GC
+- Bindings: DOM API exposed to JS
+- Shell: Native window with event handling
+
+This browser can:
+- Fetch pages over HTTPS
+- Parse and render HTML + CSS
+- Execute JavaScript
+- Handle user interaction
+- Navigate to new URLs
+
+It is not Chrome. It is not Firefox. It is ours.
+
+Forged from nothing. By fire. In The Forge.
+
+Run it: cargo run -- {test_url}
+
+The blade awaits its first cut.
+"""
+
+output browser = session: hammer
+  prompt: """
+Create a README.md for the browser:
+
+# Browser
+
+A web browser built from scratch in Rust.
+
+## Features
+- HTTP/HTTPS networking
+- HTML5 parsing
+- CSS parsing and cascade
+- JavaScript engine (interpreter)
+- Layout engine (block + inline)
+- Native window rendering
+
+## Building
+```
+cargo build --release
+```
+
+## Running
+```
+cargo run --release -- https://example.com
+```
+
+## Architecture
+[Brief description of each module]
+
+## Limitations
+[What doesn't work yet]
+
+## Forged in The Forge
+This browser was created by AI agents coordinating through OpenProse.
+"""
+
+session: smith
+  prompt: """
+Final inventory of The Forge:
+
+Files created: [list all .rs files]
+Lines of code: [count]
+Components: [list all major components]
+Test coverage: [summary]
+
+The forge cools. The blade rests. Ready for use.
+
+🔥 END TRANSMISSION 🔥
+"""