Actúa como un arquitecto de software de élite, especialista ...

Prompt

Actúa como un arquitecto de software de élite, especialista en gobernanza para desarrollo asistido por Inteligencia Artificial y auditor senior de calidad de software (QA). Tu objetivo es realizar una auditoría técnica exhaustiva, formular propuestas de mejora de alto impacto y diseñar nuevas funcionalidades para un producto singular: un sistema operativo de reglas, utilidades y protocolos concebido para gobernar la interacción y el trabajo en pareja (pair programming) entre modelos de lenguaje avanzados (agentes de IA) y un ingeniero humano. No tienes acceso al repositorio de código ni a sus archivos. Por ello, este documento de contexto contiene una radiografía completa, fidedigna y detallada de su arquitectura, filosofía operativa, herramientas internas, invariantes de seguridad, fricciones recurrentes y estado evolutivo actual. Tu informe debe ser extremadamente minucioso, profundamente razonado, técnicamente viable y ajustado con precisión milimétrica a las exigencias del creador del sistema. ### 1. PERFIL DEL DESTINATARIO Y REQUISITOS DE TONO Y COMUNICACIÓN El creador, mantenedor y usuario exclusivo de este sistema es Marc, un Ingeniero de Aseguramiento de la Calidad (QA) senior especializado en automatización de pruebas, verificación adversarial, trazabilidad y análisis de causa raíz. Para él, las promesas de un modelo de lenguaje no valen nada sin evidencias reproducibles y cuantificables. Su mentalidad profesional exige las siguientes directrices en tu informe: - Cero complacencia y rechazo frontal al peloteo: Detesta las alabanzas gratuitas ('¡Excelente arquitectura!', 'Brillante planteamiento') o el asentimiento ciego. Si detectas una debilidad conceptual, un cuello de botella o una asunción ingenua, señálala de frente, aportando datos, casos límite y escenarios de rotura. - Escepticismo metodológico constructivo: Valora únicamente al colaborador que cuestiona, duda, verifica con pruebas y desmonta premisas frágiles antes de llegar a producción. - Alergia al ruido cognitivo y a la jerga vacía: No soporta explicaciones abstractas, palabrería de consultoría ni relleno. Si empleas un concepto técnico avanzado, justifica su necesidad práctica y contextualízalo al instante. - Prohibición explícita de clichés de IA: Está terminantemente vetado el uso de fórmulas prefabricadas como 'En resumen', 'En conclusión', 'En definitiva', 'Como modelo de lenguaje' o 'Es importante destacar'. - Orientación a la acción determinista: Cada propuesta debe detallar QUÉ hacer exactamente y CÓMO implementarlo paso a paso (arquitectura, comandos y flujos), sopesando efectos colaterales. - Economía estricta de la atención: Marc delega la ejecución en los agentes, pero retiene las decisiones estratégicas. Por ello, las decisiones deben presentarse de una en una, formuladas con claridad meridiana y sin obligarle a procesar árboles infinitos de opciones. ### 2. FILOSOFÍA, ARQUITECTURA GENERAL E INVARIANTES DE 'AGENT-DESK' El proyecto (denominado 'rules-template' en su repositorio matriz y conocido operativamente como 'agent-desk') nació para resolver un problema crítico en el desarrollo asistido por IA: la degradación del trabajo cuando las sesiones se alargan. Los modelos olvidan acuerdos tras compactar contexto (/compact), inventan soluciones que contradicen decisiones previas, sufren desviaciones no deseadas ('drift') y generan código sin documentar la necesidad que lo originó. El sistema se estructura sobre principios innegociables: 1. Modelo 'Fábrica' frente a 'Repositorios Consumidores': El desarrollo de reglas y herramientas ocurre en un repositorio central aislado (la 'fábrica'). Una vez consolidadas, estas piezas se distribuyen hacia los repositorios finales de Marc (vida personal, desarrollo educativo, herramientas de QA y entornos profesionales). 2. Núcleo portable y candado criptográfico: Alrededor de 118 ficheros constituyen el núcleo portable (documentos de gobierno, utilidades CLI, ganchos de git y plantillas). La regla de oro establece que NADIE puede modificar un fichero portable dentro de un repositorio consumidor. Un manifiesto criptográfico (MANIFIESTO.md) almacena las huellas hash de cada uno. Un gancho de control en cada commit aborta cualquier operación si detecta que un fichero portable ha sufrido modificaciones locales. Lo propio de cada proyecto debe confinarse obligatoriamente en AGENTE- LOCAL.md y en el directorio local/. 3. Jerarquía inmutable de la verdad: REQUERIMIENTOS.md es la máxima autoridad del proyecto, por encima del código y de la memoria del chat. Si el código hace algo que contradice este documento, el código se considera defectuoso. Las pruebas automatizadas se escriben contra los requerimientos especificados, nunca para bendecir lo que el código hace hoy. 4. 'Nada muere en el chat': Cualquier acuerdo, idea o aclaración surgida en la conversación debe registrarse en su documento correspondiente ANTES de proponer soluciones o picar código (orden inquebrantable: registrar -> proponer -> implementar). De lo contrario, la siguiente compactación de contexto borrará la decisión y obligará al usuario a rehacer el camino. 5. Los agentes mantienen el estado; el usuario no: Marc no toca las tablas de tareas ni los resúmenes de situación. Son los agentes quienes deben mantener impecablemente actualizados los tableros, registrar las horas y reflejar el progreso para que el usuario no sufra carga administrativa. ### 3. RADIOGRAFÍA DETALLADA: DOCUMENTACIÓN DE GOBIERNO Y CAJA DE HERRAMIENTAS El ecosistema combina especificaciones vivas en Markdown con utilidades de terminal en Node.js estándar, bajo una premisa de autosuficiencia: cero dependencias pesadas, cero servicios en la nube y cero bases de datos externas. A. Documentos Clave de Gobierno: - INICIO.md: Control de acceso obligatorio. Define la secuencia exacta en la que un agente debe leer los documentos al ingresar a un repositorio o tras un /compact (INICIO -> AGENTE -> AGENTE-LOCAL -> ESTILO-ESCRITURA -> ESTADO -> REQUERIMIENTOS -> TODO). - AGENTE.md: Contrato ético y de conducta. Establece la personalidad de par escéptico, prohíbe la adulación, regula los límites de seguridad y fija el formato de entrega mediante una 'marca de lectura': un bloque final (## Marc, lee a partir de aquí) que contiene un resumen en lenguaje llano libre de jerga y un apartado obligatorio (### Lo que tienes que hacer tú) limitado a un máximo de tres puntos accionables de una sola frase, evitando que el usuario deba bucear entre salidas de terminal o trazas de razonamiento. - ESTILO-ESCRITURA.md: Manual de estilo para redacción en castellano natural, control de acentuación, convenciones tipográficas y erradicación de vicios estilísticos y giros robóticos generados por LLMs. - ESTADO.md: Instantánea de continuidad. Gestiona el traspaso entre sesiones bajo dos modalidades: 'en frío' (cierre de jornada con las tareas en reposo) o 'en caliente' (sesión viva donde se dejan preparadas las dos o tres acciones inmediatas con sus comandos exactos). Documenta dónde está el proyecto, qué cosas no se deben rehacer, las prohibiciones expresas y las hipótesis aún no confirmadas. - TODO.md y DASHBOARD.html: TODO.md actúa como base de datos de tareas. Cada tarjeta posee un identificador secuencial único por área (AREA-###), fecha de inicio, fecha de fin obligatoria al cerrarse, nivel de prioridad, estado (ok, wait, stop, done), etiquetas, estimación frente a tiempo real invertido, un título conciso (máximo 60 caracteres) y una nota explicativa para el usuario (máximo 220 caracteres). A partir de esta tabla, tools/dashboard/ genera DASHBOARD.html, un panel monorresurso en HTML puro con fuentes e iconos SVG incrustados, consultable sin servidor con doble clic en local. - CALIDAD.md: Cuaderno de bitácora del 'búnker'. Registra cada hallazgo y regresión clasificando su origen para medir la tendencia de defectos, y audita los puntos de control del barrido diario que impone que todo archivo nuevo o modificado cuente con un vigilante de pruebas automatizado o una exención justificada. B. Caja de Herramientas Internas (tools/): - tools/manifest/: Calcula y audita las firmas criptográficas de los 118 archivos portables, garantizando la integridad del núcleo frente a manipulaciones directas en proyectos cliente. - tools/split/: Analizador y particionador de documentos Markdown de gran volumen. Detecta capítulos que exceden techos críticos de tokens (~10.000 tokens) y los subdivide por encabezados jerárquicos, manteniendo índices cruzados para no colapsar la memoria del modelo al arrancar. - tools/quality/: Ejecuta barridos de integridad, verifica la cobertura de pruebas de cada fichero del repositorio y asegura que las métricas de tendencia reflejen la calidad real. - tools/autoversion/: Gestiona el versionado semántico formal e incrementa automáticamente el historial de versiones (CHANGELOG) redactado en castellano natural. - tools/audit-pack/: Protocolo de auditoría adversarial en el que pasadas limpias e independientes de agentes evalúan el código y las reglas en busca de vulnerabilidades y puntos ciegos. - tools/ui/ y ui/kit/: Sistema de diseño desacoplado y componentes HTML/CSS listos para ser consumidos sin herramientas de compilación (sin Vite, Webpack ni dependencias npm), incluyendo una galería visual interactiva (galeria.html). - tools/message/: Gancho de control que supervisa la longitud de las respuestas de los agentes y bloquea cualquier intento de cerrar el turno sin respetar la marca de lectura. - tools/verify/ y Git Hooks: Ganchos automatizados (commit-msg, pre-commit, pre-push) que vigilan que ningún commit contenga identificadores mal formados, nombres prohibidos en castellano dentro del código, firmas rotas o documentos huérfanos de pruebas. ### 4. ESTADO EVOLUTIVO, FRICCIONES TÉCNICAS Y DESAFÍOS REALES La plataforma ha alcanzado formalmente la versión 1.0.0 y avanza hacia la 1.0.1 en un ciclo de rodaje controlado: - Banco de pruebas continuo: Se emplea el repositorio de vida personal de Marc como laboratorio de pruebas en caliente antes de autorizar la mudanza definitiva de las herramientas hacia los repositorios corporativos de su entorno laboral. - La trampa de la deducción frente a la autoridad explícita (FAB-213): Varias herramientas deducían la versión del proyecto o la naturaleza del entorno a partir de rutas y nombres de directorios en lugar de consultar la lista oficial sellada en el manifiesto, provocando parches en cascada cuando cambiaba la profundidad del árbol de carpetas. - Compatibilidad multiplataforma rigurosa: El usuario alterna continuamente entre macOS y Windows. Esto ha provocado fricciones en la resolución de rutas (separadores / frente a \\), tratamientos de saltos de línea mixtos (CRLF frente a LF al partir documentos), codificación de caracteres especiales y diagnósticos cruzados incorrectos (como achacar a Windows errores ENOENT originados en macOS). - La trampa del resultado vacío frente al resultado limpio: Se descubrió que ciertas herramientas de verificación ejecutadas por agentes devolvían listas vacías debido a parámetros erróneos en llamadas a comandos internos; el sistema interpretaba el resultado como 'cero defectos encontrados', cuando en realidad la herramienta había fallado silenciosamente sin llegar a inspeccionar nada. - Presupuesto de tokens en el arranque: Inyectar todo el catálogo de documentos normativos y de estado al arrancar una sesión satura decenas de miles de tokens de contexto, encareciendo la interacción y aproximando prematuramente al agente a la zona de degradación de atención y olvido. - Riesgo de parálisis por auto-mantenimiento: Existe una constante tensión entre perfeccionar las herramientas de gobernanza interna y avanzar en los entregables reales de los proyectos, corriendo el riesgo de caer en bucles burocráticos donde el sistema se vigila a sí mismo en lugar de producir valor. ### 5. ESTRUCTURA Y REQUISITOS OBLIGATORIOS DEL INFORME TÉCNICO Tu informe debe estructurarse con total pulcritud en los cuatro bloques siguientes. Proporciona argumentos técnicos de fondo, desestima soluciones superficiales y fundamenta cada aseveración: BLOQUE 1: AUDITORÍA Y DIAGNÓSTICO CRÍTICO DE LA ARQUITECTURA ACTUAL 1. Analiza las vulnerabilidades conceptuales, asunciones frágiles y puntos ciegos derivados de gobernar agentes mediante documentos Markdown y scripts en Node.js. 2. Evalúa la fragilidad del análisis sintáctico basado en expresiones regulares y parsing de texto plano frente a esquemas de datos estructurados para tareas y estados. 3. Examina el impacto de la sincronización de archivos en repositorios donde múltiples agentes o herramientas puedan operar en paralelo. BLOQUE 2: PROPUESTAS DE NUEVAS FUNCIONALIDADES INÉDITAS (ALINEADAS CON EL ADN DEL PRODUCTO) Diseña entre 4 y 6 funcionalidades de alto valor que NO existan en el sistema ni figuren en su hoja de ruta conocida, manteniendo la premisa de no añadir servidores pesados ni dependencias externas. Para CADA propuesta debes detallar de forma exhaustiva: a) Denominación técnica y problema concreto que resuelve en la interacción humano-agente. b) Arquitectura de la solución (si opera como gancho de git, script CLI, protocolo documental o módulo del dashboard). c) Flujo operativo paso a paso (cómo interactúa el usuario, cómo actúa el agente y qué cambios se producen en el disco). d) Beneficio neto para Marc (ahorro de fricción cognitiva) y salvaguardas implementadas para evitar regresiones. BLOQUE 3: PLAN DE REFACTORIZACIÓN, ROBUSTEZ Y OPTIMIZACIÓN 1. Define un diseño arquitectónico definitivo para erradicar las discrepancias entre Windows y sistemas POSIX en el manejo de rutas y ficheros sin recurrir a parches condicionales dispersos. 2. Diseña la especificación formal del 'contrato de medición' que obligue a toda herramienta a declarar cuántos elementos examinó y bajo qué condiciones, impidiendo que una salida vacía se confunda con un resultado exitoso. 3. Plantea una estrategia avanzada para aligerar radicalmente el coste de tokens al inicio de cada sesión (arranque bajo demanda o fragmentación semántica) sin debilitar la efectividad del contrato de conducta. BLOQUE 4: MATRIZ DE RIESGOS, COMPENSACIONES Y EFECTOS COLATERALES 1. Realiza una tabla comparativa de costo-beneficio analizando la sobrecarga de mantenimiento de cada innovación frente a su retorno real. 2. Identifica con rigor qué propuestas o reglas actuales corren el riesgo de empujar al equipo al 'bucle burocrático' de hipervigilancia improductiva. 3. Establece criterios cuantitativos y reglas de poda para determinar cuándo una norma, herramienta o control debe simplificarse o eliminarse por haber quedado obsoleta.