Cotal-AI/gestores-paralelos-de-funcionalidades

Gestores paralelos de funcionalidades

Usa la malla activa de Cotal como una jerarquía:

• La sesión actual es el coordinador. Crea aislamiento, establece políticas, monitorea el progreso y retransmite decisiones. No duplica implementación ni revisión del panel.
• Cada funcionalidad obtiene un gestor enraizado en su propio worktree de Git y rama. El gestor es dueño del ciclo completo: planificación -> implementación -> revisión -> pruebas -> commit.
• Cada gestor genera tres o más pares solo lectura/revisión en un canal dedicado: como mínimo ingeniero, seguridad y crítico.
• Cerca de la puerta final, cada gestor añade un revisor externo independiente, instruido bajo la habilidad cold-review, que es la fuente única de cómo se instruye, aísla y califica ese puesto. Es un control sobre el panel, no un cuarto panelista.

Modelos: los paneles multi-proveedor son una regla de corrección, no una preferencia

Ningún puesto cuya concordancia sea vinculante puede compartir familia de modelos. Una confirmación realizada por un puesto de la misma familia que el que la emitió es un eco, no una confirmación. Un panel de tres revisores del mismo modelo ha aprobado una cabeza que contenía un defecto que los tres pasaron por alto, y lo que lo descubrió fue una lectura con un marco diferente, no un cuarto verificador.

Exprésalo así, no como un recuento. La disponibilidad es una propiedad del momento, no del proveedor: el mismo modelo se ha unido y entregado una hora y no ha podido unirse la siguiente, en el mismo host con las mismas herramientas. Una regla redactada como "N proveedores distintos" es insatisfacible en una flota degradada, y silenciosamente; y una regla que puede romperse con el reloj se ignora en lugar de obedecerse. cold-review lleva la orden de degradación y el mínimo.

Fija el modelo explícitamente al generar Y en la persona, porque la capacidad no registrada es, en efecto, no calificada: un revisor cuyo esfuerzo o modelo nadie registró produce un veredicto que nadie puede ponderar después.

Los gestores pueden ejecutar un modelo más fuerte que sus revisores. Los revisores no deben ejecutar el mismo modelo que el coordinador, para que el panel no pueda heredar los puntos ciegos del coordinador.

Verifica los identificadores exactos del modelo contra el catálogo del conector antes de generar, y trata un nivel de esfuerzo de razonamiento declarado como no verificado hasta que un puesto se haya lanzado realmente con él: un catálogo puede declarar niveles que el proveedor rechaza, y un nivel rechazado mata el puesto al lanzarse.

Reglas estrictas

• Nunca cambiar la rama del coordinador. Crea worktrees desde una base confirmada con nombre.
• Un gestor por funcionalidad, un revisor por carril de canal y un revisor externo independiente por funcionalidad. Selecciona el contacto y destino de ese puesto bajo cold-review. Un destino de archivo es una alternativa solo normativa y no puede satisfacer una puerta que requiera identidad de publicador atestiguada por el bróker. No se permiten instancias hermanas ni bifurcación de pruebas a menos que el usuario lo solicite.
• Solo los gestores editan su worktree de funcionalidad. Los revisores solo leen, ejecutan comprobaciones no mutantes y publican hallazgos con referencias de archivo/línea.
• Cada funcionalidad usa un canal de panel, review.<slug-de-funcionalidad>, más un canal dedicado de registro externo, review.<slug-de-funcionalidad>.cold-record. Mantén los acuses de recibo y el cháchara de estado fuera del canal del panel; úsalo para planes, hallazgos, disposiciones razonadas, solicitudes de revisión de código y resultados finales.
• El revisor externo independiente no está en ese canal. Su aislamiento, instrucción e informes son propiedad de cold-review; aplícalos allí, no los repliques por carril.
• Las decisiones de producto/diseño viajan por MD: gestor -> coordinador -> usuario -> coordinador -> gestor. Un gestor no debe adivinar una elección trascendental no resuelta.
• Nunca fusiones, subas, abras un PR ni elimines worktrees a menos que el usuario lo pida.
• Nunca interrumpas el bróker de la malla activa. Las pruebas usan espacios desechables y puertos altos aleatorios; mata los procesos de prueba por PID exacto, nunca un pkill amplio.

1. Establecer la matriz de funcionalidades

Para cada funcionalidad solicitada, elige y registra:

Campo	Ejemplo
Funcionalidad	exportación de canales
Slug	channels-export
Rama	feat/channels-export
Worktree	ruta hermana como Cotal-feature-channels-export
Persona del gestor	mgr-channels-export
PR	número exacto, o ninguno hasta que exista uno
Canal	review.channels-export
Contrato	comportamiento concreto, límites, pruebas y no-objetivos conocidos

Resuelve colisiones de rama/ruta antes de crear nada. Inspecciona git status, git worktree list --porcelain y las ramas existentes. No limpies ni reviertas estado sucio no relacionado.

Crea los worktrees secuencialmente porque mutan metadatos compartidos de Git:

git worktree add -b feat/<slug> /ruta/absoluta/hermana/Cotal-feature-<slug> <base>

