robot_lab 0.2.8 → 0.3.1

data/examples/15_memory_network_and_bus/output/final_article.md

@@ -1,13 +0,0 @@
-# Final Article — APPROVED
-
-For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on budget, tolerance for system maintenance, and—most important—the workload. Local inference, quantized experimentation, LoRA-style fine-tuning, and full-scale multi-GPU training place very different demands on a machine. Each platform has real strengths. macOS offers a polished, low-friction experience on Apple Silicon, with excellent power efficiency and increasingly capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style AI development. Linux, meanwhile, remains the closest match to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-style workflows. BSD is more niche, but still relevant for users who value storage integrity and system control.
-
-Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually deliver the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home fine-tuning and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU setups. macOS is less modular and often more expensive upfront, but Apple Silicon offers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the heat, noise, and power draw of a traditional tower.
-
-The software stack is where Linux keeps its advantage. Most modern machine-learning infrastructure is developed and deployed with Linux as the default target, so CUDA, PyTorch, DeepSpeed, vLLM, Docker, and many research repositories are typically best supported there. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends. TensorFlow support is more uneven than it once was in native Windows setups, however, and many users now rely on WSL2 for a more current Linux-compatible path. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but Apple Silicon does not offer NVIDIA/CUDA-class upgradeability or equally broad support for large-scale training stacks.
-
-Ease of use depends on what kind of friction matters most. macOS is arguably the easiest platform to live with day to day: its Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project of its own. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, productivity, and media-heavy desktop applications; broad driver support and a vast library of community tutorials are significant advantages. Linux demands more initiative up front, but rewards that effort with stronger reproducibility, better remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better understood as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
-
-The practical recommendation depends on what “home AI lab” means in your case. If your workload is primarily local inference, evaluation, scripting, and moderate fine-tuning, macOS is an excellent fit. If you want a single versatile workstation for image generation, local model serving, and NVIDIA-accelerated experimentation—with access to Linux tooling when needed—Windows is highly compelling. If your priority is full training compatibility, containerized workflows, remote operation, or a setup that mirrors production and rented GPU environments, Linux is the strongest foundation.
-
-For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are built and run. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single all-purpose workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over maximum training flexibility. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.

data/examples/15_memory_network_and_bus/output/linux_draft.md

@@ -1,7 +0,0 @@
-# linux_writer Draft
-
-If you’re building a home AI research lab for LLM fine-tuning, image generation, and local inference, Linux/BSD is the best foundation because it gives you full control of the hardware and software stack in a way consumer desktop OSes simply don’t. On Ubuntu/Debian, that means straightforward NVIDIA CUDA installation, broad compatibility with PyTorch, TensorFlow, JAX, Hugging Face Transformers, bitsandbytes, vLLM, Ollama, and Stable Diffusion toolchains like AUTOMATIC1111, ComfyUI, and InvokeAI. Fedora/RHEL brings the same AI-ready strengths with newer kernels, strong NVIDIA and AMD support, and excellent container workflows through Podman and Docker-compatible tooling, plus SELinux for safer multi-service setups. And if your lab values long-term predictability and data integrity, FreeBSD is compelling for its ZFS snapshots, lightweight jails, and bhyve virtualization—especially for storing large model checkpoints, datasets, and reproducible experiment environments.
-
-Performance and workflow are where Linux/BSD really pull ahead. AI researchers want server-parity: the same CUDA libraries, Python environments, container images, SSH workflows, and orchestration patterns they’ll use on rented GPUs or lab servers. Linux is the default target for most ML infrastructure, so fine-tuning with PyTorch + DeepSpeed, FSDP, PEFT/LoRA, Axolotl, llama.cpp, or text-generation-webui generally works first and best there. ROCm support for AMD is also primarily Linux-first. Developer tooling is mature and frictionless: apt, dnf, pip, conda, uv, poetry, tmux, systemd, Podman/Docker, NVIDIA Container Toolkit, and VS Code Remote SSH all fit naturally into a research workflow. That makes it easy to run one box as a local inference host, another as a training node, and package both with containers for repeatable deployments.
-
-Just as important, Linux/BSD gives you massive community support and a free, open ecosystem that rewards experimentation instead of fighting it. If you hit a CUDA mismatch, need a custom kernel module, want to pin an older Python for a model repo, or need community-tested guides for QLoRA fine-tuning on an RTX 4090, the answer is almost always documented somewhere for Ubuntu, Debian, Fedora, or another major distro. That depth of packages, tutorials, and forum knowledge matters when you’re juggling GPU drivers, model servers, vector databases, and web UIs at home. In practical terms: Linux is the native habitat of AI/ML tooling, Fedora/RHEL offers a modern and enterprise-grade path, Ubuntu/Debian maximize ease and compatibility, and FreeBSD adds unmatched storage discipline and clean isolation. For a serious home AI lab, Linux/BSD isn’t just a good choice—it’s the platform that most directly aligns with how modern AI systems are actually built and run.

