@jskit-ai/agent-docs 0.1.79 → 0.1.81

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

@@ -156,7 +156,7 @@ The most important parts look like this:
 ```json
 {
   "engines": {
-    "node": "^20.19.0 || ^22.12.0"
+    "node": "26.x"
   },
   "scripts": {
     "server": "node ./bin/server.js",
@@ -204,7 +204,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.
+Published JSKIT libraries and tooling support Node.js 22 from 22.12.0 onward, Node.js 24, and Node.js 26. Newly generated applications deliberately require Node 26: their app-level `engines` contract, `.nvmrc`, and JSKIT-managed verification workflow all name that runtime. The app-level contract is the runtime boundary for the app and its installed JSKIT runtime packages, while independently consumed JSKIT CLI and tooling packages retain the wider supported range. 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 lives in `jskit app ...`, not in copied scaffold scripts.
 
@@ -212,7 +212,7 @@ That matters because JSKIT maintenance policy changes over time. If the scaffold
 
 `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.
 
-The starter scaffold also writes `.github/workflows/jskit-verify.yml`. JSKIT generates and owns that workflow as a projection of installed package `ci` contracts. The baseline runs checkout, Node setup, `npm ci`, and `npm run verify`. Packages can add job environment values, service containers, and explicit `before-verify` steps without taking ownership of the whole YAML file. For example, the database runtime adds migrations before verification and its MySQL driver adds a MariaDB service with synthetic CI-only credentials and `DB_CLIENT=mysql2`.
+The starter scaffold also writes `.github/workflows/jskit-verify.yml`. JSKIT generates and owns that workflow as a projection of installed package `ci` contracts. The baseline runs checkout, Node 26 setup, `npm ci`, and `npm run verify`. Packages can add job environment values, service containers, and explicit `before-verify` steps without taking ownership of the whole YAML file. For example, the database runtime adds migrations before verification. Its MySQL driver adds a MariaDB service with synthetic CI-only credentials and `DB_CLIENT=mysql2`; its Postgres driver adds the equivalent Postgres service and `DB_CLIENT=pg`.
 
 The workflow content hash is recorded in `.jskit/lock.json`. Package lifecycle commands refresh it when installed requirements change and refuse to overwrite a workflow that differs from its recorded version. Application-specific CI belongs in another workflow. Use `npx jskit app sync-ci` to refresh an unmodified managed file, or `npx jskit app sync-ci --force` when you explicitly intend to replace an edited file that is already recorded as JSKIT-owned. The `--against <base-ref>` review mode still exists for local pre-merge checks and advanced CI pipelines, but the starter workflow does not assume it.
 

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

@@ -81,9 +81,9 @@ This gives you a clean ownership split:
 
 That split is worth keeping in mind through the rest of the guide. When you see `npm run verify`, read it as "run the app's JSKIT baseline verification policy, then any app-specific extra verification hook".
 
-The starter scaffold also includes `.github/workflows/jskit-verify.yml`. This is a JSKIT-managed projection, not a static template. Installed package descriptors can contribute CI environment values, services, and preparation steps through their top-level `ci` contract. JSKIT composes those contributions and renders one verification workflow in this order: checkout, Node setup, `npm ci`, package-contributed `before-verify` steps, and `npm run verify`.
+The starter scaffold also includes `.github/workflows/jskit-verify.yml`. This is a JSKIT-managed projection, not a static template. Installed package descriptors can contribute CI environment values, services, and preparation steps through their top-level `ci` contract. Published JSKIT libraries and tooling support Node.js 22 from 22.12.0 onward, Node.js 24, and Node.js 26, while newly generated applications require Node 26. The managed workflow enforces that application runtime for dependency installation and verification. JSKIT composes the contributions and renders the workflow in this order: checkout, Node 26 setup, `npm ci`, package-contributed `before-verify` steps, and `npm run verify`.
 
-For example, `database-runtime` contributes the `database-migrations` step, while `database-runtime-mysql` contributes the MariaDB service and matching synthetic CI-only `DB_*` values. `DB_CLIENT` remains the canonical `mysql2` value. Local `.env` values are never copied into the workflow.
+For example, `database-runtime` contributes the `database-migrations` step. Its MySQL driver contributes a MariaDB service with `DB_CLIENT=mysql2`, while its Postgres driver contributes a Postgres service with `DB_CLIENT=pg`. Each driver supplies matching synthetic CI-only `DB_*` values; local `.env` values are never copied into the workflow.
 
 The workflow path and generated content hash live under `managed.ciWorkflow` in `.jskit/lock.json`. Package add, remove, update, and app-wide package updates refresh this projection. If the workflow no longer matches its recorded hash, JSKIT refuses to overwrite it during those operations. Move application-specific jobs to another workflow, then explicitly regenerate the managed projection with:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jskit-ai/agent-docs",
-  "version": "0.1.79",
+  "version": "0.1.81",
   "description": "Distributed JSKIT agent references, prompts, guides, and generated reference maps.",
   "type": "module",
   "files": [
@@ -14,7 +14,7 @@
     "test": "node --test"
   },
   "engines": {
-    "node": ">=20 <23"
+    "node": "^22.12.0 || ^24.0.0 || ^26.0.0"
   },
   "publishConfig": {
     "access": "public"

package/reference/autogen/KERNEL_MAP.md

@@ -601,6 +601,7 @@ Exports
 Local functions
 - `normalizeStringArray(value)`
 - `nowMilliseconds()`
+- `createProviderLifecycleError(providerId, phase, cause)`
 
 ### `runtime/container.js`
 Exports

package/reference/autogen/packages/kernel.md

@@ -131,6 +131,7 @@ Exports
 Local functions
 - `normalizeStringArray(value)`
 - `nowMilliseconds()`
+- `createProviderLifecycleError(providerId, phase, cause)`
 
 ### `shared/runtime/container.js`
 Exports

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

@@ -433,7 +433,7 @@ Exports
 - `loadAppLocalPackageRegistry(appRoot)`
 - `loadPackageRegistry()`
 - `resolveInstalledNodeModulePackageEntry({ appRoot, packageId })`
-- `hydratePackageRegistryFromInstalledNodeModules({ appRoot, packageRegistry, seedPackageIds = [] })`
+- `hydratePackageRegistryFromInstalledNodeModules({ appRoot, packageRegistry, seedPackageIds = [], preferInstalledDescriptors = false })`
 - `loadBundleRegistry()`
 Local functions
 - `normalizeRelativePosixPath(pathValue)`