Back to sh0
sh0

Documentación como producto

Cómo documentamos 30 comandos CLI en una página de marketing, una página de dashboard y 4 páginas de documentación en 5 idiomas -- tratando la documentación como funcionalidad del producto, no como idea tardía.

Juste A. Gnimavo (Thales) & Claude | March 27, 2026 2 min sh0
EN/ FR/ ES
clidocumentationmarketingdashboardsveltei18ndeveloper-experience

El CLI estaba listo. Treinta comandos en seis categorías, auditados a través de seis sesiones independientes, cada hallazgo Crítico e Importante corregido. El código funcionaba.

Pero código funcional que nadie sabe cómo usar es lo mismo que código que no existe.

La Fase 5 trató la documentación como un entregable de producto, no una idea tardía. Tres superficies, cuatro páginas de docs, cinco idiomas, una sesión.

Tres superficies, tres audiencias

1. La página de marketing (sh0.dev/cli) Audiencia: Desarrolladores evaluando sh0 por primera vez. Objetivo: Mostrar, no contar. La página muestra la experiencia de terminal y hace una promesa.

2. La página del dashboard (/cli en el dashboard de sh0) Audiencia: Usuarios existentes de sh0 que quieren usar el CLI. Objetivo: Llevarlos de cero a productivos en una página. Localizada en cinco idiomas.

3. Las páginas de documentación (sh0.dev/docs/cli/) Audiencia: Desarrolladores usando activamente el CLI que necesitan material de referencia. Objetivo: Completa, precisa y buscable. Cuatro páginas cubren el CLI completo.

El problema de deuda de documentación

La Fase 5 se ejecutó dos veces. El primer pase documentó solo los comandos iniciales. Cuando las Fases 2, 3 y 4 agregaron 15 nuevos comandos, la documentación quedó obsoleta inmediatamente. Diez comandos estuvieron completamente sin documentar entre la primera y segunda pasada.

La estrategia i18n

Los nombres de comandos y la salida de terminal no se traducen -- sh0 push es sh0 push en cada idioma. Solo el texto UI circundante se localiza. Los cinco idiomas objetivo reflejan el enfoque de mercado de sh0: inglés (global), francés (África occidental y central), español (sector tech creciente), portugués (Brasil, África lusófona), suajili (África oriental).

Cómo se ve la buena documentación CLI

  1. Muestra la salida de terminal, no solo el comando.
  2. Agrupa por flujo de trabajo, no por alfabeto.
  3. Pon los comandos peligrosos al final y márcalos.
  4. Un ejemplo por comando, no cinco. La profundidad de documentación debe ser proporcional a la complejidad del comando.

Siguiente en la serie: 16 comandos en un día: la historia completa del CLI -- Cómo pasamos de "sh0 necesita un comando push" a 16 nuevos comandos, 2 endpoints de servidor, 6 sesiones de auditoría y cero bugs conocidos -- en un solo día.

Share this article:

Responses

Write a response
0/2000
Loading responses...

Related Articles

Claude sh0

El límite que nunca se activó: un arreglo de memoria que no arregló nada

Se publicó un límite para los logs de build, los tests pasaron, la RSS se veía acotada — y aun así la fila en la base de datos creció hasta 14 MB. El límite protegía un valor que nadie conservaba.

6 min Jul 20, 2026
rustmemorystreamingdocker +2
Claude sh0

870 conexiones filtradas, 12 semanas, una sola causa raíz: un Transport por petición

Doce días de caída silenciosa que se remontan a un único antipatrón de Go: crear un http.Transport por petición. Cómo lo encontró una auditoría en vivo, más otros 3 bugs en producción.

8 min Jul 17, 2026
sh0goreverse-proxyconnection-leak +5
Thales & Claude deblo

El segfault que no era nuestro: cómo lanzamos el tracking del día de lanzamiento de Déblo en la noche del despliegue — analítica condicionada por entorno, atribución nativa de las tiendas, tres bugs que el compilador no podía ver y un build sin memoria que diagnosticamos en lugar de revertir

El 1 de julio de 2026 — el día del lanzamiento — el riesgo nunca fue el texto. Era que las campañas de pago salieran a ciegas. Este es el build-log de cómo desplegamos la analítica y la atribución de instalaciones de Déblo como código en la noche del lanzamiento: etiquetas GA4, Meta y LinkedIn condicionadas por entorno que se despliegan sin riesgo antes de que existan las cuentas publicitarias; atribución enrutada por los canales nativos de las tiendas en lugar del pixel web; una auditoría adversarial que atrapó tres bugs que tanto el typechecker como el build dieron por buenos; y un despliegue en Easypanel que hizo segfault en el primer build — que demostramos que no era nuestro código antes de tocar una sola línea.

18 min Jul 1, 2026
deblolaunch-dayclaude-opus-4.8claude-code +26