Los atributos que hacen falta

Los siete

La plantilla

Esto es lo que conviene que lleve todo tipo que cruce el puente:

// El encabezado estándar del proyecto para un struct que cruza#[derive(Debug, Clone, serde::Serialize, serde::Deserialize)]#[serde(rename_all = "camelCase")]pub struct ProyectoResumen {    pub id: ProyectoId,    pub nombre: String,    pub numero_ficheros: usize,      // llega como numeroFicheros    pub creado_en_ms: i64,           // la unidad, en el nombre. Nivel 17.4    pub descripcion: Option<String>, // sale siempre, con null. Nivel 17.3}// Y para un enum#[derive(Debug, Clone, serde::Serialize, serde::Deserialize)]#[serde(tag = "tipo", rename_all = "camelCase")]pub enum EstadoIndexado {    Cargando,    Listo { ficheros: usize },    Fallo { code: String, message: String },}

Cuatro notas sobre las derivaciones, que también son decisiones:

• Serialize y Deserialize los dos, aunque el tipo solo salga hoy. Cuesta cero y evita el día en que hay que volver a tocarlo.
• Debug siempre: sin él, no puedes imprimir el valor cuando algo falla, que es justo cuando lo necesitas.
• Clone casi siempre en un tipo que cruza: son datos, son pequeños, y no tenerlo obliga a contorsiones al emitir el mismo valor a varias ventanas.
• No Copy. Un tipo que cruza suele llevar cadenas, así que no puede; y si pudiera, tampoco aporta.

Los dos que parecen útiles y no lo son

untagged en un enum. Quita el discriminante y deja que la variante se adivine por la forma. Al deserializar prueba las variantes en orden hasta que una encaja, así que dos variantes parecidas se confunden en silencio y según el orden en que las escribiste. El nivel 17.2 ya lo desaconsejaba; aquí se repite porque es el atributo que más se copia de un ejemplo sin entenderlo.

flatten para aplanar un struct dentro de otro. Es cómodo —evita un nivel de anidamiento— y tiene dos costes: al deserializar es notablemente más lento porque tiene que recoger las claves desconocidas antes de repartirlas, y rompe la generación de tipos de varias herramientas, incluida la del nivel 19. Si el objetivo es que el frontend no vea un nivel más, casi siempre es mejor escribir un tipo plano a propósito, que es la recomendación de tipo por pantalla del nivel 15.3.