@shinaps/skills 0.47.0 → 0.49.0

package/plugins/shinaps-claude/references/linear/configuration.md

@@ -1,21 +1,19 @@
 # プロジェクト設定
 
-設定は、運用上の決定と既存資料への参照を持つ。手順の全文は書かない。秘密値を保存しない。設定は `config_version: 2` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。利用前に同梱CLIで構造を検証し、合意・参照先・工程の実在確認は各手順で行う。
+設定は、運用上の決定と既存資料への参照を持つ。手順の全文は書かない。秘密値を保存しない。設定は `config_version: 3` のJSONで、[JSON Schema](configuration.schema.json)を契約の正本とする。利用前に同梱CLIで構造を検証し、合意・参照先・工程の実在確認は各手順で行う。
 
 ## 検証CLIと契約版
 
-利用中のskillとCLIの版を確認し、0.47.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.47.0`）。pluginだけにはCLIは含まれない。導入・更新が必要ならその権限を確認し、検証のたびに `npx latest` を取得しない。
+利用中のskillとCLIの版を確認し、0.49.0のskillには同じ版のnpm CLIを導入する（`npm install -g @shinaps/skills@0.49.0`）。pluginだけにはCLIは含まれない。導入・更新は検証に必要な準備として行い、検証のたびに `npx latest` を取得しない。
 
-0.35.0から通常設定の `review_flow.mode` に `ask` を受理する。`config_version` は2のままで、既存のauto・manualの設定は変更不要。0.33.0〜0.34.xのCLIと `$schema` のURLは `ask` を拒否するため、`ask` を使う設定では `$schema` も0.35.0以降のURLにする。
-
-0.39.0から許可 `claude_cli_bypass_permissions` を受理する。`config_version` は2のままで、0.33.0〜0.38.xのCLIと `$schema` のURLはこの許可を拒否するため、使う設定では `$schema` も0.39.0以降のURLにする。
+0.48.0から `config_version: 3`（操作ごとの許可の一覧を廃止し `constraints` を必須にした契約）だけを受理する。0.47.x以前のCLIと `$schema` のURLはv3を拒否し、0.48.0以降はv2を拒否するため、skill・CLI・`$schema` の版を揃えてから下の[旧設定の移行](#旧設定の移行)を行う。
 
 ```sh
 shinaps-skills --version
 shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 ```
 
-ローカル開発では `node bin/skills.ts validate-linear-config <file>` を使える。CLIは指定された一つのJSONを読み、同梱schemaで検証する。ネットワーク取得、正本探索、Git操作、入力変更、型変換、既定値の補完、未知キーの除去はしない。未知キーはroot・下位とも拒否する。成功は構造が有効なことだけを表し、許可の合意やLinearの状態・参照ファイルの存在は保証しない。
+ローカル開発では `node bin/skills.ts validate-linear-config <file>` を使える。CLIは指定された一つのJSONを読み、同梱schemaで検証する。ネットワーク取得、正本探索、Git操作、入力変更、型変換、既定値の補完、未知キーの除去はしない。未知キーはroot・下位とも拒否する。成功は構造が有効なことだけを表し、設定の合意、`constraints` の意味、Linearの状態・参照ファイルの存在は保証しない。
 
 `config_version` が欠落または旧版なら移行、未来版ならskillとCLIの更新、不正型なら設定修正を案内する。JSONコメントは使わず、運用条件は補足へ書く。`$schema` は公開npmパッケージの固定バージョンURLでエディタを補助する。CLIは外部のschemaを取得しない。
 
@@ -24,7 +22,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 ```text
 .shinaps/
   .gitignore            # 保存方式に応じた除外と共有対象の例外
-  linear.json           # 対象・工程・許可・終了地点・参照先・報告
+  linear.json           # 対象・工程・終了地点・制約・参照先・報告
   linear/
     instructions.md     # 採用する場合だけ置くプロジェクト固有の指示
     references/         # 必要な場合だけ分ける詳細資料
@@ -37,7 +35,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 - `local`: メインの作業ツリーに設定と補足を保存し、Gitの対象外とする。
 - `config_storage` と `path_policy_overrides` を含む必須項目の欠落は不正。旧設定は下の移行手順で明示的に移行する。
 
-保存方式は共有範囲の選択であり、対象・操作許可・担当・終了地点・レビュー条件を変えない。必須でない空ファイルを作らない。補足にSKILL.mdや独立した呼び出し名を置かず、READMEなどが正本の内容は参照する。
+保存方式は共有範囲の選択であり、対象・制約・担当・終了地点・レビュー条件を変えない。必須でない空ファイルを作らない。補足にSKILL.mdや独立した呼び出し名を置かず、READMEなどが正本の内容は参照する。
 
 ## 設定の読み方
 
@@ -55,12 +53,10 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 - その他の補足は内容に対応する既存の5分類へ記載し、担当する工程に必要なものを読む。参照された補足がない・読めない場合は未採用と解釈せず、依存する工程を止める。採用した `instructions.md` の欠落・読取不能は設定に依存する実行全体の開始・再開を止める。
 - `local`では従来どおり、存在する `instructions.md` を開始・再開時に読み、その他の補足は工程に必要なものを読む。既存設定への参照の自動追記はしない。
 - 採用していない任意の補足はなくてもよい。必要な補足を未採用扱いにして運用条件を減らさない。
-- 補足ファイルは追加の条件と手順を表す。設定の決定（対象・許可・終了地点・工程の対応）と、人の完了・QAの証拠の要件は変えない。補足と設定が矛盾したら、設定に従って止め、どちらを直すか確認する。
-- 不足や矛盾があれば、影響する工程の開始前に止めて一問ずつ確認する。影響しない工程は続ける。許可の追加やステータスの新設を推測で補わない。
-- 終了地点は操作の許可を兼ねない。設定は、利用中のツールの権限や利用者の明示的な停止・撤回を上書きしない。
-- 利用者と合意して保存した設定の許可は、その対象・操作・条件の範囲で、作業先リポジトリの規約がいう合意・許可に当たる。一般的な「明示依頼がある場合だけ」という条件も、この合意済みの範囲では満たすため、同じ操作の許可を改めて求めない。設定ファイルが存在することや、AIが合意なしに加えた許可は、その根拠にしない。利用者による今回の範囲限定・停止・撤回と、ツール固有の明示依頼条件は維持する。
+- 補足ファイルは追加の条件と手順を表す。設定の決定（対象・終了地点・制約・工程の対応）と、人の完了・QAの証拠の要件は変えない。補足と設定が矛盾したら、設定に従って止め、どちらを直すか確認する。
+- 不足や矛盾があれば、影響する工程の開始前に止めて一問ずつ確認する。影響しない工程は続ける。終了地点の変更・制約の緩和やステータスの新設を推測で補わない。
 
