VSCode build tasks for Unit and perf tests with MCP

[slyi]

First off, thank you so much for creating and maintaining goboscript! It has been an absolute game-changer for my productivity and workflow.
I am currently setting up an automated build, unit test, and performance benchmarking pipeline in VSCode using goboscript-mcp (tw start -l) and VSCode build tasks. My setup pipes logger outputs into the terminal and automatically terminates when it reads a custom exit marker ([PROCESS_EXIT]).
Here is my current proof-of-concept setup:

main.gs

costumes "blank.svg";

onflag {
log "Hello World from goboscript!";

// Broadcast the exit signal right before stopping
log "[PROCESS_EXIT]";
stop_all();

}

tasks.json

{
"label": "Build & Run (MCP)",
"type": "shell",
"command": "tw start -l | sed '/\[PROCESS_EXIT\]/q'",
"dependsOn": "2. Load into TurboWarp",
"group": {
"kind": "build",
"isDefault": true
},
"presentation": {
"reveal": "always",
"focus": true,
"clear": true
}
}

Questions on Optimal Build & Test Workflow
While this setup works well for standard console logs, I'm looking to refine the optimal cycle for running automated unit and performance tests:

CPU Throttling for Perf Tests: Is there a recommended way to emulate mid-tier mobile CPU performance during automated tw start -l test runs (e.g., via Chrome DevTools Protocol flags or launch options in the background)?

Timing & Benchmark Metrics: If hardware CPU throttling isn't directly scriptable through the CLI launcher, would scaling/dividing measured timing deltas (using timer or days_since_2000) serve as a reasonable proxy for target hardware performance, or is there a preferred pattern used in the community

My old tasks.json

{
"version": "2.0.0",
"tasks": [
{
"label": "Run Goboscript Build Script",
"type": "shell",
"command": "python macro_processor.py pre && goboscript build && python macro_processor.py post && "C:\Progra~1\WindowsApps\45747ThomasWeber.TurboWarpDesktop_1.16.0.0_x64__dx91esefr5w5e\app\TurboWarp.exe" ${workspaceFolderBasename}.sb3",
"args": [],
"group": {
"kind": "build",
"isDefault": true
},
"problemMatcher": []
},
{
"label": "Force Restore Macros",
"type": "shell",
"command": "python macro_processor.py post",
"problemMatcher": []
},
{
"type": "goboscript-build",
"problemMatcher": [],
"label": "goboscript: goboscript-build"
}
]
}

[slyi]

I made https://github.com/slyi/gobo-agent
A small dev loop for GoboScript that runs your build on the real Scratch runtime — upstream @scratch/scratch-vm in a plain browser, the same runtime family as the scratch.mit.edu player — so an agent (or you) can build, read live debugger logs, screenshot the stage, and poke values into a running project. No Scratch Desktop, no TurboWarp Desktop, no Electron. This allow for injected user input clicks and key input. This allows for fast unit, perf and UI automation tests against the real scratch vm runtime. This helps speed up code change and verify loop with agents using goboscript.

[faretek1]

Why not use turbowarp? Turbowarp scaffolding exists too. Also im unsure how electron/tw desktop is a big deal here since youre opening html in a browser anyway?

[slyi]

I target real scratch as 90% of users can't/won't use turbowarp, it performance is not real world so it's a fake perf measurement.