@jskit-ai/agent-docs 0.1.30 → 0.1.32

package/DISTR_AGENT.md

@@ -1,45 +1,15 @@
 # Distributed Agent Guide
 
-Read these in order:
+JSKIT issue work is driven by the executable session workflow.
 
-1. `workflow/app-state.md`
-2. `workflow/bootstrap.md` if the workspace is empty or no JSKIT app exists yet
-3. `workflow/scoping.md`
-4. `workflow/workboard.md`
-5. `workflow/feature-delivery.md`
-6. `workflow/review.md`
+Use:
 
-Use these references on demand:
+- `jskit session` to list sessions.
+- `jskit session create` to start a session.
+- `jskit session <session_id>` to inspect state.
+- `jskit session <session_id> step` to run the next step or render the next prompt.
+- `jskit session <session_id> step --json` for machine-readable output.
 
-- `reference/autogen/KERNEL_MAP.md`
-- `reference/autogen/README.md`
-- `patterns/INDEX.md`
-- `guide/agent/index.md`
-- `site/guide/index.md` when compressed guidance is ambiguous or missing nuance
-- `templates/APP_BLUEPRINT.md`
-- `templates/WORKBOARD.md`
-- `skills/jskit-review/SKILL.md` for review passes when your Codex environment supports packaged skills
+Do not use the old prose workflow model. Session state, receipts, prompt rendering, issue creation, review loops, doctor checks, PR creation, merge, cleanup, and final receipts belong to `jskit session`.
 
-Core rules:
-
-- Inspect the workspace before assuming a JSKIT app exists.
-- Before non-trivial edits, print a short visible checkpoint using this format:
-  - `Problem: ...`
-  - `Fix: ...`
-  - `Why this sticks: ...`
-  - `Not doing: ...`
-- Keep that checkpoint compact. Do not expand it into a long preamble unless the developer asks for detail.
-- When a request involves JSKIT UI, routing, surfaces, CRUDs, filters, placements, live actions, or similar implementation details, scan `patterns/INDEX.md` for matching keywords and read only the relevant pattern files.
-- Reuse existing JSKIT helpers and runtime seams before adding new local helpers.
-- If `npm install` is run while the app is using local JSKIT checkout links, run `npm run devlinks` immediately afterward.
-- A freshly scaffolded JSKIT app can still be in Stage 1. If platform decisions are not settled yet, continue with the initialize workflow before adding runtime packages.
-- Do not treat a missing `config.tenancyMode` line or an untouched minimal scaffold as a final tenancy decision.
-- Do not install tenancy-sensitive packages until Stage 1 decisions are complete and the chosen tenancy is written into `config/public.js`.
-- Treat standard JSKIT package-owned workflows as the default baseline once the relevant package stack is chosen. Do not ask the developer to redesign those flows unless they want overrides, restrictions, or custom additions.
-- Example: if the app is workspace-capable and uses `workspaces-core` plus `workspaces-web`, assume the standard workspace invite flow is part of the baseline package behavior.
-- For baseline package setup, ask plainly for the exact local development values needed for the next install step, but only for the modules or packages that are actually selected.
-- Use the real env var names or option names instead of vague requests for "credentials". Values such as `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `AUTH_SUPABASE_URL`, `AUTH_SUPABASE_PUBLISHABLE_KEY`, and `APP_PUBLIC_URL` are routine setup inputs when the relevant package stack needs them.
-- Do not implement app features before the blueprint has the database, surfaces, ownership model, and route/screen plan written down.
-- For substantial or multi-chunk work, create or update `.jskit/WORKBOARD.md` as the per-request execution tracker.
-- Use the compressed guide first for speed; fall back to the human guide when a workflow trap, migration caveat, or architectural boundary needs exact wording.
-- Treat generated reference maps and guide copies as vendor reference. Do not edit them manually.
+Use package docs, generated references, patterns, and guides only as technical references.

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

@@ -28,7 +28,7 @@ npx @jskit-ai/create-app exampleapp --target . --force --tenancy-mode <mode>
 npm install
 ```
 
-After that promotion, the overwritten app `AGENTS.md` becomes the source of truth for the normal JSKIT workflow.
+After that promotion, the overwritten app `AGENTS.md` stays deliberately small. Use `jskit session` for issue-driven work; session state and prompts live under `.jskit/sessions/` in the target app.
 
 After creating the real app scaffolding (the base shell, not the seed wrapper), you will need to run `npm install` to install dependencies.
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@jskit-ai/agent-docs",
-  "version": "0.1.30",
-  "description": "Distributed JSKIT agent workflows, guides, and generated reference maps.",
+  "version": "0.1.32",
+  "description": "Distributed JSKIT agent references, prompts, guides, and generated reference maps.",
   "type": "module",
   "files": [
     "DISTR_AGENT.md",
@@ -9,14 +9,13 @@
     "patterns",
     "reference",
     "skills",
-    "templates",
-    "workflow"
+    "templates"
   ],
   "scripts": {
     "test": "node --test"
   },
   "engines": {
-    "node": "20.x"
+    "node": ">=20 <23"
   },
   "publishConfig": {
     "access": "public"
@@ -25,6 +24,6 @@
     "jskit",
     "agent",
     "docs",
-    "workflow"
+    "session"
   ]
 }

package/patterns/page-scaffolding.md

@@ -9,7 +9,7 @@ Use when:
 
 Check first:
 
-- the blueprint route family and chosen surface
+- the app blueprint route family and chosen surface
 - `jskit show ui-generator --details`
 - `jskit list-placements`
 - the nearest existing routed host under `src/pages`
@@ -23,7 +23,7 @@ Rules:
 - If you need the concrete outlet inventory, use `jskit list-placements --concrete`; do not target concrete outlets by default.
 - If the page sits under an existing routed host, check whether `ui-generator page` can infer the correct `page.section-nav` owner before writing a custom link by hand.
 - If you do not use `ui-generator page`, state exactly why the generator does not fit before editing code.
-- For a small placeholder route inside an existing route family, update the workboard rather than rewriting the blueprint unless the durable route or surface plan changed.
+- For a small placeholder route inside an existing route family, keep the change scoped unless the durable route or surface plan in the app blueprint changed.
 - Generated live pages must be usable screens, not instructional scaffolds. Do not ship copy such as "replace this", "use this area", or "this page is ready".
 - Prefer a page header plus a direct `v-sheet` working region. Do not wrap every generated page in a generic `v-card`.
 - If the screen is not implemented yet, use a product-shaped empty state with one clear next action or status, not developer instructions.
@@ -42,7 +42,7 @@ Generated UI contract:
 Avoid:
 
 - hand-writing both `src/pages/...` and `src/placement.js` for a normal non-CRUD page before checking `ui-generator`
