diff --git a/Codex/Portal/DECISIONS.md b/Codex/Portal/DECISIONS.md
index e9b5a98..0a9e0a3 100644
--- a/Codex/Portal/DECISIONS.md
+++ b/Codex/Portal/DECISIONS.md
@@ -2,17 +2,23 @@
 
 ## Settled
 - 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.
 - `agentStatus === online` is not enough by itself for game action eligibility.
 - `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.
+- 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.
+- 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.
+- 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.
 - Portal is now tracked on a Node 24 baseline aligned with the API runtime line.
 - Portal linting should use the current ESLint / Next 16-compatible path rather than removed `next lint` behavior.
 - confirmed-unused HUD wrapper components and stale legacy CSS should stay removed rather than being reintroduced as dead scaffolding.
 - runtime/tooling cleanup is allowed when it preserves user-visible behavior and keeps lint/build green.
 - Portal should preserve compatibility with API auth and hosted IDE flows even when API token verification is tightened.
-- password reset request UX must remain account-enumeration safe: the user-facing success copy is generic and must not show account-not-found state.
-- reset-password confirmation must not auto-login; successful reset should direct the user to log in again.
-- authenticated profile password changes use `POST /api/auth/change-password` with `{ currentPassword, newPassword }`.
+- dashboard summary/spotlight UI should be backed by real API data and should not advertise routes that Portal does not actually implement.
+- onboarding tour targets must stay aligned with the real navigation structure.
+- billing, profile, and similar authenticated account surfaces should stay within the hub/dashboard shell unless there is a deliberate UX reason not to.
 
 ## Tracking rule
 - when Portal work completes, remove it from `OPEN_ITEMS.md`