fix(cli): apply input overrides through input blocks - #418

packages/blocks/src/blocks/input-blocks.ts (1)

244-289: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Inconsistent strictness: object/array inputs silently become garbage strings.

Checkbox and date-range validate shape and throw InvalidValueError on bad input, but slider/text/textarea/date/file/select fall back to coerceToInputString, which blindly calls String(value). An object override silently becomes "[object Object]", and an array becomes "a,b" — no error, just corrupted metadata.

♻️ Proposed guard

 function coerceToInputString(value: unknown): string {
-  return value === null || value === undefined ? '' : String(value)
+  if (value === null || value === undefined) return ''
+  if (typeof value === 'object') {
+    throw new InvalidValueError(`Invalid input value: expected a scalar, received an object/array.`, { value })
+  }
+  return String(value)
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/blocks/src/blocks/input-blocks.ts` around lines 244 - 289, Update
coerceToInputString and the scalar branches in coerceInputVariableValue to
reject non-scalar objects and arrays with InvalidValueError instead of
converting them via String(value); preserve nullish-to-empty-string behavior and
valid primitive coercion. Apply the same validation to single-value select
handling while retaining its existing multi-value array semantics, and include
the received value in the error details.

packages/blocks/src/blocks/input-blocks.ts (1)

96-99: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Numeric-string check is stricter than typical slider input.

isFiniteNumberString requires the raw string to round-trip exactly through Number.parseFloat().toString(). This rejects perfectly valid decimal notations a CLI user might type: '5.0', '.5', '+5', '1e3' all fail (parsed .toString() normalizes them away from the input form). The '07' rejection test confirms this is partly intentional (leading-zero ambiguity), but the collateral rejection of common canonical forms looks like an overlooked edge case rather than a deliberate contract.

♻️ Suggested regex-based validation (keeps '07'/'Infinity' rejected, accepts '5.0', '-5.25', etc.)

-function isFiniteNumberString(value: string): boolean {
-  const parsed = Number.parseFloat(value)
-  return Number.isFinite(parsed) && value.trim() === parsed.toString()
-}
+function isFiniteNumberString(value: string): boolean {
+  const trimmed = value.trim()
+  if (!/^-?(0|[1-9]\d*)(\.\d+)?$/.test(trimmed)) {
+    return false
+  }
+  return Number.isFinite(Number.parseFloat(trimmed))
+}

Please confirm whether exact round-trip stability is actually required by the app's slider contract, or whether this is an unintentional side effect of the .toString() comparison.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/blocks/src/blocks/input-blocks.ts` around lines 96 - 99, Clarify the
slider numeric-string contract around isFiniteNumberString: replace the exact
parseFloat/toString round-trip check with validation that accepts standard
finite decimal and exponent forms such as 5.0, .5, +5, and 1e3 while continuing
to reject ambiguous leading-zero values like 07 and non-finite values such as
Infinity. Update the associated tests to cover these accepted and rejected
forms.