data/examples/15_memory_network_and_bus/output/mac_draft.md

@@ -1,7 +0,0 @@
-# mac_writer Draft
-
-macOS is a remarkably strong choice for a home AI research lab, especially if your work centers on LLM fine-tuning, image generation, and local inference. On Apple Silicon, you get an unusually compelling mix of CPU, GPU, and unified memory in one quiet, power-efficient system. That matters in real workflows: local inference with tools like Ollama, LM Studio, and llama.cpp runs smoothly on M-series Macs, while PyTorch has native Metal Performance Shaders support so models can use the integrated GPU without needing a discrete NVIDIA card. For image generation, projects such as Stable Diffusion, ComfyUI, and AUTOMATIC1111 can run effectively on macOS, and Apple’s unified memory architecture is especially useful when working with larger models or batching workflows that would otherwise be constrained by separate VRAM limits.
-
-The software ecosystem is another major advantage. macOS gives you a Unix foundation with first-class terminal tooling, Homebrew for package management, and easy access to Python, Conda, Docker alternatives, Git, SSH, tmux, and Jupyter-based workflows. For AI development specifically, you can work with PyTorch on Metal, TensorFlow with Apple’s ML extensions, Hugging Face Transformers, llama.cpp, ONNX Runtime, MLX, and Core ML. Apple’s MLX framework is particularly exciting for home researchers because it is built for Apple Silicon and makes training and inference on local hardware feel much more natural. Core ML also gives you a path to highly optimized deployment for local apps and edge-style workflows, which is useful if your lab includes benchmarking, model packaging, or building inference tools for personal use.
-
-What makes macOS arguably the best home-lab platform is how well the whole stack fits together. Hardware compatibility is simple because Apple controls the platform end to end; you are not spending weekends debugging GPU drivers, CUDA mismatches, or power and cooling issues. An M2 Max, M3 Pro, or higher-end M-series system can serve as a capable always-on research workstation that handles experimentation, scripting, quantized fine-tuning, evaluation, and media generation while drawing far less power than a traditional multi-GPU tower. Add in strong developer tooling like Xcode, VS Code, iTerm2, and excellent community support around Apple Silicon optimization, and you get a platform that is stable, efficient, and genuinely productive. If you want a home AI lab that prioritizes practical local experimentation over endless infrastructure maintenance, macOS is hard to beat.

data/examples/15_memory_network_and_bus/output/memory.json

