Monolito

Última actualización: 06-01-2026 09:01 PM

pDOCS — Backlog (monolito)

Backlog = lo que normalmente se llama roadmap: hacia dónde vamos, qué falta, en qué orden lo abordamos y qué criterios definen “listo”.

Este documento NO es un registro diario. Su función es mantener claridad de dirección y prioridades.

1) Propósito del plan

pDOCS existe para documentar proyectos personales con estructura estable, de modo que el trabajo pueda continuar sin perder contexto.

El plan define:

Qué significa “pDOCS funciona” (criterios de terminado).
Qué falta por construir o estabilizar.
Qué se prioriza primero y por qué.

2) Restricciones (no negociables)

Estas reglas limitan el espacio de solución:

Mantener pDOCS como sitio estático (SSG).
Evitar convertir pDOCS en una app.
Mantener la documentación pública por defecto.
Español como idioma raíz (sin /es).
Búsqueda global como camino principal.

3) Definición de “Listo” (DoD) para pDOCS v1

pDOCS se considera listo (v1) cuando se cumpla, como mínimo:

3.1 Estructura editorial estable

Existe una estructura estándar para proyectos basada en 3 monolitos: Contexto / Modularidad / Backlog.
Esa estructura se aplica a los proyectos nuevos y puede adoptarse progresivamente en proyectos existentes.

3.2 Plantillas utilizables

Existe una plantilla mínima para:
- Contexto (proyecto)
- Módulo (proyecto)
- Backlog (proyecto)
- ADR (decisiones)
Las plantillas son copiables y reducen fricción (sin campos “decorativos”).

3.3 Operación sin sorpresas

Crear proyecto y páginas nuevas es un flujo claro y repetible.
Hay una prueba de humo local (build, búsqueda, dist/pagefind).
Hay una prueba de humo en producción (pagefind.js, sitemap si aplica).

3.4 Búsqueda consistente

La búsqueda global funciona siempre.
El patrón de búsqueda por proyecto existe cuando aporta valor (/proyectos/<slug>/buscar/) y se entiende cómo se implementa.

3.5 Diagramas entendibles

Existe un estándar único para diagramas (D2 visible + fallback Mermaid para consumo por LLM) y se aplica cuando hay diagramas.

3.6 Decisiones registradas

Las decisiones relevantes se capturan con ADR (cortos y con consecuencias).

4) Enfoques (líneas de trabajo)

Este plan se organiza por “líneas” para mantener control y evitar mezclar mejoras:

Arquitectura editorial: cómo se organiza la información (monolitos y navegación).
Operación: cómo crear/editar sin romper el sistema.
Calidad: evitar errores repetidos (frontmatter, duplicados, encoding, pagefind).
Experiencia de lectura: navegación, consistencia, claridad.
Compatibilidad con LLM: formatos, “fallbacks” y guías para continuidad.

5) Prioridades (Ahora / Luego / Después)

5.1 AHORA (bloque de estabilización)

A1. Reorganizar la documentación del propio pDOCS a 3 monolitos

Objetivo: que pDOCS predique con el ejemplo.
Entregable: tres documentos editables (Contexto, Modularidad, Backlog) y una navegación coherente.

A2. Mantener el estándar de Diagramas como guía transversal

Objetivo: que cualquier documento use diagramas de forma consistente.
Entregable: guía única en Modularidad/diagramas.md y referencias desde monolitos (sin duplicar reglas).

A3. Definir plantilla base para proyectos (3 monolitos) dentro de pDOCS

Objetivo: que crear un proyecto nuevo sea copiar/pegar y rellenar.
Entregable: páginas “Plantillas” o sección equivalente en Modularidad.

A4. Normalizar nombres

Objetivo: nombres consistentes en sidebar.
Entregable: decidir nombres finales (p.ej. Contexto / Modularidad / Backlog) y mapear lo existente.

5.2 LUEGO (bloque de escalamiento)

L1. Scaffold (plantilla automática) para nuevo proyecto

Objetivo: reducir fricción y errores humanos.
Entregable: guía (y si se decide, script) para crear la carpeta del proyecto con 3 monolitos listos.

L2. Reglas de consistencia (guardrails)

Objetivo: prevenir errores antes de que lleguen a producción.
Ideas:
- Validar que toda página tenga title.
- Detectar duplicados de rutas/ids.
- Checklist editorial más estricto para merges.

L3. Convenciones de enlaces y navegación interna

Objetivo: asegurar que cada proyecto sea “recorrible” de forma predecible.
Entregable: convenciones sobre “puntos de entrada”: Contexto, Modularidad, Backlog.

5.3 DESPUÉS (mejoras opcionales)

D1. Refinamiento de i18n

Objetivo: soportar /en con reglas claras y sin traducciones incompletas.

D2. Mejoras de búsqueda

Objetivo: facilitar encontrar por “tipo de página” (Contexto/Modularidad/Backlog) o por etiquetas.

D3. Sección Documentación transversal

Objetivo: separar guías transversales reutilizables (Unity, Web, pipelines) de los proyectos.

6) Decisiones (estado actual)

Estas decisiones afectan estructura y escalabilidad:

Nombre final del tercer monolito: Backlog
Dónde viven las plantillas

Opción A: dentro de Modularidad como sección Plantillas.
Opción B: página dedicada dentro de pDOCS (p.ej. /proyectos/pdocs/plantillas/).

Nivel de automatización

¿Solo guías (copy/paste) o también scripts/generadores?

7) Criterios de calidad (reglas prácticas)

La documentación debe ser operacional: si alguien la sigue, obtiene el resultado.
Se evita duplicación: un tema vive en un solo lugar.
Cada sección existe para responder una pregunta:
- Contexto: ¿qué es y bajo qué reglas?
- Modularidad: ¿cómo se hace y cómo funciona?
- Backlog: ¿qué falta y qué se prioriza?