mindforge-cc 11.8.2 → 11.9.0

package/.agent/mindforge/wf-orchestrate-review.md

@@ -0,0 +1,35 @@
+---
+description: "4-lens parallel review — factual, domain, safety, style — coordinated as one panel and merged into a single verdict"
+---
+# /mindforge:wf-orchestrate-review
+
+Runs the **Orchestrate Review** dynamic workflow.
+
+## Usage
+`/mindforge:wf-orchestrate-review [target artifact, or describe what to review]`
+
+## What it does
+- **Scope**: Pins the target and any domain context
+- **Panel**: 4 parallel lenses — factual accuracy, domain correctness, safety, style/voice
+- **Consensus**: Merges all findings, deduplicates, assigns severity (blocking/major/minor)
+- **Verdict**: APPROVED / APPROVED_WITH_SUGGESTIONS / CHANGES_REQUIRED / BLOCKING
+
+## Running
+
+Invoke via Claude Code's Workflow tool:
+
+```
+Workflow({
+  scriptPath: ".mindforge/dynamic-workflows/scripts/orchestrate-review.js",
+  args: "<your input>"
+})
+```
+
+`args` can be a plain string target, or `{ target, domainContext }` for reviews that need
+subject-matter framing (e.g. "this is a medical dosage guide" so the domain lens knows
+what expertise to check against).
+
+Or discover via CLI:
+```bash
+node bin/mindforge-cli.js workflow info orchestrate-review
+```

package/.agent/mindforge/wf-verification-loop.md

