Platforms: every kind of app QuorX builds, and how sure we are
The 16 platform packs as one matrix: what each detects, checks, runs, debugs and explains, rated proven, tested, logic tested or not yet by the evidence behind it.
QuorX builds web apps, and much more: command-line programs, desktop apps, phone apps, games and installers. Each kind of app is a platform pack, one file in server/packs/ that tells QuorX how to find the toolchain, check the work, run and drive the app, debug it, and explain it to the agent. This page lists every pack and how much evidence stands behind it.
What a pack does
A pack doesn't need all five on day one. Where a cell in the matrix says "–", that part isn't there yet, or the platform doesn't have one (an installer has nothing to debug).
How sure we are
Each pack is rated by the evidence behind it, not by how much code it has:
- Proven: an agent built and ran a real app with it in a QuorX chat.
- Tested: its self-tests passed on a real machine with the toolchain installed.
- Logic tested: the pack is written and its logic (parsers, rules, command lines) passes its tests, but nobody has run it against the real toolchain yet.
- Not yet: planned, not started.
No pack is rated proven yet. That level needs a recorded chat in which an agent builds and runs a real app with the pack, and the UI test (npm run test:ui) is how such a run gets recorded. The tested packs passed their self-tests on the machines where their pull requests were tested; the evidence column names the run.
The matrix
Filter by level to see what is ready. Each row comes from the pack registry (server/packs/), with the evidence for its level.
| Platform | Level | Covers | Detect | Check | Run and drive | Debug | Explain | Evidence |
|---|---|---|---|---|---|---|---|---|
| Electron | Tested | Desktop apps with web-page windows and a Node main process | Node.js | – | Windows read and clicked through the DevTools port | Main process: Node inspector (debug attach) | Starting with a DevTools port, main and renderer output | 8 of 8 self-tests with Electron 44 on Windows 11 (PR #8) |
| Every project | Tested | Every project | Git, FFmpeg | – | Terminal, background jobs, the browser | – | Git, and how QuorX works in any folder | Git is found on every test run |
| Godot | Tested | Games and apps made with Godot 4 and GDScript | Godot 4 | godot --check-only on each changed script | Scenes run headless and print | Godot (GDScript) | Imports, class_name, user:// logs | 8 of 8 with Godot 4.7.2: a script error caught, a breakpoint hit in the running game (PR #9) |
| Java and Kotlin | Tested | Programs, desktop apps (Swing, JavaFX), services and libraries on the JVM | Java (JDK), Gradle, Maven, Kotlin compiler | Gradle or Maven compile through the wrapper | JavaFX through UI Automation, Swing with keys; JUnit summaries | Java and Kotlin (JDK debugger) | Wrappers, JUnit reports, Swing and JavaFX | 14 of 14 with JDK 21 and Gradle 8.14: compile check, JUnit summary, a breakpoint hit (PR #11) |
| Node.js and TypeScript | Tested | Scripts, command-line tools and servers | Node.js | tsc --noEmit for TypeScript | Terminal and background servers; pages in the browser | Node inspector (built in) | npm scripts, TypeScript, servers | Self-test passes on Windows 11 (PR #3, #8) |
| Python | Tested | Scripts, command-line tools, services and desktop apps (tkinter, PyQt, PySide) | Python 3 | Syntax with the venv's own Python, plus ruff or pyflakes | tkinter windows clicked; pytest summaries | Python (debugpy) | Project venvs, pytest, tkinter limits | Python 3.12 with tkinter, debugpy and pyflakes: a button clicked, a breakpoint in its handler (PR #14) |
| Windows installers (Windows only) | Tested | MSI packages with WiX and MSIX packages with MakeAppx and SignTool | WiX Toolset (v4 or later), Windows SDK (MakeAppx, SignTool) | wix build on changed .wxs files | MSIX packed and signed with a test certificate | – | WiX, MakeAppx, SignTool, test signing only | 6 of 6 with WiX and the Windows SDK: a schema error caught, an MSIX packed and test-signed (PR #9) |
| .NET (C#) | Logic tested | Console, WinForms, WPF, ASP.NET and MAUI apps | .NET SDK, netcoredbg | dotnet build | WinForms and WPF windows read and clicked; dotnet test summaries | C# (netcoredbg) | SDKs, target frameworks, test runners | 4 logic tests pass; 7 need the .NET SDK and skip (PR #4) |
| Android | Logic tested | Apps built with Gradle, run on an emulator, tapped and read like a person would | Android SDK, Android platform tools (adb), Android emulator | Gradle compileDebugSources | Emulator booted, screen read and tapped; Logcat crash summaries | – | SDK, emulator, Gradle, Logcat | 11 logic tests pass with a stand-in Gradle; no Android SDK tested yet (PR #10) |
| Apple apps (macOS only) | Logic tested | iPhone, iPad and Mac apps (SwiftUI, UIKit, AppKit) and Swift packages | Xcode, Swift, Simulators, idb | xcodebuild, swift build | iOS Simulator driven; crash reports read | Swift and Objective-C (lldb-dap) | Xcode setup, simulators, crash reports | Needs a Mac; its logic is tested on Windows (8 pass, PR #13) |
| C and C++ | Logic tested | Native programs and libraries with CMake | CMake, Visual Studio C++ (MSVC), GCC, Clang, LLDB (lldb-dap) | cmake --build on the project's build folder | Terminal for programs | C and C++ (lldb-dap) | CMake, MSVC and MinGW, crash dumps | Debugger tests pass with a stand-in adapter; needs CMake and LLVM (PR #7) |
| Flutter and Dart | Logic tested | Windows, macOS, Linux and Android apps from one Dart codebase | Flutter, Dart SDK | flutter analyze, dart analyze | Desktop builds driven like any window; test summaries | Dart and Flutter (debug_adapter) | Devices, flutter doctor, debug_adapter | The debugger bridge tested with a stand-in adapter; no Flutter or Dart tested yet (PR #10) |
| Go | Logic tested | Command-line programs and services | Go, Delve (Go debugger) | go vet | Terminal for programs | Go (Delve) | Modules, go test, Delve | Debugger tests pass with a stand-in adapter; needs Go and Delve (PR #7) |
| Rust | Logic tested | Command-line programs, libraries and services | Rust (cargo) | cargo check | Terminal for programs | Rust (lldb-dap or CodeLLDB) | Cargo, the MSVC linker, panics | cargo check catches errors for real (3 pass); builds and the debugger need the C++ Build Tools (PR #7) |
| Tauri | Logic tested | Desktop apps with a Rust back end and a web front end | Tauri CLI, WebView2 runtime | cargo check in src-tauri | Window read and clicked through WebView2's DevTools port | Rust side: lldb-dap (Rust pack) | Tauri 1 and 2, capabilities, panics | The WebView2 drive path tested with a real WebView2 window; no real Tauri build yet (PR #6) |
| Unity | Logic tested | Games and apps made with Unity and C# | Unity Hub, Unity Editor | Unity batchmode compile | EditMode tests summarised | – (logs only) | Editor versions, license, first import, logs | Parsers and editor discovery tested on fixtures (4 pass); needs Unity with a license (PR #9) |
| MinGW gdb debugging | Not yet | Debugging MinGW builds with gdb's own adapter (gdb -i dap) | – | – | – | – | – | Not started: lldb-dap debugs MinGW builds meanwhile |
| Unity's debugger | Not yet | Breakpoints in a running Unity game | – | – | – | – | – | Not started: Unity's debugger is not one the debug tool can drive |
No rows at this level.
Help test a pack
The fastest way to move a pack from logic tested to tested is to run its self-test on a computer that has the toolchain. No key is needed and nothing is spent: the self-tests drive QuorX's own checks, debugger and builds directly, and skip whatever the computer doesn't have.
> npm run test:packs > npm run test:packs -- --pack dotnet Report: pack-test-report.md >
Paste pack-test-report.md into the pack's pull request or a "Pack test report" issue. Some packs need a little setup first: QX_PYTHON pointing at a Python with debugpy and pyflakes for the Python debugger, QX_ELECTRON at an Electron binary (or npm run desktop:setup once), and a running emulator or a virtual device for Android. The full guide is in docs/platform-packs.md.