-- treating a small page stub as permission to rewrite marketing copy, route architecture, or blueprint scope
+- treating a small page stub as permission to rewrite marketing copy, route architecture, or app blueprint scope
 - claiming that no generator exists without checking the actual `jskit` generator inventory first
 - adding cards inside cards or repeating the page title inside a card title
 - treating Vuetify component defaults as the product architecture

package/patterns/surfaces.md

@@ -9,7 +9,7 @@ Use when:
 
 Check first:
 
-- the blueprint surface plan
+- the app blueprint surface plan
 - existing route roots under `src/pages`
 - placement visibility by `surfaces`
 

package/reference/autogen/packages/users-web.md

@@ -223,7 +223,7 @@ Local functions
 
 ### `src/client/composables/records/useCrudList.js`
 Exports
-- `useCrudList({ resource = null, requestQueryParams = null, parentBinding = null, recordIdParam = "recordId", route = null, ...listOptions } = {})`
+- `useCrudList({ resource = null, requestQueryParams = null, parentBinding = null, recordIdParam = "recordId", route = null, realtime = undefined, ...listOptions } = {})`
 Local functions
 - `resolveRequestQueryParamsInput(requestQueryParams, context = {})`
 - `resolveCrudParentRequestQueryParams({ resource = {}, route = null, recordIdParam = "recordId" } = {})`
@@ -238,7 +238,7 @@ Exports
 
 ### `src/client/composables/records/useView.js`
 Exports
-- `useView({ ownershipFilter = ROUTE_VISIBILITY_WORKSPACE, surfaceId = "", access = "auto", apiSuffix = "", queryKeyFactory = null, viewPermissions = [], readMethod = "GET", readEnabled = true, transport = null, placementSource = "users-web.view", fallbackLoadError = "Unable to load resource.", notFoundStatuses = [404], notFoundMessage = "Record not found.", model, mapLoadedToModel, requestQueryParams = null, recordIdParam = "recordId", routeParams = null, routeRecordId = null, apiUrlTemplate = "", listUrlTemplate = "", editUrlTemplate = "", includeRecordIdInQueryKey = false, realtime = null, adapter = null } = {})`
+- `useView({ ownershipFilter = ROUTE_VISIBILITY_WORKSPACE, surfaceId = "", access = "auto", apiSuffix = "", queryKeyFactory = null, viewPermissions = [], readMethod = "GET", readEnabled = true, transport = null, placementSource = "users-web.view", fallbackLoadError = "Unable to load resource.", notFoundStatuses = [404], notFoundMessage = "Record not found.", model, mapLoadedToModel, requestQueryParams = null, recordIdParam = "recordId", routeParams = null, routeRecordId = null, apiUrlTemplate = "", listUrlTemplate = "", editUrlTemplate = "", includeRecordIdInQueryKey = false, realtime = undefined, adapter = null } = {})`
 
 ### `src/client/composables/runtime/addEditUiRuntime.js`
 Exports
@@ -290,7 +290,7 @@ Exports
 Exports
 - `buildEndpointReadRequestOptions({ method = "GET", query = null, transport = null } = {})`
 - `buildEndpointWriteRequestOptions({ method = "PATCH", body = undefined, options = null, transport = null } = {})`
-- `useEndpointResource({ queryKey, path = "", enabled = true, client = usersWebHttpClient, readMethod = "GET", writeMethod = "PATCH", readQuery = null, transport = null, refreshOnPull = false, queryOptions = null, mutationOptions = null, fallbackLoadError = "Unable to load resource.", fallbackSaveError = "Unable to save resource." } = {})`
+- `useEndpointResource({ queryKey, path = "", enabled = true, client = usersWebHttpClient, readMethod = "GET", writeMethod = "PATCH", readQuery = null, transport = null, refreshOnPull = false, realtime = null, queryOptions = null, mutationOptions = null, fallbackLoadError = "Unable to load resource.", fallbackSaveError = "Unable to save resource." } = {})`
 Local functions
 - `resolveRequestQuery(value = null)`
 
@@ -501,10 +501,12 @@ Local functions
 
 ### `src/client/composables/useRealtimeQueryInvalidation.js`
 Exports
+- `resolveOperationRealtimeOptions({ realtime = undefined, fallbackRealtime = null } = {})`
 - `useRealtimeQueryInvalidation({ event = "", enabled = true, matches = null, queryKey = null, onEvent = null } = {})`
 - `useOperationRealtime({ realtime = null, queryKey = null, enabled = true } = {})`
 Local functions
 - `normalizeRealtimeOptions(value = {})`
+- `hasRealtimeEventConfig(value = {})`
 - `resolveEnabled(value)`
 - `toQueryKeyList(value)`
 

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

@@ -22,6 +22,19 @@ Exports
 Exports
 - None
 
+### `src/server/appBlueprint.js`
+Exports
+- `APP_BLUEPRINT_RELATIVE_PATH`
+- `APP_PROMPT_OVERRIDE_RELATIVE_ROOT`
+- `extractAppBlueprintText(value = "")`
+- `readAppBlueprint({ targetRoot = process.cwd() } = {})`
+- `readTextInputFile(cwd, inputPath)`
+- `renderAppBlueprintPrompt({ targetRoot = process.cwd(), appBrief = "" } = {})`
+- `resolveAppBlueprintPaths(targetRoot = process.cwd())`
+- `writeAppBlueprint({ targetRoot = process.cwd(), appBlueprint = "" } = {})`
+Local functions
+- `readAppPromptTemplate(paths, templateName)`
+
 ### `src/server/cliEntrypoint.js`
 Exports
 - `runCliEntrypoint(runCli, argv = process.argv.slice(2))`
@@ -209,6 +222,7 @@ Local functions
 Exports
 - `normalizeMutationExtension(value)`
 - `normalizeTemplateContextRecord(value)`
+- `normalizeDependencyMutationRecord(value)`
 - `normalizeFileMutationRecord(value)`
 - `normalizeMutationWhen(value)`
 - `readObjectPath(source, rawPath)`
@@ -234,6 +248,7 @@ Local functions
 - `isWorkspaceCapableTenancyMode(value = "")`
 - `collectInstallWarnings({ packageEntry, appRoot, appPackageJson })`
 - `resolveManagedSourceRecord(packageEntry, existingInstall = {})`
+- `dependencyMutationUsesWhen(entries = [])`
 
 ### `src/server/cliRuntime/packageIntrospection.js`
 Exports
@@ -417,6 +432,15 @@ Exports
 Exports
 - `runAppVerifyUiCommand(ctx = {}, { appRoot = "", options = {}, stdout, stderr })`
 
