arkhe-origin-chain

52 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
davidherranandClaude Opus 4.8	4485bb8683	fix(slice-4): service.rs/rpc.rs corrected (Block root + verbatim CIDP) + §11 honest finding Slice 4 checkpoint tras intentar Opción C (David: stack consistente del tag). Build verde, 213 tests, sin regresiones. Node sigue CLI+chain_spec (mods off). === Correcciones a service.rs/rpc.rs (preservadas para wire-in) === - Block root (no opaque::Block): el runtime expone impl_runtime_apis! sobre el Block root con UncheckedExtrinsic, no un opaque block separado. rpc.rs igual. - CIDP verbatim del template restaurado: standalone::slot_duration_at + inherents::InherentDataProvider::from_timestamp_and_slot_duration. AMBOS existen en sp-consensus-aura 0.45.0 PUBLICADO (verificado inherents.rs:61). Mi 'fix' v0.0.49 (Slot::from_timestamp) era incorrecto — revertido. === §11 corrige §10.2 (diagnóstico honesto) === El problema NO era API gap (las APIs existen) ni elegir bien versiones publicadas. Es estructural del ecosistema: polkadot-sdk publica sus ~15 sub-crates sc-* en cadencias distintas → NO existe isla de versiones publicadas internamente consistente que reproduzca el tag. Verificado vía sparse index: - sc-consensus-aura 0.52.0 → sp-consensus-aura ^0.44; 0.53.0/0.53.1 → ^0.45; 0.54.0 → ^0.44 (oscila entre generaciones en patches consecutivos) - sc-service 0.54.1 (versión del tag) NO publicada en crates.io El tag solo es consistente vía su Cargo.lock commiteado en el monorepo git. === Recomendación senior para David (§11.4) === Diferir node service real al setup de infra Phase 4 testnet (que necesita build env con red git de todos modos). NO seguir adivinando versiones publicadas (no convergen). Firmes: WASM export (v0.0.48) + core2 unblock (v0.0.49) + service.rs/rpc.rs correctos. Wire-in ~1 sesión cuando haya env con git fetch O un Cargo.lock del monorepo stable2509-3. Verificación: cargo check -p origin-chain-node verde (mods off) + 213 tests verde. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-05-30 11:54:32 -05:00
davidherranandClaude Opus 4.8	980bd7d961	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>	2026-05-30 11:34:06 -05:00
davidherranandClaude Opus 4.8	28408cdf73	docs(slice-4): sc-service implementation plan V1 — reference verbatim stable2509-3 Captura el plan completo de Slice 4 (full sc-service) con el service.rs VERBATIM del solochain-template polkadot-stable2509-3 (obtenido vía WebFetch sesión 4+), para ejecución mecánica próxima sesión. Razón: sesión 4+ tuvo degradación intermitente de tooling de lectura (truncation/duplicación) que hace el ciclo compile-iterate de sc-service inseguro. Disciplina "nunca shipear roto" → NO commiteo código sc-service sin poder verificar que compila. En su lugar capturo el reference exacto + prerequisitos descubiertos. Hallazgo clave (prerequisito nuevo): Slice 4 NO es un solo ship — son 4 pasos encadenados: - 4a: runtime exporta WASM_BINARY const (HOY NO lo hace — grep -c WASM_BINARY = 0). Requiere build.rs con substrate_wasm_builder + include!(OUT_DIR/wasm_binary.rs). - 4b: chain_spec → sc_service::GenericChainSpec con WASM_BINARY embebido. - 4c: service.rs + rpc.rs (núcleo sc-service wire) — verbatim capturado §3-4. - 4d: CLI inline → sc_cli::SubstrateCli + comando run. Contenido del plan: - §2 Paso 4a WASM_BINARY export + build.rs - §3 service.rs VERBATIM stable2509-3 (correcciones vs reconstrucción: standalone:: slot_duration_at + from_timestamp_and_slot_duration + warp_sync_config + import_queue 6 type params + spawn_tasks Arc::new(network) + grandpa sync Arc) - §4 rpc.rs pattern estándar (System + TransactionPayment) - §5 Paso 4b chain_spec GenericChainSpec - §6 Paso 4d CLI sc_cli migration - §7 Orden 3 ships (v0.0.47-49) + node Cargo deps exactos - §8 Risk register 7 risks + mitigaciones - §9 Reference checkout command Ejecución: 3 ships próxima sesión con tooling sano. El service.rs verbatim coincide exacto con workspace pins stable2509-3 → bajo riesgo de API drift. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-05-30 10:26:55 -05:00

Author

SHA1

Message

Date

davidherranandClaude Opus 4.8

4485bb8683

