Hoja de ruta: nada de esto existe todavía

El análisis de código solo tiene sentido si la plataforma entiende las comprobaciones: resultados que pertenecen a un commit, aparecen en una solicitud de fusión y pueden impedir la fusión. Esta versión construye esa base, traduce la interfaz y permite elegir su tema.

• Ramas protegidas: sin push directo, fusión solo mediante una solicitud de fusión, aprobaciones y comprobaciones obligatorias.
• Pipelines en las solicitudes de fusión, con su estado visible en la solicitud y exigido antes de fusionar.
• Variables de CI predefinidas (commit, rama, solicitud de fusión, pipeline) y rules para decidir cuándo se ejecuta un job.
• Artefactos de pipeline y una API para subir informes, que es lo que usarán los análisis de las versiones siguientes.
• Relanzar un pipeline desde la interfaz, y pipelines programados.
• Tokens de acceso personal utilizables en la API REST, con ámbitos, y una descripción OpenAPI generada a partir del código.
• Un primer vínculo con ArtiFerris: publicar en una instancia de ArtiFerris un artefacto construido por un pipeline.
• La interfaz en inglés, francés, italiano, español y alemán. El idioma sigue al navegador en la primera visita, se puede cambiar al instante y se guarda en la cuenta. Los correos que envía FerrisGit usan el idioma del destinatario y las páginas públicas siguen el Accept-Language del lector. La documentación se traduce después.
• Modo oscuro como ajuste: sistema, claro u oscuro, guardado en la cuenta y aplicado sin parpadeo. Hoy la interfaz sigue la preferencia del sistema y no tiene interruptor. El logotipo de la interfaz con sesión iniciada también sigue el tema.

FerrisGit tendrá su propio motor de análisis en lugar de envolver herramientas de terceros: un binario ferrisgit-scan que ejecuta un job de pipeline, de modo que el análisis escala con los runners y el servidor sigue siendo ligero. Sus analizadores son plugins que producen hallazgos en un modelo cercano a SARIF, así que los informes de otras herramientas se pueden importar junto a los nativos.

• El motor y el almacén de hallazgos: un análisis por commit, hallazgos identificados por una huella estable y una línea base por rama para distinguir los hallazgos nuevos de una solicitud de fusión de los antiguos.
• Detección nativa de secretos, en el diff de una solicitud de fusión y en todo el historial.
• Auditoría nativa de dependencias: archivos de bloqueo (Cargo.lock, package-lock.json, otros más adelante) contrastados con bases de avisos públicas como OSV.
• Hallazgos mostrados en línea en el diff de la solicitud de fusión y resumidos en su cronología.
• Importación de informes SARIF de otras herramientas.

• Puertas de calidad, configurables por repositorio: por ejemplo, ningún hallazgo bloqueante nuevo y una cobertura mínima en el código nuevo. Una puerta es una comprobación obligatoria, así que puede impedir una fusión.
• Un panel por repositorio: hallazgos abiertos, su antigüedad, tendencia por rama, deuda técnica y puntos calientes.
• Triaje: marcar un hallazgo como falso positivo o como no se corregirá, asignarlo, suprimirlo en el código y conservar el historial.
• Un archivo .ferrisgit/scan.yml para elegir analizadores, conjuntos de reglas y umbrales, y para excluir rutas.

Todo el repositorio se analiza en cada push a la rama por defecto y en cada solicitud de fusión, y las puertas solo miran lo que introduce una solicitud de fusión (el enfoque "clean as you code"), de modo que un proyecto existente sigue siendo adoptable.

• Análisis sintáctico con tree-sitter, para que el mismo motor lea varios lenguajes. Primero Rust y TypeScript.
• Métricas: tamaño, complejidad ciclomática y cognitiva, duplicación.
• Code smells y patrones de errores, como reglas declarativas y como reglas nativas.
• Seguimiento de la cobertura de pruebas (informes LCOV y Cobertura), con la cobertura de lo que cambia una solicitud de fusión.

• Pruebas estáticas de seguridad de aplicaciones: primero reglas de patrones, después el flujo de datos dentro de una función.
• Análisis de imágenes de contenedor y de infraestructura como código.
• Un resumen de seguridad en cada solicitud de fusión y un panel de seguridad por repositorio, con severidades y la opción de bloquear la fusión por encima de una severidad elegida.
• Rastrear cada artefacto publicado en ArtiFerris hasta el commit, la solicitud de fusión y el pipeline que lo produjeron, y mostrarlo en las páginas de release y de pipeline de FerrisGit.
• Traer los resultados del análisis de artefactos de ArtiFerris a las comprobaciones de las solicitudes de fusión.
• Explorar una identidad compartida, para que una sola cuenta y una sola inscripción MFA funcionen en ambas plataformas.

• Git sobre SSH y claves de despliegue.
• Forks y solicitudes de fusión entre repositorios; renombrar y transferir un repositorio con redirecciones.
• Fusiones con squash y rebase, reabrir una solicitud de fusión, solicitudes de fusión en borrador y CODEOWNERS.
• Menciones (@nombre), referencias a incidencias (#12) y cierre de una incidencia desde un commit o una solicitud de fusión.
• Búsqueda de texto completo en el código, e importación desde GitHub y GitLab.
• Restablecimiento de contraseña por cuenta propia, notificaciones por correo con ajustes por usuario, e inicio de sesión único (OIDC, LDAP).
• Una página de registro de auditoría en la administración, métricas de Prometheus y herramientas de copia de seguridad y restauración.
• Webhooks con reintentos, un registro de envíos y más eventos (push, release).

Ideas sin versión asignada: su contenido está por definir.

• Agentes de IA en un repositorio. Posibilidades: un asistente de revisión en las solicitudes de fusión, resúmenes de solicitudes de fusión y de commits, la explicación de por qué falló un pipeline, triaje y etiquetado de incidencias. Lo que se publique debe encajar en una plataforma autoalojada: un endpoint de modelo que elige el administrador (también uno local), activación repositorio por repositorio, credenciales de alcance limitado y cada acción registrada.
• Un gráfico de commits en la vista del repositorio: ramas, fusiones y etiquetas dibujadas juntas, junto al árbol de archivos y a la lista de commits que ya existen.
• Fotos de perfil, guardadas en almacenamiento de objetos compatible con S3. Las iniciales quedan como alternativa, y ese mismo almacenamiento podría guardar más adelante los archivos de las releases y los artefactos de los pipelines.

ArtiFerris ya almacena paquetes npm e imágenes Docker/OCI y las analiza en busca de vulnerabilidades. FerrisGit y ArtiFerris son dos mitades complementarias de la misma cadena de entrega. El vínculo crece en tres pasos: publicar desde un pipeline (0.2), rastrear un artefacto hasta su commit (0.6) y traer los resultados del análisis a las comprobaciones de las solicitudes de fusión (0.6). La identidad compartida sigue siendo una cuestión abierta.