coilyco-gaming/factory-game-v3

Watch

Document the app boundary between factory-game and galaxy generation #17

New issue

Closed

opened 2026-07-09 21:06:52 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-09 21:06:52 +00:00

Owner

Capture the product boundary Kai clarified during planning: factory-game-v3 and galaxy generation should remain completely separate apps. This is a design/documentation task, not an implementation task.

Context:

factory-game-v3 is the programming-first factory/logistics simulation.
Recent planning discussed Bevy/Wasm viewer support for factory-game-v3.
The conversation then drifted into galaxy generation and Bevy. Kai clarified that those concerns should not be mixed: galaxy gen and factory gen are separate apps.
factory-game-v3#16 should be interpreted only as a future factory-game debug/observability viewer over factory_sim, not as a galaxy-gen viewer or shared app.

Design/documentation goal:

State the boundary clearly in factory-game-v3 planning docs or issue guidance.
Make clear that factory-game-v3 should not grow a factory_gen/galaxy-generation crate or assume ownership of galaxy generation.
Keep any future Bevy viewer for factory-game scoped to factory sim state: source/factory/hauler/dispatch/inventory/ticks.
Treat any galaxy generation app, Bevy galaxy viewer, galaxy seed exploration, star-system rendering, or galaxy resource distribution as separate repo/app work unless Kai explicitly creates a shared contract later.

Advisor deliverable:

Post a concise recommendation that separates the app boundaries.
Say whether any existing open issues should be renamed, closed, or annotated to avoid confusion.
Recommend how future cross-app contracts should be handled if the apps later need to exchange data, for example exported snapshots/schema rather than shared runtime coupling.

Out of scope:

Do not implement code.
Do not create or choose a galaxy-gen repo.
Do not redesign the current factory sim.
Do not merge galaxy concepts into factory-game.

Capture the product boundary Kai clarified during planning: `factory-game-v3` and galaxy generation should remain completely separate apps. This is a design/documentation task, not an implementation task. Context: * `factory-game-v3` is the programming-first factory/logistics simulation. * Recent planning discussed Bevy/Wasm viewer support for `factory-game-v3`. * The conversation then drifted into galaxy generation and Bevy. Kai clarified that those concerns should not be mixed: galaxy gen and factory gen are separate apps. * `factory-game-v3#16` should be interpreted only as a future factory-game debug/observability viewer over `factory_sim`, not as a galaxy-gen viewer or shared app. Design/documentation goal: * State the boundary clearly in `factory-game-v3` planning docs or issue guidance. * Make clear that `factory-game-v3` should not grow a `factory_gen`/galaxy-generation crate or assume ownership of galaxy generation. * Keep any future Bevy viewer for factory-game scoped to factory sim state: source/factory/hauler/dispatch/inventory/ticks. * Treat any galaxy generation app, Bevy galaxy viewer, galaxy seed exploration, star-system rendering, or galaxy resource distribution as separate repo/app work unless Kai explicitly creates a shared contract later. Advisor deliverable: * Post a concise recommendation that separates the app boundaries. * Say whether any existing open issues should be renamed, closed, or annotated to avoid confusion. * Recommend how future cross-app contracts should be handled if the apps later need to exchange data, for example exported snapshots/schema rather than shared runtime coupling. Out of scope: * Do not implement code. * Do not create or choose a galaxy-gen repo. * Do not redesign the current factory sim. * Do not merge galaxy concepts into factory-game.

coilyco-ops commented

2026-07-09 21:08:06 +00:00

Author

Owner

🔎 ward agent advisor

ward agent advisor --harness codex ran a one-shot standard research pass on this question:

Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue.

Recommendation

factory-game-v3 should document a hard app boundary: this repo owns the programming-first factory/logistics simulation and any future tooling that visualizes factory sim state only. It does not own galaxy generation, galaxy seed exploration, star-system rendering, or galaxy-scale resource distribution.

