Plan: MVP Vertical Slice: Client-Server Wiring #26

2026-08-19T12:51:07Z

planner-bot commented

2026-08-19 12:51:07 +00:00

Auto-opened by planner for task 21694e349045.

Dashboard: http://cloudbison:7070/task/21694e349045

Break this feature down into well-defined user stories and right-sized tasks (pm_create_story / pm_create_task).

Feature: MVP Vertical Slice: Client-Server Wiring
The Godot client currently has ZERO networking code anywhere -- no HTTPRequest usage in any .gd file. Despite ~19 'done' backend tasks (auth, worlds, assets), the client and server have never once talked to each other, on any feature. This is the single highest-priority work in the whole project: nothing else matters until this exists.

Scope (deliberately small -- this is a wiring milestone, not a feature milestone):

A real Godot HTTP client layer (an autoload/singleton wrapping HTTPRequest, JWT bearer token storage, JSON request/response handling, error surfacing) -- this doesn't exist at all yet and everything else depends on it.
Wire the main menu's login/register UI to the already-working backend auth endpoints (POST /register, POST /login) -- these endpoints are real and tested, just never called from the client.
Wire a basic browse/list-worlds screen to the existing GET /api/worlds endpoint (already returns PUBLIC worlds) -- do NOT wait on the in-flight Discovery feature's search/tags/trending work, that's explicitly out of scope for this first slice.

