Prompt de rollout: documentar un repo y darlo de alta en el portal

Versión canónica. Copiá el bloque de abajo, completá los dos parámetros y pegalo en un agente (Claude Code) abierto en la raíz del repo a documentar. El agente hace todo en una sola pasada — documenta, hace el triage de la documentación preexistente sin bloquearse esperando decisiones humanas, publica directo en RAMA_BUILD, da de alta el repo en el portal y verifica lo publicado — y entrega al final la tabla de triage y la checklist corta de pasos humanos.

Si un rollout encuentra un problema nuevo, se agrega acá como verificación: este prompt se calibra con esfuerzo real medido, igual que las plantillas.

Tu tarea es documentar este repositorio según el estándar de Compulandia
(docs-standard) y dejarlo listo para su alta en el portal
https://docs.compulandia.com.py. Trabajá en una sola pasada completa: nada
queda bloqueado esperando a un humano; lo que no puedas determinar se
resuelve con las reglas de triage de la FASE 2.

PARÁMETROS (completados por quien pega este prompt):
- RAMA_BUILD: {{rama que el portal importará, ej: main | develop}}
- TITULO_NAV: {{título de la sección en el portal, ej: "OMS Frontend"}}
  ⚠ El título define la URL: ej:"OMS Frontend" → docs.compulandia.com.py/oms-frontend/

FASE 0 — RELEVAMIENTO (no escribas nada todavía)
1. Cloná https://github.com/CompulandiaTI/docs-standard en un directorio
   temporal y leé su estructura completa: es el template a replicar y
   contiene el estándar (README ≤40 líneas, docs/, taxonomía de directorios
   opcionales, ADRs formato MADR, AGENTS.md, front-matter obligatorio).
2. Detectá del repo actual: URL real del remoto (usá ESE nombre, no el que
   digan otros documentos), rama default, documentación existente en
   CUALQUIER ubicación (docs/, raíz, otras carpetas), y qué comandos reales
   existen (package.json, Makefile, CI).
3. Revisá el .gitignore: si ignora /docs (u otra carpeta que vayas a usar),
   corregilo. Verificá con `git check-ignore` que todo lo nuevo sea
   versionable.

FASE 1 — ESTRUCTURA
Replicá del template: README.md (máx. 40 líneas: qué es, stack, levantar en
local, healthcheck), AGENTS.md (comandos, convenciones, restricciones — SIN
sección "Arquitectura"), symlink CLAUDE.md → AGENTS.md, docs/index.md
(portada breve del sistema, NO copies el índice del estándar), mkdocs.yml
(copiá el del template, cambiá site_name y armá el nav con tus páginas), y
.github/workflows/notificar-portal.yml (copialo del template y poné
branches: [RAMA_BUILD]).
Si CLAUDE.md ya existe como archivo con contenido: fusioná lo vigente
dentro de AGENTS.md y recién después reemplazalo por el symlink.

FASE 2 — TRIAGE NO BLOQUEANTE DE DOCUMENTACIÓN PREEXISTENTE
Si el repo ya contiene documentación previa al estándar (*.md sueltos,
carpetas de análisis, RFCs, post-mortems, contratos, notas):
1. Inventariá TODOS los documentos y clasificalos por tipo según la
   taxonomía: analisis / incidentes / estandares / integraciones / rfc /
   working file (avances, backlogs, *.progress.md).
2. Aplicá la regla automática de destino — no esperes decisión humana:
   - Contenido sensible (credenciales, datos reales de clientes, cuentas,
     detalles de infraestructura innecesarios) → fuera del control de
     versiones: carpeta gitignorada (y `git rm --cached` si estaba
     trackeado). NO se publica al portal NI se commitea — _borradores/
     solo lo esconde del portal, no de GitHub.
   - Working files → docs/_borradores/.
   - Archivos no-markdown sin función documental (PDFs, dumps, base64,
     binarios) → fuera de docs/ (carpeta gitignorada) y fuera del índice
     de git si estaban trackeados.
   - Todo lo demás → al directorio de la taxonomía que corresponda, con
     nombre kebab-case (incidentes: AAAA-MM-tema.md), front-matter
     agregado y estado: borrador. Si la vigencia es dudosa (ej. análisis
     previos a un fix posterior), agregá al inicio una nota
     "⚠ Vigencia por confirmar" — se publica igual, marcado.
   - Documentos claramente históricos/ejecutados → publicalos con
     estado: obsoleto y nota de qué los reemplaza.
3. Al mover cada documento: arreglá los links que salgan de docs/ (a código:
   URL absoluta de GitHub) y sanitizá datos sensibles puntuales si el resto
   del documento es publicable.
4. Armá la TABLA DE TRIAGE para el reporte final:
   archivo → tipo → destino → estado asignado → ¿requiere revisión humana?
   CADA documento encontrado aparece en la tabla — ninguno excluido en
   silencio. La revisión humana es POSTERIOR al rollout y se guía por esta
   tabla.
