Adding and Implementing Zod

Start with the coordinator functions and the convert entry point, then review the existing transform functions and API documentation. Define the Zod validation behavior, derived transform types, and conversion report shape before implementing them. Done means malformed input and invalid output are tested, transform mismatches fail at compile time, and report behavior is documented.

• Add Zod schemas for codemeta and code.json

  • Define Zod schemas that describe valid input for each format. Use them to parse and validate input inside the coordinator functions before the engine runs.
  • Acceptance: Malformed input produces a Zod validation error with a readable message identifying the offending field, rather than silently producing garbage output.

• Validate converted output against the target schema

  • After convert returns, validate the result against the target format's Zod schema. Decide whether invalid output throws or returns a warnings array, and document the choice.
  • Acceptance: A transform that returns an incorrectly shaped value is caught by output validation in a test, and the behavior (throw vs warn) is documented in the API docs.

• Type the transform functions properly

  • Replace (value: unknown) => unknown signatures with types derived from the Zod schemas, so transforms declare what they accept and return.
  • Acceptance: A transform with a mismatched input or output type produces a compile-time TypeScript error, and all existing transforms have typed signatures.

• Emit a conversion report alongside converted output

  • Produce a structured report describing which source fields were ignored, which target fields were filled with defaults, and any lossy transforms that ran. The report can be opt-in or always returned.
  • Acceptance: Callers can obtain a report for any conversion, and at least one test asserts on report contents for a known-lossy input (e.g. multi-author codemeta → code.json).