¿Qué hace Project Flow Ops?
Esta habilidad convierte issues desconectados de GitHub, PRs y tareas de Linear en un solo flujo de ejecución.
Úsala cuando el problema sea la coordinación, no la codificación.
Cuándo usarlo
- Clasificar backlogs de PRs o issues abiertos
- Decidir qué pertenece a Linear vs qué debe permanecer solo en GitHub
- Vincular trabajo activo de GitHub a líneas de ejecución internas
- Clasificar PRs en merge, port/rebuild, close o park
- Auditar si los comentarios de revisión, fallos de CI o issues obsoletos están bloqueando la ejecución
Modelo operativo
- GitHub es la verdad pública y comunitaria
- Linear es la verdad interna de ejecución para trabajo activo y programado
- No todos los issues de GitHub necesitan un issue en Linear
- Crear o actualizar Linear solo cuando el trabajo sea:
- activo
- delegado
- programado
- interfuncional
- lo suficientemente importante como para rastrearlo internamente
Flujo principal
1. Leer primero la superficie pública
Recopila:
- Estado del issue o PR de GitHub
- autor y estado de la rama
- comentarios de revisión
- estado de CI
- issues vinculados
2. Clasificar el trabajo
Cada elemento debe terminar en uno de estos estados:
| Estado | Significado |
|---|---|
| Merge (fusionar) | autocontenido, cumple con la política, listo |
| Port/Rebuild (portar/reconstruir) | idea útil, pero debe ser re-implementada manualmente dentro de ECC |
| Close (cerrar) | dirección incorrecta, obsoleto, inseguro o duplicado |
| Park (aparcar) | potencialmente útil, pero no programado ahora |
3. Decidir si Linear está justificado
Crear o actualizar Linear solo si:
- la ejecución está planeada activamente
- están involucrados múltiples repos o flujos de trabajo
- el trabajo necesita propiedad o secuenciación interna
- el issue es parte de un programa o línea más grande
No reflejar todo mecánicamente.
4. Mantener los dos sistemas consistentes
Cuando el trabajo está activo:
- El issue/PR de GitHub debe decir lo que está sucediendo públicamente
- Linear debe rastrear el propietario, la prioridad y la línea de ejecución internamente
Cuando el trabajo se envía o se rechaza:
- publicar la resolución pública de vuelta a GitHub
- marcar la tarea de Linear en consecuencia
Reglas de revisión
- Nunca fusionar solo por el título, resumen o confianza; usar el diff completo
- Las características de fuentes externas deben reconstruirse dentro de ECC cuando sean valiosas pero no autocontenidas
- CI rojo significa clasificar y corregir o bloquear; no finjas que está listo para fusionar
- Si el verdadero bloqueador es la dirección del producto, dilo en lugar de esconderte detrás de herramientas
Formato de salida
Devuelve:
ESTADO PÚBLICO
- estado del issue / PR
- estado de CI / revisión
CLASIFICACIÓN
- merge / port-rebuild / close / park
- justificación de un párrafo
ACCIÓN EN LINEAR
- crear / actualizar / no se necesita item en Linear
- proyecto / línea si aplica
PRÓXIMA ACCIÓN DEL OPERADOR
- siguiente movimiento exacto
Buenos casos de uso
- "Audita el backlog de PRs abiertos y dime qué fusionar vs reconstruir"
- "Mapea los issues de GitHub en nuestras líneas de programa ECC 1.x y ECC 2.0"
- "Verifica si esto necesita un issue en Linear o debe permanecer solo en GitHub"