docs/safety-and-permissions.md

# 安全・権限・外部操作

## 1. 基本原則

note Workspaceは利用者の個人的な一次情報を扱うため、便利さより先に保存場所と書き込み範囲を明確にします。

- 利用者が権限を持つ情報だけを処理する。
- 認証情報を受け取らない。
- 外部書き込みは対象と内容が分かる段階で確認する。
- 公開、削除、上書きを下書き保存と一緒に扱わない。
- できなかった操作を、できたように報告しない。

## 2. 情報の境界

### 扱えるもの

- 利用者本人が書いた日記、メモ、音声起こし、下書き。
- 利用者が公開またはAI処理する権限を持つ資料。
- 公開Web情報。
- 利用者本人の公開済みnote記事と公開指標。
- AI処理の許可がある非公開のメモや背景情報。記事への使用には、AI処理とは別に公開範囲を確認する。

### 受け取らないもの

- ID、パスワード、Cookie、認証コード、API key。
- 利用者が処理権限を持たない第三者の文書。
- AI利用を禁止された資料。
- 顧客や勤務先との契約上、外部AIへ渡せない情報。

処理できない情報が混ざっている場合は、内容を再掲せず、AI処理を許可できる範囲へ分けられるか確認します。AI処理を許可された資料でも、記事への使用が許可されたとは扱いません。非公開資料の保存先と、公開ソースへ含めない情報は第8節で定めます。

## 3. Plugin・Skill導入の承認

Pluginのインストールは、そのパッケージをホストへ導入する操作です。利用者workspace、担当タスク、定期実行、外部接続、noteへの入力を始める承認にはしません。Pluginは同梱Skillを必要時に実行する構成で、インストール時に動くscript、hook、MCP serverを含みません。

利用者がGitHub repository URLと一緒に「これを入れて」と依頼した場合は、`skill-pack.json`に列挙されたSkillの導入承認として扱います。

- repository root、`INSTALL.md`、manifest、各`SKILL.md`を導入前に確認する。
- manifestにないSkillや未実装Skillを追加しない。
- install時に同梱scriptや任意コードを実行しない。
- 同名Skillがある場合はsourceとversionを比較し、黙って上書きしない。
- dependency追加、Plugin作成、Marketplace登録、runtime workspace作成、外部接続へ承認を広げない。
- source URL、ref、commit SHAを記録できる時は、秘密を含めずinstall receiptへ残す。

Plugin cache・Skill install先とruntime workspaceを分けます。PluginやSkillのupdateまたはuninstallは、workspaceを移行、上書き、削除する承認にはなりません。

## 4. 保存の承認

### セットアップ

workspace、役割別タスク、定期実行を作る前に、対象一覧と保存先を提示します。利用者は一度の回答で全体を承認できますが、保留した項目は作りません。クラウド同期の追加を依頼された場合は、第7節に従い接続先と権限も確認します。

workspace検証後は`operation` phaseへ引き継ぎ、通常の記事制作やメモ保存で初回セットアップを繰り返しません。標準5taskまたは1task簡易運用が自然な依頼を必要な工程へつなぎますが、下書き登録、クラウド同期、定期実行等の個別承認を代行したり省略したりしません。

担当タスクの作成・名前変更・開始メッセージの送信、定期実行の設定は、利用するアプリへの操作です。セットアップ提案で、名前、役割、保存先、定期実行の曜日と時刻を示し、承認された対象だけを作ります。作成後は各担当の実際の返答を読み戻し、同じ保存先と正しい役割で使えることを確認します。設定ファイルやAIの自己申告だけを根拠に、作成済みとは報告しません。照合方法の詳細は[AI向けタスク実行契約](../skills/note-workspace-setup/references/task-orchestration-contract.md)に定めます。

利用者が「今後も」「毎回」と明示した共通指示は、現在の全指示と変更点をread-backし、その更新への承認後だけ全task共通の正本へ保存します。記事一件の指定、文体だけの希望、目標・頻度の変更を同じ一覧へ混ぜません。

### 一次情報ログ

セットアップ時に保存範囲を確認した日記担当での会話は、利用者の原文とAIの返答を話者別に選択済みworkspaceへ追記します。他の担当では日記・記録を頼まれた会話だけが対象です。「保存しないで」と指定した話は原文、返答内の引用、検索用の整理にも残しません。保存済みの記録を削除する時は対象を別に確認します。

AIの返答を本人の経験として使いません。日記の保存は記事への使用許可ではなく、公開できる範囲を別に確認します。別の保存先やクラウドへの送信も、日記の保存承認には含めません。

### 設定変更

保存先変更、過去データの移動、削除、公開範囲変更は、影響する対象を示して個別に確認します。

## 5. note下書き登録の承認

