[Standalone/Templates] Materialize standalone products as product-owned generated repos instead of packaged renames

[ogyrec-o]

Summary

Follow up the standalone shipped-product profile from #61 by defining and implementing the long-term standalone authoring/export model:

• freven-boot remains a generic multi-profile platform/devkit repo
• standalone shipped products become product-owned generated projects/repos
• product identity becomes end-to-end:
  • crate names
  • bin names
  • package names
  • manifests
  • namespaces
  • packaging outputs
  • launcher/client/server naming
• standalone exported products no longer rely on internal freven_boot / freven_client / freven_server repo-level bin identity plus packaged renames

Current state

After #61, Freven now has a real third shipped profile:

• vanilla-product
• host-foundation
• standalone-game-product

That is the correct short/medium-term base.

In particular, standalone-game-product is now honest as a shipped standalone custom-game product profile:

• zero-Vanilla by default
• no Vanilla builtin registrations by default
• explicit bundled default experience
• playable after download
• product-shaped packaged launcher/client/server names
• product-specific instance namespace
• proof/demo bundled experience rather than canonical standalone gameplay contract

However, the current standalone product identity is still implemented as:

• stable repo-level internal build bins inside freven-boot
  • freven_boot
  • freven_client
  • freven_server
• shell-owned runtime identity
• packaged artifact renaming into product-facing names

That is acceptable for the generic multi-profile repo and was the right decision for #61.

But it is not the final long-term standalone product authoring/export model.

Problem / Motivation

Freven is intended to support both of these worlds:

Platform-style flows

• Vanilla + mods
• mode/ruleset packs
• base-experience + overlays/stacks
• zero-Vanilla custom platform modes
• Roblox / Vintage Story / Minecraft-modpack style content ecosystems

Standalone shipped products

• custom games built on the same engine/runtime/API
• export/distribution to itch.io / Steam / direct download
• zero dependency on the platform shell UX at the product level
• Unreal-style packaged standalone products
• future s&box-style “build here, ship separately” workflows

That means standalone products should eventually become true product-owned app projects, not only packaged views over a generic platform repo.

If this is not made explicit, the current #61 solution could accidentally harden into the permanent model:

• generic multi-profile repo internally
• product identity only at packaging/runtime shell layer
• no true generated product project boundary

That would be good enough for proof/export, but weaker than the long-term architecture Freven should aim for.

Architectural direction

Keep this true

freven-boot is the generic multi-profile repo.

It should remain able to validate and package:

• Vanilla product
• host foundation
• standalone shipped-product proof/profile

It should not become the permanent home of every future concrete standalone game as if each product should live inside the generic repo.

Move toward this

A future standalone authoring/export flow should materialize a product-owned generated project/repo that owns its own identity end-to-end.

That generated product should own:

• crate names
• binary names
• package/display names
• product ids
• namespaces
• launcher/client/server naming
• packaging outputs
• docs/readmes
• product-facing manifests
• optional future branding/resources/icons/etc.

The standalone product should read like a real app/product repo from the inside out, not only after packaging.

Target model

At long-term maturity, standalone export should look more like:

• start from Freven engine/platform/devkit APIs and templates
• generate a standalone product project/repo
• that generated product owns real product identity end-to-end
• the product may then:
  • stay inside Freven platform ecosystem as a mode/experience lineage if desired
  • or ship independently as a standalone game
  • or support both paths intentionally

Important boundary

This issue is not asking to collapse platform mode and standalone mode into one thing.

Instead, the model should stay layered:

• shared engine/runtime/API foundation
• platform shell/product paths
• standalone generated product path

Requirements

Product-owned generated project shape

Define and implement a path where standalone projects can own, at minimum:

• launcher crate/bin identity
• client crate/bin identity
• server crate/bin identity
• product namespace / instance namespace
• product manifest identity
• packaged output naming
• product-facing docs/readmes

Preserve generic repo correctness

The solution must preserve that:

• freven-boot remains a generic multi-profile repo
• standalone-game-product in freven-boot can continue to exist as a proof/reference profile
• standalone generated products do not force Vanilla assumptions back into generic host/platform code
• generic resolver/load-plan/activation semantics remain foundation-owned, not product-redefined

Template/export flow

There should be a clear path for:

• generating a standalone product project from a template or scaffold
• configuring product identity once
• materializing real product-owned crates/bins rather than only repackaging generic repo bins
• documenting how this differs from:
  • platform mode
  • host foundation
  • Vanilla product
  • in-platform custom experiences
  • modpacks / overlays / stacks

Avoid false gameplay assumptions

The standalone generation/export path must not assume that every standalone product is:

• worldgen-driven
• avatar-based
• first-person / controller-based
• voxel-survival-like

A bundled proof/demo experience may exist, but the generated standalone model must support:

• strategy
• card game
• top-down
• puzzle
• UI-heavy
• non-avatar
• non-worldgen
• hybrid
• anything else the engine/runtime contracts allow

Product identity should be real, not cosmetic

Avoid ending up with a system where:

• product binary names are only archive-time renames
• product identity is only metadata
• internal generic names leak into user-facing generated product repos

The generated standalone project should internally read like the product it is.

Non-goals

• Do not remove or weaken the platform-mode ecosystem.
• Do not remove standalone-game-product from freven-boot as a proof/reference profile.
• Do not redesign canonical load-plan construction or resolver semantics.
• Do not force every standalone product to use the same gameplay stack.
• Do not require immediate editor/catalog/publishing backend work.
• Do not conflate standalone generated product repos with Roblox-style in-platform publishing flows.

Deliverables

At minimum:

• architecture/docs update describing the generated standalone product direction
• explicit statement of the boundary:
  • generic multi-profile repo vs generated product-owned repo
• follow-up implementation plan or initial implementation for:
  • standalone project template/scaffold
  • product-owned crate/bin naming
  • generated manifest/package identity
  • product-owned packaging/readme surfaces
• clear explanation of how this relates to [Packaging] Add a standalone custom-game product distribution profile #61 rather than replacing/reverting it

Acceptance criteria

This issue is done when Freven has a clear and durable answer to:

• how standalone shipped products become true product-owned projects
• where repo-level technical bin identity should stop
• where product-owned identity should begin
• how standalone products differ from platform modes/modpacks/stacks
• how the generic platform/devkit repo stays generic without trapping standalone products inside it forever

Related / Follow-up context

• [Packaging] Add a standalone custom-game product distribution profile #61 established the standalone shipped-product profile inside the generic multi-profile repo.
• This issue is the next step: moving from an honest proof/export profile to a true product-owned standalone project model.