chore: simplify rollup-boost args

[0xKitsune]

This PR cleans up the CLI args structure to improve ergonomics and remove redundant logic:

• Remove the Commands subcommand and debug commands. This command seems to be redundant since the debug API is already exposed over HTTP. This also created potential inconsistencies where execution_mode could be set via CLI flags but then overridden separately via debug commands.
• Remove the --flashblocks boolean flag. Instead, Flashblocks configuration is now optional via Option<FlashblocksArgs>. Flashblocks is enabled if any related --flashblocks-* flags are specified.
• Rename Args to RollupBoostArgs for clarity and consistency.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
rollup-boost	⬜️ Ignored (Inspect)	Visit Preview		Jun 30, 2025 3:05pm

[ferranbt]

Remove the Commands subcommand and debug commands. This command seems to be redundant since the debug API is already exposed over HTTP. This also created potential inconsistencies where execution_mode could be set via CLI flags but then overridden separately via debug commands.

I have to check first if there is any user using this feature. I like the pattern to ship the service with an easy UX to interact with the internal API endpoints but open to remove it if it is not widely used and the workflow to interact with those endpoints is more automatic than manual.

Remove the --flashblocks boolean flag. Instead, Flashblocks configuration is now optional via Option. Flashblocks is enabled if any related --flashblocks-* flags are specified.

This one I would like to keep. I like having a single point of control to turn on the feature. It eliminates the risk of accidentally enabling the feature just by setting a configuration value. Also, there might be cases (local testing) in which you want to enable the feature and use the default values.

[0xKitsune]

This one I would like to keep. I like having a single point of control to turn on the feature. It eliminates the risk of accidentally enabling the feature just by setting a configuration value.

Sounds good, I updated the PR to reintroduce this.

I have to check first if there is any user using this feature. I like the pattern to ship the service with an easy UX to interact with the internal API endpoints but open to remove it if it is not widely used and the workflow to interact with those endpoints is more automatic than manual.

The main motivation for removing the debug commands was to eliminate the risk of configuring --execution-mode via CLI flags and then unintentionally overriding it separately with a debug command. I’m happy to reintroduce it in a way that avoids this inconsistency if you prefer. Historically, we have just used curl to set the execution mode via the Debug API which has been simple, but if you think there’s value in retaining a CLI entry point let me know! Happy to adjust here.