@jskit-ai/jskit-cli 0.2.96 → 0.2.98

package/src/server/sessionRuntime/prompts/automated_checks_run.md

@@ -1,28 +0,0 @@
-Run automated checks for JSKIT session {{session_id}}.
-
-Worktree:
-
-{{worktree}}
-
-Command:
-
-{{check_command}}
-
-Run the command in the session worktree. If it fails, diagnose the root cause, fix the worktree, and rerun the command. Keep repeating until the command passes or until a real blocker prevents progress.
-
-Rules:
-
-- Fix the underlying cause. Do not remove checks, weaken verification, or hide failures to make the command pass.
-- Prefer JSKIT-owned helpers, generators, package seams, agent docs, package descriptors, and documented commands over local hacks.
-- If a failure involves JSKIT architecture, generator ownership, CRUD, surfaces, placements, client/server contracts, or UI verification, read the relevant docs under `node_modules/@jskit-ai/agent-docs/` or `packages/agent-docs/` before repairing it.
-- Use `npx --no-install jskit ...` for JSKIT CLI commands you run directly from the shell.
-- Keep fixes scoped to the current issue and worktree.
-- Do not create commits, branches, issues, pull requests, merges, or worktree cleanup. JSKIT session owns those steps.
-
-When finished, report:
-
-- root cause
-- files changed
-- final check command and result
-- anything still unverified
-- any meaningful verification decision, tradeoff, missing coverage, or root-cause note future steps should know

package/src/server/sessionRuntime/prompts/blueprint_updated.md

@@ -1,29 +0,0 @@
-Update the durable JSKIT app blueprint for session {{session_id}}.
-
-GitHub issue: {{issue_url}}
-Issue number: {{issue_number}}
-Issue title: {{issue_title}}
-Issue body file: {{issue_file}}
-Current blueprint file (`.jskit/APP_BLUEPRINT.md`): {{app_blueprint_file}}
-Worktree: {{worktree}}
-
-Use the accepted issue work to update only durable app/product/architecture memory. Read the current blueprint when present, issue title/body, helper map, package/app metadata, and changed files.
-
-Changed files since the session base:
-
-{{changed_files}}
-
-Rules:
-
-- Do not use this as task tracking.
-- Do not recreate `.jskit/WORKBOARD.md`.
-- Do not over-expand tiny issues into broad product rewrites.
-- Preserve useful existing blueprint content.
-- If `.jskit/APP_BLUEPRINT.md` does not exist, create it.
-- Edit `.jskit/APP_BLUEPRINT.md` directly in the worktree.
-- Add durable facts, architecture decisions, surfaces, routes, data ownership, package choices, and verification-relevant app behavior that future sessions should know.
-- Keep the result concise enough to remain useful over many issues.
-- Do not edit files other than `.jskit/APP_BLUEPRINT.md`.
-- Do not commit, branch, push, create PRs, merge, or clean up worktrees.
-
-When finished, summarize the blueprint changes, or why no blueprint update was needed.

package/src/server/sessionRuntime/prompts/deep_ui_check_run.md

@@ -1,40 +0,0 @@
-Deep UI quality check for JSKIT session {{session_id}}.
-
-Phase: {{phase}}
-GitHub issue: {{issue_url}}
-Issue number: {{issue_number}}
-Issue title: {{issue_title}}
-Issue body file: {{issue_file}}
-Worktree: {{worktree}}
-
-Changed files since the session base:
-
-{{changed_files}}
-
-Run a focused UI quality pass for the current worktree. If this is not UI-impacting after inspection, say exactly why and do not edit files. If the issue touches UI, inspect the changed routes, views, components, placements, layouts, and styles.
-
-Before changing user-facing JSKIT UI, read the relevant JSKIT agent docs when available: `node_modules/@jskit-ai/agent-docs/patterns/ui-testing.md`, `node_modules/@jskit-ai/agent-docs/patterns/page-scaffolding.md`, `node_modules/@jskit-ai/agent-docs/patterns/placements.md`, and `node_modules/@jskit-ai/agent-docs/patterns/surfaces.md`. If working inside the JSKIT monorepo or a devlinked sibling, use the equivalent `packages/agent-docs/...` paths.
-
-Check:
-
-- Material Design quality.
-- Vuetify best practices.
-- visual hierarchy and density.
-- spacing and alignment.
-- responsive behavior on mobile, tablet, and desktop.
-- loading, empty, error, disabled, and success states where relevant.
-- accessibility basics.
-- route and navigation coherence.
-- consistency with the existing app style.
-
-When clear scoped UI issues exist, fix them in the worktree. Keep fixes limited to the issue.
-
-Use Playwright for a meaningful route check when possible. If login is required, use a development-only auth bootstrap path. When possible, record UI verification with:
-
-`npx --no-install jskit app verify-ui --command "<playwright command>" --feature "<label>" --auth-mode <mode>`
-
-Important: `npx --no-install jskit app verify-ui` does not start the app server. Before running it, make sure the app is reachable by Playwright. If a local server is needed, inspect `.jskit/config/testrun_command` when present and use the app's documented server command, or start the server explicitly and wait for it before invoking `verify-ui`. Do not first run a bare Playwright command against a stopped server.
-
-Do not create commits, branches, issues, pull requests, merges, or worktree cleanup. JSKIT session owns those steps.
-
-When finished, summarize UI findings, fixes, verification, why no UI work applied, and any meaningful UI verification gaps.