-次工程を判断するときは、`review_flow`・`permissions`・`stop_after` の条件を併せて読み、[担当と工程](workflow.md)で定めた担当と前工程の結果を確認する。一つの設定から他の許可や工程の完了を推測しない。終了・待機とゴール状態は [execution.md](execution.md) に従う。
+合意済みの設定の扱いと、操作を行うかどうか・優先順位は[依頼範囲と操作](../request-scope.md)で判断する。次工程を判断するときは、実効到達点・`review_flow`・`constraints` を併せて読み、[担当と工程](workflow.md)で定めた担当と前工程の結果を確認する。一つの設定から工程の完了を推測しない。終了・待機とゴール状態は [execution.md](execution.md) に従う。
 
 ## 項目
 
@@ -68,7 +64,7 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 | キー | 内容 |
 | --- | --- |
-| `config_version` | 整数 `2`。パッケージ版とは独立した契約版 |
+| `config_version` | 整数 `3`。パッケージ版とは独立した契約版 |
 | `$schema` | 任意のエディタ補助。固定URLは下記。CLIはこのURLを取得しない |
 | `config_storage` | `shared`（Git共有）または `local`（メインの作業ツリーだけに保存）。保存・読取規則は上記に従う |
 | `target.workspace` | Linearのworkspace |
@@ -77,13 +73,13 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `team_settings` | `existing_only`（既存の定義に合わせ、変更しない）または `manage_on_setup`（初期設定・設定変更のときだけ変更案を示し、合意後に整備できる） |
 | `statuses` | 状態キーと待ち状態の `human_input` から、実在するステータス名への対応。複数のキーに同じステータスを指定できる |
 | `stop_after` | 終了地点（下の「終了地点」） |
-| `permissions` | 継続的に許可した操作の一覧（下の「許可」）。経路の許可（auto: `claude_cli` と `claude_cli_bypass_permissions`、manual: `bridge_request`）も含む。許可なしは `[]` |
+| `constraints` | プロジェクト固有の禁止事項・条件を自然文で書いた文字列の一覧（下の「制約」）。制約なしは `[]`。空白だけの項目は不正 |
 | `references` | `specifications`・`validation`・`environments`・`deployment`・`publication` の5分類をすべて記載し、既存資料のパスまたはURLの一覧を指定する。該当資料なしは `[]` |
 | `cycle_report` | Cycle報告の設定（下の「Cycle報告」）。報告を使わない場合は `null` |
 | `review_flow` | `{ "mode": "auto" }`（AIが自然な単位を決め、独立レビュー・QA後にstage・commit）または `{ "mode": "manual" }`（AIがレビュー待ちを明示し、人がWebStormで差分を確認する。人のコミット開始依頼でAIが分割案を示し、人が単位ごとに依頼したらAIがstage・commit）、または `{ "mode": "ask" }`（着手時に進行役が人へautoかmanualかを一問で確認し、回答を同じIssueの通常flowとして使う）。開始時の値（askでは回答）で経路も決まる（下の「経路」） |
 | `path_policy_overrides` | パス別に `review_flow` を上書きするルールの一覧。例外なしは `[]`（下の「パス別の方針」） |
 
-- 利用者と合意した `review_flow` はいずれも対象のstageとAIのcommitを許可する（askは解決後のmodeに従う）。`auto` は独立レビュー後、`manual` は人がその単位のコミットを依頼した後にcommitする。未合意の設定ファイルから許可を得ない。その場の明示指示が優先し、push・公開・履歴変更は別の許可に従う。
+- 利用者と合意した `review_flow` はいずれも対象のstageとAIのcommitの進め方を決める（askは解決後のmodeに従う）。`auto` は独立レビュー後、`manual` は人がその単位のコミットを依頼した後にcommitする。未合意の設定ファイルを根拠にしない。その場の明示指示が優先し、push・公開は実効到達点、履歴の書き換えは[依頼範囲と操作](../request-scope.md)の確認する操作に従う。
 - どちらのflowもdev内の確認、必須検証、Agent QA、必要なHuman QAを維持する。`auto` は独立レビューを必須とし、利用できなければ自己確認で代用せず止める。人レビュー省略を人のレビュー済みと記録しない。
 - 状態キーは [workflow.md](workflow.md) の「工程とステータス」の表と同じ。`statuses` の値はチームに実在する正確な名前にする。操作時はLinearから取得した状態のIDを使う。対応が曖昧・欠落・実物と不一致なら、その対応に依存する更新を止める。ステータスを自動で新設しない。
 - `team_settings: manage_on_setup` の場合も、通常実行ではチーム設定を変更しない。
