[DATA] F-00.2 — Migraciones y Modelos Eloquent

Épica: EPIC-00 — Setup e Infraestructura Base

🏷️ Categoría

Categoría: DataImpacta en: Equipo Backend (Laravel + Base de Datos)

📦 Dependencias

Backlogs que deben estar completados antes de implementar esta feature.

Backlog	Motivo
F-00.1	Base Laravel + Livewire instalada, artisan y Composer disponibles

Prioridad: Must

---

Descripción: Como desarrollador Quiero que todas las tablas del panel estén creadas con migraciones Laravel y que los modelos Eloquent tengan sus relaciones definidas Para que el equipo pueda trabajar con el ORM de forma segura y consistente desde el principio

Criterios de Aceptación (Checklist):

• [ ] Escenario 1 (Migración users): Tabla users con campos: id (bigserial PK), name (varchar), email (varchar unique), external_id (varchar nullable), timestamps.
• [ ] Escenario 2 (Tabla logs — solo lectura): La tabla logs existe en la BD desde n8n. La migración del panel la documenta como referencia pero no la crea si ya existe (Schema::hasTable('logs')). Campos esperados: id (bigserial PK), error_code_id (bigint FK nullable → error_codes.id), application_id (bigint FK → applications.id), severity (enum: critical/high/medium/low/other), message (text), file (varchar nullable), line (integer nullable), metadata (jsonb nullable), matched_archived_log_id (bigint nullable), resolved (boolean default false), created_at (timestamptz). Sin deleted_at — los logs se eliminan físicamente al archivar o por el script de purga.
• [ ] Escenario 3 (Migración archived_logs): Tabla archived_logs con campos: id (bigserial PK), application_id (bigint FK → applications.id), archived_by_id (bigint FK → users.id), error_code_id (bigint FK nullable → error_codes.id), severity (enum), message (text), metadata (jsonb nullable), description (text nullable), url_tutorial (varchar 500 nullable), original_created_at (timestamptz), archived_at (timestamptz), updated_at (timestamptz). Sin original_log_id — el histórico es autónomo y no mantiene referencia al log eliminado.
• [ ] Escenario 4 (Migración comments): Tabla comments con campos: id, archived_log_id (bigint FK → archived_logs.id CASCADE DELETE), user_id (bigint FK → users.id), content (text), timestamps.
• [ ] Escenario 5 (Migración error_codes): Tabla error_codes con campos: id (bigserial PK), code (varchar), application_id (bigint FK → applications.id), name (varchar), description (text nullable), severity (enum nullable), timestamps. Unique constraint: (code, application_id).
• [ ] Escenario 6 (Migración error_code_comments): Tabla error_code_comments con campos: id, error_code_id (bigint FK → error_codes.id CASCADE DELETE), user_id (bigint FK → users.id), content (text), timestamps.
• [ ] Escenario 7 (Migración applications): Tabla applications con campos: id (bigserial PK), name (varchar unique), description (text nullable), created_at (timestamptz).
• [ ] Escenario 8 (Modelos Eloquent): Modelos User, Log, ArchivedLog, Comment, ErrorCode, ErrorCodeComment, Application con relaciones hasMany/belongsTo correctas. Log sin soft delete — usar eliminación física.
• [ ] Requisito Técnico: Todas las migraciones en database/migrations/. Índices: logs(error_code_id), logs(application_id, created_at), logs(severity, resolved), logs(matched_archived_log_id), archived_logs(application_id, archived_at), error_codes(code, application_id) UNIQUE. Tipo severity declarado como CREATE TYPE severity AS ENUM (...) en la migración de logs (o como $table->enum()). php artisan migrate:fresh --seed debe correr sin errores.

---

MoSCoW: MUSTSprint: Sprint 0

Notas:

• La tabla logs puede ya existir en el servidor de producción (gestionada por n8n). Usar Schema::hasTable('logs') para evitar recrearla; documentar su estructura esperada en 0_descripcion_proyecto.md.
• archived_logs no mantiene original_log_id: el histórico es autónomo. El log original se elimina físicamente al archivar (o por purga programada).
• Los índices compuestos son críticos para el rendimiento dado el volumen de logs esperado (NFR-ESC-02).