@@ -1,13 +0,0 @@
-{
-  "data": {},
-  "results": [],
-  "messages": [],
-  "custom": {
-    "ubuntu_specialist": "Ubuntu/Debian is a strong choice for a home AI research lab because it offers excellent hardware and driver support, especially for NVIDIA CUDA setups, while keeping software installation straightforward through the apt ecosystem. It’s also stable, well-documented, and widely used in research and server environments, which makes troubleshooting, automation, and reproducing experiments much easier.",
-    "windows_draft": "Windows is the strongest all-around choice for a home AI research lab because it gives you the best combination of raw GPU support, hardware flexibility, and practical developer workflow. For LLM fine-tuning, image generation, and local inference, NVIDIA CUDA support on Windows is first-class: PyTorch, TensorFlow, xFormers, bitsandbytes, TensorRT, ONNX Runtime, and popular tools like Ollama, LM Studio, ComfyUI, AUTOMATIC1111, and Stable Diffusion WebUI all have strong Windows paths. If you want the highest-performance consumer GPUs for AI work, Windows pairs especially well with NVIDIA RTX hardware, from a single 4070 Ti Super up to multi-GPU prosumer setups. And if you need Linux-native scripts or package workflows, WSL2 gives you a near-seamless Ubuntu environment on the same machine, so you can run Hugging Face Transformers, PEFT, DeepSpeed, vLLM, llama.cpp, JupyterLab, and CUDA-enabled Linux tooling without giving up native Windows apps.\n\nWindows also wins on hardware compatibility and ecosystem breadth. A home lab often mixes gaming-class GPUs, high-core-count CPUs, fast NVMe storage, USB devices, capture cards, and sometimes unusual motherboard or networking gear; Windows consistently offers the widest driver support and easiest setup across that mix. Beyond CUDA, Windows also supports DirectML, which broadens acceleration options on AMD and Intel hardware for local inference and experimentation. On the tooling side, it integrates cleanly with Visual Studio Code, Visual Studio, Docker Desktop, PowerShell, Windows Terminal, Git for Windows, and enterprise-friendly tools for remote access, file sharing, backup, and virtualization. In practice, that means you can fine-tune a LoRA in WSL2, monitor GPUs with native Windows utilities, manage datasets on NTFS storage, launch ComfyUI or LM Studio from the desktop, and still have access to familiar scripting and automation.\n\nJust as important, Windows has massive community support for home AI builders. Most consumer AI guides now assume either native Windows or Windows plus WSL2, especially for Stable Diffusion workflows, local LLM front ends, and single-node fine-tuning recipes. Troubleshooting is easier when there are abundant guides for CUDA driver versions, PyTorch wheels, Flash Attention builds, and model-serving stacks on common RTX cards. For someone building a serious home AI lab, Windows offers the most practical balance: top-tier NVIDIA performance, Linux compatibility when you need it, broad hardware support, and a mature tool ecosystem that scales from casual experimentation to disciplined research workflows.",
-    "mac_draft": "macOS is a remarkably strong choice for a home AI research lab, especially if your work centers on LLM fine-tuning, image generation, and local inference. On Apple Silicon, you get an unusually compelling mix of CPU, GPU, and unified memory in one quiet, power-efficient system. That matters in real workflows: local inference with tools like Ollama, LM Studio, and llama.cpp runs smoothly on M-series Macs, while PyTorch has native Metal Performance Shaders support so models can use the integrated GPU without needing a discrete NVIDIA card. For image generation, projects such as Stable Diffusion, ComfyUI, and AUTOMATIC1111 can run effectively on macOS, and Apple’s unified memory architecture is especially useful when working with larger models or batching workflows that would otherwise be constrained by separate VRAM limits.\n\nThe software ecosystem is another major advantage. macOS gives you a Unix foundation with first-class terminal tooling, Homebrew for package management, and easy access to Python, Conda, Docker alternatives, Git, SSH, tmux, and Jupyter-based workflows. For AI development specifically, you can work with PyTorch on Metal, TensorFlow with Apple’s ML extensions, Hugging Face Transformers, llama.cpp, ONNX Runtime, MLX, and Core ML. Apple’s MLX framework is particularly exciting for home researchers because it is built for Apple Silicon and makes training and inference on local hardware feel much more natural. Core ML also gives you a path to highly optimized deployment for local apps and edge-style workflows, which is useful if your lab includes benchmarking, model packaging, or building inference tools for personal use.\n\nWhat makes macOS arguably the best home-lab platform is how well the whole stack fits together. Hardware compatibility is simple because Apple controls the platform end to end; you are not spending weekends debugging GPU drivers, CUDA mismatches, or power and cooling issues. An M2 Max, M3 Pro, or higher-end M-series system can serve as a capable always-on research workstation that handles experimentation, scripting, quantized fine-tuning, evaluation, and media generation while drawing far less power than a traditional multi-GPU tower. Add in strong developer tooling like Xcode, VS Code, iTerm2, and excellent community support around Apple Silicon optimization, and you get a platform that is stable, efficient, and genuinely productive. If you want a home AI lab that prioritizes practical local experimentation over endless infrastructure maintenance, macOS is hard to beat.",
-    "fedora_specialist": "Fedora and RHEL are strong choices for a home AI research lab because they combine up-to-date kernels, excellent NVIDIA/AMD driver support, and robust container tooling like Podman, making it easy to run modern ML workloads reliably. They also offer strong SELinux security, reproducible enterprise-style workflows, and a clear path from experimentation on Fedora to long-term stability on RHEL-compatible systems.",
-    "freebsd_specialist": "FreeBSD is a strong choice for a home AI research lab because it offers excellent stability, predictable system behavior, and powerful storage features through ZFS, which is ideal for protecting large datasets and snapshots of experiment environments. Its lightweight jails and bhyve virtualization make it easy to isolate services and test setups efficiently, while the base system’s consistency helps reduce maintenance overhead for long-running workloads.",
-    "linux_draft": "If you’re building a home AI research lab for LLM fine-tuning, image generation, and local inference, Linux/BSD is the best foundation because it gives you full control of the hardware and software stack in a way consumer desktop OSes simply don’t. On Ubuntu/Debian, that means straightforward NVIDIA CUDA installation, broad compatibility with PyTorch, TensorFlow, JAX, Hugging Face Transformers, bitsandbytes, vLLM, Ollama, and Stable Diffusion toolchains like AUTOMATIC1111, ComfyUI, and InvokeAI. Fedora/RHEL brings the same AI-ready strengths with newer kernels, strong NVIDIA and AMD support, and excellent container workflows through Podman and Docker-compatible tooling, plus SELinux for safer multi-service setups. And if your lab values long-term predictability and data integrity, FreeBSD is compelling for its ZFS snapshots, lightweight jails, and bhyve virtualization—especially for storing large model checkpoints, datasets, and reproducible experiment environments.\n\nPerformance and workflow are where Linux/BSD really pull ahead. AI researchers want server-parity: the same CUDA libraries, Python environments, container images, SSH workflows, and orchestration patterns they’ll use on rented GPUs or lab servers. Linux is the default target for most ML infrastructure, so fine-tuning with PyTorch + DeepSpeed, FSDP, PEFT/LoRA, Axolotl, llama.cpp, or text-generation-webui generally works first and best there. ROCm support for AMD is also primarily Linux-first. Developer tooling is mature and frictionless: apt, dnf, pip, conda, uv, poetry, tmux, systemd, Podman/Docker, NVIDIA Container Toolkit, and VS Code Remote SSH all fit naturally into a research workflow. That makes it easy to run one box as a local inference host, another as a training node, and package both with containers for repeatable deployments.\n\nJust as important, Linux/BSD gives you massive community support and a free, open ecosystem that rewards experimentation instead of fighting it. If you hit a CUDA mismatch, need a custom kernel module, want to pin an older Python for a model repo, or need community-tested guides for QLoRA fine-tuning on an RTX 4090, the answer is almost always documented somewhere for Ubuntu, Debian, Fedora, or another major distro. That depth of packages, tutorials, and forum knowledge matters when you’re juggling GPU drivers, model servers, vector databases, and web UIs at home. In practical terms: Linux is the native habitat of AI/ML tooling, Fedora/RHEL offers a modern and enterprise-grade path, Ubuntu/Debian maximize ease and compatibility, and FreeBSD adds unmatched storage discipline and clean isolation. For a serious home AI lab, Linux/BSD isn’t just a good choice—it’s the platform that most directly aligns with how modern AI systems are actually built and run."
-  }
-}

