Validar nombres de feature flags

Esta capacidad valida un nombre candidato frente a un patrón práctico de la industria: no vacío, todo en minúsculas, en kebab-case con guiones o en snake_case (nunca ambos separadores en la misma cadena), al menos dos segmentos, prefijo descriptivo como enable, feature, ff, rollout o beta, máximo sesenta y cuatro caracteres y sin separadores al borde ni consecutivos. La entrada vacía falla con invalid_input y no se factura. Los fallos de convención devuelven un payload de éxito con valid en false y una lista ordenada de issues para que la integración continua falle el build con un informe claro.

Qué exige la convención de nombres

Primero, no debe estar vacío ni ser solo espacios: un nombre vacío se rechaza al instante como invalid_input porque no hay nada útil que evaluar. Segundo, cada carácter debe ser letra ASCII minúscula, dígito y exactamente un estilo de separador: guiones para kebab-case o guiones bajos para snake_case. En conjunto, estas reglas encajan con claves al estilo LaunchDarkly, toggles Unleash y la mayoría de ficheros JSON o YAML internos sin inventar un dialecto de un solo proveedor.

Contrato de entrada, forma de respuesta y errores

Envíe un cuerpo JSON con un campo de cadena obligatorio llamado name (el manejador acepta también los alias flag_name y text por flexibilidad de transporte). En éxito la respuesta incluye siempre valid (booleano), el name recortado, style (kebab, snake o null si el patrón no se clasificó), prefix (primer segmento o null), segments como array ordenado de cadenas, segment_count, has_descriptive_prefix, issues como lista estable y ordenada de códigos legibles por máquina, y una frase breve de convention apta para la interfaz. Cuando el nombre existe pero rompe la convención, valid es false e issues enumera códigos como not_lowercase, mixed_separators, missing_descriptive_prefix, too_few_segments, invalid_characters, consecutive_separators, leading_or_trailing_separator, too_long, missing_separator_segments o invalid_pattern—sin lanzar error—para que linters y bots de pull request impriman todos los problemas de una vez. Solo nombres vacíos, ausentes o no cadena lanzan invalid_input; esos fallos no consumen saldo prepago.

Dónde aporta valor la validación de nombres de flags

Los equipos de plataforma y de experiencia de desarrollador integran esta comprobación en generadores de scaffolding para que no entren flags nuevos sin prefijo ni estilo de separador. Los trabajos de integración continua escanean solicitudes de cambios que tocan catálogos de flags o ficheros de entorno de ejemplo y fallan el build cuando un nombre confundiría a los operadores meses después. Las herramientas de analítica de producto y de experimentos usan las mismas reglas al registrar claves de despliegue para que los paneles agrupen por prefijo de forma coherente en mobile, web y backend. Los bots de revisión de código llaman a la API con una cadena candidata y pegan la lista de issues en el hilo de revisión en lugar de discutir el estilo por gusto. Como cada llamada correcta cuesta el precio base publicado $0.002 sin tokens de modelo, puede validar miles de nombres en un script de migración sin gasto sorpresa; los envíos vacíos siguen sin cargo como error del cliente. Mantenga la tabla de prefijos alineada con el estilo de su organización mapeando verbos internos al conjunto admitido, o envuelva este endpoint y rechace cualquier prefijo que su política prohíba aunque la convención base pase.