+### `src/server/commandHandlers/blueprint.js`
+Exports
+- `createBlueprintCommands(ctx = {})`
+Local functions
+- `writeJson(stdout, payload)`
+- `writeBlueprintText(stdout, payload)`
+- `readStream(stream)`
+- `resolveTextInput({ cwd, fileOption, inlineOptions = {}, io = {}, stdinOption = "-", textOption })`
+
 ### `src/server/commandHandlers/completion.js`
 Exports
 - `createCompletionCommands(ctx = {})`
@@ -638,6 +662,18 @@ Local functions
 Exports
 - `runPackageUpdateCommand(ctx = {}, { positional, options, cwd, io }, { runCommandAdd })`
 
+### `src/server/commandHandlers/session.js`
+Exports
+- `createSessionCommands()`
+Local functions
+- `writeJson(stdout, payload)`
+- `writeSessionText(stdout, payload)`
+- `readStream(stream)`
+- `resolveInputFilePath(cwd, filePath)`
+- `resolveTextInput({ codePrefix, fileOption, inlineOptions = {}, io = {}, repairCommand, cwd, stdinOption, textOption, sessionId })`
+- `resolveStepInputs({ inlineOptions = {}, io = {}, cwd, sessionId })`
+- `normalizeStepOptions(inlineOptions = {})`
+
 ### `src/server/commandHandlers/shared.js`
 Exports
 - `createCommandHandlerShared(ctx = {})`
@@ -678,6 +714,7 @@ Exports
 Local functions
 - `resolveGeneratorSubcommandRows(payload = {})`
 - `resolveOwnershipGuidance(payload = {})`
+- `renderDependencyMutationSpec(versionSpec)`
 
 ### `src/server/core/argParser.js`
 Exports
@@ -731,6 +768,136 @@ Local functions
 Exports
 - `runCli`
 
+### `src/server/sessionRuntime.js`
+Exports
+- `SESSION_STATUS`
+- `STEP_DEFINITIONS`
+- `STEP_IDS`
+- `STEP_PRECONDITION_NAMES`
+- `abandonSession({ targetRoot = process.cwd(), sessionId } = {})`
+- `adoptCodexThreadId({ targetRoot = process.cwd(), sessionId, codexThreadId } = {})`
+- `buildSessionResponse`
+- `buildSessionErrorResponse`
+- `createSession({ targetRoot = process.cwd(), sessionId = "", now = new Date() } = {})`
+- `createSessionId`
+- `extractIssueText(value = "")`
+- `inspectSession({ targetRoot = process.cwd(), sessionId } = {})`
+- `inspectSessionDetails({ targetRoot = process.cwd(), sessionId } = {})`
+- `isValidSessionId`
+- `listSessions({ targetRoot = process.cwd() } = {})`
+- `renderTemplate`
+- `resolveSessionPaths`
+- `runSessionStep({ targetRoot = process.cwd(), sessionId, options = {} } = {})`
+Local functions
+- `invalidSessionIdError(sessionId = "")`
+- `invalidSessionIdResponse({ targetRoot, sessionId })`
+- `existingSessionContext({ targetRoot = process.cwd(), sessionId } = {})`
+- `withExistingSession(input, handler)`
+- `emptySessionDetails(response)`
+- `createWorktree(paths, _options = {}, context = {})`
+- `renderIssuePrompt(paths, options = {})`
+- `draftIssue(paths, options = {})`
+- `titleFromIssue(issueText)`
+- `createIssue(paths, _options = {}, context = {})`
+- `renderImplementationPrompt(paths)`
+- `worktreeStatus(worktree)`
+- `detectChanges(paths)`
+- `commitWorktree(paths, { message, allowNoChanges = false } = {})`
+- `commitImplementation(paths)`
+- `changedFilesFromLastCommit(paths)`
+- `reviewPromptStepId(passNumber)`
+- `renderReviewPrompt(paths, passNumber)`
+- `reviewChangesStepId(passNumber)`
+- `detectAndCommitReviewChanges(paths, passNumber)`
+- `userCheckStepId(passNumber)`
+- `userCheck(paths, passNumber, options = {})`
+- `readPackageJson(root)`
+- `doctorCommandForWorktree(worktree)`
+- `runDoctor(paths)`
+- `pushBranch(paths)`
+- `issueNumberFromUrl(issueUrl)`
+- `createPr(paths)`
+- `mergePr(paths)`
+- `removeWorktree(paths)`
+- `finishSession(paths)`
+- `runNamedPreconditions(paths, names = [])`
+
+### `src/server/sessionRuntime/constants.js`
+Exports
+- `PROMPT_DIRECTORY`
+- `SESSION_ID_PATTERN`
+- `SESSION_STATUS`
+- `STEP_DEFINITIONS`
+- `STEP_IDS`
+- `STEP_LABEL_BY_ID`
+- `SESSION_STATE_RELATIVE_PATH`
+
+### `src/server/sessionRuntime/io.js`
+Exports
+- `fileExists(filePath)`
+- `normalizeText(value)`
+- `readTextIfExists(filePath)`
+- `readTrimmedFile(filePath)`
+- `runCommand(command, args = [], { cwd, env = {}, timeout = 30000 } = {})`
+- `runGit(targetRoot, args = [], options = {})`
+- `runGitInWorktree(worktree, args = [], options = {})`
+- `timestampForReceipt(now = new Date())`
+- `writeTextFile(filePath, value)`
+
+### `src/server/sessionRuntime/paths.js`
+Exports
+- `archiveSession(paths, archive)`
+- `createAvailableSessionId(targetRoot, now = new Date())`
+- `createSessionId(now = new Date())`
+- `isValidSessionId(sessionId = "")`
+- `normalizeSessionId(sessionId = "")`
+- `resolveExistingSessionRoot(paths)`
+- `resolveSessionPaths({ targetRoot, sessionId = "" } = {})`
+- `pathsForExistingSession(paths)`
+Local functions
+- `formatDatePart(value)`
+
+### `src/server/sessionRuntime/preconditions.js`
+Exports
+- `applyPreconditions(paths, checks = [])`
+- `assertGhAuth(targetRoot)`
+- `assertGitCurrentBranch(targetRoot)`
+- `assertGitRepository(targetRoot)`
+- `assertGithubOrigin(targetRoot)`
+- `assertIssueArtifacts(paths)`
+- `assertIssueTextExists(paths)`
+- `assertPrUrlExists(paths)`
+- `assertSessionExists(paths)`
+- `assertTargetRootWritable(targetRoot)`
+- `assertWorktreeExists(paths)`
+- `ensureStudioGitExclude(targetRoot)`
+- `hasWorktree(paths)`
+Local functions
+- `resolveGitCommonDirectory(targetRoot)`
+
+### `src/server/sessionRuntime/promptRenderer.js`
+Exports
+- `readPromptTemplate(targetRoot, name)`
+- `renderPrompt(paths, templateName, values = {})`
+- `renderTemplate(source, values = {})`
+
+### `src/server/sessionRuntime/responses.js`
+Exports
+- `buildSessionErrorResponse({ targetRoot = process.cwd(), sessionId = "", code, message, repairCommand = "", status = SESSION_STATUS.BLOCKED, preconditions = [], errors = undefined } = {})`
+- `buildSessionResponse(paths, { ok = true, errors = [], preconditions = [], prompt = undefined, status = undefined } = {})`
+- `createError({ code, message, repairCommand = "" })`
+- `createPrecondition({ id, ok, message })`
+- `failSession(paths, { code, message, repairCommand = "", preconditions = [], status = SESSION_STATUS.BLOCKED, prompt = "" })`
+- `markCurrentStep(paths, stepId)`
+- `markStatus(paths, status)`
+- `readReceiptSteps(paths)`
+- `readSessionArtifacts(paths)`
+- `writeReceipt(paths, stepId, message)`
+Local functions
+- `readCompletedSteps(sessionRoot)`
+- `resolveNextStep(completedSteps = [])`
+- `buildNextCommand(sessionId, stepId)`
+
 ### `src/server/shared/cliError.js`
 Exports
 - `createCliError(message, { showUsage = false, exitCode = 1, renderUsage = null } = {})`