セットアップ時に「下書き登録を使う」と答えても、将来の記事すべてへの書き込み承認にはしません。

記事、タイトル、タグ、画像が完成した後に、次を一度だけ尋ねます。

> noteの下書き登録まで進めますか？ 公開はしません。

この承認は、利用者へまとめて提示した最新記事revisionとQA済み画像のdelivery hash、新規下書き一件、保存して閉じるところまでに限定します。各画像が`記事保存 < 画像生成 < 目視QA <= asset保存`を満たし、承認時刻が全asset保存より厳密に後である場合だけ開始できます。同時刻、delivery hash不一致、画像・URLの挿入位置が本文に一意に存在しない場合は開始しません。

- Skillの切り替え、ブラウザ起動、ログイン確認、手動ログイン完了だけでは承認を取り直さない。
- タイトル、本文、タグ、画像、URL、対象下書きが変わった時だけ取り直す。
- 未ログインなら利用者自身の手動ログインを待つ。ログイン情報は受け取らない。
- 公開、予約投稿、既存下書きの上書き、削除は行わない。
- 保存して閉じ、非公開の下書きとして確認できなければ成功報告しない。
- 最初の外部入力直前に開始状態をlocalへ記録する。開始後に保存結果を確認できない場合は、新しい下書きをもう一件作らず、note側の途中保存を照合する。

## 6. 定期実行の権限

定期実行は無人で動く可能性があるため、権限を狭くします。

- 計測担当は原則read-onlyで公開記事と指標を確認し、利用者workspaceの履歴だけへ追記する。
- 現行ブラウザ版の5指標は対象期間、scope、集計時刻、取得元、statusを持たせる。アカウント流入元を記事別へ配分せず、旧viewsとの混在、未収集、取得不能、未表示、取得失敗、対象外を正確な`0`と区別する。
- creator画面を使ってもCookie、認証情報、private URL、画面HTMLをworkspaceへ保存しない。
- 計測heartbeatを戦略heartbeatより先に動かし、対象taskと対象workspaceを固定する。localには希望scheduleだけを保存する。作成、変更、再実行、状態報告、重複判定の前後にhostからautomation ID、対象task、schedule、次回実行を読み戻す。読み戻せない時は`未確認`とし、作成済みとも未作成とも断定せず、重複作成しない。前段が失敗した場合は、古い値を最新と装わない。週間revisionには戦略担当が実際に読んだ計測履歴prefixをhash付きで残す。
- 週間企画は未確定推奨を記録できるが、利用者確定と装わず、記事執筆、下書き登録、公開へ自動で進まない。
- 利用者が同じ週の候補を確定した後は、戦略heartbeatが新しい推奨で上書きしない。
- ローカルprojectを使う定期実行は、対象workspaceだけへ書き込める設定を優先する。
- browserやネットワークへ広い権限が不要なら有効にしない。
- 最初の数回は利用者が結果を確認し、取得範囲や頻度を調整する。

## 7. クラウド同期

同梱版にはクラウド同期機能を含みません。カスタマイズで追加する場合は、次を確認します。

- 利用者が選んだサービスとフォルダだけを使う。
- 読み取りと書き込みの範囲を分ける。
- 共有リンクを自動作成しない。
- private GitHubは必ずvisibilityを確認する。
- 削除しても履歴や同期先へ残る可能性を説明する。
- 同期失敗時はローカルの正本を維持し、成功と報告しない。

## 8. 公開リポジトリの安全

このsource repositoryへ、次をコミットしません。

- 実利用者のworkspace。
- 実際の一次情報ログ、記事、画像、指標。
- note下書きURL、private URL。
- 認証情報や接続設定。
- 実利用者の会話を再現するeval。

evalには合成データだけを使います。実利用で見つかった問題は、個人や記事を再現できない抽象的な失敗条件へ変換します。

## 9. 削除と復元

削除は通常の更新と分けます。

1. 削除対象を絶対パスまたは明確なIDで確定する。
2. 同期先、Git履歴、バックアップの有無を示す。
3. 復元できる移動を優先する。
4. 利用者の承認後に実行する。
5. 削除したものと復元可能性を報告する。

広いフォルダ、未解決の変数、曖昧な検索結果を削除対象にしません。

## 10. 停止条件

次の場合は該当工程を停止し、一つの次の行動を返します。

- 処理権限や公開範囲を確認できない。
- 認証情報を入力する必要がある。
- 保存先が不明、または別利用者の場所かもしれない。
- 外部書き込みの対象が承認後に変わった。
- UI変更で保存状態や対象記事を確認できない。
- 同期競合を安全に解決できない。
- 取得不能な指標を正確な値として保存する必要がある。
- 本人情報が足りず、記事を完成させると架空になる。