stableclaw 2026.4.6 → 2026.4.8

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

@@ -1,1474 +0,0 @@
-# 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 🔥
-"""