Brainstorming: evolve gametau from runtime portability to execution-topology portability

[devallibus]

Summary

A complex simulation-heavy app is a good stress test for what gametau actually needs to become. The strongest lesson so far is that the next step is not just more runtime portability, but execution-topology portability.

Today gametau mostly answers:

• Tauri or WASM?

The next class of applications needs it to answer questions like:

• main thread or worker?
• immediate command or async job?
• local-only or remote-capable?
• local authority or shared/meta authority?
• browser-safe data tier or desktop/full-fidelity tier?

Working thesis

gametau should remain local-first, but grow into a toolkit that is:

• worker-aware
• topology-aware
• metadata-rich
• validation-friendly

It should not try to become a magical "send Rust anywhere" framework.

Why this matters

Some classes of apps need all of the following at once:

• strong local responsiveness
• high entity counts
• browser and desktop targets
• optional timewarp/pause/fast-forward semantics
• deterministic local simulation in the hot path
• optional connected/meta systems that influence the world asynchronously

That combination strongly suggests:

• the hot path must stay local
• browser offload should start with workers, not network round-trips
• remote systems should focus on async jobs, persistence, shared/meta state, and coarse-grained authority

What should likely become first-class in gametau

1. Web Worker as a real execution target

For heavy browser-side workloads, the first offload target should be WASM + Web Worker, not a networked backend.

2. Distinct API kinds instead of one macro carrying every semantic

A useful split might look like:

• command: immediate local actions
• query: read-only snapshots/views
• job: async heavy work, potentially worker- or remote-capable
• authority: explicit shared/meta backend work

The goal is to avoid pretending that local &mut State calls and remote/shared reducers are the same thing.

3. Typed metadata and generated clients

Once the project has multiple execution classes, gametau should generate machine-readable manifests and typed clients from them.

4. Data/resource tiering

Browser-safe vs desktop/full-fidelity data delivery needs to be treated as a first-class concern rather than an app-specific afterthought.

5. Diagnostics and observability

Shipping complex apps needs:

• runtime identity
• invoke/query/job traces
• health reports
• repro bundles
• deterministic validation hooks

6. Headless and deterministic validation paths

For simulation-heavy apps, gametau should support non-UI validation paths more directly:

• headless sim mode
• deterministic scenarios
• state inspection
• replay/regression support

7. Remote providers, but only for the right work

Remote providers are valuable for:

• async jobs
• persistence/auth
• shared/meta state
• large-data access
• coarse-grained authority

They are a poor fit for:

• per-frame rendering-time work
• timewarp-sensitive local simulation
• immediate follow-camera or hot-path gameplay loops

What probably does not belong in gametau core

These should usually remain app-specific or example/reference material unless a broader pattern proves out:

• domain-specific simulation logic
• game-specific timewarp policy
• project-specific fleet/LOD rules
• market or economy models

Practical direction

If this framing is right, the next major platform work in gametau probably prioritizes:

1. first-class worker execution
2. command/query/job/authority separation
3. typed manifests and generated clients
4. browser-safe data/resource tiering
5. diagnostics + health + repro surfaces
6. headless validation/state inspection
7. remote provider/authority support after the above is stable

Desired outcome

This issue is meant as a strategy discussion, not a commitment to implement everything.

The useful outcome would be a clearer product opinion on whether gametau should evolve from a runtime bridge into a local-first topology-aware toolkit.

Related roadmap items

• webtau: add runtime info / capability introspection API #129
• Diagnostics: add opt-in invoke/task tracing and developer inspection hooks #130
• Validation: add benchmark harness and cross-runtime contract checks #131
• Tools: expose gametau projects through an MCP server #133
• Metadata: generate stable project and command manifests for gametau apps #134
• CLI: add machine-readable inspect/doctor/status commands for automation #135
• Validation: add deterministic headless gameplay checks for agent workflows #136
• Tracking: agent-friendly and LLM-first gametau tooling #138
• Macros/tooling: emit command metadata and optional typed clients from webtau commands #139
• CLI/tooling: add repro bundle and replay workflow for debugging #140
• create-gametau/tooling: add template-aware upgrade and sync workflow #143
• Runtime/tooling: add a headless simulation service mode for automation #145
• Runtime/tooling: add a structured state-inspection surface for automation #148
• CLI/tooling: add a machine-readable project health report #152

[devallibus]

Derived follow-up issues from this strategy thread:

• Docs/strategy: clarify gametau positioning, target app class, and non-goals #155 clarify positioning, target app class, and non-goals
• API design: separate command, query, job, and authority semantics #156 separate command/query/job/authority semantics
• Docs/tooling: publish browser-shipping constraints and data-tiering guidance #157 define support tiers and stability labels
• Product policy: define support tiers and stability labels for runtimes and public surfaces #158 publish browser-shipping constraints and data-tiering guidance