# ESPECIFICACIÓN PARA IA — MODERNIZACIÓN DEL SITIO DE ELECTRÓNICA **Estado del documento:** base inicial, destinada a ampliarse con cada página y proyecto que indique el propietario. **Fecha de inicio:** 14 de julio de 2026. **Tipo de dominio:** sitio independiente dedicado a electrónica educativa, simulación, experimentación y proyectos personales. --- ## 1. Objetivo general Modernizar un sitio web de electrónica para convertirlo en una plataforma técnica, clara, visualmente moderna y fácil de ampliar. El sitio reunirá, como mínimo: 1. Simulación de electrónica digital mediante **SimcirJS**. 2. Simulación de circuitos analógicos y mixtos mediante **CircuitJS1**. 3. Catálogo y documentación de proyectos personales. 4. Páginas educativas, recursos, herramientas y otros contenidos que el propietario irá indicando. 5. Una navegación y un sistema visual coherentes en todo el dominio. La modernización no debe convertirse en una reescritura destructiva. Antes de modificar una página se debe revisar su código actual y conservar todo comportamiento funcional existente. --- ## 2. Regla principal de continuidad La IA que continúe este trabajo debe cumplir estas reglas: - No eliminar funciones existentes. - No cambiar rutas públicas sin una razón comprobada. - No romper enlaces antiguos. - No eliminar formularios, acciones POST, parámetros GET ni endpoints. - No sustituir lógica PHP/backend que ya funciona. - No cambiar nombres de campos usados por JavaScript, PHP, bases de datos o formularios sin actualizar toda la cadena. - No asumir que una página es solamente visual. - Revisar includes, sesiones, cookies, consultas SQL, archivos JSON, cargas de archivos y scripts antes de modificar. - Modernizar de forma incremental. - Mantener una copia o parche claro de cada cambio relevante. - Si una función no se comprende, se conserva hasta investigarla. - El nuevo frontend debe envolver la funcionalidad existente, no reemplazarla a ciegas. --- ## 3. Identidad del dominio Este sitio debe tener una identidad visual propia. No debe reutilizar automáticamente el estilo del dominio GPS, del dominio de ingeniería química, de la tienda eCommerce ni de otros dominios modernizados anteriormente. ### Concepto visual El sitio debe transmitir: - laboratorio electrónico; - ingeniería práctica; - experimentación; - precisión; - tecnología accesible; - proyectos reales; - aprendizaje mediante simulación. ### Dirección visual propuesta - Fondo principal oscuro o gris grafito, con superficies claras u oscuras bien diferenciadas. - Acentos cian o azul eléctrico para acciones y navegación. - Acentos ámbar para medición, advertencias y estados de prueba. - Verde para circuitos activos, proyectos funcionales y resultados correctos. - Líneas, nodos o trazas de circuito usadas con moderación. - Tarjetas limpias, sin exceso de efectos. - Bordes y sombras suaves. - Tipografía legible y técnica. - Diseño adaptable a escritorio, tableta y móvil. - No depender de fuentes externas si no son necesarias. - Evitar una estética de “panel administrativo genérico”. - Evitar animaciones que interfieran con los simuladores. --- ## 4. Arquitectura de información propuesta La arquitectura definitiva se ajustará a las páginas reales existentes. Como objetivo, el dominio debe poder organizarse así: ### 4.1 Inicio La portada debe explicar rápidamente qué contiene el sitio. Secciones recomendadas: - presentación principal; - acceso directo a simulación digital; - acceso directo a simulación analógica; - proyectos destacados; - últimas incorporaciones; - categorías de contenido; - breve presentación del autor o laboratorio; - enlaces a recursos importantes. Mensaje conceptual sugerido: > Simula, construye, mide y documenta circuitos electrónicos directamente desde el navegador. No usar este texto como nombre definitivo del sitio sin confirmación del propietario. ### 4.2 Simuladores Una página central de simulación con dos áreas claramente diferenciadas: - **Laboratorio digital — SimcirJS** - **Laboratorio analógico — CircuitJS1** La página puede usar pestañas, botones grandes o un selector de modo. Los dos motores no deben cargarse simultáneamente si esto provoca consumo innecesario. ### 4.3 Proyectos Debe existir un catálogo visual de proyectos personales. Cada tarjeta puede mostrar: - imagen; - título; - resumen; - categoría; - estado; - año; - tecnologías; - enlace a la ficha completa. ### 4.4 Ficha individual de proyecto Cada proyecto debe poder documentarse con: - objetivo; - problema que resuelve; - estado actual; - materiales; - hardware; - software; - diagrama; - fotografías; - código; - firmware; - archivos descargables; - pruebas; - resultados; - limitaciones; - mejoras pendientes; - historial de versiones; - enlaces relacionados. ### 4.5 Recursos Posibles contenidos futuros: - tablas electrónicas; - calculadoras; - referencias; - hojas de datos; - tutoriales; - herramientas; - componentes; - enlaces técnicos; - documentación propia. No crear estas páginas como contenido vacío si todavía no existe material real. ### 4.6 Acerca del sitio Puede explicar: - propósito; - enfoque práctico; - autor o responsable; - tecnologías utilizadas; - licencias y créditos; - medios de contacto existentes. --- ## 5. Integración de SimcirJS Fuente indicada por el propietario: - https://kazuhikoarase.github.io/simcirjs/ - https://github.com/kazuhikoarase/simcirjs Los archivos serán servidos localmente desde la carpeta `js`. ### 5.1 Archivos habituales La distribución original puede contener: - `simcir.js` - `simcir.css` - `simcir-basicset.js` - `simcir-basicset.css` - `simcir-library.js` - ejemplos HTML - posibles dependencias como jQuery según la copia utilizada La IA debe revisar la copia real antes de escribir rutas definitivas. ### 5.2 Forma de integración SimcirJS se integra directamente dentro del DOM mediante un contenedor similar a: ```html
{ "width": 800, "height": 500, "showToolbox": true }
``` La configuración real podrá incluir toolbox, dispositivos, conexiones y circuitos prediseñados. ### 5.3 Reglas de implementación - Cargar los CSS de SimcirJS sin permitir que sobrescriban globalmente el diseño del sitio. - Encapsular el simulador dentro de un contenedor específico. - Evitar modificar los archivos originales del motor salvo que sea imprescindible. - Guardar personalizaciones propias en archivos separados. - Preservar los avisos de licencia. - Confirmar si la copia real necesita jQuery. - Permitir ampliar el catálogo de circuitos de ejemplo. - Mantener el JSON del circuito separado del marcado cuando resulte conveniente. - Probar arrastre, conexión, edición, toolbox y cambio entre vista de circuito y datos. - En móvil, ofrecer desplazamiento horizontal o modo de pantalla completa; no comprimir el área hasta hacerla inutilizable. ### 5.4 Funciones futuras posibles Sin implementarlas todavía como requisito obligatorio: - abrir ejemplos; - guardar un circuito en el navegador; - importar y exportar JSON; - biblioteca de circuitos digitales; - compartir una configuración; - modo de pantalla completa; - restaurar el último circuito; - proyectos educativos guiados. --- ## 6. Integración de CircuitJS1 Fuente indicada por el propietario: - https://github.com/pfalstad/circuitjs1 La implementación web más difundida se documenta actualmente en: - https://github.com/sharpie7/circuitjs1 - https://www.falstad.com/circuit/doc/js-interface.html Los archivos también serán servidos localmente desde la carpeta `js`. ### 6.1 Estructura esperada CircuitJS1 suele necesitar conservar una estructura interna similar a: ```text js/ └── circuitjs1/ ├── circuitjs.html o circuitjs1.html ├── iframe.html ├── shortrelay.php # opcional ├── circuitjs1/ │ └── archivos compilados GWT ├── circuits/ └── setuplist.txt ``` El nombre exacto del archivo de entrada debe verificarse en la copia instalada. No asumir automáticamente si se llama `circuitjs.html` o `circuitjs1.html`. ### 6.2 Forma recomendada de integración Usar un `iframe` local dentro de la página del sitio. Ejemplo conceptual: ```html ``` El atributo `src` puede asignarse únicamente cuando el usuario abra el laboratorio analógico. ### 6.3 Reglas de implementación - Mantener CircuitJS1 en el mismo origen que la página principal si se utilizará su interfaz JavaScript. - No romper la jerarquía de carpetas generada por GWT. - No mover archivos internos sin revisar sus referencias relativas. - Cargar el `iframe` de manera diferida. - Ofrecer un botón de pantalla completa. - Permitir abrir el simulador en una página independiente. - Ajustar la altura del área de trabajo para escritorio y móvil. - No colocar overlays del sitio encima del simulador. - No capturar teclas que CircuitJS1 necesita. - Preservar los avisos y condiciones de la licencia GPL. - Revisar `shortrelay.php` antes de exponerlo. - No configurar Dropbox, acortadores ni servicios externos sin necesidad. - Probar carga de ejemplos, edición, pausa, ejecución, osciloscopio, importación y exportación. - Distinguir claramente que una simulación no sustituye mediciones reales de seguridad o diseño profesional. ### 6.4 Parámetros útiles CircuitJS1 permite iniciar con parámetros de URL. La IA puede considerar, según la copia real: - circuito inicial; - fondo claro u oscuro; - corriente convencional; - simulación iniciada o pausada; - menú visible u oculto; - barra lateral visible u oculta; - edición permitida o bloqueada; - estilos de resistores; - colores de tensión. No fijar estos valores sin probarlos en la versión instalada. --- ## 7. Página unificada de simulación ### 7.1 Diseño de escritorio Propuesta: 1. Encabezado del sitio. 2. Título de la sección. 3. Selector: - Digital - Analógica 4. Barra breve de ayuda contextual. 5. Área principal del simulador. 6. Acciones: - pantalla completa; - reiniciar; - abrir ejemplo; - ayuda; - abrir en página independiente. 7. Créditos y licencia del motor activo. ### 7.2 Diseño móvil - Selector visible en la parte superior. - Simulador dentro de un contenedor con altura adecuada. - Botón de pantalla completa destacado. - Controles secundarios plegables. - No reducir demasiado el canvas. - Permitir desplazamiento horizontal cuando el motor lo requiera. - Evitar que el menú global consuma gran parte de la pantalla. ### 7.3 Carga diferida Flujo recomendado: 1. La página carga sin inicializar los dos simuladores. 2. El modo digital se inicializa solamente si está visible. 3. CircuitJS1 recibe su `src` solo al seleccionar el modo analógico. 4. Al cambiar de modo, el estado puede conservarse. 5. No destruir automáticamente el simulador si el usuario ya trabajó en él. 6. Evitar múltiples inicializaciones por clics repetidos. --- ## 8. Sistema de proyectos personales El sitio debe permitir añadir progresivamente proyectos sin rediseñar la portada cada vez. ### 8.1 Modelo de información sugerido ```json { "slug": "nombre-del-proyecto", "title": "Nombre del proyecto", "summary": "Resumen breve", "category": "robotica", "status": "prototipo", "year": 2026, "cover": "img/proyectos/nombre/portada.webp", "technologies": ["ESP32", "C++", "PHP"], "hardware": [], "software": [], "gallery": [], "downloads": [], "links": [], "sections": [] } ``` Este modelo es orientativo. Si el sitio ya usa base de datos, arrays PHP, archivos o rutas diferentes, se debe adaptar a lo existente. ### 8.2 Estados sugeridos - idea; - diseño; - prototipo; - pruebas; - funcional; - terminado; - pausado; - archivado. ### 8.3 Categorías posibles Se crearán únicamente cuando existan proyectos reales: - electrónica digital; - electrónica analógica; - microcontroladores; - robótica; - instrumentación; - comunicaciones; - IoT; - energía; - reparación; - reutilización de hardware; - software para electrónica; - inteligencia artificial aplicada; - simulación. ### 8.4 Presentación visual Las tarjetas deben ser informativas y no solamente decorativas. Cada proyecto debe poder mostrar claramente: - qué es; - qué hace; - en qué estado está; - qué tecnología utiliza; - si tiene documentación, código o archivos disponibles. --- ## 9. Componentes reutilizables del sitio La modernización debe crear componentes compartidos, sin duplicar HTML innecesariamente. Componentes recomendados: - encabezado; - navegación principal; - navegación móvil; - pie de página; - hero; - tarjetas de simulador; - tarjeta de proyecto; - insignia de estado; - lista de tecnologías; - galería; - bloque de descarga; - aviso técnico; - bloque de código; - tabla responsiva; - breadcrumb; - llamada a la acción; - mensaje de error; - estado vacío; - créditos y licencias. Si el sitio usa PHP, estos componentes pueden vivir en `includes/` o en el sistema actual de plantillas. --- ## 10. Organización de archivos propuesta Debe adaptarse sin romper la estructura real. ```text / ├── index.php ├── simuladores.php ├── proyectos.php ├── proyecto.php ├── recursos.php ├── acerca.php ├── includes/ │ ├── header.php │ ├── navigation.php │ ├── footer.php │ └── project-card.php ├── assets/ │ ├── css/ │ │ ├── site.css │ │ ├── simulators.css │ │ └── projects.css │ ├── js/ │ │ ├── site.js │ │ ├── simulator-tabs.js │ │ └── projects.js │ └── img/ ├── js/ │ ├── simcirjs/ │ └── circuitjs1/ └── docs/ └── IA_MODERNIZACION_ELECTRONICA.md ``` Si la carpeta `js` ya contiene los archivos directamente, no reorganizarla hasta comprobar todas las rutas existentes. --- ## 11. Compatibilidad y rendimiento ### Requisitos - HTML semántico. - CSS adaptable. - JavaScript sin dependencias innecesarias. - Carga diferida de imágenes e iframe. - Evitar cargar ambos simuladores al inicio. - Mantener recursos locales cuando ya estén disponibles. - No introducir frameworks grandes solo para modernizar la apariencia. - No depender de una compilación frontend si el sitio actual es PHP simple. - Evitar conflictos entre CSS global y CSS de los simuladores. - Probar en navegadores Chromium y Firefox. - Revisar comportamiento táctil. - Mantener una página funcional aunque JavaScript secundario falle. ### Caché Los motores pueden usar archivos grandes. Se debe configurar caché para archivos estáticos con versionado controlado, sin impedir que una actualización sea visible. Ejemplo conceptual: ```text site.css?v=20260714-1 simulator-tabs.js?v=20260714-1 ``` --- ## 12. Accesibilidad - Navegación mediante teclado. - Contraste suficiente. - Botones con texto o etiqueta accesible. - Estados activos identificables sin depender solo del color. - `title` descriptivo en iframes. - Encabezados jerárquicos. - Texto alternativo en imágenes de proyectos. - Mensajes claros cuando un simulador no carga. - Posibilidad de abrir el simulador en otra página. - Evitar destellos y animaciones agresivas. Los motores de simulación pueden tener limitaciones propias; la interfaz que los rodea debe ser lo más accesible posible. --- ## 13. Seguridad - No confiar en parámetros GET o POST. - Escapar contenido dinámico. - Validar archivos cargados. - No mostrar rutas internas. - Revisar endpoints heredados. - No publicar credenciales. - No habilitar `shortrelay.php` sin revisar su propósito. - Evitar URLs arbitrarias en `startCircuitLink` sin validación. - Aplicar políticas adecuadas de `Content-Security-Policy` después de comprobar los scripts reales. - No bloquear con CSP los recursos locales de SimcirJS o CircuitJS1. - Mantener los simuladores en el mismo origen cuando se necesite comunicación JavaScript. --- ## 14. Licencias y créditos ### SimcirJS SimcirJS usa licencia MIT. Se deben conservar los avisos de copyright y licencia. ### CircuitJS1 La distribución mantenida por `sharpie7/circuitjs1` usa GPL versión 2 o posterior. Se deben conservar los avisos, créditos y obligaciones correspondientes. El sitio debe incluir una sección de créditos técnicos, como mínimo en la página de simuladores o en el pie de página técnico. La IA no debe borrar archivos `LICENSE`, `COPYING`, encabezados o créditos incluidos en las distribuciones. --- ## 15. Metodología de modernización página por página Para cada archivo que entregue el propietario: 1. Identificar su función. 2. Identificar rutas y enlaces de entrada. 3. Identificar includes. 4. Identificar parámetros GET. 5. Identificar acciones POST. 6. Identificar sesiones, cookies y autenticación. 7. Identificar consultas SQL o archivos de datos. 8. Identificar JavaScript asociado. 9. Identificar CSS asociado. 10. Identificar archivos subidos o descargados. 11. Resumir qué hace actualmente. 12. Proponer cambios visuales sin romper la función. 13. Modificar solamente después de entender el flujo. 14. Probar escritorio y móvil. 15. Registrar el cambio en este documento. 16. Añadir la página al mapa del sitio. 17. Registrar pendientes y limitaciones. --- ## 16. Registro progresivo de páginas Esta sección debe ampliarse con las páginas reales. | Página | Función actual | Ruta | Backend | Estado de modernización | |---|---|---|---|---| | Portada | Pendiente de revisar | Pendiente | Pendiente | No iniciada | | Simuladores | Digital y analógica | Pendiente | SimcirJS/CircuitJS1 | Arquitectura definida | | Proyectos | Catálogo de proyectos personales | Pendiente | Pendiente | Arquitectura definida | | Proyecto individual | Documentación completa | Pendiente | Pendiente | Arquitectura definida | | Recursos | Otros contenidos técnicos | Pendiente | Pendiente | Por definir | | Acerca de | Información del sitio | Pendiente | Pendiente | Por definir | --- ## 17. Registro progresivo de proyectos Cada proyecto indicado por el propietario debe añadirse aquí. | Proyecto | Categoría | Estado real | Página | Archivos | Pendientes | |---|---|---|---|---|---| | Aún no registrado | — | — | — | — | Esperando información | Para cada nuevo proyecto se debe registrar: - nombre exacto; - propósito; - estado; - hardware; - software; - fotografías; - archivos; - URL; - texto público; - información que no debe publicarse; - pendientes técnicos. --- ## 18. Criterios de aceptación del sitio La modernización se considera correcta cuando: - el sitio conserva sus funciones previas; - las rutas antiguas relevantes siguen funcionando; - la navegación es coherente; - el dominio tiene identidad propia; - SimcirJS funciona con archivos locales; - CircuitJS1 funciona con archivos locales; - el selector digital/analógico no pierde el trabajo del usuario; - la página es utilizable en móvil; - los proyectos pueden añadirse de forma ordenada; - cada página tiene documentación suficiente; - otra IA puede continuar leyendo este archivo; - se registran limitaciones y tareas pendientes; - los créditos y licencias están visibles y preservados. --- ## 19. Información que debe solicitarse antes de modificar código Para comenzar la implementación real, se deben obtener: 1. Archivo principal o router del dominio. 2. Página de inicio actual. 3. Página actual donde estarán los simuladores. 4. Listado real de archivos dentro de `js`. 5. Includes de encabezado, menú y pie. 6. CSS actual. 7. JavaScript propio del dominio. 8. Configuración de rutas o `.htaccess`, si existe. 9. Backend PHP relacionado. 10. Una captura de la apariencia actual, si ayuda a identificar funciones. 11. Primera lista de proyectos personales. 12. Nombre definitivo del sitio o marca, si ya existe. No es obligatorio recibir todo a la vez. Se puede avanzar por página, pero siempre documentando las dependencias descubiertas. --- ## 20. Próximo paso técnico El siguiente paso recomendado es revisar el archivo principal que carga la portada o actúa como router. Después se revisará la página destinada a los simuladores y el contenido real de la carpeta `js`. La primera implementación debe centrarse en: 1. sistema visual base; 2. encabezado, navegación y pie; 3. portada; 4. página unificada de simuladores; 5. carga digital local; 6. carga analógica local; 7. validación responsiva; 8. documentación de rutas y dependencias. No se deben inventar páginas backend ni eliminar el sistema actual sin revisar sus archivos. --- ## 21. Referencias técnicas - SimcirJS: https://kazuhikoarase.github.io/simcirjs/ - Código SimcirJS: https://github.com/kazuhikoarase/simcirjs - CircuitJS1: https://github.com/sharpie7/circuitjs1 - Interfaz JavaScript CircuitJS1: https://www.falstad.com/circuit/doc/js-interface.html - Repositorio indicado por el propietario: https://github.com/pfalstad/circuitjs1 --- ## 22. Nota para cualquier IA futura Este documento es una especificación viva. No debe tratarse como una descripción cerrada. Cada vez que el propietario entregue una página o describa un proyecto: 1. actualizar este documento; 2. registrar hechos confirmados; 3. separar hechos de propuestas; 4. preservar código que ya funciona; 5. indicar exactamente qué archivos se modificaron; 6. documentar pruebas realizadas; 7. documentar qué falta; 8. evitar reconstrucciones totales sin necesidad. El propósito es que el sitio pueda evolucionar durante años sin perder su historia técnica ni depender de la memoria de una sola conversación.