Cómo registrar un repo

Hay dos registros y sirven para cosas distintas. El catálogo lista todos los repos de ingeniería y enlaza a GitLab. El manifest de agregación copia los docs/ de unos pocos repos hacia el portal.

Registro	Archivo	Alcance	Qué produce
Catálogo	`repos-inventory.json`	Todos los repos	Una fila en `/repos/` con el enlace a GitLab
Agregación	`docs-manifest.yaml`	Solo los repos registrados	Las páginas del repo publicadas en `/repos/<slug>/`

Todo repo va en el catálogo. La agregación es opt-in y deliberada: se reserva para los servicios Tier-1, donde está el riesgo de estabilidad. Un repo agregado también aparece en el catálogo, con un enlace adicional hacia sus docs.

Agrega un repo al catálogo

Abre repos-inventory.json y agrega una entrada al grupo de su disciplina. Los grupos son frontend, backend, qa, infra y platform.

{
  "url": "https://gitlab.com/crehana-team/platform/platform-radar",
  "name": "platform-radar",
  "product": "Engineering Platform",
  "module": "initiative-hub",
  "owner": "platform"
}

Completa los campos. Todos son obligatorios salvo module.

Campo	Qué es
`url`	La URL del proyecto en GitLab, con `https://`
`name`	El nombre que se muestra en la tabla
`product`	El producto al que sirve el repo
`module`	Opcional. El módulo dentro del producto
`owner`	El squad o equipo dueño

Regenera el catálogo y valida:
```
pnpm run build
```
Deberías ver el conteo actualizado:
```
✓ catalog: 3 repos, 0 registered for aggregation
```

La página /repos/ se genera desde este archivo en cada build. Nunca la edites a mano. Un JSON malformado o una entrada sin un campo obligatorio rompen el build nombrando la entrada culpable.

Agrega los docs de un repo al portal

Antes de registrar un repo en el manifest, ese repo necesita:

Una carpeta docs/ con al menos una página en .md o .mdx
Un CODEOWNERS que cubra esa carpeta, para que sus docs pasen por revisión

Después:

Agrega una entrada a docs-manifest.yaml:

repos:
  - slug: checkout-service
    name: checkout-service
    gitlab_path: crehana-team/backend/checkout-service
    docs_path: docs
    owner: squad-payments

Elige el slug con cuidado. Define la URL en /repos/<slug>/ y no cambia nunca, ni siquiera cuando el repo se mueve dentro de GitLab. Si el repo se mueve, actualiza gitlab_path y conserva el slug: las URLs del portal siguen funcionando.
Si el repo es privado, exporta un token de lectura antes de agregar:
```
export AGGREGATION_TOKEN=<token de lectura de GitLab>
```
Trae los docs y construye:
```
pnpm run aggregate
pnpm run build
```

Verificación

pnpm run aggregate reconstruye desde cero todo docs/<locale>/repos/<slug>/, así que el portal siempre es reproducible desde el manifest y los repos de origen. Deberías ver:

  checkout-service: 3 page(s) from crehana-team/backend/checkout-service@main (a1b2c3d)
✓ aggregate: 1 repo(s) pulled into es + en

Abre /repos/checkout-service/ y confirma que cada página muestra su encabezado de procedencia con el repo, el commit, la fecha y el owner. Una página agregada sin procedencia rompe el build.

Qué pasa con el idioma

Las páginas agregadas se copian tal como están en el repo de origen, a los dos árboles de idioma. No se traducen: quien las escribió es dueño de su contenido, y el portal solo las publica con su procedencia.

Relacionado

Cómo contribuir al portal — el flujo de una página escrita a mano

#Cómo registrar un repo

#Agrega un repo al catálogo

#Agrega los docs de un repo al portal

#Verificación