kiokuko-dsh 0.2.12 → 0.2.13

package/dist/locale/en.json

@@ -1,6 +1,6 @@
 {
   "meta": {
     "title": "kiokuko-dsh",
-    "description": "Version 0.2.12 — Kiokuko plugin for DeepSeek Harness"
+    "description": "Version 0.2.13 — Kiokuko plugin for DeepSeek Harness"
   }
 }

package/dist/locale/ja.json

@@ -1,6 +1,6 @@
 {
   "meta": {
     "title": "kiokuko-dsh",
-    "description": "バージョン 0.2.12 — DeepSeek Harness 向け Kiokuko プラグイン"
+    "description": "バージョン 0.2.13 — DeepSeek Harness 向け Kiokuko プラグイン"
   }
 }

package/dist/locale/ko.json

@@ -1,6 +1,6 @@
 {
   "meta": {
     "title": "kiokuko-dsh",
-    "description": "버전 0.2.12 — DeepSeek Harness용 Kiokuko 플러그인"
+    "description": "버전 0.2.13 — DeepSeek Harness용 Kiokuko 플러그인"
   }
 }

package/dist/locale/zh-CN.json

@@ -1,6 +1,6 @@
 {
   "meta": {
     "title": "kiokuko-dsh",
-    "description": "版本 0.2.12 — DeepSeek Harness 的 Kiokuko 插件"
+    "description": "版本 0.2.13 — DeepSeek Harness 的 Kiokuko 插件"
   }
 }

package/docs/coding-workflow.md

@@ -2,19 +2,25 @@
 
 An explicit request to implement or repair code starts a task-bound workflow. Questions, explanations, quotations, undecided alternatives and plan-only requests retain the conversation/read-only path. Classification is advisory and cannot authorize an unrequested change.
 
-Before the first implementation effect the agent defines an ideal Goal, implementation items and dependencies, observable item criteria, and a separate final check through the user's ordinary entry point. The host presents these together and asks **このタスクで Lisp モードを使いますか？**
+Clear unowned native implementation requests offer Lisp before the first model request. A manually enabled session selects its explicit Lisp route without another question; a declined early answer is reused for the exact request at Goal preparation. This offer does not create a memory task or grant native permission.
+
+Before the first implementation effect in an admitted workflow the agent defines an ideal Goal, implementation items and dependencies, observable item criteria, and a separate final check through the user's ordinary entry point. The host presents these together and asks **このタスクで Lisp モードを使いますか？**
 
 - **使う** permits Lisp for this task. SBCL and the enabled Lisp module must be available. Startup failures remain visible blockers.
 - **使わない** uses ordinary tools and the same completion conditions. SBCL is unnecessary.
 - **取消・作業を保持** cancels dispatch while preserving definitions and existing results.
 
-Closing, an empty answer, a disconnected client or missing question service leaves the choice pending. Conversation, reads and status remain available. `coding_workflow next` reopens the same pending question. A new task or material scope change gets a new question. Existing Lisp runtime/approval settings never answer it. Manual `/kioku-lisp enable`, `enable-task` or `disable` changes an already defined current task explicitly, invalidating its old evidence; it cannot bypass an undefined Goal.
+Closing, an empty answer, a disconnected client or missing question service leaves the choice pending; reads and conversation remain available. Use the same choice or an explicit enable/disable command to recover. Conversation, reads and status remain available. `coding_workflow next` reopens the same pending question. A new task or material scope change gets a new question unless the user explicitly selected manual session ON. The lisp.enabled configuration and approval settings alone never answer it. Manual `/kioku-lisp enable`, `enable-task` or `disable` changes an already defined current task explicitly, invalidating its old evidence; it cannot bypass an undefined Goal.
 
 After the choice, the agent follows dependency-ready items without another approval at every step. Existing Plan, native goal/ownership and destructive-effect approval rules still apply. Normal/Enno selection remains separate from Lisp selection. Enno projects its authoritative ideal, WorkUnits and focused/final verifiers into the common view; it cannot submit a competing Goal.
 