package/skills/jskit-review/SKILL.md

@@ -13,10 +13,9 @@ Preferred execution mode:
 - Use the current agent only when delegation is unavailable.
 - The same rule applies to chunk review and whole-changeset review.
 
-## Read first
+## Read First
 
-1. `../../workflow/review.md`
-2. `../../workflow/feature-delivery.md`
+Use the current `jskit session` review prompt as the source of truth when the review is part of a session.
 
 Read these on demand:
 
@@ -25,10 +24,10 @@ Read these on demand:
 - `../../guide/agent/index.md`
 - `../../site/guide/index.md` when compressed guidance is ambiguous
 
-Inspect app-local files when they exist:
+Inspect app-local session files when they exist:
 
-- `.jskit/WORKBOARD.md`
-- `.jskit/APP_BLUEPRINT.md`
+- `.jskit/sessions/active/<session_id>/prompt.md`
+- `.jskit/sessions/active/<session_id>/issue.md`
 
 ## Review target
 
@@ -37,7 +36,7 @@ Determine whether the target is:
 - the current chunk
 - or the whole changeset
 
-Use `.jskit/WORKBOARD.md` to determine the active chunk when available.
+Use the active `jskit session` state to determine the current pass when available.
 
 ## Required passes
 

package/templates/app/AGENTS.md

@@ -1,106 +1,17 @@
 # App Agent Instructions
 
-Use this file as the app-facing instruction entrypoint.
+JSKIT issue work is driven by the executable session workflow.
 
-Read these workflow files in order:
+Use:
 
-1. `node_modules/@jskit-ai/agent-docs/workflow/app-state.md`
-2. `node_modules/@jskit-ai/agent-docs/workflow/bootstrap.md` if the workspace is empty or no JSKIT app exists yet
-3. `node_modules/@jskit-ai/agent-docs/workflow/scoping.md`
-4. `node_modules/@jskit-ai/agent-docs/workflow/workboard.md`
-5. `node_modules/@jskit-ai/agent-docs/workflow/feature-delivery.md`
-6. `node_modules/@jskit-ai/agent-docs/workflow/review.md`
+- `jskit session` to list existing sessions.
+- `jskit session create` to start a new issue session.
+- `jskit session <session_id>` to inspect durable session state.
+- `jskit session <session_id> step` to run the next workflow step or get the next prompt.
+- `jskit session <session_id> step --json` when a tool or UI needs machine-readable state.
 
-Use these references on demand:
+Do not invent a parallel manual issue workflow. Follow the current session step output.
 
-- `node_modules/@jskit-ai/agent-docs/reference/autogen/KERNEL_MAP.md`
-- `node_modules/@jskit-ai/agent-docs/reference/autogen/README.md`
-- `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md`
-- `node_modules/@jskit-ai/agent-docs/guide/agent/index.md`
-- `node_modules/@jskit-ai/agent-docs/site/guide/index.md` when compressed guidance is ambiguous or missing nuance
-- `node_modules/@jskit-ai/agent-docs/templates/APP_BLUEPRINT.md`
-- `node_modules/@jskit-ai/agent-docs/templates/WORKBOARD.md`
-- `node_modules/@jskit-ai/agent-docs/skills/jskit-review/SKILL.md` for review passes when your Codex environment supports packaged skills
+If dependencies are missing, install them first. If `npm install` is run while this app uses local JSKIT checkout links, run `npm run devlinks` immediately afterward.
 
