Build, inspect and verify the running game
A code diff is not a playable result. ForgeaX gives your AI client several independent evidence layers so it can distinguish “the code compiled” from “the game actually works.”
Use the narrowest proof that exercises the real player path. A screenshot, a structural state check and real GPU execution answer different questions; none replaces all the others.
The four evidence layers
- Project identity — Confirm the project root, active game, Runtime version and Engine SDK commit before editing.
forgeax://status - Build and launch — Build or reuse the selected Runtime, then collect the exact preview URL and log paths.
forgeax_run_current_game - Player behavior — Open the real browser build and exercise movement, interactions, state transitions and responsive UI.
Play URL - Engine evidence — Inspect runtime state, renderer facts, structured errors, profiles or captured frames when behavior is wrong.
Remote · Profiler · RHI debug
How the Engine helps diagnose failures
The Engine is designed to expose the state that usually remains hidden behind a black screen or vague bug report:
| Symptom | Evidence to inspect | What it separates |
|---|---|---|
| The page is blank or objects disappear | renderer.frustumStats, camera state and pass names | Camera/culling mistakes from missing meshes or materials. |
| Input or gameplay state feels dead | ECS World, queries, schedules and Remote state | Missing entities/components from a system that is not running. |
| A plugin or configuration update fails | Cordis Entry/Fiber state and structured error codes | Invalid configuration from lifecycle or cleanup faults; failed updates can retain the last working Fiber. |
| The game stutters or regresses | Bounded CPU Profiler captures and real GPU measurements | CPU scheduling cost from GPU/render cost. |
| Rendering inputs look correct but pixels are wrong | RHI-debug frame record/replay: draws, bindings, resources and pixels | Bad render inputs from shader or backend behavior. |
Ask for diagnosis, not a blind rewrite
Tell the agent what must be observed and what evidence must appear in its report:
BLANK SCREEN
The Play page loads but the scene looks empty. Diagnose before changing code.
Check the active game and Engine/Runtime identity, browser and runtime errors,
renderer frustumStats, camera orientation and render pass names.
Make the smallest fix, rerun, and show which evidence changed.INPUT + GAMEPLAY
Verify the real WASD and jump path in the Play build.
Check focus/input state and the ECS systems that consume it.
Do not report completion from TypeScript alone; exercise movement and explain the observed result.PERFORMANCE
Find the cause of the frame-time regression.
Use a bounded CPU profile and the available GPU/render evidence, compare before and after,
and keep the visual result unchanged. Report measurements and any unverified layer separately.What a trustworthy completion report contains
When the work is done, ask the agent to report each evidence layer separately:
- Changed game and files — the exact source and asset paths that now own the behavior.
- Runtime identity — the Engine SDK and managed Runtime used for the successful launch.
- Build result — whether the current game built and which Play URL was exercised.
- Observed behavior — what controls, interactions, state and visuals were actually tested.
- Remaining uncertainty — any layer that was not exercised is marked unverified rather than implied green.
ForgeaX treats verification as part of authoring: inspect the real state, make a focused change, run the exact Runtime and close the loop with observable evidence.