portal-mojo 0.2.4 → 0.2.6

package/docs/README.md

@@ -19,12 +19,14 @@ everything: run the showcase (`npm run dev:showcase`) → **Develop → Componen
 | [admin-monitoring.md](admin-monitoring.md) | Monitoring Admin registration, logs, and exact Redis-backed metrics-permission mutations |
 | [admin-metrics-explorer.md](admin-metrics-explorer.md) | Read-only recorded-metrics discovery, full-slug adapters, KPI/fan-out/scalar contracts, and cache identity |
 | [admin-settings.md](admin-settings.md) | Runtime settings admin — direction-aware atomic writes, write-only secrets, and global/group scope |
+| [admin-fleet-configuration.md](admin-fleet-configuration.md) | Superuser structured configuration publishing, version restore and per-node application evidence |
 | [admin-bouncer.md](admin-bouncer.md) | Bouncer decisions, device investigations, and bot-signature administration with token-safe caching |
 | [admin-security-tickets.md](admin-security-tickets.md) | Ticket queue, KISS detail modal, notes, approvals, and Maestro sync contract |
 | [admin-incidents.md](admin-incidents.md) | Incident/event triage, forensic detail, merge semantics, and sanitized export boundary |
 | [admin-rules.md](admin-rules.md) | Always-inactive RuleSet authoring and the lossless, runtime-effective handler-chain builder |
 | [admin-members.md](admin-members.md) | Global membership table/detail, no-oracle admission, extensible grants, Group-detail composition, and unsupported-operation boundaries |
 | [admin-identity-users.md](admin-identity-users.md) | Global Users table and 14-section detail, system gates, action contracts, and one-time credential invariants |
+| [admin-signin.md](admin-signin.md) | System sign-in page look & feel plus Google/Apple/GitHub provider credentials — one endpoint, changed-paths saves, write-only secrets |
 | [admin-devices-geoip.md](admin-devices-geoip.md) | Fleet device triage, the login-location world map with country drill-down, and the GeoIP dossier — expiry-aware enforcement, the never-cached raw provider record, and the backend traps the port encodes |
 | [admin-jobs.md](admin-jobs.md) | Jobs engine — runner fleet, per-channel queue depth, the segmented job table with armed cancel and republishing retry, the dry-run-first control plane, scheduled tasks with a global-only gate, and the thirteen backend corrections the port encodes |
 | [admin-network-security.md](admin-network-security.md) | Perimeter control — blocked IPs, the firewall log, kernel IP sets and the geofencing page (posture, rules, simulator, evidence, exemptions), with the DSL projection and every backend correction the port encodes |

package/docs/admin-fleet-configuration.md

@@ -0,0 +1,50 @@
+# Fleet Configuration
+
+The Operations → Fleet Configuration page uses `/api/account/admin/fleet`.
+Only literal superusers see the section. An empty permission any-of array uses
+the existing superuser bypass and refuses even the global `admin` grant; the
+page checks `is_superuser === true` before fetching. Backend authority remains
+mandatory, including rejection of diagnostic/key-backed sessions and fresh auth.
+
+Applications register their schema in django-mojo. The page renders the returned
+section, label, description, default, type and restart requirement; no application
+setting names are hardcoded. Each field defaults to Keep current value. Set value
+and Remove published override are explicit actions. Clearing falls back to base
+configuration/default; it does not promise erasure of a bootstrap secret.
+
+Secret inputs start blank, never hold masked placeholders, and blank replacement
+preserves the existing secret. Values stay in the form until an imperative POST;
+secret-bearing writes bypass TanStack MutationCache. Secret current/default fields
+are removed before Query cache storage. The revision-bound publish/restore/apply
+POSTs use `withFreshAuth` and show failures without claiming success. Schema/type
+validation is repeated by the server; browser validation is only feedback.
+
+Publication means published to S3, never applied. Apply now starts a fixed
+asynchronous sync operation and polls its ID until terminal operation status. The
+short job completes after dispatching sync; completed job status does not stop
+polling. Each operation read freshly observes activation until healthy or timed
+out; failed, expired or canceled jobs also stop polling. The expected
+node roster includes missing nodes. Installed, restart requested, restarted and
+healthy remain separate evidence. Only positive installed + restarted + health
+results from every expected node with the explicit
+`request_service_jobs_and_dependencies` health scope justify fleet completion.
+Missing or older health scopes remain unconfirmed, including per-node health and
+restart confirmation, and prompt a backend upgrade. Health covers the
+request service and dependencies where enabled, plus the job engine and scheduler
+with their startup-loaded revision. Worker-only nodes need no request service.
+Draining an old engine is not proof that its replacement has loaded the revision.
+Timed-out, failed, superseded and unknown results stay visible. Refresh status observes the
+normal timer workflow even when Apply now was not used.
+
+History contains only version IDs and timestamps. Restore publishes the selected
+version as a new revision using the current expected revision. Secrets are neither
+shown nor compared. Concurrent publication rejects the stale revision; refresh
+before retrying. Settings edits are tied to their loaded publication revision.
+
+Verify with `npm run verify:admin-fleet`, `npm run typecheck`, `npm run build`, and
+browser checks of both themes. The Settings showcase includes a partial-convergence
+example. Mock Portal uses representative registered settings and an offline node.
+
+Django receives this page only after a canonical Portal artifact is built and
+vendored; follow `docs/admin-artifact.md` and the Django vendor tool. Ordinary
+Vite build output is not the canonical artifact.

