Design explicit acceptance and review of changed skill content

Bắt đầu bằng cách đọc packages/intent/src/core/source-policy.ts và packages/intent/src/core/intent-core.ts, sau đó xem lại các quyết định liên quan trong các issue #204, #220, #221, #222 và #229. Xác định quy trình review và chấp nhận, ranh giới danh tính, chẩn đoán, các cơ chế bảo vệ quyền hạn và một phần triển khai có hành vi từ chối hiển thị cùng các bài kiểm thử; được xem là hoàn tất khi các tiêu chí chấp nhận đã được đặc tả mà không bổ sung plumbing chỉ dành cho storage.

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.