feat(account): route Profile to custom React component

Author: os-zhuang

.changeset/account-profile-custom-renderer.md

@@ -0,0 +1,38 @@
+---
+'@objectstack/platform-objects': patch
+---
+
+Account App: route Profile to a custom React component instead of the
+generic sys_user record page.
+
+The Account App's `nav_account_profile` entry switched from
+`type: 'object'` (sys_user record, current user id) to
+`type: 'component'` with `componentRef: 'account:profile_card'`.
+End users now see a settings-form-style "My Profile" card
+(avatar / name / password / SSO recovery) registered by the Console
+runtime, while the `sys_user` slotted record page (`SysUserDetailPage`)
+is unchanged and remains the admin view reached from Setup → Users.
+
+This is a behavioural change for any Studio override that mutates
+`nav_account_profile`: the entry no longer has `objectName`,
+`recordId`, or `requiresObject`. Override consumers should drop
+those fields and target `componentRef: 'account:profile_card'`
+(or restore the previous nav item type explicitly).
+
+Requires a Console build that registers `account:profile_card`
+(included in the matching `@object-ui/console` release pinned via
+`.objectui-sha`).
+
+Verified end-to-end: login → Account App → 个人资料 sidebar item
+→ `/_console/apps/account/component/account/profile_card` renders
+the React Profile card; editing Name and clicking Save Changes
+POSTs `/api/v1/auth/update-user` (200) and persists.
+
+The upstream `@object-ui/console` release also fixes a latent
+`useState` bug in the same ProfilePage: when mounted under
+`<Suspense>` before `AuthProvider` resolves, `user` is null on
+first render and `setName(user?.name ?? '')` initialised to `''`
+with no follow-up sync. A `useEffect` now mirrors `user.name`
+into local state. This was masked when the page was only reached
+via the System Hub route (where `AuthGuard` ensured user was
+already loaded) and is exposed by the new mount path.

packages/platform-objects/src/apps/account.app.ts

@@ -45,21 +45,20 @@ export const ACCOUNT_APP: App = {
   // manage their own 2FA / linked accounts / personal OAuth apps. RLS on
   // each object scopes rows to the caller.
   navigation: [
-    // Profile is the canonical landing — name, email, avatar, verification
-    // status. Uses `type: 'object' + recordId: '{current_user_id}'` so it
-    // resolves to the sys_user record page; the slotted SysUserDetailPage
-    // (kind: 'slotted', isDefault: true) tailors that page into a proper
-    // self-service profile (highlight chips, grouped detail sections, no
-    // Discussion thread) without losing the record-context features
-    // (related lists, header actions, RLS-aware edit).
+    // Profile is the canonical landing — a hand-written React settings card
+    // (Vercel/Linear style) registered in the Console SPA as
+    // `account:profile_card`. The renderer reads the current user via
+    // `useAuth()` and writes via `client.auth.updateUser`, so there is no
+    // sys_user record context here — this is intentional. The admin-facing
+    // sys_user record page (see `pages/sys-user.page.ts`) stays focused on
+    // record browsing (Identity/Audit fields, related lists, admin actions)
+    // and is reached through Setup, never from the Account App.
     {
       id: 'nav_account_profile',
-      type: 'object',
+      type: 'component',
       label: 'Profile',
-      objectName: 'sys_user',
-      recordId: '{current_user_id}',
+      componentRef: 'account:profile_card',
       icon: 'user-circle',
-      requiresObject: 'sys_user',
     },
 
     // --- Inbox & work assigned to me -----------------------------------

packages/platform-objects/src/pages/sys-user.page.ts

@@ -5,9 +5,14 @@ import type { Page } from '@objectstack/spec/ui';
 /**
  * sys_user — Record Detail Page (slotted, default for ALL sys_user records)
  *
- * Tailors the synthesized admin form into a layout that works for both:
- *   • the end user landing on their own profile from the Account App, and
- *   • an admin opening someone else's user record from Setup.
+ * **Audience**: admins browsing user records from Setup.
+ *
+ * The Account App's "Profile" entry no longer routes here — it points at
+ * the `account:profile_card` Console component for a settings-form-style
+ * personal profile. This page therefore optimizes for the admin
+ * use case: scanning a user's signals (email/verification/2FA/role),
+ * reviewing related sessions/orgs/oauth/api-keys, and triggering
+ * admin actions (ban / impersonate / set_role).
  *
  * Strategy
  * --------