@@ -0,0 +1,45 @@
+---
+description: "Implementer vs. scorer loop: revise each round, score against a fixed metric, keep re-attempting until the score is maxed or a round cap is hit"
+---
+# /mindforge:wf-verification-loop
+
+Runs the **Verification Loop** dynamic workflow.
+
+## Usage
+`/mindforge:wf-verification-loop [task description, or { task, metric, targetScore, maxRounds }]`
+
+## What it does
+- **Scope**: Pins the artifact, the metric, and the target score / max-round cap
+- **Round**: An implementer agent revises the artifact; a separate scorer agent grades it
+  against the same fixed rubric every round; repeats until the target score is hit, the
+  score plateaus for `plateauRounds` consecutive rounds, or `maxRounds` is reached
+- **Report**: Round-by-round score history plus the final artifact
+
+Unlike a fixed-count review pass, this loop's whole point is that the implementer keeps
+re-attempting the SAME task, judged by a separate scorer, until the score stops moving —
+not a one-shot audit.
+
+## Running
+
+Invoke via Claude Code's Workflow tool:
+
+```
+Workflow({
+  scriptPath: ".mindforge/dynamic-workflows/scripts/verification-loop.js",
+  args: {
+    task: "Tighten this system prompt for token efficiency without losing instruction coverage",
+    metric: "10 pts clarity, 10 pts token economy, 10 pts no lost instructions",
+    targetScore: 95,
+    maxRounds: 8
+  }
+})
+```
+
+`args` can also be a plain string task description if you want the scorer to infer and
+hold its own rubric. Defaults: `targetScore` 95, `maxRounds` 8, `plateauRounds` 2 (stop
+early if the score doesn't improve for 2 consecutive rounds).
+
+Or discover via CLI:
+```bash
+node bin/mindforge-cli.js workflow info verification-loop
+```

package/.agent/mindforge/wf-workflow-optimizer.md

@@ -0,0 +1,51 @@
+---
+description: "Builder + scorer + a distinct process-optimizer role: proposes structural changes to the PROCESS itself across rounds, not just fixes to one output"
+---
+# /mindforge:wf-workflow-optimizer
+
+Runs the **Workflow Optimizer** dynamic workflow.
+
+## Usage
+`/mindforge:wf-workflow-optimizer [task family description, or { taskFamily, metric, maxRounds, priorHistory }]`
+
+## What it does
+- **Scope**: Pins the task family, the fixed outcome metric, and any prior round history
+  you supply (this script holds no state of its own between invocations)
+- **Cycle**: A builder agent runs under the *current* process instructions; a separate
+  scorer agent grades the output against the fixed metric; a **third, distinct
+  process-optimizer agent** — with no role in building or scoring — diagnoses *why* the
+  process produced that result and rewrites the builder's instructions for next round.
+  Repeats until the optimizer judges the process has converged or `maxRounds` is hit.
+- **Report**: The score trend across rounds alongside every round's structural diagnosis,
+  so you can see whether rising scores came from real process changes, not just luck.
+
+This is not "implementer vs. scorer, keep re-attempting the same task" (that's
+`/mindforge:wf-verification-loop`, one artifact, one metric, no separate optimizer role).
+This workflow's object of improvement is the **process itself** — the builder's own
+instructions evolve round to round, and the deliverable includes that evolution history,
+not just a final artifact.
+
+## Running
+
+Invoke via Claude Code's Workflow tool:
+
+```
+Workflow({
+  scriptPath: ".mindforge/dynamic-workflows/scripts/workflow-optimizer.js",
+  args: {
+    taskFamily: "Write a one-paragraph executive summary of a technical incident postmortem",
+    metric: "30 pts non-technical-reader clarity, 30 pts root-cause traceability, 40 pts action-item concreteness",
+    maxRounds: 5
+  }
+})
+```
+
+To continue optimizing the SAME process across separate sessions, pass the previous run's
+returned `processHistory` back in as `args.priorHistory` — the script itself has no
+filesystem access and keeps no state between invocations, so cross-session continuity is
+the caller's responsibility.
+
+Or discover via CLI:
+```bash
+node bin/mindforge-cli.js workflow info workflow-optimizer
+```

package/.agent/skills/article-illustrator/SKILL.md

@@ -86,8 +86,8 @@ If the user asks for a different layout (e.g., images alongside the article, or
 
 If the user supplies reference images (paths pasted inline, attachments, or a URL):
 
-1. For each reference, call `vision_analyze` with the path/URL and a question asking for style, palette, composition, and subject. Record the returned description in `{output-dir}/references/NN-ref-{slug}.md` via `write_file`.
-2. **Do not** try to copy the binary via `write_file` / `read_file` — those are text-only. If you want a local copy for the record, use `terminal` (`cp "$src" "{output-dir}/references/NN-ref-{slug}.{ext}"`). The skill itself never needs to read the binary; it works off the vision description.
+1. For each reference, call `vision_analyze` with the path/URL and a question asking for style, palette, composition, and subject. Record the returned description in `{output-dir}/references/NN-ref-{slug}.md` via `Write`.
+2. **Do not** try to copy the binary via `Write` / `Read` — those are text-only. If you want a local copy for the record, use `Bash` (`cp "$src" "{output-dir}/references/NN-ref-{slug}.{ext}"`). The skill itself never needs to read the binary; it works off the vision description.
 3. Since `image_generate` doesn't take image inputs, the vision description is what gets embedded in prompts during Step 5.
 
 Full procedures: [references/workflow.md](references/workflow.md#step-1-detect-reference-images).
@@ -101,7 +101,7 @@ Full procedures: [references/workflow.md](references/workflow.md#step-1-detect-r
 | Core arguments | 2-5 main points |
 | Positions | Where illustrations add value |
 
-Read source (file path → `read_file`, or pasted text) and write the analysis to `{output-dir}/analysis.md` using `write_file`.
+Read source (file path → `Read`, or pasted text) and write the analysis to `{output-dir}/analysis.md` using `Write`.
 
 Full procedures: [references/workflow.md](references/workflow.md#step-2-analyze).
 
@@ -123,7 +123,7 @@ Full procedures: [references/workflow.md](references/workflow.md#step-3-confirm-
 
 ### Step 4: Generate Outline → `outline.md`
 
-Save `{output-dir}/outline.md` using `write_file` with frontmatter (type, density, style, palette, image_count) and one entry per illustration:
+Save `{output-dir}/outline.md` using `Write` with frontmatter (type, density, style, palette, image_count) and one entry per illustration:
 
 ```yaml
 ## Illustration 1
@@ -142,7 +142,7 @@ Full template: [references/workflow.md](references/workflow.md#step-4-generate-o
 For each illustration:
 
 1. Create a prompt file per [references/prompt-construction.md](references/prompt-construction.md).
-2. Save to `{output-dir}/prompts/NN-{type}-{slug}.md` using `write_file` with YAML frontmatter.
+2. Save to `{output-dir}/prompts/NN-{type}-{slug}.md` using `Write` with YAML frontmatter.
 3. Prompts MUST use type-specific templates with structured sections (ZONES / LABELS / COLORS / STYLE / ASPECT).
 4. LABELS MUST include article-specific data: actual numbers, terms, metrics, quotes.
 5. Process references (`direct`/`style`/`palette`) per prompt frontmatter — for `direct` usage, embed a textual description of the reference in the prompt (since `image_generate` doesn't take reference-image inputs).
@@ -153,7 +153,7 @@ For each prompt file:
 
 1. Call `image_generate(prompt=..., aspect_ratio=...)`. `image_generate` returns a JSON result containing an image URL; it does NOT write to disk and does NOT accept an output path.
 2. Map the prompt's `ASPECT` to `image_generate`'s enum: `16:9` → `landscape`, `9:16` → `portrait`, `1:1` → `square`. Custom ratios → nearest named aspect.
-3. Download the returned URL to `{output-dir}/NN-{type}-{slug}.png` via `terminal` (e.g. `curl -sSL -o "{output-dir}/NN-{type}-{slug}.png" "{url}"`).
+3. Download the returned URL to `{output-dir}/NN-{type}-{slug}.png` via `Bash` (e.g. `curl -sSL -o "{output-dir}/NN-{type}-{slug}.png" "{url}"`).
 4. On generation failure, auto-retry once.
 
 Note: the underlying image-generation backend is user-configured (default: FAL FLUX 2 Klein 9B) and is NOT agent-selectable via `image_generate`. Do not write model names into prompts expecting them to route.
@@ -195,5 +195,5 @@ Images: X/N generated
 3. **Don't illustrate metaphors literally** — visualize the underlying concept.
 4. **Prompt files are mandatory** — no image generation without a saved prompt file. The file is what lets you regenerate or switch backends later.
 5. **`image_generate` aspect ratios** — the tool supports `landscape`, `portrait`, and `square`. Custom ratios map to the nearest option.
-6. **`image_generate` returns a URL, not a local file** — always download via `terminal` (`curl`) before inserting local image paths into the article.
+6. **`image_generate` returns a URL, not a local file** — always download via `Bash` (`curl`) before inserting local image paths into the article.
 7. **No backend selection from the agent** — `image_generate` uses whatever model the user configured (default: FAL FLUX 2 Klein 9B). Don't write `"use <model> to generate this"` into prompts expecting it to route.

package/.agent/skills/arxiv/SKILL.md

@@ -14,8 +14,8 @@ Search and retrieve academic papers from arXiv via their free REST API. No API k
 |--------|---------|
 | Search papers | `curl "https://export.arxiv.org/api/query?search_query=all:QUERY&max_results=5"` |
 | Get specific paper | `curl "https://export.arxiv.org/api/query?id_list=2402.03300"` |
-| Read abstract (web) | `web_extract(urls=["https://arxiv.org/abs/2402.03300"])` |
-| Read full paper (PDF) | `web_extract(urls=["https://arxiv.org/pdf/2402.03300"])` |
+| Read abstract (web) | `WebFetch(urls=["https://arxiv.org/abs/2402.03300"])` |
+| Read full paper (PDF) | `WebFetch(urls=["https://arxiv.org/pdf/2402.03300"])` |
 
 ## Searching Papers
 
@@ -142,10 +142,10 @@ After finding a paper, read it:
 
 ```
 # Abstract page (fast, metadata + abstract)
-web_extract(urls=["https://arxiv.org/abs/2402.03300"])
+WebFetch(urls=["https://arxiv.org/abs/2402.03300"])
 
 # Full paper (PDF → markdown via Firecrawl)
-web_extract(urls=["https://arxiv.org/pdf/2402.03300"])
+WebFetch(urls=["https://arxiv.org/pdf/2402.03300"])
 ```
 
 For local PDF processing, see the `ocr-and-documents` skill.
@@ -238,8 +238,8 @@ curl -s "https://api.semanticscholar.org/graph/v1/author/search?query=Yann+LeCun
 
 1. **Discover**: `python scripts/search_arxiv.py "your topic" --sort date --max 10`
 2. **Assess impact**: `curl -s "https://api.semanticscholar.org/graph/v1/paper/arXiv:ID?fields=citationCount,influentialCitationCount"`
-3. **Read abstract**: `web_extract(urls=["https://arxiv.org/abs/ID"])`
-4. **Read full paper**: `web_extract(urls=["https://arxiv.org/pdf/ID"])`
+3. **Read abstract**: `WebFetch(urls=["https://arxiv.org/abs/ID"])`
+4. **Read full paper**: `WebFetch(urls=["https://arxiv.org/pdf/ID"])`
 5. **Find related work**: `curl -s "https://api.semanticscholar.org/graph/v1/paper/arXiv:ID/references?fields=title,citationCount&limit=20"`
 6. **Get recommendations**: POST to Semantic Scholar recommendations endpoint
 7. **Track authors**: `curl -s "https://api.semanticscholar.org/graph/v1/author/search?query=NAME"`

package/.agent/skills/code-wiki/SKILL.md

@@ -6,7 +6,7 @@ version: 0.1.0
 
 # Code Wiki Skill
 
-Generate a comprehensive wiki for any codebase — overview, architecture, per-module deep-dives, Mermaid class and sequence diagrams. Inspired by Google CodeWiki, but works on local repos, private repos, and any language. Uses only existing tools (`terminal`, `read_file`, `search_files`, `write_file`); no Docker, no external services, no extra dependencies.
+Generate a comprehensive wiki for any codebase — overview, architecture, per-module deep-dives, Mermaid class and sequence diagrams. Inspired by Google CodeWiki, but works on local repos, private repos, and any language. Uses only existing tools (`Bash`, `Read`, `Grep`, `Write`); no Docker, no external services, no extra dependencies.
 
 This skill produces **reference documentation** (what/how). It does not produce strategic narrative (why — that's a different skill).
 
@@ -19,7 +19,7 @@ This skill produces **reference documentation** (what/how). It does not produce
 
 Do NOT use this for:
 - Single-file or single-function documentation — just answer directly
-- API reference for one specific endpoint — use `read_file` and answer inline
+- API reference for one specific endpoint — use `Read` and answer inline
 - Strategic "why does this exist" narrative — different skill, different purpose
 - Codebases the user is actively developing in this session — just answer questions as they come
 
@@ -31,7 +31,7 @@ Do NOT use this for:
 
 ## How to Run
 
-Invoke through the `terminal` tool from the target repo's root, then use `read_file` / `search_files` / `write_file` to produce the wiki. Default output location is `~/.agent/wikis/<repo-name>/`. Only write into the repo (`docs/wiki/`) when the user explicitly requests it.
+Invoke through the `Bash` tool from the target repo's root, then use `Read` / `Grep` / `Write` to produce the wiki. Default output location is `~/.agent/wikis/<repo-name>/`. Only write into the repo (`docs/wiki/`) when the user explicitly requests it.
 
 ## Quick Reference
 
@@ -75,13 +75,13 @@ REPO_NAME=$(basename "$PWD")
 Then set the output dir:
 
 ```bash
-OUTPUT_DIR="$HOME/.hermes/wikis/$REPO_NAME"
+OUTPUT_DIR="$HOME/.mindforge/wikis/$REPO_NAME"
 mkdir -p "$OUTPUT_DIR/modules" "$OUTPUT_DIR/diagrams"
 ```
 
 ### 2. Scan repo structure
 
-Use the `terminal` tool for the shell work, `read_file` for manifests:
+Use the `Bash` tool for the shell work, `Read` for manifests:
 
 ```bash
 # Shallow tree first
@@ -104,7 +104,7 @@ pygount --format=summary \
   . 2>/dev/null || true
 ```
 
-Then `read_file` the relevant manifests (`package.json`, `pyproject.toml`, `setup.py`, `Cargo.toml`, `go.mod`, `pom.xml`, `build.gradle`) and the project README. Use `search_files target='files'` to find them rather than guessing names.
+Then `Read` the relevant manifests (`package.json`, `pyproject.toml`, `setup.py`, `Cargo.toml`, `go.mod`, `pom.xml`, `build.gradle`) and the project README. Use `search_files target='files'` to find them rather than guessing names.
 
 ### 3. Pick modules to document
 
@@ -125,7 +125,7 @@ State the module list to the user before generating per-module docs on big repos
 
 ### 4. Write `README.md`
 
-`read_file` the actual project README plus the top 2–3 entry-point files. Then `write_file`:
+`Read` the actual project README plus the top 2–3 entry-point files. Then `Write`:
 
 ````markdown
 # <Project Name>
@@ -205,7 +205,7 @@ Cap at ~20 nodes per diagram. Split into sub-diagrams if larger.
 
 ### 6. Write per-module docs in `modules/`
 
-For each selected module, inspect its layout with `ls`, identify 3–5 most important files (by size, by being named `core.py` / `main.py` / `__init__.py`, by being imported a lot), then `read_file` those files (use `offset` / `limit` to read only what you need; prefer `search_files` for specific symbols).
+For each selected module, inspect its layout with `ls`, identify 3–5 most important files (by size, by being named `core.py` / `main.py` / `__init__.py`, by being imported a lot), then `Read` those files (use `offset` / `limit` to read only what you need; prefer `Grep` for specific symbols).
 
 ````markdown
 # Module: `<module>`
@@ -242,7 +242,7 @@ signatures, not full implementations.>
 
 ### 7. Write `diagrams/class-diagram.md`
 
-Pick the 5–10 most important classes/types. `read_file` them, then write:
+Pick the 5–10 most important classes/types. `Read` them, then write:
 
 ````markdown
 # Class Diagram
@@ -389,7 +389,7 @@ Generating a full wiki for a 500K-LOC monorepo is wildly token-expensive. Defaul
 
 - Initial scan: max depth 3 directories
 - Per-module docs: cap at 10 modules unless user expands scope
-- Per-file reads: prefer `search_files` for symbols + `read_file` with `offset`/`limit` over full reads
+- Per-file reads: prefer `Grep` for symbols + `Read` with `offset`/`limit` over full reads
 - Skip vendored code (`vendor/`, `third_party/`, generated code, `_pb2.py`, `.min.js`)
 
 If the user says "do the whole thing exhaustively", believe them — but ballpark the cost first: "this repo has ~340 source files, comprehensive coverage will be expensive — confirm?"
@@ -406,7 +406,7 @@ Full incremental-regeneration is a future enhancement — for now, regenerating
 
 ## Pitfalls
 
-- **Fabricating components.** Every diagram node and claimed function call must be in the source. `read_file` before writing. The single biggest failure mode for auto-generated docs is plausible-sounding fabrication.
+- **Fabricating components.** Every diagram node and claimed function call must be in the source. `Read` before writing. The single biggest failure mode for auto-generated docs is plausible-sounding fabrication.
 - **Generic AI prose.** "This module is responsible for..." is content-free. Say what the module actually does in domain-specific terms.
 - **Restating code as prose.** A module doc that says "the `process` function processes things by calling `process_item` on each item" is worse than just linking to the function.
 - **Mermaid > 50 nodes.** They don't render legibly. Split them.

package/.agent/skills/concept-diagrams/SKILL.md

@@ -38,9 +38,9 @@ If a more specialized skill is available for the subject, prefer that. If none f
 
 Optional: if the user wants a browsable gallery of multiple diagrams, see "Local Preview Server" at the bottom.
 
-Load the HTML template:
+Load the HTML template with `Read` (path relative to this skill's own directory):
 ```
-skill_view(name="concept-diagrams", file_path="templates/template.html")
+Read(".agent/skills/concept-diagrams/templates/template.html")
 ```
 
 The template embeds the full CSS design system (`c-*` color classes, text classes, light/dark variables, arrow marker styles). The SVG you generate relies on these classes being present on the hosting page.
@@ -252,7 +252,7 @@ Write a single `.html` file the user can open directly. No server, no dependenci
 
 ```python
 # 1. Load the template
-template = skill_view("concept-diagrams", "templates/template.html")
+template = Read(".agent/skills/concept-diagrams/templates/template.html")
 
 # 2. Fill in title, subtitle, and paste your SVG
 html = template.replace(
@@ -264,7 +264,7 @@ html = template.replace(
 )
 
 # 3. Write to a user-chosen path (or ./ by default)
-write_file("./sn2-mechanism.html", html)
+Write("./sn2-mechanism.html", html)
 ```
 
 Tell the user how to open it:
@@ -327,9 +327,9 @@ The `examples/` directory ships 15 complete, tested diagrams. Browse them for wo
 | `electricity-grid-flow.md` | Multi-stage flow | Voltage hierarchy, flow markers |
 | `ml-benchmark-grouped-bar-chart.md` | Chart | Grouped bars, dual axis |
 
-Load any example with:
+Load any example with `Read`:
 ```
-skill_view(name="concept-diagrams", file_path="examples/<filename>")
+Read(".agent/skills/concept-diagrams/examples/<filename>")
 ```
 
 ---

package/.agent/skills/concept-diagrams/examples/apartment-floor-plan-conversion.md

@@ -0,0 +1,244 @@
+# Apartment Floor Plan: 3 BHK to 4 BHK Conversion
+
+An architectural floor plan showing a 1,500 sq ft apartment with proposed modifications to convert from 3 BHK to 4 BHK. Demonstrates architectural drawing conventions, room layouts, proposed changes with dotted lines, and area comparison tables.
+
+## Key Patterns Used
+
+- **Architectural floor plan**: Top-down view with walls, doors, windows
+- **Proposed modifications**: Dotted red lines for new walls
+- **Room color coding**: Light fills to distinguish room types
+- **Circulation paths**: Arrows showing new access routes
+- **Data table**: Before/after area comparison with highlighting
+- **Architectural symbols**: North arrow, scale bar, door swings
+
+## Diagram Type
+
+This is an **architectural floor plan** with:
+- **Plan view**: Top-down orthographic projection
+- **Overlay technique**: Existing structure + proposed changes
+- **Quantitative data**: Area measurements and comparison table
+
+## Architectural Drawing Elements
+
+### Wall Styles
+
+```xml
+<!-- Outer walls (thick) -->
+<line class="wall" x1="0" y1="0" x2="560" y2="0"/>
+
+<!-- Internal walls (thinner) -->
+<line class="wall-thin" x1="180" y1="0" x2="180" y2="140"/>
+
+<!-- Proposed new walls (dotted red) -->
+<line class="proposed-wall" x1="125" y1="170" x2="125" y2="330"/>
+```
+
+```css
+.wall { stroke: var(--text-primary); stroke-width: 6; fill: none; stroke-linecap: square; }
+.wall-thin { stroke: var(--text-primary); stroke-width: 3; fill: none; }
+.proposed-wall { stroke: #A32D2D; stroke-width: 4; fill: none; stroke-dasharray: 8 4; }
+```
+
+### Door Symbols
+
+```xml
+<!-- Door opening with swing arc -->
+<rect x="150" y="137" width="25" height="6" fill="var(--bg-primary)"/>
+<path class="door" d="M150,140 L150,165"/>
+<path class="door-swing" d="M150,140 A25,25 0 0,0 175,140"/>
+
+<!-- Sliding door (balcony) -->
+<rect x="60" y="327" width="60" height="6" fill="var(--bg-primary)" stroke="var(--text-secondary)" stroke-width="1"/>
+<line x1="60" y1="330" x2="90" y2="330" stroke="var(--text-secondary)" stroke-width="2"/>
+<line x1="90" y1="330" x2="120" y2="330" stroke="var(--text-secondary)" stroke-width="2" stroke-dasharray="3 3"/>
+
+<!-- Proposed door (dotted) -->
+<rect x="143" y="292" width="22" height="6" fill="var(--bg-primary)" stroke="#A32D2D" stroke-width="1" stroke-dasharray="3 2"/>
+<path d="M165,295 A22,22 0 0,0 165,273" stroke="#A32D2D" stroke-width="1" stroke-dasharray="3 2" fill="none"/>
+```
+
+```css
+.door { stroke: var(--text-secondary); stroke-width: 1.5; fill: none; }
+.door-swing { stroke: var(--text-tertiary); stroke-width: 1; fill: none; stroke-dasharray: 3 2; }
+```
+
+### Window Symbols
+
+```xml
+<!-- Window with glass indication -->
+<rect class="window" x="-3" y="30" width="6" height="50"/>
+<line class="window-glass" x1="0" y1="35" x2="0" y2="75"/>
+
+<!-- Horizontal window (top wall) -->
+<rect class="window" x="220" y="-3" width="60" height="6"/>
+<line class="window-glass" x1="225" y1="0" x2="275" y2="0"/>
+```
+
+```css
+.window { stroke: var(--text-primary); stroke-width: 1; fill: var(--bg-primary); }
+.window-glass { stroke: #378ADD; stroke-width: 2; fill: none; }
+```
+
+### Room Fills
+
+```xml
+<!-- Different colors for room types -->
+<rect class="room-master" x="3" y="3" width="174" height="134" rx="2"/>
+<rect class="room-bed2" x="183" y="3" width="134" height="104" rx="2"/>
+<rect class="room-living" x="3" y="173" width="554" height="154" rx="2"/>
+<rect class="room-kitchen" x="443" y="3" width="114" height="104" rx="2"/>
+<rect class="room-bath" x="183" y="113" width="54" height="54" rx="2"/>
+
+<!-- Proposed new room (highlighted) -->
+<rect class="room-new" x="3" y="223" width="120" height="104"/>
+```
+
+```css
+.room-master { fill: rgba(206, 203, 246, 0.3); }  /* purple tint */
+.room-bed2 { fill: rgba(159, 225, 203, 0.3); }    /* teal tint */
+.room-bed3 { fill: rgba(250, 199, 117, 0.3); }    /* amber tint */
+.room-living { fill: rgba(245, 196, 179, 0.3); }  /* coral tint */
+.room-kitchen { fill: rgba(237, 147, 177, 0.3); } /* pink tint */
+.room-bath { fill: rgba(133, 183, 235, 0.3); }    /* blue tint */
+.room-new { fill: rgba(163, 45, 45, 0.15); }      /* red tint for proposed */
+```
+
+### Support Fixtures
+
+```xml
+<!-- Kitchen counter hint -->
+<rect x="450" y="15" width="50" height="25" fill="none" stroke="var(--text-tertiary)" stroke-width="0.5" rx="2"/>
+<text class="tx" x="475" y="30" text-anchor="middle">Counter</text>
+
+<!-- Balcony (dashed outline) -->
+<rect class="balcony-fill" x="3" y="333" width="200" height="50"/>
+```
+
+```css
+.balcony { fill: none; stroke: var(--text-secondary); stroke-width: 2; stroke-dasharray: 6 3; }
+.balcony-fill { fill: rgba(93, 202, 165, 0.1); }
+```
+
+### Room Labels
+
+```xml
+<!-- Room name and area -->
+<text class="room-label" x="90" y="65" text-anchor="middle">MASTER</text>
+<text class="room-label" x="90" y="78" text-anchor="middle">BEDROOM</text>
+<text class="area-label" x="90" y="95" text-anchor="middle">195 sq ft</text>
+
+<!-- Proposed room (in red) -->
+<text class="room-label" x="63" y="268" text-anchor="middle" fill="#A32D2D">BEDROOM 4</text>
+<text class="tx" x="63" y="282" text-anchor="middle" fill="#A32D2D">(NEW)</text>
+```
+
+```css
+.room-label { font-family: system-ui; font-size: 11px; fill: var(--text-primary); font-weight: 500; }
+.area-label { font-family: system-ui; font-size: 9px; fill: var(--text-tertiary); }
+```
+
+### Circulation Arrow
+
+```xml
+<defs>
+  <marker id="circ-arrow" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto">
+    <path d="M0,0 L10,5 L0,10 Z" class="circulation-fill"/>
+  </marker>
+</defs>
+
+<path class="circulation" d="M300,250 L200,250 L145,250 L145,280" marker-end="url(#circ-arrow)"/>
+<text class="tx" x="250" y="242" fill="#3B6D11" font-weight="500">New corridor access</text>
+```
+
+```css
+.circulation { stroke: #3B6D11; stroke-width: 2; fill: none; }
+.circulation-fill { fill: #3B6D11; }
+```
+
+### North Arrow and Scale Bar
+
+```xml
+<!-- North arrow -->
+<g transform="translate(520, 260)">
+  <circle cx="0" cy="0" r="20" fill="none" stroke="var(--text-tertiary)" stroke-width="0.5"/>
+  <polygon points="0,-18 -5,5 0,0 5,5" fill="var(--text-primary)"/>
+  <text class="tx" x="0" y="-22" text-anchor="middle">N</text>
+</g>
+
+<!-- Scale bar -->
+<g transform="translate(420, 300)">
+  <line x1="0" y1="0" x2="100" y2="0" stroke="var(--text-primary)" stroke-width="2"/>
+  <line x1="0" y1="-5" x2="0" y2="5" stroke="var(--text-primary)" stroke-width="1"/>
+  <line x1="50" y1="-3" x2="50" y2="3" stroke="var(--text-primary)" stroke-width="1"/>
+  <line x1="100" y1="-5" x2="100" y2="5" stroke="var(--text-primary)" stroke-width="1"/>
+  <text class="tx" x="0" y="15" text-anchor="middle">0</text>
+  <text class="tx" x="50" y="15" text-anchor="middle">5'</text>
+  <text class="tx" x="100" y="15" text-anchor="middle">10'</text>
+</g>
+```
+
+## Area Comparison Table
+
+### Table Structure
+
+```xml
+<!-- Header row -->
+<rect class="table-header" x="0" y="0" width="180" height="28" rx="4 4 0 0"/>
+<text class="ts" x="90" y="18" text-anchor="middle" font-weight="500">Room</text>
+
+<!-- Normal row -->
+<rect class="table-row" x="0" y="28" width="180" height="24"/>
+<text class="tx" x="10" y="44">Master Bedroom</text>
+<text class="tx" x="230" y="44" text-anchor="middle">195</text>
+
+<!-- Alternating row -->
+<rect class="table-row-alt" x="0" y="52" width="180" height="24"/>
+
+<!-- Highlighted row (for changes) -->
+<rect class="table-highlight" x="0" y="100" width="180" height="24"/>
+<text class="tx" x="10" y="116" fill="#A32D2D" font-weight="500">Bedroom 4 (NEW)</text>
+<text class="tx" x="430" y="116" text-anchor="middle" fill="#3B6D11">+100</text>
+
+<!-- Total row -->
+<rect x="0" y="268" width="180" height="28" fill="var(--bg-secondary)" stroke="var(--border)" stroke-width="1"/>
+<text class="ts" x="10" y="286" font-weight="500">TOTAL CARPET AREA</text>
+```
+
+```css
+.table-header { fill: var(--bg-secondary); }
+.table-row { fill: var(--bg-primary); stroke: var(--border); stroke-width: 0.5; }
+.table-row-alt { fill: var(--bg-tertiary); stroke: var(--border); stroke-width: 0.5; }
+.table-highlight { fill: rgba(163, 45, 45, 0.1); stroke: #A32D2D; stroke-width: 0.5; }
+```
+
+## Layout Notes
+
+- **ViewBox**: 800×780 (portrait for floor plan + table)
+- **Scale**: 10px = 1 foot (apartment ~50ft × 33ft)
+- **Floor plan origin**: Offset at (50, 60) for margins
+- **Wall thickness**: 6px outer, 3px inner (represents ~6" walls)
+- **Room labels**: Centered in each room with area below
+- **Table placement**: Below floor plan with full width
+
+## Color Coding
+
+| Element | Color | Usage |
+|---------|-------|-------|
+| Proposed walls | Red (#A32D2D) dotted | New construction |
+| New room fill | Red 15% opacity | Bedroom 4 area |
+| Circulation | Green (#3B6D11) | New access path |
+| Window glass | Blue (#378ADD) | Glass indication |
+| Bedrooms | Purple/Teal/Amber tints | Room differentiation |
+| Wet areas | Blue tint | Bathrooms |
+| Living | Coral tint | Common areas |
+
+## When to Use This Pattern
+
+Use this diagram style for:
+- Apartment/house floor plans
+- Office layout planning
+- Renovation proposals showing before/after
+- Space planning with area calculations
+- Real estate marketing materials
+- Interior design presentations
+- Building permit documentation