Skill: Descubrir arquitectura en un proyecto existente

Analiza la estructura y el código de un repositorio para identificar arquitectura implícita — elecciones de tecnología, patrones, convenciones o compromisos que están vivos en el código pero nunca se documentaron formalmente.

Cada hallazgo se traduce en artefactos de dos tipos (ver el skill arch-manage para la distinción completa):

• Un ADR — la decisión histórica: por qué se eligió algo. Todo hallazgo relevante produce un ADR candidato.
• Un requisito dentro de un estándar de dominio — la regla viva que el código sigue hoy (docs/standards/). El estándar es amplio (un dominio técnico o funcional entero: Testing Standards, API Standards…; un aspecto de arquitectura, no un dominio de negocio/DDD) y agrupa varios requisitos; cada requisito se redacta con RFC 2119/8174 (MUST/SHOULD/MAY…). Un hallazgo que es una norma continua y verificable propone un requisito, dentro del estándar de dominio que le corresponde (agrupándolo con otros del mismo dominio). La unidad verificable fina —el criterio de cumplimiento (CR-XXX), que pertenece a un requisito pero vive en la tabla única del estándar— la propone arch-manage al crear el artefacto, para que el usuario elija cuáles crear; en descubrimiento basta con proponer el requisito y su regla.

Ejemplo: detectar "unit tests con PHPUnit" y "e2e con Playwright" son dos decisiones (dos ADR), pero un solo estándar de dominio Testing Standards con dos requisitos («Unit testing», «E2E testing»). En cambio detectar "hubo una migración de Webpack a Vite" es una decisión histórica (ADR sin criterio de cumplimiento): no hay una norma continua que cumplir, solo un hecho.