package/src/server/sessionRuntime/prompts/final_comment.md

@@ -1,10 +0,0 @@
-Codex thread id: {{codex_thread_id}}
-Issue session status: finished
-PR: {{pr_url}}
-PR outcome: {{pr_outcome}}
-Outcome reason: {{pr_outcome_reason}}
-Local transcript: {{transcript_log}}
-
-Summary:
-
-Session {{session_id}} finished with PR outcome `{{pr_outcome}}`.

package/src/server/sessionRuntime/prompts/final_report_created.md

@@ -1,44 +0,0 @@
-You are preparing the pull request draft for JSKIT session {{session_id}}.
-
-Write the pull request body to this exact file:
-
-{{pull_request_file}}
-
-Context:
-- Worktree: {{worktree}}
-- Issue: {{issue_url}}
-- Issue title: {{issue_title}}
-- Issue file: {{issue_file}}
-- Base branch: {{base_branch}}
-
-Files changed:
-{{files_changed}}
-
-Commits:
-{{commits}}
-
-Checks:
-{{checks}}
-
-UI checks:
-{{ui_checks}}
-
-Review passes:
-{{review_passes}}
-
-User check:
-{{user_check}}
-
-Blueprint:
-{{blueprint_status}}
-
-Command log:
-{{command_log}}
-
-Requirements:
-- Write only `pull_request.md` at the path above.
-- Do not create a GitHub pull request.
-- Do not run `gh`, `git push`, `git commit`, merge, or clean up the worktree.
-- Include any closing issue reference needed for GitHub to close the issue.
-- Keep the body useful to a reviewer: summary, key changes, verification, and any known gaps.
-- When done, briefly summarize that the file was written.

package/src/server/sessionRuntime/prompts/issue_created.md

@@ -1,26 +0,0 @@
-Create the canonical issue files from the scoped issue discussion in this Codex thread.
-
-Canonical issue body file to write: {{issue_file}}
-Canonical issue title file to write: {{issue_title_file}}
-
-Use the issue definition and scoping conversation that just happened in this terminal. If something is still materially unclear, ask the user before writing the files.
-
-Do not create a GitHub issue.
-Do not implement the change.
-Do not edit app code.
-Do not run generators, tests, installs, `gh`, `git add`, `git commit`, `git push`, or JSKIT workflow mutation commands.
-
-Write:
-
-- A short issue title to `{{issue_title_file}}`.
-- A concrete, implementation-ready issue body to `{{issue_file}}`.
-
-The issue body should include:
-
-- The requested change or bug clearly stated.
-- The accepted scope.
-- Important exclusions or non-goals.
-- Relevant implementation boundaries.
-- Acceptance criteria when useful.
-
-After writing the files, show the title and body in the terminal for user review.

package/src/server/sessionRuntime/prompts/issue_prompt_rendered.md

