DEV Community

Nivando Soares
Nivando Soares

Posted on

Contract-Fed Scheduler Rails for the TD2 SDL Port

Contract-Fed Scheduler Rails for the TD2 SDL Port

This checkpoint closes an important bootstrap gap in the SDL port.

The runtime already had three promoted scheduler rails:

  • intro_noinput
  • menu_gameplay_entry
  • gameplay_live_race_mid

But two of them were still encoded as hardcoded C branches. That was good enough to prove the path, but not good enough to treat the rails as reusable contracts.

What changed

The non-intro rails now load from a shared contract file:

  • rom_analysis/docs/scheduler_rail_contracts.jsonc

That file carries the validated frame windows for:

  • the menu handoff corridor from 1500 -> 2050
  • the reproducible gameplay seed over 0 -> 11

So td2_scheduler no longer needs embedded anchor tables for menu/gameplay playback. The runtime still uses the callback model for intro, but menu and gameplay now come from versioned contract data.

I also tightened the scheduler smoke so it proves more than field values. It now asserts:

  • scheduler.contract_loaded
  • segment_count
  • scheduler_contract as the live state source

That pushes the smoke from 156 checks to 175, while keeping the same three rails green.

Wiki automation fix

The second part of the checkpoint is operational, but it matters.

The repo already had a post-push wrapper that rebuilt the curated docs wiki. The old safety rule was to skip the wiki auto-commit whenever the main worktree had unrelated dirty files. That avoided mixing work, but it also meant the wiki was often left stale.

The wrapper now rebuilds the wiki in a temporary isolated git worktree at the pushed checkpoint. If the generated wiki changes, the follow-up refresh commit is created and pushed from there.

That means:

  • unrelated local dirty files no longer block wiki publication
  • the wiki refresh commit stays isolated
  • local generated wiki output can be cleaned back to the pushed state afterward

Why this matters

This is still bootstrap infrastructure, not full gameplay execution. But it moves the port in the right direction:

  • runtime rails are becoming data-backed instead of branch-backed
  • validation is proving source and handoff shape, not just static values
  • the docs/wiki side is finally reliable enough to keep up with the checkpoint flow

The next step is not more rail hardcoding. The next step is mutating menu_gameplay_entry and gameplay_live_race_mid under real input on top of these contracts.

Top comments (0)