data/examples/15_memory_network_and_bus/output/revision_1.md

@@ -1,18 +0,0 @@
-# Revision 1
-
-This is strong as written. Here’s a lightly tightened editorial version with a slightly smoother cadence and clearer conclusion:
-
-For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on your hardware budget, tolerance for system maintenance, and the kind of AI work you plan to do. Each platform has legitimate strengths. macOS offers a polished, low-friction experience on Apple Silicon, combining strong power efficiency with capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style development. Linux, meanwhile, remains the closest analogue to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-oriented tooling. BSD is more niche, but still relevant for users who care deeply about storage integrity and system control.
-
-Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually offer the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home training and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU configurations. macOS is less modular and often more expensive upfront, but Apple Silicon delivers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the noise, heat, and power demands of a traditional tower.
-
-The software stack is where Linux keeps its edge. It remains the default environment for much of modern machine-learning infrastructure: CUDA, PyTorch, JAX, DeepSpeed, vLLM, Docker, and countless research repositories tend to land there first. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, TensorFlow, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends, while WSL2 allows users to mix native desktop convenience with Linux workflows on the same machine. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but it still lacks the same universality for cutting-edge training stacks and does not offer a straightforward route to top-tier discrete-GPU performance.
-
-Ease of use depends on what kind of friction matters most to you. macOS is arguably the easiest platform to live with day to day: the Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project in itself. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, general productivity, and media-heavy desktop applications; its broad driver support and vast library of community tutorials are real advantages. Linux demands more initiative up front, but rewards that effort with better reproducibility, stronger remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better viewed as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
-
-The practical recommendation is straightforward, even if the answer is not one-size-fits-all. For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are developed and deployed. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single versatile workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over absolute training performance. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
-
-If you want, I can also:
-- make it more magazine-like and opinionated,
-- make it shorter and punchier,
-- or remove the final “Linux-first” tilt to make it even more neutral.