+## Lisp coding prototype
+
+For a clear unowned native coding request with Lisp ON, run a small relevant `lisp_eval` with `prototype: true`, then read its successful saved `operationId` with `lisp_inspect` (`resultOperationId`, `section: "result"`, complete page from offset zero). Implementation dispatch waits for both actual execution and inspection. The status distinguishes pending, required, result pending, reviewed, declined and failed; ON alone never marks the prototype verified. Two failed attempts stop automatic retries; recover the cause or explicitly disable Lisp. A fresh request cannot replay an old prototype operation. Reads, conversation/research, Stop and native permission checks remain independent. This is a bounded tool workflow, not an OS sandbox or proof that arbitrary Lisp is pure, the experiment is semantically relevant, or the whole task is complete.
+
 ## Model-facing API
 
-`coding_workflow` exposes `status` and `next`; status includes the current revision, a complete `minimumValidInput` example and the next safe action. `coding_workflow_apply` accepts `propose` or `revise`, with required `expectedRevision` and `definition`. `coding_workflow_blocker` requires `expectedRevision` and `blocker`. The legacy propose/revise/report_blocker actions remain accepted on `coding_workflow`. The published schemas and execution use the same required fields. Put constraints in `definition.goal.constraints`; goal, item and criterion IDs must be unique across the entire definition. Final Goal criteria must be separate from item criteria. A stale revision or invalid field returns its correction. These operations cannot write Lisp answers or satisfied verdicts.
+`coding_workflow` exposes `status` and `next`; status includes the current revision, a complete `minimumValidInput` example and the next safe action. `coding_workflow_apply` accepts `propose` or `revise`, with required `expectedRevision` and `definition`. `coding_workflow_blocker` requires `expectedRevision` and `blocker`. The legacy propose/revise/report_blocker actions remain accepted on `coding_workflow`. The published schemas and execution use the same required fields. Every `definition.goal.criterionIds` entry must be covered by at least one responsible `definition.items[].goalCriterionIds`. Validation names each uncovered ID and its field; choose the implementing item yourself and retry without removing the final check. Unknown references and duplicate declaration IDs are separate errors. Put constraints in `definition.goal.constraints`; goal, item and criterion IDs must be unique across the entire definition. Final Goal criteria must be separate from item criteria. A stale revision or invalid field returns its correction. These operations cannot write Lisp answers or satisfied verdicts.
 
 Preparation, continuation and execution consume the same source-bound `requestIntent`. Jev/Laya receives the current request, the active Goal and bounded same-session proposals; its finite decisions include the selected proposal references. On abstention or failure the main model resolves that context through `prepare_requested_work`. Same-scope continuation preserves the Goal and Lisp choice. Scope changes block dispatch until a revised Goal is accepted. Verification permits native process checks without being reclassified as implementation; it does not authorize direct file changes or override native permissions.
 

package/docs/lisp-prototype-planning.md

@@ -7,8 +7,7 @@ small authorized target-runtime probes, choose controls/counterexamples before
 execution, retain observations and failures, and use that evidence in one plan.
 Existing permissions, read-only inputs, scratch, host approvals, generation and
 result ownership, recovery and verification contracts remain authoritative.
-Non-coding tasks do not acquire a coding-experiment requirement. There is no new
-host execution gate, schema, tool or fixed experiment-count limit.
+Non-coding tasks do not acquire a coding-experiment requirement. Native coding preparation now enforces actual prototype execution and complete saved-result inspection before implementation, with a two-failure retry budget. Planning relevance remains model guidance; a successful probe does not prove task completion. The evaluation records below describe their original source snapshots.
 
 The full representation remains the default. Runtime compilation preserves the
 new block and the previous contract. The unchanged fixed size baseline still

package/docs/lisp.md

@@ -89,7 +89,7 @@ starts a worker. Variables, definitions and references are lost on restart; the
 agent receives the new generation and must rebuild helpers without replaying
 completed effects. Crashes and explicit cancellation still require human recovery.
 
-Enter a normal implementation or debugging request in DSH, including dsh-cli.
+Enter a normal implementation or debugging request in DSH, including dsh-cli. Clear unowned native implementation requests now offer Lisp before model generation, including native Bash. A manually enabled session uses the selected route and requires a fresh `lisp_eval` prototype (`prototype: true`) followed by complete saved-result inspection through `lisp_inspect` before implementation. ON alone does not mark prototype verification successful. This routine is bounded to two failed attempts; repair the cause or explicitly disable Lisp. Native permissions, Stop and read-only conversation/research remain independent.
 With `typedDecisions.mode: auto`, an accepted Jev/Laya `build` or `debug`
 classification reaches the existing Lisp question without repeating the task-category
 question. Laya receives complete requests up to 4096 UTF-8 bytes, including quoted
