docs(slice-4): §10 hallazgos ejecución — core2 RESUELTO + decisión David (publicado≠tag API)

§10.1 core2 yanked unblock documentado (vendor path patch).
§10.2 finding: crates.io sc-/sp- consensus ≠ git tag API bajo misma versión.
3 opciones para David: A git consensus / B diferir node / C git todo el workspace.
Recomendación Charon: C como inversión pre-Phase-4.
§10.3 estado 4 pasos: 4a DONE, 4b/4c/4d bloqueados por §10.2.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/SLICE_4_SC_SERVICE_IMPLEMENTATION_PLAN_V1.md

@@ -606,4 +606,46 @@ El `service.rs` en §3 es verbatim de esa fuente. `rpc.rs` §4 es el pattern est
 
 ---
 
-— Charon ⚓ (Pilar 4, Slice 4 plan V1 con reference verbatim stable2509-3, sesión 4+ 2026-05-27. Ejecución 3 ships próxima sesión tooling sano.)
+---
+
+## §10 — Hallazgos de ejecución (v0.0.48 + v0.0.49, 2026-05-27)
+
+Ship 1 (v0.0.48 WASM_BINARY export) shipped limpio. Ship 2 reveló dos cosas — una resuelta, una que necesita decisión de David.
+
+### §10.1 — RESUELTO: core2 yanked (el muro de 3 sesiones)
+
+`sc-network-types 0.16.0 → cid ^0.9` (única 0.9.x = 0.9.0, yanked) `→ core2 ^0.4` (única 0.4.x = 0.4.0, yanked; las no-yanked son 0.3.x que no satisfacen `^0.4`). Cargo no auto-selecciona versiones yanked → la resolución del node fallaba. **Este era exactamente el blocker documentado en `chain_spec.rs` que difirió sc-service desde Slice 3.**
+
+**Fix aplicado (v0.0.49)**: vendorizado el `.crate` publicado de `core2 0.4.0` (yanked pero descargable de static.crates.io) en `vendor/core2-0.4.0/` + `[patch.crates-io] core2 = { path = "vendor/core2-0.4.0" }`. Una path source es seleccionable por cargo independiente del estado yanked. El git source (technocreatives/core2 master) NO sirvió — resultó ser workspace ≤0.3.x. Resuelto: core2 0.4.0 + cid 0.9.0 ya en Cargo.lock, deps del node resuelven.
+
+### §10.2 — DECISIÓN DE DAVID: crates.io consensus crates ≠ git tag API
+
+Las crates sc-/sp- **publicadas** en crates.io tienen API **distinta** al git tag `polkadot-stable2509-3` **bajo el mismo número de versión**:
+
+| Símbolo | git tag stable2509-3 | crates.io publicado |
+|---------|----------------------|---------------------|
+| slot_duration_at | `sc_consensus_aura::standalone::slot_duration_at` | `sc_consensus_aura::slot_duration_at` (root) |
+| slot inherent provider | `sp_consensus_aura::inherents::InherentDataProvider::from_timestamp_and_slot_duration` | **NO EXISTE** (`Slot` no implementa el trait; `Slot::from_timestamp` toma 1 arg) |
+
+polkadot-sdk reusa números de versión con cambios git no publicados (el mismo patrón que pallet-revive: crates.io 0.12.2 ≠ git tag 0.10.1). El `sp-consensus-aura 0.45.0` publicado **no tiene un slot InherentDataProvider en absoluto** → el patrón de node service Aura no es construible contra las crates publicadas.
+
+**Dos opciones (necesito tu decisión, David)**:
+
+- **Opción A — Migrar sc-/sp- consensus a git sources del tag stable2509-3**. Permite un node service real ahora. Riesgo: la misma cirugía duplicate-crate que golpeó pallet-revive (cargo trata git source + crates.io como crates distintos → conflictos de tipos en frame-system/sp-runtime). Mitigación: mover TODO el stack consensus (no solo aura) a git para coherencia. Scope: 1-2 sesiones cuidadosas, alto riesgo de cascada.
+
+- **Opción B — Mantener crates.io publicadas; diferir el node service real**. El node sigue siendo CLI + chain_spec builder (sin `--dev` produciendo bloques) hasta una futura generación Substrate donde las publicadas alcancen al tag. Bajo riesgo. Phase 4 testnet necesitaría node real → empuja testnet.
+
+- **Opción C — Migrar TODO el workspace a git sources `polkadot-stable2509-3`** (no solo consensus). Coherencia total tag-vs-publicado, resuelve pallet-revive vendor + este gap de una vez. Mayor scope pero elimina la clase entera de bug "publicado ≠ tag". Probable mejor inversión a largo plazo pre-mainnet.
+
+**Recomendación Charon**: Opción C como inversión pre-Phase-4, pero es decisión tuya por el scope. Mientras tanto el core2 unblock + WASM_BINARY export quedan firmes; `service.rs`/`rpc.rs` conservados como WIP (verbatim tag + 2 fixes intentados contra publicado).
+
+### §10.3 — Estado de los 4 pasos
+
+- **4a WASM_BINARY export** — ✅ DONE (v0.0.48)
+- **4b chain_spec GenericChainSpec** — ⏸ bloqueado por §10.2 (GenericChainSpec vive en sc-service stack)
+- **4c service.rs + rpc.rs** — ⏸ WIP escrito, bloqueado por §10.2 (API gap consensus)
+- **4d CLI sc_cli** — ⏸ pendiente 4b/4c
+
+---
+
+— Charon ⚓ (Pilar 4, Slice 4 plan V1 + §10 hallazgos ejecución v0.0.48-49, sesión 4+ 2026-05-27)