@@ -92,18 +88,18 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 実装・修正・コミットはClaude Codeが `shinaps:dev-claude` と `shinaps:commit` で行う（境界内のUIの微調整はCodexが行える。[担当と工程](workflow.md#codexによるuiの微調整)）。Codexとの間の経路は、着手時に通常設定の `review_flow.mode` で一つに決める。
 
-| 通常設定 | 経路 | 必要な許可 | メインのモデル |
-| --- | --- | --- | --- |
-| `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | `claude_cli`・`claude_cli_bypass_permissions` | Opus。起動とすべてのresumeで `--model opus` を指定する |
-| `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | `bridge_request` | Opusを基本とし、Issueの着手時にFableかOpusかを確認する。同じIssueの一括修正・継続・再開では選択を引き継ぐ |
-| `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路の許可 | 回答した経路のモデル |
+| 通常設定 | 経路 | メインのモデル |
+| --- | --- | --- |
+| `auto` | Codexが起動するローカルClaude CLIの同じsession（[Claude CLI](claude-cli.md)） | Opus。起動とすべてのresumeで `--model opus` を指定する |
+| `manual` | WebStorm内の対話Claude CodeセッションへBridgeで依頼する（[Bridge](bridge.md)） | Opusを基本とし、Issueの着手時にFableかOpusかを確認する。同じIssueの一括修正・継続・再開では選択を引き継ぐ |
+| `ask` | 着手時に人へ一問で確認した回答（auto・manual）の経路 | 回答した経路のモデル |
 
 - メインはdevを実行するClaude Codeのセッションを指す。担当（独立レビューを含む）のモデルは役割定義の値で、経路とは独立している。単独のdev（Linear進行を経ないdev）のメインは利用者のセッション設定のまま。メインは調査・設計・実装・指摘の採否を自分で行うので、メインのモデル（manualでFableを選べばFable）がそのまま設計・実装のモデルになる。
 - manualの対話セッションのモデルは、人が `/model` で切り替える。Claudeへのプロンプトや Bridge のメッセージでは切り替えられない（[model-config](https://code.claude.com/docs/en/model-config)）。
 - manualで基本（Opus）と違う選択なら、Codexが人へ切り替えを依頼する。Codexは人の報告を記録し、実際のモデルを照合できたとは扱わない。
 
-- `ask` では、進行役がClaudeへ依頼する前に、Issueの作業内容と推奨する経路の理由を添えてautoかmanualかを一問で確認し、回答まで着手しない。回答・Issue・作業先・設定・選んだ経路を作業記録に残し、同じIssueの修正・再開・QA・差分確定では再質問せず記録した選択を使う。同じIssueに明示的な既存の選択があれば再質問しない。Cycle全体・バックログ消化でもIssueごとに選ぶ。設定の `ask` は書き換えない。選択は他の許可を増やさず、選んだ経路の許可を確認する。
-- 経路はIssueの途中で切り替えない。`permissions`・`stop_after`・`dev_delegation`・worktreeや別セッションの作成の許可は、経路によって変わらない。
+- `ask` では、進行役がClaudeへ依頼する前に、Issueの作業内容と推奨する経路の理由を添えてautoかmanualかを一問で確認し、回答まで着手しない。回答・Issue・作業先・設定・選んだ経路を作業記録に残し、同じIssueの修正・再開・QA・差分確定では再質問せず記録した選択を使う。同じIssueに明示的な既存の選択があれば再質問しない。Cycle全体・バックログ消化でもIssueごとに選ぶ。設定の `ask` は書き換えない。選択は依頼範囲を広げない。
+- 経路はIssueの途中で切り替えない。実効到達点・`constraints`・委託やworktreeの扱いは、経路によって変わらない。
 - manual経路でパス別の方針によりauto単位が生じた場合は、人のコミット開始依頼の後、対話session内のClaudeがその単位を単位ごとの依頼なしに独立レビュー後にcommitし、人のレビューの省略を記録する。
 - auto経路でmanual単位が生じた場合、非対話CLIは人との相談・コミットの依頼を扱えない。CodexはLocal Agent QAで判定記録を照合した時点で検出し、差分確定の依頼前に人へ一問で確認する: 「今回の明示指示でその単位をautoとして進める」か「Issueを中止し、未コミット差分を保全したまま設定（通常設定またはルール）を見直してから、manual経路でやり直す（通常設定がaskなら `ask` は書き換えず、この回答を同じIssueの以前の選択に代わる選択として作業記録へ残す）」か。黙ってautoへ落とさない。`commit` の中で検出した場合は手順を進めず、判定を記録してresultへ返す。
 
@@ -121,8 +117,8 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 - 上書きは `review_flow` オブジェクト全体を置換する。各ルールは空でない `paths` と `review_flow` オブジェクト だけを必須とする。パス別のmodeは `auto` か `manual` だけで、`ask` は設定不備とする。その他のキー、省略、不正値や構文は設定不備として依存工程を止める。
 - 通常設定が `ask` の場合は、着手時に解決したmodeを通常方針として使い、パス例外は同じ規則で適用する。
-- パス別のflowもstageとcommit担当を上記のとおり決める。push・公開・終了地点・ツール権限・必要なQAは変更しない。経路はパス例外では切り替えず、単位のmodeと経路が異なる場合は上の「経路」に従う。
-- パス設定への合意は対象と工程の許可であり、変更内容に含まれる未合意仕様や権限拡張への承認ではない。内容や拡張子から例外許可を推定しない。
+- パス別のflowもstageとcommit担当を上記のとおり決める。push・公開・終了地点・制約・ツール権限・必要なQAは変更しない。経路はパス例外では切り替えず、単位のmodeと経路が異なる場合は上の「経路」に従う。
+- パス設定への合意は対象と工程の合意であり、変更内容に含まれる未合意仕様や権限拡張への承認ではない。内容や拡張子から例外を推定しない。
 
 ### パターンとコミット全体の照合
 
@@ -138,27 +134,29 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 
 各予定単位について、設定の正本と内容、適用した全ルール（または適用なしの理由）、単位の比較元と全差分、実効 `review_flow`（通常設定が `ask` でも解決後の `auto` か `manual`）、今回の明示指示とflowの合意根拠、検証・レビューの結果を記録する。manualの単位は依頼記録（コミットの依頼発話の要約・stage時のtree hash・作成したSHA）も残す。差分の同一性はパスだけでなく内容・mode等も含めて確認する。Linear進行での担当間の引き渡しは [workflow.md](workflow.md)、コミット前後の単位照合と完了時の全体照合は `commit` に従う。
 
-予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・許可確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。manualで人の修正・依頼を経てcommitした場合は `commit` に従い、commit後に目的・範囲・実効flowと影響する挙動を確認する。正当な修正は元の予定との差と対応を残して確定単位へ反映する。不明・対象外の変更、確定単位との不一致は停止し、履歴を無断で書き換えない。
-
-### config_version 1 からの移行
-
-0.33.0から `config_version: 1`、`implementation_skill`、`review_flow.tool`、許可の `codex_task`・`managed_session:*` は受け付けない。Codex実装タスク・Managedセッションの経路はなくなるため、次の順で展開する。
+予定単位の内容・分割・統合を変更したら、変更した単位を再判定して必要なレビュー・確認・検証へ戻す。設定変更時も影響する未実行単位を再判定する。以前の判定や別単位の方針は流用しない。manualで人の修正・依頼を経てcommitした場合は `commit` に従い、commit後に目的・範囲・実効flowと影響する挙動を確認する。正当な修正は元の予定との差と対応を残して確定単位へ反映する。不明・対象外の変更、確定単位との不一致は停止し、履歴を無断で書き換えない。
 
-1. 進行中Issueを棚卸しする（Codex実装タスク・Managedセッション上の未取り込み差分、Coding・QA中のIssue）。
-2. 各Issueを、旧版のまま終了地点まで進めるか、差分を作業先へ取り込んで実装工程からClaudeへ引き継ぐかに分ける。
-3. 0.33.0を公開し、各端末のpluginとCLIを更新する。
-4. リポジトリごとに下の手順で設定と補足を移行し、CLIで検証する。
-5. 進行中Issueを再開する。
+## 旧設定の移行
 
-`linear-plan` は各リポジトリで以下を行い、検証・保存を完了してから再開する。CLIは移行しない。
+0.48.0から `config_version: 3` だけを受理する。v2以前の設定（`.shinaps/linear.json` のv2・v1、旧 `.shinaps/linear.yaml`、scalar `review_flow`）は、CLIが移行案内付きで拒否する。CLIは移行しない。`linear-plan` が各リポジトリで、利用者の一度の確認を経て次の順で移行し、検証・保存を完了してから依頼を再開する。他のリポジトリの設定は、そのリポジトリの依頼として個別に移行する。
 
-1. 現在の設定・許可・補足・進行中Issueを確認する。
-2. `config_version: 2` にし、`implementation_skill`、`review_flow.tool`、`path_policy_overrides[].review_flow.tool` を削除する。
-3. `permissions` から `codex_task`・`managed_session:*` を削除する。経路の許可（通常設定がautoなら `claude_cli` と `claude_cli_bypass_permissions`、manualなら `bridge_request`）は、そのリポジトリの利用者と合意して明示的に追加する。既存の `bridge_request` は、任意の引き渡しに加えてmanual経路の依頼も表すようになるため、残すかを確認する。他の許可は増やさない。
-4. `statuses` は変更しない。補足からCodex実装タスク・Managed・tool・人がコミットする条件の記述とそれらの資料へのリンクを除き、合意日付を残す。
-5. `$schema` を利用中の公開版のURLへ更新し、CLIで検証して読み戻す。
+1. 現在の設定・採用済みの補足（`instructions.md` と `references` の資料）・進行中Issue（Codex実装タスク・Managedセッション上の未取り込み差分を含む）を読む。
+2. 次の内容を引き継ぐ案を作る。
+   - 終了地点（3で利用者が変更を選んだ場合を除く）・`review_flow`・パス別の方針・`config_storage`・`target`・`team_settings`・`statuses`・`references`・`cycle_report` は変えない。
+   - 補足やプロジェクトの資料に書かれた明示的な制約・運用条件は、元の場所に残して引き続き適用する。ただし旧版で廃止した経路（Codex実装タスク・Managedセッション・`review_flow.tool`・人がコミットする条件）の記述とその資料へのリンクは除き、補足に記録された合意の日付は残す。
+   - 旧版だけのキーを除く: `permissions`、`implementation_skill`、`review_flow.tool`、`path_policy_overrides[].review_flow.tool`、`human_code_review`、`commit_mode`、`document_only_changes`、パス別のai_commit。旧 `document_only_changes: none` は例外なしとして `path_policy_overrides: []` にする。旧ai_commitは具体的なパスへの移行か廃止を合意し、暗黙に変換しない。
+   - 旧 `permissions` に無かった操作を禁止事項へ機械的に変換しない。
+3. 引き継ぐ内容と新方式の影響を示し、禁止事項を一度だけ確認する。影響には次を含める。
+   - 終了地点までの通常操作が、操作ごとの確認なしに進むこと（[依頼範囲と操作](../request-scope.md)）。
+   - 旧一覧に無かったため、今後は確認なしになる操作（例: 終了地点が `issue_done` で旧一覧に `merge` が無かった場合のマージ）。
+   - 旧 `deploy:`・`publish:`・`evidence:` の先がどの資料に書かれているか。書かれていない先は今後も確認する操作になる。
+   - 引き続き確認する操作（[確認する操作](../request-scope.md#確認する操作)）。実利用者のデータへの破壊的でない操作は、制約に書かなければ確認なしになる。
+   - auto経路の `bypassPermissions` への個別の同意項目がなくなること。実行環境側の制限はそのまま適用される。
 
-旧 `.shinaps/linear.yaml` とscalar `review_flow`（0.32.0より前）も同じ手順でv2のJSONへ移す。YAMLコメントの運用条件は `instructions.md` または対応する参照資料へ移す。旧 `human_code_review`・`commit_mode`・permissionsのstage/commit・`document_only_changes`・パス別ai_commitは除去し、旧noneは例外なし、旧ai_commitは具体的パスへの移行または廃止を合意して暗黙変換しない。保存後に旧YAMLを除き、ignore・参照・共有対象も更新する。追跡解除・stage・commitは既存の許可と安全手順に従う。
+   選択肢は「提示どおり移行する（`constraints: []`）」と「禁止事項を加えて移行する（自由入力の自然文）」にする。加える禁止事項が終了地点と矛盾する場合（例: `issue_done` で「マージしない」）は、同じ確認の中で終了地点の変更案（例: `pr_created`）も示す。
+4. 回答どおりに `config_version: 3` と `constraints`（終了地点を変えると回答した場合は `stop_after` も）を書き、旧版だけのキーを除き、`$schema` を利用中の公開版のURLへ更新する。CLIで検証して読み戻す。確認の内容と回答は作業記録と、関係するIssueがあればそのコメントに残す。保存したv3の設定があれば、同じ内容を再確認しない。
+5. 旧YAMLからの移行では、YAMLコメントの運用条件を `instructions.md` または対応する参照資料へ移し、保存後に旧YAMLを除いてignore・参照・共有対象も更新する。追跡解除・stage・commitは依頼範囲と安全手順に従う。
+6. 進行中のIssueは、移行後に設定と実効到達点を読み直して再開する。未取り込み差分があるIssueは、差分を作業先へ取り込んでから実装工程として再開する。
 
 ## 終了地点
 
@@ -167,35 +165,20 @@ shinaps-skills validate-linear-config /absolute/repository/.shinaps/linear.json
 | `stop_after` | 止まる地点 |
 | --- | --- |
 | `pre_push_qa` | 差分確定を終えた後、公開確認でpush前の最終Agent QAが合格し、記録した時点 |
-| `pr_created` | 必須の検証と許可されたpush・PR作成を終え、IssueとPRの相互リンクを確認した時点。Staging QAが未実施なら残項目として記録する |
+| `pr_created` | 必須の検証とpush・PR作成を終え、IssueとPRの相互リンクを確認した時点。Staging QAが未実施なら残項目として記録する |
 | `issue_done` | Issueの必須受入条件をすべて満たし、Doneにした時点 |
 
 - 終了地点の工程がそのIssueにない場合（Git変更がない作業など）の扱いは、[workflow.md](workflow.md) の「工程とステータス」に従う。
-- 終了地点は到達点だけを決める。stage・commitは合意済み `review_flow`、その他の操作は `permissions` が決める。許可のない操作（例 `merge`）がある場合は、その操作の前で許可を確認する。これは許可待ちであり、終了地点への到達ではない。Cycle全体を任された場合も、許可待ちのIssueは終了地点に達したものとして扱わない。
+- Linear進行の一般的な依頼では、終了地点が実効到達点になる。そこまでの操作の判断は[依頼範囲と操作](../request-scope.md)に従い、stage・commitの進め方は合意済み `review_flow` に従う。確認待ちは終了地点への到達ではない。Cycle全体を任された場合も、確認待ちのIssueは終了地点に達したものとして扱わない。
 
-## 許可
+## 制約
 
-| 値 | 許可する操作 |
-| --- | --- |
-| `issue_update` | 対象のteam・projectの中で、利用者が任せたIssue・Cycleの範囲に対する運用上の更新（本文・コメント・状態・依存・Linearへの添付、整理で必要になったIssueの作成・分割）と、利用者から任された目的の作業を着手前にIssueへ紐づけるための作成（[issue.md](issue.md) の「着手前に作業をIssueへ紐づける」）。チーム設定の変更、未合意の範囲・期限の変更、Cycle外への進行、Issueの削除、外部への送信を含めない |
-| `development_operations` | 任された対象の開発に必要な、既存アカウントへの通常のログイン、ローカル環境準備、プロジェクトの依存導入、開発サーバー・Simulatorの起動停止、ビルド・テスト・QA操作を継続的に許可する。下の範囲に従う |
-| `claude_cli` | auto経路で、Codexが行うClaudeのローカルCLI起動、同じsessionの状態・結果取得、質問への回答・修正・許可済みコミットのresume。メインのモデル（[経路](#経路)）と権限モードの指定のほかは既存CLI設定を保持する（[手順](claude-cli.md)）。bypassPermissionsでの起動への同意は含まない |
-| `claude_cli_bypass_permissions` | auto経路のClaudeのローカルCLIを、起動と同じsessionのすべてのresumeで `--permission-mode bypassPermissions` にすることへの、利用者の継続的な同意。CLIの権限チェックを省くだけで、操作の許可を追加しない。Claudeの操作は依頼の範囲と他の許可・合意済みの `review_flow` に限る（[手順](claude-cli.md#操作権限)） |
-| `bridge_request` | manual経路で、CodexがBridgeで対話Claude Codeセッションへ行う依頼と報告の受け取り、および別会話との任意の進行の引き渡し。報告は照合材料であり、操作許可を変更しない（[手順](bridge.md)） |
-| `push` | 対象Issueの作業ブランチの通常のpush |
-| `pr_create` | 対象IssueのPRの作成と更新 |
-| `merge` | 必要なQA・承認が揃った対象PRのマージと、元のブランチへ戻る操作 |
-| `deploy:<環境>` | 指定した環境への配備・配布（例 `deploy:staging`） |
-| `publish:<操作>` | 一般公開やストアへの提出など、指定した公開操作（例 `publish:app_store_submit`） |
-| `dev_delegation` | `shinaps:dev-claude` の中で、サブエージェントへ委託する。許可がない場合、入口のメインは担当の作業を代わりに行わず、必要な許可を求める。worktreeの作成は含まない |
-| `evidence:<保存先>` | Linear以外の指定した保存先へQA素材を保存する（LinearのIssueへの添付は `issue_update` に含む） |
-
-- 開発進行には `issue_update` と、[経路](#経路)の許可が必要（auto: `claude_cli`・`claude_cli_bypass_permissions` とローカルClaude CLI、manual: `bridge_request` と、Bridge MCP・WebStorm内の対話Claude Codeセッション。ask: 着手時に選んだ経路の許可）。今回の明示依頼による同じ経路の許可も引き継ぐ。初期設定は `issue_update`・経路の許可（askでは選択肢にする両経路の許可）・`dev_delegation` と `review_flow` を具体的に提案し、合意を得る。設定の存在だけでは許可を得ない。
-- `development_operations` は、既存の認証手段と利用者が許可した既存アカウントを使い、対象の開発・検証環境と専用の検証データで行う操作に限る。本人の二要素認証・セキュリティキー・CAPTCHA等が必要なら具体的に依頼し、回避しない。ログイン成功を新しい権限への同意と扱わず、新規アカウント・OAuth権限の拡大・課金・新規クラウド資源・共有環境への破壊的変更・実利用者データの操作は含めない。秘密値をIssueや証拠へ記載しない。
-- この包括許可は `stage`・`commit`・`push`・`pr_create`・`merge`・`deploy:*`・`publish:*`・外部への送信・履歴やデータの破壊的操作を含まない。テストや環境準備がこれらを伴うときも、stage・commitは合意済みflow、その他はそれぞれの許可が必要。人レビュー・Human QA・ツール側の承認条件を省略しない。`permissions` に明示された場合だけ適用し、既存設定に自動で追加しない。
-- 一つの操作が別の操作を伴う場合は、伴う操作の許可も必要とする（マージで本番へ自動配備される場合は `merge` と `deploy:production`）。
-- 次の操作は一覧に含めず、常にその場で確認する: force-push、履歴の書き換え、ブランチの削除、チーム設定の変更。
-- 設定の許可は、今回の依頼で任されたIssue・Cycleの範囲を広げない。
+`constraints` には、そのプロジェクトで行わないこと・守る条件を、利用者と合意した自然文で一項目ずつ書く（例: 「本番環境へは配備しない」「共有のstaging DBは読み取りだけにする」）。操作名の一覧や独自の書式は使わない。制約がなければ `[]` と明示する。
+
+- 意味の判断はスキルが[依頼範囲と操作](../request-scope.md#照合する制約)に従って行う。CLIは文字列の一覧であることと空白だけの項目がないことだけを検証する。
+- 補足やプロジェクトの資料に書かれた明示的な制約も同じように照合する。`constraints` へ写すことは必須にしない。
+- `constraints` の欠落は「制約なし」と補わず、設定不備として止める。
+- 制約の追加・変更・削除は[設定変更](#設定変更)として利用者と合意する。今回だけの例外は保存済みの制約を変えない。
 
 ## Cycle報告
 
@@ -217,8 +200,8 @@ manualの設定例。同じprojectを複数のリポジトリがそれぞれの
 
 ```json
 {
-  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
-  "config_version": 2,
+  "$schema": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.48.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
+  "config_version": 3,
   "config_storage": "shared",
   "target": {
     "workspace": "your-workspace",
@@ -243,11 +226,8 @@ manualの設定例。同じprojectを複数のリポジトリがそれぞれの
   },
   "path_policy_overrides": [],
   "cycle_report": null,
-  "permissions": [
-    "development_operations",
-    "issue_update",
-    "bridge_request",
-    "dev_delegation"
+  "constraints": [
+    "本番環境へは配備しない"
   ],
   "references": {
     "specifications": [
@@ -266,28 +246,28 @@ manualの設定例。同じprojectを複数のリポジトリがそれぞれの
 
 この例では `instructions.md` と `qa.md` を採用して一緒に共有する。実際に必要な補足だけを選び、例に合わせた空ファイルは作らない。
 
-この例は `stop_after: pre_push_qa` なので、`post_commit` より後の工程の対応を書いていない。
+この例は `stop_after: pre_push_qa` なので、`post_commit` より後の工程の対応を書いていない。`constraints` の項目は架空の例で、制約がなければ `[]` にする。
 
 ## 初期設定
 
 依頼の実行に設定が必要で、「設定の読み方」により両方が真に不在と確認できた場合だけ、同じセッションで `linear-plan` の以下の手順を開始する。共有設定の欠落・不備をlocal設定の新規作成で補わない。初期設定の案内やスキルの再実行依頼だけで止めない。設定なしでできる相談・読み取り・明示依頼されたIssue整理には、初期設定を必須にしない。
 
-Claudeもこの手順で初期設定を行える。合意した設定の保存・確認後は元の依頼へ戻る。設定作成は元の依頼の実行範囲や担当、操作許可を増やさず、開発の進行役も変更しない。
+Claudeもこの手順で初期設定を行える。合意した設定の保存・確認後は元の依頼へ戻る。設定作成は元の依頼範囲や担当を広げず、開発の進行役も変更しない。
 
 1. アカウント、workspace、team、projectと、チームのステータス一覧・既存の運用をLinearから読む。
 2. 作業先リポジトリのAGENTS.md・CLAUDE.md・README・CI・検証や配備のスクリプトを読み、`references` の候補を決める。
 3. 設定案を一つ作る。チーム設定を管理できる場合だけ、FamilyStayを基にした工程の分離（[workflow.md](workflow.md) の工程表に対応するステータス）を変更案として示す。利用者のプロジェクトらしいという推測で `manage_on_setup` にしない。
-4. 既存の情報で決まらない運用上の決定（`config_storage`、`stop_after`、`permissions`、`review_flow`、`team_settings`、Cycle報告）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらう。パス別の例外が必要な場合は、具体的な対象パターンと上書き項目、通常設定からの変更を示して合意する。例外を使わない新規設定には `path_policy_overrides: []` を記載する。旧設定の移行は上の手順に従う。
+4. 既存の情報で決まらない運用上の決定（`config_storage`、`stop_after`、`constraints`、`review_flow`、`team_settings`、Cycle報告）だけを一問ずつ確認する。終了地点は上の一覧から選んでもらい、そこまでの通常操作が操作ごとの確認なしに進むことを添える。禁止事項は既存の資料に書かれたものを示し、追加があるかを一問で確認する。パス別の例外が必要な場合は、具体的な対象パターンと上書き項目、通常設定からの変更を示して合意する。例外を使わない新規設定には `path_policy_overrides: []` を記載する。旧設定は上の[旧設定の移行](#旧設定の移行)に従う。
 5. 合意した方式の正本へ、下の保存手順に従って保存する。sharedでは採用する補足の `references` と共有対象を照合し、別checkoutでも同じ条件を読めるようにする。同梱CLIでJSONを検証し、正本と補足を読み直して確認する。
 6. Linearのチーム設定の変更は、設定の保存とは別に扱う。対象チームと変更差分（追加・改名するステータスと順序）を示し、合意を得てから反映して読み戻す。反映後に `statuses` を実物に合わせて確定する。
 
 ## 設定変更
 
-初期設定と同じ手順で、既存の設定との差分を示して合意を得る。保存方式が未決の場合だけ `shared` / `local` を一問で確認し、すでに合意した方式は再質問しない。許可の追加を推測で補わない。
+初期設定と同じ手順で、既存の設定との差分を示して合意を得る。保存方式が未決の場合だけ `shared` / `local` を一問で確認し、すでに合意した方式は再質問しない。終了地点の変更や制約の緩和を推測で補わない。
 
 - localからsharedへ変えるときは、端末固有情報を作業記録へ分け、必要補足の参照と共有対象、ignoreの差分を示す。既存の運用条件は一緒に共有するか共有済みの資料へ移す。補足を不採用にして黙って条件を削らず、条件自体の変更は別途合意する。
 - sharedからlocalへ変えるときは、メインにファイルを保全する方法、追跡解除の対象、Git履歴に内容が残ること、他checkoutへの影響を示す。他checkoutを自動編集しない。
-- 方式の合意だけではstage・commit・push・追跡解除を許可しない。対象操作を満たす既存の許可があれば再確認せず、その範囲で行う。キーの変更、共有準備、追跡、コミット、他checkoutでの取得を区別して報告する。
+- 方式の合意だけではstage・commit・push・追跡解除を依頼したことにならない。これらは依頼範囲（[依頼範囲と操作](../request-scope.md)）に含まれる場合に再確認せず行う。キーの変更、共有準備、追跡、コミット、他checkoutでの取得を区別して報告する。
 
 ## 設定の保存とGit共有
 
@@ -314,7 +294,7 @@ sharedでは `.shinaps/.gitignore` 自身、`linear.json`、採用した補足
 
 親の `.shinaps/` が除外されている場合、ルートの `.gitignore` に `!/.shinaps/` など必要な差分を加えてから個別例外を確認する。ユーザーのグローバルignoreや `.git/info/exclude` は編集しない。必要な共有ができなければ原因を報告し、force-addで回避しない。
 
-`git check-ignore --no-index -v <対象パス>` で有効な除外規則と例外を確認し、`git ls-files -- <対象パス>` で追跡状態、`git status --short --untracked-files=all` で実際の変更を確認する。ignoreだけでは追跡済みファイルは対象外にならない。追跡解除は自動で行わず、対象・影響と許可を確認する。
+`git check-ignore --no-index -v <対象パス>` で有効な除外規則と例外を確認し、`git ls-files -- <対象パス>` で追跡状態、`git status --short --untracked-files=all` で実際の変更を確認する。ignoreだけでは追跡済みファイルは対象外にならない。追跡解除は自動で行わず、対象・影響を示して確認する。
 
 必要補足はJSONと一緒に共有するか、同じ内容を確認できる共有済み資料への参照に置き換える。元のPCだけに必要補足が残る状態は共有未完了。URLとアクセス条件も別PCで同じ運用を確認できるものにする。ignore例外やファイルの存在だけで採用の有無を決めず、共有JSONの `references` と実際の共有対象を揃える。cloneやworktreeでも、参照された補足の欠落を未採用と解釈しない。
 
@@ -324,4 +304,4 @@ sharedでは `.shinaps/.gitignore` 自身、`linear.json`、採用した補足
 
 `instructions.md` には、QA固有の注意（端末・ブラウザ・テストアカウントの取得方法への参照）、版の照合に使うコマンド、報告の文体・見せ方、関係者への依頼方法など、プロジェクト共通の条件・手順・相対パス・URLを書く。共通の手順は複製しない。端末固有の絶対パス、session/thread ID、一時的なログイン状態、進捗、QA結果は現在の `.shinaps/work/` へ記録する。秘密値はshared・localのどちらにも保存しない。
 
-委託時は保存方式、正本の所在、必要な補足・参照資料、合意済みの操作許可を渡す。CodexからClaudeへの依頼にも同じ情報を添える。
+委託時は保存方式、正本の所在、必要な補足・参照資料、実効到達点と `constraints` を渡す。CodexからClaudeへの依頼にも同じ情報を添える。

package/plugins/shinaps-claude/references/linear/configuration.schema.json

@@ -1,7 +1,7 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.39.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
-  "title": "Shinaps Linear configuration v2",
+  "$id": "https://cdn.jsdelivr.net/npm/@shinaps/skills@0.48.0/plugins/shinaps-claude/references/linear/configuration.schema.json",
+  "title": "Shinaps Linear configuration v3",
   "type": "object",
   "properties": {
     "$schema": {
@@ -9,7 +9,7 @@
     },
     "config_version": {
       "type": "integer",
-      "const": 2
+      "const": 3
     },
     "config_storage": {
       "enum": ["shared", "local"]
@@ -133,28 +133,11 @@
         "additionalProperties": false
       }
     },
-    "permissions": {
+    "constraints": {
       "type": "array",
       "items": {
-        "anyOf": [
-          {
-            "enum": [
-              "issue_update",
-              "development_operations",
-              "claude_cli",
-              "claude_cli_bypass_permissions",
-              "bridge_request",
-              "dev_delegation",
-              "push",
-              "pr_create",
-              "merge"
-            ]
-          },
-          {
-            "type": "string",
-            "pattern": "^(deploy|publish|evidence):[^\\s]+$"
-          }
-        ]
+        "type": "string",
+        "pattern": "\\S"
       }
     },
     "references": {
@@ -260,7 +243,7 @@
     "stop_after",
     "review_flow",
     "path_policy_overrides",
-    "permissions",
+    "constraints",
     "references",
     "cycle_report"
   ],

package/plugins/shinaps-claude/references/linear/cycle-report.md

@@ -1,6 +1,6 @@
 # Cycle完了QAと成果報告
 
-Codexが実行する。Cycle全体を任され、報告まで許可されている場合は、報告用Issue以外の対象Issue（文書・運用のIssueを含む）がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定が `cycle_report: null` なら報告を行わない。報告を依頼された場合は設定変更を先に行う。設定の不足・不正値は [configuration.md](configuration.md) に従って確認する。
+Codexが実行する。Cycle全体を任され、報告まで依頼されている場合は、報告用Issue以外の対象Issue（文書・運用のIssueを含む）がすべてDoneであることを確認して続ける。Issue単位の依頼では自動で開始せず、全件完了を案内する。報告だけを明示的に依頼された場合も開始できる。設定が `cycle_report: null` なら報告を行わない。報告を依頼された場合は設定変更を先に行う。設定の不足・不正値は [configuration.md](configuration.md) に従って確認する。
 
 対象のCycle IDとIssue一覧を記録する。日付の到来・自動繰り越し・Cycleの移動・取消を、全件完了の根拠にしない。取消・持ち越し・対象外への変更は、成果と区別して記録する。履歴を取得できない場合は不明と書く。
 

package/plugins/shinaps-claude/references/linear/execution.md

@@ -1,6 +1,6 @@
 # 実行範囲とゴール
 
-実行範囲は今回の依頼で決める。JSON設定は担当・QA・レビュー・操作許可・終了地点を決めるもので、実行範囲の既定値を持たない。
+実行範囲は今回の依頼で決める。JSON設定は担当・QA・レビュー・終了地点・制約を決めるもので、実行範囲（Issue単体・Cycle全体・バックログ消化と対象）の既定値を持たない。操作を行うかどうかは[依頼範囲と操作](../request-scope.md)で判断する。
 
 | モード | 対象 | 終了条件 |
 | --- | --- | --- |
@@ -14,15 +14,15 @@
 
 対象一覧は最後のページまで読み、作業先・依存・状態・優先順位を確認する。対象IDの一覧、依存順の実行順、開始時点、終了条件を既存の親Issue・依頼元Issueのコメントまたはローカル作業記録へ残す。記録のためだけに親Issueを新設しない。後から追加されたIssue、別Cycle、対象外の依存Issueを自動で取り込まない。順序を変える必要がある場合は理由を記録し、範囲の変更は利用者と合意する。
 
-作業先リポジトリは、Issue本文に記載した作業先のリポジトリ名（共通テンプレートでは「実装方針」）で特定する。Issueがまだない作業では依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、利用できるセッションの一覧、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。各Issueの作業先の設定・補足を読み、担当と許可を引き継ぐ。操作の許可は作業先リポジトリの設定で決め、同じLinear projectに属するだけでは別のリポジトリの作業を含めない。設定がない・不足する対象は、他のリポジトリの設定で実行せず、開発進行を始めない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
+作業先リポジトリは、Issue本文に記載した作業先のリポジトリ名（共通テンプレートでは「実装方針」）で特定する。Issueがまだない作業では依頼の内容で特定する。ローカルの場所は、自分の作業ディレクトリ、利用できるセッションの一覧、利用者の指示から確認し、確定できなければ一問確認する。ローカルの絶対パスをIssueに書かない。各Issueの作業先の設定・補足を読み、担当・終了地点・制約を引き継ぐ。これらは作業先リポジトリの設定で決め、同じLinear projectに属するだけでは別のリポジトリの作業を含めない。設定がない・不足する対象は、他のリポジトリの設定で実行せず、開発進行を始めない。バックログで開始時から進められない場合も、その理由を報告し、独断で対象を除外して消化済みにしない。
 
-「このIssueを進めて」などの一般的な進行依頼では、設定の `stop_after` を到達点として記録する。Doneより手前という理由だけで再確認しない。具体的に指定された到達点と設定が矛盾する場合だけ、開始前に相違を解消する。途中の終了地点への到達を、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。操作許可を暗黙に増やさない。
+「このIssueを進めて」などの一般的な進行依頼では、設定の `stop_after` を実効到達点として記録し、そこまでの通常操作を操作ごとの確認なしに進める。Doneより手前・マージや公開を含むという理由だけで再確認しない。「プランまで」「PR作成まで」など今回具体的に指定された到達点・停止・撤回は設定より優先し、その到達点で止まる。指定が曖昧で設定と食い違う解釈が残る場合だけ、開始前に一問で解消する。途中の終了地点への到達を、Issue全体の完了とは報告しない。Cycle完了報告を含む依頼で `cycle_report: null` の場合も、設定変更か報告なしの範囲を利用者と合意してから進む。依頼範囲を暗黙に広げない。
 
 ## Issue開始時の実装体制
 
-進行役は各Issueの設定・受入条件・関連範囲・既存検証・リスクを短く確認し、体制判断の材料として必須検証・許可範囲とともにClaudeへ渡す。体制は[体制の選択](../dev/staffing.md)に従って確認して渡す。範囲全体の指定があれば引き継ぎ、無ければIssueごとに確認する。追加の担当（BASIC・ULTRA）は、Claudeのメインが材料と現物から設計の前に決め、進行役へ報告する。
+進行役は各Issueの設定・受入条件・関連範囲・既存検証・リスクを短く確認し、体制判断の材料として必須検証・依頼範囲・制約とともにClaudeへ渡す。体制は[体制の選択](../dev/staffing.md)に従って確認して渡す。範囲全体の指定があれば引き継ぎ、無ければIssueごとに確認する。追加の担当（BASIC・ULTRA）は、Claudeのメインが材料と現物から設計の前に決め、進行役へ報告する。
 
-Claudeのメインは途中の新しい根拠で必要な担当を増やし（BASIC・ULTRA。LITEは体制の変更を相談する）、進行役へ報告する。追加担当の確認が必要な工程は結果が揃うまで完了にしない。追加の担当・増員は人の承認待ちにせず、仕様・範囲・許可・予算の変更だけ確認する。
+Claudeのメインは途中の新しい根拠で必要な担当を増やし（BASIC・ULTRA。LITEは体制の変更を相談する）、進行役へ報告する。追加担当の確認が必要な工程は結果が揃うまで完了にしない。追加の担当・増員は人の承認待ちにせず、仕様・範囲・制約・予算の変更だけ確認する。
 
 ## 継続と待機
 
@@ -30,8 +30,8 @@ Claudeのメインは途中の新しい根拠で必要な担当を増やし（BA
 
 - 実装担当の作業中や、manualの人のレビュー・コミットの依頼・Human QA・本人認証・通常の承認待ちは必要な工程として扱い、必要な依頼を行って会話側のゴールを `active` のまま待機する。回答や通知がないこと、待ち時間だけでは、終了条件・ブロッカー到達・障害・承認・完了のいずれとも扱わず、新しいsession・CLI・ゴールを作る根拠にもしない。
 - Claudeの作業中は、経路ごとの通知を待つ。manualはBridgeで届くClaudeの報告の通知、autoは実行ツールが知らせるCLIのprocess終了の通知を待つ。autoで通知を受け取れない場合だけ、[Claude CLI](claude-cli.md) の「起動と観測」の間隔と対象で同じprocessの終了を確認する。manualで通知を受け取れない場合は [Bridge](bridge.md) の「競合の回避と待機」に従う。切断、processや対象セッションの消失、異常終了、エラー出力など異常の根拠がある場合は、経路の資料に従って調べる。
-- QAで見つけた不具合は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
-- 未決の仕様判断、許可不足、対象外の依存、外部障害など、現在の許可と対象内では解消できない進行不能をブロッカーとする。
+- QAで見つけた不具合は[共通ルール](workflow.md#失敗確認停止の共通ルール)に従って実装担当へ戻し、再検証する。テストの失敗だけでバックログ実行を打ち切らない。
+- 未決の仕様判断、確認する操作・制約への抵触に対する回答待ち、実行環境の拒否、対象外の依存、外部障害など、現在の依頼範囲と対象内では解消できない進行不能をブロッカーとする。
 - バックログでは最初のブロッカーで次のIssueへ進まず、到達点・未完了の対象ID・理由・必要な判断や準備・再開条件を報告して今回の実行を終了する。残Issueの状態をDoneにせず、ブロッカー自体を解決済みとは報告しない。
 - Issue単体・Cycle全体では、ブロッカー報告だけで完了にしない。必要な判断や準備を求め、再開条件を記録する。
 

package/plugins/shinaps-claude/references/linear/issue.md

@@ -10,12 +10,12 @@
 
 1. 作業先リポジトリと、紐づけ先のworkspace・team・projectを決める。紐づけ先は、[configuration.md](configuration.md) の「設定の読み方」に従って読んだ作業先リポジトリの設定の `target`、または利用者がその場で指定した先にする。
 2. 決めた先で、目的と作業先に合う既存Issue（依頼で示されたIssue、未完了のIssue、作業を含む親・関連Issue）を探し、あれば再利用する。作業が既存Issueの範囲に入る場合は、そのIssueの中の手順として扱う。
-3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、呼び出し元の `linear-plan` / `linear-execute` と [configuration.md](configuration.md) の「許可」で認められた範囲だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
+3. 該当がなければ、利用者から任された目的について、下の「共通Issueテンプレート」に従って作成する。作成は、呼び出し元の `linear-plan` / `linear-execute` の依頼範囲（[依頼範囲と操作](../request-scope.md)）の中だけで行う。新しいIssueをCycleへ入れるのは、既存の合意か明示依頼がある場合だけにする（「Cycle・期限・見積もり」）。作成の後は読み戻し、結果が不明なら現状を確かめてから再試行し（「要件を整理する手順」）、同じ目的のIssueを重ねて作らない。
 4. 使うIssueのリンクを、会話またはBridgeの依頼・報告に示してから実作業に入る。
 
-紐づけ先が決まらない、接続できない、または新しいIssueの作成が必要だがその許可がない場合は、別のworkspace・team・projectや別のリポジトリの設定で代わりに作成・更新しない。紐づけを必要とする実作業の前で止まり、理由と必要な判断・準備（作成の許可がない場合はIssue案）を利用者に伝え、回答を得てから再開する。
+紐づけ先が決まらない、接続できない、または新しいIssueの作成が必要だが依頼範囲に含まれない場合は、別のworkspace・team・projectや別のリポジトリの設定で代わりに作成・更新しない。紐づけを必要とする実作業の前で止まり、理由と必要な判断・準備（作成が依頼範囲に含まれない場合はIssue案）を利用者に伝え、回答を得てから再開する。
 
-Issueの作成・紐づけは作業の記録であり、担当・人のレビュー・終了地点・継続の範囲を変えない。コミット・push・公開・外部への送信の許可を追加せず、開発進行・Cycleの継続・ゴールの設定を始めない。
+Issueの作成・紐づけは作業の記録であり、担当・人のレビュー・終了地点・継続の範囲を変えない。コミット・push・公開・外部への送信へ依頼範囲を広げず、開発進行・Cycleの継続・ゴールの設定を始めない。
 
 ## 要件を整理する手順
 
@@ -68,5 +68,5 @@ Issueの作成・紐づけは作業の記録であり、担当・人のレビュ
 ## 書き方
 
 - 一つの欄で一つの疑問に答え、空欄や定型文で埋めず、同じ情報を複数の欄に書かない。判断の要点（採用した案と理由、未決事項）は該当する欄の本文に書き、詳細な設計は参照先に置く。途中の議論と検証の詳細はコメントへ残し、採用した結論を本文へ統合する。長いログを本文へ貼らない。
-- Issueの範囲は[共通ルール](workflow.md#失敗・許可・停止の共通ルール)のとおり目的・変更内容・受入条件から判断するので、範囲外の一覧は作らず、誤解されやすい境界だけを該当する欄に書く。
+- Issueの範囲は[共通ルール](workflow.md#失敗確認停止の共通ルール)のとおり目的・変更内容・受入条件から判断するので、範囲外の一覧は作らず、誤解されやすい境界だけを該当する欄に書く。
 - 「できるようになること」の説明に必要なら、画面はデザインやスクショ、操作や遷移は短い動画、画面のない処理は入出力の例を添える。

package/plugins/shinaps-claude/references/linear/qa.md

@@ -66,7 +66,7 @@ Codexは各工程のQA結果を、対応するIssueのコメントへ残す。
 
 - 画面を変更・検証した場合は、結果を説明できる代表スクショを記録する。遷移・入力・アニメーションなど静止画だけでは判断できない挙動は、操作と結果が分かる短い動画で示す。既存の対象版の素材を再利用できる場合は重複して撮影しない。画面を持たない変更はAPI・ログ等で示し、無関係な画像や動画を求めない。
 - 素材には画面名、対象版、環境、端末または画面幅・ブラウザ、確認した内容を添える。レビューで比較が必要な場合は、仕様・デザインや変更前の状態と対応づける。スクショだけで操作の成功を証明せず、期待結果と実際の結果も記録する。
-- 保存先は、Linearの添付、設定の `evidence:<保存先>` で許可された先、または利用者がその場で許可した先とする。Issue・QAコメント・Cycle報告から閲覧できるようにし、ローカルの一時パスだけで引き渡しを完了しない。
+- 保存先は、Linearの添付、または[依頼範囲と操作](../request-scope.md#確認する操作)で指定された先（受入条件・作業先の資料に書かれた先、利用者がその場で指定した先）とする。Issue・QAコメント・Cycle報告から閲覧できるようにし、ローカルの一時パスだけで引き渡しを完了しない。
 - 画像の表示、動画の再生、リンク先へのアクセスを確認してから、共有済みとして扱う。埋め込みが使えない場合は説明付きのリンクを使う。保存・撮影ができなければ不足と理由を記録し、取得済みとは扱わない。公開設定を緩めて共有せず、秘密値・Cookie・実利用者の情報を含まない素材を使う。
 
 ## Human QAの引き渡し