@@ -1 +0,0 @@
-You are helping the user define this issue before implementation. Treat the request above as the starting point and keep returning to it when deciding scope, exclusions, and acceptance criteria. Your job is to turn the request into a clear, scoped, implementation-ready issue through conversation. Be helpful to the user. Be a good software engineer who understands both the app being developed and the JSKIT framework being used, and provide practical advice that improves the issue before implementation starts. Do not create files. Do not write `issue.md`. Do not write `issue_title`. Do not create a GitHub issue. Do not implement the change. Do not edit app code. Do not run generators, tests, installs, `gh`, `git add`, `git commit`, `git push`, or JSKIT workflow mutation commands. You may inspect the app read-only when it helps scope the issue: use commands such as `pwd`, `ls`, `find`, `rg`, `cat`, `sed`, and `git status`; read package.json, `.jskit/lock.json`, config, routes, packages, source files, `.jskit/APP_BLUEPRINT.md`, and `.jskit/helper-map.md` when available; use non-mutating JSKIT inspection commands when available and relevant, such as `npx --no-install jskit list`, `npx --no-install jskit show <package> --details`, and `npx --no-install jskit list-placements`; if `jskit` is not on PATH, or `npx --no-install jskit ...` fails because a linked/devlinked JSKIT CLI cannot resolve a package such as `@jskit-ai/kernel`, treat that as a local development environment limitation and continue with filesystem inspection instead of trying to repair PATH, reinstall packages, publish packages, edit devlinks, or advance the JSKIT session; prefer JSKIT agent docs over reverse-engineering framework architecture from source files, starting with `node_modules/@jskit-ai/agent-docs/DISTR_AGENT.md`, `node_modules/@jskit-ai/agent-docs/guide/agent/index.md`, and `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` when present, or `packages/agent-docs/...` when working inside the JSKIT monorepo or a devlinked sibling. Only run shell commands when inspecting the app. Do not run `printf`, `echo`, `cat`, heredocs, or similar commands merely to display your own summary or communicate with the user. Engage with the user meaningfully: restate what you think the user wants; identify ambiguities, hidden constraints, and likely ownership boundaries; ask focused questions only when the answer would materially change scope or implementation; suggest a practical scope if the request is too broad; call out what should be excluded from this issue; and when the issue is clear enough, respond normally in the Codex conversation with the agreed scope, acceptance criteria, and any important implementation boundaries. Stop there. The user will continue to the next JSKIT step when they are satisfied with the scoped issue.

package/src/server/sessionRuntime/prompts/make_plan.md

@@ -1,57 +0,0 @@
-Create an implementation plan for JSKIT session {{session_id}}.
-
-GitHub issue: {{issue_url}}
-Issue number: {{issue_number}}
-Issue title: {{issue_title}}
-Issue body file: {{issue_file}}
-Issue title file: {{issue_title_file}}
-App blueprint file (`.jskit/APP_BLUEPRINT.md`): {{app_blueprint_file}}
-Worktree: {{worktree}}
-
-This planning step is read-only for app code. Do not edit app files, create commits, create branches, create issues, create pull requests, merge, or clean worktrees.
-
-Create the plan from the issue and local app. Use the issue files, package.json, .jskit metadata, config, packages, routes, generated references, package docs, any saved app blueprint, and `.jskit/helper-map.md` when available.
-
-Before deriving JSKIT architecture from source files, read the package-owned agent docs that apply to this work. Start with `node_modules/@jskit-ai/agent-docs/DISTR_AGENT.md`, `node_modules/@jskit-ai/agent-docs/guide/agent/index.md`, and `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` when present. If the worktree is the JSKIT monorepo or a devlinked sibling, use the equivalent `packages/agent-docs/...` paths. Then read the specific pattern docs needed for the lane, such as `patterns/crud-scaffolding.md`, `patterns/crud-repository-mapping.md`, `patterns/page-scaffolding.md`, `patterns/placements.md`, `patterns/surfaces.md`, `patterns/client-requests.md`, `patterns/live-actions.md`, `patterns/generated-ui-contract-tracking.md`, or `patterns/ui-testing.md`.
-
-If these docs are unavailable, continue with app inspection and say that the agent docs were unavailable. Do not compensate by inventing framework rules from isolated source files.
-
-Start by identifying the implementation lane:
-
-- package install
-- generator scaffolding
-- custom local code
-- a combination of those
-
-Planning rules:
-
-- Keep the plan scoped to the issue. Avoid "while I am here" work.
-- If details are insufficient, say exactly what is missing instead of inventing foundational details.
-- Prefer vertical slices that produce visible or end-to-end progress.
-- If the work is too broad to review confidently, split it into clear chunks.
-- Make generator decisions concrete. Name the exact `npx --no-install jskit` commands to run when a generator or package install applies.
-- Base JSKIT lane and generator decisions on the agent docs and package descriptors first, then verify against the local codebase.
-- For non-CRUD route page work, plan to check `npx --no-install jskit show ui-generator --details` and `npx --no-install jskit list-placements` before hand-writing pages or placement entries.
-- For CRUD work, plan server ownership first. Name the `npx --no-install jskit generate crud-server-generator scaffold ...` command before any CRUD UI plan.
-- For CRUD-owned tables, plan around the real database table shape. Do not plan a separate hand-written migration for a table that `crud-server-generator` will own.
-- Every persisted app-owned table should have generated/package CRUD ownership unless there is a narrow explicit exception.
-- Do not hand-build CRUD routes, CRUD endpoints, or CRUD page trees before the server CRUD package and shared resource file exist.
-- `feature-server-generator` is for non-CRUD workflows and orchestration, not ordinary persisted entity tables.
-- Keep runtime, UI, and data concerns separated.
-- Before planning new helpers, composables, service functions, maps, or package glue, check `.jskit/helper-map.md` when it exists and prefer existing entries.
-- Keep direct knex exceptional and minimal. Prefer internal json-rest-api seams outside generated CRUD packages and explicit weird-custom feature lanes.
-- For package-owned baseline workflows, plan to install and verify the baseline before inventing custom code around it.
-- For user-facing UI, include Material/Vuetify quality expectations and a Playwright verification path.
-- If login is required for UI verification, plan for a development-only auth bootstrap path instead of live external auth.
-- Do not create or update the old `.jskit/WORKBOARD.md` workflow. JSKIT session state, issue text, terminal transcript, and commits are the tracker.
-
-If setup values are needed, ask plainly using exact env var or option names. For example: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST, DB_PORT, AUTH_SUPABASE_URL, AUTH_SUPABASE_PUBLISHABLE_KEY, APP_PUBLIC_URL.
-
-If the issue is not clear enough to plan safely, ask the user concise follow-up questions first.
-
-When the plan is ready:
-
-- Present the final plan and any new decisions clearly in the terminal for the user to review.
-- Do not write a plan file.
-
-Keep the plan concrete and implementation-oriented. Include likely files or areas to touch, ordered steps, generator commands to consider, review expectations, and checks that should be run.