package/docs/admin-identity-directories-sources.json

@@ -0,0 +1,130 @@
+{
+  "package": "portal-mojo",
+  "package_version": "0.2.5",
+  "source_repository": "https://github.com/NativeMojo/portal-mojo",
+  "source_tag": "v0.2.5",
+  "source_commit": "93c7fdfeb3096d33010e72bd4483cf9ca6e3d6f5",
+  "license": "Apache-2.0",
+  "license_file": "packages/portal-mojo/LICENSE",
+  "files": [
+    {
+      "source_path": "apps/portal/src/group-permissions.ts",
+      "source_sha256": "6237ad45328ecb9637a1a07d8954dd27cd019e22fa32942f5e7d05a76037fb5c",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-permissions.ts",
+      "package_sha256": "b909f5a5cf029b8b910a70e6817fea8abd9ded6797af14a16170b2695c0c1699",
+      "adaptation": "Moves system-pinned group permission clauses into the canonical package identity surface."
+    },
+    {
+      "source_path": "apps/portal/src/models.ts",
+      "source_sha256": "0b98a906a774e572f9109703fe22444c3a2e190ca5e02c3a93dfbd02cc3fcb84",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/models.ts",
+      "package_sha256": "6ac12a64d00e409874bc1b13d7941cf54c38a715af5ebcfddd2b2e9257356759",
+      "adaptation": "Extracts the Group model/type and group kind options; shared User, Member and Log models remain owned by their package domains."
+    },
+    {
+      "source_path": "apps/portal/src/pages/ApiKeysPage.tsx",
+      "source_sha256": "3d338cf77c3110b72a9361565c1cced10a7fccc52c486e3dafda119d66c676b2",
+      "package_path": "packages/portal-mojo/src/admin/identity/users/PersonalApiKeysPage.tsx",
+      "package_sha256": "f377d8a97b5c0ccbce745c333fdd7e4a5fd5f5a89b868b058677b31e3efe64ff",
+      "adaptation": "Expanded row facts and actions are presented in a native DetailView modal that observes the current API key record."
+    },
+    {
+      "source_path": "apps/portal/src/pages/GroupDetail.tsx",
+      "source_sha256": "01a8a6032a59a337636ec28e5e2aef90717e5bc00656807135e02820a92a394b",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/GroupDetail.tsx",
+      "package_sha256": "e26943218e3e8f5ac79ddc7f1b0bd40736bcab0bd6e9c694e01830086349a4e2",
+      "adaptation": "Raw metadata is visible in the explicit Metadata section without a collapsible control."
+    },
+    {
+      "source_path": "apps/portal/src/pages/GroupsPage.tsx",
+      "source_sha256": "82e4aa5e7ebf67832bbd3bcf7e15dcfdeea64383039cc426591fa15262e4d4c8",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/GroupsPage.tsx",
+      "package_sha256": "e16f3d0630fdb1937cf667cd2abe8cd1aabc9bb2b731113112930e66bde2f1df",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/AuditSection.tsx",
+      "source_sha256": "49848f57e5050c0008aa83f7092af9abb8f55d262791a2591e525eaa6d741df4",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/AuditSection.tsx",
+      "package_sha256": "07a40636549a0a1d8636a115ee330313b84c0c82500890c6464301fd39de1e06",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/AuthConfigDialog.tsx",
+      "source_sha256": "f42e18a802f206a2b3f30248c30ad12887598b170deb73b532232a6bf89699dd",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/AuthConfigDialog.tsx",
+      "package_sha256": "e2280185bde7eab3ca7108f7d6da9e0e66c4f4d8323ec97f3fd7d49376932b65",
+      "adaptation": "Raw auth overrides remain visible in the explicit configuration dialog without collapsible content."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/EventsSection.tsx",
+      "source_sha256": "b8cb12ae99d7c8d5931a090b7be8ea4e0373ff4657e786094e9ac862167d43ec",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/EventsSection.tsx",
+      "package_sha256": "f0004605fbf7ceb2704adb42c0a3dd14dc5a468c445f0f94f2548fbc5f1bfeb4",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/GeofenceSection.tsx",
+      "source_sha256": "d0ce22f5ef922371d7a78c353e1a29e5d9ca4932e45814499e9c3cdeda7dc137",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/GeofenceSection.tsx",
+      "package_sha256": "227850a8ef844867ea55d599997144b462ee058967224c361dd821713d1b677a",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/IdentitySection.tsx",
+      "source_sha256": "cda776a26f1e21b73820ed88ab7dcbafdaf2b146c4c3ee4bf6b24dcbaeecc9f4",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/IdentitySection.tsx",
+      "package_sha256": "888ff5f7a70c80d8a868f13675b39af9a2a7076d6ea5fbc323493c0265ce9880",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/MembersSection.tsx",
+      "source_sha256": "dc2e99924b8ba856ce2ed48dffae082e98cac9ef78df3ddb1f05fe8a71f9725d",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/MembersSection.tsx",
+      "package_sha256": "abccb58bcdb62d0d1de2611cad080ca7237e0dfa781b10c5fc1d7e251398f628",
+      "adaptation": "Passes the group navigation callback into UserDetail to keep cross-record navigation available."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/OverviewSection.tsx",
+      "source_sha256": "fb395569018b89e6efd45cea241ba665b73efd15549802a6f0d98d90116ce894",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/OverviewSection.tsx",
+      "package_sha256": "08b460272af71ba6209fe388b71f37f79d94a9fecc21c0c2ee3abaf11f01372f",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/SubGroupsSection.tsx",
+      "source_sha256": "81074a2d74d80fda93e40379b87620807c31db7979736f90559e359bdafc0672",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/SubGroupsSection.tsx",
+      "package_sha256": "61e412e709afb4384fdcbaa1d8fbb6df6ba414634ecc6aaa8201c66cf722af93",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/auth-config.ts",
+      "source_sha256": "37d75dff84bca2577bcd1804c77aa0ef1519e4d913dcfdf7914266045fdbabe6",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/auth-config.ts",
+      "package_sha256": "37d75dff84bca2577bcd1804c77aa0ef1519e4d913dcfdf7914266045fdbabe6",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/geofence-data.ts",
+      "source_sha256": "169d5feb72fbe16a0463d591328ce49963e95f1bc0f5f7e5fa9ed271a5ace8e6",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/geofence-data.ts",
+      "package_sha256": "169d5feb72fbe16a0463d591328ce49963e95f1bc0f5f7e5fa9ed271a5ace8e6",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/models.ts",
+      "source_sha256": "ec6a2fd700a0a91e8f1d9e49c364ffe5466db340b435004971e719da08b49371",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/models.ts",
+      "package_sha256": "ec6a2fd700a0a91e8f1d9e49c364ffe5466db340b435004971e719da08b49371",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    },
+    {
+      "source_path": "apps/portal/src/pages/group-sections/shared.ts",
+      "source_sha256": "68aa819b14edcbbd8ae399d5c5a74360cc50ffd281b6d0d3be1c4f8ebc4e4f6c",
+      "package_path": "packages/portal-mojo/src/admin/identity/groups/group-sections/shared.ts",
+      "package_sha256": "68aa819b14edcbbd8ae399d5c5a74360cc50ffd281b6d0d3be1c4f8ebc4e4f6c",
+      "adaptation": "Moved into the package identity domain and updated package-relative imports."
+    }
+  ]
+}

