Design explicit acceptance and review of changed skill content

Empieza leyendo packages/intent/src/core/source-policy.ts y packages/intent/src/core/intent-core.ts; después, revisa las decisiones relacionadas en los issues #204, #220, #221, #222 y #229. Define el flujo de revisión y aceptación, los límites de identidad, los diagnósticos, las protecciones de autoridad y un tramo de implementación con un comportamiento de rechazo visible y pruebas; se considera terminado cuando los criterios de aceptación están especificados sin añadir plumbing exclusivo de almacenamiento.

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.