Docs: add goal, base guidelines, and base implemetation

[marvin1099]

docs/base-guidelines.md — launcher flow overview (moved from src/wand_launcher/Docs.md and renamed).
docs/goals.md — project goals and direction (rewritten). docs/implementation.md — detailed implementation guide covering each phase's internal logic, no code.

This is not needed but i just made it as an option.

[gemini-code-assist]

Code Review

This pull request introduces comprehensive documentation for the Wand Launcher project, including the base guidelines flow draft, project goals and direction, and a detailed implementation guide. The reviewer feedback highlights a couple of inconsistencies in the documentation: a mismatch in the number of options described versus listed in the prefix setup section, and conflicting paths specified for the metadata.json file. Both comments provide clear, actionable suggestions to resolve these documentation issues.

[marvin1099]

^ Renamed PR to fit convention (^^ There i also re-based on rewrite/v2).

[marvin1099]

Added some more details and some refinements.
Still optional to merge directly in main project to folder docs.
We can also put this in a other folder or hide it or delegate to somewhere else.

[shymega]

Again, this feels very overengineered (although I now understand the rationale for StepRunner and migrations), and I think we need to take a step back and adhere to the KISS philosophy.

It's commendable that you're trying to do so much good in the rewrite, but I worry it'll end up like before, where its unmaintainable, and quite complex to work with.

[marvin1099]

Again, this feels very overengineered (although I now understand the rationale for StepRunner and migrations), and I think we need to take a step back and adhere to the KISS philosophy.

It's commendable that you're trying to do so much good in the rewrite, but I worry it'll end up like before, where its unmaintainable, and quite complex to work with.

As mentioned, I don't want useless stuff, but I'm willing to add a bit more complexity for a nicer experience with the code-base or when using the launcher as a user or for modularity.

I don't think is a good idea to try to squash complexity at all opportunity's.
If there is a good use for complexity, I still think its worth it.

[shymega]

I suppose my point is that this launcher has historically been very simple. It has a rather straightforward execution flow, in terms of the launch options.

I'm not necessarily squashing complexity, I just question about certain processes being proposed.

