Boundary between the manager and StarMap

[Maximilian-Nesslauer]

This narrows question 3 of #13 .
That question asks whether the loader is an external dependency. The fact is that both an in-game mod manager and instancing are currently being built twice.

What exists right now:

• StarMap has a working in-game mod manager on a local feature branch (video). @KlaasWhite has said he deliberately paused it to wait for what gets decided here, and that he wants everything beyond mod loading to stay optional, e.g. disabled by an argument, so other managers are not forced to go through it. ( https://discord.com/channels/1439383096813158702/1532471092252381244/1533481043984646254 )
• Borea plans a Factorio-style in-game part as a KSA mod, sharing Borea.Core/Borea.Storage/Borea.Network with the desktop app.
• StarMap also already contains the skeleton of a two-process design: IPC.proto defines browsing, mod details with versions and download locations, and applying a set of mod changes, implemented on the loader side and stubbed on the supervising side. See research/starmap.md.
• Instancing sits in the middle: StarMapLoader/StarMap#80 redirects Constants.DocumentsFolderPath, and Borea's instance model is built on exactly that redirect existing.

@MrJeranimo sketched two models in Discord ( https://discord.com/channels/1439383096813158702/1532471092252381244/1533478096714338385 ) and is open to both:

1. StarMap owns the in-game management and works with Borea so both share data and files appropriately.
2. StarMap stays a loader and Borea ships its own KSA mod for the in-game part.

He also offered a third mechanism that cuts across both: StarMap could consume the Borea.Core/Borea.Storage/Borea.Network libraries directly, so both frontends run on the same code.

What needs deciding

1. Who ships the in-game UI? Model 1, model 2, or both with a defined interface. "Both, uncoordinated" is the one outcome we should avoid.
2. What is the shared state, and who owns it? Installed-mod registry, instance definitions, cache locations, download bookkeeping. Today each side has its own answer, and manifest.toml is the only file they both touch.
3. Which direction does the dependency point? The Proposal of StarMap consuming Borea libraries makes the loader depend on one manager's internals. A neutral contract, on-disk formats or the existing IPC protocol, keeps the loader manager-agnostic, which also matches the multi-loader future @MrJeranimo argued for in Scope Discussion #13.
4. Where does instancing live? If StarMap#80 lands, the loader provides the mechanism. Does the definition of what an instance is (its folders, its manifest, its metadata) belong to the loader, the manager, or a spec here that both implement?

Answers to 2 and 3 are the part that should become an RFC; 1 is ultimately a decision for the two projects, but it should be recorded here either way.

[Maximilian-Nesslauer]

Facts update: StarMap 0.4.6 released, and it changes two things this discussion was resting on.

The two-process design is gone. The IPC.proto protocol, the pipe transport, and the supervising launcher process I pointed at in the opening post were all deleted.
@KlaasWhite confirmed it is not needed anymore: applying a mod change now means doing the file operations and spawning a fresh StarMap.exe, which picks them up before mods load. So the integration surface I described ("the existing IPC protocol") no longer exists; the loader's pattern is file operations plus a self-restart.

Instancing shipped. StarMapLoader/StarMap#80 is merged and released: -InstancePath <path> or the STARMAP_INSTANCE_PATH environment variable redirect Constants.DocumentsFolderPath before mod discovery, which moves the whole profile (mods, manifest, saves, settings). A manager can set either per launch without touching StarMap's config. That unblocks the instancing pre-RFC @MrJeranimo wanted to open.

The research doc is updated accordingly in #22.

[MrJeranimo]

Personally, I think the boundary should be one of two.

1. StarMap stays just a loader, no mod manager in it. Keeps StarMap lightweight.
2. StarMap adds a manager but makes it optional, potentially through a CLA like @KlaasWhite said he was planning. This would make it possible for other managers to still use StarMap without any coupling. However a drawback is StarMap will get more complex, but I am not sure how much that will impact anything.

My preference is 1 because it also removes any chance of Instancing mis-match between StarMap and other mod managers.