-## Mandatory Start Gate
-
-Before any non-trivial change:
-
-1. Read this file and the workflow files above in the current turn. Do not rely on memory alone.
-2. If the task involves JSKIT UI, routing, surfaces, CRUDs, filters, placements, live actions, or similar implementation details, scan `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` and read the relevant pattern files before editing.
-3. For substantial or multi-chunk work, create or update `.jskit/WORKBOARD.md` before editing.
-4. Before editing, print a compact read receipt with:
-   - `Read receipt: ...`
-   - `Active chunk: ...`
-   - `Generator decision: ...` with the exact `jskit` command to run, or the exact generator/placement discovery commands checked and why no generator applies
-   - `Relevant patterns: ...`
-   - `Active rules from docs: ...`
-5. When files need to be created, prefer `jskit generate ...` over creating them from scratch, even if the generated output will need follow-up adaptation. For a new non-CRUD route page or menu-linked screen, default to `jskit generate ui-generator page ...`. If not using a generator, say why.
-6. Do not edit code until the read receipt is printed and the workboard step is complete when it applies.
-
-## Mandatory Done Gate
-
-Before calling a chunk done, report:
-
-- `Deslop review: ...`
-- `JSKIT review: ...`
-- `Material/Vuetify review: ...`
-- `Playwright: ...` for any chunk that adds or changes user-facing UI
-- `Verification: ...`
-- `Files changed: ...`
-- `Commands run: ...`
-- `Remaining unverified: ...`
-
-If a feature spans more than one chunk, repeat those passes on the whole changeset after the final chunk.
-
-Core rules:
-
-- Inspect the workspace before assuming a JSKIT app exists.
-- Before non-trivial edits, print a short visible checkpoint using this format:
-  - `Problem: ...`
-  - `Fix: ...`
-  - `Why this sticks: ...`
-  - `Not doing: ...`
-- Keep that checkpoint compact. Do not expand it into a long preamble unless the developer asks for detail.
-- Reuse existing JSKIT helpers and runtime seams before adding new local helpers.
-- If `npm install` is run while the app is using local JSKIT checkout links, run `npm run devlinks` immediately afterward.
-- A freshly scaffolded JSKIT app can still be in Stage 1. If the app was just created and platform decisions are not settled yet, continue with the initialize workflow before adding runtime packages.
-- Do not treat a missing `config.tenancyMode` line or an untouched minimal scaffold as a final tenancy decision.
-- Do not install tenancy-sensitive packages until Stage 1 decisions are complete and the chosen tenancy is written into `config/public.js`.
-- Treat standard JSKIT package-owned workflows as the default baseline once the relevant package stack is chosen. Do not ask the developer to redesign those flows unless they want overrides, restrictions, or custom additions.
-- Example: if the app is workspace-capable and uses `workspaces-core` plus `workspaces-web`, assume the standard workspace invite flow is part of the baseline package behavior.
-- For baseline package setup, ask plainly for the exact local development values needed for the next install step, but only for the modules or packages that are actually selected.
-- Use the real env var names or option names instead of vague requests for "credentials". Values such as `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `AUTH_SUPABASE_URL`, `AUTH_SUPABASE_PUBLISHABLE_KEY`, and `APP_PUBLIC_URL` are routine setup inputs when the relevant package stack needs them.
-- For CRUD chunks, creating the server CRUD with `jskit generate crud-server-generator scaffold ...` is the crucial first step even if no CRUD UI will be created yet.
-- Unless a table is already owned by a JSKIT baseline package or is an explicit narrow exception recorded in `.jskit/table-ownership.json`, every persisted app-owned table must have its own server CRUD package created first with `jskit generate crud-server-generator scaffold ...`, even if no CRUD UI will ever exist.
-- Treat that as a hard invariant, not a style preference. If a persisted app-owned table does not have generated CRUD ownership, `jskit doctor` is expected to fail.
-- If the table should be CRUD-owned but should not expose public CRUD HTTP routes yet, use `jskit generate crud-server-generator scaffold ... --internal` rather than dropping to direct knex or a hand-built pseudo-repository.
-- For a CRUD table that `crud-server-generator` will own, do not hand-write a separate migration. Create the real table directly in the database first, then scaffold the server CRUD so JSKIT can install and manage the CRUD migration scaffold itself.
-- Do not generate CRUD UI or hand-build CRUD routes before the server CRUD package and shared resource file exist.
-- `feature-server-generator` is for workflows, orchestration, and other non-CRUD server features. Do not use it as the starting point for ordinary persisted entity tables.
-- Keep direct knex minimal and exceptional. Outside generated CRUD packages and explicit weird-custom feature lanes, app-owned runtime code should use internal `json-rest-api` seams instead of talking to knex directly.
-- For CRUD chunks, ask the developer which operations are allowed, which fields belong in the list view if one exists, and the intended look of the view and edit/new forms before generating code.
-- Every user-facing screen must pass a Material Design and Vuetify quality review before the chunk is considered done.
-- Any chunk that adds or changes user-facing UI must include a Playwright check that exercises the changed behavior before the chunk is considered done.
-- Record that Playwright run with `jskit app verify-ui --command "<playwright command>" --feature "<label>" --auth-mode <mode>` so `jskit doctor` can verify the receipt. For local pre-merge review, normally follow it with `jskit doctor --against <base-ref>`. Advanced CI setups may also use `--against <base-ref>`, but that is app-specific.
-- If the UI flow requires login, use the app's development-only auth bypass or session bootstrap path instead of a live external auth login flow.
-- In JSKIT apps using the standard auth stack, that means enabling the dev auth bypass in development and using `POST /api/dev-auth/login-as` during Playwright setup.
-- If authenticated UI work has no usable local auth bootstrap path yet, treat that as a testability gap and call it out before the chunk can be considered complete.
-- Do not implement app features before the blueprint has the database, surfaces, ownership model, and route/screen plan written down.
-- Plan implementation work as vertical slices. Each chunk should deliver a user-visible or end-to-end outcome that the developer can recognize in the app or behavior, not just an isolated layer change.
-- Do not churn `.jskit/APP_BLUEPRINT.md` for a small placeholder page or route stub that fits an existing route family unless the durable route/surface plan actually changed. Track request-level movement in `.jskit/WORKBOARD.md` instead.
-- Break planned work into reviewable chunks before implementing. One CRUD is usually one chunk, but auth/platform setup, shell work, and cross-cutting integrations can be their own chunks.
-- Avoid horizontal chunk plans like "all migrations first", "all routes next", or "all UI last" unless platform setup truly forces that order. Prefer slices the developer can inspect as real progress.
-- Do not move to the next chunk until the current chunk has passed implementation, deslop review, JSKIT best-practices review, Material Design/Vuetify review, and verification.
-- If a feature spans more than one chunk, run a final whole-changeset deslop pass, JSKIT pass, Material Design/Vuetify pass, and verification pass after the last chunk.
-- Prefer a fresh review agent for chunk and whole-changeset review when the runtime supports delegation.
-- Have that fresh review agent use the packaged `jskit-review` skill when it is available to the runtime.
-- If delegation or skills are unavailable, follow `workflow/review.md` manually in the current agent.
-- Use the compressed guide first for speed; fall back to the human guide when a workflow trap, migration caveat, or architectural boundary needs exact wording.
-- Treat generated reference maps and guide copies as vendor reference. Do not edit them manually.
-
-If dependencies are not installed yet:
-
-- install dependencies so `node_modules/@jskit-ai/agent-docs/` exists
-- inspect the workspace before assuming a JSKIT app already exists
-- if the workspace is empty and the user wants a new app, start with the initialize workflow at a high level first
+For JSKIT implementation details, use package docs, generated references, and `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` only as technical references. They are not the issue workflow source of truth.

package/templates/APP_BLUEPRINT.md

@@ -1,81 +0,0 @@
-# App Blueprint
-
-## Product
-
-- App purpose:
-- Primary users:
-- Success criteria:
-
-## Platform Choices
-
-- Tenancy mode:
-- Database engine:
-- Auth provider:
-- Optional extras: realtime / assistant / uploads / other
-
-## Actors And Access
-
-- Actor list:
-- Permission boundaries:
-- Console/admin-only areas:
-
-## Surfaces
-
-- Global surfaces:
-- Workspace surfaces:
-- Settings surfaces:
-
-## Data Model
-
-| Entity | Purpose | Ownership | Notes |
-| --- | --- | --- | --- |
-| | | | |
-
-## Route And Screen Plan
-
-- Home/global routes:
-- Account routes:
-- Console routes:
-- Workspace app routes:
-- Workspace admin routes:
-
-## Package Plan
-
-- Baseline runtime packages:
-- Optional runtime packages:
-- Generator packages to use:
-- Package-owned workflows to accept as baseline:
-- Package-owned workflows to override or extend:
-
-## Implementation Notes
-
-- CRUDs to scaffold:
-- Non-CRUD pages to scaffold:
-- Custom code areas:
-
-## CRUD Planning
-
-| CRUD | Operations | List Fields | View Form Shape | Edit/New Form Shape | Notes |
-| --- | --- | --- | --- | --- | --- |
-| | | | | | |
-
-## Delivery Plan
-
-| Chunk | Goal | Type | Depends on | Done when |
-| --- | --- | --- | --- | --- |
-| | | | | |
-
-Chunk notes:
-
-- One CRUD is usually one chunk.
-- Platform/auth/shell work may be its own chunk.
-- Prefer vertical slices that produce visible or end-to-end progress the developer can inspect.
-- Each chunk must be independently reviewable and testable.
-
-## Verification
-
-- Commands to run:
-- Playwright coverage plan:
-- Test auth strategy:
-- UI review expectations:
-- Known open questions:

package/templates/WORKBOARD.md

@@ -1,46 +0,0 @@
-# Workboard
-
-## Request
-
-- Request summary:
-- Current stage:
-- Current status:
-
-## Scope Snapshot
-
-- Platform decisions:
-- Current blueprint path:
-- Current workboard owner:
-
-## Chunk Tracker
-
-| Chunk | Goal | Status | Deslop | JSKIT Review | UI Review | Verification | Notes |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| | | | | | | | |
-
-Status guide:
-
-- `planned`
-- `active`
-- `implemented`
-- `reviewed`
-- `verified`
-- `done`
-- `blocked`
-
-## Current Focus
-
-- Active chunk:
-- Next action:
-- Blockers:
-
-## Verification Log
-
-- Commands run:
-- Playwright status:
-- Remaining unverified:
-
-## Notes
-
-- Decisions made:
-- Open questions:

package/workflow/app-state.md

@@ -1,34 +0,0 @@
-# App State Gate
-
-Before planning, scaffolding, or implementing, classify the workspace into one of these states:
-
-- `empty`
-- `non_jskit_repo`
-- `partial_jskit_app`
-- `jskit_app`
-
-Use these markers for a real JSKIT app:
-
-- `package.json`
-- `config/public.js`
-- `src/main.js`
-- `packages/main/package.descriptor.mjs`
-- `.jskit/lock.json`
-
-State handling:
-
-- `empty`
-  - Start the initialize workflow.
-  - Ask only high-level questions first: app goal, tenancy shape, database engine, auth provider, optional assistant/realtime needs.
-  - Do not jump straight into detailed feature implementation.
-- `non_jskit_repo`
-  - Ask whether the JSKIT app should live here or in a new subdirectory.
-  - Do not overwrite unrelated project files.
-- `partial_jskit_app`
-  - Explain which scaffold markers are missing.
-  - Recover or finish the scaffold instead of re-initializing from scratch.
-- `jskit_app`
-  - If this is a fresh minimal scaffold and Stage 1 platform decisions are not settled yet, continue with the initialize workflow first.
-  - Otherwise continue with scoping or feature delivery.
-
-This state gate is intentionally strict. The agent must inspect first and only then choose initialize, recover, or extend.

package/workflow/bootstrap.md

@@ -1,62 +0,0 @@
-# Initialize Workflow
-
-Use this when:
-
-- the app state gate resolves to `empty`
-- the user explicitly wants a brand-new JSKIT app in a new directory
-- or a fresh minimal JSKIT scaffold exists but Stage 1 platform decisions are not settled yet
-
-Safe bootstrap paths:
-
-1. Empty directory path
-   - Ask the Stage 1 platform questions first.
-   - Once the high-level shape is clear, run `create-app` with the chosen tenancy mode.
-2. Fresh scaffold path
-   - If the app was just created with `npx @jskit-ai/create-app <app-name>` and `npm install`, treat that scaffold as provisional.
-   - Ask the Stage 1 platform questions before adding tenancy-sensitive packages.
-   - If the chosen tenancy is `personal` or `workspaces`, write it into `config/public.js` before installing workspace packages.
-   - Once a baseline package stack is chosen, assume its standard package-owned workflows unless the developer asks for overrides.
-
-Important constraint:
-
-- Do not install tenancy-sensitive packages while tenancy is still provisional.
-- In practice, that means `workspaces-core` and `workspaces-web` must wait until the Stage 1 tenancy decision is complete.
-- A missing `config.tenancyMode` line behaves like `none` at runtime. Treat it as provisional only if no tenancy-sensitive package install has happened yet.
-
-Version 0 sketch:
-
-1. Define the broad app shape before running generators.
-2. Capture only the first-round decisions:
-   - app purpose
-   - tenancy mode: `none`, `personal`, or `workspaces`
-   - database engine: MySQL or Postgres
-   - auth provider, with Supabase as the default documented path
-   - whether the first baseline should include workspaces, realtime, or assistant
-3. Treat Stage 1 as a package-stack decision, not a blank-slate workflow design exercise.
-4. Once those high-level choices are clear, continue into deeper scoping questions later.
-
-Ask setup values plainly:
-
-- Only ask for setup values that correspond to the modules or packages already chosen for the baseline.
-- When the next package install needs concrete local development values, ask for them directly using the exact env var names or option names.
-- Do not hide behind vague requests for "credentials" or "values after that boundary".
-- If MySQL or Postgres is selected, confirm that the target database already exists before the runtime install, or that the developer has enough local admin or create-database access to create it now.
-- Do not proceed as if `DB_NAME` alone means the database is ready. The actual database must exist before the database runtime install and migration flow can be treated as valid.
-- In this workflow, these are routine setup inputs:
-  - If the MySQL runtime is selected: `DB_NAME`, `DB_USER`, `DB_PASSWORD`
-  - If the MySQL host or port differs from the local default `127.0.0.1:3306`: `DB_HOST`, `DB_PORT`
-  - If Supabase auth is selected: `AUTH_SUPABASE_URL`, `AUTH_SUPABASE_PUBLISHABLE_KEY`
-  - If browser-facing auth callbacks are relevant: confirm whether `APP_PUBLIC_URL` should stay `http://localhost:5173`
-- Ask in plain language and continue once the developer provides the values.
-
-Baseline expectations after initialization:
-
-- create the app scaffold
-- install the baseline runtime packages in the documented order
-- install dependencies
-- run `npm run devlinks` immediately after `npm install` when the app is using local JSKIT checkout links
-- run database migrations when the chosen package set requires them
-- use the standard packaged workflows that come with those packages unless the blueprint records an override
-- leave the app in a reproducible, verified baseline state
-
-Do not improvise package order. Use the distributed guide chapters under `guide/agent/app-setup/` or `site/guide/app-setup/`.