package/docs/admin-identity-directories.md

@@ -0,0 +1,60 @@
+# Admin Groups and Personal API Keys
+
+The global Admin registry contributes Groups and Personal API Keys to the
+Identity & Access navigation group. `adminSectionRoutes()` and
+`adminSectionsMenu()` therefore mount the same pages in the standalone
+reference portal and in an embedded System Admin boundary:
+
+```tsx
+import {
+  GROUPS_ADMIN_SECTION,
+  GROUP_VIEW_PERMS,
+  GroupDetail,
+  GroupModel,
+  GroupsPage,
+  PERSONAL_API_KEYS_ADMIN_SECTION,
+  PersonalApiKeysPage,
+} from 'portal-mojo/admin/identity';
+```
+
+The registered routes are `/groups` and `/apikeys`; an embedded mount prefixes
+both routes. Group directory and detail access use the system-pinned
+`sys.groups | sys.view_groups` clause. Group mutations use
+`sys.groups | sys.manage_groups`. Active-group membership cannot satisfy
+these gates. The personal key section uses the system identity-view clause,
+while its API requests remain scoped to the signed-in user's own keys.
+
+## Groups
+
+`GroupsPage` retains the native server-owned `ModelTable` search, filters,
+presets, paging, sorting, column chooser, persistence and exports against
+`GET /api/group`. Opening a row presents `GroupDetail` in `modal.detail`.
+`GroupDetail` preserves the Overview, Identity, Members, Sub-Groups, API Keys,
+Webhooks, Geofencing, Events, Audit and Metadata surfaces, with each section's
+existing system permission gate and conditional queries. Parent, child, member
+and user navigation opens native detail modals while keeping the directory
+underneath.
+
+The group model and section code are adapted from the reference portal at
+`v0.2.5` commit `93c7fdfeb3096d33010e72bd4483cf9ca6e3d6f5`. The source hashes
+and corresponding package hashes are recorded in
+[`admin-identity-directories-sources.json`](admin-identity-directories-sources.json).
+The moved implementation retains the package Apache-2.0 license. Two raw JSON
+surfaces render their values directly in their explicit Metadata/Auth details;
+they do not use collapsible content.
+
+## Personal API Keys
+
+`PersonalApiKeysPage` uses the existing `ApiKeyModel` at
+`/api/account/api_keys` and the caller-only generation mutation at
+`/api/auth/generate_api_key`. The generated token is shown once and scrubbed
+before it can reach the query or mutation cache. Key facts and actions open in
+a native detail modal. Disable/enable remains reversible with an undo toast;
+revoke remains armed because it rotates the secret and cannot be undone. There
+is no delete action. This page does not use the separate group credential
+endpoint.
+
+The Personal API Keys route was added to the package identity section registry
+alongside Users, Members, Groups, Credentials and Sign-in. Compatibility page
+paths in the reference app re-export the package-owned pages, and its menu and
+route composition do not inject duplicate directory entries.