fix(slice-4): service.rs/rpc.rs corrected (Block root + verbatim CIDP) + §11 honest finding

Slice 4 checkpoint tras intentar Opción C (David: stack consistente del tag).
Build verde, 213 tests, sin regresiones. Node sigue CLI+chain_spec (mods off).

=== Correcciones a service.rs/rpc.rs (preservadas para wire-in) ===
- Block root (no opaque::Block): el runtime expone impl_runtime_apis! sobre el
  Block root con UncheckedExtrinsic, no un opaque block separado. rpc.rs igual.
- CIDP verbatim del template restaurado: standalone::slot_duration_at +
  inherents::InherentDataProvider::from_timestamp_and_slot_duration. AMBOS existen
  en sp-consensus-aura 0.45.0 PUBLICADO (verificado inherents.rs:61). Mi 'fix'
  v0.0.49 (Slot::from_timestamp) era incorrecto — revertido.

=== §11 corrige §10.2 (diagnóstico honesto) ===
El problema NO era API gap (las APIs existen) ni elegir bien versiones publicadas.
Es estructural del ecosistema: polkadot-sdk publica sus ~15 sub-crates sc-* en
cadencias distintas → NO existe isla de versiones publicadas internamente
consistente que reproduzca el tag. Verificado vía sparse index:
- sc-consensus-aura 0.52.0 → sp-consensus-aura ^0.44; 0.53.0/0.53.1 → ^0.45;
  0.54.0 → ^0.44 (oscila entre generaciones en patches consecutivos)
- sc-service 0.54.1 (versión del tag) NO publicada en crates.io
El tag solo es consistente vía su Cargo.lock commiteado en el monorepo git.

=== Recomendación senior para David (§11.4) ===
Diferir node service real al setup de infra Phase 4 testnet (que necesita build
env con red git de todos modos). NO seguir adivinando versiones publicadas (no
convergen). Firmes: WASM export (v0.0.48) + core2 unblock (v0.0.49) +
service.rs/rpc.rs correctos. Wire-in ~1 sesión cuando haya env con git fetch
O un Cargo.lock del monorepo stable2509-3.

Verificación: cargo check -p origin-chain-node verde (mods off) + 213 tests verde.

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

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

2026-05-30 11:54:32 -05:00

davidherranandClaude Opus 4.8

980bd7d961

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>

2026-05-30 11:34:06 -05:00

davidherranandClaude Opus 4.8

28408cdf73

docs(slice-4): sc-service implementation plan V1 — reference verbatim stable2509-3

Captura el plan completo de Slice 4 (full sc-service) con el service.rs VERBATIM
del solochain-template polkadot-stable2509-3 (obtenido vía WebFetch sesión 4+),
para ejecución mecánica próxima sesión.

Razón: sesión 4+ tuvo degradación intermitente de tooling de lectura
(truncation/duplicación) que hace el ciclo compile-iterate de sc-service inseguro.
Disciplina "nunca shipear roto" → NO commiteo código sc-service sin poder verificar
que compila. En su lugar capturo el reference exacto + prerequisitos descubiertos.

Hallazgo clave (prerequisito nuevo): Slice 4 NO es un solo ship — son 4 pasos
encadenados:
- 4a: runtime exporta WASM_BINARY const (HOY NO lo hace — grep -c WASM_BINARY = 0).
  Requiere build.rs con substrate_wasm_builder + include!(OUT_DIR/wasm_binary.rs).
- 4b: chain_spec → sc_service::GenericChainSpec con WASM_BINARY embebido.
- 4c: service.rs + rpc.rs (núcleo sc-service wire) — verbatim capturado §3-4.
- 4d: CLI inline → sc_cli::SubstrateCli + comando run.

Contenido del plan:
- §2 Paso 4a WASM_BINARY export + build.rs
- §3 service.rs VERBATIM stable2509-3 (correcciones vs reconstrucción: standalone::
  slot_duration_at + from_timestamp_and_slot_duration + warp_sync_config +
  import_queue 6 type params + spawn_tasks Arc::new(network) + grandpa sync Arc)
- §4 rpc.rs pattern estándar (System + TransactionPayment)
- §5 Paso 4b chain_spec GenericChainSpec
- §6 Paso 4d CLI sc_cli migration
- §7 Orden 3 ships (v0.0.47-49) + node Cargo deps exactos
- §8 Risk register 7 risks + mitigaciones
- §9 Reference checkout command

Ejecución: 3 ships próxima sesión con tooling sano. El service.rs verbatim
coincide exacto con workspace pins stable2509-3 → bajo riesgo de API drift.

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

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

2026-05-30 10:26:55 -05:00