OpMeta Input allows contradictory computed/constant shapes (computation without bits, parameters with bits)

[thedavidmeister]

Unit

crates/cli/src/meta/types/op/v1.rs — Input (computed vs constant inputs).

Intent oracle

OpMeta.inputs doc: "for opcodes with dynamic number of inputs, 'bits' field must be specified which determines this opcode has dynamic inputs ... with 'computation' field applied if specified". Input.bits doc: "Required only for computed (non-constant) inputs"; Input.computation doc: same.

Violated property

Cross-field consistency of the computed-input shape. Validation is per-field only, so these all validate today:

• {"computation": "bits + 1"} with no bits — a computation over operand bits that are never allocated;
• {"parameters": [..], "bits": [0, 3]} — constant parameters together with dynamic bits, leaving the input count ambiguous between parameters.len() and the bits value.

Verified repro

OpMeta::try_from(br#"{"name":"add","inputs":[{"computation":"bits + 1"}]}"#.to_vec()) returns Ok (verified while building the AMT suite — the new test_opmeta_input_computation_validated uses exactly this shape as its "valid" arm because the current validator accepts it).

Triage framing

The docs describe a discriminated union (constant: parameters; computed: bits [+ computation]) that the struct does not enforce. Consumers (rainlang tooling) presumably fail later or misread such metas. Possibly out of scope for schema-level validation — flagged for a human call.

[thedavidmeister]

Answering the triage framing, since the two shapes in this issue do not have the same answer.

{"computation": "bits + 1"} with no bits is a real defect. Fixed in #260: Input gains a struct-level #[validate(schema(...))] rejecting it. The sibling Output in the same file already encodes the union as an enum whose Computed(BitIntegerRange, Computation) cannot be split, and upstream's schemas/op.meta.schema.json in rainlanguage/rain-metadata makes bits required on ComputedOutput. The repro OpMeta::try_from(br#"{"name":"add","inputs":[{"computation":"bits + 1"}]}"#) now returns Err.

{"parameters": [..], "bits": [..]} is not a defect and must not be rejected. It is the canonical shape of every dynamic-input opcode. The same upstream schema makes parameters required on InputArgs with bits optional beside it, and the shipped examples carry both:

"inputs": {
  "bits": [0, 7],
  "parameters": [{ "name": "input", "spread": true }]
}

(examples/op-meta/Add.op.meta.json; Call.op.meta.json is identical in shape.) InputParameter.spread — "Specifies if an argument is dynamic in length" — has no valid use at all if a parameter may not sit beside bits, and the inputs doc already resolves the count: bits present means the count derives from the bits, not from parameters.len(), so there is no ambiguity to enforce away. Enforcing it would reject add and call. #260 pins that shape as accepted with a test so it is not "fixed" later.