@bleedingdev/modern-js-main-doc 3.2.0-ultramodern.12 → 3.2.0-ultramodern.120

package/docs/en/guides/advanced-features/international/routing.mdx

@@ -32,7 +32,48 @@ i18nPlugin({
 | `/en/about` | Visits normally, language is `en` |
 | `/zh/about` | Visits normally, language is `zh` |
 
-Some paths, such as API routes and static assets, do not need locale prefixes. Use `ignoreRedirectRoutes` to skip redirects. See [Locale Detection -> ignoreRedirectRoutes](./locale-detection.md#ignoreredirectroutes).
+API and BFF prefixes are skipped automatically, so server API routes do not need locale prefixes or `localisedUrls` entries. For additional application paths that should not redirect, use `ignoreRedirectRoutes`. See [Locale Detection -> ignoreRedirectRoutes](./locale-detection.md#ignoreredirectroutes).
+
+## Localised URL Paths
+
+When `localePathRedirect` is enabled, `localisedUrls` is enabled by default. This means every localisable route path must define a URL for every configured language. If you add a new language to `languages`, Modern.js will fail route generation until each localised URL entry includes that language too.
+
+`localisedUrls` applies to file-system routes generated for both React Router and TanStack Router projects. Do not configure localised URL entries for API routes, BFF prefixes, or configured `bff.prefix` values; those paths are excluded from locale redirects automatically.
+
+```ts
+// modern.config.ts
+i18nPlugin({
+  localeDetection: {
+    localePathRedirect: true,
+    languages: ['en', 'cs'],
+    fallbackLanguage: 'en',
+    localisedUrls: {
+      '/terms-of-service': {
+        en: '/terms-of-service',
+        cs: '/podminky-pouzivani',
+      },
+      '/products': {
+        en: '/products',
+        cs: '/produkty',
+      },
+      '/products/:slug': {
+        en: '/products/:slug',
+        cs: '/produkty/:slug',
+      },
+    },
+  },
+});
+```
+
+**Result:**
+
+| Visited path | Result |
+| --- | --- |
+| `/terms-of-service` | Redirects to `/en/terms-of-service` |
+| `/cs/terms-of-service` | Redirects to `/cs/podminky-pouzivani` |
+| `/cs/podminky-pouzivani` | Visits normally, language is `cs` |
+
+Set `localisedUrls: false` only when you want locale prefixes without translated path segments.
 
 ## Route Configuration
 
@@ -131,4 +172,4 @@ function Navigation() {
 <I18nLink to="/en/about">About</I18nLink>
 ```
 
-`I18nLink` extends the `Link` component from `@modern-js/runtime/router` and supports all standard Link props such as `replace`, `state`, and `className`. For the full Props type, see [API Reference](./api.md#i18nlink-component).
+`I18nLink` uses the active Modern.js router. In React Router projects it renders the React Router `Link`; in TanStack Router projects it navigates through TanStack Router. For the full Props type, see [API Reference](./api.md#i18nlink-component).

package/docs/en/guides/basic-features/debug/using-storybook.mdx

@@ -55,7 +55,7 @@ Add the following scripts to `package.json` to start the BFF server and Storyboo
 ```json
 {
   "scripts": {
-    "dev:api": "modern dev --api-only",
+    "dev:api": "ultramodern dev --api-only",
     "storybook": "BFF_PROXY=1 storybook dev -p 6006 --no-open",
   }
 }

package/docs/en/guides/basic-features/deploy.mdx

@@ -15,12 +15,12 @@ Currently, Modern.js only supports running in a Node.js environment. Support for
 
 ## Build Deployment Products
 
-Running the `modern deploy` command will automatically produce deployment products. This process includes optimizing Bundler build products and their dependencies, detecting the current deployment platform, and automatically generating deployment products that can run on that platform.
+Running the `ultramodern deploy` command will automatically produce deployment products. This process includes optimizing Bundler build products and their dependencies, detecting the current deployment platform, and automatically generating deployment products that can run on that platform.
 
-If you want to generate and test the output locally for a specific deployment platform, you can specify the platform by setting the environment variable: `modern deploy`:
+If you want to generate and test the output locally for a specific deployment platform, you can specify the platform by setting the environment variable: `ultramodern deploy`:
 
 ```bash
-MODERNJS_DEPLOY=netlify npx modern deploy
+MODERNJS_DEPLOY=netlify npx ultramodern deploy
 ```
 
 :::info
@@ -36,10 +36,10 @@ By default, Modern.js outputs builds that can be run in a Node.js environment wh
 Use the following command to build the project:
 
 ```bash
-npx modern deploy
+npx ultramodern deploy
 ```
 
-When running the `modern deploy` command, Modern.js will generate runnable products and output the following content in terminal:
+When running the `ultramodern deploy` command, UltraModern.js will generate runnable products and output the following content in terminal:
 
 ```bash
 Static directory: `.output/static`
@@ -67,7 +67,7 @@ Assume that the name in the `package.json` of the current project is `app`. Taki
 {
   "scripts": {
     "build:packages": "pnpm --filter 'app^...' run build",
-    "deploy": "pnpm run build:packages && modern deploy"
+    "deploy": "pnpm run build:packages && ultramodern deploy"
   }
 }
 ```
@@ -78,7 +78,7 @@ If you use Rush as your Monorepo management tool, you can add the following comm
 {
   "scripts": {
     "build:packages": "rush rebuild --to-except app",
-    "deploy": "rushx build:packages && modern deploy"
+    "deploy": "rushx build:packages && ultramodern deploy"
   }
 }
 ```
@@ -108,7 +108,7 @@ Add the following content to `netlify.toml`:
 ```toml
 [build]
   publish = "dist"
-  command = "modern deploy"
+  command = "ultramodern deploy"
 ```
 
 :::info
@@ -125,7 +125,7 @@ Full-stack projects refer to projects that use Custom Web Server, SSR or BFF. Th
 ```toml title="netlify.toml"
 [build]
   publish = "dist"
-  command = "modern deploy"
+  command = "ultramodern deploy"
 
 [functions]
   directory = ".netlify/functions"
@@ -173,7 +173,7 @@ Add the following script in `packages/app/package.json`, before executing the de
 {
   "scripts": {
     "build:packages": "pnpm --filter 'app^...' run build",
-    "deploy": "pnpm run build:packages && modern deploy"
+    "deploy": "pnpm run build:packages && ultramodern deploy"
   }
 }
 ```
@@ -213,7 +213,7 @@ Add the following content to `vercel.json`:
 
 ```json title="vercel.json"
 {
-  "buildCommand": "modern deploy",
+  "buildCommand": "ultramodern deploy",
   "outputDirectory": ".vercel/output"
 }
 ```
@@ -281,7 +281,7 @@ Add the following script to `packages/app/package.json` to run `build` command o
 {
   "scripts": {
     "build:packages": "pnpm --filter 'app^...' run build",
-    "deploy": "pnpm run build:packages && modern deploy"
+    "deploy": "pnpm run build:packages && ultramodern deploy"
   }
 }
 ```
@@ -326,7 +326,7 @@ For branch deployment, follow these steps:
 ```
 "scripts": {
   //...
-  "deploy:gh-pages": "MODERNJS_DEPLOY=ghPages modern deploy && gh-pages -d .output"
+  "deploy:gh-pages": "MODERNJS_DEPLOY=ghPages ultramodern deploy && gh-pages -d .output"
 }
 ```
 
@@ -334,7 +334,7 @@ For branch deployment, follow these steps:
 
 :::info
 
-1. Running `MODERNJS_DEPLOY=ghPages modern deploy` will build the production output for GitHub in the .output directory.
+1. Running `MODERNJS_DEPLOY=ghPages ultramodern deploy` will build the production output for GitHub in the .output directory.
 2. You can refer to the [project](https://github.com/web-infra-dev/modern-js-examples/tree/main/examples/modern-js-deploy-csr)
    :::
 

package/docs/en/guides/basic-features/env-vars.mdx

@@ -16,8 +16,8 @@ The current path prefix of the asset, which is a read-only environment variable.
 
 The current execution environment and is a **read-only** environment variable whose have different values under different execution commands:
 
-- `production`: Default value when running `modern build` or `modern serve`.
-- `development`: Default value when running `modern dev`, also the default value in other cases.
+- `production`: Default value when running `ultramodern build` or `ultramodern serve`.
+- `development`: Default value when running `ultramodern dev`, also the default value in other cases.
 
 ### MODERN_ENV
 

package/docs/en/guides/basic-features/routes/config-routes.mdx

@@ -271,7 +271,7 @@ Config routes can be used together with convention routes. You can merge routes
 
 :::info
 
-Current route structure can be viewed through the [`modern routes`](#debugging-routes) command
+Current route structure can be viewed through the [`ultramodern routes`](#debugging-routes) command
 
 :::
 
@@ -319,7 +319,7 @@ Since the final structure after route merging may not be intuitive, Modern.js pr
 
 ```bash
 # Generate route structure analysis report
-npx modern routes
+npx ultramodern routes
 ```
 
 This command will generate the final route structure in the `dist/routes-inspect.json` file, helping you understand the complete route information after merging.

package/docs/en/guides/basic-features/routes/routes.mdx

@@ -464,7 +464,7 @@ When defining a `loading.tsx`, if the route transitions from `/` to `/blog` or f
 
 ## Prefetching
 
-Most white screens during route transitions can be optimized by defining a `<Loading>` component. Modern.js also supports preloading static resources and data with the `prefetch` attribute on `<Link>` components.
+Most white screens during route transitions can be optimized by defining a `<Loading>` component. Modern.js also supports navigation warmup with the `prefetch` and `preload` attributes on `<Link>` components.
 
 For applications with higher performance requirements, prefetching can further enhance the user experience by reducing the time spent displaying the `<Loading>` component:
 
@@ -474,21 +474,36 @@ For applications with higher performance requirements, prefetching can further e
 
 :::tip
 
-Data preloading currently only preloads data returned by the [Data Loader](/guides/basic-features/data/data-fetch) in SSR projects.
+Route data warmup is opt-in. In SSR projects, data returned by the [Data Loader](/guides/basic-features/data/data-fetch) is only prefetched when the matched route explicitly enables it with `handle.navigationWarmup.data`.
 
 :::
 
-The `prefetch` attribute has three optional values:
+By default, same-origin links prefetch the route module when the `<Link>` renders and preload when the link enters the viewport. Modern.js skips these automatic warmups on Save-Data or slow network connections.
 
-- `none`: The default value. No prefetching, no additional behavior.
-- `intent`: This is the recommended value for most scenarios. When you hover over the Link, it will automatically start loading the corresponding chunk and the data defined in the Data Loader. If the mouse moves away, the loading is automatically canceled. In our tests, even quick clicks can reduce load time by approximately 200ms.
-- `render`: When the `<Link>` component is rendered, it begins loading the corresponding chunk and data defined in the Data Loader.
+The `prefetch` attribute has four optional values:
+
+- `render`: The default value. When the `<Link>` component is rendered, it begins warming the corresponding route module.
+- `intent`: When users focus, hover, or touch the link, it starts warming the corresponding route module. If the intent is canceled before warmup starts, the warmup is canceled.
+- `viewport`: When the `<Link>` component enters the viewport, it begins warming the corresponding route module.
+- `none`: Disables automatic render prefetching. It also disables the default viewport preload unless an explicit `preload` value is provided.
+
+The `preload` attribute accepts the same timing values and defaults to `viewport`. Explicit `preload` values always win, and `preload={false}` disables preload behavior.
+
+To opt a route into SSR data warmup:
+
+```ts title="routes/page.config.ts"
+export const handle = {
+  navigationWarmup: {
+    data: true,
+  },
+};
+```
 
 :::details Difference Between "render" and Not Using Route Splitting
 
-- `render` allows you to control the timing of route splitting, triggering only when the `<Link>` component enters the viewport. You can control the loading timing of the split by adjusting the rendering position of the `<Link>` component.
-- `render` loads static resources only during idle times, thus not occupying the loading time of critical modules.
-- Besides preloading route splits, `render` will also initiate data prefetching in SSR projects.
+- `render` allows you to control route-module warmup with the position of the `<Link>` component in the tree.
+- `viewport` lets you defer module warmup until the link is close to becoming actionable.
+- SSR data prefetching is not enabled by default; use `handle.navigationWarmup.data` only for routes whose loader data is safe and useful to fetch before navigation.
 
 :::
 

package/docs/en/guides/basic-features/testing/_meta.json

@@ -1 +1 @@
-["playwright", "rstest", "vitest", "jest", "cypress"]
+["rstest", "playwright"]

package/docs/en/guides/concept/server.mdx

@@ -26,10 +26,10 @@ Static asset files can be directly hosted by Modern.js' server, but it is highly
 
 Modern.js supports running built artifacts in any Node.js environment. Typically, the CI environment has already installed all application dependencies.
 
-You can run the [`modern build`](/apis/app/commands#modern-build) command to build the application and the [`modern serve`](/apis/app/commands#modern-serve) command to run the Web server, starting the Modern.js application.
+You can run the [`ultramodern build`](/apis/app/commands#ultramodern-build) command to build the application and the [`ultramodern serve`](/apis/app/commands#ultramodern-serve) command to run the Web server, starting the UltraModern.js application.
 
 ## Running in Production Environments
 
 When deploying to production, the artifact size should be as small as possible. The aforementioned method for running in CI environments keeps all artifacts from the original project. Therefore, it is not recommended to run the application using the above commands in a production environment.
 
-Modern.js offers a standalone deployment solution. When running the [`modern deploy`](/apis/app/commands#modern-deploy) command, the artifacts will include an entry file for running the Web server.
+UltraModern.js offers a standalone deployment solution. When running the [`ultramodern deploy`](/apis/app/commands#ultramodern-deploy) command, the artifacts will include an entry file for running the Web server.

package/docs/en/guides/get-started/quick-start.mdx

@@ -27,7 +27,7 @@ import DebugApp from '@site-docs-en/components/debug-app';
 
 ## Configuration
 
-In a Modern.js project created using `@modern-js/create`, a `modern.config.ts` file is generated by default.
+In an UltraModern.js project created using `@bleedingdev/modern-js-create`, a `modern.config.ts` file is generated by default.
 
 You can modify the configuration through this file to override the default behavior of Modern.js. For example, to enable SSR, add the following configuration:
 
@@ -48,7 +48,7 @@ After running `pnpm run dev` again, you can find that the project has completed
 
 In a newly created project, the `@modern-js/app-tools` npm package is installed by default. It is the core package of the Modern.js framework and provides the following capabilities:
 
-- It offers commonly used CLI commands such as `modern dev`, `modern build`, and more.
+- It offers commonly used CLI commands such as `ultramodern dev`, `ultramodern build`, and more.
 - It integrates Rsbuild, providing build capabilities.
 - It integrates Modern.js Server, providing capabilities for development and production servers.
 

package/docs/en/guides/get-started/tech-stack.mdx

@@ -18,13 +18,13 @@ Rsbuild supports building Vue applications. If you need to use Vue, you can refe
 
 Modern.js provides two first-party routing frameworks:
 
-- [React Router v7](https://reactrouter.com/en/main) (default), via `@modern-js/runtime/router`.
-- [TanStack Router](https://tanstack.com/router), via `@modern-js/plugin-tanstack/runtime`.
+- [TanStack Router](https://tanstack.com/router) (UltraModern default), via `@modern-js/plugin-tanstack/runtime`.
+- [React Router v7](https://reactrouter.com/en/main) (compatibility path), via `@modern-js/runtime/router`.
 
-When creating a project, you can choose TanStack Router by using:
+When creating an UltraModern project, TanStack Router is included by default:
 
 ```bash
-npx @modern-js/create@latest myapp --router tanstack
+pnpm dlx @bleedingdev/modern-js-create myapp
 ```
 
 Modern.js supports conventional routing, self-controlled routing, or other routing schemes. Please refer to ["Routing"](/guides/basic-features/routes/routes) to make your choice.
@@ -84,6 +84,12 @@ Modern.js can be used with any React UI component library from the community, su
 
 Modern.js supports the use of [Storybook](https://storybook.js.org/) for developing UI components. This feature is optional. Please refer to ["Using Storybook"](/guides/basic-features/debug/using-storybook) to enable it.
 
+## Testing Framework
+
+Modern.js recommends [Rstest](https://rstest.rs/) for unit tests and component tests. Rstest is built on Rspack for fast startup and execution, and it can reuse your Modern.js app configuration through [`@modern-js/adapter-rstest`](/guides/basic-features/testing/rstest).
+
+For end-to-end (E2E) tests, you can use [Playwright](/guides/basic-features/testing/playwright).
+
 ## Node.js Framework
 
 import TechStackNodeFramework from '@site-docs-en/components/tech-stack-node-framework';

package/docs/en/guides/get-started/ultramodern.mdx

@@ -36,11 +36,11 @@ UltraModern.js additions are designed as the default product surface for new Sup
 | BFF runtime choices | Hono runtime path only in Modern.js 3.0 baseline (no built-in Effect runtime path) | Sets Effect as default runtime, enforces strict runtime split (`effect` -> `api/effect`, `hono` -> `api/lambda`), and adds Effect-Schema-first contracts plus MF failure-injection reliability coverage |
 | Telemetry standardization | Observability wiring is often app-specific | Adds framework-level telemetry pipeline with OTLP/VictoriaMetrics exporters, redaction, batching, and backpressure controls |
 | App-level MF SSR handshake | No dedicated super-app app-level stability contract focus | Adds `server.ssr.moduleFederationAppSSR` plus integration-tested env/config handshake |
-| MF remote reliability | Retry/fallback patterns are often implemented per app | Adds deterministic timeout/network/contract-error reliability matrix and distributed OTEL continuity tests |
+| MF vertical loading reliability | Retry/fallback patterns are often implemented per app | Adds deterministic timeout/network/contract-error reliability matrix and distributed OTEL continuity tests |
 | Module onboarding governance | No module-certification evidence profile in baseline | Adds module SDK contracts, boundary anti-pattern guards, and release/module certification gate workflows |
 | Router runtime | Default runtime path centers on React Router | Adds first-class TanStack Router runtime/CLI path (React Router remains supported) |
-| Scaffolding templates | Default create templates center on React Router starter path | Adds TanStack-ready and Tailwind-ready create templates |
-| Starter preset enforcement | No generated UltraModern preset gate workflow | Generated starters include `ultramodern:check`, opt-out env switches, and `.github/workflows/ultramodern-gates.yml` |
+| Scaffolding templates | Default create templates center on React Router starter path | Generates a SuperApp workspace by default with TanStack, Effect, Module Federation, i18n, Tailwind, Cloudflare, and ownership contracts |
+| Workspace preset enforcement | No generated UltraModern preset gate workflow | Generated workspaces include `.github/workflows/ultramodern-workspace-gates.yml`, `pnpm check`, primitive local gates, and generated contract validation |
 
 ## What We Intentionally Do Not Change
 
@@ -56,25 +56,93 @@ For teams already on Modern.js 3.0, the adoption path remains compatibility-awar
 1. Keep existing React Router apps running as-is. TanStack Router is the preferred path for new scaffolds and incremental route adoption, but the React Router lane remains supported while teams move on their own schedule.
 2. Prefer `bff.runtimeFramework: 'effect'` for new BFF work, with the entry implemented at `api/effect/index.ts`. If your app already uses Hono handlers under `api/lambda/**`, keep `bff.runtimeFramework: 'hono'` until you are ready to move them; Hono remains a supported compatibility lane.
 3. Treat the baseline contracts as progressive defaults, not a forced cutover. `MODERN_BASELINE_ENABLE_MF_SSR`, `MODERN_BASELINE_ENABLE_BFF_REQUEST_ID`, and `MODERN_BASELINE_ENABLE_TELEMETRY_EXPORTERS` already let each app opt out while it converges on the preferred stack.
-4. The public preset now ships with explicit release and certification gates. The generated starter also ships `.github/workflows/ultramodern-gates.yml`, so `pnpm run ultramodern:check` and `pnpm run build` stay part of the adoption contract from day one.
+4. The public preset now ships with explicit release and certification gates. Generated workspaces include `.github/workflows/ultramodern-workspace-gates.yml`, so `pnpm check` and `pnpm build` stay part of the local adoption contract from day one while CI runs the primitive gates as parallel matrix jobs.
 
 This page is not a migration guide or codemod plan. Migration guidance for existing applications is intentionally deferred from the current Micro Verticals framework scope.
 
-## Micro Vertical Delivery Path
-
-`presetUltramodern(...)` is also the single public entrypoint for Micro Verticals. The intended adoption sequence is:
-
-1. start with one app and keep route/data ownership inside the shell,
-2. extract stable route subtrees into MF remotes once fallback and compatibility behavior are explicit,
-3. extract shared workflows into strict Effect services when request, identity, locale, and trace context must survive deployment boundaries,
-4. keep Hono only as an explicit compatibility lane for existing Modern.js-style BFF handlers.
-
-In this repo, the reference examples are:
-
-- `routes-tanstack-mf` for shell + remote composition and MF SSR contracts,
-- `bff-corss-project` for cross-project producer/consumer wiring,
-- `bff-runtime-parity` for generated-client build/serve parity,
-- `bff-hono` for the compatibility lane.
+## Human Workflow
+
+The public BleedingDev create package has one supported generated product. The
+default command creates a production-ready UltraModern SuperApp workspace with
+`presetUltramodern(...)`, SSR, TanStack Router, Tailwind CSS v4, i18n, Effect
+BFF, Module Federation topology, generated quality gates, and Cloudflare deploy
+basics:
+
+```bash
+pnpm dlx @bleedingdev/modern-js-create myapp
+cd myapp
+mise install
+mise exec -- pnpm install
+mise exec -- pnpm check
+```
+
+The workspace starts from a shell and generated platform contracts. It does not
+generate a demo domain by default. Add real business MicroVerticals when they
+become real ownership boundaries:
+
+```bash
+pnpm dlx @bleedingdev/modern-js-create transportation --vertical
+pnpm dlx @bleedingdev/modern-js-create food-delivery --vertical
+pnpm dlx @bleedingdev/modern-js-create payments --vertical
+pnpm dlx @bleedingdev/modern-js-create maps --vertical
+mise exec -- pnpm check
+```
+
+The `--vertical` command mutates the current workspace. It creates the vertical
+package and updates topology metadata, ownership records, shell Module
+Federation wiring, local development overlays, package dependencies, generated
+contracts, ports, route-owned i18n, CSS isolation, and the vertical-owned Effect
+BFF/client surface.
+
+### Runtime Contracts
+
+Generated apps and verticals keep SSR on the normal Modern.js path. SuperApp
+workspaces add `server.ssr.moduleFederationAppSSR` when Module Federation SSR is
+needed, but the flag remains an explicit contract rather than a requirement for
+every app.
+
+Each app emits `src/routes/ultramodern-route-metadata` with
+`ultramodernLocalisedUrls`. The i18n plugin reads that map in
+`localeDetection.localisedUrls` and serves dynamic backend JSON from
+`/locales/{{lng}}/{{ns}}.json`. The route owner changes localized paths and
+locale resource JSON together.
+
+The generated contract writes `.modernjs/ultramodern-generated-contract.json`
+with a `cssFederation` section:
+
+- `packages/shared-design-tokens` owns the shared token layer and exports `./tokens.css`.
+- Shell CSS owns only shell base and overlay layers under `[data-app-id="shell-super-app"]`.
+- Each vertical owns one CSS layer, for example `[data-app-id="vertical-transportation"]` with app-local class prefixes.
+- Tailwind CSS v4 is local to each generated app through `@tailwindcss/postcss`; shared base styles must not be duplicated by verticals.
+- SSR first paint requires shared token CSS and app-owned CSS to be emitted by Modern/Rspack assets. Vertical CSS is loaded through manifest ownership, not copied into shell source.
+
+Version switching must select UI, Effect API, CSS, i18n JSON, and MF manifest evidence from the same vertical build marker. A shell render that only changes the UI marker is not enough.
+
+### Validation And Deploy
+
+Local gates:
+
+```bash
+mise exec -- pnpm check
+mise exec -- pnpm build
+mise exec -- pnpm cloudflare:build
+```
+
+Generated workspaces include `scripts/proof-cloudflare-version.mjs` for live
+Cloudflare and Zephyr proof:
+
+```bash
+ULTRAMODERN_PUBLIC_URL_SHELL_SUPER_APP=https://shell-super-app.example.workers.dev \
+ULTRAMODERN_PUBLIC_URL_TRANSPORTATION=https://transportation.example.workers.dev \
+ULTRAMODERN_PUBLIC_URL_PAYMENTS=https://payments.example.workers.dev \
+mise exec -- pnpm cloudflare:proof -- --require-public-urls
+```
+
+Live Cloudflare and Zephyr proof requires public Worker URLs and Zephyr credentials. Without those, the repo can validate generated contracts, local builds, local Cloudflare output, dry-run Zephyr evidence plans, and local evidence schemas, but it cannot prove shell-driven live version selection.
+
+BleedingDev packages are published through GitHub Actions trusted publishing.
+The public workflow is tokenless; do not publish packages manually from a
+developer machine.
 
 ## Baseline Switches (Opt-out)
 

package/docs/en/guides/topic-detail/module-federation/application.mdx

@@ -103,7 +103,7 @@ export default RemoteApp;
 
 ## Start the Application
 
-Now, both the producer and consumer applications are set up. We can run `modern dev` locally to start both applications.
+Now, both the producer and consumer applications are set up. We can run `ultramodern dev` locally to start both applications.
 
 After startup, when the consumer application accesses the `/remote` route, it will enter the producer application. Accessing `http://localhost:8080/remote` will display a complete page of the producer's remote module in the browser.
 

package/docs/en/guides/topic-detail/module-federation/deploy.mdx

@@ -88,10 +88,10 @@ export default createModuleFederationConfig({
 
 ## Local Deployment Verification
 
-Modern.js provides the `modern deploy` command, which can easily generate products that can run in a Node.js environment.
+Modern.js provides the `ultramodern deploy` command, which can easily generate products that can run in a Node.js environment.
 
 ```bash
-modern deploy
+ultramodern deploy
 ```
 
 After executing the command, you can see the following output in the console:

package/docs/en/guides/topic-detail/module-federation/usage.mdx

@@ -154,7 +154,7 @@ The second part, `remoteExpose`, is the `key` configured in the `exposes` field
 
 ## Start the Applications
 
-Now, both the producer and consumer applications are set up. You can run `modern dev` locally to start both applications.
+Now, both the producer and consumer applications are set up. You can run `ultramodern dev` locally to start both applications.
 
 Once started, the imports of the producer's modules in the consumer will no longer throw errors, and the types will be downloaded to the consumer application.
 
@@ -164,7 +164,7 @@ After modifying the producer's code, the consumer will automatically fetch the p
 
 Access `http://localhost:8080/remote`, and you will see that the page includes the `Button` component from the producer's remote module.
 
-We can also execute `modern serve` locally to simulate the production environment.
+We can also execute `ultramodern serve` locally to simulate the production environment.
 
 Because the Module Federation plugin will automatically read Modern.js's `output.assetPrefix` configuration as the access address for remote modules, and this value defaults to `/` after building in the production environment.
 
@@ -180,7 +180,7 @@ export default defineConfig({
     port: 3051,
   },
   output: {
-    // Now this configuration is only used in the local when you run modern serve command.
+    // Now this configuration is only used in the local when you run ultramodern serve command.
     // If you want to deploy the application to the platform, use your own domain name.
     // Module federation will automatically write it to mf-manifest.json, which influences consumer to fetch remoteEntry.js.
     assetPrefix: 'http://127.0.0.1:3051',
@@ -189,10 +189,10 @@ export default defineConfig({
 });
 ```
 
-Now, in the producer, run `modern build && MODERN_MF_AUTO_CORS=true  modern serve`, and in the consumer, run `modern build && modern serve` to simulate the production environment locally and access the remote modules.
+Now, in the producer, run `ultramodern build && MODERN_MF_AUTO_CORS=true  ultramodern serve`, and in the consumer, run `ultramodern build && ultramodern serve` to simulate the production environment locally and access the remote modules.
 
 :::tip
-When using the `modern serve` command, you need to set the `MODERN_MF_AUTO_CORS=true` environment variable when starting the producer project to automatically handle CORS issues and ensure that consumers can properly access the producer's remote module resources.
+When using the `ultramodern serve` command, you need to set the `MODERN_MF_AUTO_CORS=true` environment variable when starting the producer project to automatically handle CORS issues and ensure that consumers can properly access the producer's remote module resources.
 :::
 
 You can refer to this example: [Modern.js & Module Federation Basic Example](https://github.com/web-infra-dev/modern-js-examples/tree/main/examples/module-federation/base).

package/docs/en/guides/troubleshooting/builder.mdx

@@ -23,7 +23,7 @@ Modern.js is internally based on [Rsbuild](https://v2.rsbuild.rs/) and encapsula
 Modern.js provides [inspect command](https://modernjs.dev/en/apis/app/commands.html) to view the final Modern.js configuration and Rspack configuration generated by the project.
 
 ```bash
-➜ npx modern inspect
+➜ npx ultramodern inspect
 
 Inspect config succeed, open following files to view the content:
 

package/docs/en/guides/upgrade/other.mdx

@@ -87,14 +87,14 @@ Modern.js 3.0 uses React Router v7 as the default routing library. React Router
 
 If you need to use React Router v5 or React Router v6, you need to use **self-controlled routing** mode. Self-controlled routing allows you to fully control routing configuration without being limited by Modern.js convention-based routing.
 
-## Using @modern-js/create to Create Monorepo and Modern.js Module
+## Using @bleedingdev/modern-js-create to Create Monorepo and Modern.js Module
 
-Modern.js 3.0 no longer supports creating Monorepo projects and Modern.js Module projects through `@modern-js/create`.
+Modern.js 3.0 no longer supports creating Monorepo projects and Modern.js Module projects through `@bleedingdev/modern-js-create`.
 
 **Changes**:
 
-- In [v2.53.0](https://github.com/web-infra-dev/modern.js/releases/tag/v2.53.0), the functionality to create Monorepo projects using `@modern-js/create` was removed
-- In [v2.61.0](https://github.com/web-infra-dev/modern.js/releases/tag/v2.61.0), the functionality to create Modern.js Module projects using `@modern-js/create` and `modern new` commands was removed
+- In [v2.53.0](https://github.com/web-infra-dev/modern.js/releases/tag/v2.53.0), the functionality to create Monorepo projects using `@bleedingdev/modern-js-create` was removed
+- In [v2.61.0](https://github.com/web-infra-dev/modern.js/releases/tag/v2.61.0), the functionality to create Modern.js Module projects using `@bleedingdev/modern-js-create` and `ultramodern new` commands was removed
 
 **Handling**:
 
@@ -103,12 +103,12 @@ Modern.js 3.0 no longer supports creating Monorepo projects and Modern.js Module
 
 ## new and upgrade Commands Removed
 
-Modern.js 3.0 removed the `modern new` and `modern upgrade` commands, and you need to perform operations manually according to the documentation.
+Modern.js 3.0 removed the `ultramodern new` and `ultramodern upgrade` commands, and you need to perform operations manually according to the documentation.
 
 **Changes**:
 
-- The `modern new` command is no longer supported in Modern.js 3.0, and you cannot add entries or enable features through commands
-- The `modern upgrade` command is no longer supported in Modern.js 3.0, and you cannot automatically upgrade dependencies through commands
+- The `ultramodern new` command is no longer supported in Modern.js 3.0, and you cannot add entries or enable features through commands
+- The `ultramodern upgrade` command is no longer supported in Modern.js 3.0, and you cannot automatically upgrade dependencies through commands
 
 **Handling**: