wpp/weirsoe-party-protocol
8
0
Fork 0
Code Issues 19 Pull Requests Actions Packages Projects Releases Wiki Activity

[Need-to-have][Architecture] Restore game-cartridge boundary: move FupOgFakta-specific flow out of lobby and under fupogfakta #311

New Issue
Open
opened 2026-03-16 19:46:34 +01:00 by architecture-bot · 2 comments
architecture-bot commented 2026-03-16 19:46:34 +01:00
Owner
Copy Link

Parent epic: #287

Problem statement

The implementation has drifted away from the intended game-cartridge architecture. Right now, FupOgFakta-specific gameplay flow lives primarily in lobby/ endpoints and views, while fupogfakta/ mostly contains models/admin. That means the so-called platform layer currently owns concrete lie -> guess -> reveal -> scoreboard behaviour.

This is a problem even for MVP:

  • lobby is no longer a generic session/platform layer
  • future games with different phase models will either be forced into FupOgFakta-shaped endpoints or require expensive late refactoring
  • the current code placement hides domain ownership and makes the boundary between platform vs game logic unclear

This also appears to violate the intended architecture described in:

  • docs/plans/2026-03-09-fupogfakta-game-engine-design.md
  • docs/plans/2026-03-09-fupogfakta-implementation-plan.md

Both documents describe lobby/ as platform/session layer and fupogfakta/ as the first self-contained game cartridge that owns its phase logic.

Expected value / why now

We are now close enough to a playable build that continuing to add more gameplay-specific logic in lobby/ will make the eventual separation harder and risk locking the MVP into the wrong shape.

Fixing the ownership boundary now provides:

  • a clearer MVP architecture
  • safer path to future multi-game support
  • less hidden coupling between frontend, realtime, and the current FupOgFakta phase model
  • better domain ownership: FupOgFakta rules live with the FupOgFakta app

Acceptance criteria

  • Document the target boundary between lobby (platform/session shell) and fupogfakta (game cartridge / game engine).
  • Identify which current endpoints, helpers, and phase-transition logic in lobby/ are FupOgFakta-specific and should move.
  • Move FupOgFakta-specific gameplay logic out of lobby/ and under fupogfakta/ (or an explicit game-cartridge layer) without breaking the current playable path.
  • Preserve a thin generic platform responsibility in lobby: session container, join/create, host/player shell entry, generic session metadata, and routing into a game cartridge.
  • Ensure the resulting structure makes it possible for a future game with a different flow to plug in without adding FupOgFakta-specific branching into lobby.
  • Update tests/docs to reflect the corrected architecture.

Scope boundary

  • Not a demand to finish a fully generic plugin ecosystem right now.
  • Not a rewrite of the whole frontend before gameplay remains testable.
  • Not post-MVP multi-game features themselves.
  • The goal is to restore the intended ownership boundary and stop further gameplay logic from accreting in the platform layer.

Suggested decomposition

  1. Architecture note / boundary decision
  2. Extract gameplay-specific phase/state helpers from lobby into fupogfakta
  3. Re-point endpoints/service layer so lobby becomes a shell/orchestrator instead of the concrete game engine
  4. Verify current canonical loop still works after the move
Parent epic: #287 ## Problem statement The implementation has drifted away from the intended game-cartridge architecture. Right now, FupOgFakta-specific gameplay flow lives primarily in `lobby/` endpoints and views, while `fupogfakta/` mostly contains models/admin. That means the so-called platform layer currently owns concrete `lie -> guess -> reveal -> scoreboard` behaviour. This is a problem even for MVP: - `lobby` is no longer a generic session/platform layer - future games with different phase models will either be forced into FupOgFakta-shaped endpoints or require expensive late refactoring - the current code placement hides domain ownership and makes the boundary between platform vs game logic unclear This also appears to violate the intended architecture described in: - `docs/plans/2026-03-09-fupogfakta-game-engine-design.md` - `docs/plans/2026-03-09-fupogfakta-implementation-plan.md` Both documents describe `lobby/` as platform/session layer and `fupogfakta/` as the first self-contained game cartridge that owns its phase logic. ## Expected value / why now We are now close enough to a playable build that continuing to add more gameplay-specific logic in `lobby/` will make the eventual separation harder and risk locking the MVP into the wrong shape. Fixing the ownership boundary now provides: - a clearer MVP architecture - safer path to future multi-game support - less hidden coupling between frontend, realtime, and the current FupOgFakta phase model - better domain ownership: FupOgFakta rules live with the FupOgFakta app ## Acceptance criteria - Document the target boundary between `lobby` (platform/session shell) and `fupogfakta` (game cartridge / game engine). - Identify which current endpoints, helpers, and phase-transition logic in `lobby/` are FupOgFakta-specific and should move. - Move FupOgFakta-specific gameplay logic out of `lobby/` and under `fupogfakta/` (or an explicit game-cartridge layer) without breaking the current playable path. - Preserve a thin generic platform responsibility in `lobby`: session container, join/create, host/player shell entry, generic session metadata, and routing into a game cartridge. - Ensure the resulting structure makes it possible for a future game with a different flow to plug in without adding FupOgFakta-specific branching into `lobby`. - Update tests/docs to reflect the corrected architecture. ## Scope boundary - Not a demand to finish a fully generic plugin ecosystem right now. - Not a rewrite of the whole frontend before gameplay remains testable. - Not post-MVP multi-game features themselves. - The goal is to restore the intended ownership boundary and stop further gameplay logic from accreting in the platform layer. ## Suggested decomposition 1. Architecture note / boundary decision 2. Extract gameplay-specific phase/state helpers from `lobby` into `fupogfakta` 3. Re-point endpoints/service layer so `lobby` becomes a shell/orchestrator instead of the concrete game engine 4. Verify current canonical loop still works after the move
architecture-bot commented 2026-03-16 19:51:08 +01:00
Author
Owner
Copy Link

Architect decomposition for the cartridge-boundary fix:

  • #312 [READY][Architecture] #311-A Map and isolate FupOgFakta-specific logic currently living in lobby/
  • #313 [READY][Architecture] #311-B Extract FupOgFakta phase/state engine from lobby into fupogfakta/
  • #314 [READY][Architecture] #311-C Reintroduce explicit GameDriver/GameRun boundary or document the replacement contract

These child tasks are intended to keep the refactor concrete and tied back to the originally documented cartridge/game-driver architecture.

Architect decomposition for the cartridge-boundary fix: - #312 [READY][Architecture] #311-A Map and isolate FupOgFakta-specific logic currently living in lobby/ - #313 [READY][Architecture] #311-B Extract FupOgFakta phase/state engine from lobby into fupogfakta/ - #314 [READY][Architecture] #311-C Reintroduce explicit GameDriver/GameRun boundary or document the replacement contract These child tasks are intended to keep the refactor concrete and tied back to the originally documented cartridge/game-driver architecture.
architecture-bot commented 2026-03-16 20:28:07 +01:00
Author
Owner
Copy Link

Architect fast-progress wave added for immediate pickup:

  • #316 [READY][Gameplay] #287-G Extract canonical phase_view_model builder out of lobby.views hot path
  • #317 [READY][Gameplay] #287-H Add session-detail refresh contract tests for host/player route sync after phase events
  • #318 [READY][Architecture] #311-D Move one concrete FupOgFakta write endpoint out of lobby as the first cartridge slice

These are intentionally small, mergeable slices aimed at reducing coupling and speeding up current gameplay/architecture progress.

Architect fast-progress wave added for immediate pickup: - #316 [READY][Gameplay] #287-G Extract canonical phase_view_model builder out of lobby.views hot path - #317 [READY][Gameplay] #287-H Add session-detail refresh contract tests for host/player route sync after phase events - #318 [READY][Architecture] #311-D Move one concrete FupOgFakta write endpoint out of lobby as the first cartridge slice These are intentionally small, mergeable slices aimed at reducing coupling and speeding up current gameplay/architecture progress.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
PO vil have det her prioriteret
PO-prioriteret
 architect
Architect-owned coordination thread
 backend
Backend
 bot-task
Task managed by scheduler bots
 devops
DevOps/deploy related
 epic
Long-lived scope/phase tracking
 frontend
Frontend
 i18n
Internationalization
 mvp
auto by architect runner
 need-to-have
Required before merge/release
 needs-approval
Requires PO approval before execution
 nice-to-have
Improvement not blocking MVP
 release-approved
Architect approved release scope
 resolved
Løst og merged
 scope-guardrail
Scope and acceptance criteria source-of-truth
 smoke-fail
Smoke test failure
 spa
auto by architect runner
 staging
Staging infrastructure/deploy
 stale
Ingen aktivitet / forældet ift. main
 ui
Frontend/UI related
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
architecture-bot dev-bot email-manager integrator-bot manager-bot reviewer-bot scheduler-bot tester-bot
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wpp/weirsoe-party-protocol#311
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?