@@ -498,4 +498,4 @@ Clean installation and platform status: [code intelligence setup](code-intellige
 
 ## Coding task choice and recovery
 
-For a new coding task, `coding_workflow` first defines and displays the Goal, implementation items and observable conditions. The host then asks whether to use Lisp. Existing enabled settings never imply yes. Closing the question leaves it pending and `coding_workflow next` reopens the same question. Explicit continuation after a host restart restores the task choice; a new task or material scope change asks again. A saved yes followed by startup failure remains a visible blocker; recover the runtime or explicitly change the task route with `/kioku-lisp disable`. No uses ordinary tools and still requires fresh item checks followed by a final user-entry Goal check. Lisp evaluation success alone is insufficient: bind `task_completion` and collect actual host process evidence. See [coding workflow](coding-workflow.md).
+For a new coding task, `coding_workflow` first defines and displays the Goal, implementation items and observable conditions. The host then asks whether to use Lisp. Configuration alone never implies yes; an explicit manual session ON is reused as the selected route. Closing the question leaves it pending and `coding_workflow next` reopens the same question. Explicit continuation after a host restart restores the task choice; a new task or material scope change asks again. A saved yes followed by startup failure remains a visible blocker; recover the runtime or explicitly change the task route with `/kioku-lisp disable`. No uses ordinary tools and still requires fresh item checks followed by a final user-entry Goal check. Lisp evaluation success alone is insufficient: bind `task_completion` and collect actual host process evidence. See [coding workflow](coding-workflow.md).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kiokuko-dsh",
-  "version": "0.2.12",
+  "version": "0.2.13",
   "description": "Kiokuko plugin for DeepSeek Harness",
   "type": "module",
   "license": "MIT",

package/skills/coding-ideal-routine-skill/SKILL.md

@@ -20,7 +20,11 @@ description: バグ修正・機能追加・挙動に関わる設定や配布物
 
 DSH の実装タスクでは、初回の変更前に `coding_workflow status` を読み、`propose` で Goal・依存関係付きの全項目・各項目の観測可能な条件・別の最終 Goal 条件を原子的に登録する。先に必要な読取調査を行ってよい。元依頼の権限と対象を広げない。Enno では既存 ideal・plan を提出し、その共通表示を使う。別の Goal を提案しない。
 
-ホストが Goal・項目・条件を示し、そのタスクで Lisp を使うか人間に確認する。未回答・閉じる・切断は pending。モデルは回答を代行せず、選択前に変更・プロセス・Lisp を起動しない。`next` は再表示と依存達成済みの項目の確認に使う。no では通常ツールで同じ条件を進め、Lisp を勧め直さない。yes の起動失敗はブロッカーとして扱う。
+通常 native 実装依頼ではモデル要求前に Lisp を提案し、ON 済みならその経路を使う。Goal 準備は同じ依頼の人間の回答を再利用する。全ての goal.criterionIds を、実装を担当する少なくとも1つの items[].goalCriterionIds に対応付ける。未対応 ID の診断では該当 item を自分で選んで修正し、最終条件を消したり対応を捏造しない。
+
+Lisp ON の native coding preparation は小さい関連試作を lisp_eval（prototype:true）で実行し、成功した保存 operationId を lisp_inspect（resultOperationId、section:"result"）で読み取ってから実装する。ON 表示や自己申告は試作の証拠ではない。2回失敗したら自動再試行を止め、原因修復または明示的な OFF を選ぶ。
+
+Goal・項目・条件を定義し、早期回答がない場合はホストが Lisp を使うか人間に確認する。未回答・閉じる・切断は pending。モデルは回答を代行せず、選択前に変更・プロセス・Lisp を起動しない。`next` は再表示と依存達成済みの項目の確認に使う。no では通常ツールで同じ条件を進め、Lisp を勧め直さない。yes の起動失敗はブロッカーとして扱う。
 
 選択後は各項目を自律的に進める。実行前に `task_completion bind` でチェックを対応付け、owned tools または Lisp の実子プロセスから host receipt を得る。全項目が達成済みになった後、最新成果物で通常の利用入口を確かめる最終 Goal チェックを実行する。状態と未達理由は `coding_workflow status` で確認し、自己申告で完了にしない。
 

package/skills/kiokuko-lisp/SKILL.md

@@ -18,7 +18,7 @@ Persistent mode: coding choice or /kioku-lisp enable. Task mode uses /kioku-lisp
 
 Use kioku_read, kioku_write, kioku_edit, kioku_remove, kioku_exec and kioku_result for observed development. PATH commands, bash/zsh, builds/tests, coding-needed external investigation and project edits need no routine confirmation. Source/data deletion and existing durable user database mutation need a concrete review; generated/temp/disposable artifacts are ordinary development. Memory organization waits until task completion and user permission; saving requires approval of the exact shown content. Declare destructiveTargets when executing commands with destructive intent. The host does not attempt to classify every side effect of arbitrary code.
 
-Ordinary foreground kioku.process:run uses native Bash sandbox/approval/Stop; no memory task, Goal or coding choice. Admitted workflows, owned tools, async jobs and protected mode retain task/protocol authority. Prefer kioku.tools:call-tool or broker receipts; direct Lisp/FFI effects or generated passed fields prove no verification. Bind task_completion conditions/source paths before checks (subdirectories too); collect async receipts with kioku_result. Cancellation/ownership remain authoritative. In admitted work, Plan permits read/search/status until human implementation instructions or approval exit at the next accepted boundary. Conversation keeps native policy.
+Foreground kioku.process:run uses native Bash sandbox/approval/Stop without a memory task/Goal. Selected coding requires prototype/result inspection. Admitted workflows, owned tools, async jobs and protected mode keep task/protocol authority. Use kioku.tools:call-tool/broker receipts; direct Lisp/FFI or generated passed fields prove no verification. Bind task_completion conditions/source paths (subdirs too) before checks; collect async receipts with kioku_result. Cancellation/ownership remain authoritative. Admitted Plan allows read/search/status until human implementation/approval exits at the next boundary. Conversation: native policy.
 
 Schemas define arguments; never guess. `lisp_describe` without a symbol gives the
 API/verifier map, even during recovery. Persistent `lisp_eval`: declared inputs;
@@ -138,6 +138,10 @@ ask_user_question/exit_plan_mode preserve ownership, cancellation and the select
 <!-- /kiokuko:runtime -->
 
 <!-- kiokuko:documentation examples -->
+## Native coding preparation
+
+Clear native implementation requests offer Lisp before model generation. A task choice is reused at Goal preparation; explicit manual session ON persists across reload. Run one small relevant `lisp_eval` with `prototype: true`, then read its successful saved `operationId` using `lisp_inspect` (`resultOperationId`, `section: "result"`, complete page from zero) before implementation. ON is not evidence or completion. Two failed attempts stop automatic retries: repair the cause or explicitly disable Lisp. New requests and formal Goal scopes need fresh proof. These steps are also supplied by the live coding-preparation status and tool schemas; conversation and research are unaffected.
+
 ## Project-shared functions
 
 Project-shared functions work in both Lisp modes without a mode switch after the

package/skills/one-shot-software-completion/SKILL.md

@@ -38,7 +38,7 @@ failures or lost context. Token budgets use host usage, not bytes or capacity.
 
 ## Completion contract
 
-Coding: coding_workflow binds Goal/items/checks before the task Lisp choice. Verify items, then the user entry with fresh host evidence. Pending checks prevent completion; resume exact task/operation IDs.
+Coding: early native Lisp choice is reused when coding_workflow binds Goal/items/checks; cover every goal.criterionIds ID in a responsible items[].goalCriterionIds. Lisp ON coding preparation runs lisp_eval prototype:true and inspects its actual successful saved result before implementation; ON is not evidence. Verify items, then the user entry with fresh host evidence. Pending checks prevent completion; resume exact task/operation IDs.
 
 Bind behavior, required method, preserved contracts and evidence before editing.
 No unapproved proxy: raster for required geometry, hardcoded output, mocks or