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

[READY][Architecture] #311-A Map and isolate FupOgFakta-specific logic currently living in lobby/ #312

New Issue
Open
opened 2026-03-16 19:51:08 +01:00 by architecture-bot · 0 comments
architecture-bot commented 2026-03-16 19:51:08 +01:00
Owner
Copy Link

Parent issue: #311

Problem statement

Before moving code safely, we need one explicit inventory of which parts of lobby/ are actually FupOgFakta-specific. Right now phase/state helpers, transition endpoints, and response contracts are mixed into the platform layer.

Expected value / why now

This creates a safe extraction map instead of a vague “move stuff later” intention. It reduces the risk of partial refactors that leave hidden game logic behind in lobby/.

Acceptance criteria

  • Identify the concrete FupOgFakta-specific helpers, endpoints, response builders, and phase-transition logic currently living in lobby/.
  • Distinguish them from truly generic platform/session concerns.
  • Produce one documented extraction map that names source files/functions and intended destination/module ownership.
  • Reference the existing cartridge-plan docs that describe the intended lobby vs fupogfakta boundary.
  • PR/issue output references #311 and states what is generic platform vs game-specific logic.

Scope boundary

  • Not the full code move itself.
  • Not frontend rewrite.
  • Not support for a second game yet.
Parent issue: #311 ## Problem statement Before moving code safely, we need one explicit inventory of which parts of `lobby/` are actually FupOgFakta-specific. Right now phase/state helpers, transition endpoints, and response contracts are mixed into the platform layer. ## Expected value / why now This creates a safe extraction map instead of a vague “move stuff later” intention. It reduces the risk of partial refactors that leave hidden game logic behind in `lobby/`. ## Acceptance criteria - Identify the concrete FupOgFakta-specific helpers, endpoints, response builders, and phase-transition logic currently living in `lobby/`. - Distinguish them from truly generic platform/session concerns. - Produce one documented extraction map that names source files/functions and intended destination/module ownership. - Reference the existing cartridge-plan docs that describe the intended `lobby` vs `fupogfakta` boundary. - PR/issue output references #311 and states what is generic platform vs game-specific logic. ## Scope boundary - Not the full code move itself. - Not frontend rewrite. - Not support for a second game yet.
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#312
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?