Trabajo en equipo

Argui asume por defecto un solo responsable —el orquestador humano que convoca a los agentes (ver agentes/README.md)—. Escalar a un equipo no cambia el proceso: cambia quién posee cada unidad de trabajo, con un principio que ordena lo demás —un responsable por unidad— y un hecho que conviene decir de frente: el trabajo en paralelo es una propiedad de la iteración (Fase 5) y la evolución (Fase 6); la preparación es secuencial por diseño.

Cuándo el equipo trabaja en paralelo

La preparación (Fases 0–4) es una cadena de dependencias reales: el entendimiento alimenta los PRD (Product Requirements Document), los PRD alimentan el prototipo, el prototipo aprobado alimenta el backlog, el backlog los estándares, los estándares los agentes. No se paralelizan porque cada paso necesita el anterior — y forzar el paralelismo ahí fabrica incoherencia, justo el modo de falla que la metodología existe para prevenir (“estructura antes que ejecutores”). El valor de la preparación está en su coherencia, no en su throughput.

Eso no deja al equipo ocioso durante 0–4: en esa etapa converge, no produce en paralelo.

Investigación en paralelo (Fase 1): varios pueden cubrir distintas áreas del dominio (ruta B).
Revisión en los gates ✋: la validación de los PRD y la del prototipo son momentos de equipo — todos juzgan, aunque uno solo redacte.
Onboarding y setup de cada quien (ver abajo) y pre-estudio del stack y las herramientas.
Paralelismo acotado en Fase 4: una vez el arquitecto fija dirección, los estándares por dominio y los agentes por dominio (backend, frontend, infra) se pueden redactar en paralelo; el arquitecto los integra.

El staffing puede ser escalonado: el núcleo (lead + arquitecto) lleva las Fases 0–3 y el resto del equipo entra en la Fase 4/5, cuando ya hay trabajo paralelizable.

Adopción. La preparación es corta y se hace una vez; el paralelismo —y la mayor parte del trabajo— vive en la iteración, donde el grafo de dependencias lo vuelve seguro. No se reparte un problema aún sin definir: se converge un núcleo en una base sólida y luego se abre en paralelo.

Un responsable por unidad; el grafo coordina; el claim es la rama

En el ciclo iterativo la unidad es un change/item del backlog: cada desarrollador toma uno o más items y es su responsable —orquesta los agentes de ese item de extremo a extremo (apply → verify → qa → archive)—.

El grafo de dependencias del backlog es el coordinador. Qué puede ir en paralelo y qué bloquea a qué ya está en el diagrama (workflow.md F4.4, vivo en F5.1). Dos items sin arista entre ellos pueden tener responsables distintos a la vez; tomar trabajo = elegir un nodo sin dependencias abiertas.
El claim es la rama publicada. Tomar un item = publicar su rama (la convención de nombre codifica el ID — ver operations.md → Ramas). La lista de ramas remotas (git branch -r) o de PR (Pull Request) abiertos es el tablero en vivo: dice qué está tomado sin tocar main. El diagrama de progreso del backlog es la vista consolidada (pendiente/en curso/archivado), que se actualiza en los puntos de integración. Como el nombre de la rama es la clave del tablero, un check de CI (Continuous Integration) valida su formato (<tipo>/<ID>-<slug>): un nombre mal formado rompe el tablero, así que se rechaza — lo verificable se verifica como código (esqueleto en templates/equipos/).
Un worktree por unidad en paralelo. Cada unidad simultánea corre en su propio git worktree: rama propia + su entorno de IA confinado propio (el aislamiento de Fase 0 se aplica por worktree). Evita el thrash de cambiar de rama y sostiene una sesión por unidad.
Ramas abandonadas (claim fantasma) las marca la auditoría/grooming (ramas viejas sin commits), que engancha con la métrica de WIP (Work In Progress) de abajo.

Roles singulares y CODEOWNERS

Para que el criterio sea uno solo entre todos los responsables, hay piezas compartidas y versionadas, no por persona:

Los estándares (standards.md) y las definiciones de los agentes (.claude/agents/) viven en el repo; todos convocan a los mismos agentes con el mismo criterio.
Cambiar un estándar o un agente es su propia unidad de trabajo (rama + PR), no un ajuste al vuelo dentro de otra unidad.
El gate de impacto arquitectónico (F5.1) no cambia: todo cambio architectural: true pasa por el arquitecto, lo lleve quien lo lleve.

CODEOWNERS es cómo el forge (GitHub, GitLab…) hace cumplir lo anterior. Es un archivo (.github/CODEOWNERS, o la raíz / docs/) que mapea rutas → dueños (personas o equipos); cuando un PR toca una ruta gobernada, el forge pide la revisión del dueño y —con la protección de rama “requerir revisión de Code Owners” activa— no deja integrar sin su aprobación.

Con varios desarrolladores se crean equipos en el forge (p. ej. @org/arquitectura, @org/plataforma, @org/diseno) y se vinculan los miembros según los mecanismos internos de la organización. Argui entrega una plantilla de CODEOWNERS con las rutas gobernadas ya mapeadas a equipos de marcador de posición — ver templates/equipos/.
Coherencia sin bus-factor. Listar un equipo (no una persona) hace que el rol no dependa de alguien en particular; y como el criterio (estándares + definición del agente arquitecto) viaja versionado con el repo, quien ejerza el rol aplica el mismo criterio documentado — está en los archivos, no en una cabeza.
Portabilidad. CODEOWNERS es del forge; el concepto portable es “aprobación obligatoria por ruta”. Un forge sin esa función cae al check de CI + convención (ver portability.md).