package/src/server/sessionRuntime/prompts/plan_executed.md

@@ -1,39 +0,0 @@
-Execute the approved implementation plan for JSKIT session {{session_id}}.
-
-GitHub issue: {{issue_url}}
-Issue number: {{issue_number}}
-Issue title: {{issue_title}}
-Issue body file: {{issue_file}}
-Worktree: {{worktree}}
-
-Implement the plan that was just reviewed in this Codex conversation. If the plan is not visible in the current terminal context, first make a concise plan from the issue, then execute it. Keep the change scoped to the issue.
-
-Implementation rules:
-
-- Inspect the current app before editing. App setup has already passed; if required JSKIT app files are missing, report setup failure rather than inventing recovery work.
-- Follow `{{issue_file}}`. If the request is ambiguous, ask for clarification before changing files.
-- Before implementing JSKIT app structure, generators, CRUD, surfaces, placements, app setup, package-owned workflows, or UI verification paths, read the relevant JSKIT agent docs. Start with `node_modules/@jskit-ai/agent-docs/DISTR_AGENT.md`, `node_modules/@jskit-ai/agent-docs/guide/agent/index.md`, and `node_modules/@jskit-ai/agent-docs/patterns/INDEX.md` when present. If working inside the JSKIT monorepo or a devlinked sibling, use `packages/agent-docs/...` as the source-tree equivalent.
-- Read specific pattern docs before touching their lane, such as CRUD scaffolding/repository mapping, page scaffolding, surfaces, placements, client requests, live actions, generated UI contract tracking, and UI testing. Prefer these docs and package descriptors over reverse-engineering framework rules from source files.
-- Read `.jskit/helper-map.md` when it exists before creating helpers, composables, service functions, maps, or package glue.
-- Prefer existing JSKIT helpers, app-local helpers, package runtime seams, generated scaffolds, and documented generators over new local helpers.
-- If the plan calls for a generator or package install, use the planned `npx --no-install jskit` command unless inspection proves it does not apply. If you skip a generator, explain the exact gap.
-- For non-CRUD route pages, use `npx --no-install jskit generate ui-generator page ...` when it fits instead of hand-writing both route files and placement entries.
-- For CRUD work, scaffold the server side first with `crud-server-generator` before CRUD UI or CRUD route work.
-- Do not hand-write a separate CRUD migration for a table owned by `crud-server-generator`.
-- Do not hand-build CRUD endpoints or page trees before the server CRUD package and shared resource file exist.
-- Keep direct knex exceptional and minimal. Prefer internal json-rest-api seams outside generated CRUD packages and explicit weird-custom feature lanes.
-- Keep runtime, UI, and data concerns separated.
-- Avoid accidental scope expansion.
-- Do not create `.jskit/WORKBOARD.md`; the session files are the workflow record.
-- If user-facing UI changes, bring the screen to Material Design and Vuetify quality before calling it done. Include coherent responsive layout, loading, empty, error, disabled, and success states where relevant.
-- If verification needs login, use the app's local development auth bootstrap path rather than a live external auth login.
-
-After making changes:
-
-- Review for repeated code, unnecessary helpers, fragmented functions, placeholder work, missing states, broken route wiring, ownership mistakes, and weak JSKIT reuse.
-- Run the smallest relevant checks you can run safely in the worktree.
-- For changed user-facing UI, run or clearly identify the Playwright verification path. When possible, record UI verification with `npx --no-install jskit app verify-ui --command "<playwright command>" --feature "<label>" --auth-mode <mode>`.
-- `npx --no-install jskit app verify-ui` does not start the app server. Before using it for Playwright, make sure the app is reachable. If a local server is needed, inspect `.jskit/config/testrun_command` when present and use the app's documented server command, or start the server explicitly and wait for it before invoking `verify-ui`. Do not first run a bare Playwright command against a stopped server.
-- Summarize changed files, checks run, and any important implementation decisions or verification gaps in the terminal.
-
-Do not create commits, branches, issues, pull requests, merges, or worktree cleanup yourself. JSKIT session will handle those steps.

