Design explicit acceptance and review of changed skill content

Inizia leggendo packages/intent/src/core/source-policy.ts e packages/intent/src/core/intent-core.ts, quindi esamina le decisioni correlate nelle issue #204, #220, #221, #222 e #229. Definisci il flusso di revisione e accettazione, i confini dell’identità, la diagnostica, le protezioni dell’autorità e una porzione di implementazione con un comportamento di rifiuto visibile e test; il lavoro è completo quando i criteri di accettazione sono specificati senza aggiungere plumbing limitato allo 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.