Skip to content

feat(m3): siembra de réplica cross-engine — IDeterministicSeeding + peer_id de Loro (CHARTER-13) - #29

Merged
montfort merged 1 commit into
mainfrom
charter/14-siembra-cross-engine
Jul 18, 2026
Merged

feat(m3): siembra de réplica cross-engine — IDeterministicSeeding + peer_id de Loro (CHARTER-13)#29
montfort merged 1 commit into
mainfrom
charter/14-siembra-cross-engine

Conversation

@montfort

Copy link
Copy Markdown
Contributor

Segundo de tres Charters que vacían el backlog antes del publish (T060). Cierra FU-016: promueve la siembra de identidad de réplica de capacidad concreta de YrsEngine (CHARTER-09) a capacidad cross-engine, y añade el equivalente de Loro. Backlog: 3 open → 2 (FU-010 → CHARTER-14; FU-015 → bloqueado upstream).

Esfuerzo S, no el M del registro: las incógnitas que lo justificaban (API de set_peer_id, default de record_timestamp) se resolvieron verificándolas en las fuentes de loro 1.13.6 antes de escribir código.

La investigación descartó dos premisas del follow-up

El «gate Loro↔referencia» no es construible. loro-crdt de npm es un build wasm del mismo core Rust; compararlo con nuestro loro nativo es tautológico. El gate yrs↔Yjs es significativo porque Yjs y yrs son implementaciones genuinamente independientes; Loro no tiene contraparte. Se implementa un gate de auto-determinismo (cross-run/cross-RID con peer_id fijo) — testigo de regresión, no prueba de paridad, documentado como tal en golden-loro.json y el test.

Un CreateDoc(ulong) en ICrdtEngine filtraría la abstracción. Por la asimetría de dominios (yrs < 2^53; Loro todo u64 salvo MAX, verificado en loro-internal/src/loro.rs:184), un método único no puede contratar su dominio válido sin forzar al llamador a ramificar por motor — la fuga que P-IV existe para evitar. Se usa una capacidad opcional IDeterministicSeeding que hace del dominio parte del contrato (MaxReplicaIdExclusive), espejando NativeVersioning → INativeVersioning?.

Cambios

  • Shim de Loro: weft_loro_doc_new_with_peer_id con guard de u64::MAX en la frontera, catch_unwind, ABI v2→v3. mem_asan.rs cubre la función nueva (camino feliz + valor reservado + out nulo).
  • .NET: IDeterministicSeeding + ICrdtEngine.DeterministicSeeding + Yrs/Loro seeding + binding + resolver v3. TrackingEngine de los tests actualizado.
  • Gate: golden-loro.json + Loro_seeded_export_matches_golden (ascii + unicode) + estabilidad cross-run. record_timestamp=false verificado en loro 1.13.6 — sin él el gate sería imposible; se confía en el default con el golden como red de seguridad (R3, decisión documentada en el AILOG).
  • El relay/broker NO se tocan: sembrar peer_id es un footgun en producción (reusar un id entre escritores concurrentes corrompe el doc); documentado en el XML doc.

El pago del orden 12→13

HeaderBindingParityTests (creado en CHARTER-12) validó automáticamente la función nueva y el bump de ABI sin que lo tocara — 6/6 verde. Era exactamente la razón de hacer el 12 antes del 13.

Verificación

Check Resultado
Suite .NET 151/151 (Determinism 4→8, Versioning 36→45)
Shim Loro (cargo test) 7/7 (+ seeded_peer_id)
ASan sobre la fn nueva 0 fugas / 0 double-free
Paridad header↔binding 6/6 — valida el ABI v3 sin tocar el test
Golden yrs↔Yjs intacto (CHARTER-09 sin regresión)
straymark validate 34/34

🤖 Generated with Claude Code

…eer_id de Loro (CHARTER-13)

Cierra FU-016. Promueve la siembra de identidad de réplica de capacidad concreta
de YrsEngine (CHARTER-09) a capacidad cross-engine, y añade el equivalente de Loro.
Segundo de tres Charters del vaciado del backlog: 3 open → 2. Esfuerzo S (no el M
del registro: las incógnitas que lo justificaban se verificaron en las fuentes).

La investigación descartó dos premisas del follow-up:

- El «gate Loro↔referencia» NO es construible: loro-crdt de npm es un build wasm del
  MISMO core Rust, así que compararlo con nuestro loro nativo es tautológico. Se
  implementa un gate de AUTO-DETERMINISMO (cross-run/cross-RID con peer_id fijo),
  testigo de regresión, no prueba de paridad.
- Un CreateDoc(ulong) en ICrdtEngine filtraría la abstracción por la asimetría de
  dominios (yrs <2^53, Loro todo u64 salvo MAX). Se usa una capacidad opcional
  IDeterministicSeeding que hace del dominio parte del contrato (MaxReplicaIdExclusive),
  espejando NativeVersioning → INativeVersioning?.

Shim de Loro: weft_loro_doc_new_with_peer_id con guard de u64::MAX en la frontera,
catch_unwind, ABI v2→v3. mem_asan cubre la fn nueva. El HeaderBindingParityTests de
CHARTER-12 validó el bump de ABI y la firma nueva SIN tocarlo — el pago del orden 12→13.

.NET: IDeterministicSeeding + ICrdtEngine.DeterministicSeeding + Yrs/Loro seeding +
binding + resolver v3. Gate: golden-loro.json + Loro_seeded_export_matches_golden
(+ estabilidad cross-run). record_timestamp=false verificado en loro 1.13.6 (sin él el
gate sería imposible); se confía en el default, con el golden como red de seguridad (R3).

El relay/broker NO se tocan: sembrar peer_id es footgun en producción (documentado en
el XML doc). Verificado: 151/151 tests, ASan 0 fugas sobre la fn nueva, golden yrs↔Yjs
intacto (CHARTER-09 sin regresión).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@montfort
montfort merged commit 27c523c into main Jul 18, 2026
16 checks passed
@github-actions github-actions Bot locked and limited conversation to collaborators Jul 18, 2026
@montfort
montfort deleted the charter/14-siembra-cross-engine branch July 18, 2026 04:48
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant