Closes #493

Problem

When a VSS signal has datatype: string and an allowed attribute, the protobuf exporter emits a plain string field. This silently accepts any value at the protobuf layer — the constraint declared in the VSS spec is invisible to protobuf consumers.

# Before — allowed values ['DRY', 'WET', 'SNOW', 'ICE'] are lost
string Surface = 2;

Fix

print_messages() now uses a two-pass approach in src/vss_tools/exporters/protobuf.py:

• Pass 1: for each string + allowed field, emit a nested enum <FieldName>Enum with allowed values assigned indices starting at 0 (satisfying the proto3 zero-value requirement).
• Pass 2: emit the field using the enum type instead of string.

repeated string[] fields with allowed become repeated <EnumType>. String fields without allowed and all non-string fields are unchanged.

# After
message A {
  enum SurfaceEnum {
    DRY = 0;
    WET = 1;
    SNOW = 2;
    ICE = 3;
  }
  repeated SurfaceEnum Surface = 2;
}

Note on proto3 zero-value semantics: proto3 uses the first enum entry as the default for unset fields. This implementation assigns index 0 to the first entry in the VSS allowed list. For signals that follow the convention of listing UNKNOWN first (e.g., Vehicle.Exterior.RoadSurfaceCondition), this aligns naturally. For signals without a natural "unset" first value, the first allowed entry becomes the proto default. Happy to discuss if a different index assignment strategy is preferred.

Changes

Tests

$ python3 -m pytest tests/ -k "proto" -v
13 passed in 5.36s

All 13 protobuf-related tests pass, including the two existing test_protobuf_comments parametrized cases (no-comments / with-comments) which already contained a string + allowed field in their fixture.

AI-assisted — authored with Claude, reviewed by Komada.