@nocobase/app-template-default 1.0.0-beta.74 → 1.0.0-beta.76

package/.agents/rules/build-and-deploy.md

@@ -2,6 +2,10 @@
 
 Read this before changing the build, packing a deployment archive, building or editing the Docker image, setting `CDN_BASE_URL`, or building for another platform. The deployment process itself is in the [deployment Skill](../skills/nocobase-deployment/SKILL.md), and dependency placement and the build failure table are in [where to declare a dependency](../skills/nocobase-app-development/references/dependencies.md).
 
+## Client typechecking
+
+Keep `types: ["node"]` in the client `tsconfig.json`. Shared contracts from database and lifecycle packages resolve to their TypeScript sources in a workspace and require Node.js declarations during typechecking. Declare that requirement explicitly instead of relying on unrelated plugin imports to load the declarations; type-only imports still disappear from the browser bundle.
+
 ## CDN assets at build time
 
 `CDN_BASE_URL` sets Vite's `base` only during a production build: `CDN_BASE_URL=https://cdn.example.com/my-app/v1/ pnpm build`. Use a full HTTPS URL ending in `/`; unset, empty or whitespace-only values keep the default `./`. `pnpm build` reads it from the process environment, then `.env.local`, then `.env`; development ignores it and continues using `APP_BASE_PATH`. It is a build parameter, absent from `config variables` and `dist/variables.json`, with no `config.yml` setting. Changing it requires rebuilding.

package/.agents/rules/components.md

@@ -35,4 +35,6 @@ The default brand palette and density live in `client/theme/themes/*.css`; share
 
 ## Standard process management
 
-The template includes `FlowDiagram`, `LifecycleDiagram` and `client/extensions/nocobase-workflow-management/` source. Reuse them when business workflows are introduced; preinstallation does not register a settings route or sample process. `LifecycleDiagram.configuration` automatically offers configuration for authorized native parameter bindings, using the application’s real parameter editor and API. Read [Lifecycle UI](../skills/nocobase-app-development/references/lifecycle-ui.md) before wiring the workflow directory, definition and execution pages. Preserve the standard visuals unless the user explicitly asks to customize them. UI Library names are shadcn registry items, not npm package names; an npm 404 is not evidence that a component is unavailable.
+The template includes `FlowDiagram`, `LifecycleDiagram` and `client/extensions/nocobase-workflow-management/` source. Reuse them when business workflows are introduced; preinstallation does not register a settings route or sample process. `LifecycleDiagram.configuration` automatically offers configuration for authorized native parameter bindings, using the application’s real parameter editor and API. Read [Lifecycle UI](../skills/nocobase-app-development/references/lifecycle-ui.md) before wiring the workflow directory, definition and execution pages. The existing `LifecycleDiagram` supports `presentation="process"` for compact approval/work cards and start/outcome pills, with `stateKind` supplied by the application; omitting it keeps the classic presentation. Preserve configuration and recorded-history behavior when selecting a presentation. UI Library names are shadcn registry items, not npm package names; an npm 404 is not evidence that a component is unavailable.
+
+Use `RecordLink` from `#components/record-link` for clickable record names and identifiers in lists and tables. It uses foreground text with medium weight, an underline on hover, and an underline plus focus outline for keyboard navigation. Preserve the native link semantics and route query context. Do not give record fields a permanent underline, primary-blue text, or a button-shaped surface. Keep action buttons and menu items on their own components; do not globally restyle every link in the application.

package/AGENTS.md

@@ -53,7 +53,7 @@ A feature with a page and an API touches five places: a migration for the table,
 
 ## System settings are part of feature delivery
 
