Parse a Custom Record with Fixed Fields, Mapped Keys, and Nested Lists

Design a parser that converts a custom record string into an object. A record has four fixed fields followed by a marked free-form section: `machine_code, timestamp, field1, field2, $[freeform]&` A representative input is: ```text 123, 1231231231, AAA, BBB, $[v1: SSS, v2:[sdjf, sdf], v1: TTT]& ``` Some fixed-field values must be converted using supplied mappings or enums. In particular, the numeric machine code maps to an enum-like object. Free-form keys also require supplied key mappings, and values may include bracketed lists. Explain how you would parse, validate, transform, and construct the result. ### Constraints The complete grammar, mapping tables, target object types, and duplicate-key policy are unspecified. The sample deliberately contains repeated `v1`; do not silently decide which value wins. Do not assume ordinary CSV rules or split every comma indiscriminately. This is a parser-design exercise with unresolved semantics rather than a fixed console contract. ### Clarifying Questions - Can values contain quoted commas, colons, brackets, or escaped delimiters? - Can lists nest, and may free-form values contain objects or only scalar/list values? - What should unknown enum codes, unmapped keys, repeated keys, and malformed markers do? - Are free-form mapped keys allowed to collide with fixed-field names? ```hint Track delimiter context The comma between two list values is not the separator between two top-level key-value pairs. ``` ### What a Strong Answer Covers - A grammar-aware separation of the four fixed fields and marked free-form section. - Context-sensitive delimiter handling, duplicate policy, and useful validation errors. - Distinct parsing and mapping phases, typed object construction, and tests for the supplied structural features. ### Follow-up Questions - How would you preserve the input position of an invalid enum code? - How would a future nested-value extension affect a simple comma-splitting implementation?