Onboarding de repo por el tech lead¶
Este es el Nivel 3 del camino de adopción. Asume que ya tienes la organización (Nivel 1) y el proyecto inicializado (Nivel 2 — ver Configurar un Proyecto).
Mientras que Configurar un Proyecto cubre el rai init local, este nivel es la responsabilidad específica del tech lead: dejar el repositorio listo para que el equipo trabaje con confianza. Es un paso que se hace una vez por repo.
Qué logra este nivel¶
Al terminar, el repositorio tendrá: 1. Registro en la organización/servidor (los demás devs lo encuentran). 2. Un grafo de conocimiento construido (Rai "conoce" el código). 3. Los cartuchos de conocimiento presentes (metodología + dominio). 4. Una primera epic/story recorrida (el camino está trazado). 5. Gates verificados (el piso de calidad está activo).
1. Registrar el repo en la organización¶
El registro asocia este repositorio con tu organización en el servidor, para que los demás devs y las herramientas lo resuelvan por nombre.
Si el repo vive en otra ruta:
Verifica el registro:
Referencia: rai repo.
2. Construir el grafo de conocimiento¶
El grafo es la memoria estructural del repo: módulos, dependencias, patrones. Es lo que permite a Rai responder "¿dónde está X?" y "¿qué se rompe si cambio Y?".
Esto analiza el código desde el directorio actual (sin flag --project) y escribe el índice. Verifica con una consulta:
Para repos grandes (brownfield), corre primero un discovery scan — ver Configurar un Proyecto → Discovery Scan.
Referencia: rai graph.
3. Asegurar los cartuchos de conocimiento¶
Los cartuchos son paquetes de conocimiento de dominio que Rai consulta. Como tech lead, confirma que el repo tiene al menos los cartuchos base de metodología y, si aplica, el cartucho del repo.
Si faltan, instálalos/genéralos según tu organización. El cartucho del repo se autogenera al construir el grafo en proyectos configurados para ello.
Nota: la distribución automática de los cartuchos base durante
rai initestá en evolución — confirma con tu organización qué cartuchos deben estar presentes.
4. Trazar el camino: primera epic/story¶
Antes de invitar al equipo, recorre tú una primera epic o story completa. Esto valida que el pipeline, los gates y las integraciones funcionan, y deja un ejemplo real que el equipo puede imitar.
Sigue Tu Primera Story para el ciclo completo, o Pipeline Quickstart para arrancar el pipeline automatizado.
5. Verificar los gates¶
Los gates son el piso de calidad del repo (tests, lint, formato, tipos). Confirma que pasan en limpio antes de abrir el repo al equipo:
Un repo que entra al equipo con gates rojos enseña la lección equivocada. Déjalos verdes.
Siguiente nivel¶
Con el repo registrado, su grafo construido, cartuchos presentes y gates verdes, estás listo para incorporar al equipo → Onboarding de Equipo — Fase 2.