data/examples/15_memory_network_and_bus/output/revision_2.md

@@ -1,13 +0,0 @@
-# Revision 2
-
-For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on budget, tolerance for system maintenance, and—most important—the workload. Local inference, quantized experimentation, LoRA-style fine-tuning, and full-scale multi-GPU training place very different demands on a machine. Each platform has real strengths. macOS offers a polished, low-friction experience on Apple Silicon, with excellent power efficiency and increasingly capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style AI development. Linux, meanwhile, remains the closest match to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-style workflows. BSD is more niche, but still relevant for users who value storage integrity and system control.
-
-Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually deliver the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home fine-tuning and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU setups. macOS is less modular and often more expensive upfront, but Apple Silicon offers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the heat, noise, and power draw of a traditional tower.
-
-The software stack is where Linux keeps its advantage. Most modern machine-learning infrastructure is developed and deployed with Linux as the default target, so CUDA, PyTorch, DeepSpeed, vLLM, Docker, and many research repositories are typically best supported there. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends. TensorFlow support is more uneven than it once was in native Windows setups, however, and many users now rely on WSL2 for a more current Linux-compatible path. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but Apple Silicon does not offer NVIDIA/CUDA-class upgradeability or equally broad support for large-scale training stacks.
-
-Ease of use depends on what kind of friction matters most. macOS is arguably the easiest platform to live with day to day: its Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project of its own. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, productivity, and media-heavy desktop applications; broad driver support and a vast library of community tutorials are significant advantages. Linux demands more initiative up front, but rewards that effort with stronger reproducibility, better remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better understood as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
-
-The practical recommendation depends on what “home AI lab” means in your case. If your workload is primarily local inference, evaluation, scripting, and moderate fine-tuning, macOS is an excellent fit. If you want a single versatile workstation for image generation, local model serving, and NVIDIA-accelerated experimentation—with access to Linux tooling when needed—Windows is highly compelling. If your priority is full training compatibility, containerized workflows, remote operation, or a setup that mirrors production and rented GPU environments, Linux is the strongest foundation.
-
-For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are built and run. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single all-purpose workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over maximum training flexibility. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.

data/examples/15_memory_network_and_bus/output/windows_draft.md

