Replay command accepts negative replay rates without validation

[Sathvikarai]

Summary

The replay CLI command accepts negative values for the --rate parameter and continues execution without validation. Replay rates are expected to represent a positive playback interval or replay speed, but non-positive values are currently allowed.

Reproduction

Run the following command:
python -m sigflow replay samples/valid_telemetry.sgf --rate -1

Expected Behavior

The replay command should validate the replay rate and reject non-positive values with a clear user-friendly error message.
Example:
error: replay rate must be greater than 0

Actual Behavior

The replay command executes successfully using the negative replay rate value.
Example output:
replay stream=42 sequence=1 rate=-1
replay stream=42 sequence=2 rate=-1

Environment

Python version: 3.10.11
sigflow version or commit: sigflow-0.1.0
Operating system: Windows

Additional Context

During investigation, the --rate argument was observed to accept negative integer values without validation. The argument appears to be parsed successfully, but there is currently no boundary check to ensure the replay rate is greater than zero before execution begins.
Allowing invalid replay rates may lead to undefined or inconsistent replay timing behavior and weakens CLI input validation reliability.

[jmestwa-coder]

From the current implementation, it appears the --rate argument is accepted and propagated to output, but it is not currently involved in replay timing or scheduling logic. Because of that, I’m not yet certain whether this is considered an actual functional bug or simply permissive CLI behavior.

It may be useful to first confirm the intended contract for --rate validation before proposing a behavioral change.

[Sathvikarai]

I noticed this mainly because some other CLI arguments already validate invalid values, so I assumed similar validation might apply here as well. I understand that the current behaviour may be intentionally permissive until the expected contract for --rate is defined more clearly.

[jmestwa-coder]

I initially interpreted this as a possible consistency issue because some other CLI parameters already reject invalid ranges. After reviewing the current replay flow more closely, I agree that the intended contract for --rate is not clearly defined yet, especially since it is not currently used in timing or scheduling calculations.