package/docs/admin-identity-users.md

@@ -25,7 +25,12 @@ reason per batch; rows already in the target state are ineligible.
 
 The detail preserves all 14 sections: Overview, Profile, Personal, Security,
 OAuth, Groups, Sys Perms, conditional App Perms, API Keys, Devices, Logins,
-Audit, Notifications, and Metadata. Subsidiary count/list queries are enabled
+Audit, Notifications, and Metadata. Permission sections are labeled **System
+permissions** and **Product permissions** in the UI. Consuming apps install
+their product tabs with `registerFormTabs(USER_APP_PERMS_TABSET, tabs)`; the
+section stays absent when none are registered. User grants can cover multiple
+groups; use a Member product permission for a single group.
+Subsidiary count/list queries are enabled
 only when their exact system permission is present. Logs use
 `sys.view_logs | sys.manage_logs | sys.security`; incident events use
 `sys.view_security | sys.security`. Permission revocation therefore removes

package/docs/admin-members.md

@@ -12,6 +12,7 @@ import {
   MEMBERS_ADMIN_SECTION,
   openMemberAdmissionDialog,
   registerMemberPermissions,
+  MEMBER_APP_PERMS_TABSET,
 } from 'portal-mojo/admin';
 ```
 
@@ -103,6 +104,16 @@ and read-only rather than disappearing. Permission switches autosave through
 `FormView`; a deployment's `MEMBER_PERMS_PROTECTION` remains authoritative,
 and rejected changes revert with the server error shown.
 
+For a larger product catalog, also register native `FormView` tabs under
+`MEMBER_APP_PERMS_TABSET` with `registerFormTabs` from `portal-mojo/ui`.
+Use dotted `permissions.<grant>` fields and retain the corresponding
+`registerMemberPermissions` definitions. A separate **Product permissions**
+detail section appears when this tabset is populated. Fields covered by those
+tabs leave the ordinary **Permissions** section, so each grant has one editor.
+Both forms save the same membership row with the same gates, partial-dict
+merge, escalation confirmation and rejection handling. The tabset creates no
+new grant semantics: the backend still decides what each key authorizes.
+
 ## Composition
 
 `MEMBERS_ADMIN_SECTION` is root-relative and dual-mounts as `/members` in the
@@ -110,3 +121,8 @@ standalone Admin and `/system/members` when embedded. It never consumes active
 group context. `GroupMembersPanel` is the reusable Group-detail composition;
 pass optional `onNavigateUser` and `onNavigateGroup` callbacks to connect
 sibling identity details without coupling the package to an app.
+
+Member product tabs only render `permissions.<grant>` fields whose grant is
+registered through `registerMemberPermissions()` and editable. System/derived
+grants, unregistered names and unrelated fields (such as `group` or `user`)
+are ignored; tabs with no valid fields do not appear.

package/docs/admin-network-security.md

@@ -163,7 +163,7 @@ flag is detected, `true` REQUIRES the flag (rare), absent/`null` means don't
 care.
 
 `geofence-data.ts` is the ONE definition of the lossy projection between that
-DSL and the friendly form. `apps/portal/src/pages/group-sections/geofence-data.ts`
+DSL and the friendly form. `packages/portal-mojo/src/admin/identity/groups/group-sections/geofence-data.ts`
 is a re-export shim over it, so the platform page and the group panel cannot
 drift. `GeofenceRuleEditor` is the ONE editor both render.
 

package/docs/admin-push.md

@@ -6,38 +6,117 @@ Import `PushPage`, its individual panels/pages, the canonical push models, API h
 
 The page has six possible tabs: Your stats, Global metrics, Devices, Deliveries, Templates, and Config. Stats are authenticated caller data. Every other tab is independently filtered by its exact permission clause, and only the active authorized panel mounts, so hidden/inactive surfaces issue no requests.
 
-`push_surface` is registered with `registerNonFilterParams` at module load. It survives table writes but never becomes a Django lookup or filter pill. Changing tabs replaces the flat URL params with only `push_surface`, intentionally clearing search, sort, paging, and filters that belong to the prior model.
+`push_surface` is registered with `registerNonFilterParams` at module load. It survives table writes but never becomes a Django lookup or filter pill. Changing tabs retains only `push_surface` and the showcase host's `demo` selector, clearing search, sort, paging, and filters belonging to the prior model. Showcase registers `demo` as a non-filter param at boot, so table writes keep the selected demo without sending it as a model lookup.
 
 ## Exact permissions
 
-All UI clauses carry the `sys.` namespace and are ANY-of:
+All UI clauses carry the `sys.` namespace. Alternatives within a clause are ANY-of:
 
 - Devices view: `view_devices | manage_devices | comms | owner | manage_users`; save: `manage_devices | comms | owner`.
 - Deliveries view: `view_notifications | manage_notifications | comms | owner | manage_users`; save: `manage_notifications | comms`.
 - Templates view: `manage_notifications | manage_groups | comms | owner | manage_users`; save: `manage_notifications | manage_groups | comms`.
 - Config view/save: `manage_push_config | manage_groups | comms`.
 - Config connection test: `manage_push_config | comms`.
+- Device test: `send_notifications | comms` **AND** the Devices view clause above.
 - Global metrics: `view_metrics | metrics`, with `account="global"`.
 
 `sys.users` is deliberately absent: it is not in `RegisteredDevice.RestMeta.VIEW_PERMS`. The Stats endpoint requires authentication only and always scopes all five keys to `request.user`.
 
+Device inspection or config management alone never enables a test send. The backend separately enforces global `send_notifications | comms` and visibility of the selected registration; invisible and missing devices both return 404. Config checks require global `manage_push_config | comms`, independently of config editing. Group/member grants, API keys, and key-backed sessions cannot satisfy these test-action gates.
+
 ## Projection and ownership boundaries
 
 Every model pins a `basic` or `default` graph, allowlists list params, and positively projects rows before Query or Mutation cache reconciliation. RegisteredDevice never retains `device_token`; Delivery never retains `platform_data`, and its arbitrary `data_payload` is not retained by the UI projection. Related users are reduced to id plus a short display label—never email, phone, metadata, or an expanded user graph. Template JSON objects accept only a bounded shallow scalar projection on reads.
 
+The additional evidence retained by the UI is:
+
+| Model / result | Retained fields and fallback |
+|---|---|
+| `PushDeviceRow` | `is_active` is boolean or null; an older backend with no field shows “Activity unknown”. |
+| `PushConfigRow` | `fcm_project_id` (max 200 characters), `fcm_client_email` (max 254), and boolean/null `has_fcm_credentials`. Missing metadata is “Not reported” / “Presence not reported”; credential presence is not verification. |
+| `PushDeliveryRow` | `push_outcome` allowlists `accepted`, `delivered`, `simulated`, `rejected`, `blocked`, `unknown`, `pending`, `sent`, and `failed`; otherwise null, with display falling back to stored `status`. |
+| `PushTestConfig` | Positive safe-integer `id`, `name` (max 100), `group` (safe-integer id/name up to 120 characters, or explicit null for system default), `fcm_project_id` (max 200), `test_mode`, `is_active`, `has_fcm_credentials`. No service-account email or secret material. |
+| `PushTestResult` | `success`, `outcome`, local `message`, allowlisted/null `error_code`, success-only `message_id` (max 500), positive safe-integer/null `delivery_id` and `device_id`, and projected/null `config`. |
+
+Test results live in the open dialog, outside Query and Mutation caches. Provider messages and raw error bodies are replaced by local copy; unknown error codes are discarded. `PushReadiness` retains only `ready`, local `message`, `device_id`, and projected `config`.
+
 `PushDeviceModel` now lives canonically in `admin/messaging/push`. The former `admin/identity/users/models.ts` definition is a compatibility re-export of the same object, so User Detail and the global Push page share one endpoint definition and Query key.
 
 ## FCM credentials and actions
 
 FCM writes are imperative and cache-free. A service account textarea is an uncontrolled DOM ref and never prefills. Blank means untouched and is omitted. Replacement must parse to an object with `type="service_account"`, `project_id`, `client_email`, and a PEM `private_key`. Clear sends `null` only after explicit confirmation. Empty replacement is impossible, and server responses are sanitized before cache reconciliation.
 
-Connection testing calls only `POST /api/account/devices/push/config/<id>/test` with an empty body. The backend uses its dummy token to validate credentials. The portal never accepts a device token. It also does not expose `/send`, caller `/test`, delivery retry, device registration/unregistration, or any delete action.
+### Saved configuration check
+
+`testPushConfigConnection(id)` calls `POST /api/account/devices/push/config/<id>/test` with `{}`. The backend authenticates with FCM and submits a validation-only message, including when `test_mode=true` or the selected config is inactive. It sends no device notification and does not activate the config. The portal never accepts a raw device token.
+
+The adapter accepts success only when the envelope has not failed, `success === true`, `outcome === "validated"`, `validation_only === true`, and `message_id` matches `projects/<project>/messages/<reference>`. Missing/malformed verdicts, simulated legacy responses, and provider rejections cannot display a verified connection. Backend HTTP 400 failures retain safe diagnostic data; the adapter returns a failed `PushTestResult` for the dialog to display.
+
+“Check FCM connection” lives in the config header menu. The result and check time remain visible in Overview and Connection for that saved record/revision. Checks lock duplicate checks, editing, and active-state changes while pending. Editing or changing active state clears the result; record revision, permission, caller, or mount changes invalidate late completions. This is evidence from the current view, not a persisted credential-verification flag.
+
+### One registered device
+
+The device header's “Send test push” opens a focused dialog. The API helpers use the existing test endpoint:
+
+| Helper | Request | Purpose |
+|---|---|---|
+| `fetchPushDeviceReadiness(42)` | `GET /api/account/devices/push/test?device_id=42` | Local readiness; no FCM traffic. |
+| `sendPushDeviceTest(42, title, message)` | `POST /api/account/devices/push/test` with `{"device_id":42,"title":"Push test","message":"This is a test notification."}` | One real notification to the selected registration. |
+
+`device_id` here is the numeric database `id`, not the app-provided string `device_id` used for registration. The portal never calls the caller-wide POST variant without a selector. The backend resolves the device owner's active org config, falling back to the active system default; the dialog shows the device, user, config ID/name, scope, and FCM project actually reported by readiness or the send result.
+
+Readiness must explicitly match the requested device and include an active config with credentials present and simulation disabled. Inactive registration, push disabled, an opted-out `test` category, missing token/config/credentials, or simulation prevents sending. Readiness does not verify provider credentials or device reachability. Unknown/malformed readiness disables Send rather than guessing.
+
+The dialog defaults to title `Push test` and message `This is a test notification.`; inputs must be nonblank and fit 200/1000 characters. A single pending guard prevents duplicate submissions and locks fields, Cancel, Escape, and backdrop dismissal during sending. Each dialog permits one completed attempt; reopen it to obtain fresh readiness before another. Permission loss hides stale results; settled requests still unlock dismissal. Every attempt invalidates device, delivery, and caller-stat queries in `finally`.
+
+Device results require explicit `success === true`, `outcome === "accepted"`, a provider message reference, and the requested `device_id`. Handled backend failures may be HTTP 200 with `data.success=false`; inspect the projected result. A failed envelope cannot establish success. Uncertain transport/malformed responses become `unknown`, and known HTTP 400/401/403/404 refusals without structured evidence become blocked. There is no automatic resend.
+
+The portal exposes no general `/send`, caller-wide test, delivery retry, device registration/unregistration, or delete action.
+
+All four REST models have live `CAN_DELETE = false`; the mock returns 403 without removing or cascading anything. Templates/configs can be created and edited under their save clauses. Device record editing and delivery mutation remain absent from this page.
+
+## Outcomes and delivery evidence
+
+Test dialogs keep a visible result label, local explanation, check time, and delivery record ID when available:
+
+| Outcome | Meaning |
+|---|---|
+| `validated` | FCM connection verified; no notification delivered. |
+| `accepted` | FCM accepted the notification; the operator must check the selected device for receipt. |
+| `rejected` | FCM refused the request; show the safe diagnostic. |
+| `blocked` | Readiness, credentials, authentication, or request refusal prevented a successful test. |
+| `unknown` | Acceptance is uncertain. Check the device and delivery history before another test; do not label it failed or retry automatically. |
 
-All four REST models have live `CAN_DELETE = false`; the mock returns 403 without removing or cascading anything. Templates/configs can be created and edited under their save clauses. Devices and deliveries remain investigative here.
+Delivery lists/details prefer `push_outcome` over `status`. `simulated` is explicitly shown as no FCM send, even though the stored status is `sent`. `unknown` remains pending; provider acceptance alone does not mark a record delivered. Older `sent` records are described as lacking acceptance/receipt evidence. Status filtering and sorting still use the stored status field, not the derived outcome. The caller-stat tile is “Recorded sent” because its count may include simulations.
 
 ## Modal lifecycle convention
 
 See [Admin modal policy](admin-modals.md) for header actions, content-only
 sections, supported lifecycle fields and retained irreversible exceptions.
-Config/template active-state controls live in the detail header. Config saves
-retain write-only credential handling, and test sends keep their separate gate.
+Config/template active-state controls live in the detail header. Device details
+use Overview/Preferences with active and push-state chips; delivery details use
+Notification/Delivery with outcome explanations. Templates use
+Overview/Notification/Variables; configs use Overview/Connection with scope,
+send-mode, credential-presence, and service-account metadata.
+
+Config/template editors keep one pending save guard and protect Escape/backdrop
+dismissal as well as Cancel. Config saves retain write-only credential handling;
+device test sends use their separate permission AND and dismissal lock.
+
+## Showcase and verification
+
+Open `#/?demo=admin-push` in Showcase. Its banner explicitly identifies
+local fixtures: connection checks and test pushes there never contact FCM or
+deliver notifications. Fixtures exercise system/org config selection, disabled
+push, simulation blockers, safe metadata, and a selected-device accepted result
+with a delivery row and no delivered timestamp. Switching Push tabs preserves
+`demo=admin-push`; model filtering never consumes that host selector.
+
+`npm run verify:admin-push` runs both `scripts/verify-admin-push.mjs` (mock wire,
+permissions, projections, credentials, and target selection) and
+`scripts/verify-push-tests.mjs` (mounted dialog/adapters). The latter covers strict
+provider verdicts, malformed/mismatched responses, revision/permission ownership,
+persistent results, duplicate-send prevention, pending dismissal, and cache
+isolation. JSDOM assertions do not prove native dialog layout or stacking;
+complete browser verification in both themes and a narrow viewport, including
+the device test, configuration check, and nested editors.

