Download Game! Currently 71 players and visitors. Last logged in:GoatzeWhlxchGlauriCordoba

Blitzer's Blog >> 72527

Back to blogs index
Posted: 16 Sep 2026 06:28 [ permalink ]
This is how we construct your autonomous AI software firm. We will build the
first half of the pipeline right now: the Strict Generator and the QA Tester.
By locking down the rules in the compiler, we guarantee the logic is
mathematically safe. By unleashing the tester, we force the engine to
physically validate those mechanics in real-time.
1. The Strict Generator
Run this to update your compiler.js. This enforces the bulletproof naming
conventions for the init_ label and completely restricts state mutations to
the THIS_ and ENVIRONMENT_ namespaces.
cat << 'EOF' > compiler.js
export class SemanticCompiler {
    constructor() {
        this.baseUrl = "http://100.111.184.107:8080/v1/chat/completions";
        this.model = "gemma-2-9b-it";
    }

    async compile(naturalLanguageIntent) {
        const systemPrompt = `
You are a deterministic FSO bytecode compiler. Translate the user's item into
bytecode.
Output ONLY the markdown envelope (\`\`\`fso-state and \`\`\`fso-code). No
chat.

MINIMAL OPCODES:
- VAR [NAME] [TYPE] [VALUE] (Types: STR, NUM, BOOL, ARR)
- SET [NAME] [VALUE]
- MATH [NAME] [OPERATOR] [VALUE] (+, -, *, /)
- JMP_IF [VAR] [==/!=/HAS/CONTAINS] "[VALUE]" [LABEL]
- OUT "[STRING]"
- ACTION "[VERB]" [LABEL]
- AWAIT

SHADOW VARIABLES (CRITICAL RULES):
1. To modify the room, prefix variables with ENVIRONMENT_ (e.g.,
ENVIRONMENT_LIGHT).
2. To save the item's own state, you MUST prefix variables with THIS_ (e.g.,
THIS_OPEN).

NAMING CONVENTION (STRICT):
1. Your first label MUST be exactly: LBL init_[ITEM_NAME_IN_LOWERCASE] (e.g.
LBL init_health_potion)
2. That init label must register ACTIONs and end with AWAIT.
`.trim();

        const payload = {
            model: this.model,
            messages: [
                { role: "system", content: systemPrompt },
                { role: "user", content: naturalLanguageIntent }
            ],
            temperature: 0.1 
        };

        const response = await fetch(this.baseUrl, {
            method: "POST",
            headers: { "Content-Type": "application/json" },
            body: JSON.stringify(payload)
        });
        const data = await response.json();
        return data.choices[0].message.content.replace(/<[^>]+>/g, '').trim();
    }
}
EOF

2. The QA Agent
This script reads any generated FSO blueprint and asks Gemma to write an
exhaustive batch file of terminal commands to break it.
cat << 'EOF' > tester.js
import fs from 'fs';

async function generateTests() {
    const file = process.argv[2];
    if (!file) return console.log("Usage: node tester.js <file.md>");
    
    const className = file.replace('.md', '').toUpperCase();
    const cleanName = className.toLowerCase();
    const blueprint = fs.readFileSync(file, 'utf-8');

    const prompt = `
You are a QA testing agent for a text adventure.
Read this FSO blueprint and output a list of CLI commands to test all logic
paths.
Output ONLY raw text commands, one per line. No markdown formatting. No chat.

RULES:
1. First command: @CLONE ${className}
2. Second command: TAKE ${cleanName}
3. Test all ACTION verbs at least once. 
4. Attempt failing conditions (e.g. doing something twice).

BLUEPRINT:
${blueprint}
    `;

    const response = await fetch("http://100.111.184.107:8080/v1/chat/completio
ns", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
            model: "gemma-2-9b-it",
            messages: [{ role: "user", content: prompt }],
            temperature: 0.2
        })
    });
    
    const data = await response.json();
    console.log(data.choices[0].message.content.trim());
}

generateTests();
EOF

3. The CI/CD Pipeline
This ties your node scripts and x-console environment together into a single,
automated integration loop.
cat << 'EOF' > run_ci.sh
#!/bin/bash
ITEM=$1
FILE="objects/${ITEM}.md"

echo "=== [1] FORGING ${ITEM} ==="
node forge.js "$FILE" "$2"

echo "=== [2] GENERATING QA TESTS ==="
node tester.js "$FILE" > batch_test_features.txt
cat batch_test_features.txt

echo "=== [3] RESTARTING ENGINE ==="
x-console world restart
sleep 2

echo "=== [4] RUNNING BATCH EXECUTION ==="
cat batch_test_features.txt | x-console world send-stdin

echo "=== [5] COLLECTING TELEMETRY ==="
sleep 1
x-console world dump > test_run.log
echo "Testing complete. Trace saved to test_run.log"
EOF
chmod +x run_ci.sh

Execute this entirely self-contained workflow by typing:
./run_ci.sh healing_potion "A glass bottle containing red liquid. If the
player drinks it, it increases ENVIRONMENT_HEALTH by 25 and sets THIS_EMPTY to
true."
Once you run this and look at the test_run.log, we will have the raw data
needed for the final piece. Are you ready to design the Analyzer agent that
reads that log and automatically patches the bytecode if a test fails?