Skip to content

ADR-0016: Convención de IDs para diseños y estudios — sin prefijo DES

Status

PROPOSED (2026-09-08, conversación directa con el operador). La decisión adoptada por el operador: "vamos con ADR-*, creamos un ADR y lo trabajamos, para luego lanzar el proyecto".

Contexto

Durante la formalización de la convención de IDs del Knowledge Plane (2026-09-07) el lead introdujo el prefijo DES-* para las memorias técnicas / architecture packs de proyecto (6 ficheros architecture/design/ migrados del repo docs sin frontmatter original). El prefijo no estaba en el plano original (DES- era gradual) y el operador lo cuestiona: la jerarquía ya tiene ARCH-*, ADR-*, SVC-*, RUN-*, PROC-*, PROJ-*, REF-* — un diseño o estudio nuevo debe tener cabida en los existentes.

Decision

  1. No usar el prefijo DES-*. Un diseño o estudio nuevo se documenta directamente como ADR-NNNN con status: proposed. Un ADR proposed es trabajable: se itera en su ficha hasta accepted, y al aceptarse se lanza el proyecto. No hay un documento de diseño paralelo previo.
  2. Los sub-planes de implementación, inventarios y estudios de apoyo de ese ADR (lo que antes eran los "planes largos") van a records/REC-<YYYYMMDD>-<slug> como evidencia derivada, referenciados desde el ADR (related). Nunca como documentos paralelos de decisión.
  3. Re-etiquetado histórico: los 6 packs migrados con id: DES-* pasan a id: ARCH-<SLUG> con status: draft (describen arquitectura no desplegada o log de decisiones; no son decisiones aceptadas). Los ficheros permanecen en architecture/design/.
  4. Plantilla: _templates/design-pack.md se retira; los proyectos nuevos siguen el flujo: ADR proposed (trabajar) → accepted (lanzar) → SVC ficha al desplegar, con OBJ como contrato de proyecto cuando aplique.
  5. La skill docops (§14) se actualiza a esta convención (sin DES en el lifecycle).

Consequences

Positivas - Menos prefijos; el mapa mental del operador (ARCH/ADR/SVC/RUN/PROC/PROJ/REF) queda intacto — no se añade una categoría nueva a memorizar. - El ciclo de un diseño queda unificado en el lifecycle de ADR (proposed→accepted→superseded), que ya tiene herramienta: status + related. - Los ADRs proposed dejan trazabilidad del trabajo de diseño (quién, cuándo, alternativas descartadas), que un pack suelto no garantizaba.

Negativas / mitigaciones - Un ADR no sustituye un estudio largo con múltiples secciones → los anexos de análisis van como records (REC-) referenciados; el ADR queda como decisión + resumen. - Los 6 ficheros históricos cambian de ID → se actualiza el id-registry y se deja mapeado el cambio en el frontmatter (source_provenance).

Riesgos

  • Re-etiquetado puede romper wikilinks existentes (related: [DES-*]) → buscar y reemplazar en el mismo PR.
  • La CI validate.yaml acepta DES (regex legacy) — quitarlo de la tabla de naming para que no vuelva a usarse; el regex no se endurece (los legacy REF/PROC/ARCH siguen aceptados).

Alternatives considered

  • Mantener DES-* formalizado (implementado el 2026-09-07, f0f3304): descartado por el operador — preferencia por no introducir categorías nuevas cuando las existentes cubren el caso.
  • Todo diseño = ARCH proposed: rechazado — ARCH es la vista de lo desplegado; mezclarlo con propuestas diluye la autoridad del inventario.