0
Conflictos de merge esperados
38
Archivos con owner único
Ownership de Archivos por Agente
- src/app/(auth)/login/page.tsx
- src/app/(auth)/register/page.tsx
- src/app/(auth)/layout.tsx
- src/components/auth/LoginForm.tsx
- src/components/auth/RegisterForm.tsx
- src/components/auth/PasswordStrength.tsx
- src/components/profile/ProfileCard.tsx
- src/components/profile/AvatarUploader.tsx
- src/components/rbac/RoleGuard.tsx
- src/hooks/useAuth.ts
- src/hooks/usePermissions.ts
- src/store/authStore.ts
- src/middleware.ts (Next.js edge)
- src/api/auth/routes.ts
- src/api/auth/controller.ts
- src/api/auth/validators.ts
- src/api/profile/routes.ts
- src/api/profile/controller.ts
- src/services/AuthService.ts
- src/services/TokenService.ts
- src/services/ProfileService.ts
- src/db/schema/users.ts
- src/db/schema/sessions.ts
- src/db/migrations/0001_auth.ts
- src/middlewares/authMiddleware.ts
- src/middlewares/rbacMiddleware.ts
- tests/unit/auth/AuthService.test.ts
- tests/unit/auth/TokenService.test.ts
- tests/unit/components/LoginForm.test.tsx
- tests/unit/components/RoleGuard.test.tsx
- tests/integration/auth/login.test.ts
- tests/integration/auth/register.test.ts
- tests/e2e/auth.spec.ts
- tests/e2e/profile.spec.ts
- tests/mocks/handlers.ts
- tests/fixtures/users.ts
- src/types/auth-contract.ts READ-ONLY para otros
- src/types/user-contract.ts READ-ONLY para otros
- src/types/rbac-contract.ts READ-ONLY para otros
- src/index.ts (barrel — solo TL)
- src/api/index.ts
- package.json
- drizzle.config.ts
- .env.example
- .github/workflows/ci.yml
Contratos de Interfaz TypeScript (READ-ONLY)
src/types/auth-contract.ts
Owned by Team Lead · Ambos agentes importan, ninguno modifica
export interface AuthCredentials {
email: string;
password: string;
}
export interface AuthResponse {
token: string;
refreshToken: string;
user: UserProfile;
expiresAt: number;
}
export interface AuthService {
login(creds: AuthCredentials): Promise<AuthResponse>;
register(data: RegisterData): Promise<AuthResponse>;
logout(token: string): Promise<void>;
refresh(refreshToken: string): Promise<AuthResponse>;
}
src/types/rbac-contract.ts
Define roles y permisos que usan FE (RoleGuard) y BE (rbacMiddleware)
export type Role =
| 'admin'
| 'manager'
| 'viewer';
export type Permission =
| 'campaigns:read' | 'campaigns:write'
| 'users:read' | 'users:write'
| 'reports:read' | 'billing:manage';
export const ROLE_PERMISSIONS: Record<Role, Permission[]> = {
admin: ['campaigns:read', 'campaigns:write',
'users:read', 'users:write',
'reports:read', 'billing:manage'],
manager: ['campaigns:read', 'campaigns:write',
'users:read', 'reports:read'],
viewer: ['campaigns:read', 'reports:read'],
};
export interface JWTPayload {
userId: string;
role: Role;
iat: number; exp: number;
}
Patrón de Integración Elegido
Vertical Slice
Horizontal Layer
✓ Híbrido
Vertical para Login/Register (slices independientes), horizontal para infraestructura compartida JWT/RBAC.
1
Agente 1 (FE): Login + Register completos
Formularios, validación, store Zustand, middleware Next.js — todo el slice de UI sin dependencia del BE real (usa MSW mock inicialmente)
2
Agente 2 (BE): JWT + RBAC infraestructura
AuthService, TokenService, schema Drizzle, migraciones y middleware Express — capa horizontal de infraestructura compartida
3
Agente 3 (QA): Tests contra contratos
Escribe tests usando las interfaces definidas en auth-contract.ts. No espera implementación real — mockea con fixtures y MSW handlers
Plan de Sprints
Sprint 1
Días 1–2
TL: Contratos TS + Branch setup
FE: LoginForm + RegisterForm (con MSW)
BE: DB schema + JWT service
QA: Fixtures + MSW handlers
Sprint 2
Días 3–4
FE: RoleGuard + ProfileCard + hooks
BE: RBAC middleware + API routes
QA: Unit tests FE+BE · Integration auth
TL: Code review + contract validation
Sprint 3
Días 5–6
Integración real FE ↔ BE
QA: E2E Playwright
FE: Fix integration issues
TL: Merge PR + CI verde
Regla cardinal: Un owner por fichero. Los barrel files (index.ts, api/index.ts) son exclusivos del Team Lead.
Estrategia de Branching
main
└── feature/auth-system
├── feature/auth-system-fe
├── feature/auth-system-be
├── feature/auth-system-qa
└── feature/auth-system-lead
Merge order: lead → be → fe → qa → feature/auth-system → main
Reglas Anti-Conflicto
!
Archivos compartidos → designar un owner
Si más de un agente necesita editar el mismo fichero, el no-owner envía un mensaje al owner con el cambio exacto requerido.
!
Barrel files: exclusivos del Team Lead
index.ts, api/index.ts, y cualquier re-exportación global — solo el TL los toca para evitar conflictos automáticos.
!
Cambio en contratos → broadcast obligatorio
Antes de modificar auth-contract.ts, rbac-contract.ts o user-contract.ts, el TL notifica a TODOS los agentes y espera confirmación.
Troubleshooting — Escenarios Comunes en CultivaFlow
❌ FE y BE bloquean esperando código del otro
El TL extrae la interfaz compartida en auth-contract.ts. FE mockea con MSW + handlers.ts. BE implementa contra la misma interfaz. Se integran en Sprint 3.
❌ QA rompe tests porque BE cambió el signature de login()
Regla: ningún cambio en AuthService.ts sin actualizar auth-contract.ts primero. El TL debe aprobar el cambio de contrato y notificar broadcast.
❌ Merge conflict en src/middleware.ts
FE es owner de src/middleware.ts (Next.js edge). BE no toca este archivo — crea src/middlewares/authMiddleware.ts separado para Express. Namespaces distintos.
❌ La descomposición inicial resultó incorrecta a mitad del Sprint 2
Stop del trabajo nuevo. TL redistribuye ficheros, comunica broadcast. El código parcialmente escrito se acepta como sunk cost — continuar con la partición incorrecta es peor.
CultivaFlow — Feature: Auth System v1.0
· Skill: desarrollo-paralelo-multi-agente
· CULTIVA IA / IA-Ingeniería-MLOps
4 agentes · 0 merge conflicts esperados · 6 días