Proposal: Adopt zod_gen to generate TS types + Zod schemas from Rust DTOs (reduce duplicated API structs)

[TheBest6337]

(Moved from @15i1i-s7v's Issue: #986)

Context

• We currently define DTO/event payload structs twice: once in Rust (server) and again in TypeScript (electron).
• This creates duplicated work and risk of drift (rename, optional fields, enums, etc.).

What is zod_gen?

• zod_gen generates Zod schemas and TypeScript types from Rust types via derive macros.
• Output pattern: export const XSchema = ...; export type X = z.infer<typeof XSchema>;
  Refs:
• https://github.com/cimatic/zod_gen
• https://docs.rs/zod_gen
• Zod docs: https://zod.dev/

Why this might help QiTech long-term

• Single source of truth for payload types in Rust
• TS gets runtime validation (Zod) + inferred types automatically
• Expected reduction in “change type in 2 places” work and mismatch bugs

Costs / Risks / Unknowns

• Add a codegen step to the build/CI (and keep it reproducible in Nix workflows)
• Small project / limited bus factor (evaluate maintainability)
• Coverage: some Rust types may require manual schemas

Alternatives

• ts-rs: generates TS typings from Rust but no Zod validators
• typeshare: generates TS + other languages from Rust types, but not Zod validators
• specta: exports Rust types to TS and others (evaluate fit)

Proposed Spike (PoC) plan

1. Pick 1–2 real DTOs/events used by both server + electron (small but representative).
2. Add #[derive(ZodSchema, Serialize, Deserialize)] on these Rust types.
3. Add a small Rust generator binary that writes electron/src/generated/schemas.ts.
4. Use XSchema.parse(...) (or safeParse) in the electron boundary (REST/socket event handler).
5. Remove the duplicated TS interfaces/zod schemas for those DTOs.

Success criteria (to decide "go / no-go")

• ≥ 1 real DTO fully generated and used end-to-end
• Tangible removal of duplicated TS type/schema code
• Codegen step is stable + easy for devs + CI
• No unacceptable limitations with enums/renames/options used in our payloads

Non-goals (for this issue)

• Migrating all DTOs at once
• Refactoring unrelated UI/business logic

[TheBest6337]

(Answer from @Oshgnacknak )

I might take a look into this further, once we've done the WAGO todos. Generating (string literals containing) front-end code seems valid for our use case. Mutations, State Events and LiveValues might be generatable in the front-end.