H4d: hammer compat <repo> — la búsqueda que particiona un repo contra lo instalado (SDD 15 §H4)

Responde la pregunta que arrancó §H4 ("cuando busco, ¿cuáles puedo adoptar?"): es el `filtrar`
del prototipo wawa-memo, ahora sobre el repo real y READ-ONLY (no construye ni toca nada).
Evalúa cada paquete contra el estado instalado y lo parte en {compatibles, requieren-elección,
incompatibles}, combinando la vía declarada (slots, H4b) con la observada (paths, H4c):
incompatible domina, colisión (de slot o fichero) -> elección, si no compatible.

Verificado e2e real (tests/compat_gate.rs): un repo de dos paquetes se parte correctamente
(uno choca de fichero con lo instalado -> elección; otro limpio -> compatible).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/15-frontier-ai-native.md

@@ -336,9 +336,17 @@ La definición dura de compatibilidad de una config `C` contra mi estado `E`:
     escriben `/share/logo.png`; el segundo aborta con "COLISIÓN de fichero" **y no escribe nada**;
     con `--force-slots` la elección se respeta y el fichero se escribe.
   Con H4c, un paquete **sin declarar slots** ya participa del gate por lo que de verdad toca.
-  Lo que queda abierto es **derivar la otra mitad** (los `requires` observados: de qué depende
-  el paquete) y subir el grano del path-slot a superficies más ricas (un módulo wasm de wawa,
-  un componente), además del **colapso** con el lado proceso.
+- **H4d** ✅ — **La BÚSQUEDA: `hammer compat <repo>`.** El `filtrar` del prototipo `wawa-memo`,
+  ahora sobre el repo real y **read-only** (no construye ni toca nada). Responde la pregunta que
+  arrancó §H4 — *"cuando busco, ¿cuáles puedo adoptar?"*: evalúa **cada** paquete del repo contra
+  el estado instalado y lo particiona en **{compatibles, requieren-elección, incompatibles}**,
+  combinando la vía declarada (slots, H4b) con la observada (paths, H4c) — incompatible domina,
+  colisión (de slot o de fichero) ⇒ elección, si no compatible. **Verificado e2e real**
+  (`tests/compat_gate.rs`): un repo de dos paquetes se parte correctamente (uno choca de fichero
+  con lo instalado ⇒ elección, otro limpio ⇒ compatible).
+  Lo que queda abierto: **derivar la otra mitad** (los `requires` observados: de qué depende el
+  paquete, no sólo qué escribe), subir el grano del path-slot a superficies más ricas (un módulo
+  wasm de wawa, un componente), y el **colapso** con el lado proceso.
 
 **Frontera honesta.** H4a demuestra el *álgebra* sobre hashes abstractos; lo que **no**
 resuelve es la **granularidad de los slots** — dos configs pueden no colisionar en el slot
@@ -400,7 +408,8 @@ H3a (design-doc)  ──► registrar la visión, barato
              └► H4a ✅ (config = conjunto de slots por hash: compatible/completa/segura)
                   └► H4b ✅ (slots en la receta/.swm real + gate en `hammer install`)
                        └► H4c ✅ (superficies OBSERVADAS: colisión de fichero, sin declarar slots)
-                            └► [proceso] replay del MonotonicLog  ──► plan OS-CRDT (otro agente)
+                            └► H4d ✅ (`hammer compat <repo>`: la búsqueda que particiona un repo)
+                                 └► [proceso] replay del MonotonicLog  ──► plan OS-CRDT (otro agente)
 ```
 
 Recomendación: **H1 primero** (empuja la frontera que ya tenemos, sin apuestas). **H2a** en