package/docs/admin-settings.md

@@ -33,6 +33,16 @@ queries `/api/group`, and preserves that scope on save. New settings default to
 Global. Delete is intentionally absent because live `Setting.RestMeta` does not
 declare deletion.
 
+## Viewing values
+
+JSON objects and arrays show a compact type/count summary in the list. Long or
+multiline text shows a single-line preview, capped at 80 characters. Select the
+row to open the full value in the existing detail
+modal. JSON uses the shared `JsonBlock` viewer, expanded initially, with syntax
+highlighting, Show/Hide, Copy, and a scrollable body. Other text preserves line
+breaks in a scrollable area; invalid JSON remains plain text. Secret values stay
+masked in both views.
+
 ## Atomic write contract
 
 Use `saveSettingAtomic()` / `buildSettingPayload()` rather than a generic

package/docs/admin-signin.md

@@ -0,0 +1,73 @@
+# Sign-in admin (#5547)
+
+Import `SigninPage`, `SIGNIN_ADMIN_SECTION`, the permission clause and the API
+helpers from `portal-mojo/admin` (or `portal-mojo/admin/identity`). The section
+registers one global route, `/system/sign-in`, under **Identity & Access**,
+gated by `SIGNIN_ADMIN_PERMISSIONS` = `['sys.manage_settings', 'sys.admin']`
+(superusers pass). Admin global scope masks any outer product group.
+
+The page has two parts:
+
+- **Look & feel** — the SYSTEM hosted login/registration page: branding,
+  layout/appearance/accent color, hero panel, sign-in heading/copy/methods,
+  registration, custom CSS. It edits the same keys a group admin edits in the
+  group **Configure Auth** dialog; a group's own settings still override these.
+- **Providers** — one card each for Google, Apple and GitHub: an Enabled
+  switch, a read-only callback URL with a Copy button, the credential fields,
+  a Ready / Needs setup badge, and a link to the provider's console.
+
+KISS by design: trusted admins, no step-up auth, no confirmation beyond a
+browser `confirm()` before clearing a stored value.
+
+## Wire contract
+
+One endpoint, both methods, django-mojo envelope.
+
+`GET /api/account/admin/signin` → `{schema_version, auth, editable, options, providers}`
+
+- `auth` is `public_auth_config` of the resolved system config
+  (`{theme, login, registration}`).
+- `editable` lists the flat dotted paths the POST accepts. The page renders
+  only fields whose path is listed, so the backend can narrow it.
+- `options` carries the allowed tokens for methods, layouts, appearances,
+  hero image positions and passkey prompts. Legacy layouts `card` /
+  `fullscreen` display as `compact` / `branded-panel`; any other unknown select
+  value falls back to the first option with a `console.warn`.
+- `providers[]`: `{name, label, enabled, ready, missing, callback_url,
+  console_url, help, fields[]}`; each field is `{key, label, secret,
+  multiline, configured, source, value, hint}`. `source` is `admin`,
+  `deployment` (shown as "Set in server config") or `none`. Secret fields
+  never carry `value`; `hint` (e.g. `…a1b2`) is shown when present.
+
+`POST /api/account/admin/signin` returns the same full payload, which the page
+writes straight into its query cache (`SIGNIN_QUERY_KEY`).
+
+- Look & feel: `{auth: {"theme.app_title": "…", "login.methods": […]}}` —
+  only the paths whose value differs from the loaded payload, sent by the
+  explicit **Save** button. Password is locked on in the sign-in methods picker;
+  the server rejects a list without it (400).
+- Provider: `{provider, values, enabled}`. In `values`, an omitted key or
+  `""` keeps the stored value and `null` clears it. The card's **Save** sends
+  only fields the admin typed into; **Clear…** (shown for `source: "admin"`)
+  confirms, then sends `null` at once. The **Enabled** switch saves
+  immediately with `{provider, enabled}`, which adds/removes the provider from
+  both `login.methods` and `registration.methods`.
+- Errors are `{status: false, error}` (HTTP 400). The client rejects them; the
+  page shows the message inline and as a toast and keeps the unsaved edits.
+
+Secrets are entered in password inputs (the Apple `.p8` key in a textarea)
+and cleared from local state after a successful save.
+
+## Mock
+
+`src/client/mock.ts` implements the endpoint: global `manage_settings` /
+`admin` gate (401 anonymous, 403 otherwise), `editable`-only writes with the
+option and password rules, and credential storage. Seed: Apple has Team ID and
+Services ID stored in the Admin (missing Key ID and private key), Google has
+nothing, GitHub is configured by the deployment. Saved look & feel lands in a
+system override that `/api/auth/config` layers between the deployment config
+and group overrides, so the public config reflects saves. An Admin-stored
+credential wins over the deployment value; clearing it falls back to the
+deployment value.
+
+Verify with `npm run verify:admin-signin`.

