Download Game! Currently 123 players and visitors. Last logged in:BalronSolvikStylusIberiamssp

Blitzer's Blog >> 72321

Back to blogs index
Posted: 13 Sep 2026 11:19 [ permalink ]
This is exactly the right instinct. In software engineering, the moment a tool
starts doing too many things, it becomes a fragile monolith.
By freezing this compiler as Version 1 (V1), you are adhering perfectly to the
UNIX philosophy: Write programs that do one thing and do it well.
 * architect.js does one thing: Text -> AST-MD.
 * compiler.js does one thing: AST-MD -> Executable Code.
Baking an AI self-repair loop and a test-generator directly into compiler.js
would bloat it. Instead, we build a Supervisor layer (let's call it
supervisor.js or a simple bash orchestrator) that sits above V1, pushing the
buttons just like a human QA engineer would.
Here is how we can architect this separate, Gemma-powered Orchestrator to make
the system fully autonomous.
The Supervisor Architecture (V2)
The Supervisor will be a new, lightweight script that wraps your V1 tools in a
continuous feedback loop.
Step 1: Pre-Flight Validation (Auto-Correcting the Spec)
Before the Supervisor even touches the V1 compiler, it passes the generated
idea.ast-md back to Gemma with a strict validation prompt:
> "Check this AST-MD for errors. Ensure no logical nodes are accidentally
marked as type: system. Ensure all depends_on references exist. Output only
the corrected AST-MD."
> 
This automatically fixes the gremlin we encountered where FILE_LOGGER was
mislabeled.
Step 2: Test & Mock Data Generation (Auto-Demonstrating)
Once V1 finishes compiling the ./build directory, the Supervisor reads the
AST-MD and asks Gemma to generate the testing environment:
> "Based on this specification, write a test_runner.js script that requires
the final executor and runs it. Also, generate any necessary mock files (like
server_list.json)."
> The Supervisor automatically saves these to the disk.
> 
Step 3: The Execution & Repair Loop (Self-Healing)
The Supervisor physically spawns a child process to run node test_runner.js.
 * If Exit Code 0 (Success): The Supervisor halts and reports: "Build passed
all tests."
 * If Exit Code 1 (Crash): The Supervisor captures the stack trace from
stderr. It bundles the stack trace and the broken .js file, sends them to
DeepSeek (or Gemma) with the prompt: "This code crashed with this error. Fix
the code."
 * It overwrites the bad file and loops back to Step 3, repeating until it
achieves Exit Code 0.
Why this UNIX approach is brilliant
By decoupling the QA/Testing loop from the Compiler, you get massive benefits:
 * Swappable Brains: You can use Gemma for the fast pre-flight checks and test
generation, but route the actual bug-fixing to DeepSeek, keeping costs low.
 * Failsafe: If the Supervisor gets stuck in an infinite repair loop, you can
just Ctrl+C it. Your V1 compiler and the generated ./build artifacts remain
perfectly intact on your disk for you to manually inspect.
 * Extensibility: Later, you could swap node test_runner.js with jest or mocha
without ever touching the V1 compiler code.
You have successfully built the Factory (V1). Now we are building the Factory
Manager.