theus-cli-linux-arm64 0.2.84

package/vendor/theus-arsenal/skills/metodologia-benchmarks/SKILL.md

@@ -0,0 +1,131 @@
+---
+name: metodologia-benchmarks
+description: Puntúa un set de competidores ya escalonado en nueve dimensiones ponderadas con rúbricas explícitas de 1 a 5 y un plano de tensión estratégica. Usa esta skill después de analisis-plataformas-competencia y antes de estructura-informes-competencia.
+---
+
+# Metodología de benchmarks
+
+Usa esta skill para convertir un set acotado de competidores en **puntuaciones comparables y defendibles**. Cada competidor se evalúa en las mismas nueve dimensiones, con rúbricas explícitas de 1 a 5, y se captura en una ficha de perfil uniforme. La consistencia es el punto: las puntuaciones solo sirven si la misma evidencia obtendría el mismo número para cualquier competidor.
+
+## Cuándo activarla
+
+- Hay un set de competidores acotado y escalonado (de `analisis-plataformas-competencia`) listo para puntuar.
+- Se necesitan puntuaciones comparables y ancladas en evidencia — no rankings por intuición.
+- La tensión estratégica del cliente (los ejes pareados que definen su espacio blanco objetivo) ya está establecida.
+- Se preparan fichas de perfil para ensamblarlas en `estructura-informes-competencia`.
+
+## Brief de posicionamiento del cliente (establécelo primero)
+
+Antes de puntuar, establece el brief de posicionamiento del cliente. Aporta:
+
+- **Tensión estratégica** — los dos ejes (p. ej., memorabilidad × contratabilidad) cuya intersección marca el espacio blanco objetivo del cliente. La dimensión 9 es siempre la tensión nombrada por el cliente; reporta ambos polos por separado, nunca promediados.
+- **Diferenciador** — qué constituye el foso competitivo del cliente. Informa qué dimensiones importan más para su argumento de posicionamiento.
+- **Balance de marca** — la mezcla prevista de énfasis estratégicos distintos. Las recomendaciones estratégicas no deben romper ese balance sin señalarlo.
+
+## Por qué estas dimensiones
+
+El cliente compite sobre una **tensión específica sostenida entre dos polos**, no sobre amplitud de servicios. Las dimensiones se ponderan para reflejar ese foso. Dos dimensiones — los polos de la tensión — se puntúan **por separado y nunca se promedian**, porque la pregunta estratégica del cliente es precisamente si un rival logra ambos a la vez.
+
+## Las nueve dimensiones (con pesos)
+
+Los pesos guían el énfasis de la síntesis, no una puntuación única combinada (evita un compuesto falso — ver Controles de sesgo). Suma = 100 %.
+
+1. **Claridad y distintividad del posicionamiento** (18 %) — ¿La posición del estudio es nítida, apropiable e instantáneamente legible? ¿O genérica?
+2. **Voz de marca / distintividad verbal** (15 %) — ¿La redacción tiene un registro propio, o es jerga de agencia intercambiable?
+3. **Identidad visual y factura del sitio** (15 %) — Calidad y propiedad del sistema visual; el sitio como prueba de oficio.
+4. **Oferta de servicios y empaquetado** (12 %) — Productizado y legible (sprints/auditorías con nombre) vs. vago. Madurez del empaquetado.
+5. **Evidencia y credibilidad** (12 %) — Clientes nombrados, resultados cuantificados, profundidad de los casos de estudio. Prueba más allá de la afirmación.
+6. **Preparación enterprise / madurez comercial** (10 %) — Señales de que pueden ganar y sostener trabajo SaaS/fintech/B2B/enterprise (proceso, logos, escala, contratos).
+7. **Liderazgo de opinión / presencia de contenido** (8 %) — Punto de vista propio: escritura, charlas, newsletters, frameworks. Profundidad sobre volumen.
+8. **Transparencia de precios y modelo de contratación** (5 %) — ¿El precio/modelo es legible? ¿Productizado, a medida u opaco?
+9. **[Tensión estratégica del cliente]** (5 % como bandera; **puntúa AMBOS polos, repórtalos por separado**) — Lee el nombre de la tensión y las descripciones de los ejes del brief de posicionamiento. Grafica ambos; la brecha es el hallazgo. El cuadrante objetivo del cliente es el hallazgo más importante: ¿quién más está ya ahí?
+
+## Rúbrica de puntuación (1–5, aplica a las dimensiones 1–8)
+
+Ancla cada puntuación a evidencia observable. Los descriptores siguientes son genéricos; adapta los detalles por dimensión pero mantén constante el significado de cada nivel.
+
+- **1 — Ausente / genérico.** Sin posición ni oficio discernibles; indistinguible de una plantilla. Un lastre activo.
+- **2 — Por debajo del estándar.** Hay intención pero es inconsistente, derivativa o poco convincente. No sobreviviría una comparación lado a lado.
+- **3 — Competente / lo esperable.** Sólido, profesional, anodino. Cumple la expectativa, no lo posee nadie.
+- **4 — Fuerte / distintivo.** Claramente por encima de sus pares; una fortaleza real que un comprador notaría y citaría.
+- **5 — Define la categoría.** El mejor de su clase, apropiable, difícil de imitar. Pone el listón al que otros reaccionan.
+
+### Ejes de la tensión (dimensión 9) — puntúa cada uno de 1 a 5
+
+Lee las etiquetas de los ejes y sus anclas 1/3/5 del brief de posicionamiento del cliente. Anclas de ejemplo para una tensión memorabilidad × credibilidad:
+
+- **Memorabilidad** — 1: se olvida al instante · 3: reconocible en contexto · 5: inolvidable, comentado, distintivamente propio.
+- **Credibilidad** — 1: se percibe riesgoso/amateur · 3: seguro, competente, sin emoción · 5: confianza enterprise, la opción segura obvia.
+
+Grafica a los competidores en la matriz 2×2 de la tensión. El cuadrante objetivo del cliente está nombrado en el brief. Quién más ocupa ese cuadrante es el hallazgo más importante del benchmark.
+
+## Cómo recolectar los datos
+
+Por cada competidor, trabaja las dimensiones en este orden (la señal más barata primero):
+
+1. **El sitio del propio competidor** — posicionamiento, voz, empaquetado de la oferta, postura de precios, clientes nombrados, manifiesto/punto de vista. Captura la home + un caso de estudio.
+2. **Casos de estudio / trabajos** — profundidad de la evidencia, resultados cuantificados, nombres de clientes. Distingue lo *afirmado* ("entregamos X") de lo *probado* (métricas, con nombre, verificable).
+3. **Directorios de reseñas** — corrobora clientes, tamaño de proyectos, modelo de contratación → credibilidad y preparación enterprise (p. ej., Clutch.co o el equivalente del nicho).
+4. **LinkedIn** — tamaño/modelo del equipo, narrativa de los fundadores, cadencia de contenido → liderazgo de opinión, modelo.
+5. **Plataformas de portafolio / oficio** — registro del oficio (usa el escaparate nativo del nicho: tableros de diseño, showreels, muestras publicadas, etc.).
+6. **Canales de contenido** — newsletter/charlas/escritura → profundidad del liderazgo de opinión.
+
+**Qué registrar por dimensión:** la puntuación, una justificación de una línea y el enlace/captura de la fuente que la sustenta. Sin evidencia no hay puntuación.
+
+## Controles de sesgo
+
+- **Sin puntuación compuesta única.** Reporta las puntuaciones por dimensión y el plano de tensión por separado. Un promedio ponderado esconde la asimetría que importa.
+- **Afirmado vs. probado.** Rebaja las puntuaciones de credibilidad/evidencia para afirmaciones autorreportadas sin corroboración. La redacción del sitio es marketing, no un hecho.
+- **Sesgo de afinidad estética.** Los revisores pueden sobrepuntuar estudios cuya estética comparten y subestimar la fortaleza comercial de los rivales. Puntúa oficio y credibilidad de forma independiente; un sitio "aburrido" puede estar ganando clientes más grandes.
+- **Sesgo de novedad / vistosidad.** El trabajo premiado y vistoso deslumbra pero puede carecer de profundidad comercial — verifica con directorios/clientes antes de puntuar credibilidad.
+- **Supervivencia.** Los estudios visibles y bien comercializados no son todo el mercado; anota a los operadores fuertes-pero-discretos encontrados vía directorios/reseñas.
+- **Calibra sobre el set, no en aislamiento.** Antes de cerrar, relee las puntuaciones lado a lado — un "4" debe significar lo mismo para todos los competidores. Ajusta los atípicos.
+
+## Ficha de perfil de competidor (formato de salida)
+
+Produce una ficha por competidor perfilado — la unidad atómica de la que se ensambla el informe:
+
+```
+## <Nombre del competidor>
+- **Perfil / Tier:** <postura de posicionamiento · especialización · banda de tamaño> / <Directo | Adyacente | Aspiracional>
+- **En una línea:** <cómo se posicionan, en sus propias palabras>
+- **Modelo / tamaño / geografía:** <solo|micro|boutique> · <región> · <modelo de precios/contratación>
+- **Clientes notables / evidencia:** <nombrados, con etiqueta probado/afirmado>
+
+### Puntuaciones por dimensión
+| Dimensión | Puntuación (1–5) | Justificación (1 línea) | Fuente |
+|---|---|---|---|
+| Claridad y distintividad del posicionamiento | | | |
+| Voz de marca / distintividad verbal | | | |
+| Identidad visual y factura del sitio | | | |
+| Oferta de servicios y empaquetado | | | |
+| Evidencia y credibilidad | | | |
+| Preparación enterprise / madurez comercial | | | |
+| Liderazgo de opinión / presencia de contenido | | | |
+| Transparencia de precios y modelo de contratación | | | |
+
+### Plano de tensión
+- **[Eje 1 del brief de posicionamiento]:** <1–5> — <por qué>
+- **[Eje 2 del brief de posicionamiento]:** <1–5> — <por qué>
+- **Cuadrante:** <alto/alto | alto-1/bajo-2 | bajo-1/alto-2 | bajo/bajo>
+
+### Lectura para [cliente]
+- **Fortaleza de la que aprender:** <…>
+- **Debilidad a explotar / espacio blanco que expone:** <…>
+- **Amenaza para [cliente]:** <…>
+```
+
+Entrega las fichas completas más el plano de tensión a `estructura-informes-competencia`.
+
+## Antipatrones
+
+- **Promediar los ejes de la tensión.** Los dos polos de la tensión estratégica del cliente deben puntuarse y reportarse por separado. Promediarlos destruye el hallazgo — la brecha entre polos es el resultado.
+- **Puntuar sin evidencia.** Cada puntuación requiere una justificación de una línea y un enlace fuente. Una puntuación sin evidencia es una opinión, no un benchmark.
+- **Crear una puntuación compuesta única.** Reporta las dimensiones individualmente. Un promedio ponderado oculta las fortalezas asimétricas que importan para el posicionamiento.
+- **Aplicar las anclas genéricas de la rúbrica sin adaptarlas.** Las anclas 1–5 deben calibrarse a la dimensión específica y al set de competidores. Las descripciones genéricas son punto de partida, no estándar fijo.
+- **Ejecutar antes de acotar el set de competidores.** Usa primero `analisis-plataformas-competencia` para producir un set escalonado y depurado. Puntuar una lista sin acotar desperdicia esfuerzo en competidores irrelevantes.
+
+## Skills relacionadas
+
+- `analisis-plataformas-competencia` — el prerrequisito; produce el set escalonado de competidores que esta skill puntúa.
+- `estructura-informes-competencia` — el siguiente paso; ensambla las fichas puntuadas en un informe entregable al cliente.