package/docs/menus-and-access.md

@@ -26,8 +26,10 @@ setDefaultMenu('admin');
 Resolution: route containment in registration order (group menus eligible
 only under a kind-matched active group) → defaultMenu → first non-group
 visible. Items support `permissions` (any-of) ∧ `requiresGroupKind`;
-dividers with no visible children drop; a parent lights when a child route
-is active. `scope: 'admin' | 'group' | 'account' | 'global'` makes ownership
+dividers with no visible children drop. Only the destination row is selected;
+an accordion parent is a neutral disclosure control and opens for its active
+child. `exact: true` end-matches both the visual selection and `aria-current`.
+`scope: 'admin' | 'group' | 'account' | 'global'` makes ownership
 explicit; legacy `groupKind` menus still infer group scope. Static rendering
 remains the default for compatibility. `presentation: 'accordion'` enables
 searchable, single-open-section navigation. Give accordion parents stable
@@ -57,6 +59,8 @@ Admin section bundles contribute through `adminSectionsMenu`. Use
 `{grouped: true, presentation: 'accordion'}` for the domain-grouped Admin
 experience. Routes remain mount-relative; multiple embedded root sections
 share one `/system` landing instead of emitting duplicate index routes.
+Generated Admin destinations are exact matched, so an embedded mount’s root
+Dashboard cannot remain selected on every nested page.
 
 Import the route/menu machinery from `portal-mojo/admin/core`, then import only
 the registry domains the shell installs. The stable domains are `identity`,

