@jskit-ai/agent-docs 0.1.26 → 0.1.28

package/guide/agent/app-setup/authentication.md

@@ -83,7 +83,7 @@ npm run server
 
 Then open `http://localhost:5173/auth/login` in the browser.
 
-The login page is now real, and it already contains several different auth modes behind the same card.
+The login page is real, and it already contains several different auth modes behind the same card.
 
 - **Sign in** is the normal email-and-password flow.
 - **Register** creates a new Supabase auth user.
@@ -91,7 +91,7 @@ The login page is now real, and it already contains several different auth modes
 - **Use one-time code** switches to an email OTP login flow.
 - **Remember this account on this device** stores a small local hint in browser storage so the next visit can greet the last-used account and let the user keep that email preselected.
 
-If you go back to `http://localhost:5173/home`, the shell also has a small auth widget in the top-right corner. When you are signed out it shows a guest state and a menu entry that leads to `/auth/login`. After you sign in, the same placement changes to a sign-out menu.
+If you go back to `http://localhost:5173/home`, the shell also has a small auth widget in the status area. When you are signed out it shows a guest state and a menu entry that leads to `/auth/login`. After you sign in, the same placement changes to a sign-out menu.
 
 ## Reading the screen carefully
 
@@ -165,7 +165,7 @@ JSKIT asks Supabase to send OTP login emails only for existing users. In other w
 
 That endpoint asks Supabase to send a password reset email. In this chapter's scaffold, this mode is only the **request** step.
 
-The backend already supports the later recovery endpoints too, but the chapter's simple app does **not** yet scaffold a dedicated app-owned `reset-password` page. So at this stage, the guide should be read as: the screen can request recovery emails now, while the full browser-side password-reset completion UI is still something you would add explicitly in the app.
+The backend already supports the later recovery endpoints too, but the chapter's simple app does **not** yet scaffold a dedicated app-owned `reset-password` page. So at this stage, the guide should be read as: the screen can request recovery emails, while the full browser-side password-reset completion UI is still something you would add explicitly in the app.
 
 ### Remembered account behavior
 
@@ -184,7 +184,7 @@ On the next visit, the card can show a `Welcome back, ...` panel and a `Use anot
 
 The screen is also ready to show OAuth provider buttons, but only if providers are configured.
 
-Right now the chapter's `config.server.js` keeps this empty:
+For this chapter, `config.server.js` keeps this empty:
 
 ```js
 config.auth = {
@@ -319,10 +319,10 @@ The placement entry is just a normal shell link:
 ```js
 addPlacement({
   id: "ui-generator.page.home.reports.link",
-  target: "shell-layout:primary-menu",
+  target: "shell.primary-nav",
+  kind: "link",
   surfaces: ["home"],
   order: 155,
-  componentToken: "local.main.ui.surface-aware-menu-link-item",
   props: {
     label: "Reports",
     surface: "home",
@@ -332,13 +332,22 @@ addPlacement({
 });
 ```
 
-And the page file itself is a normal page scaffold:
+And the page file itself is a normal generated empty-state screen:
 
 ```vue
 <template>
-  <section class="pa-4">
-    <h1 class="text-h5 mb-2">Reports</h1>
-    <p class="text-body-2 text-medium-emphasis">Replace this scaffold with your page implementation.</p>
+  <section class="generated-page-screen d-flex flex-column ga-4">
+    <header>
+      <p class="text-overline text-medium-emphasis mb-1">Screen</p>
+      <h1 class="generated-page-screen__title">Reports</h1>
+    </header>
+
+    <v-sheet rounded="lg" border class="generated-page-screen__empty-state">
+      <h2 class="text-h6 mb-2">No Reports activity yet</h2>
+      <p class="text-body-2 text-medium-emphasis mb-0">
+        Activity and actions for this screen will appear here.
+      </p>
+    </v-sheet>
   </section>
 </template>
 ```
@@ -364,9 +373,18 @@ To make the route require login, add a route guard block to `src/pages/home/repo
 </route>
 
 <template>
-  <section class="pa-4">
-    <h1 class="text-h5 mb-2">Reports</h1>
-    <p class="text-body-2 text-medium-emphasis">Replace this scaffold with your page implementation.</p>
+  <section class="generated-page-screen d-flex flex-column ga-4">
+    <header>
+      <p class="text-overline text-medium-emphasis mb-1">Screen</p>
+      <h1 class="generated-page-screen__title">Reports</h1>
+    </header>
+
+    <v-sheet rounded="lg" border class="generated-page-screen__empty-state">
+      <h2 class="text-h6 mb-2">No Reports activity yet</h2>
+      <p class="text-body-2 text-medium-emphasis mb-0">
+        Activity and actions for this screen will appear here.
+      </p>
+    </v-sheet>
   </section>
 </template>
 ```
@@ -383,17 +401,17 @@ So after login, JSKIT can send the user back to the page they originally asked f
 
 ### Hide the menu entry when signed out
 
-The route is now protected, but the drawer link is still visible. That is expected. Route protection and shell visibility are separate concerns.
+The route is protected, but the drawer link is still visible. That is expected. Route protection and shell visibility are separate concerns.
 
 To hide the `Reports` menu entry until the user is logged in, update the placement entry in `src/placement.js`:
 
 ```js
 addPlacement({
   id: "ui-generator.page.home.reports.link",
-  target: "shell-layout:primary-menu",
+  target: "shell.primary-nav",
+  kind: "link",
   surfaces: ["home"],
   order: 155,
-  componentToken: "local.main.ui.surface-aware-menu-link-item",
   props: {
     label: "Reports",
     surface: "home",
@@ -407,7 +425,7 @@ addPlacement({
 
 The only new part is the `when(...)` line. That predicate is evaluated by the shell placement runtime using the auth context that `auth-web` injects from `/api/session`.
 
-So the behavior now becomes:
+So the behavior becomes:
 
 - signed out:
   - the `Reports` drawer entry disappears
@@ -440,7 +458,7 @@ const auth = useAuthStore();
     </v-alert>
 
     <h1 class="text-h5 mb-2">Home</h1>
-    <p class="text-body-2 text-medium-emphasis">Replace this scaffold with your page implementation.</p>
+    <p class="text-body-2 text-medium-emphasis">Your account session is active on this device.</p>
   </section>
 </template>
 ```
@@ -501,7 +519,7 @@ At this point the guide has shown three distinct layers of client state:
 - `shell-web` adds shell-facing stores such as `useShellLayoutStore()`
 - `auth-web` adds `useAuthStore()` for authentication state
 
-That progression is intentional. Packages keep their operational runtimes internally, but the app-facing shared state they surface to Vue code is now store-based.
+That progression is intentional. Packages keep their operational runtimes internally, but the app-facing shared state they surface to Vue code is store-based.
 
 ## What `auth-base` adds to the app
 
@@ -528,7 +546,7 @@ Three things are worth noticing immediately.
 
 - `auth-provider-supabase-core` is the provider-specific runtime.
 - `auth-web` is the part that adds the web routes and the default auth UI.
-- there is now an `auth` surface-specific dev/build script family, just as `home` already had.
+- there is an `auth` surface-specific dev/build script family, just as `home` already had.
 
 The provider command also writes a new `.env` file:
 
@@ -541,7 +559,7 @@ APP_PUBLIC_URL=http://localhost:5173
 
 This is the bridge between the scaffold and your real Supabase project. `APP_PUBLIC_URL` matters because auth emails and callback flows need to know which browser URL they should return to.
 
-Public routing config changes too. `config/public.js` now has a second surface:
+Public routing config changes too. `config/public.js` has a second surface:
 
 ```js
 config.surfaceDefinitions.auth = {
@@ -568,7 +586,7 @@ config.auth = {
 };
 ```
 
-That small block explains a lot of the default login screen. The stock UI is ready for OAuth providers such as Google, but right now the provider list is empty, so the page only shows the email/password and one-time-code flows. Later, if you enable a provider in Supabase and list it here, the same login screen can expose that button too.
+That small block explains a lot of the default login screen. The stock UI is ready for OAuth providers such as Google, but this chapter keeps the provider list empty, so the page only shows the email/password and one-time-code flows. Later, if you enable a provider in Supabase and list it here, the same login screen can expose that button too.
 
 The auth routes themselves are app-owned wrappers around the module-supplied default views. `src/pages/auth/login.vue` looks like this:
 
@@ -606,7 +624,8 @@ Authentication also becomes visible in the shell through `src/placement.js`:
 ```js
 addPlacement({
   id: "auth.profile.widget",
-  target: "shell-layout:top-right",
+  target: "shell.status",
+  kind: "component",
   surfaces: ["*"],
   order: 1000,
   componentToken: "auth.web.profile.widget"
@@ -614,10 +633,10 @@ addPlacement({
 
 addPlacement({
   id: "auth.profile.menu.sign-in",
-  target: "auth-profile-menu:primary-menu",
+  target: "auth.profile-menu",
+  kind: "link",
   surfaces: ["*"],
   order: 200,
-  componentToken: "auth.web.profile.menu.link-item",
   props: {
     label: "Sign in",
     to: "/auth/login"
@@ -627,10 +646,10 @@ addPlacement({
 
 addPlacement({
   id: "auth.profile.menu.sign-out",
-  target: "auth-profile-menu:primary-menu",
+  target: "auth.profile-menu",
+  kind: "link",
   surfaces: ["*"],
   order: 1000,
-  componentToken: "auth.web.profile.menu.link-item",
   props: {
     label: "Sign out",
     to: "/auth/signout"
@@ -639,7 +658,7 @@ addPlacement({
 });
 ```
 
-This is the shell placement system from the previous chapter doing real work again. `auth-web` does not hard-code a permanent top-right button into `ShellLayout.vue`. Instead, it contributes a widget and two menu entries into named outlets, and those entries react to the current auth state.
+This is the shell placement system from the previous chapter doing real work again. `auth-web` does not hard-code a permanent auth button into `ShellLayout.vue`. Instead, it contributes the profile widget into the semantic `shell.status` placement and contributes sign-in/sign-out links into the semantic `auth.profile-menu` placement. Topology maps those semantic targets to concrete outlets and renderers.
 
 So the auth story in this chapter is spread across clear responsibilities:
 
@@ -701,7 +720,7 @@ onBeforeUnmount(() => {
     </v-alert>
 
     <h1 class="text-h5 mb-2">Home</h1>
-    <p class="text-body-2 text-medium-emphasis">Replace this scaffold with your page implementation.</p>
+    <p class="text-body-2 text-medium-emphasis">Your account session is active on this device.</p>
   </section>
 </template>
 ```
@@ -916,7 +935,7 @@ It is also why the shell widget can react cleanly to auth state without storing
 
 ### Authenticated Playwright testing with the dev auth bypass
 
-JSKIT now ships a development-only auth bootstrap path specifically so authenticated UI can be verified in Playwright without depending on a real live login flow through Supabase.
+JSKIT ships a development-only auth bootstrap path specifically so authenticated UI can be verified in Playwright without depending on a real live login flow through Supabase.
 
 This is the standard path the agent should use for authenticated browser tests:
 
@@ -1082,6 +1101,6 @@ That is why the confirmation screen in the app should be understood as a **sessi
 
 ## Summary
 
-After this chapter, the app can really authenticate against Supabase. It has a public `auth` surface, a stock login page, a sign-out route, and a shell widget that reflects auth state. The provider-specific values now live in `.env`, and the web auth layer is wired into the same placement and surface system introduced earlier in the guide.
+After this chapter, the app can really authenticate against Supabase. It has a public `auth` surface, a stock login page, a sign-out route, and a shell widget that reflects auth state. The provider-specific values live in `.env`, and the web auth layer is wired into the same placement and surface system introduced earlier in the guide.
 
 Just as importantly, the app is still deliberately incomplete. Authentication exists, but the database-backed user model does not. That separation is useful, because the next layer of the guide can explain users and persistence without having to also explain the first auth setup at the same time.

package/guide/agent/app-setup/console.md

@@ -25,7 +25,7 @@ npm run db:migrate
 - `console-core` owns the console schema, owner check, bootstrap flag, and API routes
 - `console-web` owns the console surface scaffold, settings shell, and menu placement
 
-So the console is a real vertical slice now. The users packages no longer know about it.
+The console is a real vertical slice. The users packages do not own it.
 
 ## What the console is for
 
@@ -70,7 +70,7 @@ Then sign in.
 
 Once you are authenticated, two things matter:
 
-- the app now knows who you are as a persistent JSKIT user
+- the app knows who you are as a persistent JSKIT user
 - the console bootstrap logic can determine whether you are the console owner
 
 Open:
@@ -92,7 +92,7 @@ This is the most important idea in the chapter.
 
 The account surface only requires authentication. The console surface requires a specific access flag: `console_owner`.
 
-That means the guide now has two different kinds of authenticated routes:
+That means the guide has two different kinds of authenticated routes:
 
 - normal authenticated routes such as `/account`
 - privileged authenticated routes such as `/console`
@@ -163,7 +163,7 @@ This is the first clear example in the guide of a surface guarded by a named fla
 
 ### The starter console routes are app-owned
 
-After the previous chapter, the app now has:
+After the previous chapter, the app has:
 
 ```text
 src/pages/console.vue
@@ -179,7 +179,7 @@ This follows the same route-owner pattern the guide has already shown on `home`
 - `src/pages/console/settings.vue` is the nested settings shell
 - `src/pages/console/settings/index.vue` is the initial developer-owned stub
 
-That last file is intentionally empty, because later modules are expected to add real console settings sections into the `console-settings:primary-menu` outlet.
+That last file is intentionally empty, because later modules are expected to add real console settings sections through `page.section-nav` with owner `console-settings`.
 
 ### `src/placement.js` wires the first console menu entry
 
@@ -188,10 +188,10 @@ The starter placement block is:
 ```js
 addPlacement({
   id: "console.web.menu.settings",
-  target: "shell-layout:primary-menu",
+  target: "shell.primary-nav",
+  kind: "link",
   surfaces: ["console"],
   order: 100,
-  componentToken: "local.main.ui.menu-link-item",
   props: {
     label: "Settings",
     to: "/console/settings",
@@ -308,7 +308,7 @@ That stricter access model is the key idea to keep:
 - `/account` is for any signed-in user
 - `/console` is only for the console owner
 
-So the app now has both:
+So the app has both:
 
 - a normal authenticated user area
 - a privileged operator area with its own server-side ownership check

package/guide/agent/app-setup/database-layer.md

@@ -49,11 +49,11 @@ Installing `database-runtime-mysql` gives the app three important things right a
 
 ### A real database runtime
 
-The server can now build a real Knex client from environment variables. That gives later packages a standard way to ask for a database connection instead of each package inventing its own wiring.
+The server can build a real Knex client from environment variables. That gives later packages a standard way to ask for a database connection instead of each package inventing its own wiring.
 
 ### A migration workflow
 
-The app now gets three new scripts in `package.json`:
+The app gets three database scripts in `package.json`:
 
 ```json
 {
@@ -73,7 +73,7 @@ If you run the status command immediately after this chapter:
 npm run db:migrate:status
 ```
 
-you should still see that there are no completed migrations and no pending migration files yet. The runtime and the Knex wiring exist now, but no package has added real schema files until the next chapter.
+you should still see that there are no completed migrations and no pending migration files yet. The runtime and the Knex wiring exist at this point, but no package has added real schema files until the next chapter.
 
 ### A place for future schema files
 
@@ -88,7 +88,7 @@ That is the key idea of this chapter:
 
 This chapter is the right place to make one distinction very explicit.
 
-There are now two different migration-related layers in the app:
+The app has two different migration-related layers:
 
 - JSKIT-managed migration files on disk
 - Knex actually applying those files to the database
@@ -171,7 +171,7 @@ import {
 } from "@jskit-ai/database-runtime/shared";
 ```
 
-This is worth calling out now because the database layer is not only "Knex plus migrations".
+This is worth calling out here because the database layer is not only "Knex plus migrations".
 
 It also gives your later repositories and services a standard persistence toolbox so every package does not have to solve the same problems differently. The main point is consistency:
 
@@ -561,7 +561,7 @@ The three new scripts are also worth reading carefully:
 
 They are not special JSKIT commands. They are ordinary project scripts, which makes them easy to run in any environment.
 
-### `.env` now owns the database connection settings
+### `.env` owns the database connection settings
 
 The package install also writes the database settings into `.env`:
 
@@ -583,7 +583,7 @@ This matters because the generic runtime is written to support more than one dri
 
 ### `knexfile.js` is for migration commands, not normal page code
 
-The migration scripts in `package.json` work because the app now has a top-level `knexfile.js`:
+The migration scripts in `package.json` work because the app has a top-level `knexfile.js`:
 
 ```js
 import path from "node:path";
@@ -628,7 +628,7 @@ It is not the main runtime API that your app code imports during a request. It i
 npm run db:migrate
 ```
 
-So there are really two separate database entry points now:
+So there are really two separate database entry points:
 
 - `knexfile.js` for migration commands
 - the JSKIT server provider runtime for application code
@@ -695,7 +695,7 @@ At first glance it can feel strange that the database layer is installed but the
 
 The reason is simple:
 
-- the runtime is now available
+- the runtime is available
 - but almost no installed package is using it yet
 
 Right now:
@@ -739,7 +739,7 @@ So the auth layer keeps behaving the same way it did before:
 - JSKIT still mirrors just enough profile data locally
 - that JSKIT-side mirror is still not persistent yet
 
-The database runtime is now ready, but the users layer that will actually use it has not been installed yet.
+The database runtime is ready, but the users layer that will actually use it has not been installed yet.
 
 ### Why the empty `migrations/` directory is important
 
@@ -747,7 +747,7 @@ The new `migrations/` directory can look almost silly at first because it only c
 
 It means:
 
-- the app now has a migration system
+- the app has a migration system
 - the app does **not** yet have a schema of its own
 
 That is exactly the right state at this stage of the guide.
@@ -758,9 +758,9 @@ The database runtime chapter should give the app a database foundation first. Th
 
 This chapter did not make the app feel dramatically different in the browser, but it changed the server foundation in an important way.
 
-- the app now has a real JSKIT database runtime
-- the app now has a standard Knex migration workflow
-- the app now has a place for future schema files
+- the app has a real JSKIT database runtime
+- the app has a standard Knex migration workflow
+- the app has a place for future schema files
 
 But just as importantly, this chapter also defined what has **not** changed yet:
 
@@ -771,5 +771,5 @@ But just as importantly, this chapter also defined what has **not** changed yet:
 So the right mental model at the end of this chapter is:
 
 - Supabase already handles real authentication
-- MySQL is now wired up and ready
+- MySQL is wired up and ready
 - the persistent JSKIT-side user model arrives in the next chapter

package/guide/agent/app-setup/initial-scaffolding.md

@@ -14,7 +14,7 @@ npm install
 
 The first command creates a new folder called `exampleapp` and fills it with JSKIT's base shell template. The `exampleapp` name is used in a few template replacements, such as the package name and the browser title. The `--tenancy-mode none` flag tells JSKIT to start with the smallest routing model. In this mode, the app is not workspace-aware (more of this later in the guide, when multihoming is introduced). That keeps the first scaffold easier to read because there is no workspace slug handling yet.
 
-If you are working with an AI agent and want the agent to drive the initial JSKIT setup conversation, there is now a dedicated seed path:
+If you are working with an AI agent and want the agent to drive the initial JSKIT setup conversation, use the dedicated seed path:
 
 ```bash
 npx @jskit-ai/create-app exampleapp --template ai-seed
@@ -166,23 +166,35 @@ The most important parts look like this:
     "build": "vite build",
     "build:all": "vite build",
     "build:home": "VITE_SURFACE=home vite build",
+    "preview": "vite preview",
+    "lint": "eslint .",
     "test": "node --test",
     "test:client": "vitest run tests/client",
+    "test:e2e": "playwright test tests/e2e",
     "verify": "jskit app verify && npm run --if-present verify:app",
     "release": "jskit app release",
     "jskit:update": "jskit app update-packages"
   },
   "dependencies": {
     "@local/main": "file:packages/main",
+    "@fastify/static": "^9.1.1",
     "@jskit-ai/kernel": "0.x",
+    "@tanstack/vue-query": "^5.90.5",
     "@jskit-ai/http-runtime": "0.x",
     "fastify": "^5.7.4",
+    "json-rest-schema": "^1.0.13",
     "pinia": "^3.0.4",
     "vue": "^3.5.13",
+    "vue-router": "^5.0.4",
     "vuetify": "^4.0.0"
   },
   "devDependencies": {
+    "@jskit-ai/agent-docs": "0.x",
+    "@jskit-ai/config-eslint": "0.x",
     "@jskit-ai/jskit-cli": "0.x",
+    "@playwright/test": "^1.57.0",
+    "@vitejs/plugin-vue": "^5.2.1",
+    "eslint": "^9.39.1",
     "vite": "^6.1.0",
     "vitest": "^4.0.18"
   }
@@ -191,7 +203,7 @@ The most important parts look like this:
 
 There are two details worth noticing immediately. The dependency on `@local/main` points at `file:packages/main`, which means your app already contains its own local JSKIT package. The maintenance scripts are also useful to notice early, because they show an important ownership boundary in JSKIT.
 
-`verify`, `jskit:update`, `devlinks`, and `release` are intentionally thin wrappers. They stay in `package.json` because they are convenient app-local shortcuts, but the real implementation now lives in `jskit app ...`, not in copied scaffold scripts.
+`verify`, `jskit:update`, `devlinks`, and `release` are intentionally thin wrappers. They stay in `package.json` because they are convenient app-local shortcuts, but the real implementation lives in `jskit app ...`, not in copied scaffold scripts.
 
 That matters because JSKIT maintenance policy changes over time. If the scaffold copied a large shell script into every app, existing apps would freeze the old behavior forever. By delegating to `jskit app verify`, `jskit app update-packages`, `jskit app link-local-packages`, and `jskit app release`, the app keeps the nice `npm run` shortcuts while the maintained behavior stays in the installed CLI package.
 
@@ -257,6 +269,7 @@ The important part looks like this:
 ```js
 import { createApp } from "vue";
 import { createPinia } from "pinia";
+import { QueryClient, VueQueryPlugin } from "@tanstack/vue-query";
 import { createRouter, createWebHistory } from "vue-router/auto";
 import { routes } from "vue-router/auto-routes";
 import "vuetify/styles";
@@ -265,6 +278,10 @@ import * as components from "vuetify/components";
 import * as directives from "vuetify/directives";
 import { aliases as mdiAliases, mdi } from "vuetify/iconsets/mdi-svg";
 import { createSurfaceRuntime } from "@jskit-ai/kernel/shared/surface/runtime";
+import {
+  shouldRetryTransientQueryFailure,
+  transientQueryRetryDelay
+} from "@jskit-ai/kernel/shared/support";
 import {
   bootstrapClientShellApp,
   createShellRouter
@@ -308,13 +325,28 @@ const vuetify = createVuetify({
   }
 });
 const pinia = createPinia();
+const queryClient = new QueryClient({
+  defaultOptions: {
+    queries: {
+      refetchOnWindowFocus: false,
+      refetchOnReconnect: true,
+      retry: shouldRetryTransientQueryFailure,
+      retryDelay: transientQueryRetryDelay
+    }
+  }
+});
 
 void bootstrapClientShellApp({
   createApp,
   rootComponent: App,
   appConfig: config,
-  appPlugins: [pinia, vuetify],
+  appPlugins: [
+    pinia,
+    [VueQueryPlugin, { queryClient }],
+    vuetify
+  ],
   pinia,
+  queryClient,
   router,
   bootClientModules: bootInstalledClientModules,
   surfaceRuntime,
@@ -326,7 +358,7 @@ void bootstrapClientShellApp({
 });
 ```
 
-The flow is simple once you read it in order: config in, runtime in memory, router built from that runtime, UI plugin installed, app bootstrapped.
+The flow is simple once you read it in order: config in, runtime in memory, router built from that runtime, app-owned Vue plugins created once, app bootstrapped. Pinia, Vue Query, the router, and Vuetify are owned by the base app bootstrap so runtime packages share the same instances instead of carrying independent copies.
 
 <DocsInDepth title="In depth" preview-height="15rem">
 
@@ -766,7 +798,7 @@ That is why you saw `@jskit-ai/kernel` and `@jskit-ai/http-runtime` earlier in `
 
 ### Other files and options
 
-The remaining files are easier to understand once you know the core pieces above. `vite.config.mjs` configures the frontend build and the `/api` proxy used during development. `index.html` is the HTML shell Vite uses to mount Vue. `tests/` contains basic smoke tests so the app has a verification path from day one. The `scripts/` directory is now much smaller than it used to be, because JSKIT maintenance helpers such as `verify`, `jskit:update`, `devlinks`, and `release` are package-owned CLI commands rather than copied app scripts.
+The remaining files are easier to understand once you know the core pieces above. `vite.config.mjs` configures the frontend build and the `/api` proxy used during development. `index.html` is the HTML shell Vite uses to mount Vue. `tests/` contains basic smoke tests so the app has a verification path from day one. The `scripts/` directory is intentionally small because JSKIT maintenance helpers such as `verify`, `jskit:update`, `devlinks`, and `release` are package-owned CLI commands rather than copied app scripts.
 
 The `create-app` command also accepts a few other flags that are useful without changing the basic meaning of this chapter's setup. `--title <text>` lets you replace the browser title and other template text with a friendlier app name. `--target <path>` lets you choose a different output directory instead of the default `./exampleapp`. `--tenancy-mode <mode>` can seed `none`, `personal`, or `workspaces`; for this chapter we intentionally use `none` so the first scaffold stays small and non-workspace. `--force` allows writing into a non-empty target directory when you know that is what you want. `--dry-run` prints the planned file writes without touching the filesystem, which is useful when you want to inspect what the generator would do. `-h` or `--help` prints the command help.