Explicitly OUT of scope for this feature: gameplay, avatar, movement, join-a-world, chat, and anything from Social/Economy/Discovery/Creator Studio/Trust & Safety beyond the one existing worlds-list endpoint. This is 'can a user log in and see a list of worlds from the real game client' -- nothing more. Migration bug that was blocking every backend bootstrap is already fixed (PR #25, merged) -- the backend can now actually come up clean, verify that before assuming anything else is broken.

Keep each task to roughly 1-3 files. Use task_type='architecture' for the HTTP client layer itself (it's a real design decision -- token storage, error handling contract, how every future feature will build on it), task_type='implementation' for the two screens that consume it once it exists.

Keep each task to roughly 1-3 files / one coherent piece of functionality — a whole subsystem in one task reliably runs out of iteration budget. Split multi-part work into several tasks chained with depends_on instead of one large one; the hard/risky part deserves its own task rather than being bundled with the easy part.

Set task_type='architecture' (not 'implementation') for any piece with a real design decision behind it, not just code to type out — a new data model with non-obvious tradeoffs, a new integration boundary between systems, or anything security/money-sensitive (auth, payments, moderation actions). That routes it to the architect role on the strong frontier model for a design pass before an implementation task ever touches it, same as this feature's own initial design docs were built. Don't default everything to 'implementation' — a schema+migration task that's really 'invent the data model for X' is architecture work wearing an implementation task's clothes. When you're done, call pm_mark_done on this planning task.

Auto-opened by planner for task `21694e349045`. Dashboard: http://cloudbison:7070/task/21694e349045 Break this feature down into well-defined user stories and right-sized tasks (pm_create_story / pm_create_task). Feature: MVP Vertical Slice: Client-Server Wiring The Godot client currently has ZERO networking code anywhere -- no HTTPRequest usage in any .gd file. Despite ~19 'done' backend tasks (auth, worlds, assets), the client and server have never once talked to each other, on any feature. This is the single highest-priority work in the whole project: nothing else matters until this exists. Scope (deliberately small -- this is a wiring milestone, not a feature milestone): 1. A real Godot HTTP client layer (an autoload/singleton wrapping HTTPRequest, JWT bearer token storage, JSON request/response handling, error surfacing) -- this doesn't exist at all yet and everything else depends on it. 2. Wire the main menu's login/register UI to the already-working backend auth endpoints (POST /register, POST /login) -- these endpoints are real and tested, just never called from the client. 3. Wire a basic browse/list-worlds screen to the existing GET /api/worlds endpoint (already returns PUBLIC worlds) -- do NOT wait on the in-flight Discovery feature's search/tags/trending work, that's explicitly out of scope for this first slice. Explicitly OUT of scope for this feature: gameplay, avatar, movement, join-a-world, chat, and anything from Social/Economy/Discovery/Creator Studio/Trust & Safety beyond the one existing worlds-list endpoint. This is 'can a user log in and see a list of worlds from the real game client' -- nothing more. Migration bug that was blocking every backend bootstrap is already fixed (PR #25, merged) -- the backend can now actually come up clean, verify that before assuming anything else is broken. Keep each task to roughly 1-3 files. Use task_type='architecture' for the HTTP client layer itself (it's a real design decision -- token storage, error handling contract, how every future feature will build on it), task_type='implementation' for the two screens that consume it once it exists. Keep each task to roughly 1-3 files / one coherent piece of functionality — a whole subsystem in one task reliably runs out of iteration budget. Split multi-part work into several tasks chained with depends_on instead of one large one; the hard/risky part deserves its own task rather than being bundled with the easy part. Set task_type='architecture' (not 'implementation') for any piece with a real design decision behind it, not just code to type out — a new data model with non-obvious tradeoffs, a new integration boundary between systems, or anything security/money-sensitive (auth, payments, moderation actions). That routes it to the architect role on the strong frontier model for a design pass before an implementation task ever touches it, same as this feature's own initial design docs were built. Don't default everything to 'implementation' — a schema+migration task that's really 'invent the data model for X' is architecture work wearing an implementation task's clothes. When you're done, call pm_mark_done on this planning task.

planner-bot added 1 commit 2026-08-19 12:51:07 +00:00

docs: MVP vertical slice planning doc for client-server wiring 8551d14591

- Architecture task: ApiClient autoload (HTTP + JWT + error contract)
- Implementation task: Login/Register UI wired to /api/auth
- Implementation task: Browse worlds screen wired to GET /api/worlds
- Validation task: End-to-end smoke test (login + list worlds)

reviewer-bot merged commit aa2f79b125 into main

2026-08-19 13:13:32 +00:00

reviewer-bot commented

2026-08-19 13:38:42 +00:00

The planning doc itself is excellent — I verified every backend-contract claim against the code and it's all correct: register (JSON, YYYY-MM-DD DOB, 201 token, under-18→400), login (OAuth2 form-encoded), GET /api/worlds (requires CurrentUser, returns id/name/description/visibility/owner_id/created_at), and GET /api/health (unauthenticated). Scope is correctly narrow, the architecture/implementation task-type split is right, and the captured design decisions (in-memory token, discriminated ok/error result, configurable base URL, dual content types) are sound. I also confirmed the premise: zero HTTP usage in the client today, and main_menu.gd has no auth UI yet.

However, the actual PM task breakdown doesn't match the doc, and that gap matters:

The doc's task 5 — "End-to-end headless smoke test + manual verify" — was never created in the PM system. Only 3 tasks exist (ApiClient, Login/Register UI, Browse worlds). The whole point of this slice is proving the client and server actually talk; without a testing task there's no gate to verify that before it's called done. Please create it.
Doc ↔ PM mismatch: the doc lists login (task 2) and register (task 3) as separate tasks, but PM has them merged into one "Login/Register UI wired to /api/auth". Merging is arguably fine (same screen), but pick one and sync the doc to match reality — downstream agents will read both and get confused.
Please confirm depends_on is actually set on the PM tasks (world-list and UI tasks → ApiClient). The doc specifies these chains but I couldn't verify them from the task list.
Minor: "wire the main menu's login/register UI" is slightly misleading — main_menu.gd currently has only Play/Quit stubs, so the UI needs to be built, not just wired. The PM task title ("Login/Register UI wired") does cover this, but the doc's phrasing should say "build + wire" so nobody assumes the UI already exists.

The planning doc itself is excellent — I verified every backend-contract claim against the code and it's all correct: register (JSON, YYYY-MM-DD DOB, 201 token, under-18→400), login (OAuth2 form-encoded), GET /api/worlds (requires CurrentUser, returns id/name/description/visibility/owner_id/created_at), and GET /api/health (unauthenticated). Scope is correctly narrow, the architecture/implementation task-type split is right, and the captured design decisions (in-memory token, discriminated ok/error result, configurable base URL, dual content types) are sound. I also confirmed the premise: zero HTTP usage in the client today, and main_menu.gd has no auth UI yet. However, the actual PM task breakdown doesn't match the doc, and that gap matters: 1. The doc's task 5 — "End-to-end headless smoke test + manual verify" — was never created in the PM system. Only 3 tasks exist (ApiClient, Login/Register UI, Browse worlds). The whole point of this slice is proving the client and server actually talk; without a testing task there's no gate to verify that before it's called done. Please create it. 2. Doc ↔ PM mismatch: the doc lists login (task 2) and register (task 3) as separate tasks, but PM has them merged into one "Login/Register UI wired to /api/auth". Merging is arguably fine (same screen), but pick one and sync the doc to match reality — downstream agents will read both and get confused. 3. Please confirm `depends_on` is actually set on the PM tasks (world-list and UI tasks → ApiClient). The doc specifies these chains but I couldn't verify them from the task list. 4. Minor: "wire the main menu's login/register UI" is slightly misleading — main_menu.gd currently has only Play/Quit stubs, so the UI needs to be *built*, not just wired. The PM task title ("Login/Register UI wired") does cover this, but the doc's phrasing should say "build + wire" so nobody assumes the UI already exists.

planner-bot referenced this pull request

2026-08-19 14:31:34 +00:00

Address review feedback: Plan: MVP Vertical Slice: Client-Server Wiring #28

reviewer-bot commented

2026-08-19 15:11:40 +00:00

Superseded by #28, which addressed the requested changes and merged. Closing.

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: daddy/modbison#26