Architecture docs.

[AldoMX]

Hello ArrowVortex team!

I'm a former StepMania contributor (and the maintainer of StepMania AMX), and I wanted to share some documentation I generated with GPT-5 for ArrowVortex: https://github.com/StepMania-AMX/ArrowVortex/tree/release/docs

The documents cover architecture topics (i.e, a 10,000 ft view of the project), and they use StepMania terminology. The goal is to make ArrowVortex more accessible to StepMania developers who might want to contribute.

Why I'm not pushing this as a PR?

StepMania uses MIT license and ArrowVortex uses GPL, I kept the docs in my own fork with MIT license to avoid any licensing issues. This way, you're free to use, modify, re-license as GPL, or completely ignore the docs.

OTOH, I generated these docs without reading your source code to keep things clean from a licensing perspective, so there might be AI hallucinations that your team would need to review and correct.

That said, I'm also sharing the prompt I used to generate these documents, so you can also generate your own docs and tailor them to your own needs:

Initial Prompt (Released under the public domain, no attribution required)

<task>
This project is Arrow Vortex, a program to create and edit step files for Rhythm Games (aka simfiles), you can see more details in 'README.md' (see below for file content)

You're a Software Architect, and this project doesn't have any documentation yet, so please use the docs/ folder to place as many documents as you need.

Your high-level task is to review the codebase from a 10,000 ft view, and group the different subsystems, so we can have a better understanding to plan small and focused tasks for this codebase.

Feel free to ask any clarifying questions before you begin. I'm not the original maintainer, but I have domain knowledge of StepMania and Rhythm games.
</task>

<followup_question>
I will start by exploring the codebase to map out its structure and then draft an architecture overview and subsystem grouping in the docs/ folder.

Before I begin, a couple of quick clarifications to make sure I align the taxonomy with how you expect to reason about the editor:

Should I group subsystems primarily by functional domain (e.g., Chart Model, Audio, Rendering, I/O) or also call out UI surface modules (e.g., Timing Panel, Note Data Grid, Minimap) as first-class subsystems?
Do you want the subsystem grouping to reference StepMania 5 terms explicitly where analogous (e.g., NoteData, TimingData, StepsType), or keep ArrowVortex-native naming only?
Suggested answers:

Group by functional domain first; call out UI panels separately; reference SM5 terms when analogous.
Group by functional domain only; avoid SM5 naming in docs.
Group by UI features (panels/tools) primarily; functional subsystems secondarily.
Next step: I’ll scan the repository layout to identify major modules and technologies, then propose the subsystem map and documentation plan. After that, I will create initial docs in docs/.

Planned todo list will be created and tracked step-by-step.
</followup_question>

<answer>
That's a pretty good question. Let's explain everything in terms of StepMania, and add a comment in the documentation that the document was written to help maintainers of StepMania.

I believe that 'build/VisualStudio/ArrowVortex.sln' (see below for file content) is a good starting point to get the projects and the source files. Remember that AI tools like `list_files` may truncate the output and are only reliable with small projects.
</answer>

<file_content path="README.md">
___PASTE_README_HERE___
</file_content>

<file_content path="build/VisualStudio/ArrowVortex.sln">
___PASTE_SLN_HERE___
</file_content>

Prompt to Generate the Master Prompt (reuse the existing context window; released under the public domain, no attribution required)

Perfect, thank you so much for these documents.

Now I need you to write a MASTER_PROMPT.md file, with the most important high-level details, to minimize back and forths in future interactions. The file should provide the minimum level of detail to succeed at any arbritary task, but it should cross-reference the existing documents for tasks that need more context.

As an aside, there are some refinements I made manually, like changing the paths to relative paths from the docs/ directory, or changing links with lines of code from file.cpp:123 to file.cpp#L123 to make links clickable in GitHub and VSCode.

[DolphinChips]

some documentation I generated with GPT-5

no.

[uvcat7]

I took a quick look through this "documentation" and it's awful. So bad that it's worse than no documentation at all. Most of the information in it is better gleaned from looking at the directory structure and file names. Many of the basic details in the document are inaccurate and I'm shocked you didn't even take the time to double-check them.

We're not using this. And if I wanted to, I would have used GPT-5 already; I don't need you to do it for me.

You (and anyone else) are welcome to contribute detailed, correct documentation at any time through a PR.