jester/zlh-grind
1
0
Fork 0
Code Issues 14 Pull Requests Actions Packages Projects Releases Wiki Activity

Record Portal API boundary decisions

Browse Source
This commit is contained in:
jester 2026-04-30 19:22:06 +00:00
parent d05651f51c
commit bbd8098088
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
Codex/Portal/DECISIONS.md
View File

@ -1,14 +1,19 @@
# Portal — Decisions # Portal - Decisions
## Settled ## Settled
- Portal should consume API-normalized state, not talk directly to agents for normal status/actions. - Portal should consume API-normalized state, not talk directly to agents for normal status/actions.
- Portal should not keep fallback direct-agent bridges in the frontend repo once the API owns the supported route. - Portal should not keep fallback direct-agent bridges in the frontend repo once the API owns the supported route.
- Portal must never add or expose `INTERNAL_API_TOKEN` in browser/client code.
- Portal server deletion should use `DELETE /api/servers/{id}` with the logged-in user's JWT, not the legacy `DELETE /api/containers/{vmid}` path.
- Portal delete UX should map API responses explicitly, including `409` as `Stop host before deleting`.
- `agentStatus === online` is not enough by itself for game action eligibility. - `agentStatus === online` is not enough by itself for game action eligibility.
- `ready === false` does not automatically mean a stopped server is unstartable. - `ready === false` does not automatically mean a stopped server is unstartable.
- Portal should not infer `Needs attention` from `connectable === false`; it must prefer specific API/host/operation states before falling back to error labels. - Portal should not infer `Needs attention` from `connectable === false`; it must prefer specific API/host/operation states before falling back to error labels.
- game-server readiness and dev-container readiness should remain separate because DEV status is host/agent/IDE oriented while GAME status is game service/connectability oriented. - game-server readiness and dev-container readiness should remain separate because DEV status is host/agent/IDE oriented while GAME status is game service/connectability oriented.
- host/container lifecycle actions should be represented as accepted asynchronous operations and polled through API-owned host status rather than treated as completed immediately. - host/container lifecycle actions should be represented as accepted asynchronous operations and polled through API-owned host status rather than treated as completed immediately.
- server creation progress should be shown on the Servers surface with user-facing phases rather than leaving the user on the create form without progress context. - server creation progress should be shown on the Servers surface with user-facing phases rather than leaving the user on the create form without progress context.
- creation progress may begin before the API returns a VMID, but once the VMID exists Portal should reconcile the pending marker to the real server id.
- stopped/stopping host lifecycle states should not be presented as fresh `creating` or `installing` setup work.
- IDE controls should stay compact and colocated with IDE readiness indicators on console and server-list surfaces. - IDE controls should stay compact and colocated with IDE readiness indicators on console and server-list surfaces.
- backup actions should not be blocked purely by frontend readiness assumptions when backend can decide validity. - backup actions should not be blocked purely by frontend readiness assumptions when backend can decide validity.
- Portal is now tracked on a Node 24 baseline aligned with the API runtime line. - Portal is now tracked on a Node 24 baseline aligned with the API runtime line.