ITHZ MCP

Memoria del proyecto con un plan para el siguiente paso

Qué aporta

• El proyecto posee la memoria: los agentes reciben paquetes de contexto deterministas y específicos de la tarea en lugar de depender de un chat o de escanear todo el archivo.
• Los eventos permanecen inmutables mientras que las decisiones, riesgos, compuertas y afirmaciones son registros tipados con procedencia, validez y sustitución explícita.
• Los registros vinculados a fuentes pueden verificarse contra evidencia exacta; la memoria no verificada o desvinculada puede bloquearse o ponerse en cuarentena en lugar de confiarse automáticamente.
• Implementadores, revisores y oponentes independientes pueden recibir diferentes vistas de evidencia, incluida una ruta de datos crudos que reduce el sesgo de resúmenes compartidos.
• Los hashes de puntos de control, los recibos de comandos y los manifiestos de revisión final hacen que el estado revisado del proyecto sea reproducible, mientras que Git sigue siendo el historial del código fuente e ITHZ MCP sigue siendo evidencia de revisión, no autoridad de despliegue.

Planificar primero, verificar cada traspaso

Al inicio de la tarea, proponga los pasos, roles de asesoría, dependencias, verificaciones, rutas de reparación y límites de aprobación. Una tarea pequeña puede permanecer con un solo agente; los roles adicionales no se inician automáticamente.

El coordinador local opcional vincula los resultados al checkout y al contrato de la tarea, conserva los fallos y aplica los límites de reparación y tiempo configurados. La ejecución es secuencial en esta versión. No reemplaza los permisos del host, un sandbox del sistema operativo ni un adaptador de despliegue.

Las afirmaciones ya no se hacen pasar por hechos

Las notas clásicas de proyecto son útiles hasta que las decisiones antiguas y nuevas entran en conflicto o un resumen pierde su fuente. ITHZ MCP mantiene un rastro de episodios inmutable y construye abstracciones tipadas sobre él: una decisión, riesgo, compuerta o afirmación puede apuntar a evidencia, declarar su alcance y ser sustituida sin borrar el historial.

El resultado práctico es un contexto más pequeño y específico por rol. Un implementador puede recibir las decisiones y restricciones necesarias para una tarea, mientras que un revisor u oponente entre laboratorios puede inspeccionar una ruta de evidencia más independiente. El modelo no se vuelve mágicamente más inteligente; se vuelve más consistente y más fácil de auditar.

Un canario con frenos, no una segunda autoridad

Una memoria de larga duración puede preservar un error con la misma eficiencia que una decisión correcta. Por lo tanto, el canario prueba memoria sospechosa o conflictiva en un carril deliberadamente restringido: comienza deshabilitado, solo lee evidencia, tiene límites de tiempo y de casos, y puede detenerse con un interruptor de seguridad.

Su veredicto no puede ejecutar un cambio ni escribirse en el archivo como verdad. La promoción sigue dependiendo de recibos trazables, revisión independiente y la autoridad humana o de flujo de trabajo que ya gobierna el proyecto.

La memoria existente del proyecto no necesita reescribirse

Los archivos existentes de project.ithz siguen siendo legibles. La actualización segura consiste en hacer una copia de seguridad del archivo, instalar el paquete actual en un entorno nuevo de Python 3.10+, ejecutar las verificaciones de integridad de memoria y del canario, y mantener el canario deshabilitado hasta que el proyecto opte explícitamente por activarlo.

Los registros antiguos pueden permanecer como evidencia heredada mientras el nuevo trabajo comienza a producir procedencia más sólida y recibos de revisión v2. Las instalaciones muy antiguas o personalizadas aún necesitan una prueba específica del proyecto y un plan de reversión probado; la compatibilidad no es una razón para omitir la verificación.