<?php

namespace App\Support;

/**
 * El formato de una versión de contenido: `YYYYMMDDXX`, diez dígitos.
 *
 * Es el mismo formato que usa Moodle para las versiones de plugin —fecha más dos dígitos
 * de secuencia—, y el número con el que se decide qué contenido le toca a cada sitio.
 *
 * **Por qué está aquí y no en cada acción.** La comprobación y su mensaje estaban
 * repetidos **palabra por palabra en siete acciones** —`features`, `tutorials`,
 * `resources`, `scss`, `scss-cdn`, `js` y `setup`—, y lo único que cambiaba entre ellas
 * era el código de error de su familia. Ver MGR-024.
 *
 * Lo que se unifica es lo que **no debe** divergir: el patrón y el mensaje. Cada acción
 * sigue lanzando su propia excepción con su propio código, que es lo que sí tiene que ser
 * distinto —`3003` para setup y scss, `4003` para js y tutoriales, `5003` para features y
 * recursos—.
 *
 * > **El mensaje es contrato.** Sale por la red al plugin del cliente tal cual, y hay
 * > versiones desplegadas que podrían estar mirándolo. Vive en una constante justo para
 * > que nadie lo cambie «de paso» al tocar una acción.
 */
class VersionDeContenido
{
    /**
     * El texto exacto que se devuelve al cliente. **No se cambia**: ver la nota de arriba.
     */
    public const MENSAJE_DE_FORMATO = 'Invalid version format. Expected YYYYMMDDXX format (10 digits)';

    /**
     * ¿Es una versión con la forma que espera el Manager?
     *
     * Diez dígitos y nada más: ni `5.1.1`, ni `2026-01-01`, ni un número de nueve. No se
     * comprueba que la fecha exista —`2026133100` pasa—, porque lo que hace falta es que
     * el número sea comparable con los demás, y para eso basta la longitud.
     */
    public static function esValida(?string $version): bool
    {
        return $version !== null && preg_match('/^\d{10}$/', $version) === 1;
    }
}