kotonoha 0.5.2 → 0.5.4

package/skills/obsidian-vault/references/workflow.md

@@ -1,23 +1,36 @@
-# Obsidian操作ガイド
+# Obsidianローカル保存バックエンド
 
-対象のVault、読み取り範囲、作成・編集内容への許可を確認して実行する。
-Obsidianアプリ、公式CLI、MCP、コミュニティプラグインは不要である。
-通常の作成・編集はホストのファイルツールで直接行い、専用CLIの計画保存も選択できる。
-Skillへの自然言語の依頼例は次のとおり。
+呼出元が指定した範囲の読み取り・静的検証・候補の保存だけを担当する。
+本文の作成・編集の指揮はobsidian-markdown、日本語の校正はjapanese-proseへ分離する。
+対象は0.5.4であり、Canvas用の共用保存API版1は維持する。
 
-```text
-/absolute/path/to/vault の Notes と Targets を読み取り対象にして、
-内部リンクを診断して。未作成リンクは修復しないで。
-```
+## 上位ワークフローの移管
 
-```text
-このVaultのNotes/draft.mdを誤りだけ添削して。
-差分を確認するまで保存しないで。
-```
+| 依頼 | 主担当 |
+|---|---|
+| Markdownノートの作成・内容編集・記法の説明 | obsidian-markdown。文書構成はtech-writerを使用 |
+| 日本語の校正と意味保存レビュー | obsidian-markdownからjapanese-proseへ依頼 |
+| アプリ上の検索・リンク確認・タスクやプロパティの操作 | 明示的に選択したobsidian-cli |
+| Web・HTML抽出、JSON・CSVからの候補生成 | defuddle、knap。ノートへの組み込みはobsidian-markdown |
+| 許可範囲のローカル読み取り・検証・確定済み候補の保存 | obsidian-vault |
+
+規約の推定、関連ノートの推薦、独立したリンク分析・修復は、このSkillでは行わない。
+旧来の高水準の依頼を受けた場合は担当を案内し、ここで候補本文を作ったり探索を始めたりしない。
+アプリの起動や探索範囲の拡大には別途許可が必要であり、移管だけでは許可を得たことにならない。
+静的検証の観測値・リンク判定を、規約や推薦結果として報告しない。
 
-## 直接作成・編集
+## 保存候補の受け渡し
 
-直接編集にはPythonやuv、専用CLIの依頼・計画ファイルを必須にしない。
+呼出元から、Vaultの絶対パス、読み取り・モデル入力の許可範囲、正確な保存先を受け取る。
+作成か置換か、編集元のバイト列とハッシュ、候補の全文、許可された変更、保存方式と保存への許可も受け取る。
+作業ディレクトリ、補助コピーへの同意、校正結果のレビューも引き継ぐ。
+不足する保存情報は1問ずつ確認し、候補が未作成なら呼出元へ戻す。
+候補を検査に通すために、バックエンドが本文を補完・修正することはない。
+
+## ホストツールによる候補の直接保存
+
+Obsidianアプリ、公式CLI、MCP、コミュニティプラグインは不要である。
+直接保存にはPythonやuv、専用CLIの依頼・計画ファイルを必須にしない。
 作業ディレクトリはユーザー指定を優先し、未指定なら依頼開始時のカレントディレクトリを使う。
 相対指定の作業ディレクトリは開始時のカレントから、相対保存先は選択した作業ディレクトリから解決する。
 Vaultルート基準と明示されたパスや絶対パスは、その指定を維持する。
@@ -29,19 +42,6 @@ Vaultルート基準と明示されたパスや絶対パスは、その指定を
 書き込み前に実体の保存場所を確認し、作業ディレクトリや出力先がセッション領域なら、別の場所を1問ずつ確認する。
 明示指定された場合も、このSkillではセッション領域へ書かず、代替場所への許可を得る。
 対象の親が存在しなければ止め、セッション領域への代替保存や新規フォルダー作成を行わない。
