Feature: forward repeatable application arguments through sb-dev
Context
The plugin/runtime smoke scenarios need to launch the app with deterministic entrypoint arguments such as --serial, --no-account, and --bypass-onboarding. The current draft #850 adds this to scripts/sb-dev.sh, but its only linked reference is closed #809 and no current issue describes the tooling contract.
This is development-loop support. It does not change production device behavior or the REST/WebSocket API.
Current behavior
sb-dev start forwards platform/build flags and repeatable --dart-define values, but cannot pass application arguments to main(). Restart persistence therefore cannot reproduce a runtime invocation that depends on BLE-discovery suppression or account/onboarding bypass.
Scoped proposal
- Add repeatable --app-arg and --app-arg= forms to sb-dev start.
- Forward each argument as a Flutter Dart entrypoint argument without reinterpreting its content.
- Persist and restore the exact argument list across sb-dev restart.
- Reject missing values and newline-containing values deterministically.
- Document the supported scenario arguments and retain compatibility for existing invocations.
- Add shell fixture tests that verify argument order and forwarding.
Alternatives and open decision
Direct flutter run --dart-entrypoint-args=... already supports these launches. This optional development-tool change keeps them inside the repository's managed readiness/reload/restart/cleanup loop. It is not required for the shipped Skale or E64 plugin behavior.
Should sb-dev expose this generic forwarding option, or should the scenarios document direct Flutter invocation? The draft accepts empty strings and preserves spaces and shell metacharacters literally; it rejects newlines because persisted flags are line-oriented. --serial suppresses BLE discovery rather than selecting a serial device.
Related work
Acceptance criteria
- Repeated --app-arg values reach Flutter in the original order and remain single arguments.
- --app-arg=value and separated-value forms behave identically.
- Missing values and newline-containing values fail before launch.
- sb-dev restart reproduces the saved arguments exactly.
- Existing start/restart invocations without --app-arg behave unchanged.
- Shell fixture tests and documentation cover --serial, --no-account, and --bypass-onboarding.
Discussion status
This proposal is being opened alongside an existing draft implementation so the contract can be discussed explicitly. The draft is review material, not evidence of maintainer acceptance. Please settle the scope and API choices here before advancing it.
Feature: forward repeatable application arguments through sb-dev
Context
The plugin/runtime smoke scenarios need to launch the app with deterministic entrypoint arguments such as --serial, --no-account, and --bypass-onboarding. The current draft #850 adds this to scripts/sb-dev.sh, but its only linked reference is closed #809 and no current issue describes the tooling contract.
This is development-loop support. It does not change production device behavior or the REST/WebSocket API.
Current behavior
sb-dev start forwards platform/build flags and repeatable --dart-define values, but cannot pass application arguments to main(). Restart persistence therefore cannot reproduce a runtime invocation that depends on BLE-discovery suppression or account/onboarding bypass.
Scoped proposal
Alternatives and open decision
Direct
flutter run --dart-entrypoint-args=...already supports these launches. This optional development-tool change keeps them inside the repository's managed readiness/reload/restart/cleanup loop. It is not required for the shipped Skale or E64 plugin behavior.Should
sb-devexpose this generic forwarding option, or should the scenarios document direct Flutter invocation? The draft accepts empty strings and preserves spaces and shell metacharacters literally; it rejects newlines because persisted flags are line-oriented.--serialsuppresses BLE discovery rather than selecting a serial device.Related work
Acceptance criteria
Discussion status
This proposal is being opened alongside an existing draft implementation so the contract can be discussed explicitly. The draft is review material, not evidence of maintainer acceptance. Please settle the scope and API choices here before advancing it.