package/workflow/feature-delivery.md

@@ -1,82 +0,0 @@
-# Feature Delivery Workflow
-
-Before implementation, break the planned work into chunks.
-
-Chunk rules:
-
-- One CRUD is usually one chunk.
-- Platform setup, shell/navigation, and cross-cutting integrations may be separate chunks.
-- A chunk must be independently reviewable and testable.
-- Prefer vertical slices. A chunk should usually produce a user-visible or end-to-end outcome, not just a hidden layer-only milestone.
-- If a chunk is too broad to review confidently, split it before coding.
-- Avoid horizontal plans like "database first, then routes, then UI" unless the work is foundational platform setup that genuinely cannot be sliced vertically yet.
-
-For each chunk, follow this order:
-
-1. Scope the chunk inside the blueprint.
-2. Mark the chunk as active in `.jskit/WORKBOARD.md`.
-3. Decide whether it is:
-   - package install
-   - generator scaffolding
-   - custom local code
-   - or a combination
-   Record the exact `jskit` commands that will be used if generators or package installs apply.
-4. Implement the smallest correct change.
-5. Deslop the chunk.
-6. Review the chunk against JSKIT reuse and best practices.
-7. Review user-facing screens against Material Design and Vuetify best practices, and improve any screens that do not meet that bar.
-8. Verify the chunk with the relevant commands. Any chunk that adds or changes user-facing UI must include a Playwright flow that exercises the changed behavior, and that run must be recorded with `jskit app verify-ui`.
-9. Update `.jskit/WORKBOARD.md` with status, commands run, and anything still unverified.
-10. Only then move to the next chunk.
-
-For CRUD chunks:
-
-1. Decide the table shape first.
-2. Create the real table directly in the database before scaffolding. `crud-server-generator` reads the live table shape; it does not invent the table for you.
-3. Unless the table is already owned by a JSKIT baseline package or is a narrow explicit exception recorded in `.jskit/table-ownership.json`, every persisted app-owned table must have a server CRUD package. Do not let a new table exist without that ownership decision.
-4. If `crud-server-generator` is going to own the CRUD schema, do not hand-write a separate migration for that CRUD table. The server generator installs and manages the CRUD migration scaffold itself.
-5. Scaffold the server side first with `crud-server-generator`, even if no CRUD UI will be created yet.
-6. Only after the shared resource file exists, scaffold the client side against that resource.
-7. Treat that shared resource file as the canonical CRUD definition. Put field and ownership changes there instead of hand-duplicating derived CRUD validators elsewhere.
-8. Do not guess CRUD operations or screen shape. Ask the developer:
-   - which operations are allowed
-   - which fields belong in the list view if one exists
-   - what the view form should look like
-   - what the edit/new form should look like
-
-During implementation:
-
-- Prefer existing JSKIT helpers over local helper duplication.
-- If a selected JSKIT package already ships the required baseline workflow, install and verify that workflow before inventing custom code around it.
-- Ask only about overrides, restrictions, or app-specific additions to packaged baseline workflows.
-- Use generated CRUD/UI scaffolds only after the route and ownership model are decided.
-- Do not hand-build CRUD routes, CRUD endpoints, or CRUD page trees before `crud-server-generator` has created the server package and shared resource file.
-- `feature-server-generator` is for non-CRUD workflows and orchestration. Do not use it as the first persistence lane for ordinary entity tables.
-- For app-owned non-CRUD route pages, default to `jskit generate ui-generator page ...` instead of hand-writing both `src/pages/...` and `src/placement.js`.
-- Before hand-writing a route page or placement entry, check `jskit show ui-generator --details` and `jskit list-placements`.
-- If `ui-generator page` applies and you still choose not to use it, stop and explain the exact gap before coding.
-- Keep runtime, UI, and data concerns separated.
-- Keep direct knex exceptional and minimal. Outside generated CRUD packages and explicit weird-custom feature lanes, app-owned runtime code should stay on internal `json-rest-api` seams.
-- Avoid “while I’m here” scope creep unless it is required for correctness.
-- Do not turn a small placeholder or route stub into a copy-polish or blueprint-rewrite task unless the developer asked for that broader work.
-
-After the last chunk:
-
-- If there was only one chunk, the chunk review is the final review.
-- If there was more than one chunk, run one more whole-changeset pass:
-  - deslop the whole changeset
-  - review the whole changeset against JSKIT best practices
-  - review the whole changeset against Material Design and Vuetify best practices
-  - run the widest relevant verification, including Playwright
-  - update `.jskit/WORKBOARD.md` with the final result and any remaining gaps
-
-Playwright note:
-
-- When login is required, use a test-only auth bypass or session bootstrap path instead of dependence on a live external auth provider.
-- Record the run through `jskit app verify-ui --command "<playwright command>" --feature "<label>" --auth-mode <mode>` so `jskit doctor` can verify the receipt against the current changed UI files.
-- In local pre-merge review, use `jskit doctor --against <base-ref>` after the recorded Playwright run so JSKIT compares against the branch delta, not only the current dirty worktree.
-- Advanced CI setups may also use `--against <base-ref>`, but JSKIT does not scaffold hosted browser/auth/database verification by default.
-- In the standard JSKIT auth stack, the default development path is `POST /api/dev-auth/login-as`, guarded by `AUTH_DEV_BYPASS_ENABLED=true` and `AUTH_DEV_BYPASS_SECRET=...`.
-- That route is development-only and must not be enabled in production.
-- Because it is still an unsafe POST, fetch `csrfToken` from `/api/session`, send it as the `csrf-token` header, and make the request in the same browser context that will run the Playwright assertions so the session cookies land in the page session.
-- If such a path does not exist yet, treat that as a testability gap and decide whether the chunk must add it before the feature is considered complete.

package/workflow/review.md

@@ -1,56 +0,0 @@
-# Review Workflow
-
-Preferred review mode:
-
-- Prefer a fresh review agent for chunk and whole-changeset review when the runtime supports delegation.
-- Have that fresh review agent use the packaged `jskit-review` skill when it is available.
-- If delegation or skills are unavailable, follow this file manually in the current agent.
-
-Before calling a chunk or a whole changeset done, review it in four passes:
-
-1. Deslop review
-   - repeated functions or duplicated local helpers
-   - helpers reimplemented locally when a kernel/runtime seam already exists
-   - placeholder, fake-complete, or vague UI/copy/code structure
-   - dead code, unused props/imports, TODO-shaped gaps, or accidental abstractions
-   - missing loading, empty, error, permission, or ownership states
-   - broken flows, missing route wiring, or missing migrations
-   - surface or entity ownership mistakes: `public`, `user`, `workspace`, `workspace_user`
-2. JSKIT review
-   - existing helper/runtime seam available?
-   - duplicate local code that should reuse kernel/runtime support?
-   - should this have been a package install, generator step, or scaffold extension instead of hand code?
-   - if a generator existed, was the exact `jskit` command used or was the gap documented clearly before hand-coding?
-   - for CRUD work, was `crud-server-generator scaffold` used before any CRUD UI or CRUD route hand-coding?
-   - for CRUD tables owned by JSKIT, did the change avoid a separate hand-written CRUD migration?
-   - does every live app-owned table now have either declared generated/package CRUD ownership or an explicit narrow `.jskit/table-ownership.json` exception?
-   - is any direct app-owned knex usage limited to generated CRUD packages or explicit weird-custom feature lanes?
-   - are surface, route, ownership, and migration choices aligned with JSKIT conventions?
-   - package metadata and actual behavior still aligned?
-3. UI standards review
-   - every user-facing screen follows Material Design and Vuetify best practices
-   - list screens use clear hierarchy, actions, density, empty states, and table/list patterns
-   - view and edit/new screens use clear form grouping, labels, helper text, validation, spacing, and action placement
-   - responsive layout, loading, disabled, success, and error states are coherent
-   - improve weak screens before sign-off; do not just note the problem and move on
-4. Verification review
-   - run the smallest relevant verification commands for a chunk
-   - run the widest relevant verification commands for a whole changeset
-   - any added or changed user-facing UI must be exercised with Playwright
-   - that Playwright run should normally be recorded through `jskit app verify-ui`
-   - for local pre-merge review, prefer following that receipt with `jskit doctor --against <base-ref>`
-   - if login is required, use the chosen local test-auth path instead of live external auth
-   - in the standard JSKIT auth stack, prefer the development-only `POST /api/dev-auth/login-as` path
-   - if there is no usable local auth bootstrap path, explicitly record that as a blocking testability gap
-   - note anything left unverified
-
-Minimum expectation:
-
-- list the files changed
-- list the commands run
-- list anything still unverified
-- update `.jskit/WORKBOARD.md` with the review outcome
-
-Whole-changeset rule:
-
-- If the work was split into more than one chunk, repeat all four passes over the whole changeset after the final chunk is complete.

