Tu stack
El repositorio que ya tienes, o uno empezado desde cero
El reconocimiento es un atajo, nunca un requisito. Un repositorio cuyos marcadores conocemos recibe gratis sus comandos de instalación, arranque y verificación; uno que no conocemos queda registrado como no reconocido, y tu propio modelo escribe esos comandos contra el árbol que tiene delante.
01Tu stack
Tu repositorio tal como está, o uno nuevo desde cero.
La lista de abajo es un atajo, no una puerta. Un stack que reconoce recibe sus comandos de compilación, pruebas y linter sin preguntar a nadie; uno que no reconoce queda registrado como no reconocido y es tu propio modelo quien escribe los comandos.
- El repositorio que ya tienes
- Cualquier lenguaje, incluidas las partes que nadie quiere abrir. Leemos el árbol, sembramos los comandos que podemos y decimos con claridad cuáles hemos deducido.
- Todo lo que la lista no incluye
- Queda registrado como no reconocido en lugar de forzarlo a la fila más parecida. Los comandos de compilación, pruebas y linter se escriben entonces contra tu repositorio en vez de leerse de una tabla, y la ejecución dice cuál de las dos cosas pasó.
- Un proyecto nuevo desde cero
- Un repositorio vacío se monta con el framework de la casa, mediante el generador del propio framework. No empaquetamos plantillas, y un árbol existente nunca se reescribe para meterlo en un framework: eso es un cambio que aprueba una persona, no un andamiaje.
Reconocidos de serie
- Bun
- Node
- Python
- Go
- Rust
- Ruby
- ultimate
Nada de esto exige un stack reconocido. La lista de reconocidos solo decide si los primeros comandos llegan gratis.
Cómo se recoge un repositorio
Reconocido por un archivo marcador
La detección lee el primer nivel del checkout y nada más: bun.lock, package.json, pyproject.toml, requirements.txt, setup.py, go.mod, Cargo.toml, Gemfile. Gana el marcador más específico, así que un lockfile junto a un manifiesto decide la fila. No se descarga nada por la red ni se deduce nada del nombre del repositorio.
No reconocido no es rechazado
Un árbol sin ningún marcador conocido queda registrado como no reconocido, en vez de empujarlo a la fila más parecida. Entonces tu propio modelo lee el repositorio y escribe los tres comandos, y el registro de la ejecución dice cuál de las dos cosas ocurrió.
Tus comandos mandan
Los comandos predefinidos aterrizan como scripts en el repositorio y toda escritura respeta lo que ya existe. Un script de instalación, arranque o verificación que ya traigas sobrevive intacto, y el que reescribas después se queda reescrito.
Por qué importan los comandos
El comando de verificación es lo que ejecuta un agente para demostrar su propia pull request, y lo que ejecuta la revisión profunda sobre un diff. Un repositorio con tres comandos reales se corrige de forma mecánica; uno sin ninguno se revisa sin ese control.
La lista es un atajo, no un techo
La lista de stacks reconocidos existe para que un repositorio que sabemos nombrar de forma mecánica tenga un control que funcione antes de preguntarle nada a un modelo. No decide nada más. Un repositorio fuera de la lista se clona igual, se lee igual, se trabaja igual y abre pull requests igual; lo que pierde es el trío de comandos gratis, y lo recupera en cuanto tu propio modelo escribe los tres comandos por su cuenta. Esa es toda la letra pequeña, y preferimos imprimirla antes que vender una lista de lenguajes que no mantenemos.
Empezar desde cero
Un único framework de la casa
Un repositorio vacío se monta ejecutando el generador del propio framework de la casa, no copiando plantillas que guardemos aquí. No empaquetamos nada, así que recibes lo que ese framework publica hoy y no una copia vieja.
O la estructura de la casa en tu stack
Si pides otro stack en un repositorio nuevo, lo que recibe es la estructura de repositorio de la casa: Bun, Node, Python, Go, Rust, Ruby. Un stack fuera de esa lista se rechaza por su nombre, con el motivo en el registro, en lugar de caer en silencio en una base vacía.
Un árbol existente nunca se reescribe
No hay comando de migración ni lo habrá. Aplicar un framework a un repositorio que ya tiene código es una reescritura que aprueba una persona, así que el generador la rechaza por su nombre en vez de recortarla a un trabajo parcial que parece un éxito.
Siguiente
Dónde seguir leyendo
- Cómo funciona
El ciclo que sigue una ejecución sobre tu repositorio, desde la incidencia hasta la pull request fusionada.
- Instalación
Qué permisos pide la GitHub App, qué necesita el runner en tu máquina y qué pasa en la primera pasada.
- Documentación
El archivo de política, el trío de comandos, los artefactos que escribe una pasada de preparación y los códigos de salida que puede usar un control.
- Solicitar acceso
El acceso es solo por invitación mientras crece la flota. Cuéntanos qué repositorios quieres que recojamos primero.
Publica más. Mantén menos.
Creemos que el software se va a escribir más rápido de lo que cualquier equipo puede revisar. Trae tus repositorios, tus servidores y tus claves. Nosotros ponemos la organización que sigue el ritmo.