create-vitnode-app 2.0.0-canary.2 → 2.0.0-canary.4

package/copy-of-vitnode-app/root/src/router.tsx

@@ -14,28 +14,8 @@ import {
   withCoreRootRoutes,
 } from "@vitnode/core/tanstack/routes";
 
-/**
- * The auth transport, registered by importing the module that declares it.
- *
- * `@vitnode/core/tanstack/auth` owns every auth decision this app makes but may
- * not declare a `createServerFn` - uncompiled on the server, one silently
- * resolves to `undefined` - so `lib/auth.ts` declares the eight wrappers and
- * hands them over at module scope. A bare import because there is nothing to
- * name: the registration *is* the module's effect.
- *
- * Here because a router is the one module both entry points load, so the
- * registration has happened before any route, loader or component can reach for
- * it, in the browser bundle and on the server alike.
- */
 import "./lib/auth";
-/**
- * The admin transport, registered the same way and for the same reason.
- *
- * One server function rather than eight, reading the AdminCP's own session under
- * its own cookie. It is a separate registration from the auth one on purpose:
- * they are two sessions, two cookies and two cache entries, and nothing in
- * VitNode may let the public session answer an admin question.
- */
+
 import "./lib/admin-auth";
 import { createLocaleRewrite, localeRouting } from "./lib/i18n/runtime";
 import { pageHead } from "./lib/page-head";
@@ -44,160 +24,26 @@ import { Route as adminShellRoute } from "./routes/_admin";
 import { Route as mainShellRoute } from "./routes/_main";
 import { routeTree as fileRouteTree } from "./routeTree.gen";
 
-/**
- * The Content Engine registry, behind a literal dynamic import.
- *
- * Awaited by the one loader that needs it - `/admin/content/*` - rather than
- * imported here. Building the registry reaches `@vitnode/core/content` and
- * every configured plugin's admin form components, and this module is the one
- * the client entry evaluates on every page: as a static import it put `zod`,
- * every plugin's content registrations, the content form primitives and
- * `react-hook-form` in front of the front page's first paint. See
- * `CoreAdminRouteContext.loadContentRegistry`.
- */
 const loadContentRegistry = async () =>
   (await import("./lib/content-registry")).contentRegistry;
 
-/**
- * One route tree: this app's route files, plus the AdminCP screens `@vitnode/core`
- * owns, plus the pages its plugins declare.
- *
- * At module scope rather than inside `getRouter`, because `getRouter` runs once
- * per server request and mounting the plugin routes mutates the route tree - the
- * generated tree is a module singleton. `withPluginRoutes` is idempotent anyway;
- * doing it once is simply where it belongs.
- *
- * The plugin half comes from one generated file: a static import of each
- * configured plugin's own route tree. No plugin page is copied into
- * `src/routes`, no route path is written by hand, and nothing here knows which
- * plugins are installed - see `@vitnode/core/tanstack/plugin-routes`.
- *
- * A page is reached only through the literal `lazy(() => import(...))` its route
- * declared, so every one of them is a chunk of its own. The one part of a plugin
- * route that is not lazy is a `search` schema: a router's `validateSearch` runs
- * during path matching, before any chunk is fetched, so it lives in the tree
- * rather than in the page.
- *
- * `mountUnder` names one route per shell, which is the whole of what "a plugin
- * route renders in the application shell" amounts to here. A plugin declares
- * `area: "main"` or `area: "admin"`; `_main` is the route that renders the
- * public shell and `_admin` the one that renders the AdminCP, and being a child
- * of one of them is what gives `/example` the header and the one `<main>` that
- * `/discover` has, or gives `/admin/reports` the sidebar, the breadcrumb area
- * and the admin session guard that `/admin/core` has. No new field, no per-route
- * layout metadata and no second copy of either shell - route composition, which
- * the area declaration already described.
- *
- * Neither shell changes a path: both are pathless, so `/example` stays
- * `/example` and an admin plugin route's `/admin/…` is the path its own route
- * spells out in full. An area VitNode knows and this app has not named here
- * fails the composition rather than being mounted under the other one.
- *
- * `_main` and `_admin` are imported for their route objects, and they are the
- * same objects the generated tree holds: `createFileRoute` produces one instance
- * per module and `routeTree.gen.ts` mutates it in place.
- *
- * `withCoreMainRoutes`, `withCoreAdminRoutes` and `withCoreRootRoutes` mount
- * core's own screens the same way, one per mount point: the public pages under
- * the main shell, the AdminCP's under its own, and the shell-less ones - the auth
- * cards and the AdminCP sign-in - straight under the root.
- *
- * They were twenty-nine route files in this application until
- * `@vitnode/core/tanstack/routes` existed, every one of them pure wiring around
- * something imported from the package - so an app carried a copy of VitNode's own
- * routing table and core adding a screen meant an edit here. They are code-based
- * rather than declared as plugin routes because they need the router's full
- * option set: a real `validateSearch` that clamps `?page=999` before anything
- * renders, a `beforeLoad` guard that runs before any chunk is fetched, and a
- * splat path a plugin route path does not represent.
- *
- * `localeRouting` goes to the last of the three because a sign-in navigates to a
- * path a *visitor* supplied: the route tree carries no locale, so the prefix has
- * to be stripped before the router sees it, and which prefixes exist is this
- * app's answer. It is the same object the `rewrite` below uses.
- *
- * `pageHead` is this app's own `createRouteHead(metadata)` binding, handed over
- * because a package cannot know the site's name: a plugin page's `<title>` goes
- * through the same `"<page> - <site>"` rule every other VitNode page's does,
- * rather than through a second one the plugin invented.
- */
 const routeTree = withCoreRootRoutes(
   withCoreAdminRoutes(
     withCoreMainRoutes(
-      withPluginRoutes(
-        fileRouteTree,
-        pluginRouteSpecs(pluginRouteSources),
-        {
-          mountUnder: { admin: adminShellRoute, main: mainShellRoute },
-          pageHead,
-        },
-      ),
-      { mountUnder: mainShellRoute, pageHead },
+      withPluginRoutes(fileRouteTree, pluginRouteSpecs(pluginRouteSources), {
+        mountUnder: { admin: adminShellRoute, main: mainShellRoute },
+        pageHead,
+      }),
+      { localeRouting, mountUnder: mainShellRoute, pageHead },
     ),
     { loadContentRegistry, mountUnder: adminShellRoute, pageHead },
   ),
   { localeRouting, mountUnder: fileRouteTree, pageHead },
 );
 
-/**
- * The app's router, and the QueryClient it owns.
- *
- * Start calls this once per server request and once in the browser, which is
- * exactly the lifetime a QueryClient should have: created here, it is per
- * request on the server - never a module-level client shared by every visitor
- * being rendered at once - and a single long-lived one on the client.
- *
- * It goes into the router context, so a route loader reaches it as
- * `context.queryClient` and can `ensureQueryData` before its component renders.
- * That is the whole point of putting it here rather than in a provider: a
- * loader runs before React does, so a client mounted by a component would be
- * out of reach of the code that most wants it.
- *
- * `setupRouterSsrQueryIntegration` wires the two together: it dehydrates the
- * cache into the SSR stream (including queries that resolve mid-render),
- * hydrates it on the client before the first render, routes `redirect()` thrown
- * inside a query or mutation through the router, and wraps the app in the one
- * `QueryClientProvider` for this client. Nothing else in this app may create a
- * `QueryClient` or a provider for one - two clients in a page means a query a
- * loader cached is invisible to the component that reads it.
- *
- * `defaultPreloadStaleTime: 0` leaves caching to Query rather than having the
- * router keep a second copy of the same data with its own expiry.
- *
- * `defaultStaleReloadMode: 'blocking'` is what makes a route's pending shape
- * reachable at all once preloading is on. Router core's default is
- * `'background'`, and a background reload never opens a pending window - but it
- * still waits for the route's component chunk before it commits. So the common
- * desktop path, hover a link and click it, took the one branch that renders
- * nothing: the hover filled the loader, the click was therefore a background
- * reload, and the chunk downloaded with the previous page still on screen and
- * no skeleton in sight.
- *
- * It costs nothing here because a VitNode loader does not block on a warm cache:
- * `ensureQueryData` with `revalidateIfStale` hands back the cached entry and
- * refreshes behind it, so "blocking" describes a promise that resolves in a
- * microtask. What changes is only that the router now marks the match pending
- * while that happens, which is what `defaultPendingMs` is for.
- *
- * `defaultPendingMs: 150` is that threshold, and it is not zero for the same
- * reason. At zero, every navigation opens a pending window, so
- * `defaultPendingMinMs` holds a *fully cached* navigation behind a skeleton for
- * 300ms - a page that could have been instant, made slow to look busy. At 150ms
- * a cached navigation goes straight through with nothing shown and a slow one
- * still gets its shape, in the content area and the breadcrumb together.
- *
- * `rewrite` is what makes one route tree serve two public URL shapes: `/pl/...`
- * arrives, `/...` is matched, and every link the router builds gets the prefix
- * back. No route file mentions a locale, so nothing here has to be duplicated
- * per language - see `@vitnode/core/tanstack/i18n`.
- */
 export function getRouter() {
   const queryClient = createVitNodeQueryClient();
 
-  // The rewrite reads the locale off the router's own current location, and the
-  // router needs the rewrite to parse that location - so it is handed a getter
-  // rather than the router itself. `output` only ever runs once a link is built,
-  // which is long after the assignment below.
   const holder: { current?: AnyRouter } = {};
 
   const router = createTanStackRouter({

package/copy-of-vitnode-app/root/src/routes/__root.tsx

@@ -30,27 +30,11 @@ import appCss from "../styles.css?url";
 
 const { debug, i18n, metadata, theme } = vitNodeConfig;
 
-/**
- * What the router itself provides, before any route has run.
- *
- * The QueryClient, and nothing else. `beforeLoad` below adds `locale` on top, so
- * what a loader actually receives is `{ queryClient, locale }` - the language
- * included, because a loader that fetches anything user-facing needs to know
- * which one it is fetching.
- */
 export interface RootRouterContext {
   queryClient: QueryClient;
 }
 
 export const Route = createRootRouteWithContext<RootRouterContext>()({
-  /**
-   * The request's language, resolved once and handed to every loader below.
-   *
-   * The same function the rewrite and the components use, so there is one answer
-   * per request rather than one per consumer. Note that a language switch does
-   * not change the *internal* URL - only the public one - so the switcher
-   * invalidates the router to bring this back in step.
-   */
   beforeLoad: ({ location }) => ({
     locale: resolveLocale<Locale>(publicPathnameOf(location)),
   }),
@@ -58,16 +42,7 @@ export const Route = createRootRouteWithContext<RootRouterContext>()({
   head: () => ({
     links: [
       { href: appCss, rel: "stylesheet" },
-      /*
-       * The tab icon, from `public/favicon.ico`.
-       *
-       * Stated rather than left to the browser's automatic `/favicon.ico`
-       * request, because that request is a 404 until the file exists and a
-       * silently missing icon is easy to never notice. Drop your own 32px `.ico`
-       * at `public/favicon.ico`; it lives there rather than being imported so
-       * that the URL is stable and the file is still reachable at the well-known
-       * path browsers ask for unprompted.
-       */
+
       {
         href: "/favicon.ico",
         rel: "icon",
@@ -78,80 +53,22 @@ export const Route = createRootRouteWithContext<RootRouterContext>()({
     meta: [
       { charSet: "utf-8" },
       { content: "width=device-width, initial-scale=1", name: "viewport" },
-      // The default title, from the app's config. A route that names itself
-      // renders `"<page> - <shortTitle>"` instead, through `formatPageTitle` -
-      // the same rule Next.js applies through `title.template`.
       { title: metadata.title },
     ],
   }),
-  /**
-   * Warm this language's shell strings before anything renders.
-   *
-   * `context.locale` rather than a default: `/pl` has to arrive with Polish
-   * already in the cache, or the first paint is English and the page flips after
-   * hydration.
-   */
   loader: async ({ context }) => {
     await context.queryClient.ensureQueryData(
       intlQueryOptions({ locale: context.locale }),
     );
   },
-  /**
-   * Every URL this application does not serve.
-   *
-   * The last resort, and until now there was none: a path that matched no route
-   * at all fell through to TanStack Router's own `<p>Not Found</p>` - no shell,
-   * no strings, no way back - and the router warned about the missing option on
-   * every such navigation. `/admin/contents` and a hand-typed `/blog/post-30`
-   * both landed there.
-   *
-   * ## What reaches it, and what does not
-   *
-   * Only a path **no route matched**. A route that matched and then answered
-   * `notFound()` from its own loader is caught by the nearest
-   * `notFoundComponent` above it, which is why `/admin/content/nope` and
-   * `/admin/content/blog/articles/999999/edit` render the AdminCP's 404 inside
-   * the panel rather than this - see `_admin`'s, which mounts the shell around
-   * the same message.
-   *
-   * ## It is a 404, and not a redirect anywhere
-   *
-   * The route tree is the whole application, so a URL that reaches here is one
-   * somebody typed or a stale bookmark, and saying so is the honest answer.
-   * Bouncing an unmatched path at some other origin would hide a genuinely
-   * missing page behind a hop to a server that 404s it anyway. Where a URL is
-   * served from is a deployment question, and a proxy in front of the app
-   * answers it better than this route can.
-   */
   notFoundComponent: RootNotFound,
   shellComponent: RootDocument,
 });
 
-/**
- * Rendered inside `RootComponent`, which is what makes the strings work: the
- * providers it mounts include `RouteMessages` with `core.global`, and that is
- * the namespace `NotFound` reads its two lines from. The root's loader has
- * already warmed that entry, so nothing suspends.
- */
 function RootNotFound() {
   return <NotFound actions={<ErrorActions />} />;
 }
 
-/**
- * The VitNode provider tree, mounted once above every route.
- *
- * Every provider in it is shared with the Next.js app - the theme, the toaster,
- * the tooltip provider, the WebSocket - plus the pair of `use-intl` records that
- * only a package can name. `VitNodeRootProviders` owns all of it, including the
- * argument for why the realtime listeners are inside it rather than in the main
- * shell.
- *
- * What this route contributes is the two things an application owns: which
- * languages it serves, and its theme defaults.
- *
- * Because the locale comes from router state, changing language re-renders this:
- * new locale, new query key, new messages, no page reload.
- */
 function RootComponent() {
   return (
     <VitNodeRootProviders config={{ debug, locales: i18n.locales, theme }}>
@@ -160,20 +77,6 @@ function RootComponent() {
   );
 }
 
-/**
- * The document itself.
- *
- * `lang` is the language this request actually resolved to - `en` for `/`, `pl`
- * for `/pl`, and on a route outside the localized URL space (`/admin`) whatever
- * the visitor's cookie says. It comes from the same router state the provider
- * reads, so the two cannot disagree and hydration has nothing to complain about.
- *
- * `ThemeScript` has to be in the head, and it has to be inline: it applies the
- * stored theme to `<html>` before the browser paints, so the first frame is the
- * theme the visitor chose rather than a flash of the default one.
- * `suppressHydrationWarning` covers the attributes it writes, which by design
- * differ from what the server rendered.
- */
 function RootDocument({ children }: { children: React.ReactNode }) {
   const locale = useLocale();
 

package/copy-of-vitnode-app/root/src/routes/_admin/admin.core.index.tsx

@@ -5,60 +5,11 @@ import {
   loadAdminDashboardRoute,
 } from "@vitnode/core/tanstack/admin/dashboard";
 
-/**
- * `/admin/core` - the AdminCP dashboard, and the one route file `_admin` keeps.
- *
- * Topology only. The layout query, the widget catalogue, the drag-and-drop
- * board, the settings dialogs and the four mutations behind them are
- * `@vitnode/core/tanstack/admin/dashboard`.
- *
- * ## Why this one file is still here
- *
- * Every other AdminCP screen is `@vitnode/core`'s, mounted by
- * `withCoreAdminRoutes` as a code-based route - see `src/router.tsx`. This one
- * stays because the file-based generator requires it to, and the requirement is
- * sharp rather than stylistic:
- *
- * - A pathless layout with no file children is **dropped from the generated
- *   tree**. `buildRouteTreeConfig` skips it outright, so `_admin` would not be
- *   in `routeTree.gen.ts` at all and the route object `src/router.tsx` mounts
- *   core's screens under would be an orphan.
- * - It also collapses to a full path of `/`, which collides with `_main/index.tsx`
- *   and fails the generator's uniqueness check by name.
- *
- * So `_admin` needs one file-based child with a real path in order to exist, and
- * this is it - which is the same job it has always had. It was the shell's first
- * child for exactly this reason, and now it is the only one.
- *
- * Deleting it does not remove a screen; it removes the AdminCP.
- *
- * ## No `head`, deliberately
- *
- * The Next.js page exports no `generateMetadata`, so the tab keeps the site's
- * own name. Declaring `title: 'VitNode'` here would render "VitNode - VitNode"
- * through `formatPageTitle`; saying nothing inherits the root's title and
- * `_admin`'s `noindex`, which is the parity-preserving answer.
- *
- * ## `pluginWidgets` is not passed
- *
- * A plugin declares widgets in its `admin.dashboard.widgets`, which reaches a
- * Next.js board through `getVitNodeConfig()`. This route does not read the
- * config - the AdminCP takes its plugin data from the generated projections, and
- * neither of those carries widgets - so the board shows core's own, which is the
- * complete set for this install because no configured plugin declares any. It is
- * the same seam `AdminShell` leaves open for nav `declarations`.
- */
+
 export const Route = createFileRoute("/_admin/admin/core/")({
   loader: async ({ context }) => await loadAdminDashboardRoute(context),
   component: AdminDashboardRoute,
-  /**
-   * The whole of how an admin route contributes to the trail in the shell's
-   * header: the route declares its own crumb next to its own component, the
-   * shell renders whichever matched route declared the deepest one, and there is
-   * no map from pathname to breadcrumb anywhere. The label comes from the
-   * *visible* navigation, so this reads "Core" in whatever language the
-   * administrator is using without this file naming a string.
-   */
+  
   staticData: {
     breadcrumb: <AdminBreadcrumb segments={["core"]} />,
   },

package/copy-of-vitnode-app/root/src/routes/_admin.tsx

@@ -13,92 +13,7 @@ import { ErrorActions } from "@vitnode/core/tanstack/layout";
 import { AdminShell } from "#/components/admin-shell";
 import { pageHead } from "#/lib/page-head";
 
-/**
- * The boundary every AdminCP page sits under - the admin session guard, and the
- * shell.
- *
- * Pathless: the leading underscore means it contributes no URL segment, so
- * `routes/_admin/core/index.tsx` is `/admin/core`, guarded, and the guard is
- * this file. A page joins the AdminCP by *where its file lives*, not by
- * remembering to check a session.
- *
- * ## It is not under `_authenticated`, and must not be
- *
- * The AdminCP has its own session, under its own cookie (`vitnode_auth_admin`),
- * with its own model and its own endpoint. Stacking the public guard above this
- * one would bounce an administrator to `/login` for a session the AdminCP does
- * not use - and `AuthState.isAdmin`, which lives on the *public* session, means
- * "may be offered the AdminCP", not "is inside it". Two cookies, two questions.
- *
- * ## Exactly one splat may live under here, and nothing wider
- *
- * `admin.content.$.tsx` claims `/admin/content/*` - the Content Engine's own
- * namespace, which Stage 13 moved into this router. That one is deliberate and
- * narrow; a second is how the AdminCP breaks.
- *
- * `$.tsx`, `admin.$.tsx` or any other catch-all beside it would consume every
- * *remaining* admin URL, including the ones no route declares. The AdminCP's own
- * not-found would stop being reachable, a plugin's admin route would be shadowed
- * by whichever splat sat above it, and nothing would report either - silently,
- * and all at once. `src/tests/admin-routes.test.ts` pins both halves: that the
- * content splat sits at exactly that path, and that it is the only one.
- *
- * ## Why the check is in `beforeLoad`
- *
- * It runs before the loader and long before React, so a visitor without admin
- * access never receives a byte of an AdminCP page - not a flash, not a
- * hydration, not a `useEffect` that redirects afterwards. A component-level
- * check would render the page first and then take it away, which on the server
- * means admin markup already written into the stream.
- *
- * ## A hover is not a navigation
- *
- * `defaultPreload: 'intent'` means the router runs this whole chain when a
- * pointer rests on an admin link, and router-core has no staleness gate on
- * `beforeLoad` the way it has on a loader - it re-runs it from the top of the
- * branch every time. With `ADMIN_SESSION_STALE_TIME` at zero that made crossing
- * the sidebar one server-function POST and one Hono call *per link the mouse
- * passed over*, for a question nobody had asked yet.
- *
- * So the read is chosen by the `preload` flag the router already hands in.
- * `preloadAdminAccess` is the same query, the same key and the same rejection
- * behaviour, trusted for thirty seconds - the identical window the public
- * session has always used for the identical reason. `ensureAdminAccess` and its
- * `staleTime: 0` are untouched on the path that matters, and that is the whole
- * of the revocation guarantee: entering a screen is a real navigation, this runs
- * again with `preload: false`, and the API is asked. Router-core never lets a
- * preloaded `beforeLoad` result stand in for a navigation's.
- *
- * The redirect below is deliberately *not* conditional on `preload`. It is not a
- * navigation - `preloadClientRoute` catches it and preloads the sign-in page
- * instead of moving anybody - and skipping it would leave a denied preload
- * walking into the screen loaders underneath, which would then send admin
- * requests the API is going to refuse.
- *
- * ## A failed read is not a denial
- *
- * `ensureAdminAccess` resolves only for an answer the API actually gave - `200`
- * or `403`. A `429` from the rate limiter, a `500`, an API that is not listening:
- * all three reject, and that rejection is deliberately left to propagate as an
- * ordinary route error.
- *
- * Only `canEnterAdmin` answering `false` sends anybody to `/admin`. Catching the
- * rejection and redirecting instead would sign every administrator out of the
- * AdminCP during an outage and present them with a sign-in form for a session
- * they already hold - which is precisely what the Next.js `getSessionAdminApi()`
- * does today, and precisely what this shape exists to stop.
- *
- * ## What it is not
- *
- * A navigation guard, and only that. `api/config.ts` puts
- * `globalAdminMiddleware()` in front of every request whose path contains
- * `/admin/`, each handler re-checks the staff tables, and
- * `SessionAdminModel.getUser()` re-runs `checkIfUserIsAdmin` against the
- * database on every request - deleting the session the moment the answer turns
- * false. So an administrator who edits this app's cached permission set in
- * devtools gets a visible button and an API that still refuses them. Nothing
- * here is, or may become, the security boundary.
- */
+
 export const Route = createFileRoute("/_admin")({
   beforeLoad: async ({ context, location, preload }) => {
     const access = preload
@@ -133,96 +48,20 @@ export const Route = createFileRoute("/_admin")({
     // a page cannot disagree with the guard that let it render.
     return { adminAccess: access };
   },
-  /**
-   * The shell's strings, warmed before React renders.
-   *
-   * `adminNav.namespaces` is the same array `AdminShell` hands the shell, and it
-   * has to be: the provider reads back the identical `intlQueryOptions` entry
-   * this fills, so warming a different namespace set would fill an entry nobody
-   * looks at and cost a round trip on the first paint anyway. It is not a fixed
-   * list because it cannot be - a plugin group's headings live under that
-   * plugin's own id, and which plugins this installation configured is decided
-   * in `src/admin-nav.gen.ts`.
-   *
-   * ## Imported inside the loader, not above it
-   *
-   * A route file's `loader` body runs only for a navigation into this shell; the
-   * file itself is evaluated in the client entry, on every page of the site. The
-   * generated navigation is not small - it carries every configured plugin's
-   * sidebar icons and its content type definitions, and through those the whole
-   * Content Engine and `zod` - so a static import here put ~45 KB of AdminCP
-   * data, plus `zod`, in front of the front page's first paint. `AdminShell`
-   * imports the same module, and `AdminShell` is this route's `component`, which
-   * is code-split: the two land in the same chunk, so an administrator pays for
-   * it once and everybody else not at all.
-   */
+  
   loader: async ({ context }) => {
     const { adminNav } = await import("#/lib/admin-nav");
 
     await loadAdminMessages({ ...context, namespaces: adminNav.namespaces });
   },
-  /**
-   * Stated once for the whole panel rather than on each screen.
-   *
-   * The AdminCP is behind a session and must never be indexed. Router merges the
-   * `head` of every matched route and dedupes `meta` by `name`, preferring the
-   * deepest, so an admin screen inherits this by saying nothing - which is
-   * exactly what `RouteHeadOptions` describes. A screen's own `pageHead` adds
-   * only its title and description.
-   */
+  
   head: () => pageHead({ robots: "noindex, nofollow" }),
-  /**
-   * The AdminCP's 404, rendered inside the shell.
-   *
-   * What reaches it is a screen whose loader called `requireAdminPermission`
-   * and was refused - the same answer `app/[locale]/admin/(auth)/not-found.tsx`
-   * gives in the Next.js AdminCP. Declared here rather than per screen so every
-   * one of them answers a missing permission identically.
-   *
-   * A content URL that resolves to no content type reaches it too, and by the
-   * same route: `loadContentAdminRoute` throws `notFound()` for a splat its
-   * registry cannot name, which is the answer the Next.js catch-all's
-   * `notFound()` gives one navigation later.
-   *
-   * A URL under `/admin` that matches no route at all does *not* reach this one.
-   * Outside `/admin/content`, `_admin` has only declared children - see above -
-   * so such a path matches nothing in this subtree and the router falls back to
-   * its own not-found at the root. That is the correct trade, and the cost is
-   * paid deliberately: rendering an unmigrated admin URL inside this shell would
-   * mean claiming it. (The root has no `notFoundComponent` of its own yet, so
-   * that fallback is currently the router's bare one - for every unmatched URL
-   * in this application, not only admin ones. Giving the root a real 404 page is
-   * its own piece of work.)
-   */
+  
   notFoundComponent: AdminNotFoundScreen,
   component: AdminLayout,
 });
 
-/**
- * The refusal, wearing the panel it was refused inside.
- *
- * ## It mounts the shell itself, and has to
- *
- * A `notFoundComponent` renders *instead of* the component of the route that
- * handles the error, not inside it - so this replaces `AdminLayout`, sidebar
- * and header and palette included. An administrator who opened a screen they
- * lack the permission for would otherwise be dropped onto a bare 404 page with
- * no way back into the AdminCP but the browser's back button, which is not what
- * the Next.js AdminCP does: its `not-found.tsx` sits *under*
- * `admin/(auth)/layout.tsx` and keeps the panel around the message.
- *
- * Mounting `AdminShell` here restores that, and it costs nothing: `beforeLoad`
- * has already resolved the admin session and the loader above has already
- * warmed the shell's messages, so the providers inside read the same two cache
- * entries the working screens read and nothing suspends or fetches again.
- *
- * ## What is bound rather than defaulted
- *
- * `ErrorActions` is this app's binding rather than core's default: `/` is served
- * by the Next.js application on some installs and by this one on others, and
- * only the route tree knows which. It is passed as an element from module scope
- * so the type is stable across renders.
- */
+
 function AdminNotFoundScreen() {
   return (
     <AdminShell>
@@ -231,24 +70,7 @@ function AdminNotFoundScreen() {
   );
 }
 
-/**
- * The AdminCP shell.
- *
- * `AdminShell` is this app's binding of `AdminShellContent` - the sidebar, the
- * command palette, the breadcrumb area, the user menu and the one `<main>` every
- * admin page renders inside. It mounts `AdminPermissionsProvider` itself, from
- * the same admin session query the guard above has already filled, so
- * `AdminStaffPermissionGate` and `useAdminStaffPermission` work identically here
- * and in the Next.js AdminCP. It cannot suspend in practice and nothing below it
- * can suspend at all; see the note on the provider.
- *
- * What `#/components/admin-shell` adds on top is only what a package cannot
- * answer for a particular installation: where the user lookup runs, which
- * plugins this app configured, and how the command palette moves without a link.
- *
- * The guard, the loader and the route options above are the parts that must not
- * move.
- */
+
 function AdminLayout() {
   return (
     <AdminShell>

package/copy-of-vitnode-app/root/src/routes/_main/index.tsx

@@ -2,24 +2,6 @@ import { createFileRoute } from "@tanstack/react-router";
 
 import { pageHead } from "#/lib/page-head";
 
-/**
- * The front page.
- *
- * One route file serving every public URL of the home page: `/` and `/pl` both
- * match here, because the locale is stripped before matching and written back
- * into every link the router builds. There is no `routes/pl/index.tsx` and there
- * does not need to be one.
- *
- * **`head` must be written after `loader`** on routes that have one -
- * `loaderData` is inferred from `loader` in the same object literal, and
- * TypeScript reads a literal's members in order. This route has no loader: it
- * fetches nothing, and the shell above it already warmed everything the header
- * reads.
- *
- * `robots: 'index, follow'` is stated rather than assumed. `_main` says nothing
- * about indexing, and a page that wants to be found should say so where somebody
- * editing it will see it.
- */
 export const Route = createFileRoute("/_main/")({
   head: () =>
     pageHead({
@@ -30,18 +12,6 @@ export const Route = createFileRoute("/_main/")({
   component: HomeRoute,
 });
 
-/**
- * Replace this with your own home page.
- *
- * No `<main>`: the shell owns the document's one `main` landmark, and a page
- * that renders a second gives a screen reader two to choose between. A page owns
- * its container - width, padding, vertical rhythm - and nothing above it.
- *
- * The copy is hard-coded because a new app has no strings of its own yet. To
- * translate it, add the keys to `src/locales/` and read them with
- * `useTranslations` from `use-intl` - the same hook every VitNode component
- * uses, on every host.
- */
 function HomeRoute() {
   return (
     <div className="container mx-auto flex max-w-2xl flex-col gap-4 p-4">