Artefactos compartidos y decisiones

El backlog (con su diagrama), el CLAUDE.md y el decisiones.md los tocan muchas unidades al actualizar progreso. Se resuelven en el merge, no a mano:

El diagrama de dependencias se regenera, no se fusiona a mano: ante un conflicto en el bloque Mermaid, el agente de progreso lo regenera desde los campos Estado/Dependencias después del merge (ya es artefacto vivo — F5.1).
El PR por unidad sigue siendo la pieza que integra; la actualización de progreso entra con él.

decisiones.md es la memoria compartida del equipo. En solitario es un log; en equipo es el canal asíncrono por el que la decisión de un responsable llega a los demás:

Propagación. La decisión viaja en el PR de su unidad: cuando ese PR se integra a main, todos la reciben en su git pull, igual que el código. Si afecta ahora el trabajo en vuelo de otro, se hace commit y push temprano (es una línea — captura en el origen); el chat del equipo es la notificación, el archivo es la verdad durable.
Conflictos. Es append-only y se agrega al final (cronológico): el conflicto, si lo hay, cae en la última fila y se resuelve concatenando ambas, nunca reescribiendo. Si los conflictos llegaran a doler, la escalada es una carpeta decisiones/ con un archivo por decisión (cero conflictos) — el mismo patrón de auditorias/. El default sigue siendo el archivo único.
Dueño. decisiones.md es ruta gobernada; su dueño en CODEOWNERS es el arquitecto.

Guarda de gobernanza en CI

Las reglas verificables de arriba —“cambiar un estándar o un agente es su propia unidad”, “el arquitecto aprueba lo compartido”— se codifican: dejarlas como prosa que el revisor debe recordar es justo lo que el principio lo verificable se verifica como código (standards.md) prohíbe. Es condicional a equipo (en solitario no hay drift que prevenir) y proporcional, en dos capas:

Rutas gobernadas = las que, al cambiar, afectan a todos: standards.md, las definiciones de agentes (.claude/agents/), el schema/perfil de OpenSpec y las skills del ciclo, la config de CI misma, el pin de versión (Argui / OpenSpec / dependencias), decisiones.md y los tokens del design system. (El diagrama de dependencias no se guarda: se regenera.)
Capa 1 — dueño + visibilidad (baseline). CODEOWNERS (arriba): el rol dueño aprueba todo PR que toque una ruta gobernada, y un check de CI las marca para que el cambio nunca pase invisible en un diff grande.
Capa 2 — gate declarado. La unidad declara governance: true (etiqueta del PR o metadato del change) cuando va a tocar una ruta gobernada; CI falla si se tocan sin esa declaración —o mezcladas con trabajo no relacionado—. Es el espejo del gate architectural: true | false (F5.1): vuelve ejecutable la regla “cambiar lo compartido es su propia unidad”.

Honestidad de límites: la guarda detecta que una ruta gobernada cambió, no si el cambio es correcto —el dueño sigue juzgando—; es un backstop del proceso humano, no su reemplazo.

Setup de equipo (antes de la Fase 5)

Antes de que el equipo trabaje en paralelo se hace, una vez, el setup de equipo —análogo al aislamiento de Fase 0, pero para la colaboración—:

Equipos en el forge y CODEOWNERS desde templates/equipos/, ajustado a las rutas gobernadas reales del proyecto.
Protección de rama: main protegida, requerir revisión de Code Owners, y el check de la guarda de gobernanza como obligatorio.
Convención de ramas acordada y validada en CI (formato <tipo>/<ID>-<slug>; ver operations.md → Ramas).
Gestor de secretos compartido: credenciales fuera del repo y fuera del chat (eco de la honestidad de límites del aislamiento — un .env dentro de la carpeta montada sigue siendo visible).
Dueños de los roles singulares designados (quién ejerce arquitecto / dueño de estándares).
Cadencia de auditoría/grooming acordada (la del proyecto, no por persona).

Onboarding de un desarrollador

Sumar a alguien a un proyecto Argui ya en marcha no necesita proceso nuevo: los artefactos vivos son el onboarding. La checklist:

Leer los PRD, el CLAUDE.md y los estándares vivos — el estado y el criterio del proyecto.
Entender el grafo de dependencias del backlog (el mapa de progreso) y la convención de ramas.
Montar su worktree + el aislamiento de Fase 0.
Conocer la cadencia de auditoría/grooming y el CODEOWNERS (qué rutas requieren al dueño).

La metodología documenta los pasos; el proyecto aporta el contenido con sus artefactos. Un proyecto puede copiar esta checklist a su propio CONTRIBUTING.md, pero el hogar canónico es este.

Métricas de equipo

Señales que solo existen con equipo, capturadas de git/PR y leídas en la misma auditoría — detalle en metrics.md: WIP (unidades abiertas en paralelo), espera de revisión (PR abierto → merge) y conflictos / disparos de la guarda de gobernanza. Responden la versión de equipo de la pregunta madre: ¿la coordinación cuesta más de lo que el paralelismo ahorra? Como todas las métricas de Argui, miden el sistema, nunca rankean personas.

Auditorías y grooming

Son del proyecto, no del responsable: se corren una vez por cadencia sobre el estado ya integrado (post-merge), no por persona (ver operations.md).