Decision to record

factory-game-v3 remains the home of factory_content, factory_sim, factory_cli, and any future debug or observability viewer for factory simulation state.
A future Bevy/Wasm viewer in this repo should be scoped to factory_sim data such as sources, factories, haulers, dispatch state, inventory, recipes, and ticks.
This repo should not grow a factory_gen crate, galaxy-generation crate, or shared runtime that assumes ownership of galaxy concerns.
Any galaxy-generation app or Bevy galaxy viewer should be treated as separate repo/app work unless Kai later defines an explicit cross-app contract.

Why this is the right boundary

The current repo surface already points this way. The checked-in docs describe a Bevy-free Rust workspace centered on factory_sim and a headless CLI, with simulation concepts limited to typed content IDs, dispatch, haulers, factories, inventory, and tick stepping.
Mixing galaxy generation into this repo would blur product ownership and make the current migration slice less coherent. It would also turn a focused factory-sim migration into a speculative shared-engine effort.
Keeping the boundary hard preserves a clean path for a future factory-game viewer without forcing shared runtime coupling with a separate galaxy app.

What to do with existing issues

#16 should stay open if its intent is the future factory-game debug/observability viewer over factory_sim.
#16 should be annotated to say explicitly that it is not a galaxy viewer, galaxy generator, or shared Bevy app.
#16 should be renamed only if its current title is ambiguous. A good direction would be wording like "Document or build a factory-sim debug viewer" rather than a generic "Bevy viewer" title.
#17 is the right place to capture the boundary decision itself. It should not fan out into separate child issues unless later work actually spans multiple repos.

Suggested wording for the boundary note

factory-game-v3 owns the factory/logistics simulation and any viewer that inspects factory simulation state. Galaxy generation, galaxy visualization, star-system rendering, and galaxy resource distribution are separate app concerns and do not belong in this repo unless an explicit cross-app contract is created later.

Options considered

Keep both factory and galaxy work in one Bevy app.
- Not recommended. It couples two product surfaces too early, muddies ownership, and invites shared runtime assumptions before any stable data contract exists.
Keep them separate apps with a future data contract.
- Recommended. It preserves product clarity now and still leaves room for later interoperability.

Open questions

Where should the boundary be recorded first: a planning doc, docs/FEATURES.md, or issue guidance around #16? My recommendation is to capture it in repo docs and annotate #16, because issue-only guidance is too easy to lose.
If the apps later need to exchange data, what is the contract shape?

Recommendation for any future cross-app contract

Prefer an exported snapshot/schema boundary, not shared runtime coupling.
Concretely, the factory app could emit versioned snapshots or schemas describing the factory state it wants to expose, and a separate galaxy app could consume its own independent inputs and outputs through similarly versioned artifacts.
If shared semantics become necessary, define them as a narrow versioned schema or protocol with ownership called out explicitly, rather than adding shared live crates across both apps by default.

Risks if this is not documented now

Future Bevy viewer work may drift into galaxy scope because "viewer" is too broad.
Engineers may infer that any procedural generation belongs here and start adding factory_gen or galaxy-adjacent crates without a product decision.
Later separation will be more expensive if runtime coupling forms before a contract is defined.

Bottom line

Post a repo-level clarification that factory-game-v3 is the factory sim app, not the galaxy app. Keep #16 alive only as a factory-sim viewer track, annotate it to remove galaxy ambiguity, and require any future interop to happen through a versioned exported data contract rather than a shared runtime.