Nota: _borradores/ queda fuera del portal porque docs-portal lo excluye en
su propio mkdocs.yml (el portal ignora el exclude_docs de los repos
importados — no confíes en el del repo, que solo afecta la vista local).

FASE 3 — CONTENIDO (solo hechos verificables, nada inventado)
- docs/arquitectura.md: componentes reales, tabla de dependencias externas
  con "¿qué pasa si no está?", diagrama Mermaid, UN flujo principal narrado.
- docs/runbook.md: deploy real (leé los workflows de CI y scripts de deploy
  que existan), dónde están los logs, rollback, y las 3 fallas más
  frecuentes CON EVIDENCIA (troubleshooting existente, historial de git,
  post-mortems del triage). Si no encontrás evidencia de fallas reales,
  dejá la sección con un TODO explícito — no inventes fallas hipotéticas.
- docs/adr/: máximo 3 ADRs retroactivos de decisiones VIGENTES que aún se
  re-discuten, formato MADR del template. Si la fecha de la decisión no
  está registrada, decilo. Índice en docs/adr/README.md.
- Todo documento generado lleva front-matter: generado_por, revisado_por:
  pendiente, fecha, estado: borrador.

FASE 4 — VERIFICACIÓN (obligatoria antes de commitear)
1. Build estricto local (el mismo modo que usa el portal; si falla acá,
   rompe el deploy del portal):
     python3 -m venv /tmp/mkdocs-venv && /tmp/mkdocs-venv/bin/pip install mkdocs-material
     /tmp/mkdocs-venv/bin/mkdocs build --strict
2. Escaneo de secretos sobre TODO lo publicable (docs/ completo incluyendo
   lo migrado en el triage, README, AGENTS.md, mkdocs.yml): tokens,
   passwords, claves privadas, JWTs, datos reales de clientes.
   Placeholders tipo <jwt> o {{ejemplo}} están bien.
3. Contá las líneas del README: máximo 40.

FASE 5 — PUBLICACIÓN (flujo directo: sin ramas alternativas ni PRs)
1. Commiteá directo en RAMA_BUILD con un mensaje que referencie el
   estándar, y pusheá. En estos repos trabaja un solo desarrollador: la
   revisión es posterior, guiada por la tabla de triage.
2. Import en el portal: cloná CompulandiaTI/docs-portal, agregá al nav:
   de su mkdocs.yml la línea
     - TITULO_NAV: '!import <URL-real-del-repo>?branch=RAMA_BUILD'
   y pusheá directo a main (dispara el deploy, ~2 min). Sin acceso al
   portal: dejá la línea exacta en el reporte final como paso humano.
3. Verificá lo publicado (esperá 2-3 minutos tras el push al portal):
   - La sección aparece en https://docs.compulandia.com.py/<slug>/.
   - La búsqueda del portal devuelve un término distintivo de este repo.
   - NINGÚN documento de _borradores/ aparece en el portal ni en su
     búsqueda.
   - El workflow "Notificar portal de docs" de este repo quedó en verde.
   Si algo falla, diagnosticá con el runbook del portal
   (https://docs.compulandia.com.py/runbook/, fallas frecuentes 1 y 2).
   Aviso: si tu red recibe redirección a cloudflareaccess.com, la
   verificación por HTTP no es posible desde donde estás (el portal está
   tras Cloudflare Access, con bypass solo para la red de la oficina) —
   pasale estos chequeos al humano para verificar en navegador.
4. Entregale al usuario: (a) la TABLA DE TRIAGE completa, (b) el resultado
   de la verificación del punto 3, y (c) esta checklist de pasos humanos
   con los valores ya completados para este repo:
   □ Confirmar que el secret de organización PORTAL_DISPATCH_TOKEN
     alcanza a <repo> (ya existe a nivel CompulandiaTI y se hereda
     automáticamente; solo un repo excluido de su visibilidad necesitaría
     uno propio)
   □ Verificar que el MULTIREPO_ACCESS_TOKEN de docs-portal tenga lectura
     sobre <repo>
   □ Revisar la tabla de triage: confirmar vigencias (borrador → validado),
     decidir los marcados "requiere revisión humana"
   □ Validación real: otro dev levanta el sistema siguiendo solo el README
   □ Registrar horas invertidas y pasar los front-matter a estado: validado

RESTRICCIONES
- No inventes: cada afirmación de arquitectura/runbook sale del código, la
  configuración o documentación existente. Lo que no sepas, marcalo como
  pendiente y decilo en el resumen final.
- Fuera de este repo, lo único que tocás es la línea !import en el
  mkdocs.yml de docs-portal — ningún otro archivo ni repo.
- No publiques secretos ni datos reales de clientes, tampoco en ejemplos.
- Ante la duda sobre un documento del triage: _borradores/ y a la tabla —
  nunca borrado, nunca publicado con datos sensibles, nunca omitido del
  reporte.