Stand up a standalone Bevy/Wasm shell without sim coupling #18

New issue

Closed

opened 2026-07-09 21:24:33 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-09 21:24:33 +00:00

Owner

Build and publish the first Bevy/Wasm app shell for factory-game-v3, deliberately without chaining it to the underlying Rust simulation yet.

Goal:

Prove the Rust/Bevy/Wasm app packaging path.
Keep it deployable as a static site.
Do not depend on factory_sim, factory_content, or factory_cli in this first shell.

This is an ops/build/deploy foundation, not gameplay integration. The shell may later become a factory viewer, but this issue should not wire it to sim state.

Implementation guidance:

Add a new workspace crate for the web shell, for example crates/factory_web or crates/factory_shell. Pick a name that makes it clear this is the deployable web app shell, not the simulation kernel.
Use Bevy for a minimal renderable app that works in native and WebAssembly builds.
The shell can render simple generated primitives/text only: title, background, status text, maybe a moving marker or basic scene proving Bevy renders.
Add Trunk or the repo-standard equivalent for wasm32-unknown-unknown static web packaging.
Add repo verbs in .ward/ward.yaml for native run and web build/serve if sensible.
Add a static-site container build/publish path if the repo has a conventional place for it. The deploy repo expects app repos to publish an image like the atlas pattern.
Update docs/FEATURES.md and any focused docs needed to describe the shell and commands.

Hard constraints:

The shell must not depend on factory_sim, factory_content, or factory_cli.
Do not move simulation rules into Bevy.
Do not wire the shell to the iron-bars scenario or JSON snapshots yet.
Do not add galaxy-generation concepts. Galaxy generation is a separate app concern.
Keep factory-game and galaxy-gen domain/runtime code independent. Similar ops/build/deploy shape is fine.

Acceptance criteria:

cargo test --workspace passes.
A native Bevy shell can be run locally through a ward verb or documented cargo command.
A Wasm/static build can be produced locally, preferably through Trunk.
The Wasm shell loads in a browser from static files and visibly renders a minimal Bevy scene.
The shell crate has no meaningful dependency on the simulation crates.
A static publish artifact or container image path is in place for the deploy repo to consume.
Docs state that this is a deployable shell only, with sim integration deferred.

Out of scope:

Factory simulation visualization.
Tick playback.
Inventory/dispatch UI.
Bevy ECS ownership of sim state.
Galaxy generation or galaxy viewer work.
Production art.

Related follow-up deployment work should use the atlas-style static-site pattern in coilyco-bridge/deploy, likely public at factory-game.coilysiren.me.

Build and publish the first Bevy/Wasm app shell for `factory-game-v3`, deliberately **without** chaining it to the underlying Rust simulation yet. Goal: * Prove the Rust/Bevy/Wasm app packaging path. * Keep it deployable as a static site. * Do not depend on `factory_sim`, `factory_content`, or `factory_cli` in this first shell. This is an ops/build/deploy foundation, not gameplay integration. The shell may later become a factory viewer, but this issue should not wire it to sim state. Implementation guidance: * Add a new workspace crate for the web shell, for example `crates/factory_web` or `crates/factory_shell`. Pick a name that makes it clear this is the deployable web app shell, not the simulation kernel. * Use Bevy for a minimal renderable app that works in native and WebAssembly builds. * The shell can render simple generated primitives/text only: title, background, status text, maybe a moving marker or basic scene proving Bevy renders. * Add Trunk or the repo-standard equivalent for `wasm32-unknown-unknown` static web packaging. * Add repo verbs in `.ward/ward.yaml` for native run and web build/serve if sensible. * Add a static-site container build/publish path if the repo has a conventional place for it. The deploy repo expects app repos to publish an image like the atlas pattern. * Update docs/FEATURES.md and any focused docs needed to describe the shell and commands. Hard constraints: * The shell must not depend on `factory_sim`, `factory_content`, or `factory_cli`. * Do not move simulation rules into Bevy. * Do not wire the shell to the iron-bars scenario or JSON snapshots yet. * Do not add galaxy-generation concepts. Galaxy generation is a separate app concern. * Keep factory-game and galaxy-gen domain/runtime code independent. Similar ops/build/deploy shape is fine. Acceptance criteria: * `cargo test --workspace` passes. * A native Bevy shell can be run locally through a ward verb or documented cargo command. * A Wasm/static build can be produced locally, preferably through Trunk. * The Wasm shell loads in a browser from static files and visibly renders a minimal Bevy scene. * The shell crate has no meaningful dependency on the simulation crates. * A static publish artifact or container image path is in place for the deploy repo to consume. * Docs state that this is a deployable shell only, with sim integration deferred. Out of scope: * Factory simulation visualization. * Tick playback. * Inventory/dispatch UI. * Bevy ECS ownership of sim state. * Galaxy generation or galaxy viewer work. * Production art. Related follow-up deployment work should use the atlas-style static-site pattern in `coilyco-bridge/deploy`, likely public at `factory-game.coilysiren.me`.

coilyco-ops commented

2026-07-09 21:24:56 +00:00

Author

Owner

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-factory-game-v3-18 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T21:24:54Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-gaming/factory-game-v3#18 · branch issue-18 · harness codex · workflow direct-to-main
Run: engineer-codex-factory-game-v3-18 · ward v0.493.0 · dispatched 2026-07-09T21:24:54Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-factory-game-v3-18` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T21:24:54Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-gaming/factory-game-v3#18` · branch `issue-18` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-factory-game-v3-18` · ward `v0.493.0` · dispatched `2026-07-09T21:24:54Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops added the

priority

autonomy

async-consult

labels

2026-07-10 09:00:59 +00:00