Controlled Desync

[flyingrobots]

Migrated from Method backlog

This issue was created from a legacy filesystem backlog card. GitHub Issues are now the live work tracker; repository docs remain Method evidence.

Source backlog: docs/method/backlog/cool-ideas/KERNEL_splash-guy-controlled-desync.md
Original lane: cool-ideas
Original legend: KERNEL

Original backlog card

Milestone: Splash Guy | Priority: P2

Status: active cool idea. Task DAG issue #224 is still live and blocks the
Splash Guy course track (#226). docs/guide/splash-guy.md and the course
shell define the lesson; no controlled-desync harness exists yet.

Controlled Desync

Issue: #224

User Story: As a learner, I want to intentionally break determinism in specific, documented ways so that I understand what goes wrong and how to detect it.

Requirements

• R1: Create 3 desync scenarios, each as a toggleable flag:
  • Scenario A: Use rand() instead of seeded PRNG for balloon fuse timer
    (nondeterministic initial state).
  • Scenario B: Deliberately bypass DFix64/F32Scalar by using raw f64
    for explosion radius (cross-platform divergence).
  • Scenario C: Process inputs in arrival order instead of canonical order
    (network ordering nondeterminism).
• R2: Each scenario has a before/after explanation documenting what went wrong and why.
• R3: The two-peer harness detects the desync via fingerprint mismatch and reports which tick diverged.
• R4: Each scenario is runnable via a CLI flag or feature toggle.

Acceptance Criteria

• AC1: Scenario A: two peers diverge within 10 ticks when rand() is used.
• AC2: Scenario B: two peers on different platforms (or with different compiler settings) produce different explosion results.
• AC3: Scenario C: two peers with different network arrival order produce different game states.
• AC4: Each scenario has a doc comment explaining the lesson learned.

Definition of Done

• Code reviewed and merged
• Tests pass (CI green)
• Documentation updated (if applicable)

Scope: 3 desync scenarios with detection and documentation.
Out of Scope: Desync recovery/repair; scenarios involving more than 2 peers.

Test Plan

• Goldens: Golden "first divergent tick" for each scenario given fixed seeds/inputs.
• Failures: Scenario flag not set — no desync (confirms the flag is necessary).
• Edges: Desync on tick 0 (Scenario A with immediate divergence); desync on the last tick only.
• Fuzz/Stress: n/a (scenarios are deterministic given the flag).

Blocked By: lockstep-protocol
Blocking: course-material

Est. Hours: 5h
Expected Complexity: ~350 LoC

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• Demo 2: Splash Guy — controlled desync lessons (make it fail on purpose) #224

🔗 Related PRs

#113 - feat(benches): PR-12 — snapshot hash microbench (Closes #43) [merged]
#240 - docs: add Demo 3 'Tumble Tower' scenario spec [merged]
#247 - M2.1: DPO concurrency litmus (spec + tests) [merged]
#309 - feat: add Doghouse PR flight recorder [merged]
#388 - docs(method): add backlog cards and hook failure note [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!