@jskit-ai/agent-docs 0.1.17 → 0.1.18

package/guide/agent/app-setup/multi-homing.md

@@ -591,12 +591,12 @@ registerProfileSyncLifecycleContributor(app, "workspaces.core.profileSyncLifecyc
   return Object.freeze({
     contributorId: "workspaces.core.profileSync",
     order: 100,
-    async afterIdentityProfileSynced({ profile, created, options } = {}) {
-      if (!created || !profile || typeof workspaceService?.provisionWorkspaceForNewUser !== "function") {
+    async afterIdentityProfileSynced({ profile, options } = {}) {
+      if (!profile || typeof workspaceService?.ensureProvisionedWorkspaceForAuthenticatedUser !== "function") {
         return;
       }
 
-      await workspaceService.provisionWorkspaceForNewUser(profile, options);
+      await workspaceService.ensureProvisionedWorkspaceForAuthenticatedUser(profile, options);
     }
   });
 });
@@ -604,7 +604,9 @@ registerProfileSyncLifecycleContributor(app, "workspaces.core.profileSyncLifecyc
 
 That means the workspace package does not need to patch auth directly to learn that a user was added. It listens through the `users-core` lifecycle registry instead.
 
-For this chapter's `tenancyMode = "personal"` setup, that contributor now does real work. When a brand-new JSKIT user is synchronized from auth, `workspaces-core` uses the lifecycle seam to provision that user's first personal workspace automatically.
+For this chapter's `tenancyMode = "personal"` setup, that contributor now does real work. When an authenticated JSKIT user is synchronized from auth, `workspaces-core` ensures that user's personal workspace exists.
+
+That detail matters for the retrofit path described earlier in this chapter. If the app started on `none`, then later switched to `personal`, the first sign-in after that switch still needs to backfill the personal workspace for the already-existing user record. The lifecycle contributor handles that because the workspace provision step is idempotent.
 
 - `users-core` owns the "user was synchronized" lifecycle
 - `workspaces-core` subscribes to that lifecycle through the registry

package/guide/agent/app-setup/working-with-the-jskit-cli.md

@@ -568,6 +568,7 @@ So `update` is for reapplying package-owned managed changes, not for generic dep
 The best guide example is the tenancy-mode recovery path from the multi-homing chapter. If you installed `workspaces-core` or `workspaces-web` while the app was still on `tenancyMode = "none"`, then later changed the app to `personal`, the missing gated scaffold does not backfill automatically. The recovery path is:
 
 ```bash
+npx jskit update package users-core
 npx jskit update package workspaces-core
 npx jskit update package workspaces-web
 ```

package/guide/agent/generators/crud-generators.md

@@ -284,6 +284,28 @@ That file is the shared CRUD contract. The UI generator reads it to decide:
 
 So even though the server scaffold writes many files, the resource file is the bridge between the server and UI halves.
 
+### One install boundary to remember
+
+`crud-server-generator scaffold` also adds a new local app package dependency such as:
+
+```text
+@local/contacts
+```
+
+So before you build or run the app again, install that new local package:
+
+```bash
+npm install
+```
+
+If you are verifying the guide against a local JSKIT checkout and have already been using local package links, rerun:
+
+```bash
+npm run devlinks
+```
+
+The same rule applies after later server scaffolds such as `addresses` and `comments`. The UI generator can still read the generated resource file directly, but the app runtime needs the local package install boundary to be completed before the CRUD can boot normally.
+
 For standard CRUDs, that file is now intentionally compact. It uses `defineCrudResource(...)` from `@jskit-ai/resource-crud-core`, authors the canonical `schema` / `searchSchema` / `defaultSort` / `autofilter` shape once, and lets JSKIT derive the standard CRUD operation contracts from it.
 
 ### Step 3: scaffold the UI

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/agent-docs",
-  "version": "0.1.17",
+  "version": "0.1.18",
   "description": "Distributed JSKIT agent workflows, guides, and generated reference maps.",
   "type": "module",
   "files": [

package/reference/autogen/tooling/jskit-cli.md

@@ -166,7 +166,7 @@ Exports
 
 ### `src/server/cliRuntime/mutations/fileMutations.js`
 Exports
-- `applyFileMutations(packageEntry, appRoot, preparedMutations, managedFiles, managedMigrations, touchedFiles, warnings = [], existingManagedFiles = [])`
+- `applyFileMutations(packageEntry, appRoot, preparedMutations, managedFiles, managedMigrations, touchedFiles, warnings = [], existingManagedFiles = [], { reapplyManagedAppFiles = false } = {})`
 - `prepareFileMutations(packageEntry, options, appRoot, fileMutations, existingManagedFiles = [])`
 
 ### `src/server/cliRuntime/mutations/installMigrationMutation.js`