@jskit-ai/agent-docs 0.1.90 → 0.1.92

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

@@ -974,7 +974,7 @@ The generated `playwright.config.mjs` is a thin delegate to `@jskit-ai/jskit-cli
 
 - without `PLAYWRIGHT_BASE_URL`, it builds the app and starts the local server on `http://127.0.0.1:4173`
 - with `PLAYWRIGHT_BASE_URL`, it uses that managed preview and does not start another server
-- with `JSKIT_PLAYWRIGHT_STORAGE_STATE`, it loads the supplied authenticated state into Playwright contexts
+- with `VIBE64_PLAYWRIGHT_STORAGE_STATE`, it loads the Vibe64-supplied authenticated state into Playwright contexts
 
 Tests should therefore navigate with relative paths such as `page.goto("/w/acme/admin/contacts")`.
 
@@ -1032,7 +1032,7 @@ A managed host authenticates outside the project browser context. It performs it
 
 ```bash
 PLAYWRIGHT_BASE_URL=https://managed-preview.example.test \
-JSKIT_PLAYWRIGHT_STORAGE_STATE=/secure/temp/playwright-state.json \
+VIBE64_PLAYWRIGHT_STORAGE_STATE=/secure/temp/playwright-state.json \
 playwright test tests/e2e/contacts.spec.ts
 ```
 

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

@@ -209,7 +209,7 @@ Published JSKIT libraries and tooling support Node.js 22 from 22.12.0 onward, No
 
 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`, and `jskit app release`, the app keeps the nice `npm run` shortcuts while the maintained behavior stays in the installed CLI package.
 
-The Playwright scaffold follows the same rule. `playwright.config.mjs` delegates to `@jskit-ai/jskit-cli/test/playwright`, and the starter browser specs delegate their shared responsive checks to published JSKIT helpers. The generated files stay small while later JSKIT package updates can change local server startup, managed `PLAYWRIGHT_BASE_URL` handling, and `JSKIT_PLAYWRIGHT_STORAGE_STATE` support without copying that logic into each new app.
+The Playwright scaffold follows the same rule. `playwright.config.mjs` delegates to `@jskit-ai/jskit-cli/test/playwright`, and the starter browser specs delegate their shared responsive checks to published JSKIT helpers. The generated files stay small while later JSKIT package updates can change local server startup, managed `PLAYWRIGHT_BASE_URL` handling, and `VIBE64_PLAYWRIGHT_STORAGE_STATE` support without copying that logic into each new app.
 
 `jskit app verify` is worth noticing specifically. Linting, tests, and builds check your source code and runtime behavior. The JSKIT part of that flow runs `doctor`, which checks JSKIT-managed app state: installed package visibility, lock-file-backed managed files, and other JSKIT-specific health rules. It is there because a JSKIT app is not only code. It is also a descriptor-driven managed project.
 

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

@@ -804,7 +804,7 @@ That command does two things:
 - runs the targeted Playwright command you give it
 - writes a receipt describing the verified feature, auth mode, and current dirty UI file set
 
-The auth mode is receipt metadata, not an authentication implementation. `jskit app verify-ui` does not log a user in, inject a secret, or rewrite the Playwright context. A direct local run uses `loginAsExistingUser()` from `@jskit-ai/auth-web/test/playwright`; a managed runner supplies authenticated state through `JSKIT_PLAYWRIGHT_STORAGE_STATE`. The generated `playwright.config.mjs` consumes that state and honors `PLAYWRIGHT_BASE_URL` without starting a second server.
+The auth mode is receipt metadata, not an authentication implementation. `jskit app verify-ui` does not log a user in, inject a secret, or rewrite the Playwright context. A direct local run uses `loginAsExistingUser()` from `@jskit-ai/auth-web/test/playwright`; Vibe64 supplies authenticated state through `VIBE64_PLAYWRIGHT_STORAGE_STATE`. The generated `playwright.config.mjs` consumes that state and honors `PLAYWRIGHT_BASE_URL` without starting a second server.
 
 `doctor` then compares the current changed UI files to that receipt. If you edit the UI again afterwards, the receipt is stale and `doctor` tells you to rerun `jskit app verify-ui`.
 

package/package.json

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

package/patterns/ui-testing.md

@@ -16,7 +16,7 @@ Rules:
 - Generated `playwright.config.mjs` delegates to `@jskit-ai/jskit-cli/test/playwright`. Do not copy base-URL, web-server, or storage-state logic into app tests.
 - Use relative paths such as `page.goto("/home")`. The shared config owns the browser base URL.
 - A managed runner supplies `PLAYWRIGHT_BASE_URL`. When it is set, JSKIT does not start another app server.
-- A managed runner supplies an authenticated context through `JSKIT_PLAYWRIGHT_STORAGE_STATE`. Treat that file as a temporary secret: do not commit it, print it, or retain it after the run.
+- Vibe64 supplies an authenticated context through `VIBE64_PLAYWRIGHT_STORAGE_STATE`. Treat that file as a temporary secret: do not commit it, print it, or retain it after the run.
 - Do not install a browser when the environment provides a managed browser runner.
 
 ## Direct local authentication
@@ -61,7 +61,7 @@ A managed preview must not expose `AUTH_DEV_BYPASS_SECRET` to project code or fo
 
 ```bash
 PLAYWRIGHT_BASE_URL=https://managed-preview.example.test \
-JSKIT_PLAYWRIGHT_STORAGE_STATE=/secure/temp/playwright-state.json \
+VIBE64_PLAYWRIGHT_STORAGE_STATE=/secure/temp/playwright-state.json \
 playwright test tests/e2e/contacts.spec.ts
 ```
 

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

@@ -534,6 +534,27 @@ Local functions
 - `applyTextReplacements(sourceText = "", replacements = [])`
 - `collectCrudFormFieldCandidateFiles(appRoot = "")`
 
+### `src/server/commandHandlers/appCommands/previewIdentity.js`
+Exports
+- `PREVIEW_IDENTITY_PROTOCOL`
+- `executeJskitPreviewIdentityRequest(value = {}, { env = process.env, fetchImpl = globalThis.fetch } = {})`
+- `runAppPreviewIdentityCommand(_ctx = {}, { env = process.env, fetchImpl = globalThis.fetch, stdin = process.stdin, stdout = process.stdout } = {})`
+Local functions
+- `previewIdentityResponse(requestId = "", values = {})`
+- `previewIdentityFailure(requestId = "", error = {})`
+- `commandError(message = "", code = "jskit_preview_identity_failed", extra = {})`
+- `readInput(stream)`
+- `normalizeRequest(value = {})`
+- `identityFromSubject(subject = {})`
+- `responseSetCookie(response = {})`
+- `cookieHeader(setCookie = [])`
+- `responsePayload(response = {})`
+- `upstreamError(payload = {}, response = {}, extra = {})`
+- `postJson(fetchImpl, href, body, headers = {})`
+- `readSession(fetchImpl, targetOrigin, setCookie = [])`
+- `logout(fetchImpl, targetOrigin, session)`
+- `login(fetchImpl, targetOrigin, identity, secret, session)`
+
 ### `src/server/commandHandlers/appCommands/release.js`
 Exports
 - `runAppReleaseCommand(ctx = {}, { appRoot = "", options = {}, stdout, stderr })`