Background
Found during code review of #7 (flag-consistency test PR #14). --timeout currently has a different default per command:
upgrade: 0 (no limit) — per-attempt timeout for the full compile+flash cycleversions: 12s — per-device timeout waiting for a log linediagnostics: 15s — per-device timeout for boot log collectionvalidate: 30s — per-device timeout for config validation
These differences may be intentional (compiling/flashing vs. tailing logs have very different natural timescales), but they were never explicitly reviewed as a design decision — they just accreted command by command.
Goal
Review whether each default is still the right choice, and document the rationale (in code comments and/or README) for why they differ, so it reads as a deliberate decision rather than drift. If any default no longer makes sense, adjust it.
Note
This is a review/decision issue, not necessarily a code-change issue — the outcome may simply be "defaults are correct, documented why." Out of scope for the flag-consistency test in #7, which intentionally only checks flag signature (type/shorthand), not default values.
Flow
Design/review → (optional) feature branch + change → PR → review (code-improver agent) → merge.
Background
Found during code review of #7 (flag-consistency test PR #14).
--timeoutcurrently has a different default per command:upgrade:0(no limit) — per-attempt timeout for the full compile+flash cycleversions:12s— per-device timeout waiting for a log linediagnostics:15s— per-device timeout for boot log collectionvalidate:30s— per-device timeout for config validationThese differences may be intentional (compiling/flashing vs. tailing logs have very different natural timescales), but they were never explicitly reviewed as a design decision — they just accreted command by command.
Goal
Review whether each default is still the right choice, and document the rationale (in code comments and/or README) for why they differ, so it reads as a deliberate decision rather than drift. If any default no longer makes sense, adjust it.
Note
This is a review/decision issue, not necessarily a code-change issue — the outcome may simply be "defaults are correct, documented why." Out of scope for the flag-consistency test in #7, which intentionally only checks flag signature (type/shorthand), not default values.
Flow
Design/review → (optional) feature branch + change → PR → review (code-improver agent) → merge.