0.0.9

Added

• start --timeout=<n> option (default 90): configures the maximum seconds the VM Service URI scrape loop waits for flutter run to print the debug URI in the log file. Previously the deadline was hardcoded to 90 s; cold starts on slow CI machines or after a fresh Flutter SDK install can exceed this limit. Setting --timeout=120 (or higher) prevents false-timeout failures. The error message now reports the configured value rather than a literal "90s". Applies to the --cdp-port branch only; the non-CDP branch retains its own hardcoded deadline.
• start --cdp-port=<n> now probes the CDP port for availability BEFORE launching Chrome. When the port is already in use, the command exits 1 immediately with a clear message: "CDP port N is already in use; pass --cdp-port or free it before running start." This replaces the previous misleading "Is Chrome installed?" catch-all that fired when Chrome failed to open the debug port it was asked to bind.

Changed

• plugin:install's install.yaml bootstrap_command now AUTO-RUNS after a successful manifest install instead of only printing a hint. Once the plugin is registered (plugins.json + lib/app/_plugins.g.dart regenerated), the declared command is spawned as a fresh dispatcher subprocess (./bin/fsa <cmd> --non-interactive when bin/fsa exists, else dart run <consumer>:artisan <cmd> --non-interactive), so the just-registered plugin command actually executes. --non-interactive is always forwarded so an interactive bootstrap (e.g. starter:install) cannot hang. --bootstrap-command=<name> overrides the manifest value; --no-bootstrap skips the auto-run and falls back to the hint. When no dispatcher resolves (no bin/fsa, no consumer pubspec name), the one-line Bootstrap with: artisan <cmd> hint is printed as before.

Fixed

• plugin:install now surfaces a failing bootstrap_command instead of implying success. BootstrapCommandRunner.run returns a BootstrapRunResult carrying the subprocess exit code and captured stderr (it previously discarded the ProcessResult), and plugin:install warns with the exit code + stderr and prints the manual bootstrap hint when the chained command exits non-zero. A bootstrap that fails (stale fast-CLI bundle, unknown command, scaffold error) is no longer reported to the operator as if it had completed.
• start --timeout=<n> now rejects zero and negative values immediately with an actionable error ("--timeout must be a positive integer"), instead of silently passing a non-positive deadline to the VM Service scrape loop and producing a confusing "Timed out after 0s" failure.
• Passing an unknown option to any command now fails loudly instead of silently printing help and exiting as if help were requested (issue #12). The dispatcher writes Unknown option: <flag> to stderr (both long --foo and short -x forms), prints the command help, and exits non-zero. Other parse failures keep their original messages: a missing option value (Missing argument for "..."), a disallowed value, and a value given to a flag each surface their specific diagnostic unchanged. --help / -h and every valid invocation are unaffected. Because this is the shared dispatch path for every command, the fix benefits every plugin CLI built on the substrate.