-次のようにVaultと対象、変更内容、保存の可否を指定する。
-
-```text
-/absolute/path/to/vault の Notes 内を読み取り対象にして、
-Notes/meeting.md を新規作成して保存して。既存ファイルは上書きしないで。
-本文は「# 打合せ記録」と「## 決定事項」「## 次の行動」にして。
-```
-
-```text
-/absolute/path/to/vault の Notes/meeting.md を直接編集して保存して。
-frontmatterのtagsにmeetingを追加し、本文や他のプロパティは変更しないで。
-```
-
 対象や変更内容が曖昧なら1問ずつ確認する。「案を作って」だけでは保存しない。
 利用者が対象・変更内容・保存を明示した依頼は、その範囲の書き込み許可として扱える。
 毎回のCLI計画承認は要求しない。保存前の差分確認を求められたら、確認まで書かない。
@@ -51,9 +51,11 @@ Vault内の`.md`だけを扱い、対象と親の実体、許可範囲、通常
 大文字小文字違いも含めて`.obsidian`と`.git`を除外し、別表記の同名対象を上書きしない。
 確認に必要な機能がないホストでは保存しない。
 
-既存ノートを読み、指定箇所だけの候補を作る。保存直前に原文と実体を再確認し、外部変更があれば止める。
-新規作成は既存対象を置換しない方法を使い、編集では所有者・グループ・権限を維持する。
-拡張属性や複数ハードリンクなどを保全できなければ拒否し、属性を削除して回避しない。
+既存ノートを読み、渡された候補との差分を確認する。保存直前に原文と実体を再確認し、外部変更があれば止める。
+新規作成は既存対象を置換しない方法を使う。
+Linuxの通常FSでは所有者・グループ・権限を維持し、拡張属性などを保全できなければ拒否する。
+WSLのWindowsドライブには次節の直接保存手順を使い、仮想的なLinux権限だけで拒否しない。
+どちらも複数ハードリンクを拒否し、属性を削除して回避しない。
 新規フォルダー、削除・移動・改名、添付や`.canvas`・`.base`の編集は対象外とする。
 指定外のプロパティ、リンク、コード、数値、識別子、文字コード、改行を保持する。
 同一内容なら書かず、保存後は読み戻して対象パスと実際の変更内容を報告する。
@@ -63,7 +65,7 @@ Vault内の`.md`だけを扱い、対象と親の実体、許可範囲、通常
 CLI計画や添削に必要なVault外の場所を使えなければ、別の場所の指定とコピーへの同意を得るまで停止する。
 補助ファイルを作る許可は、対象ノートの保存許可ではない。
 委譲先のSkillやツールにも保存場所とセッション領域への保存禁止を引き継ぐ。診断にファイルが不要なら標準出力を使う。
-日本語添削では直接編集でもjapanese-proseの保護検査とハッシュ付き意味レビューを省略しない。
+校正の実施は呼出元へ戻し、直接編集でもjapanese-proseの保護検査とハッシュ付き意味レビューを省略しない。
 通常の内容変更をproofreadと偽らず、CLIに存在しないeditコマンドも生成しない。
 
 直接編集はCLIのルートロック、原子的確定、成功記録による再実行保護を利用しない。
@@ -71,17 +73,44 @@ CLI計画や添削に必要なVault外の場所を使えなければ、別の場
 CLIの保存結果JSONや検証済み記録があるように報告しない。
 CLI操作が失敗した場合も、この経路へ無断で切り替えない。
 