Usa el mismo commit base para todas las funcionalidades a menos que el usuario quiera explícitamente trabajo apilado.

2. Hacer disponible el contexto del repositorio privado

Antes del lanzamiento, verifica que cada worktree pueda leer .internal/plans/STATUS.md y las guías relevantes. Normalmente git submodule update --init .internal es suficiente.

Si la inicialización falla porque el superproyecto fija un commit no disponible:

1. Compara el puntero confirmado (git ls-tree <base> .internal) con el HEAD del submódulo local activo (git -C .internal rev-parse HEAD). Esto es desviación del estado del repositorio, no un problema de ACL de Cotal.
2. Prefiere arreglar/publicar el commit de submódulo previsto y el puntero del superproyecto cuando esté autorizado.
3. Para una ejecución paralela temporal, materializa el commit .internal local conocido como bueno de forma independiente en cada worktree de funcionalidad desde el repositorio de submódulo local activo.
4. Informa a los gestores que el superproyecto puede mostrar M .internal; deben leerlo pero nunca escenificarlo, editarlo ni incluirlo en los commits de funcionalidad.

No dejes a los gestores bloqueados solo porque un worktree nuevo no puede obtener un commit privado que ya está disponible y verificado localmente. No pretendas que el desajuste está limpio; informa la reparación permanente necesaria.

3. Crear primero las personas del gestor y revisor con la política

Los agentes gestores necesitan capabilities: [spawn] más ACL de canal. Los agentes revisores necesitan ACL de canal y no deben tener spawn. cotal_persona no puede otorgar política, y cotal_spawn no puede anular allowSubscribe o allowPublish, así que escribe cada archivo de persona antes de generar. Estos archivos son locales/ignorados en este repositorio. Una máquina limpia que solo tiene una persona predeterminada no puede formar el panel: los nombres de spawn a continuación fallan a menos que esos archivos existan, y una persona local sobrante no es un sustituto porque sus concesiones pueden faltar o ser más amplias que el carril.

---
name: mgr-<slug>
role: feature-manager
model: <modelo de gestor fijado>
description: Dueño de <feature> y su panel de revisión.
tags: [manager, <slug>]
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>, review.<slug>.cold-record]
allowPublish: [review.<slug>]
capabilities: [spawn]
---

Crea archivos coincidentes para los tres puestos del panel y el puesto externo antes de cualquier spawn. Dale a cada persona de revisor un nombre de archivo con alcance de carril como review-<slug>-ingeniero; el catálogo de personas es compartido por carriles concurrentes, por lo que los nombres de archivo genéricos chocan incluso cuando los worktrees y canales no lo hacen. Las personas del panel se suscriben y publican solo en review.<slug>. La persona externa lista subscribe y allowSubscribe vacíos para que la no unión sea una propiedad del puesto, no una instrucción, y puede publicar solo a review.<slug>.cold-record. No reutilices ni redefinas una persona de revisor de otro carril.

---
name: review-<slug>-ingeniero
role: reviewer
model: <modelo de panel fijado, familia A>
subscribe: [review.<slug>]
allowSubscribe: [review.<slug>]
allowPublish: [review.<slug>]
capabilities: []
---

---
name: review-<slug>-externo
role: reviewer
model: <modelo externo fijado, no la familia del autor>
subscribe: []
allowSubscribe: []
allowPublish: [review.<slug>.cold-record]
capabilities: []
---

Repite la plantilla del panel para review-<slug>-seguridad y review-<slug>-critico con diferentes familias de modelos. Si luego se requiere un árbitro, crea review-<slug>-arbitro de la misma manera que el puesto externo, con subscribe y allowSubscribe vacíos más una concesión de allowPublish en un canal de registro dedicado, antes de generarlo.

El prompt del gestor debe incluir todo lo siguiente:

