Volume unit enums disagree: `zoo kcl volume` accepts mm3, `zoo file volume` rejects it

[sneg55]

Context: API Makeathon participant, hit while building a tool that cross-checks kcl and file volume results against each other.

The two subcommands measure the same physical quantity but accept different unit enums, and the kcl side's error message for an invalid unit does not list the accepted values.

Repro (CLI only, argument parsing)

$ zoo file volume --output-unit mm3 part.step
error: invalid value 'mm3' for '--output-unit <OUTPUT_UNIT>'
  [possible values: cm3, ft3, in3, m3, yd3, usfloz, usgal, l, ml]

  tip: a similar value exists: 'cm3'

mm3 is not in the file enum at all.

$ zoo kcl volume --output-unit mm3 part.kcl

parses fine and proceeds to the engine (zoo kcl analyze --volume-output-unit mm3 likewise; measured results come back in mm3 as requested).

A second, smaller asymmetry: the kcl side's invalid-value error does not enumerate its options, so there is no way to discover the accepted spellings from the CLI:

$ zoo kcl volume --output-unit bogus part.kcl
error: invalid value 'bogus' for '--output-unit <OUTPUT_UNIT>': parse failed.

compared with the file side's helpful [possible values: ...] list above.

Why it bites

Millimeters are the default working unit for most KCL (and @settings(defaultLengthUnit = mm) is idiomatic), so mm3 is the natural request. A script that works against zoo kcl volume breaks when pointed at zoo file volume, and cross-checking a KCL build against its own exported STEP file requires converting units on one side.

Suggested fix: use one shared unit enum for both, and let clap print [possible values: ...] on the kcl side.

Environment

• Zoo CLI v0.2.184 (33534cd), macOS arm64, verified 2026-07-25