-A bare create-app stays Home-only with no settings routes or menu. As the application develops business capabilities, inspect its current state on every iteration and automatically register the prepared Users and Roles and permissions contribution from `client/pages/settings/routes.ts` once in `client/routes.ts`; preserve it and reconcile missing management surfaces on every iteration, without a first-build flag or one-time setup stage. Whenever an application adds lifecycles, workflows, approvals, notifications, files or other configurable capabilities, automatically include their real administration surfaces without requiring a second user request. Follow [system settings delivery](.agents/skills/nocobase-app-development/references/system-settings.md); in particular, every used process includes a definitions directory, standard diagram, supported parameters and authorized execution history. Do not add demo plugins or empty settings for unused capabilities. The template preinstalls `#components/lifecycle-diagram` (React Flow + ELK) and `client/extensions/nocobase-workflow-management/`: use them by default, preserve their visuals unless the user explicitly requests another style, and connect authorized parameter bindings through `LifecycleDiagram.configuration` to the real editor. These are UI Registry sources; an npm package lookup is not a component availability check.
+A bare create-app shows Home to signed-in users and System settings → App foundation only to unrestricted administrators. The Foundation plugin owns this initial settings group; the navigation transform merges its entry into the application settings group when business administration is registered. As the application develops business capabilities, inspect its current state on every iteration and automatically register the prepared Users and Roles and permissions contribution from `client/pages/settings/routes.ts` once in `client/routes.ts`; preserve it and reconcile missing management surfaces on every iteration, without a first-build flag or one-time setup stage. Whenever an application adds lifecycles, workflows, approvals, notifications, files or other configurable capabilities, automatically include their real administration surfaces without requiring a second user request. Follow [system settings delivery](.agents/skills/nocobase-app-development/references/system-settings.md); in particular, every used process includes a definitions directory, standard diagram, supported parameters and authorized execution history. Do not add demo plugins or empty settings for unused capabilities. The template preinstalls `#components/lifecycle-diagram` (React Flow + ELK) and `client/extensions/nocobase-workflow-management/`: use them by default, preserve their visuals unless the user explicitly requests another style, and connect authorized parameter bindings through `LifecycleDiagram.configuration` to the real editor. These are UI Registry sources; an npm package lookup is not a component availability check.
 
 ## Rules that apply everywhere
 
@@ -123,3 +123,9 @@ When the built-in mechanism genuinely cannot express what is being asked, changi
 | [.agents/rules/components.md](.agents/rules/components.md)             | Adding or changing a component, a shadcn primitive, a UI Library item, or the visual design                  |
 | [.agents/rules/shell.md](.agents/rules/shell.md)                       | Changing layouts, the header, sidebar, breadcrumbs, the account menu or loading indicators                   |
 | [.agents/rules/build-and-deploy.md](.agents/rules/build-and-deploy.md) | Changing the build, packing a deployment, the Docker image, `CDN_BASE_URL`, or building for another platform |
+
+## Visible and manageable role assignments
+
+Assign application business roles to explicitly identified users through the prepared User management role-assignment UI. Never seed a business permission set onto `authenticated:*`, broaden the inherited platform `member` role, or write startup reconciliation that grants access to everyone merely to make a feature usable. Unchecked actions in one role do not revoke grants inherited from another. If the user explicitly requests a global default role, first deliver a permission-protected administration control that shows its recipients and allows changing or removing the assignment; show inherited roles and their source in user access details. Without that UI, use explicit user assignments and explain the limitation. Keep page access independent from business operations.
+
+Run `pnpm exec vitest run tests/logic/authorization-assignment-safety.test.ts` after permission initialization changes and before delivery. It boots the real application on an isolated database and inspects initialized wildcard assignments and the inherited member role. Keep this test in generated applications. An intentional global default requires explicit user authorization, a working administration surface and corresponding acceptance tests before deliberately updating the expected baseline; do not delete, skip or loosen the guard to make tests pass. Test an ordinary user with only the configured role: inspect all effective grant sources and verify both hidden buttons and rejected direct API calls.

package/README.MD

@@ -6,7 +6,7 @@ You own everything in this directory. Add pages, API routes, database tables, an
 
 ## Default and Examples
 