I would encourage critical scrutiny of the LLM-generated content (will work on a policy for this, as I've used LLMs too!), and keeping it as barebones as possible. The KISS philosophy is worth bearing in mind.

[marvin1099]

I'm not necessarily squashing complexity, I just question about certain processes being proposed.

Ok, shure we can rethink, just don't want to run after simplicity, but of course we can still change stuff.
Its a suggestion on the main flow after all so changes are of course intended.
What do you think then needs to be reworked,
dont have to go after the entire thing we can just change what we get to.

I would encourage critical scrutiny of the LLM-generated content

I do try to reprompts and make manual edits, to try to make shure its inline with what I imagin for the launcher, sounds like I missed some things.
Can happen will just change what is not inline.

[shymega]

I'm not necessarily squashing complexity, I just question about certain processes being proposed.

Ok, shure we can rethink, just don't want to run after simplicity, but of course we can still change stuff. Its a suggestion on the main flow after all so changes are of course intended. What do you think then needs to be reworked, dont have to go after the entire thing we can just change what we get to.

I think the idea of a flow is good, and I'd also like to see some sort of versioned schema for configs that the launcher could pull from GitHub. However, we really need to document a new versioning process.

I would encourage critical scrutiny of the LLM-generated content

I do try to reprompts and make manual edits, to try to make shure its inline with what I imagin for the launcher, sounds like I missed some things. Can happen will just change what is not inline.

Yeah. I only used Claude originally because the 'legacy' codebase was spaghetti-like. But I think we need to work on documenting in issues what we want, then directing Claude to that, with minimal LLM-input, and human oversight.

[marvin1099]

Yeah. I only used Claude originally because the 'legacy' codebase was spaghetti-like. But I think we need to work on documenting in issues what we want, then directing Claude to that, with minimal LLM-input, and human oversight.

I dont really have that kind of money, so I usually use opencode's free model big-pickle.
The quality is good enough because I know what I want, Claude is probably a bit better in that regard.

Other then that the idea of the docs folder was to have the ai also be able to use docs/ to understand the project.
If we where to document in issues, I would not know how to get the docs localy and I prefer to have the data the ai works on be downloaded so it dosnt have to make a bunch of web requests.
Also there is the risk of the ai reading issues intended for v1, something well crafted description to what we want like these files is pretty good for having ai references as well as humans can also use it for relevance.

I think the idea of a flow is good, and I'd also like to see some sort of versioned schema for configs that the launcher could pull from GitHub. However, we really need to document a new versioning process.

I that would be what the manifest file was supposed to be.
A collection of settings that are pulled and contain things like a UA, a build prefixes repo link, conifg version and things like that.

The config in .config was the user config file so thats just empty by default or has like a small template like entry as example.

Exact details I have not jet created, foot no note for shure.

[shymega]

Yeah. I only used Claude originally because the 'legacy' codebase was spaghetti-like. But I think we need to work on documenting in issues what we want, then directing Claude to that, with minimal LLM-input, and human oversight.

I dont really have that kind of money, so I usually use opencode's free model big-pickle. The quality is good enough because I know what I want, Claude is probably a bit better in that regard.

I tried Big Pickle, didn't know about it. Seems pretty good.

Other then that the idea of the docs folder was to have the ai also be able to use docs/ to understand the project. If we where to document in issues, I would not know how to get the docs localy and I prefer to have the data the ai works on be downloaded so it dosnt have to make a bunch of web requests. Also there is the risk of the ai reading issues intended for v1, something well crafted description to what we want like these files is pretty good for having ai references as well as humans can also use it for relevance.

I think we should use issues, so we can collaborate on them, and the AI is smart enough to figure out the latest context - I've done this on a different project. We could even setup a CI workflow to download an issue and its comments into a Markdown file, and the LLM can be pointed there if that works. But the planning documents would be best in an issue, with a Kanban board.

I think the idea of a flow is good, and I'd also like to see some sort of versioned schema for configs that the launcher could pull from GitHub. However, we really need to document a new versioning process.

I that would be what the manifest file was supposed to be. A collection of settings that are pulled and contain things like a UA, a build prefixes repo link, conifg version and things like that.

Yes, I see.

The config in .config was the user config file so thats just empty by default or has like a small template like entry as example.

Exact details I have not jet created, foot no note for shure.

Not sure what you mean here?

[marvin1099]

The config in .config was the user config file so thats just empty by default or has like a small template like entry as example
Exact details I have not jet created, foot no note for shure.

Not sure what you mean here?

I meant like setting global settings for the games; like disable the troubleshooter is saved there, just settings that can be changed and we want to allow to be changeable via the .config file, so user can then override things.

That config would be after game setting overrides if there are any like environment vars.

[shymega]

Hi, I'd imagine you mean locally-scoped settings for the games? I think we could use the Steam app ID, or fallback to heuristics and guess from the Wine path.

On 28.06.2026 12:02, Marvin1099 wrote: marvin1099 left a comment (DeckCheatz/wemod-launcher#268) > > The config in .config was the user config file so thats just empty by default or has like a small template like entry as example > > Exact details I have not jet created, foot no note for shure. > Not sure what you mean here? I meant like setting global settings for the games; like disable the troubleshooter, just settings that can be changed and we want to allow we expose to be changeable via the .config file, the user can then override things. That config would be after game setting overrides if there are any like environment vars. -- Reply to this email directly or view it on GitHub: #268 (comment) You are receiving this because your review was requested. Message ID: ***@***.***>

Best wishes, -- Dom Rodriguez

[marvin1099]

I'd imagine you mean locally-scoped settings for the games?

Global setting are also intended.
I thoght:
config.json
games.json

For global and game settings.

I think we could use the Steam app ID, or fallback to heuristics and guess from the
Wine path.

No real need for guess work, we can just use the game path as json key, the path will usualy not change and works is run with regular wine as well

The script already needs to extract the gameexe path for running it with the bat, we can use that one.

[shymega]

I'd imagine you mean locally-scoped settings for the games?

Global setting are also intended. I thoght: config.json games.json

For global and game settings.

I'm happy with this, as long as the local scope of game settings take precedence over global settings.

I think we could use the Steam app ID, or fallback to heuristics and guess from the
Wine path.

No real need for guess work, we can just use the game path as json key, the path will usualy not change and works is run with regular wine as well

I think this is flimsy. We should use the Steam App DB API to work out the game title, as not all games will have it in their path.

The script already needs to extract the gameexe path for running it with the bat, we can use that one.

Yes, but its not necessarily going to be 100% flawless - therefore, it is ever-so-slightly fragile.

[marvin1099]

I think this is flimsy. We should use the Steam App DB API to work out the game title, as not all games will have it in their path.

I meant we just use the full path as json key then we dont need the Steam app I'd at all, not all games will have that, like some itch games that are not on steam.
All games have a path and 2 games are never on the same path.

[marvin1099]

Yes, but its not necessarily going to be 100% flawless - therefore, it is ever-so-slightly fragile.

True the script could miss the game path, bit if it did it would start anyway because we need the game path to run the game in the first place.

[marvin1099]

m happy with this, as long as the local scope of game settings take precedence over global settings.

Was intended to yes, if there is no game config we can fallback to the global one. Something like that.

[shymega]

I think this is flimsy. We should use the Steam App DB API to work out the game title, as not all games will have it in their path.

I meant we just use the full path as json key then we dont need the Steam app I'd at all, not all games will have that, like some itch games that are not on steam. All games have a path and 2 games are never on the same path.

That's true, we do need to account for non-Steam games. However, using the SteamDB API to determine game titles could be used for more rich data in the launcher, so we shouldn't dismiss that right away.

I also would like us to finish finalising what issues we want to create for the Kanban board, then upload them based on this branch. I'm going up to the office soon, so I can spend time on the train writing up issues based on what you've done - and create from there. Thoughts on that?

[marvin1099]

That's true, we do need to account for non-Steam games. However, using the SteamDB API to determine game titles could be used for more rich data in the launcher, so we shouldn't dismiss that right away.

Personaly I prefer if we dont relied on steams db.
I prefer the launcher to be a general tool and not nessesary have a extra code path for steam games. I'm not saying I completly against it but I prefer the launcher to be a general game tool.

Using full paths must be different for all games so we can save data, but as the launcher really works the same across all games and the stored settings are more preferences then anything else so steam data won't really be that useful. I would be more inclined to consider using steam db is the settings we want to store for the game are like needed for game compatibility, but as we just let proton or similar handle it the steam db info is not that useful really.

I also would like us to finish finalising what issues we want to create for the Kanban board, then upload them based on this branch. I'm going up to the office soon, so I can spend time on the train writing up issues based on what you've done - and create from there. Thoughts on that?

Shure we can always add or remove from the Bord. See what the Bord should have I will also check on that soonish.