The Phase 27 BattleViewer was the last UI surface still issuing raw
fetch() against the backend REST contract (`/api/v1/user/games/...
/battles/...`). The dev-deploy gateway never proxied that path, so
the viewer worked only in tools/local-dev/. Move it onto the signed
ConnectRPC channel every other authenticated surface already uses.
Wire pieces:
- FBS GameBattleRequest in pkg/schema/fbs/battle.fbs, regenerated
Go + TS bindings.
- MessageTypeUserGamesBattle constant + GameBattleRequest struct in
pkg/model/report/messages.go.
- pkg/transcoder/battle.go gains GameBattleRequestToPayload and
PayloadToGameBattleRequest helpers.
- gateway games_commands.go switches on the new message type and
GETs /api/v1/user/games/{id}/battles/{turn}/{battle_id}; the JSON
response is re-encoded as a FlatBuffers BattleReport before being
returned. 404 from backend surfaces as the canonical `not_found`
gateway error.
- ui/frontend/src/api/battle-fetch.ts now builds the FBS request,
calls GalaxyClient.executeCommand, and decodes the FBS response
into the existing UI shape (Record<string,string> race/ship maps,
string-form UUID). BattleFetchError carries an HTTP-style status
derived from the result code so the active-view's not_found branch
keeps working.
- battle.svelte pulls the GalaxyClient from the in-game shell
context. While the layout's boot Promise.all is in flight the
effect stays in `loading` until the client handle becomes
non-null.
- ui/Makefile FBS_INPUTS gains battle.fbs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The owner reported two symptoms after pulling the Phase 14 stack:
1. user.games.order.get answered with `unimplemented: message_type
is not routed`. The gateway/backend code was correct, but the
local-dev compose images were stale — `make rebuild` picked up
the new routes table and the symptom went away. To prevent this
class of regression from depending on docker-image freshness,
gateway/internal/backendclient/routes_test.go now asserts that
every authenticated MessageType constant declared in
pkg/model/{user,lobby,order,report} is registered, and verifies
that user.games.order.get specifically resolves to the game
command client.
2. The inspector kept the un-renamed name after a successful submit.
ui/frontend/tests/inspector-overlay.test.ts mounts the inspector
tab against a real OrderDraftStore + a stubbed GameStateStore
and walks the full happy path (add planetRename → markSubmitting
→ applied → simulate refresh) plus the integration scenario
driven through the order-tab Submit button. Both cases pass —
the underlying overlay path is reactive and resilient to a
refresh that returns the un-renamed snapshot. The original
in-browser symptom was the rebuilt-image freshness issue from
point 1; this test pins the reactive contract for future
refactors.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Ilia Denisov