-Default provides the application shell and product capabilities without example plugins or business demo pages. Application-owned business API routes start empty, and new databases receive no article sample data. A bare create-app shows Home only, with no System settings routes or menu. As business capabilities are developed, the app development skill reconciles missing core administration on every iteration and registers the prepared Users and Roles and permissions contribution (`client/pages/settings/routes.ts`); each actually used configurable capability includes its administration as part of feature delivery. Its built-in Users integration lists direct Authorization Permission Sets as application roles, while access assigned to all authenticated users remains separate. Use `app-template-examples` for article management and runnable plugin demonstrations.
+Default provides the application shell and product capabilities without example plugins or business demo pages. Application-owned business API routes start empty, and new databases receive no article sample data. A bare create-app shows Home and, for unrestricted administrators only, System settings → App foundation. Foundation is installed and registered on both Client and Server; its read-only overview is available at `/foundation` under the application base path. As business capabilities are developed, the app development skill reconciles missing core administration on every iteration and registers the prepared Users and Roles and permissions contribution (`client/pages/settings/routes.ts`); each actually used configurable capability includes its administration as part of feature delivery. Its built-in Users integration lists direct Authorization Permission Sets as application roles, while access assigned to all authenticated users remains separate. Use `app-template-examples` for article management and runnable plugin demonstrations.
 
 Existing Default installations retain their data when example plugins are unregistered. If an installation already ran the article migration, retain its original migration sources as described in the [upgrade migration rules](.agents/skills/nocobase-app-upgrade/references/edge-cases.md#migrations) before upgrading. Do not erase migration history or delete existing data to make an upgrade start.
 
@@ -403,9 +403,9 @@ Tests live in `tests/`, never beside the source they cover. Put logic and integr
 
 Application tests use the `/server`, `/client` and `/cli` entries of `@nocobase/app-testing`. Start page tests from `tests/components/page-harness.test.tsx`: it uses `renderWithApp()` with real application hooks, strict translations, permission checks and a test toaster. Answer requests through `answerApi()` and replace external services through `services`, without also registering their owning plugins. The template's Vitest configuration includes client plugins in custom package scopes so their contexts and service tokens remain shared. See `.agents/skills/nocobase-app-development/references/testing.md` for fixture ownership and complete server, migration and CLI examples.
 
-### Notification testing
+### Notification verification
 
-With the `notification:test` `send` permission, send a real message through the durable Notification Manager with `POST <APP_BASE_PATH>/api/notifications/testSends`. `GET <APP_BASE_PATH>/api/notifications/testTargets` lists each configured channel and the fields its test takes: Email tests require an address and IM tests use the configured logical target. The server enforces the permission when the message is submitted.
+Exercise the application's business notification flow, or use a server-side command resolving `notificationServiceToken` and calling `send()` with complete messages and explicit recipients. Inspect the returned notification ID through the protected `/api/notifications/logs` API or the logs page installed by the application. Log access requires `page:notification.logs` `access`.
 
 ## API documentation
 

package/cli/plugins.ts

@@ -1,8 +1,9 @@
 import { defineCliPlugins, type AppCliPlugins } from '@nocobase/app-cli';
+import foundation from '@nocobase/app-plugin-foundation/cli';
 import scheduler from '@nocobase/app-plugin-scheduler/cli';
 
 // Array order is command registration order. A plugin contributes its commands
 // by appearing in this list; removing its entry and its import removes them.
-const cliPlugins: AppCliPlugins = defineCliPlugins([scheduler]);
+const cliPlugins: AppCliPlugins = defineCliPlugins([scheduler, foundation]);
 
 export default cliPlugins;

package/client/components/data-table/data-table.tsx

@@ -107,6 +107,8 @@ export function DataTable<TData, TValue = unknown>({
     data: tableData,
     columns,
     manualPagination,
+    // Controlled hosts own URL page resets and correction after writes.
+    autoResetPageIndex: paginationState === undefined,
     rowCount,
     manualSorting,
     ...(onPaginationChange ? { onPaginationChange } : {}),

package/client/components/data-table/pagination.tsx

@@ -69,9 +69,9 @@ export function DataTablePagination<TData>({
             })
           : null}
       </div>
-      <div className='flex flex-wrap items-center gap-6 lg:gap-8'>
-        <div className='flex items-center gap-2'>
-          <p className='text-sm font-medium'>
+      <div className='flex min-w-0 flex-wrap items-center justify-end gap-x-6 gap-y-3 lg:gap-x-8'>
+        <div className='flex shrink-0 items-center gap-2'>
+          <p className='text-sm font-medium whitespace-nowrap'>
             {t('dataTable.rowsPerPage', { defaultValue: 'Rows per page' })}
           </p>
           <Select
@@ -83,7 +83,7 @@ export function DataTablePagination<TData>({
           >
             <SelectTrigger
               size='sm'
-              className='w-[70px]'
+              className='w-[70px] shrink-0'
               aria-label={t('dataTable.rowsPerPage', {
                 defaultValue: 'Rows per page',
               })}
@@ -102,14 +102,14 @@ export function DataTablePagination<TData>({
             </SelectContent>
           </Select>
         </div>
-        <div className='flex w-[100px] items-center justify-center text-sm font-medium'>
+        <div className='shrink-0 text-sm font-medium whitespace-nowrap tabular-nums'>
           {t('dataTable.pageOf', {
             defaultValue: 'Page {{page}} of {{pageCount}}',
             page: pageIndex + 1,
             pageCount,
           })}
         </div>
-        <div className='flex items-center gap-2'>
+        <div className='flex shrink-0 items-center gap-2'>
           <Button
             variant='outline'
             size='icon-sm'