package/docs/realtime.md

@@ -19,6 +19,11 @@ disable this shared provider.
   `auth_success`. An auth error closes and suspends the connection until the
   token value changes.
 - Heartbeat is a `ping` every 20 seconds with a 10-second `pong` deadline.
+  A server-initiated `{type:'ping'}` (django-mojo 1.32+ sends one every 20
+  seconds and culls a socket silent for 90) is answered at once with
+  `{type:'pong'}` while ready, clears the pending `pong` deadline, and is never
+  dispatched to consumers. Answering from the message handler keeps the socket
+  alive while a background tab throttles the client's own ping timer.
   Reconnect uses capped jittered backoff. Pre-accept close code 4429 enforces at
   least 60 seconds, and focus/visibility cannot bypass that deadline.
 - Desired topics are refcounted and replay after authentication. Operations are

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "portal-mojo",
-    "version": "0.2.4",
+    "version": "0.2.6",
     "description": "React portal toolkit for django-mojo — typed client + params store, mission-control UI, dependency-free SVG charts, admin section bundles.",
     "type": "module",
     "license": "Apache-2.0",

package/src/admin/core/index.ts

@@ -207,8 +207,8 @@ export function adminSectionsMenu(sections: readonly AdminSection[], opts: {
             const labeled = section.routes.filter((route) => route.label);
             const destinations: MenuItem[] = labeled.length > 0 ? labeled.map((route) => ({
                 id: `admin:${section.id}:${route.path || 'index'}`, label: route.label!, keywords: [section.title],
-                route: absolutePath(base, route.path), permissionClauses: [section.permissions, ...(route.permissions ? [route.permissions] : [])],
-            })) : [{ id: `admin:${section.id}`, label: section.title, keywords: [section.title], route: absolutePath(base), permissionClauses: [section.permissions] }];
+                route: absolutePath(base, route.path), exact: true, permissionClauses: [section.permissions, ...(route.permissions ? [route.permissions] : [])],
+            })) : [{ id: `admin:${section.id}`, label: section.title, keywords: [section.title], route: absolutePath(base), exact: true, permissionClauses: [section.permissions] }];
             if (section.navigationGroup === null) {
                 items.push(...destinations.map((destination) => ({ ...destination, icon: section.icon })));
                 continue;
@@ -227,8 +227,8 @@ export function adminSectionsMenu(sections: readonly AdminSection[], opts: {
         const base = relativePath(mount, section.basePath ?? section.id);
         items.push({
             label: section.title, icon: section.icon, permissions: section.permissions,
-            ...(base ? { route: absolutePath(base) } : {}),
-            children: labeled.map((route) => ({ label: route.label!, route: absolutePath(base, route.path), permissions: route.permissions })),
+            ...(base ? { route: absolutePath(base), exact: true } : {}),
+            children: labeled.map((route) => ({ label: route.label!, route: absolutePath(base, route.path), exact: true, permissions: route.permissions })),
         });
     }
     return { name: opts.name ?? 'admin', scope: 'admin', presentation: opts.presentation ?? 'static', items };