Contribuir

Las contribuciones son bienvenidas: reportes de bugs, ideas de features, correcciones de documentación y código. El proyecto vive en github.com/isaias-alt/vexillum.

Reportar un bugCopiar enlace

Abrí un issue y elegí la plantilla de bug report. Un buen reporte permite que otra persona reproduzca el problema sin preguntarte nada. Incluí:

• Qué pasó, y qué esperabas que pasara.
• Los pasos exactos para reproducirlo, idealmente desde un proyecto limpio.
• La salida de vx --version y de vx doctor, y tu sistema operativo y arquitectura.
• Cualquier salida, log o captura relevante.

Buscá primero entre los issues abiertos. Si el problema ya está reportado, sumá lo que sepas ahí en vez de abrir un duplicado.

Proponer una featureCopiar enlace

Abrí un issue y elegí la plantilla de feature request antes de escribir código. Describí el problema que querés resolver, no solo la solución: ¿qué estabas haciendo cuando encontraste la falta? Después contá qué proponés y qué alternativas consideraste. Acordar la forma de un cambio en un issue sale más barato que rehacer un pull request terminado.

Enviar un pull requestCopiar enlace

1. Hacé un fork del repositorio y creá una rama desde canary, la rama por defecto. Mantené cada rama chica y enfocada en una sola cosa.
2. Hacé el cambio y agregá o actualizá tests. Los tests usan el paquete testing de la librería estándar de Go.
3. Poné el título del pull request, y escribí los mensajes de commit, como conventional commits con prefijo feat:, fix: o docs:. Mantienen el historial legible y dicen de un vistazo qué hace cada commit.
4. Corré los chequeos antes de pushear:

go build ./...
go vet ./...
go test ./... -race

Si cambiaste el sitio de documentación, corré también esto desde el directorio site, uno tras otro y nunca al mismo tiempo:

pnpm lint
pnpm build
pnpm seo:audit

El CONTRIBUTING.md del repositorio lista el conjunto completo de chequeos, incluidos los de links que corre CI.

Actualizar la documentaciónCopiar enlace

Un pull request que cambia comandos, comportamiento, configuración o skills también debe actualizar la documentación, en inglés y en español, en las mismas páginas y en la misma posición del menú. Las páginas de la referencia del CLI se generan desde el binario: regeneralas en vez de editarlas a mano y commiteá el resultado. CONTRIBUTING.md tiene el comando exacto. Un pull request que cambia el núcleo sin tocar la documentación no está completo.

Actualizar los avisos de tercerosCopiar enlace

THIRD-PARTY-NOTICES.md se genera, nunca se edita a mano. Después de cambiar el bundle de la whiteboard, su package-lock.json o las fuentes vendoreadas, corré cd tools/whiteboard-bundle && npm ci && npm run notices y commiteá el resultado. go test ./internal/thirdparty falla si los avisos quedaron desactualizados. tools/whiteboard-bundle/README.md explica qué lee el generador y cuándo se niega a correr.

Instalar tu propio buildCopiar enlace

Los maintainers pueden instalar el checkout actual como su vx-dev local con scripts/install-local.sh. Se niega a instalar con un checkout sucio o en una rama que no sea canary, verifica que el vx --version del binario recién compilado reporte HEAD, guarda el binario anterior como vx-dev.prev al lado para volver atrás en un paso, y reemplaza vx-dev de forma atómica. El vx estable viene de Homebrew, así que el build de desarrollo nunca toma su nombre. Definí VX_INSTALL_DIR para cambiar el destino (por defecto ~/.local/bin), o pasá --force para saltear las guardas de checkout limpio y de rama. Un build de desarrollo imprime su identidad, por ejemplo vx dev (a1b2c3d, 2026-10-05, dirty).

AlcanceCopiar enlace

vexillum corre en Claude Code, Pi y OpenCode. El soporte para otro agente no es un pull request para abrir en frío: discutilo primero en un issue, así la dirección queda acordada antes de escribir código.

Qué esperar de la revisiónCopiar enlace

Los pull requests se revisan por corrección, tests, la regla de documentación de arriba y encaje con la dirección del proyecto. Esperá preguntas y pedidos de cambios; son sobre el cambio, no sobre vos. Los pull requests chicos y enfocados se revisan más rápido. Cuando los chequeos pasan y la revisión está atendida, un maintainer lo mergea.

Ver Land vs ship para saber cómo vexillum convierte una mission en un pull request.