package/vendor/theus-arsenal/skills/migraciones-bd/SKILL.md

@@ -0,0 +1,430 @@
+---
+name: migraciones-bd
+description: Buenas prácticas de migraciones de base de datos para cambios de esquema, migraciones de datos, rollbacks y despliegues sin downtime en PostgreSQL, MySQL y los ORMs habituales (Prisma, Drizzle, Kysely, Django, TypeORM, golang-migrate).
+---
+
+# Patrones de migración de bases de datos
+
+Cambios de esquema seguros y reversibles para sistemas en producción.
+
+## Cuándo activarla
+
+- Al crear o alterar tablas de base de datos
+- Al agregar o eliminar columnas o índices
+- Al ejecutar migraciones de datos (backfill, transformación)
+- Al planificar cambios de esquema sin downtime
+- Al configurar la tooling de migraciones para un proyecto nuevo
+
+## Principios fundamentales
+
+1. **Todo cambio es una migración** — nunca alteres bases de datos de producción a mano
+2. **En producción las migraciones solo van hacia adelante** — los rollbacks se hacen con nuevas migraciones hacia adelante
+3. **Las migraciones de esquema y de datos van separadas** — nunca mezcles DDL y DML en una misma migración
+4. **Prueba las migraciones contra datos de tamaño de producción** — una migración que funciona con 100 filas puede bloquear con 10 M
+5. **Las migraciones son inmutables una vez desplegadas** — nunca edites una migración que ya corrió en producción
+
+## Checklist de seguridad de migraciones
+
+Antes de aplicar cualquier migración:
+
+- [ ] La migración tiene UP y DOWN (o está marcada explícitamente como irreversible)
+- [ ] Sin locks de tabla completa en tablas grandes (usa operaciones concurrentes)
+- [ ] Las columnas nuevas tienen default o son nullable (nunca agregues NOT NULL sin default)
+- [ ] Los índices se crean de forma concurrente (no inline con CREATE TABLE para tablas existentes)
+- [ ] El backfill de datos es una migración separada del cambio de esquema
+- [ ] Probada contra una copia de los datos de producción
+- [ ] Plan de rollback documentado
+
+## Patrones de PostgreSQL
+
+### Agregar una columna de forma segura
+
+```sql
+-- BIEN: columna nullable, sin lock
+ALTER TABLE users ADD COLUMN avatar_url TEXT;
+
+-- BIEN: columna con default (en Postgres 11+ es instantáneo, sin reescritura)
+ALTER TABLE users ADD COLUMN is_active BOOLEAN NOT NULL DEFAULT true;
+
+-- MAL: NOT NULL sin default en una tabla existente (exige reescritura completa)
+ALTER TABLE users ADD COLUMN role TEXT NOT NULL;
+-- Esto bloquea la tabla y reescribe todas las filas
+```
+
+### Agregar un índice sin downtime
+
+```sql
+-- MAL: bloquea las escrituras en tablas grandes
+CREATE INDEX idx_users_email ON users (email);
+
+-- BIEN: no bloquea, permite escrituras concurrentes
+CREATE INDEX CONCURRENTLY idx_users_email ON users (email);
+
+-- Nota: CONCURRENTLY no puede ejecutarse dentro de un bloque de transacción
+-- La mayoría de las herramientas de migración necesitan manejo especial para esto
+```
+
+### Renombrar una columna (sin downtime)
+
+Nunca renombres directamente en producción. Usa el patrón expandir-contraer:
+
+```sql
+-- Paso 1: agregar la columna nueva (migración 001)
+ALTER TABLE users ADD COLUMN display_name TEXT;
+
+-- Paso 2: backfill de datos (migración 002, migración de datos)
+UPDATE users SET display_name = username WHERE display_name IS NULL;
+
+-- Paso 3: actualizar el código de la aplicación para leer/escribir ambas columnas
+-- Desplegar los cambios de la aplicación
+
+-- Paso 4: dejar de escribir en la columna vieja y eliminarla (migración 003)
+ALTER TABLE users DROP COLUMN username;
+```
+
+### Eliminar una columna de forma segura
+
+```sql
+-- Paso 1: eliminar todas las referencias a la columna en la aplicación
+-- Paso 2: desplegar la aplicación sin la referencia a la columna
+-- Paso 3: eliminar la columna en la siguiente migración
+ALTER TABLE orders DROP COLUMN legacy_status;
+
+-- Para Django: usa SeparateDatabaseAndState para quitarla del modelo
+-- sin generar DROP COLUMN (y elimínala en la siguiente migración)
+```
+
+### Migraciones de datos grandes
+
+```sql
+-- MAL: actualiza todas las filas en una sola transacción (bloquea la tabla)
+UPDATE users SET normalized_email = LOWER(email);
+
+-- BIEN: actualización por lotes con progreso
+DO $$
+DECLARE
+  batch_size INT := 10000;
+  rows_updated INT;
+BEGIN
+  LOOP
+    UPDATE users
+    SET normalized_email = LOWER(email)
+    WHERE id IN (
+      SELECT id FROM users
+      WHERE normalized_email IS NULL
+      LIMIT batch_size
+      FOR UPDATE SKIP LOCKED
+    );
+    GET DIAGNOSTICS rows_updated = ROW_COUNT;
+    RAISE NOTICE 'Actualizadas % filas', rows_updated;
+    EXIT WHEN rows_updated = 0;
+    COMMIT;
+  END LOOP;
+END $$;
+```
+
+## Prisma (TypeScript/Node.js)
+
+### Flujo de trabajo
+
+```bash
+# Crear una migración a partir de cambios en el esquema
+npx prisma migrate dev --name add_user_avatar
+
+# Aplicar las migraciones pendientes en producción
+npx prisma migrate deploy
+
+# Reiniciar la base de datos (solo dev)
+npx prisma migrate reset
+
+# Generar el cliente tras cambios en el esquema
+npx prisma generate
+```
+
+### Ejemplo de esquema
+
+```prisma
+model User {
+  id        String   @id @default(cuid())
+  email     String   @unique
+  name      String?
+  avatarUrl String?  @map("avatar_url")
+  createdAt DateTime @default(now()) @map("created_at")
+  updatedAt DateTime @updatedAt @map("updated_at")
+  orders    Order[]
+
+  @@map("users")
+  @@index([email])
+}
+```
+
+### Migración con SQL personalizado
+
+Para operaciones que Prisma no puede expresar (índices concurrentes, backfills de datos):
+
+```bash
+# Crear una migración vacía y luego editar el SQL a mano
+npx prisma migrate dev --create-only --name add_email_index
+```
+
+```sql
+-- migrations/20240115_add_email_index/migration.sql
+-- Prisma no puede generar CONCURRENTLY, así que lo escribimos a mano
+CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_users_email ON users (email);
+```
+
+## Drizzle (TypeScript/Node.js)
+
+### Flujo de trabajo
+
+```bash
+# Generar una migración a partir de cambios en el esquema
+npx drizzle-kit generate
+
+# Aplicar migraciones
+npx drizzle-kit migrate
+
+# Empujar el esquema directamente (solo dev, sin archivo de migración)
+npx drizzle-kit push
+```
+
+### Ejemplo de esquema
+
+```typescript
+import { pgTable, text, timestamp, uuid, boolean } from "drizzle-orm/pg-core";
+
+export const users = pgTable("users", {
+  id: uuid("id").primaryKey().defaultRandom(),
+  email: text("email").notNull().unique(),
+  name: text("name"),
+  isActive: boolean("is_active").notNull().default(true),
+  createdAt: timestamp("created_at").notNull().defaultNow(),
+  updatedAt: timestamp("updated_at").notNull().defaultNow(),
+});
+```
+
+## Kysely (TypeScript/Node.js)
+
+### Flujo de trabajo (kysely-ctl)
+
+```bash
+# Inicializar el archivo de configuración (kysely.config.ts)
+kysely init
+
+# Crear un archivo de migración nuevo
+kysely migrate make add_user_avatar
+
+# Aplicar todas las migraciones pendientes
+kysely migrate latest
+
+# Revertir la última migración
+kysely migrate down
+
+# Mostrar el estado de las migraciones
+kysely migrate list
+```
+
+### Archivo de migración
+
+```typescript
+// migrations/2024_01_15_001_create_user_profile.ts
+import { type Kysely, sql } from 'kysely'
+
+// IMPORTANTE: usa siempre Kysely<any>, no tu interfaz de BD tipada.
+// Las migraciones quedan congeladas en el tiempo y no deben depender
+// de los tipos del esquema actual.
+export async function up(db: Kysely<any>): Promise<void> {
+  await db.schema
+    .createTable('user_profile')
+    .addColumn('id', 'serial', (col) => col.primaryKey())
+    .addColumn('email', 'varchar(255)', (col) => col.notNull().unique())
+    .addColumn('avatar_url', 'text')
+    .addColumn('created_at', 'timestamp', (col) =>
+      col.defaultTo(sql`now()`).notNull()
+    )
+    .execute()
+
+  await db.schema
+    .createIndex('idx_user_profile_avatar')
+    .on('user_profile')
+    .column('avatar_url')
+    .execute()
+}
+
+export async function down(db: Kysely<any>): Promise<void> {
+  await db.schema.dropTable('user_profile').execute()
+}
+```
+
+### Migrador programático
+
+```typescript
+import { Migrator, FileMigrationProvider } from 'kysely'
+import { promises as fs } from 'fs'
+import * as path from 'path'
+// Solo ESM — en CJS puedes usar __dirname directamente
+import { fileURLToPath } from 'url'
+const migrationFolder = path.join(
+  path.dirname(fileURLToPath(import.meta.url)),
+  './migrations',
+)
+
+// `db` es tu instancia de base de datos Kysely<any>
+const migrator = new Migrator({
+  db,
+  provider: new FileMigrationProvider({
+    fs,
+    path,
+    migrationFolder,
+  }),
+  // ADVERTENCIA: habilítalo solo en desarrollo. Desactiva la validación
+  // de orden por timestamp, lo que puede causar drift de esquema
+  // entre entornos.
+  // allowUnorderedMigrations: true,
+})
+
+const { error, results } = await migrator.migrateToLatest()
+
+results?.forEach((it) => {
+  if (it.status === 'Success') {
+    console.log(`la migración "${it.migrationName}" se ejecutó correctamente`)
+  } else if (it.status === 'Error') {
+    console.error(`falló la ejecución de la migración "${it.migrationName}"`)
+  }
+})
+
+if (error) {
+  console.error('la migración falló', error)
+  process.exit(1)
+}
+```
+
+## Django (Python)
+
+### Flujo de trabajo
+
+```bash
+# Generar una migración a partir de cambios en los modelos
+python manage.py makemigrations
+
+# Aplicar migraciones
+python manage.py migrate
+
+# Mostrar el estado de las migraciones
+python manage.py showmigrations
+
+# Generar una migración vacía para SQL personalizado
+python manage.py makemigrations --empty app_name -n description
+```
+
+### Migración de datos
+
+```python
+from django.db import migrations
+
+def backfill_display_names(apps, schema_editor):
+    User = apps.get_model("accounts", "User")
+    batch_size = 5000
+    users = User.objects.filter(display_name="")
+    while users.exists():
+        batch = list(users[:batch_size])
+        for user in batch:
+            user.display_name = user.username
+        User.objects.bulk_update(batch, ["display_name"], batch_size=batch_size)
+
+def reverse_backfill(apps, schema_editor):
+    pass  # Migración de datos, no necesita reversa
+
+class Migration(migrations.Migration):
+    dependencies = [("accounts", "0015_add_display_name")]
+
+    operations = [
+        migrations.RunPython(backfill_display_names, reverse_backfill),
+    ]
+```
+
+### SeparateDatabaseAndState
+
+Elimina una columna del modelo de Django sin borrarla de la base de datos de inmediato:
+
+```python
+class Migration(migrations.Migration):
+    operations = [
+        migrations.SeparateDatabaseAndState(
+            state_operations=[
+                migrations.RemoveField(model_name="user", name="legacy_field"),
+            ],
+            database_operations=[],  # No tocar la BD todavía
+        ),
+    ]
+```
+
+## golang-migrate (Go)
+
+### Flujo de trabajo
+
+```bash
+# Crear el par de migraciones
+migrate create -ext sql -dir migrations -seq add_user_avatar
+
+# Aplicar todas las migraciones pendientes
+migrate -path migrations -database "$DATABASE_URL" up
+
+# Revertir la última migración
+migrate -path migrations -database "$DATABASE_URL" down 1
+
+# Forzar versión (arreglar estado dirty)
+migrate -path migrations -database "$DATABASE_URL" force VERSION
+```
+
+### Archivos de migración
+
+```sql
+-- migrations/000003_add_user_avatar.up.sql
+ALTER TABLE users ADD COLUMN avatar_url TEXT;
+CREATE INDEX CONCURRENTLY idx_users_avatar ON users (avatar_url) WHERE avatar_url IS NOT NULL;
+
+-- migrations/000003_add_user_avatar.down.sql
+DROP INDEX IF EXISTS idx_users_avatar;
+ALTER TABLE users DROP COLUMN IF EXISTS avatar_url;
+```
+
+## Estrategia de migración sin downtime
+
+Para cambios críticos en producción, sigue el patrón expandir-contraer:
+
+```
+Fase 1: EXPANDIR
+  - Agregar la columna/tabla nueva (nullable o con default)
+  - Deploy: la app escribe en AMBAS, la vieja y la nueva
+  - Backfill de los datos existentes
+
+Fase 2: MIGRAR
+  - Deploy: la app lee de la NUEVA, escribe en AMBAS
+  - Verificar la consistencia de los datos
+
+Fase 3: CONTRAER
+  - Deploy: la app solo usa la NUEVA
+  - Eliminar la columna/tabla vieja en una migración separada
+```
+
+### Ejemplo de cronograma
+
+```
+Día 1: la migración agrega la columna new_status (nullable)
+Día 1: deploy de la app v2 — escribe en status y new_status
+Día 2: ejecutar la migración de backfill para las filas existentes
+Día 3: deploy de la app v3 — lee solo de new_status
+Día 7: la migración elimina la columna status vieja
+```
+
+## Antipatrones
+
+| Antipatrón | Por qué falla | Mejor enfoque |
+|-------------|--------------|-----------------|
+| SQL manual en producción | Sin trazabilidad, irrepetible | Usa siempre archivos de migración |
+| Editar migraciones desplegadas | Causa drift entre entornos | Crea una migración nueva en su lugar |
+| NOT NULL sin default | Bloquea la tabla, reescribe todas las filas | Agrega nullable, haz backfill y luego agrega la restricción |
+| Índice inline en tabla grande | Bloquea escrituras durante la construcción | CREATE INDEX CONCURRENTLY |
+| Esquema + datos en una migración | Difícil de revertir, transacciones largas | Migraciones separadas |
+| Eliminar la columna antes de quitar el código | La aplicación falla por columna inexistente | Quita el código primero, elimina la columna en el siguiente deploy |