• Contrato exacto de la funcionalidad, rama y ruta absoluta del worktree.
• Ser dueño de la funcionalidad de principio a fin y confirmar solo los archivos previstos.
• Leer las instrucciones del repositorio, documentos actuales y .internal antes de editar.
• Unirse primero a review.<slug>.
• Generar solo las personas creadas en esta sección. Generar review-<slug>-ingeniero, review-<slug>-seguridad y review-<slug>-critico, colocados de modo que ninguno de ellos cuya concordancia sea vinculante comparta familia de modelos. Esa es la regla ordinal anterior y no un recuento. Cuando el conjunto de proveedores sea corto, nombra la colisión mecánicamente y la clase que deja descubierta. Nombrar es divulgación, no finalización: un panel cuyas aprobaciones vinculantes son ecos de la misma familia no puede completarse, incluido A, A, A y A, B, A. No trates un panel formado pero colisionado como una puerta superada. Dale a cada uno su propio worktree separado como cwd. Un revisor califica en su propio árbol, nunca en el árbol que está calificando, y "solo lectura" debe nombrar los verbos de escritura de Git explícitamente (checkout, switch, stash, reset, clean, restore) en lugar de solo decir "no editar código fuente".
• Enviar MD a cada identidad de revisor devuelta para unirse al canal y permanecer solo lectura/revisión.
• Ejecutar revisión del plan antes de editar, revisión de código/pruebas después de la implementación, doblar los hallazgos válidos y pedir a los tres una disposición final.
• Después de que el panel y la implementación converjan, generar exactamente un review-<slug>-externo en su propio worktree separado e instruirlo bajo la habilidad cold-review, que es propietaria de lo que se le da a ese puesto, a dónde va su veredicto, qué vincula el veredicto y cómo se degradan las reglas cuando el conjunto de proveedores es corto. No repliques nada de eso aquí.
• Resolver los hallazgos externos bajo la regla canónica de cold-review, nunca diciéndole a ese puesto que reconsidere. Si el gestor creó el cambio y un bloqueador necesita refutación independiente, envía al coordinador solo el hallazgo con SHA exacto y el artefacto. El coordinador provisiona un review-<slug>-arbitro fresco en su propio worktree separado; ese puesto no participó en la creación, calificación ni supervisión del carril, no comparte familia de modelos con el autor y no recibe ningún razonamiento del autor. El coordinador provisiona al árbitro pero no actúa como él. Si un pliegue cambia código, devuelve el resultado al panel del canal para otra pasada final y fija de nuevo el puesto externo al nuevo SHA con su límite de entrega explícitamente reiniciado por escrito. Si ese puesto se ha ido, crea una persona externa nueva con subscribe y allowSubscribe vacíos más solo su concesión de allowPublish en el canal de registro dedicado, genéralo e instrúyelo bajo cold-review en el nuevo SHA como un nuevo puesto de una entrega. Eso es un sucesor, no una tercera ruta de cierre para el SHA antiguo.
• Resolver la cabeza como una acción, no como una afirmación posterior. Al instruir, en cualquier afirmación de finalización, y nuevamente antes de fusionar, el gestor o coordinador resuelve primero el destino de la revisión. Para un PR, ejecuta git ls-remote origin refs/pull/<n>/head y verifica gh pr view <n> --json headRefOid. Para una rama sin PR, resuelve git ls-remote origin refs/heads/<branch> y omite la verificación cruzada de API solo para PR. Obtén el objeto resuelto en el worktree de revisión separado si aún no está presente, luego ejecuta git cat-file -t en ese objeto con un control conocido y un ID de objeto de ancho completo conocido como faltante, como cuarenta ceros, que debe fallar. No hagas el control negativo añadiendo un carácter al ID real: Git puede resolver el ID de objeto inicial válido y devolver éxito. Nombra al actor que ejecutó los instrumentos. Si los instrumentos aplicables no coinciden, detente. Un veredicto o refutación que nombra un SHA diferente no cierra esta cabeza.
• Ejecutar las pruebas relevantes él mismo. Los revisores no editan el código fuente.
• Escalar solo decisiones trascendentales no resueltas con esta estructura exacta:

DECISIÓN NECESARIA: <pregunta de una línea>
Opciones: <A>; <B>; ...
Recomendación: <recomendación del gestor y por qué>
Impacto: <comportamiento observable / compatibilidad / riesgo>
Bloqueado: <lo que no puede continuar>; Continuando: <lo que puede continuar>

• Al finalizar, enviar MD al coordinador el ID del commit, pruebas ejecutadas, las tres disposiciones del panel, el veredicto externo final y cualquier refutación pública, y riesgos residuales.

4. Sembrar canales y lanzar gestores

Crea el canal del panel y el canal de registro externo dedicado antes de invitar al equipo, con reproducción habilitada y una breve nota del operador. Luego genera cada gestor mediante cotal_spawn:

name: mgr-<slug>
role: feature-manager
agent: <conector>
model: <modelo de gestor fijado>
cwd: /ruta/absoluta/al/worktree-de-funcionalidad

Lanza los gestores en paralelo solo después de que existan todos los worktrees, personas y canales. Rastrea la identidad del revisor devuelta, no un nombre supuesto; un lanzamiento reiniciado o duplicado puede seguir numerándose automáticamente aunque el nombre de archivo de la persona tenga alcance de carril.

Verifica con cotal_roster que cada gestor aparezca y tenga su panel completo. No generes duplicados que parezcan faltantes prematuramente; permite tiempo de inicio y vuelve a verificar primero.

Un spawn que informa un tiempo de espera no es evidencia de que el spawn falló. Puede que ya haya tenido éxito, y reintentar envía un segundo objetivo que duplica el efecto. Lee el resultado de la lista de procesos antes de actuar, y nunca reintentes solo por un tiempo de espera.

Verifica un puesto por RESPUESTA, nunca por presencia. Un puesto puede informar como en ejecución y estar silenciosamente inalcanzable. Pide un artefacto nonce que deba producir, como un echo de un token aleatorio unido al commit corto en el que está sentado, y verifica la salida cruda. Un apretón de manos que indica la respuesta esperada ("confirma que estás en en ") es tendencioso: una respuesta compatible con echo prueba que algo puede reflejar texto, no que se ejecutó un shell.

El revisor independiente es intencional

…

[truncado para traducción]