theus-cli-linux-x64 1.2.2 → 1.4.0

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

@@ -1,131 +0,0 @@
----
-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

@@ -1,430 +0,0 @@
----
-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 |