Researched and posted automatically by ward agent advisor --harness codex (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Codex, via ward agent

### 🔎 ward agent advisor `ward agent advisor --harness codex` ran a one-shot **standard** research pass on this question: > Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue. --- **Recommendation** `factory-game-v3` should document a **hard app boundary**: this repo owns the programming-first factory/logistics simulation and any future tooling that visualizes **factory sim state only**. It does **not** own galaxy generation, galaxy seed exploration, star-system rendering, or galaxy-scale resource distribution. **Decision to record** - `factory-game-v3` remains the home of `factory_content`, `factory_sim`, `factory_cli`, and any future debug or observability viewer for factory simulation state. - A future Bevy/Wasm viewer in this repo should be scoped to `factory_sim` data such as sources, factories, haulers, dispatch state, inventory, recipes, and ticks. - This repo should **not** grow a `factory_gen` crate, galaxy-generation crate, or shared runtime that assumes ownership of galaxy concerns. - Any galaxy-generation app or Bevy galaxy viewer should be treated as **separate repo/app work** unless Kai later defines an explicit cross-app contract. **Why this is the right boundary** - The current repo surface already points this way. The checked-in docs describe a **Bevy-free** Rust workspace centered on `factory_sim` and a headless CLI, with simulation concepts limited to typed content IDs, dispatch, haulers, factories, inventory, and tick stepping. - Mixing galaxy generation into this repo would blur product ownership and make the current migration slice less coherent. It would also turn a focused factory-sim migration into a speculative shared-engine effort. - Keeping the boundary hard preserves a clean path for a future factory-game viewer without forcing shared runtime coupling with a separate galaxy app. **What to do with existing issues** - `#16` should stay open **if** its intent is the future factory-game debug/observability viewer over `factory_sim`. - `#16` should be **annotated** to say explicitly that it is **not** a galaxy viewer, galaxy generator, or shared Bevy app. - `#16` should be **renamed only if its current title is ambiguous**. A good direction would be wording like "Document or build a factory-sim debug viewer" rather than a generic "Bevy viewer" title. - `#17` is the right place to capture the boundary decision itself. It should not fan out into separate child issues unless later work actually spans multiple repos. **Suggested wording for the boundary note** > `factory-game-v3` owns the factory/logistics simulation and any viewer that inspects factory simulation state. Galaxy generation, galaxy visualization, star-system rendering, and galaxy resource distribution are separate app concerns and do not belong in this repo unless an explicit cross-app contract is created later. **Options considered** - Keep both factory and galaxy work in one Bevy app. - Not recommended. It couples two product surfaces too early, muddies ownership, and invites shared runtime assumptions before any stable data contract exists. - Keep them separate apps with a future data contract. - Recommended. It preserves product clarity now and still leaves room for later interoperability. **Open questions** - Where should the boundary be recorded first: a planning doc, `docs/FEATURES.md`, or issue guidance around `#16`? My recommendation is to capture it in repo docs **and** annotate `#16`, because issue-only guidance is too easy to lose. - If the apps later need to exchange data, what is the contract shape? **Recommendation for any future cross-app contract** - Prefer an **exported snapshot/schema boundary**, not shared runtime coupling. - Concretely, the factory app could emit versioned snapshots or schemas describing the factory state it wants to expose, and a separate galaxy app could consume its own independent inputs and outputs through similarly versioned artifacts. - If shared semantics become necessary, define them as a narrow versioned schema or protocol with ownership called out explicitly, rather than adding shared live crates across both apps by default. **Risks if this is not documented now** - Future Bevy viewer work may drift into galaxy scope because "viewer" is too broad. - Engineers may infer that any procedural generation belongs here and start adding `factory_gen` or galaxy-adjacent crates without a product decision. - Later separation will be more expensive if runtime coupling forms before a contract is defined. **Bottom line** Post a repo-level clarification that `factory-game-v3` is the **factory sim app**, not the galaxy app. Keep `#16` alive only as a factory-sim viewer track, annotate it to remove galaxy ambiguity, and require any future interop to happen through a versioned exported data contract rather than a shared runtime. --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 21:11:37 +00:00

Author

Owner

Clarification from Kai: the intended boundary is not “these projects must look unrelated.”

The boundary is domain/runtime/code ownership:

factory-game-v3 must not depend on galaxy-gen code in any meaningful way.
galaxy-gen must not depend on factory-game code in any meaningful way.
Neither app should assume the other app’s domain model or runtime.

The acceptable and expected similarity is ops/build/deploy structure because both may be Rust/Bevy/Wasm apps:

similar Cargo workspace conventions
similar ward verbs
similar native dev loop plus Wasm build target
similar Trunk/static artifact packaging if that becomes the chosen web path
similar CI/deploy conventions once the Wasm deploy pattern is established

So future guidance should say: converge on deployment architecture where useful, but keep domain architecture and runtime code independent.

Clarification from Kai: the intended boundary is not “these projects must look unrelated.” The boundary is **domain/runtime/code ownership**: * `factory-game-v3` must not depend on galaxy-gen code in any meaningful way. * galaxy-gen must not depend on factory-game code in any meaningful way. * Neither app should assume the other app’s domain model or runtime. The acceptable and expected similarity is **ops/build/deploy structure** because both may be Rust/Bevy/Wasm apps: * similar Cargo workspace conventions * similar `ward` verbs * similar native dev loop plus Wasm build target * similar Trunk/static artifact packaging if that becomes the chosen web path * similar CI/deploy conventions once the Wasm deploy pattern is established So future guidance should say: converge on deployment architecture where useful, but keep domain architecture and runtime code independent.

coilyco-ops added the

priority

autonomy

async-consult

labels

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

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

coilyco-ops referenced this issue from a commit

2026-07-21 04:41:21 +00:00

docs: record the factory-game vs galaxy-gen app boundary (closes #17)

coilyco-ops closed this issue

2026-07-21 04:41:21 +00:00

coilyco-ops commented

2026-07-21 04:41:32 +00:00

Author

Owner

Boundary recorded on main in 41d93eb: docs/app-boundary.md, linked from the AGENTS.md repo boundaries.

Advisor recommendations from the issue body, resolved:

Existing issues - no renames or closes needed. #16 already scopes itself to a factory_sim debug/observability viewer and #18 already carries the "no galaxy-generation concepts" hard constraint, so both are consistent with the boundary. #11's design brief predates the clarification but is a historical record, not guidance - the boundary doc now outranks it for scope questions.
Future cross-app contracts - exported artifacts over shared code. The JSONL tick snapshots and run summaries factory_cli already emits are the template: versioned schema files one app writes and another reads. A shared contract crate only if Kai explicitly creates one, and neither app ever reaches into the other's internals or runtime.
Guardrail placement - the rule lives in AGENTS.md (agents read it every session) with the reasoning in docs/app-boundary.md, so future Bevy issues cite a path instead of a conversation.

WARD-OUTCOME: done

Boundary recorded on `main` in `41d93eb`: [docs/app-boundary.md](https://forgejo.coilysiren.me/coilyco-gaming/factory-game-v3/src/branch/main/docs/app-boundary.md), linked from the AGENTS.md repo boundaries. Advisor recommendations from the issue body, resolved: * **Existing issues** - no renames or closes needed. #16 already scopes itself to a `factory_sim` debug/observability viewer and #18 already carries the "no galaxy-generation concepts" hard constraint, so both are consistent with the boundary. #11's design brief predates the clarification but is a historical record, not guidance - the boundary doc now outranks it for scope questions. * **Future cross-app contracts** - exported artifacts over shared code. The JSONL tick snapshots and run summaries `factory_cli` already emits are the template: versioned schema files one app writes and another reads. A shared contract crate only if Kai explicitly creates one, and neither app ever reaches into the other's internals or runtime. * **Guardrail placement** - the rule lives in AGENTS.md (agents read it every session) with the reasoning in docs/app-boundary.md, so future Bevy issues cite a path instead of a conversation. `WARD-OUTCOME: done`

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

coilyco-gaming/factory-game-v3#17

No description provided.

Rows
Columns