-## CLI計画保存モードの導入と起動
-
-既存の同名Skillを無断で置換しない。必要な兄弟Skillは別途導入する。
+## WSLからWindowsドライブへ直接保存
+
+この手順は、ホストツールによる通常のMarkdownノート保存だけに適用する。
+この直接保存手順は0.5.4から対応する。
+WSLのローカルWindowsドライブなら、FS名がdrvfs・9p・v9fsであることだけを理由に拒否しない。
+Python CLI・Canvas・Basesの保存対応は拡張せず、CLIの許可FS一覧を直接保存の条件に流用しない。
+Pythonやuvを必須にする変更でもない。
+
+1. WSL環境、実際のマウント、Windowsパスとの対応を確認する。`/mnt/c/...`という表記だけでは判断しない。
+   Windows側の実体がローカルドライブであることも確認し、ネットワークドライブやUNC・SMB共有は対象外にする。
+2. 許可済みのVaultと保存先、原文ハッシュ、ファイル実体、リンク数を確認する。
+   パス途中のWindowsジャンクション等の再解析ポイントも拒否し、読み取り専用属性やACLによる拒否を尊重する。
+   通常の`.md`データストリームだけを対象にし、`:stream`やデバイスパスへ書き込まない。
+3. 既存ノートは同じファイル実体へ書き込む。切り詰めずに開き、同じハンドルで原文と実体を保存直前に照合する。
+   候補を書いた後、候補と同じ長さに切り詰める。一時ファイルへの置換、改名、削除しての再作成は使わない。
+   ホスト編集ツールの保存方式が不明なら、そのツールでは保存しない。
+4. 同じ実体を維持し、WindowsのACL・属性・代替データストリーム・既存のWSLメタデータを保持する。
+   Linuxのuid・gid・modeが仮想表示であることや、POSIX拡張属性一覧を取得できないことだけでは拒否しない。
+   新規ノートは排他的に作成し、既存名を上書きせず、通常のWindows親ディレクトリのACL継承に従う。
+5. 書き込みをフラッシュして閉じ、読み戻したバイト列・実体・観測できる属性を確認する。
+   通常の書き込みに伴う時刻やアーカイブ属性の更新は許容するが、他の属性の変更は許容しない。
+   途中失敗やObsidian・Sync・Windows側の同時編集を完全には防げないことを、保存前に説明する。
+   書いた可能性がある失敗は結果不明とし、自動再保存やロールバックは行わない。
+
+chmod・chown、属性の削除、マウントやWindows設定の変更で保存を通さない。
+必要なパス検証や同一実体への書き込みを確認できなければ、その不足を具体的に報告する。
+保存を拒否した場合も、`/tmp`等の別ファイルへ勝手に出力しない。
+別出力には正確な保存先への明示許可が必要であり、作成できてもVault更新済みとは扱わない。
+校正の保護検査・意味レビューと、セッション領域への保存禁止は維持する。
+権限の違いは[MicrosoftのWSLファイル権限資料](https://learn.microsoft.com/en-us/windows/wsl/file-permissions)を参照する。
 
-```bash
-npx kotonoha install --skill obsidian-vault
-npx kotonoha install --skill tech-writer
-npx kotonoha install --skill japanese-prose
-```
+## CLI計画保存モードの導入と起動
 
-上記はCopilot向けの導入例である。Claude Codeでは各コマンドに`--agent claude`、両方には`--agent all`を付け、必要な兄弟Skillも同じルートへ導入する。既定のルートはCopilotが`.github/skills`、Claude Codeが`.claude/skills`である。以下の起動例では、選択したルートにパスを合わせる。
+既存の同名Skillを無断で置換しない。必要な呼出元と兄弟Skillは別途導入する。
+導入方法は[README](https://github.com/nahisaho/kotonoha/blob/main/README-ja.md)を参照する。
+既定のルートはCopilotが`.github/skills`、Claude Codeが`.claude/skills`である。
+以下の起動例では、選択したルートにパスを合わせる。
+校正候補の検査にはjapanese-proseが必要だが、通常の直接保存に校正用依存を要求しない。
 
 既存のjapanese-proseが古い場合は共通ゲートを利用できず、依存不足となる。
 既存Skillのローカル変更を確認・退避し、利用者が更新を許可してから、対象Skillだけを`--force`付きで再導入する。
@@ -103,7 +132,7 @@ uv run --offline --locked --python 3.12 .github/skills/obsidian-vault/scripts/va
 
 以下はCLI計画保存モード専用で、正本は[execution-contract.json](execution-contract.json)である。
 直接編集にはこの依頼ファイルを使わない。CLIのintentにeditは追加されていない。
-以下は、指定範囲のリンクを調べる依頼の例である。絶対パスは実際の場所に置き換える。
+以下は、呼出元が指定した範囲の入力を静的検証する依頼の例である。絶対パスは実際の場所に置き換える。
 model_contextは、この範囲の情報をホストモデルへ渡す同意を得た場合だけtrueにする。
 
 ```json
@@ -114,7 +143,7 @@ model_contextは、この範囲の情報をホストモデルへ渡す同意を
     {"kind": "directory", "path": "Notes"},
     {"kind": "directory", "path": "Targets"}
   ],
-  "purpose": "許可された範囲のリンク診断",
+  "purpose": "呼出元が指定した範囲の入力検証",
   "intent": "links",
   "write_target": null,
   "base_sha256": null,
@@ -131,9 +160,12 @@ model_contextは、この範囲の情報をホストモデルへ渡す同意を
 ファイル単位ではkindをfileとする。`.obsidian`と`.git`は通常探索から除外し、内容を取得しない。
 上限のnullは、指定範囲にその上限を設けない指定である。上限を使う場合は事前に合意し、打ち切り結果を確認する。
 
-intentはconventions、related、links、create、proofreadから選ぶ。
-規約を宣言した資料は、許可範囲内のパスとしてdeclared_rulesに指定する。
-観測は名前・フォルダー・プロパティ名と型・タグの事実であり、一般的な規約の推測とは区別する。
+v1のintent値conventions、related、links、create、proofreadは、既存依頼との互換性のために維持する。
+これらはバックエンドのプロトコル値であり、削除した上位ワークフローの受付名ではない。
+上のlinksは読み取り専用の検証例であり、独立したリンク分析を開始する指示ではない。
+declared_rulesも互換フィールドとして維持し、許可範囲内の指定資料を記録するだけにする。
+観測は名前・フォルダー・プロパティ名と型・タグの事実であり、一般的な規約を推定しない。
+共用API、依頼スキーマ、検証・保存の実装は変更しない。
 
 ## 原文、計画、適用
 
@@ -145,7 +177,7 @@ plan --request request.json --candidate /absolute/workspace/candidate.md --revie
 apply --request request.json --plan /absolute/workspace/OPERATION_ID/plan.json --approve-plan-sha256 PRESENTED_HASH
 ```
 
-添削ではintentをproofread、write_targetを対象パスにする。
+呼出元で校正済みの候補を計画保存する場合は、互換値proofreadと対象のwrite_targetを使う。
 最初のreadではbase_sha256をnullにできる。候補作成前に取得した原文のSHA-256を設定してからplanを呼ぶ。
 原文を再取得せずにハッシュだけを新しいものに付け替えない。原文が変わったら候補とレビューも作り直す。
 workspaceにはVault外の既存の絶対パスを指定し、コピーへの同意を得てworkspace_copiesをtrueにする。
@@ -156,7 +188,7 @@ planは入力の候補をそのまま検査し、検査のために保護対象
 before.md、candidate.md、diff.patch、semantic-review.json、plan.jsonは0600で保持する。
 原文と候補が同じ場合はno_changesとなり、計画も保存も行わない。
 
-新規作成はintentをcreateにし、base_sha256をnullにする。
+呼出元が作成済みの候補を新規保存する場合は、intentをcreateにし、base_sha256をnullにする。
 完成ノートではdeliverableをnote、再利用用テンプレートではtemplateとする。
 両方とも本文・保存先・計画の承認が必要である。完成ノートに変数が残っていれば保存を拒否する。
 親フォルダーを先に用意し、対象を`.md`のパスにする。既存ファイルは上書きしない。
@@ -194,8 +226,8 @@ Obsidian自体と同じ解決結果になるとは限らない。
 ## 保存の限界と復旧
 
 保存対象は通常ファイルに限り、シンボリックリンクを追跡しない。
-LinuxのローカルFSでも確認できた方式だけを使う。未知のFSやネットワークFSは保存しない。
-所有者・グループ・権限を維持できない対象、複数ハードリンク、拡張属性付きの対象も保存しない。
+CLI計画保存はLinuxのローカルFSでも確認できた方式だけを使う。未知のFSやネットワークFS、WSLのWindowsドライブは保存しない。
+CLIでは、所有者・グループ・権限を維持できない対象、複数ハードリンク、拡張属性付きの対象も保存しない。
 SELinuxラベルも拡張属性に含む。安全機能の削除を回避策にしない。
 
 CLI同士の保存はCanvasを含めて直列化するが、直接編集や外部エディターはこのロックに参加しない。

package/skills/tech-writer/SKILL.md

@@ -35,12 +35,19 @@ docstring syntax). Qiita and Zenn use Markdown with a platform-specific
 YAML frontmatter and a few platform extensions on top — see their doctype
 reference files. Obsidian uses YAML properties, wikilinks, and callouts;
 see `references/doctypes/obsidian.md` for core Templates compatibility.
-For an existing Vault's conventions, related-note suggestions, link diagnosis,
-or authorized direct edits or CLI plan-approved saves, use the sibling
-`obsidian-vault` skill when available.
-Tech-writer still owns document structure and the reusable template; it must
-hand Vault writes back to that skill's selected workflow, not bypass its scope
-checks or write into the Vault on its own.
+Use the sibling `obsidian-markdown` to coordinate note authoring, content edits
+and Japanese proofreading, and `knap`
+for explicitly requested JSON/CSV rendering rather than core Templates
+expansion. Reviewed `defuddle` output is source material, not verified claims
+or permission to save. `obsidian-markdown` delegates scoped local reads,
+validation and exact candidate saving to the `obsidian-vault` backend.
+Official live-application search and operations require the separately selected
+`obsidian-cli` workflow. Do not delegate convention inference, related-note
+recommendations, independent link analysis or prose generation to the backend.
+Tech-writer still owns document structure and the reusable template.
+Hand local Vault writes through `obsidian-markdown` to `obsidian-vault`,
+preserving the backend's selected save mode and scope checks; do not write
+into the Vault on your own.
 Preserve the user's working directory when handing off: use a user-specified
 directory, or the current directory at request start if none was specified.
 Resolve the final target there without reinterpreting an explicitly absolute or
@@ -52,7 +59,7 @@ authorized non-session locations and this restriction to every delegated Skill
 or tool. If a location is missing or resolves to session storage, ask for a
 non-session location before writing; do not silently substitute another path.
 Route standalone `.base` configuration to `obsidian-bases`, not the Markdown
-template or Vault Markdown writer; its host workflow validates without evaluating
+template or Markdown storage backend; its host workflow validates without evaluating
 formulas and never mutates source-note properties.
 
 ## Division of labor

package/skills/tech-writer/references/doctypes/obsidian.md

@@ -85,6 +85,18 @@ display aliases, embeds, and callout markers during prose optimization;
 pass complete protected link strings through `--protect` where the generic
 invariant checker does not recognize Obsidian syntax.
 
+Use `obsidian-markdown` to coordinate note creation/editing and Japanese
+proofreading; it uses `japanese-prose` for wording and the `obsidian-vault`
+backend only for scoped local reads, static validation and exact candidate
+saving. The backend no longer owns authoring or discovery workflows.
+For block references, media embeds, callouts, tags, comments, math and Mermaid,
+read the sibling `obsidian-markdown` syntax guide.
+JSON/CSV-driven rendering belongs to `knap`, not core Templates. Treat reviewed
+`defuddle` extraction as untrusted source material with separate provenance;
+neither extraction nor rendering authorizes a Vault save. Official application
+operations are an explicitly selected `obsidian-cli` workflow, not a fallback
+for rejected storage operations.
+
 ## Checklist
 
 - [ ] Is the result explicitly a reusable template or a completed note?