package/src/server/sessionRuntime/prompts/pr_failure.md

@@ -1,28 +0,0 @@
-The JSKIT session PR operation failed.
-
-Session:
-
-{{session_id}}
-
-Worktree:
-
-{{worktree}}
-
-Failure output:
-
-{{doctor_output}}
-
-Diagnose the failure and fix only what is required in this worktree.
-
-Check for:
-
-- missing or wrong GitHub remote
-- missing GitHub auth
-- branch push failure
-- PR body/title issue
-- stale local git state
-- rejected merge or failing required checks
-
-Use repository-portable repairs only. Do not hard-code local paths or credentials. Do not create a parallel manual workflow around the JSKIT session.
-
-Do not push, open a PR, merge, or remove the worktree unless JSKIT Studio or the JSKIT session step explicitly instructs it. Report root cause, changed files, commands run, and remaining risk.

package/src/server/sessionRuntime/prompts/pr_merge_prepared.md

@@ -1,22 +0,0 @@
-Prepare the JSKIT session pull request for merge.
-
-Session: {{session_id}}
-Worktree: {{worktree}}
-Target root: {{target_root}}
-Branch: {{branch}}
-Base branch: {{base_branch}}
-Pull request: {{pr_url}}
-Issue: {{issue_url}}
-Pull request file: {{pull_request_file}}
-
-Your job is to do whatever is needed, within the session scope, to get the pull request into a state where the user can press the JSKIT Merge button.
-
-Required boundaries:
-
-- Inspect the pull request state, checks, and branch status.
-- Resolve merge conflicts or failing checks if the fix is clear and in scope.
-- Commit and push any preparation changes to the session branch.
-- Do not merge the pull request.
-- Do not remove the worktree, archive the session, update the local base branch, or write JSKIT session state. JSKIT owns deterministic cleanup after the user decides.
-
-When you are done, summarize what you checked, what changed, and whether you believe the PR is ready for the user to merge.

package/src/server/sessionRuntime/prompts/review_changes_accepted_resolve.md

@@ -1,12 +0,0 @@
-Resolve the important findings from the latest deslop review in this conversation.
-
-Fix only those findings. Keep scope tight. Do not create commits, branches, issues, pull requests, merges, or worktree cleanup.
-
-Use existing JSKIT helpers, generators, package seams, and app-local helpers where they fit. Do not introduce helper churn or unrelated refactors while resolving these findings.
-
-When finished:
-
-- Summarize the exact findings fixed.
-- List changed files.
-- List checks run, or say why checks were not run.
-- Wait for the next review prompt.

package/src/server/sessionRuntime/prompts/review_prompt_rendered.md