@@ -1,7 +0,0 @@
-# win_writer Draft
-
-Windows is the strongest all-around choice for a home AI research lab because it gives you the best combination of raw GPU support, hardware flexibility, and practical developer workflow. For LLM fine-tuning, image generation, and local inference, NVIDIA CUDA support on Windows is first-class: PyTorch, TensorFlow, xFormers, bitsandbytes, TensorRT, ONNX Runtime, and popular tools like Ollama, LM Studio, ComfyUI, AUTOMATIC1111, and Stable Diffusion WebUI all have strong Windows paths. If you want the highest-performance consumer GPUs for AI work, Windows pairs especially well with NVIDIA RTX hardware, from a single 4070 Ti Super up to multi-GPU prosumer setups. And if you need Linux-native scripts or package workflows, WSL2 gives you a near-seamless Ubuntu environment on the same machine, so you can run Hugging Face Transformers, PEFT, DeepSpeed, vLLM, llama.cpp, JupyterLab, and CUDA-enabled Linux tooling without giving up native Windows apps.
-
-Windows also wins on hardware compatibility and ecosystem breadth. A home lab often mixes gaming-class GPUs, high-core-count CPUs, fast NVMe storage, USB devices, capture cards, and sometimes unusual motherboard or networking gear; Windows consistently offers the widest driver support and easiest setup across that mix. Beyond CUDA, Windows also supports DirectML, which broadens acceleration options on AMD and Intel hardware for local inference and experimentation. On the tooling side, it integrates cleanly with Visual Studio Code, Visual Studio, Docker Desktop, PowerShell, Windows Terminal, Git for Windows, and enterprise-friendly tools for remote access, file sharing, backup, and virtualization. In practice, that means you can fine-tune a LoRA in WSL2, monitor GPUs with native Windows utilities, manage datasets on NTFS storage, launch ComfyUI or LM Studio from the desktop, and still have access to familiar scripting and automation.
-
-Just as important, Windows has massive community support for home AI builders. Most consumer AI guides now assume either native Windows or Windows plus WSL2, especially for Stable Diffusion workflows, local LLM front ends, and single-node fine-tuning recipes. Troubleshooting is easier when there are abundant guides for CUDA driver versions, PyTorch wheels, Flash Attention builds, and model-serving stacks on common RTX cards. For someone building a serious home AI lab, Windows offers the most practical balance: top-tier NVIDIA performance, Linux compatibility when you need it, broad hardware support, and a mature tool ecosystem that scales from casual experimentation to disciplined research workflows.

data/examples/15_memory_network_and_bus/prompts/os_advocate.md

@@ -1,13 +0,0 @@
----
-description: OS advocate for home AI research labs
-parameters:
-  os_name: null
-  strengths: null
----
-You are a passionate advocate for <%= os_name %> as the ideal operating system for a home AI research lab.
-
-Key strengths to emphasize: <%= strengths %>
-
-Write a 2-3 paragraph advocacy piece arguing why <%= os_name %> is the best choice for someone building a home AI research lab. Cover hardware compatibility, software ecosystem, performance, and community support. Be specific about AI/ML frameworks, GPU support, and developer tooling.
-
-Be persuasive but factual. Use concrete examples of tools and workflows.

data/examples/15_memory_network_and_bus/prompts/os_chief.md

@@ -1,13 +0,0 @@
----
-description: Editor-in-chief who gives final approval on articles
----
-You are the editor-in-chief of a technology publication. Review the submitted article for:
-
-1. Balance — does it fairly represent all platforms?
-2. Accuracy — are technical claims correct?
-3. Recommendation quality — is the conclusion well-supported?
-4. Readability — is it clear and well-structured?
-
-If the article meets your standards, respond starting with APPROVED followed by a brief note on what makes it strong.
-
-If it needs work, respond starting with REVISE: followed by specific, actionable feedback on what to improve. Be concise.

data/examples/15_memory_network_and_bus/prompts/os_editor.md

@@ -1,13 +0,0 @@
----
-description: Editor who synthesizes OS advocacy drafts into a balanced article
----
-You are a senior technology editor specializing in AI infrastructure.
-
-You will receive three advocacy drafts arguing for different operating systems (macOS, Windows, Linux/BSD) for home AI research labs. Synthesize them into a balanced 4-6 paragraph article that:
-
-1. Acknowledges the strengths of each platform
-2. Compares them fairly across key dimensions (cost, GPU support, software ecosystem, ease of use)
-3. Identifies which scenarios favor which OS
-4. Ends with a clear, nuanced recommendation
-
-Write in a professional editorial voice. Be objective even though your sources are advocates.

data/examples/16_writers_room/.envrc

@@ -1 +0,0 @@
-export ROBOT_LAB_TEMPLATE_PATH="${PWD}/prompts"

data/examples/16_writers_room/display.rb

@@ -1,158 +0,0 @@
-# frozen_string_literal: true
-
-require "rainbow"
-require "io/console"
-
-# ── Display ─────────────────────────────────────────────────
-#
-# Terminal formatting for the Writers' Room demo.
-#
-#   - Broadcasts: white, prefixed with speaker name
-#   - Direct messages: magenta, shows sender → recipient
-#   - Memory writes: dimmed annotation
-#   - Spawns: green annotation
-#   - Completion: bright green
-#   - Chapter content: cyan (when assembled)
-#
-class Display
-  WRITER_COLORS = %i[cyan yellow blue magenta white].freeze
-
-  def initialize(log_path: nil)
-    @term_width = (IO.console&.winsize&.last || 80)
-    @wrap_width = @term_width - 8
-    @log_file = log_path ? File.open(log_path, "w") : nil
-    @color_map = {}
-    @next_color = 0
-  end
-
-  # ── Room Messages ──────────────────────────────────────────
-
-  def broadcast(from, text)
-    color = color_for(from)
-    puts
-    puts Rainbow("  [#{from}] (broadcast):").send(color).bright
-    wrap(text, @wrap_width).each do |line|
-      puts Rainbow("    #{line}").send(color)
-    end
-
-    log("\n  [#{from}] (broadcast):")
-    wrap(text, @wrap_width).each { |line| log("    #{line}") }
-  end
-
-  def direct_message(from, to, text)
-    puts Rainbow("    [#{from} -> #{to}]: #{text[0..100]}").magenta.faint
-    log("    [#{from} -> #{to}]: #{text[0..100]}")
-  end
-
-  # ── Memory ─────────────────────────────────────────────────
-
-  def memory_write(writer, key)
-    puts Rainbow("    [memory] #{writer} wrote :#{key}").darkgray
-    log("    [memory] #{writer} wrote :#{key}")
-  end
-
-  # ── Lifecycle ──────────────────────────────────────────────
-
-  def spawn(requester, name)
-    puts Rainbow("    [spawn] #{requester} recruited #{name}").green
-    log("    [spawn] #{requester} recruited #{name}")
-  end
-
-  def complete(writer)
-    puts
-    puts Rainbow("  [#{writer}] marked the work as COMPLETE").green.bright
-    log("\n  [#{writer}] marked the work as COMPLETE")
-  end
-
-  # ── Incoming message (from bus, before LLM processes) ──────
-
-  def incoming(writer, from, content)
-    puts Rainbow("    [#{writer}] heard #{from}: #{content.to_s[0..80]}...").darkgray
-    log("    [#{writer}] heard #{from}: #{content.to_s[0..80]}...")
-  end
-
-  # ── Chrome ─────────────────────────────────────────────────
-
-  def banner(text)
-    puts
-    text.each_line { |line| puts Rainbow(line.chomp).bright }
-    puts
-
-    log("")
-    text.each_line { |line| log(line.chomp) }
-  end
-
-  def separator
-    puts Rainbow("  #{"─" * (@term_width - 4)}").darkgray
-    puts
-    log("  #{"─" * 56}")
-    log("")
-  end
-
-  def phase(text)
-    puts
-    puts Rainbow("  ▸ #{text}").bright
-    puts
-    log("\n  ▸ #{text}\n")
-  end
-
-  def info(text)
-    puts Rainbow("  #{text}").darkgray
-    log("  #{text}")
-  end
-
-  def stats(text)
-    puts
-    text.each_line { |line| puts Rainbow(line.chomp).bright }
-    log("")
-    text.each_line { |line| log(line.chomp) }
-  end
-
-  def close
-    @log_file&.close
-  end
-
-  private
-
-  def color_for(name)
-    @color_map[name] ||= begin
-      c = WRITER_COLORS[@next_color % WRITER_COLORS.size]
-      @next_color += 1
-      c
-    end
-  end
-
-  def log(line)
-    return unless @log_file
-
-    @log_file.puts line
-    @log_file.flush
-  end
-
-  def wrap(text, max_width)
-    lines = []
-
-    text.to_s.each_line do |paragraph|
-      paragraph = paragraph.strip
-      next(lines << "") if paragraph.empty?
-
-      words = paragraph.split(/\s+/)
-      current = +""
-
-      words.each do |word|
-        if current.empty?
-          current = +word
-        elsif current.length + 1 + word.length <= max_width
-          current << " " << word
-        else
-          lines << current
-          current = +word
-        end
-      end
-
-      lines << current unless current.empty?
-    end
-
-    lines
-  end
-end

