kotonoha 0.5.6 → 0.5.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +18 -1
- package/README-ja.md +8 -6
- package/README.md +11 -8
- package/package.json +1 -1
- package/skills/obsidian-markdown/SKILL.md +4 -2
- package/skills/obsidian-vault/SKILL.md +71 -27
- package/skills/obsidian-vault/references/workflow.md +32 -14
package/CHANGELOG.md
CHANGED
|
@@ -7,6 +7,22 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
7
7
|
|
|
8
8
|
## [Unreleased]
|
|
9
9
|
|
|
10
|
+
## [0.5.7] - 2026-11-08
|
|
11
|
+
|
|
12
|
+
### Added
|
|
13
|
+
|
|
14
|
+
- Allow an approved tarball SHA-256 in the manual npm publishing workflow.
|
|
15
|
+
Pack once, verify the supplied hash and publish that exact archive; stop
|
|
16
|
+
before publishing if the artifact differs.
|
|
17
|
+
|
|
18
|
+
### Fixed
|
|
19
|
+
|
|
20
|
+
- Use WSL-visible path, type and file-identity checks for normal OneDrive host
|
|
21
|
+
reads/saves instead of requiring Windows reparse-tag or final-path APIs.
|
|
22
|
+
Cloud reparse metadata alone no longer blocks WSL operations. Keep detected
|
|
23
|
+
redirection/access denials, source rechecks and in-place updates; retain
|
|
24
|
+
native Windows tag verification and unchanged Python CLI/Canvas/Bases gates.
|
|
25
|
+
|
|
10
26
|
## [0.5.6] - 2026-11-07
|
|
11
27
|
|
|
12
28
|
### Added
|
|
@@ -305,4 +321,5 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
|
|
|
305
321
|
[0.5.4]: https://github.com/nahisaho/kotonoha/compare/v0.5.3...v0.5.4
|
|
306
322
|
[0.5.5]: https://github.com/nahisaho/kotonoha/compare/v0.5.4...v0.5.5
|
|
307
323
|
[0.5.6]: https://github.com/nahisaho/kotonoha/compare/v0.5.5...v0.5.6
|
|
308
|
-
[
|
|
324
|
+
[0.5.7]: https://github.com/nahisaho/kotonoha/compare/v0.5.6...v0.5.7
|
|
325
|
+
[Unreleased]: https://github.com/nahisaho/kotonoha/compare/v0.5.7...HEAD
|
package/README-ja.md
CHANGED
|
@@ -6,7 +6,7 @@ kotonohaは、GitHub CopilotとClaude Code向けのスキルを提供します
|
|
|
6
6
|
|
|
7
7
|
Obsidian向けには、Markdown記法、許可されたVault内のノート操作、JSON Canvas、Bases、公式アプリCLIを扱います。DefuddleによるWeb・HTML本文の抽出と、KnapによるJSON・CSVからのテンプレート生成にも対応します。操作ごとに、参照範囲・依存関係・保存の許可を確認します。
|
|
8
8
|
|
|
9
|
-
バージョンは **0.5.
|
|
9
|
+
バージョンは **0.5.7** です(2026-11-08更新)。`obsidian-markdown`、`obsidian-cli`、`defuddle`、`knap`を含む11のスキルを同梱しています。npmパッケージを使うか、[ソースからスキルを導入する手順](#このチェックアウトからスキルを導入)を参照してください。
|
|
10
10
|
|
|
11
11
|
[English](./README.md) | [日本語](./README-ja.md)
|
|
12
12
|
|
|
@@ -101,14 +101,16 @@ Linuxでは所有者・グループ・権限を維持します。
|
|
|
101
101
|
既存ノートは置換せず同じ実体へ書き込み、WindowsのACL・属性を保持します。仮想的なLinux権限だけでは拒否しません。
|
|
102
102
|
ネットワーク共有は対象外とし、パス・実体・保存後のバイト列を検証します。保存方式が不明な編集ツールは使いません。
|
|
103
103
|
`/tmp`等への別出力を、許可済みVaultの更新の代わりにはしません。
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
104
|
+
WSLのOneDrive保存は、WSLのパス解決・要素の型・ファイル実体の確認を使います。cloud再解析属性はWSLのシンボリックリンクではありません。
|
|
105
|
+
通常のWSLファイルにWindows再解析タグ取得や最終パスAPIを要求せず、取得機能がないことだけでは保存を拒否しません。
|
|
106
|
+
ネイティブWindowsではcloudタグ検証を維持します。検出した転送・リンク・範囲外への逸脱と実際の権限拒否は引き続き拒否します。
|
|
107
|
+
オンライン専用と判明したファイルのローカル取得通信には別途同意が必要です。
|
|
107
108
|
Python CLI・Canvas・Basesの対応範囲は広げません。CLIでは引き続きWSLのWindowsドライブや拡張属性付き対象を拒否します。
|
|
108
109
|
SELinuxラベルなどの削除を回避策にしません。
|
|
109
110
|
直接編集はCLIの原子的確定、ルートロック、成功記録による再実行保護を利用しません。
|
|
110
111
|
保存後に読み戻して確認しますが、途中失敗や同時編集の完全な防止は保証しません。
|
|
111
112
|
LLMの誤判断を完全には防げず、ホストを隔離する機能でもありません。
|
|
113
|
+
WSLのホストから見えるパス確認はWindows再解析情報の独立監査ではなく、検出不能な転送がないことを保証しません。
|
|
112
114
|
|
|
113
115
|
ホストツールでは、Markdown・PDFに限らず、明示指定したディレクトリの作成と通常ファイルの作成・編集・削除も行えます。
|
|
114
116
|
正確な対象・操作への許可を確認し、ワイルドカードの一括指定は範囲内で列挙した全対象を承認してから実行します。
|
|
@@ -155,7 +157,7 @@ Node 18以上と固定依存が必要です。依存の準備は別途許可を
|
|
|
155
157
|
|
|
156
158
|
## Obsidian記法・アプリ操作・データからのノート生成
|
|
157
159
|
|
|
158
|
-
0.5.
|
|
160
|
+
0.5.7は、[kepano/obsidian-skills](https://github.com/kepano/obsidian-skills)の6つの機能分野を、kotonoha独自の手順と例で扱います。
|
|
159
161
|
参照した版は[`3ccff5338ea700537839b21900aa5358a0402c98`](https://github.com/kepano/obsidian-skills/tree/3ccff5338ea700537839b21900aa5358a0402c98)です(2026-11-05確認)。
|
|
160
162
|
対応する実行環境や保存方法が参照先と同一という意味ではありません。既存のCanvas・Basesの検査範囲と保存制約を維持します。
|
|
161
163
|
|
|
@@ -299,7 +301,7 @@ npx kotonoha install --skill all
|
|
|
299
301
|
```
|
|
300
302
|
|
|
301
303
|
`--skill all`が既定値であるため、`npx kotonoha install`も同じ動作です。導入できるスキルは、使用したパッケージに依存します。
|
|
302
|
-
0.5.
|
|
304
|
+
0.5.7には11のスキルを同梱しています。導入先プロジェクトで、すべて配置されたことを確認します。
|
|
303
305
|
|
|
304
306
|
```bash
|
|
305
307
|
test -f .github/skills/consulting-analyst/SKILL.md
|
package/README.md
CHANGED
|
@@ -14,7 +14,7 @@ The Obsidian suite covers Markdown syntax, authorized Vault notes, JSON Canvas,
|
|
|
14
14
|
Bases, official app commands, web/HTML extraction and JSON/CSV template rendering.
|
|
15
15
|
Each workflow keeps its own scope, dependency and save requirements.
|
|
16
16
|
|
|
17
|
-
Version: **0.5.
|
|
17
|
+
Version: **0.5.7** (updated 2026-11-08), with eleven bundled Skills, including
|
|
18
18
|
`obsidian-markdown`, `obsidian-cli`, `defuddle` and `knap`.
|
|
19
19
|
Install the npm package or use the
|
|
20
20
|
[source-checkout installation](#install-skills-from-this-source-checkout).
|
|
@@ -176,10 +176,12 @@ for requests, command examples, data retention and recovery.
|
|
|
176
176
|
Saving requires verifiable local regular files; symlinks and multiple hard
|
|
177
177
|
links are refused. Native Linux saves preserve ownership/modes.
|
|
178
178
|
Host direct saves also support native Windows and confirmed local Windows drives
|
|
179
|
-
through WSL (`drvfs`/`9p`/`v9fs`), not network shares.
|
|
180
|
-
|
|
181
|
-
|
|
182
|
-
|
|
179
|
+
through WSL (`drvfs`/`9p`/`v9fs`), not network shares. WSL OneDrive saves use
|
|
180
|
+
WSL-resolved paths, component types and file identity; cloud reparse metadata
|
|
181
|
+
is not a WSL symlink. Windows tag/final-path APIs are not required for otherwise
|
|
182
|
+
normal WSL files. Native Windows retains cloud-tag verification. Detected
|
|
183
|
+
redirections, symlinks, scope escapes and actual access denials remain blocked;
|
|
184
|
+
known hydration requires separate consent. Existing notes must be updated in place,
|
|
183
185
|
preserving Windows ACLs/attributes rather than replacing the file or requiring
|
|
184
186
|
synthetic Linux permissions. Path/identity checks and exact readback remain
|
|
185
187
|
mandatory; an unknown host replacement method is not sufficient.
|
|
@@ -189,7 +191,8 @@ CLI saving still requires a verified Linux filesystem and refuses all xattrs,
|
|
|
189
191
|
including SELinux labels. Never remove attributes to bypass a refusal.
|
|
190
192
|
Direct-edit failure and concurrency limitations are disclosed before saving;
|
|
191
193
|
neither mode eliminates post-check external edits or LLM mistakes.
|
|
192
|
-
The skill is not a host sandbox.
|
|
194
|
+
The skill is not a host sandbox. WSL host-visible checks are not an independent
|
|
195
|
+
Windows reparse audit or a guarantee against undetectable redirections.
|
|
193
196
|
|
|
194
197
|
Host operations also allow explicitly authorized directory creation and
|
|
195
198
|
regular-file creation, editing and deletion, not just Markdown/PDF outputs.
|
|
@@ -255,7 +258,7 @@ for exact-byte preservation, four original templates and failure handling.
|
|
|
255
258
|
|
|
256
259
|
## Obsidian syntax, app commands and data-driven notes
|
|
257
260
|
|
|
258
|
-
The 0.5.
|
|
261
|
+
The 0.5.7 Skills cover all six capability families in
|
|
259
262
|
[kepano/obsidian-skills](https://github.com/kepano/obsidian-skills), with original
|
|
260
263
|
kotonoha instructions and examples. Reference snapshot:
|
|
261
264
|
[`3ccff5338ea700537839b21900aa5358a0402c98`](https://github.com/kepano/obsidian-skills/tree/3ccff5338ea700537839b21900aa5358a0402c98),
|
|
@@ -447,7 +450,7 @@ npx kotonoha install --skill all
|
|
|
447
450
|
```
|
|
448
451
|
|
|
449
452
|
`--skill all` is the default, so `npx kotonoha install` has the same behavior.
|
|
450
|
-
The selected package determines which Skills are available; version 0.5.
|
|
453
|
+
The selected package determines which Skills are available; version 0.5.7
|
|
451
454
|
includes all eleven. In the destination project, confirm they were installed:
|
|
452
455
|
|
|
453
456
|
```bash
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "kotonoha",
|
|
3
|
-
"version": "0.5.
|
|
3
|
+
"version": "0.5.7",
|
|
4
4
|
"description": "Skills for GitHub Copilot and Claude Code: consulting, technical writing, Japanese prose, Obsidian Markdown, Canvas, Bases and CLI, Defuddle, Knap, and PPTX planning.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"author": "nahisaho",
|
|
@@ -27,8 +27,10 @@ Coordinate content and review, not a second storage backend. Read the
|
|
|
27
27
|
Preserve the selected direct-save or optional plan-approved workflow.
|
|
28
28
|
For a WSL local Windows drive, use its host direct-save profile; do not
|
|
29
29
|
reject `v9fs` alone or route a normal content edit through Python CLI planning.
|
|
30
|
-
|
|
31
|
-
|
|
30
|
+
WSL OneDrive targets use WSL path/type/identity checks, not native Windows
|
|
31
|
+
reparse-tag or final-path API requirements. Missing Windows metadata tools
|
|
32
|
+
alone must not block a normal WSL OneDrive save. Native Windows uses the
|
|
33
|
+
backend's separate tag-verification profile.
|
|
32
34
|
Do not silently substitute `/tmp` output for the authorized Vault target.
|
|
33
35
|
If it is unavailable, report the missing sibling and provide an unsaved draft.
|
|
34
36
|
- Use `tech-writer` for note structure and its existing
|
|
@@ -79,7 +79,13 @@ write or CLI filesystem requirements to a read. Do not enumerate a parent
|
|
|
79
79
|
folder or read sibling documents merely to open an already specified file;
|
|
80
80
|
parent metadata checks do not authorize parent content access.
|
|
81
81
|
|
|
82
|
-
On
|
|
82
|
+
On WSL Windows drives, use the WSL host path/type/identity checks described in
|
|
83
|
+
the direct-save profile below for authorized reads too. Windows cloud reparse
|
|
84
|
+
metadata is not a WSL symlink. Do not require Windows reparse-tag queries or
|
|
85
|
+
Windows final-path APIs when WSL resolves the authorized path and exposes a
|
|
86
|
+
regular file; their absence alone must not block the read.
|
|
87
|
+
|
|
88
|
+
On native Windows, a OneDrive folder name or the
|
|
83
89
|
`FILE_ATTRIBUTE_REPARSE_POINT` flag alone is not grounds to refuse reading.
|
|
84
90
|
Inspect the actual reparse tag for each flagged component from root to target.
|
|
85
91
|
Allow only verified Windows cloud-family tags (`IO_REPARSE_TAG_CLOUD` and its
|
|
@@ -89,10 +95,13 @@ Reject symlinks, junctions, mount-point redirections, unknown tags and scope
|
|
|
89
95
|
escapes. Missing tag/final-path verification blocks the affected read; report
|
|
90
96
|
the exact path and missing capability rather than declaring all OneDrive unsafe.
|
|
91
97
|
|
|
92
|
-
Read only locally available regular-file bytes. Before opening
|
|
98
|
+
Read only locally available regular-file bytes. Before opening a known online-only
|
|
93
99
|
or recall-on-access placeholder, obtain explicit consent for hydration/network
|
|
94
|
-
access; if
|
|
95
|
-
|
|
100
|
+
access; if metadata or host warnings indicate recall risk and availability
|
|
101
|
+
cannot be established, stop before a potentially hydrating read. A normal WSL
|
|
102
|
+
file read does not need a separate Windows cloud-availability query merely
|
|
103
|
+
because a parent is in OneDrive. Do not change cloud attributes, pin files,
|
|
104
|
+
change sync settings
|
|
96
105
|
or create copies to force access. Respect ACL denials, host tool refusals and
|
|
97
106
|
content-exclusion policies; never retry through another tool to bypass them.
|
|
98
107
|
Check the source identity and change metadata around the read and report
|
|
@@ -150,8 +159,8 @@ not performed, not an unverified substitute.
|
|
|
150
159
|
changes; never overwrite from stale content. Identical bytes mean no write.
|
|
151
160
|
5. Save the exact candidate with host tools. On native Linux filesystems,
|
|
152
161
|
preserve owner/group/modes and refuse xattrs or unsupported attributes.
|
|
153
|
-
For
|
|
154
|
-
profile below instead.
|
|
162
|
+
For Windows drives, select the matching WSL or native Windows direct-save
|
|
163
|
+
profile below instead; do not apply native Windows checks to WSL.
|
|
155
164
|
Both profiles refuse multiple hard links and attribute-removing workarounds,
|
|
156
165
|
including removal of SELinux labels.
|
|
157
166
|
6. Read back after saving; require exact candidate bytes and unchanged unspecified content.
|
|
@@ -174,26 +183,36 @@ the target first when its save state is unknown.
|
|
|
174
183
|
Support authorized Markdown saves on a confirmed local Windows drive mounted
|
|
175
184
|
through WSL as `drvfs`, `9p` or `v9fs`. Do not reject it solely because of that
|
|
176
185
|
filesystem name or apply the Python CLI's filesystem allowlist to host saves.
|
|
177
|
-
|
|
178
|
-
|
|
186
|
+
WSL OneDrive saves are supported when the authorized target is exposed as a
|
|
187
|
+
normal WSL file. OneDrive cloud reparse metadata, including on parent directories,
|
|
188
|
+
is not a WSL symbolic link and is not itself a path redirection.
|
|
189
|
+
Native Windows uses the separate tag-verification profile below.
|
|
179
190
|
This profile does not extend Python CLI, Canvas or Bases saving support.
|
|
180
191
|
|
|
181
192
|
1. Verify WSL, the actual mount and its Windows path mapping; a `/mnt/c/...`
|
|
182
|
-
spelling alone is not evidence.
|
|
183
|
-
|
|
193
|
+
spelling alone is not evidence. Use the actual WSL mount metadata and path
|
|
194
|
+
mapping to identify the local Windows drive, not a mapped network drive or
|
|
195
|
+
UNC/SMB share. Do not require PowerShell, fsutil or Windows drive APIs to
|
|
196
|
+
repeat a local-drive mapping already established from WSL.
|
|
184
197
|
2. Keep the authorized root/target, byte hashes, no-symlink and link-count checks.
|
|
185
|
-
|
|
198
|
+
Use WSL path resolution, component metadata (`lstat` or equivalent), regular
|
|
199
|
+
file/directory types and opened-file identity within the authorized root.
|
|
186
200
|
A OneDrive folder name or `FILE_ATTRIBUTE_REPARSE_POINT` alone is not grounds
|
|
187
|
-
to refuse saving.
|
|
188
|
-
|
|
189
|
-
|
|
190
|
-
|
|
191
|
-
Reject symlinks, junctions
|
|
201
|
+
to refuse saving. Do not require Windows reparse-tag queries, cloud-tag
|
|
202
|
+
allowlists or Windows final-path APIs for this WSL profile. Missing Windows
|
|
203
|
+
metadata capabilities alone must not block a normal WSL OneDrive save.
|
|
204
|
+
Verify the resolved WSL path and opened file stay inside the authorized root
|
|
205
|
+
and exact target. Reject WSL symlinks, detected junctions or other path
|
|
206
|
+
redirections, scope escapes and special files. If optional Windows metadata
|
|
207
|
+
identifies an actual name-surrogate/redirection, reject it; do not ignore
|
|
208
|
+
positive evidence of a redirection.
|
|
192
209
|
For new files verify the parent before exclusive creation and the opened
|
|
193
|
-
file before writing. Missing
|
|
194
|
-
|
|
195
|
-
Before reading or updating
|
|
196
|
-
obtain explicit hydration/network consent
|
|
210
|
+
file before writing. Missing WSL path/type/identity checks block the affected
|
|
211
|
+
target; report which check is missing, not a blanket reparse-point refusal.
|
|
212
|
+
Before reading or updating a known online-only or recall-on-access placeholder,
|
|
213
|
+
obtain explicit hydration/network consent. Stop if recall risk is indicated
|
|
214
|
+
but availability is unknown; do not demand a cloud-availability API for an
|
|
215
|
+
otherwise normal WSL file merely because its parent is in OneDrive.
|
|
197
216
|
Do not pin files, remove cloud attributes or change sync settings.
|
|
198
217
|
Respect Windows read-only attributes and ACL access denials.
|
|
199
218
|
Target only the ordinary `.md` data stream, not `:stream` or device paths.
|
|
@@ -210,8 +229,12 @@ This profile does not extend Python CLI, Canvas or Bases saving support.
|
|
|
210
229
|
For a new note, create exclusively without overwriting an equivalent name,
|
|
211
230
|
allowing normal Windows parent ACL inheritance.
|
|
212
231
|
5. Flush/close, then read back exact bytes and verify file identity and observable
|
|
213
|
-
attributes, allowing only normal write timestamps/archive-bit
|
|
232
|
+
WSL-observable attributes, allowing only normal write timestamps/archive-bit
|
|
233
|
+
updates and
|
|
214
234
|
consented hydration state changes, not loss of cloud-provider metadata.
|
|
235
|
+
Retaining the object avoids intentionally replacing its Windows metadata;
|
|
236
|
+
unavailable Windows ACL/cloud-attribute enumeration is not a refusal reason
|
|
237
|
+
and must not be reported as verified attribute preservation.
|
|
215
238
|
Report saved only on a match. Disclose non-atomic writes,
|
|
216
239
|
possible partial writes and concurrent Obsidian/Sync/Windows edits before saving;
|
|
217
240
|
after a possible write failure report unknown, without retry or rollback.
|
|
@@ -222,6 +245,24 @@ Do not silently redirect a refused save to `/tmp` or another file. An alternate
|
|
|
222
245
|
output needs explicit exact-path consent and is never a successful Vault update.
|
|
223
246
|
Proofreading gates and the session-storage prohibition still apply.
|
|
224
247
|
|
|
248
|
+
### Native Windows direct saves
|
|
249
|
+
|
|
250
|
+
Use the same authorization, source rechecks, exclusive creation, in-place updates
|
|
251
|
+
and exact readback rules. Verify the local Windows backing drive and ordinary
|
|
252
|
+
data stream. A OneDrive folder name or flag alone is not grounds to refuse
|
|
253
|
+
saving. For native Windows path verification, inspect each actual reparse
|
|
254
|
+
tag, including parent directories, and allow only verified Windows cloud-family
|
|
255
|
+
tags (`IO_REPARSE_TAG_CLOUD` and documented variants) that are not name surrogates.
|
|
256
|
+
Verify the opened object's final path and identity stay inside the authorized
|
|
257
|
+
root and exact target. Reject symlinks, junctions, mount-point redirections,
|
|
258
|
+
unknown tags and escapes. Missing tag/final-path verification blocks the affected
|
|
259
|
+
native Windows target. Respect ACLs/read-only attributes and hydration consent.
|
|
260
|
+
Do not apply these Windows-API preconditions to WSL host reads or saves.
|
|
261
|
+
|
|
262
|
+
Neither host profile is a Windows security sandbox or a guarantee against all
|
|
263
|
+
undetectable reparse redirections, races or sync failures. WSL checks establish
|
|
264
|
+
the host-visible path/type/identity, not an independent Windows reparse audit.
|
|
265
|
+
|
|
225
266
|
## Authorized file and directory operations
|
|
226
267
|
|
|
227
268
|
Use host filesystem tools for directory creation and regular-file creation,
|
|
@@ -247,10 +288,12 @@ existing save gates. Never use generic file writing to bypass those gates.
|
|
|
247
288
|
siblings, parent creation, attachment changes or backlink repair.
|
|
248
289
|
Check resolved paths from root to target, equivalent-name collisions, types,
|
|
249
290
|
identity, link counts and management-directory exclusions. Reject symlinks,
|
|
250
|
-
junctions,
|
|
251
|
-
|
|
252
|
-
ACL and hydration checks
|
|
253
|
-
|
|
291
|
+
detected junctions/redirections, scope escapes and special/device files.
|
|
292
|
+
Select the WSL or native Windows profile for local-drive, ordinary-stream,
|
|
293
|
+
ACL and hydration checks; unknown-tag refusal is native-Windows-only.
|
|
294
|
+
Do not reintroduce Windows tag/API requirements for WSL operations.
|
|
295
|
+
Do not bypass host refusals or content exclusions; missing verification blocks
|
|
296
|
+
only the affected operation.
|
|
254
297
|
3. For `mkdir`, list and authorize each missing parent explicitly. Create each
|
|
255
298
|
directory without overwriting, after verifying its existing parent; recheck
|
|
256
299
|
the new directory's identity and scope before proceeding to its children.
|
|
@@ -311,8 +354,9 @@ PDF download or Docling conversion. Neither tool is bundled or auto-installed.
|
|
|
311
354
|
Existing files require separate replacement authority and source bytes/hash;
|
|
312
355
|
use the selected direct-save profile, never a converter's unchecked overwrite.
|
|
313
356
|
Verify paths, identities, no symlinks, management-directory exclusions and
|
|
314
|
-
link counts as above. Windows/WSL imports use
|
|
315
|
-
verified non-redirecting cloud tags
|
|
357
|
+
link counts as above. Windows/WSL imports use their respective host profile:
|
|
358
|
+
WSL path/type checks or native Windows verified non-redirecting cloud tags.
|
|
359
|
+
Apply the profile's ordinary-data-stream rule to
|
|
316
360
|
each authorized artifact extension, never `:stream` or device paths.
|
|
317
361
|
4. Only create missing directories with separate approval for their exact paths,
|
|
318
362
|
after verifying the existing ancestor and rechecking each created directory;
|
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
呼出元が指定した範囲の読み取り・静的検証・候補の保存と、明示許可されたPDF・変換成果物の取り込みを担当する。
|
|
4
4
|
ホストツールによるディレクトリ作成、通常ファイルの作成・編集・削除も、正確な対象と操作への許可を得て行う。
|
|
5
5
|
本文の作成・編集の指揮はobsidian-markdown、日本語の校正はjapanese-proseへ分離する。
|
|
6
|
-
対象は0.5.
|
|
6
|
+
対象は0.5.7であり、Canvas用の共用保存API版1は維持する。
|
|
7
7
|
|
|
8
8
|
## 上位ワークフローの移管
|
|
9
9
|
|
|
@@ -84,23 +84,29 @@ CLI操作が失敗した場合も、この経路へ無断で切り替えない
|
|
|
84
84
|
|
|
85
85
|
この手順は、ホストツールによる通常のMarkdownノート保存だけに適用する。
|
|
86
86
|
この直接保存手順は0.5.4から対応する。
|
|
87
|
-
ネイティブWindows
|
|
88
|
-
|
|
87
|
+
ネイティブWindowsの再解析タグ検証は別の手順とし、WSL保存の必須条件に流用しない。
|
|
88
|
+
通常ファイルの作成・編集と成果物取り込みも、実行環境に応じた手順を各拡張子の通常データストリームに適用する。
|
|
89
89
|
WSLのローカルWindowsドライブなら、FS名がdrvfs・9p・v9fsであることだけを理由に拒否しない。
|
|
90
90
|
Python CLI・Canvas・Basesの保存対応は拡張せず、CLIの許可FS一覧を直接保存の条件に流用しない。
|
|
91
91
|
Pythonやuvを必須にする変更でもない。
|
|
92
92
|
|
|
93
93
|
1. WSL環境、実際のマウント、Windowsパスとの対応を確認する。`/mnt/c/...`という表記だけでは判断しない。
|
|
94
|
-
Windows
|
|
94
|
+
WSLのマウント情報とパス対応からローカルWindowsドライブを確認し、ネットワークドライブやUNC・SMB共有は対象外にする。
|
|
95
|
+
WSLで確認できたドライブ対応を、PowerShell・fsutil・Windows APIで再確認することは必須にしない。
|
|
95
96
|
2. 許可済みのVaultと保存先、原文ハッシュ、ファイル実体、リンク数を確認する。
|
|
96
97
|
OneDriveというフォルダー名や再解析ポイント属性だけでは保存を拒否しない。
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
98
|
+
OneDriveのcloud再解析属性はWSLのシンボリックリンクではなく、それ自体は別パスへの転送を示さない。
|
|
99
|
+
WSLのパス解決、各要素のlstat等のメタデータ、通常ファイル・ディレクトリか、開いた実体の識別情報を確認する。
|
|
100
|
+
解決したWSLパスと実体が許可済みのVaultと正確な対象の範囲に収まることを確認する。
|
|
101
|
+
Windows再解析タグ取得、cloudタグの許可一覧、Windows最終パスAPIは必須にしない。
|
|
102
|
+
それらの取得機能がないことだけで、通常のWSLファイルとして扱えるOneDriveへの保存を拒否しない。
|
|
103
|
+
WSLのシンボリックリンク、検出したジャンクションや実際の転送、範囲外、特殊ファイルは拒否する。
|
|
104
|
+
任意のWindowsメタデータ検査で名前代理・転送が判明した場合も拒否し、実際の転送の証拠は無視しない。
|
|
100
105
|
新規対象は排他的作成前に親を検証し、作成した実体も書き込み前に確認する。
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
106
|
+
オンライン専用やアクセス時に取得すると判明したファイルは、読み取り・更新前に取得通信への明示同意を得る。
|
|
107
|
+
取得通信の兆候がありローカル利用可能か不明なら止めるが、通常のWSLファイルにWindows側の利用可能性APIを要求しない。
|
|
108
|
+
固定、クラウド属性削除、同期設定変更で回避しない。
|
|
109
|
+
WSLのパス・型・実体を確認できなければ、その不足と対象パスを具体的に報告する。読み取り専用属性やACLによる拒否を尊重する。
|
|
104
110
|
通常の`.md`データストリームだけを対象にし、`:stream`やデバイスパスへ書き込まない。
|
|
105
111
|
3. 既存ノートは同じファイル実体へ書き込む。切り詰めずに開き、同じハンドルで原文と実体を保存直前に照合する。
|
|
106
112
|
候補を書いた後、候補と同じ長さに切り詰める。一時ファイルへの置換、改名、削除しての再作成は使わない。
|
|
@@ -110,7 +116,8 @@ Pythonやuvを必須にする変更でもない。
|
|
|
110
116
|
新規ノートは排他的に作成し、既存名を上書きせず、通常のWindows親ディレクトリのACL継承に従う。
|
|
111
117
|
5. 書き込みをフラッシュして閉じ、読み戻したバイト列・実体・観測できる属性を確認する。
|
|
112
118
|
通常の書き込みに伴う時刻・アーカイブ属性更新と、同意済みのローカル取得に伴う状態変化だけを許容する。
|
|
113
|
-
|
|
119
|
+
同じ実体を維持し、クラウドプロバイダーのメタデータを意図的に置換しない。
|
|
120
|
+
WindowsのACL・cloud属性を列挙できないことだけでは拒否せず、検証できた属性として報告もしない。
|
|
114
121
|
途中失敗やObsidian・Sync・Windows側の同時編集を完全には防げないことを、保存前に説明する。
|
|
115
122
|
書いた可能性がある失敗は結果不明とし、自動再保存やロールバックは行わない。
|
|
116
123
|
|
|
@@ -121,6 +128,15 @@ chmod・chown、属性の削除、マウントやWindows設定の変更で保存
|
|
|
121
128
|
校正の保護検査・意味レビューと、セッション領域への保存禁止は維持する。
|
|
122
129
|
権限の違いは[MicrosoftのWSLファイル権限資料](https://learn.microsoft.com/en-us/windows/wsl/file-permissions)を参照する。
|
|
123
130
|
|
|
131
|
+
### ネイティブWindowsでの直接保存
|
|
132
|
+
|
|
133
|
+
ネイティブWindowsでは親を含む実際の再解析タグを確認し、名前代理ではない確認済みのcloud系タグだけを許可する。
|
|
134
|
+
開いた実体のWindows最終パスと識別情報を確認し、未知のタグ、ジャンクション、範囲外への転送は拒否する。
|
|
135
|
+
確認できなければネイティブWindowsの対象を停止するが、このWindows API要件をWSL保存へ流用しない。
|
|
136
|
+
認可、原文再照合、非上書き作成、同一実体への更新、読み戻しと取得通信同意は維持する。
|
|
137
|
+
WSLの確認はホストから見えるパス・型・実体の確認であり、Windows再解析情報の独立監査ではない。
|
|
138
|
+
どちらも検出不能な転送、同時変更、同期失敗がないことを保証しない。
|
|
139
|
+
|
|
124
140
|
## ディレクトリとファイルのホスト操作
|
|
125
141
|
|
|
126
142
|
許可済みのVaultと範囲内で、ディレクトリ作成、通常ファイルの作成・編集・削除をホストツールで行う。
|
|
@@ -135,8 +151,10 @@ chmod・chown、属性の削除、マウントやWindows設定の変更で保存
|
|
|
135
151
|
必要な読み取り・モデル入力範囲、コピー同意も渡し、不足する情報は1問ずつ確認する。
|
|
136
152
|
2. 全対象と操作を提示する。ワイルドカードや一括指定は許可済みの列挙範囲内だけで展開し、確定したパス・操作への承認を得る。
|
|
137
153
|
親・対象の実体、同等名、型、範囲、リンク数、管理フォルダー除外を確認する。
|
|
138
|
-
|
|
139
|
-
|
|
154
|
+
シンボリックリンク、検出したジャンクション・転送、範囲外、特殊ファイルは拒否する。
|
|
155
|
+
WSLでは前節のWSLパス・型・実体の確認、ネイティブWindowsでは再解析タグ検証を使う。
|
|
156
|
+
未知のWindowsタグ拒否はネイティブWindowsに限定し、WSLでWindowsメタデータ取得を再び必須にしない。
|
|
157
|
+
どちらもローカルドライブ・通常ストリーム・ACL・取得通信の確認は維持する。
|
|
140
158
|
ホスト拒否やコンテンツ除外を回避せず、確認不能なら影響する操作だけを停止する。
|
|
141
159
|
3. ディレクトリ作成は未作成の親もすべて正確なパスで許可を得て、既存の親を検証してから非上書きで順に作る。
|
|
142
160
|
作成した各実体と範囲を確認してから子へ進む。検証済みの既存ディレクトリは変更なしとする。
|
|
@@ -174,7 +192,7 @@ DefuddleとKnapをPDF変換の代替として使わない。
|
|
|
174
192
|
利用できる取得ツール・Doclingと出力方式を実行前に確認する。依存導入やOCR・モデル資産の取得は別途許可を得る。
|
|
175
193
|
3. 元PDF、抽出Markdown、明示指定した画像・JSON等の全出力先を保存前に提示する。
|
|
176
194
|
同名・同等名の衝突を確認して非上書きで作成し、既存対象の置換には別途許可と元のバイト列・ハッシュを要求する。
|
|
177
|
-
対象・親の実体、範囲、管理フォルダー除外、リンク数を確認し、Windows
|
|
195
|
+
対象・親の実体、範囲、管理フォルダー除外、リンク数を確認し、WSLとネイティブWindowsそれぞれの手順を使う。
|
|
178
196
|
変換ツールの無検証上書きは使わず、通常データストリーム以外への書き込みは拒否する。
|
|
179
197
|
4. 親が未作成なら正確な作成パスへの別途許可を得て、既存の祖先と作成した各フォルダーを再確認する。
|
|
180
198
|
ツールの追加出力を承認済みのものに限定できなければ、別途同意した仮出力先で生成し、検証済みのバイト列だけを移す。
|