@@ -1,61 +0,0 @@
-Review changes for session {{session_id}}.
-
-Review pass: {{review_pass_number}}.
-
-Changed files in the current session worktree:
-
-{{changed_files}}
-
-Review the current worktree changes, but do not silently fix everything you find unless the user explicitly sends the resolve deslop prompt.
-
-Inspect the worktree and produce a short, prioritized list of important findings. The answer should be conversational and useful for the user to read; the user will decide what happens next.
-
-Use priorities this way:
-
-- `high`: correctness, broken flow, data loss, security, route/runtime breakage, or serious JSKIT ownership/generator mistake.
-- `medium`: maintainability, meaningful duplication, missing required state, weak JSKIT reuse, important verification gap, or visible UI quality issue inside the requested scope.
-- `low`: polish, optional cleanup, copy tuning, minor test expansion, or judgment-call improvements the user should decide on.
-
-If the user later sends the resolve deslop prompt, fix the important findings from this deslop review in the current worktree. After fixing them, summarize what changed and wait for the next review prompt.
-
-If there are no important findings, say so explicitly and do not make cosmetic churn.
-
-Use four passes:
-
-1. Deslop review
-   - repeated functions or duplicated local helpers
-   - helpers reimplemented locally when a kernel/runtime seam already exists
-   - helpers reimplemented locally when `.jskit/helper-map.md` already lists a usable app-local helper or JSKIT export
-   - 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, missing migrations, or stale generated metadata
-   - surface or entity ownership mistakes: public, user, workspace, workspace_user
-2. JSKIT review
-   - were relevant `@jskit-ai/agent-docs` guide or pattern docs consulted before inferring JSKIT architecture from source?
-   - existing helper/runtime seam available?
-   - was `.jskit/helper-map.md` checked before introducing helper-like code?
-   - should this have been a package install, generator step, or scaffold extension instead of hand code?
-   - if a generator existed, was the exact `npx --no-install jskit` command used or was the gap documented?
-   - for CRUD work, was `crud-server-generator scaffold` used before CRUD UI or CRUD route hand-coding?
-   - for CRUD-owned tables, did the change avoid a separate hand-written CRUD migration?
-   - does every live app-owned table have generated/package CRUD ownership or a narrow explicit exception?
-   - is direct app-owned knex usage limited to generated CRUD packages or explicit weird-custom feature lanes?
-   - are surface, route, ownership, package metadata, and migration choices aligned with JSKIT conventions?
-3. UI standards review
-   - user-facing screens follow Material Design and Vuetify best practices
-   - list screens have clear hierarchy, actions, density, empty states, and table/list patterns
-   - view and edit/new screens have clear 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 when the fix is scoped
-4. Verification review
-   - run the smallest relevant verification commands for the changed scope
-   - any changed user-facing UI should be exercised with Playwright when possible
-   - UI verification should normally be recorded through `npx --no-install jskit app verify-ui`
-   - `npx --no-install jskit app verify-ui` does not start the app server; if Playwright needs a local server, inspect `.jskit/config/testrun_command` when present and start or wrap the documented server command before invoking `verify-ui`
-   - if login is required, use the chosen local test-auth path instead of live external auth
-   - if there is no usable local auth bootstrap path, record it as a blocking testability gap
-
-Do not create commits, branches, pull requests, merges, or worktree cleanup yourself. JSKIT session owns those steps.
-
-When finished, report the findings considered, fixes made during this pass if any, changed files, checks run, and anything still unverified. If there are no important findings, say so explicitly and list residual risk.

package/src/server/sessionRuntime/prompts/user_check_completed.md

@@ -1,17 +0,0 @@
-Complete user check for session {{session_id}}.
-
-Issue: {{issue_url}}
-Issue title: {{issue_title}}
-Issue body file: {{issue_file}}
-
-The code should already be built or runnable according to the implementation instructions.
-
-Ask the user to test the changed behavior in the app and report whether it works as intended. Be specific about the user-visible behavior, route, command, or workflow to inspect.
-
-If the user finds a problem, diagnose the root cause and fix it in this worktree. Keep the fix scoped. Reuse JSKIT helpers, generated seams, and package workflows where they apply.
-
-If the behavior works, tell the user to run:
-
-npx --no-install jskit session {{session_id}} step --user-check passed
-
-Do not commit, push, create a PR, merge, or clean up the worktree yourself. JSKIT session owns those steps.