Vector form support is inconsistent across dimensions in dimensions.json

[matt-edmondson]

Summary

The strategy doc requires every dimension to declare which vector forms it supports (Vector0, Vector1, Vector2, Vector3, Vector4). Today the metadata is uneven:

• Length declares V0, V1, V2, V3, V4.
• ElectricCurrent declares V0, V1, V3 (no V2) — yet ElectricField2D is generated and mentioned in dot/cross product rules.
• Most "scalar-only" dimensions (Mass, Energy, Area) only have V0, but the generator's V0 subtraction pathway assumes a V1 exists (see Resolve open design decision for Vector0 subtraction #52).

Evidence

• Semantics.SourceGenerators/Metadata/dimensions.json — inspect the per-dimension forms arrays.
• Generated output: Acceleration2D.g.cs, Displacement2D.g.cs, ElectricField2D.g.cs, Force2D.g.cs, Velocity2D.g.cs exist, but other 2D forms expected by the strategy table (e.g. Position2D) may not.

Suggested next step

1. Audit dimensions.json and explicitly list intended forms per dimension.
2. Add a generator-time validator that fails fast if a relationship references a form the dimension does not declare.
3. Update the strategy doc with the canonical per-dimension form matrix.

Area / Severity

Metadata / SourceGenerators · incomplete

[matt-edmondson]

Status / partial response.

The metadata is intentionally uneven, not accidentally so:

• Linear-motion families (Length, Velocity, Acceleration, Jerk, Snap, Force, Momentum, Displacement) declare V0–V4.
• Angular families (AngularDisplacement, AngularVelocity, AngularAcceleration, AngularJerk, Torque, AngularMomentum) declare V0/V1/V3 only — pseudovectors don't have meaningful 2D or 4D forms.
• ElectricCurrent declares V0/V1/V3 (no 2D current notion).
• ElectricField declares V0/V1/V2/V3 (the issue's "ElectricField2D" call-out — that one is intentional and correctly emitted).
• Scalar-only dimensions (Mass, Energy, Area, Time, Temperature, Frequency, etc.) declare V0 only, optionally with a V1 delta.

CLAUDE.md was rewritten in #66 to use the V0/V1/Vn vocabulary; with #70 it now correctly says V0–V0 subtraction is structural, not "skipped if V1 is missing", so the original concern about scalar-only dimensions losing arithmetic is no longer true.

What's still open from the original issue and worth doing:

1. Document the canonical form matrix in docs/strategy-unified-vector-quantities.md — write down "linear quantities ⇒ V0–V4, angular ⇒ V0/V1/V3, electric current ⇒ V0/V1/V3, scalar ⇒ V0(+V1)" so adding a new dimension doesn't have to reverse-engineer it from neighbours.
2. Generator-time validator for relationships at unsupported forms. Today, if dotProducts declares A.B = C and only A has V3, the operator is silently skipped at line ~252. Worth a SEM003 warning so an accidentally-mismatched form combination shows up rather than disappearing into the build.

Leaving open for those two pieces; the metadata itself is consistent.

---

Generated by Claude Code

[matt-edmondson]

Update on #58 work:

Done in #72 — added a "Form Coverage Matrix" section to docs/strategy-unified-vector-quantities.md writing down the canonical patterns (linear V0–V4, angular V0/V1/V3, electric current V0/V1/V3, scalar-only V0(+V1), dimensionless Ratio/SignedRatio). The metadata is consistent with this matrix today.

Not done — needs a metadata schema change first. The original suggestion was a "fail fast if a relationship references a form the dimension does not declare" diagnostic (a SEM003). Looking at dimensions.json more carefully, relationships (integrals / derivatives / dotProducts / crossProducts) are dimension-to-dimension today, not form-specific:

"crossProducts": [
  { "other": "Displacement", "result": "Torque" }
]

The generator iterates the form table internally and emits an operator for every form that exists on both sides. There's no metadata field for "this cross product should specifically exist at V3 only". So a SEM003 for "form not declared" can't fire on current metadata — there's nothing to validate against.

To make SEM003 meaningful, the schema would need either:

1. Per-form relationships — "crossProducts": [{ "form": 3, "other": "Displacement", "result": "Torque" }] — and SEM003 warns when the declared form is missing on either side.
2. A required-forms list per relationship — "crossProducts": [{ "other": "Displacement", "result": "Torque", "requiredForms": [3] }].

Option 1 is cleaner and would also let the form matrix be enforced (today every cross product implicitly only emits at V3 anyway). Worth doing as a small follow-up; I'll leave this issue open for that work.

---

Generated by Claude Code