Design explicit acceptance and review of changed skill content

まず packages/intent/src/core/source-policy.ts と packages/intent/src/core/intent-core.ts を読み、次に issue #204、#220、#221、#222、#229 の関連する決定事項を確認します。レビューと受け入れのフロー、アイデンティティの境界、診断、権限の保護、および明示的な拒否動作とテストを備えた実装スライスを定義します。受け入れ基準が、ストレージのみの plumbing を追加せずに仕様化されていれば完了です。

Problem

Current permission selects a source or skill name, not a reviewed content snapshot. An allowed skill can change without a version change and load immediately. This is documented name-based trust behavior, not a bypass of an existing content lock.

Evidence

Replacing an allowed SKILL.md body while preserving package name and version changed the content returned by loadIntentSkill on the next call.

Sources: permission matching, live content read. #204 previously explored broader accepted-state work; #220 and #221 explicitly exclude byte-level content verification.

Verified against main at 206e987 (@tanstack/intent 0.3.8), Node v24.12.0 on macOS arm64. Tests used installed dependencies and synthetic local fixtures.

Acceptance criteria

• Define the user flow for reviewing, accepting, and refusing changed content before choosing a storage format.
• Define source identity and the acceptance boundary for SKILL.md, referenced resources, scripts, new files, deletions, and path escapes.
• Specify what happens when package version stays unchanged but accepted content changes.
• Distinguish content equality, publisher provenance, and instruction safety in diagnostics and documentation.
• Define who may update acceptance state and what host/filesystem protections are required for a hard authority boundary.
• A proposed implementation slice includes visible review/refusal behavior and tests, not storage-only plumbing.

Scope and priority

Priority: High. Type: feature design.

Separate design and follow-up release, not a v0.4.0 dependency. Reuse #222 for policy explanations and #229 for command-authority work. Do not widen #221 into content drift. No hosted registry, Git sources, native delivery synchronization, or claim that a hash proves safety.