package/workflow/scoping.md

@@ -1,53 +0,0 @@
-# Scoping Workflow
-
-Before implementing any feature or batch of features, create or update an app-local working blueprint using `templates/APP_BLUEPRINT.md` as the template.
-
-Recommended location:
-
-- `.jskit/APP_BLUEPRINT.md`
-- `.jskit/WORKBOARD.md` for per-request progress tracking
-
-Do not edit the vendor template in `node_modules/` directly.
-
-The blueprint must capture at least:
-
-- product purpose
-- actors and permissions
-- tenancy mode
-- database engine
-- auth choice
-- core surfaces and route families
-- core entities
-- ownership model per entity: `public`, `user`, `workspace`, or `workspace_user`
-- package install plan
-- generator plan
-- custom-code areas
-- baseline package-owned workflows and any intended overrides
-- delivery plan broken into chunks
-- CRUD-specific operation and screen decisions where relevant
-
-Scoping rules:
-
-- Use `guide/agent/index.md` for fast navigation and `site/guide/index.md` for exact details.
-- Inspect packages and generators before choosing them.
-- Make the generator plan concrete. Name the exact `jskit` commands expected for the chunk, not just a package or a general idea.
-- For non-CRUD route page work, check `jskit show ui-generator --details` and `jskit list-placements` before deciding that custom page or placement code is necessary.
-- For CRUD work, make the server-first plan explicit. Name the exact `jskit generate crud-server-generator scaffold ...` command before any CRUD UI plan.
-- Before accepting a new persisted app-owned table, decide whether it is CRUD-owned or a narrow explicit exception. If it is not already owned by a JSKIT baseline package, the default answer should be server CRUD ownership.
-- If a CRUD will be owned by `crud-server-generator`, plan around a real table that already exists in the database. Do not plan a separate hand-written CRUD migration for that table.
-- Decide ownership early; do not treat it as a UI-only detail.
-- If Stage 1 platform choices are still provisional, finish them before installing tenancy-sensitive runtime packages.
-- Record which selected JSKIT package-owned workflows are accepted as baseline and which, if any, need custom behavior.
-- Do not ask the developer to redesign package-owned baseline workflows from scratch. Ask only whether the default behavior is accepted or whether the app needs overrides, restrictions, or extensions.
-- Create or refresh `.jskit/WORKBOARD.md` for substantial or multi-chunk work so the request has an explicit execution tracker.
-- Do not rewrite `.jskit/APP_BLUEPRINT.md` for a one-off placeholder page inside an already planned route family unless the durable route plan, surface plan, or ownership model changed.
-- Break delivery into chunks that can be independently reviewed and tested.
-- One CRUD is usually one chunk. Platform setup, shell work, and cross-cutting integrations may also be separate chunks.
-- For each CRUD chunk, decide these before implementation:
-  - which operations exist: `list`, `view`, `new`, `edit`, `delete`, or a narrower set
-  - which fields appear in the list view if a list exists
-  - the intended structure and visual hierarchy of the view form
-  - the intended structure and visual hierarchy of the edit/new form
-- If the package/runtime choice is unclear, stop and resolve it before writing implementation code.
-
-No feature implementation should start until the blueprint covers database, screens, functional boundaries, and chunk plan well enough that the implementation path is obvious.

package/workflow/workboard.md

@@ -1,29 +0,0 @@
-# Workboard Workflow
-
-Use a workboard for any substantial request, especially:
-
-- new app builds
-- multi-chunk feature work
-- requests that need scoping before coding
-- requests where verification spans several steps
-
-Recommended location:
-
-- `.jskit/WORKBOARD.md`
-
-Use `templates/WORKBOARD.md` as the starting template.
-
-Purpose:
-
-- track the current request
-- record the current stage and current chunk
-- track chunk status across implementation, deslop, JSKIT review, UI review, and verification
-- record blockers, open questions, and remaining gaps
-
-Workboard rules:
-
-- The workboard is the execution tracker for the current request.
-- The blueprint remains the durable product and architecture record.
-- Keep the workboard concise and current.
-- Update it when stage, chunk, blockers, or verification state changes.
-- When the request finishes, either reset it for the next request or leave a short final state that makes completion obvious.