@ingcrea/aumic-puf 0.0.0-stage → 3.1.0

package/MANIFEST.es.md

@@ -0,0 +1,172 @@
+# 📜 MANIFIESTO ARQUITECTÓNICO: ESTÁNDAR AUM-IC 7
+
+> 🌍 **Navegación:** 🇲🇽 [Leer en Español](./MANIFEST.es.md) | 🇺🇸 [Read in English](./MANIFEST.md) | 📖 [README (ES)](./README.es.md)
+
+Este documento rige el **Paradigma de Universos Multidimensionales de Ingeniería Creativa (Estándar AUM-IC 7)**. No es solo una guía de carpetas; es una estructura física, matemática y de ingeniería de software diseñada para cumplir de manera nativa con las normativas internacionales de calidad **ISO/IEC 25010** e **ISO 27001**.
+
+---
+
+
+> 🏆 **LA VISIÓN AUM-IC:** Todo proyecto creado desde su inicio o migrado íntegramente al Paradigma AUM-IC es un proyecto que aspira al cumplimiento nativo de los más altos estándares globales. Al adoptar esta arquitectura, el sistema hereda las aristas de calidad de software (**ISO/IEC 25010**), blinda su infraestructura bajo máxima seguridad y privacidad corporativa (**ISO 27001, ISO 27701, SOC 2**), garantiza su testabilidad (**ISO 29119**) y asegura la inclusión y posicionamiento absoluto mediante un código semánticamente perfecto (**ISO 40500 / WCAG / SEO**).
+
+
+## 🌌 El Porqué Fundamental: Entropía vs. Perfección Matemática
+
+**La programación creada por humanos es entropía pura.** Es energía caótica que se dispersa: código espagueti, dependencias circulares, sistemas que se degradan con el tiempo y lógicas que colapsan. 
+
+El Universo real, aunque a simple vista parece caótico, es **brutal y matemáticamente preciso**. Desde la física cuántica hasta la mecánica celeste, todo obedece a un diseño quirúrgico impecable. 
+
+**El Paradigma AUM-IC nace para llevar la programación a esta perfección matemática universal.** Somete el caos del código a las leyes de la física cósmica. Es un modelo mental absoluto, **100% agnóstico al lenguaje** (TypeScript, Python, Rust, Go, C#), que divide el desarrollo en Materia Observable, Fuerzas Invisibles y Leyes del Tiempo.
+
+---
+
+## PARTE I: LA MATERIA OBSERVABLE (Estructura Fractal)
+
+El Principio Hermético dicta: *"Como es arriba, es abajo"*. El ensamblaje de componentes sigue un ordenamiento jerárquico estricto. **Esta regla aplica simétricamente para la Interfaz (UI), las APIs (Controladores) y las Bases de Datos (Modelos).**
+
+Para detener la entropía, los directorios utilizan obligatoriamente prefijos numéricos:
+
+### ⚛️ Nivel 1: Átomos (`1-atoms/`)
+* **Concepto:** La unidad base indivisible (Botones en UI / Helpers y Utils puros en Backend).
+* **Regla:** 100% ignorantes. No importan otros archivos, no hacen peticiones, no tienen estado.
+
+### 🧬 Nivel 2: Moléculas (`2-molecules/`)
+* **Concepto:** La unión de dos o más átomos (Campos de formulario en UI / Middlewares y Validadores en Backend).
+* **Regla:** Tienen propósito específico pero carecen de lógica de negocio profunda.
+
+### 🦠 Nivel 3: Células (`3-cells/`)
+* **Concepto:** Contenedores funcionales interactivos (Formularios completos en UI / Entidades ORM o Servicios unitarios en Backend).
+* **Regla:** Manejan eventos de usuario pero delegan el procesamiento masivo a capas superiores.
+
+### 🦎 Nivel 4: Organismos (`4-organisms/`)
+* **Concepto:** Bloques complejos y autónomos (Secciones dinámicas en UI / Casos de Uso y Orquestadores en Backend).
+* **Regla:** Agrupan células. Pueden ser inyectados en diferentes planetas y funcionar de manera independiente.
+
+### 🌍 Nivel 5: Planetas (`5-planets/`)
+* **Concepto:** Macro-secciones semánticas (Headers/Footers en UI / Endpoints y Controladores API en Backend).
+* **Regla:** Son el "hogar" de los organismos. Estructuran y enrutan la información.
+
+### 🌌 Nivel 6: Sistemas Solares y Galaxias (`6-layouts/`)
+* **Concepto:** El esqueleto gravitacional maestro (Plantillas maestras en UI / Configuración de Servidores y App Modules en Backend).
+* **Regla:** Manejan los metadatos y abren el "espacio" para que los planetas existan.
+
+---
+
+## PARTE II: LAS FUERZAS INVISIBLES Y LA CINEMÁTICA (Datos y Flujos)
+
+Un universo estático está muerto. Estas leyes dictan cómo interactúa la materia.
+
+### 🌑 1. Materia Oscura (Manejo del Estado Global)
+* **El Concepto:** Son los datos globales de la aplicación en memoria (Redux, Zustand, Daemons).
+* **Uso Práctico:** En lugar de pasar un dato bajando por 10 archivos distintos (*Prop Drilling*), guardas ese dato en la "Materia Oscura". Cualquier archivo lo absorbe directamente. Es la **Fuente Única de Verdad**.
+* **Estándar ISO:** Mantenibilidad y Modularidad.
+
+### 🧲 2. Gravedad Cero (Acoplamiento)
+* **El Concepto:** Nivel de Acoplamiento (Dependency Injection).
+* **Uso Práctico:** Un Átomo debe tener "Gravedad Cero". No puede importar conexiones a Base de Datos. La gravedad pesada (lógica compleja) se reserva solo para los Organismos y Planetas.
+* **Estándar ISO:** Reusabilidad y Portabilidad (Principios SOLID).
+
+### ⚡ 3. Velocidad de la Luz y Agujeros de Gusano (Latencia y Caché)
+* **El Concepto:** Peticiones de red, tiempos de espera y memoria a corto plazo.
+* **Uso Práctico:** Superamos el límite de la velocidad de la luz mediante **UI Optimista** (mostrar resultados al instante mientras el dato viaja). Además, utilizamos **Agujeros de Gusano (Redis, Caché de Navegador, CDNs)** para doblar el espacio-tiempo, entregando información frecuente instantáneamente desde la memoria sin tener que hacer el viaje completo hasta la Base de Datos.
+* **Estándar ISO:** Eficiencia de Rendimiento y Escalabilidad.
+
+### 🕸️ 4. La Malla Cósmica (Microservicios e Interoperabilidad)
+* **El Concepto:** Distintas aplicaciones o módulos se comunican a través de "hilos" de energía (APIs, Webhooks, gRPC).
+* **Uso Práctico:** Dos galaxias distintas no comparten bases de datos. Si una galaxia explota, el resto sobrevive ignorando ese hilo cortado (Circuit Breaker).
+* **Estándar ISO:** Tolerancia a Fallos e Interoperabilidad.
+
+### ☄️ 5. Órbitas Cerradas (Ciclo de Vida)
+* **El Concepto:** Los Listeners, WebSockets y procesos en segundo plano.
+* **Uso Práctico:** Todo proceso cíclico debe ser destruido explícitamente al dejar de usarse (Limpieza / Unmount). Una órbita abierta es un planeta rebelde que consume RAM hasta destruir el dispositivo (Memory Leak).
+* **Estándar ISO:** Utilización Eficiente de Recursos.
+
+---
+
+## PARTE III: LEYES DEL TIEMPO Y EL MULTIVERSO (Control de Versiones)
+
+### ⏱️ El Multiverso y las Líneas Temporales (Git)
+* **El Concepto:** El control de versiones no es una herramienta, es la manipulación del espaciotiempo.
+* **Uso Práctico:** Un `commit` congela el universo en el tiempo. Un `branch` crea un Universo Paralelo para experimentar. Jamás se altera el Universo Real (`main`) sin que el Paralelo sea matemáticamente perfecto. Si algo falla, se colapsa la línea temporal (`git revert`).
+
+---
+
+## PARTE IV: CERTIFICACIÓN Y SUPERVIVENCIA (Estándares ISO y Cumplimiento)
+
+Para que un proyecto sea considerado formalmente AUM-IC, debe cumplir con los 4 pilares de supervivencia cósmica. Estos garantizan que la plataforma cumpla de forma automatizada y nativa con los estándares más estrictos del mundo corporativo (**ISO 25010, ISO 27001, ISO 27701, ISO 40500, ISO 29119 y SOC 2**).
+
+### 🛡️ 1. Horizonte de Sucesos, Firmas Espectrales y Campos Magnéticos (Seguridad Total)
+* **Las Normas:** ISO/IEC 27001 (Seguridad) e ISO/IEC 27701 (Privacidad de la Información).
+* **El Horizonte y La Singularidad:** Las contraseñas y secretos viven en el Backend (Horizonte). La "Privacy by Design" comprime y cifra identidades para que nadie pueda ver datos en claro (Singularidad).
+* **Firmas Espectrales (Auth y JWT):** Cada petición debe portar una "Firma Espectral" validada criptográficamente (JWT, Sesiones con Cookies `HttpOnly`). Si un viajero presenta una firma alterada, el Middleware rechaza la conexión instantáneamente.
+* **Campos Magnéticos (ORMs y Sanitización):** Así como el campo magnético de la Tierra desvía la radiación solar mortal, el uso estricto de **ORMs (Object-Relational Mapping)** y validadores (ej. Zod) actúa como un escudo magnético. Atrapa, filtra y desvía caracteres maliciosos e Inyecciones SQL o XSS antes de que toquen el núcleo de la base de datos. Está estrictamente prohibido apagar el campo magnético ejecutando "Raw SQL" con inputs de usuario.
+
+### 💥 2. El Colisionador de Hadrones (Testing y Calidad)
+* **La Norma:** ISO/IEC/IEEE 29119 (Pruebas de Software).
+* **Uso Práctico:** Todo Átomo y Organismo debe sobrevivir a colisiones a alta velocidad en ambientes controlados (Unit Testing, E2E, TDD). Si el código se rompe bajo estrés simulado en el pipeline automatizado (CI/CD), el Universo rechaza el despliegue. El caos no entra a Producción.
+
+### 📡 3. Radiación de Fondo Cósmica (Observabilidad y Auditoría)
+* **La Norma:** SOC 2 Tipo II (Integridad de Procesamiento y Disponibilidad).
+* **Uso Práctico:** El Big Bang dejó un rastro que nos cuenta la historia del universo. Del mismo modo, todo error, acción del usuario o caída del servidor deja un **Rastro Radiactivo inmutable** (Telemetría, Sentry, Datadog, Audit Logs). Es imposible silenciar fallos; todo debe ser rastreable forensemente. Esto incluye la observabilidad del cliente (**RUM - Real User Monitoring**), capturando globalmente excepciones del navegador, recursos rotos (404) y *Dead Clicks* (botones inactivos) enviando el rastro instantáneamente al centro de mando.
+
+### 🌍 4. La Biósfera y el Espectro Invisible (Accesibilidad y SEO)
+* **La Norma:** ISO/IEC 40500 (Pautas de Accesibilidad WCAG) y Directrices de Motores de Búsqueda (SEO).
+* **Uso Práctico:** La **Biósfera** exige que el ecosistema visual soporte toda forma de vida humana (validación matemática de contraste de colores, navegación por teclado). Sin embargo, el **Espectro Invisible** (Infrarrojo/Ultravioleta) es como las máquinas ven tu aplicación. Motores de búsqueda (Googlebots) y Tecnologías de Asistencia (Screen Readers) consumen tu código a través de etiquetas Semánticas, *ARIA-labels* y metadatos. Si tu planeta no emite en el espectro invisible, no existe en la web.
+
+## PARTE V: EL MOTOR DE EJECUCIÓN (Protocolo de Creación y Telemetría)
+
+Para garantizar que el universo no colapse al expandirse (desarrollo de nuevas *features*) o mutar (refactorización), todo arquitecto AUM-IC debe regirse por el siguiente flujo de operaciones inquebrantable.
+
+### Fase 1: El Protocolo de Mutación Segura
+1. **Identificar Comportamientos:** Mapear la gravedad (dependencias) y las órbitas (ciclo de vida) del componente antes de alterar su código.
+2. **Línea Base en el Colisionador:** Escribir los tests automatizados y comprobar que pasan en verde con el código *actual*. Esta es la red de seguridad matemática.
+3. **Refactorización AUM-IC:** Aplicar la simetría fractal (mover de 1-atoms a 6-layouts, aplicar gravedad cero, aislar lógicas).
+4. **Punto de Control Temporal (Checkpoint):** Congelar la línea de tiempo en el Multiverso (Commit en Git). Si la entropía ataca, se colapsa la línea temporal sin daños.
+5. **Fichas de Anatomía:** Comentar el código (JSDoc invisible en producción) explicando el *porqué* atómico para futuras inteligencias artificiales o humanos.
+
+### Fase 2: Observabilidad y Respuesta Inmediata (Telemetría de Supernova)
+6. **Caja Negra de Logs Atómicos:** Se debe programar un sistema interno de trazabilidad. Toda interacción crítica, desde un fallo silencioso en un Átomo hasta un *Fatal Error* en una Galaxia, genera un Log estructurado. Se establecen *breakpoints* y *checkpoints* internos en la ejecución para permitir análisis forense forense y gestión de fallos.
+7. **Alarma de Supernova (Intercepción y Alerta en Tiempo Real):** El sistema de logs no es pasivo; es proactivo. Al interceptar un fallo (Warn, Error, Fatal), el paradigma exige emitir un pulso a la Velocidad de la Luz al Centro de Mando de Desarrollo. A través de NTFY, Webhooks (Discord/Telegram), SMS o bots de WhatsApp, el equipo de ingeniería es notificado en el milisegundo exacto del fallo, garantizando soporte técnico preventivo antes de que el usuario final lo reporte.
+
+
+
+## PARTE VI: LA LEY DE CORRESPONDENCIA (Escalabilidad y Plataformas Agnósticas)
+
+El argumento de *"Este paradigma es demasiada sobreingeniería"* nace de la incomprensión de las leyes del universo. **Como es arriba, es abajo.** El estándar AUM-IC 7 obedece a la **Ley de Correspondencia del Kybalión**: un asteroide obedece la misma física que una galaxia, y una App Móvil obedece la misma arquitectura que un ERP de escritorio o una web en la nube. Las fuerzas solo se encienden en proporción a su Masa Crítica.
+
+Para mantener la velocidad de desarrollo sin sacrificar las certificaciones ISO, el arquitecto debe clasificar su proyecto:
+
+### 🪨 Nivel 1: El Asteroide (Sistemas de Propósito Único)
+* **Ejemplos:** Landing Pages, Scripts CLI, Apps Móviles unidireccionales (Calculadora, Lector QR), Utilidades Desktop pequeñas.
+* **Materia Observable:** Solo carpetas `1-atoms` a `4-organisms`.
+* **Materia Oscura (Estado Global):** **APAGADA.** No necesitas Redux, Vuex ni Singletons pesados. El estado vive localmente (Energía Cinética).
+* **Campo Magnético Perimetral:** **ENCENDIDO.** Todo input externo es un rayo cósmico mortal. En Web, usas filtros de desafío invisible anti-bots. En Móvil/Desktop, usas validadores biométricos (FaceID) o sanitización estricta (Zod/Regex) para evitar *Buffer Overflows* o ejecución de macros maliciosos.
+* **La Biósfera (Accesibilidad):** **MÁXIMA.** En web es SEO semántico. En Móvil/Desktop, obligas el uso de APIs nativas (*VoiceOver, TalkBack*) para que la tecnología de asistencia pueda "leer" tu interfaz.
+
+### 🌍 Nivel 2: El Planeta (Sistemas Transaccionales y Puntos de Venta)
+* **Ejemplos:** E-Commerce, Puntos de Venta locales (Sistemas de Punto de Venta (POS) locales), Apps Móviles transaccionales.
+* **Agujeros de Gusano (Caché y Offline-First):** **ENCENDIDO.** En la nube usas Redis. En POS Desktop o Móvil, enciendes bases de datos locales incrustadas (SQLite, Realm, CoreData). Si el internet se cae, el planeta sigue girando y facturando gracias al Agujero de Gusano.
+* **Firmas Espectrales (Seguridad de Sesión):** **ENCENDIDO.** Implementas JWT para web, o el **Keychain / Windows Credential Manager** para proteger contraseñas localmente en Desktop/Móvil. Jamás se guarda texto plano en disco.
+
+### 🌌 Nivel 3: La Galaxia (Ecosistemas Masivos y Distribuidos)
+* **Ejemplos:** Sistemas ERP distribuidos en la nube, Core Bancario, Suites de Escritorio pesadas (Suites de escritorio de alto rendimiento).
+* **Malla Cósmica (Microservicios / IPC):** **ENCENDIDA.** En la nube, las galaxias se comunican por APIs REST/gRPC. En Desktop, se comunican mediante hilos aislados (IPC - Inter-Process Communication). Si un hilo colapsa, el programa no se cierra. La arquitectura implementa **Circuit Breakers (Disyuntores)** para cortar comunicación con APIs externas caídas y **Bucles de Auto-Sanación (Exponential Reconnects)** para revivir conexiones a bases de datos sin intervención humana.
+* **Materia Oscura y Telemetría:** **MÁXIMA POTENCIA.** El estado global dicta todo. El sistema de Logs (Radiación de Fondo) reporta cada *Fatal Error* de inmediato vía Sentry, Datadog o Webhooks (NTFY/Discord) al centro de mando.
+
+---
+
+## GLOSARIO TÁCTICO: EL PORQUÉ DE LAS COSAS (Respuestas para la Élite)
+
+Para que AUM-IC 7 no sea visto como un capricho estético, todo arquitecto debe saber defender la física de sus decisiones en *cualquier* lenguaje (C#, Python, JS, Swift):
+
+* **¿Por qué y cuándo encender el Campo Magnético (ORMs o Query Builders)?**
+  * *Cuándo:* Siempre que el software (Web, POS o App) interactúe con una base de datos o sistema de archivos.
+  * *Por qué:* Escribir consultas "Raw SQL" (SQL crudo) combinadas con variables del usuario es apagar el campo magnético de tu planeta. Los rayos cósmicos (Inyecciones SQL) freirán tu núcleo, ya sea en un clúster en la nube o en la base local de SQLite de la caja registradora. El ORM actúa como una magnetósfera que purifica los comandos maliciosos antes de que toquen el disco. Además, la materia nunca se destruye: se exige el **Borrado Lógico (Soft Deletes)** y el control estricto de esquemas mediante Archivos de Migración.
+
+* **¿Por qué y cuándo hacer un Commit (Punto de Control en el Multiverso)?**
+  * *Cuándo:* Jamás al final del día por costumbre. Se hace **cada vez que un átomo o ruta alcanza la estabilidad matemática (Test en verde)**.
+  * *Por qué:* El desarrollo es una lucha contra la entropía (el caos). Si en la siguiente hora tu código colapsa, el *commit* te permite colapsar esa línea temporal fallida y regresar instantáneamente al último punto donde el universo era estable.
+
+* **¿Por qué destruir los Listeners (Órbitas Cerradas)?**
+  * *Cuándo:* Cuando una ventana modal, un componente o una sub-rutina se cierra o destruye.
+  * *Por qué:* Un Webhook, un proceso *Background Worker* en C#, o un WebSocket que no se destruye explícitamente se convierte en un "Planeta Errante". Seguirá orbitando invisible en la memoria RAM (Memory Leak) hasta destruir la capacidad del dispositivo, forzando al usuario a reiniciar su computadora o teléfono.

package/MANIFEST.md

@@ -0,0 +1,64 @@
+
+# 🌌 AUM-IC 7 Standard (2026 Edition)
+**Multidimensional Universe Architecture - Engineering Standard**
+
+<p align="center">
+  <img src="https://img.shields.io/badge/version-7.0.0-crimson?style=flat-square" alt="Version 7.0.0">
+  <img src="https://img.shields.io/badge/nature-Clean%20Architecture%20Standard-38bdf8?style=flat-square" alt="Nature">
+</p>
+
+> 🌐 **Navigation:** 🇺🇸 [Read in English](./MANIFEST.md) | 🇲🇽 [Leer en Español](./MANIFEST.es.md) | 📖 [README (EN)](./README.md) | 📖 [README (ES)](./README.es.md) | 🌌 [AUM-IC 7 Standard](https://github.com/ingcrea/aum-ic)
+
+## THE PARADIGM
+AUM-IC is not just a folder structure. It is a universal framework of laws that governs software behavior, drawing parallels from quantum mechanics and astrophysics to deliver **Military-Grade Security, High Availability (SRE), and Fractal Scalability**.
+
+### 1. ⚛️ Atomic Physics (The Structure)
+Software must follow fractal symmetry.
+- `1-atoms`: The irreducible elements (Buttons, Inputs).
+- `2-molecules`: Simple compositions (Form Fields).
+- `3-cells`: Reusable blocks (Cards, Navbars).
+- `4-organisms`: Self-contained features (Login Form).
+- `5-planets`: Full views or screens (Dashboard).
+- `6-layouts`: The spatial grid that holds planets.
+
+### 2. 🌌 The 7 Cosmic Forces (SRE & Security Core)
+AUM-IC defines 7 laws that must govern the software's execution engine:
+
+1. **Dark Matter (Global State):** The invisible gravitational pull. State (like Redux or Zustand) connects organisms without direct coupling.
+2. **Event Horizon (Perimeter Security):** The impenetrable border. Enforces **CSP (Content Security Policy)**, strict Rate Limiting, and JWT signatures. If a request lacks proper spectral signatures, the Middleware rejects it instantly.
+3. **Magnetic Field (ORM & Sanitization):** Protects the core from cosmic radiation (SQL Injection). Raw SQL is forbidden. Additionally, matter is never truly destroyed: **Soft Deletes** and declarative schema Migrations are mandatory.
+4. **The Hadron Collider (CI/CD Testing):** Chaos does not enter Production. Before deploying, the pipeline mandates **CVE Vulnerability Audits** (Supply Chain Defense) and deterministic tests.
+5. **Wormholes (Cache & Offline-First):** Bypasses the speed of light. Uses local SQLite/Realm databases for Desktop/Mobile or Redis for Web, ensuring the system survives network outages.
+6. **The Cosmic Web (Resilience):** For massive systems. Implements **Circuit Breakers** to cut off failing external APIs and **Exponential Reconnect Loops** to revive database connections autonomously.
+7. **Cosmic Microwave Background (RUM Observability):** Every action leaves a forensic trace. Enforces **Real User Monitoring (RUM)**, catching global browser exceptions, dead clicks, and 404s, sending real-time alerts to the command center (SOC 2 Compliance).
+
+---
+
+## PART VI: THE LAW OF CORRESPONDENCE (Critical Mass Scalability)
+"As above, so below." AUM-IC obeys the Hermetic Law of Correspondence: an asteroid obeys the same physics as a galaxy, but forces ignite proportionally to their **Critical Mass**.
+
+### 🪨 Level 1: The Asteroid (Single-Purpose Systems)
+* **Examples:** Landing Pages, CLI Scripts, Utility Mobile Apps.
+* **Dark Matter (State):** **OFF.**
+* **Perimeter Magnetic Field:** **MAXIMUM.** Inputs are deadly. Web requires invisible challenge filters (WAF/CAPTCHAs). Desktop/Mobile requires strict biometric validation or Zod sanitization.
+* **The Biosphere (Accessibility/SEO):** **MAXIMUM.** Semantic HTML or native OS Accessibility APIs (VoiceOver/TalkBack).
+
+### 🌍 Level 2: The Planet (Transactional Systems)
+* **Examples:** E-Commerce, Local POS Systems, Transactional Apps.
+* **Wormholes (Cache & Offline-First):** **ON.** Local DBs (SQLite) keep the system running during outages.
+* **Spectral Signatures (Auth):** **ON.** Secrets saved in OS Keychains or secure HttpOnly cookies.
+
+### 🌌 Level 3: The Galaxy (Massive Ecosystems)
+* **Examples:** Cloud ERPs, Core Banking, Heavy Desktop Suites.
+* **The Cosmic Web (Microservices/IPC):** **ON.**
+* **Telemetry & Dark Matter:** **MAXIMUM.**
+
+---
+
+## TACTICAL GLOSSARY (The "Why")
+* **Why use an ORM always?** Writing Raw SQL is shutting down your magnetic field. Cosmic rays (SQL Injections) will fry your core, whether on an AWS cluster or a local cash register POS.
+* **When to Commit?** Never "at the end of the day." Commit the millisecond an atom achieves mathematical stability (Green Test). It is a temporal save point in the multiverse.
+* **Why destroy Listeners?** A background worker or WebSocket that isn't explicitly closed becomes a "Rogue Planet" causing Memory Leaks until it crashes the user's OS.
+
+---
+> 🏛️ Intellectual Property of **Ingeniería Creativa (IngCrea)**. Standard released under CC BY-SA 4.0 / MIT.

package/PUF-15.md

@@ -0,0 +1,118 @@
+---
+name: aumic-puf15
+description: Protocolo Universal contra Fallos (PUF-15) del Estándar AUM-IC 7:2026. Matriz de 15 compuertas de calidad agnóstica (Rust, Astro, Python, PHP, C#) para auditoría, detección, resolución metódica de fallos, refactorización limpia sin deuda técnica y blindaje de ergonomía del sistema operativo.
+---
+# Protocolo Universal contra Fallos (PUF-15) — AUM-IC 7:2026
+### Matriz de Compuertas de Calidad Agnóstica (Rust, Astro, Python, PHP, C#)
+
+Cuando el usuario invoque **PUF-15** (o PUF) o solicite resolver un fallo bajo este estándar, se debe ejecutar con rigor militar este ciclo cerrado de 15 compuertas consecutivas (G1 a G15), reportando el progreso y las evidencias en consola:
+
+---
+
+## Matriz de Compuertas de Calidad (G1 - G15)
+
+### 1. G1: Mapeo de Comportamientos y Límites (Behavior & Boundary Mapping)
+- **Alcance:** Analizar el flujo completo de ejecución y ciclo de vida de la UI.
+- **Acciones:**
+  - Identificar entradas, tipos, contratos, mutaciones y salidas esperadas.
+  - Definir formalmente casos de borde: valores nulos (`None`, `null`, `Option::None`), cadenas vacías, desbordamientos numéricos, condiciones de carrera/concurrencia y accesos no autenticados o permisos insuficientes.
+  - **Aislamiento del Bucle de UI:** Prohibido disparar I/O pesado, comandos o procesos síncronos dentro de temporizadores o callbacks de interfaz gráfica (`slint::Timer`, `setInterval`, `requestAnimationFrame`). Deben delegarse a tareas de fondo asíncronas con canales o cachearse de forma atómica.
+
+### 2. G2: Test de Reproducción — Fase Roja (Reproduction Test-First)
+- **Alcance:** Probar y demostrar empíricamente el defecto antes de tocar una sola línea de lógica.
+- **Acciones:**
+  - Escribir un test automatizado (unitario, integración o CLI determinista) que replique la falla reportada con fidelidad.
+  - Ejecutar el test y confirmar que falle contra el código actual (*Red State*), validando que el bug ha sido capturado de forma determinista.
+
+### 3. G3: Checkpoint Inmutable (State Snapshot)
+- **Alcance:** Blindaje de rollback y preservación de estado pre-mutación.
+- **Acciones:**
+  - Generar un respaldo atómico timestamped en `checkpoints/` o tag git (`<archivo>.bak_YYYYMMDD_HHMMSS`).
+  - Registrar hash de verificación o estado previo para permitir reversión instantánea sin pérdida de información ni corrupción colateral.
+
+### 4. G4: Reparación Focalizada y Refactorización Limpia (Pure Logic Refactor)
+- **Alcance:** Corrección quirúrgica de la causa raíz.
+- **Acciones:**
+  - Atacar la causa raíz sin aplicar parches superficiales ni parches ciegos.
+  - Cero código muerto, cero dependencias circulares, bajo acoplamiento y alta cohesión.
+  - Cumplir principios de código limpio del stack correspondiente:
+    - **Rust:** Cero `unwrap()` no justificado; manejo exhaustivo con `Result` / `Option`.
+    - **Astro:** Componentes puros, separación de lógica frontmatter y JSX estático/reactivo.
+    - **Python:** Tipado estricto (Type hints), PEP 8, manejo explícito de excepciones.
+    - **PHP:** POO fuertemente tipada, tipos estrictos (`declare(strict_types=1);`), inyección de dependencias.
+  - **Prohibición Absoluta de CSS Inline:** Queda terminantemente prohibido inyectar atributos `style="..."` o estilos en línea en el HTML/PHP/JSX/Astro. Si se encuentran estilos inline preexistentes, es obligatorio refactorizarlos y extraerlos a su archivo `.css` o `.scss` respectivo con clases semánticas estructuradas.
+
+### 5. G5: Validación de Test y No-Regresión — Fase Verde (Green State & Non-Regression)
+- **Alcance:** Verificación de solución completa y estabilidad perimetral.
+- **Acciones:**
+  - Reejecutar el test de reproducción desarrollado en G2 y validar el 100% de aserciones aprobadas (*Green State*).
+  - Ejecutar la suite de pruebas perimetral/completa para certificar cero efectos secundarios o regresiones colaterales.
+
+### 6. G6: Análisis Estático, Tipado y Compilador Estricto (Static Gate)
+- **Alcance:** Tolerancia cero a advertencias del compilador o linters.
+- **Acciones:**
+  - Ejecutar compilador y análisis estático en modo estricto según el stack:
+    - **Rust:** `cargo clippy -- -D warnings` y `cargo check`.
+    - **Astro / TypeScript:** `npx astro check` y `npx eslint`.
+    - **Python:** `ruff check` y `mypy --strict`.
+    - **PHP:** `php -l` (sintaxis) y `phpstan analyse --level=max`.
+  - Cero advertencias o errores tolerados.
+
+### 7. G7: Documentación Semántica y Registro ADR (Intent & Architecture Decision)
+- **Alcance:** Memoria técnica e intención arquitectónica.
+- **Acciones:**
+  - Explicar en comentarios de código el *por qué* de la decisión y no solo el *qué hace*.
+  - Registrar en `BITACORA.md` de la raíz del proyecto bajo el formato estricto:
+    ```markdown
+    [Timestamp] | Contexto | Decisión | Consecuencia
+    ```
+
+### 8. G8: Aplanadora POSIX y Sanitización Anti-Mojibake (aumic-sanitizer)
+- **Alcance:** Integridad de codificación y terminación de línea.
+- **Acciones:**
+  - Barrer los archivos con `node C:\Users\NexoRemoto\Proyectos\aumic-sanitizer\index.js` (o `npx aumic-sanitizer`).
+  - Purgar de raíz cualquier carácter corrupto Mojibake (ej. `ó`, `’`, `ñ`) forzando UTF-8 puro sin BOM.
+  - Aplanar y forzar saltos de línea Unix LF (`\n`), erradicando Windows CRLF (`\r\n`).
+
+### 9. G9: Integridad Operativa, Permisos y Secretos Zero-Trust (Ops Shield)
+- **Alcance:** Blindaje de infraestructura y seguridad de credenciales.
+- **Acciones:**
+  - Verificar permisos restrictivos en sistema de archivos (`chmod 644` archivos / `755` directorios, llaves SSH `600`, propietario correcto del servicio `chown`).
+  - Cero credenciales, tokens o contraseñas en texto plano. Gestionar accesos vía variables de entorno seguras o `SECRETOS.py`.
+
+### 10. G10: Invalidación y Purga de Estado Efímero (State Flush)
+- **Alcance:** Consumo garantizado del código fresco en runtime.
+- **Acciones:**
+  - Purgar deterministamente memoria compartida, caché de objetos (`wp cache flush`, Redis, Memcached, Opcache).
+  - Limpiar transientes de base de datos o reiniciar workers (Gunicorn, Systemd, SSR Node, PM2) para garantizar que los clientes o servicios consuman el código recién validado sin residuos en memoria.
+
+### 11. G11: Blindaje de Ergonomía del SO, Foco de Ventanas y Aislamiento UI (OS & Desktop Ergonomics Gate)
+- **Alcance:** Experiencia de usuario inmaculada, ausencia total de robo de foco y persistencia limpia en el Sistema Operativo.
+- **Acciones:**
+  - **Inmunidad al Robo de Foco (Zero-Focus Stealing):** Toda invocación de subprocesos en Windows (`Command::new`, `powershell`, `cmd`, `sc`, `reg`, `net`) DEBE incorporar obligatoriamente `.creation_flags(0x08000000)` (`CREATE_NO_WINDOW`) para erradicar consolas emergentes o parpadeos (flickering) que desactiven la ventana activa del usuario.
+  - **Zero-Ghost Processes:** Comprobar que al cerrar la aplicación no queden procesos huérfanos (`conhost`, workers zombies) consumiendo CPU.
+  - **Caché de Consultas de Privilegios:** Consultas de privilegios (`is_admin`) o del SCM deben usar caché atómico perezoso (`AtomicU8` / `OnceLock`), evitando invocaciones repetidas de subprocesos en bucles de tiempo.
+
+---
+### 12. G12: Topología de Rutas Vivas & Dead Link Sweeper (Living Routes Gate)
+- **Alcance:** Integridad de navegación sin pantallas 404 ni rutas huérfanas en Web (Astro, React, Next, Vue), Mobile (Flutter, React Native) y Desktop (Slint, C /WPF, Tauri).
+- Cero enlaces rotos hacia destinos locales inexistentes.
+
+### 13. G13: Grafo de Interactividad & Erradicación Zombie (Living UI Actions Gate)
+- Cero botones decorativos, pseudoelementos inertes o acciones no conectadas que no responden al usuario.
+
+- Todo control interactivo debe resolver en un evento real (API, modal, mutación o feedback).
+
+### 14. G14: Traza de Contratos HTTP & Endpoints Vivos (Living API Contract Gate)
+- Consistencia granular entre las llamadas del cliente y los controladores declarados en el backend.
+- Cero llamadas fetch o solicitudes HTTP a paths huérfanos o inexistentes.
+
+### 15. G15: Headless E2E Crawler & Runtime Exceptions (Headless Handshake Gate)
+- Detección de errores silenciosos, excepciones de runtime y bloqueos de interfaz.
+- Certificación del pase limpio de interactividad antes de liberar a producción.
+
+## Reglas Inviolables de Ejecución
+
+1. **Cero Complacencia o Respuestas Evasivas:** No dejar tareas a medias ni usar marcadores vacíos (`// el resto del código aquí`).
+2. **Determinismo Técnico:** Todo entregable debe ser determinista, verificado en consola y listo para producción.
+3. **Reporte por Compuerta:** Reportar siempre el estado de cada compuerta (G1 a G15) con su respectiva evidencia de consola.

package/PUF_G16_Lighthouse.md

@@ -0,0 +1,70 @@
+# PUF G16 – Integración de auditorías Lighthouse
+
+## Objetivo
+Incorporar métricas críticas de rendimiento, accesibilidad, SEO y buenas prácticas que Lighthouse evalúa, para enriquecer el Protocolo Universal de Fallos (PUF) bajo el paradigma AUM‑IC 7:2026.
+
+## KPI Prioritarios de Lighthouse (basados en Google PSI)
+| Categoría | Métrica | Umbral de PASS | Umbral de WARN | Umbral de FAIL |
+|-----------|---------|----------------|----------------|----------------|
+| **Core Web Vitals** | **Largest Contentful Paint (LCP)** | < 2.5 s | 2.5 s – 4 s | > 4 s |
+| | **Cumulative Layout Shift (CLS)** | < 0.1 | 0.1 – 0.25 | > 0.25 |
+| | **First Input Delay (FID)** (o **Total Blocking Time** si FID no está disponible) | < 100 ms | 100 ms – 300 ms | > 300 ms |
+| **Performance** | **Speed Index** | < 3 s | 3 s – 4.5 s | > 4.5 s |
+| | **Time to Interactive (TTI)** | < 5 s | 5 s – 7 s | > 7 s |
+| **Accessibility** | **Contrast Ratio** (texto vs fondo) | ≥ 4.5:1 (normal) ≥ 3:1 (large) | – | < 3:1 |
+| | **ARIA roles & labels** | Todos presentes | – | Falta alguno |
+| | **Form labels** | 100 % etiquetado | – | < 100 % |
+| **SEO** | **Meta description** | Presente y 50‑160 caracteres | – | Ausente o fuera de rango |
+| | **Title length** | 50‑60 caracteres | – | < 30 o > 70 |
+| | **Canonical link** | Presente y válido | – | Ausente o inválido |
+| **Best Practices** | **HTTPS** | Sí | – | No |
+| | **Sin contenido mixto** | Sí | – | No |
+| | **Política de caché** (Cache‑Control) | > 1 día para assets estáticos | – | < 1 día |
+
+## Mapeo a checkpoints del PUF y pesos (siguiendo la distribución de Google PSI)
+- **G16‑01**: LCP – **Peso 10 %** del bloque G16.
+- **G16‑02**: CLS – **Peso 10 %**.
+- **G16‑03**: FID/TBT – **Peso 10 %**.
+- **G16‑04**: Speed Index – **Peso 8 %**.
+- **G16‑05**: TTI – **Peso 7 %**.
+- **G16‑06**: Accesibilidad (contrast, ARIA, labels) – **Peso 15 %**.
+- **G16‑07**: SEO (meta, title, canonical) – **Peso 10 %**.
+- **G16‑08**: Buenas prácticas (HTTPS, mixed‑content, cache) – **Peso 10 %**.
+- **G16‑09**: Peso agregado de **Performance** dentro del PUF global – **40 %** del puntaje total (suma de los pesos anteriores).
+- **G16‑10**: Peso de **Accesibilidad** dentro del PUF global – **15 %**.
+- **G16‑11**: Peso de **SEO** dentro del PUF global – **10 %**.
+- **G16‑12**: Peso de **Best Practices** dentro del PUF global – **10 %**.
+
+## Umbrales de salud del PUF (Google PSI style)
+- **Excelente**: Todos los KPI en PASS.
+- **Adecuado**: Máximo 2 WARN, sin FAIL.
+- **Deficiente**: ≥ 1 FAIL o > 2 WARN.
+
+## Prototipo de auditoría Lighthouse (`lighthouse-audit.js`)
+Se añadirá un script Node que:
+1. Recibe una URL como argumento.
+2. Ejecuta `lighthouse` con `--only-categories=performance,accessibility,seo,best-practices`.
+3. Extrae los scores y métricas clave (LCP, CLS, FID/TBT, Speed Index, TTI, contrast, ARIA, etc.).
+4. Genera un JSON compatible con el formato actual de `report-generator.js`.
+5. Opcional: actualiza el puntaje global del PUF según los pesos definidos.
+
+## Integración CI/CD (opciones)
+- **GitHub Actions**: workflow que instala `node`, corre `npm ci`, ejecuta `node scripts/lighthouse-audit.js <URL>`, falla si algún KPI está en FAIL y publica artefacto HTML.
+- **Azure Pipelines**: pipeline YAML con etapas `npm install`, `npm run lighthouse-audit -- <URL>`, `PublishTestResults` para fallos.
+- **GitLab CI**: similar a GH Actions, usando `script:` secciones.
+- **Local on‑demand**: ejecutable vía `npx lighthouse-audit <URL>` o `npm run lighthouse-audit -- <URL>`.
+
+## Dependencias
+```bash
+npm i lighthouse chrome-launcher --save-dev
+```
+
+## Próximos pasos
+1. Crear `scripts/lighthouse-audit.js` con el esqueleto descrito.
+2. Extender `report-generator.js` para consumir los nuevos campos.
+3. Añadir script a `package.json` (`"lighthouse-audit": "node scripts/lighthouse-audit.js"`).
+4. Configurar CI (GitHub Actions o Azure Pipelines) según tu preferencia.
+5. Ejecutar pruebas en `https://segurosiller.com/` y validar visualmente.
+
+---
+*Este documento está listo para ser versionado en el repositorio `aumic-puf`.*