data/examples/16_writers_room/output/.gitignore

@@ -1,4 +0,0 @@
-book.md
-room.log
-memory.json
-screenplay.md

data/examples/16_writers_room/output/README.md

@@ -1,69 +0,0 @@
-# Writers' Room Output
-
-This directory contains the creative works produced by the Writers' Room
-self-organizing robot teams (Demo 16). No human wrote any of the prose,
-outlines, or screenplay content — it all emerged from robots coordinating
-through bus messages and shared memory.
-
-## The Works
-
-### opus_001.md — First Book
-
-The first novella ever produced by the Writers' Room. A team of writer
-robots self-organized to create a 10-chapter science fiction story. They
-discussed the premise, built a story bible, outlined the plot, claimed
-chapters, and wrote them — all without orchestration or assigned roles.
-
-`opus_001_notes.log` contains the session log from that run.
-
-### opus_002.md — Second Book
-
-The second novella produced by the Writers' Room. Same process, same
-self-organizing pattern, different story.
-
-`opus_002_notes.log` contains the session log.
-
-### opus_002_screenplay.md — First Screenplay
-
-The first screenplay the robots ever created. After opus_002 was written,
-the Writers' Room was extended with a screenplay mode that adapts a
-finished book into a 4-act made-for-TV movie pilot.
-
-The workflow:
-
-1. Book mode runs and produces a novella (opus_002.md)
-2. Book mode also dumps all creative artifacts (story bible, outline,
-   chapters) to `memory.json`
-3. Screenplay mode is launched with `--screenplay-from memory.json`,
-   which reloads that memory into the room before the screenwriters start
-4. The screenwriters read the source material, discuss adaptation choices,
-   build a scene outline, and write individual scenes in standard
-   screenplay format
-
-```bash
-# Step 1: Write the book (memory.json is saved automatically)
-bundle exec ruby examples/16_writers_room/writers_room.rb
-
-# Step 2: Adapt it to a screenplay
-bundle exec ruby examples/16_writers_room/writers_room.rb \
-  --screenplay-from examples/16_writers_room/output/memory.json
-```
-
-Screenplay writers work at the scene level — each robot claims and writes
-individual scenes rather than entire acts. They maintain a `scene_registry`
-in shared memory listing all planned scenes, and can drop or reorder
-scenes as the adaptation takes shape. When unclaimed scenes pile up, the
-robots spawn additional writers to help.
-
-`opus_002_screenplay_notes.md` is the log of the robots discussing the
-screenplay adaptation process — debating what to keep, what to cut, how
-to restructure the story for screen, and how to handle act breaks.
-
-## Working Files
-
-These files are generated each run and git-ignored:
-
-- `book.md` — latest book mode output
-- `screenplay.md` — latest screenplay mode output
-- `memory.json` — memory dump from the latest book mode run
-- `room.log` — structured log from the Room (timestamps, tool calls, heartbeats)