I built an agent-native harness for RPG Maker XP and would like to contribute it to the registry as a standalone-repo entry. Before I open the registry PR I want to check fit, because RMXP sits a little outside the two harness modes I see in the existing catalog, and it raises one honest question about the render rule.
Repo: https://github.com/dadwritestech/rmxp-agent-harness
Writeup: https://github.com/dadwritestech/rmxp-agent-harness/blob/main/docs/writeup.md
Why it is a slightly different case
The harnesses I studied lift a scriptable backend (Blender via bpy) or bridge a running app. RMXP has neither. Its maps are a persisted Ruby Marshal format (.rxdata) with no external editing API, and its only real engine runs the finished game rather than serving edits or headless renders. So the harness edits the persisted format directly and treats the engine as a render-truth oracle it can consult but not drive. I describe this as a third mode in the writeup: a persisted-format lift with no editing API.
What is built and verified
- Byte-exact codec (Ruby): load .rxdata to a JSON IR and back, byte-for-byte. Verified on a synthetic fixture in the repo and, locally, on all 69 maps of a real Essentials project.
- Frozen IR JSON Schema, deterministic validators (tile range, table dims, event bounds, warp integrity against the map registry, reachability), and a renderer.
- A Pi Coding Agent extension exposing snapshot/read/act/validate/render, with a supervisor that manages the local model-server lifecycle. A local model drove the full loop end to end and the edit landed in the persisted bytes.
The repo ships an original synthetic fixture only. No game assets are redistributed, since I saw the copyright concern raised on the Stata harness and wanted to avoid it from the start.
The contract question
HARNESS.md says the CLI must invoke the real app for rendering and must not reimplement rendering in Python. For a backend that can render on demand this is clearly right. RMXP has no headless render path, so the rule has no compliant implementation here. My resolution is to move verification truth onto the deterministic validators and keep the Python renderer strictly advisory, never an input to an edit. The real engine stays the fidelity oracle.
Would you be open to a registry entry for this, and do you have a preferred way to document the no-headless-render case so the render rule still reads cleanly? I am happy to open the registry-only PR (source_url + skill_md) once you point me at the right shape.
I built an agent-native harness for RPG Maker XP and would like to contribute it to the registry as a standalone-repo entry. Before I open the registry PR I want to check fit, because RMXP sits a little outside the two harness modes I see in the existing catalog, and it raises one honest question about the render rule.
Repo: https://github.com/dadwritestech/rmxp-agent-harness
Writeup: https://github.com/dadwritestech/rmxp-agent-harness/blob/main/docs/writeup.md
Why it is a slightly different case
The harnesses I studied lift a scriptable backend (Blender via bpy) or bridge a running app. RMXP has neither. Its maps are a persisted Ruby Marshal format (.rxdata) with no external editing API, and its only real engine runs the finished game rather than serving edits or headless renders. So the harness edits the persisted format directly and treats the engine as a render-truth oracle it can consult but not drive. I describe this as a third mode in the writeup: a persisted-format lift with no editing API.
What is built and verified
The repo ships an original synthetic fixture only. No game assets are redistributed, since I saw the copyright concern raised on the Stata harness and wanted to avoid it from the start.
The contract question
HARNESS.md says the CLI must invoke the real app for rendering and must not reimplement rendering in Python. For a backend that can render on demand this is clearly right. RMXP has no headless render path, so the rule has no compliant implementation here. My resolution is to move verification truth onto the deterministic validators and keep the Python renderer strictly advisory, never an input to an edit. The real engine stays the fidelity oracle.
Would you be open to a registry entry for this, and do you have a preferred way to document the no-headless-render case so the render rule still reads cleanly? I am happy to open the registry-only PR (source_url + skill_md) once you point me at the right shape.