LAP-256 Fase 1 — Contraste contra instrucciones existentes

Sección 1 — Startup (65 campos)

Campo	Estado	Fuente	Nota
`registeredById`	Nuevo (schema)	N/A — solo schema BD (`Startup.registered_by_id`, FK Profile)	Ownership server-side. No es un campo que el usuario vea; necesario para RLS.
`status`	Nuevo (schema)	N/A — enum `EntityStatus` en Prisma	DRAFT/PENDING/APPROVED/REJECTED. Usado por admins. No lo decide Frank en instrucciones de formulario.
`companyName`	Alineado	Panel 1 identidad legal (FS + FD) — referencia estándar en biblia-hub-central y en instrucciones	Sin discrepancia. Label "Nombre comercial" consistente.
`country`	Alineado	Panel 1 — "País de origen" referenciado en `instrucciones-activas.md` (contexto de taxonomías) y `schema.prisma` NOT NULL	Canónico.
`city`	Divergente	Panel 1 — schema NOT NULL; `qa-lap218.md` cita "city=Lima" como dato real en BD	Discrepancia: en instrucciones Frank asume que el campo se llena (ver Mis Registros QA-LAP218). Mi FieldDef dice `scoreWeight: 0` porque hoy el FS inserta `""`. Decidir: ¿se pide o se deja opcional?
`originCountry`	Legacy	N/A — duplicado de `country`	Marcado para consolidar en Fase 2. Frank nunca lo pidió explícito.
`originRegion`	Legacy	N/A — columna en Prisma sin consumidor	Derivable de `country`. No se pide en formulario.
`fiscalDomicile`	Divergente	Panel 1 — schema Prisma lo tiene como `string`. `ICG.fiscalCountries` (array) sí se pide en instrucciones-activas	Discrepancia de tipo: en ICG es `array<string>` (Panel 4), en Startup es `string`. Mi nota en el FieldDef ya advierte que el FD persiste además `fiscal_domicile_countries` que no está en schema — deuda técnica.
`companyType`	Alineado	Enum `CompanyType` Prisma + instrucción 2026-04-17: "empresas de base tecnológica — Startups, Scaleups y PyMEs"	STARTUP/PYME/SCALEUP.
`isTechBased`	Alineado	Instrucción 2026-04-18 22:06: "taxonomía tech vs tradicional"	Controla visibilidad de TRL (solo si es tech).
`industryId`	Legacy	N/A — singular, reemplazado por StartupIndustry (many-to-many)	Instrucción 2026-04-18 23:55 explícita: "se debe elegir al menos una subindustria entre los dos listados" — plural.
`subIndustryId`	Legacy	N/A	Legacy paralelo a `industryId`.
`revenueRange`	Alineado	Panel 2 FD — rango de facturación; instrucción 2026-04-19 15:30 confirma "propósito de los recursos y TMRL"	Enum de 6 valores consistente con lo que Frank usa en V.6.
`revenueYear`	Nuevo (schema)	N/A — columna Prisma	Año asociado al rango. No mencionado explícito en instrucciones; opcional.
`brlLevel`	Alineado	Panel 2 FD — mencionado en `analisis-alcance-honesto` ("LAP-50 tooltips BRL/TRL/CRL")	Coherente.
`trlLevel`	Alineado	Panel 2 FD — mismo LAP-50	Coherente. Condicional a `isTechBased`.
`aboutCompany`	Divergente	Panel 2 FD — presente en FD hoy, mostrado en perfil	Divergencia de score: mi FieldDef dice `scoreWeight: 0` (nota explicita que `profileScore.ts` no lo incluye). Frank espera que perfiles "completos" cuenten descripción — decidir si subir peso en Fase 2.
`crlLevel`	Divergente	Panel 3 madurez (mi asignación); `analisis-alcance-honesto.md` y biblia dicen "CRL: 9 niveles de madurez comercial"	Discrepancia de panel: lo asigné a stepper 3 (Nivel de madurez) pero en el UI histórico del FD aparece en Panel 2. Decidir si se reordena el stepper.
`tmrlLevel`	Divergente	Instrucción 2026-04-19 15:30 ("agrega TMRL a la BD"); Panel 3 mi asignación	Discrepancia de panel: mi FieldDef lo asigna al stepper 3 pero yo mismo anoté que "en el UI actual aparece dentro del Panel 6 Equipo". Decidir dónde queda.
`investmentSources`	Divergente	Instrucción 2026-04-19 00:50: "capital no dilusivo y financiamiento" — Panel 4 tesis	Divergencia de comportamiento: instrucción dice "si no hay nada seleccionado el sistema toma como si hubiera algo" (bug reportado). Mi FieldDef lo declara simplemente como array; falta documentar la validación "al menos una opción".
`financing`	Legacy	N/A — superseded por `financingSources`	Columna Prisma sin uso activo.
`financingSources`	Alineado	Panel 4 tesis — relacionado con "capital no dilusivo" (instrucción 2026-04-19 00:50)	Array de strings.
`investmentTicket`	Alineado	Panel 4 — referenciado como concepto estándar de Startup	Sin discrepancia.
`investmentPurpose`	Alineado	Panel 4 — instrucción 2026-04-19 15:30: "propósito de los recursos"	Frank pidió explícitamente agregar esta lista a Supabase.
`previousInvestments`	Nuevo (schema)	N/A — columna Prisma (string JSON)	No mencionado explícito en instrucciones activas; sí existe en FD actual.
`previousRounds`	Nuevo (schema)	N/A — columna Prisma	Similar: presente en FD, no destacado en instrucciones-activas.
`totalCapitalRaised`	Nuevo (schema)	N/A — columna Prisma	Presente en FD. No hay instrucción directa reciente.
`pitchDeckUrl`	Alineado	`lap-16-storage-archivos.md`: "Pitch deck (solo FD)"	Bucket privado `pitch-decks`. Peso 10 binario ya en `profileScore.ts`.
`pitchDeckConsent`	Nuevo (schema)	N/A — columna Prisma `pitch_deck_consent`	Flag DEFAULT false. No hay instrucción directa.
`highConceptPitch`	Alineado	Panel 5 modelo de negocio FD — campo existente	Sin discrepancia.
`icp`	Alineado	Panel 5 — perfil de cliente ideal (FD)	Sin discrepancia.
`idealClientProfile`	Legacy	N/A — duplicado de `icp`	Consolidar en Fase 2.
`problemStatement`	Alineado	Panel 5 FD — "Problema que resuelve"	Sin discrepancia.
`problemToSolve`	Legacy	N/A — duplicado de `problemStatement`	Consolidar en Fase 2.
`solution`	Alineado	Panel 5 FD — "Solución propuesta"	Sin discrepancia.
`businessModel`	Legacy	N/A — superseded por `businessModelDescription`	Consolidar en Fase 2.
`businessModelDescription`	Alineado	Panel 5 FD — "Descripción del modelo de negocio"	Sin discrepancia.
`teamSize`	Divergente	Panel 6 equipo FD	Divergencia de score: `profileScore.ts` NO cuenta teamSize (usa teamComposition). Score del campo = 0. Decidir si es el comportamiento esperado.
`teamComposition`	Alineado	Panel 6 — JSON array de roles	Sin discrepancia.
`teamConsent`	Nuevo (schema)	N/A — columna Prisma DEFAULT false	Cuenta al score (pTeamA). No hay instrucción directa que lo mencione.
`teamVerified`	Nuevo (schema)	N/A — columna Prisma	Flag operativo de admin.
`ceoFirstName`	Alineado	FS + FD Panel 6 — "Nombre del CEO"	Sin discrepancia.
`ceoLastName`	Alineado	FS + FD Panel 6	Sin discrepancia.
`ceoGender`	Alineado	FS + FD Panel 6	Sin discrepancia.
`ceoLinkedIn`	Alineado	FS + FD Panel 6 — "LinkedIn del CEO"	Sin discrepancia.
`ceoEmail`	Alineado	FS + FD Panel 6	Sin discrepancia.
`ceoPhone`	Alineado	FS + FD Panel 6	Sin discrepancia.
`ceoIsFounder`	Alineado	FS + FD Panel 6	Sin discrepancia.
`ceoContactConsent`	Nuevo (schema)	N/A — columna Prisma DEFAULT false	Flag de consentimiento. No en instrucciones-activas.
`website`	Alineado	Panel 7 presencia digital — instrucción 2026-04-15 20:22 (LAP-132: "Página web en FUD sin prefijo https://")	Coherente.
`linkedIn`	Divergente	Panel 7 — instrucción 2026-04-16 12:30: "en el último panel pedimos al menos 1 red social, resaltar la advertencia"	Divergencia de obligatoriedad: Frank requiere "al menos 1 red social". Mi FieldDef declara cada red como `required: false` individual pero falta representar la regla compuesta "al menos una de (LinkedIn, Instagram, Facebook, Twitter, YouTube, TikTok)".
`instagram`	Divergente	Panel 7 — misma instrucción 2026-04-16 12:30	Misma observación: regla "al menos 1" no capturada.
`facebook`	Divergente	Panel 7 — misma instrucción	Misma observación.
`twitter`	Divergente	Panel 7 — misma instrucción	Misma observación. Además mi nota declara deuda: en FS actual `twitter` espeja `tiktok` por retrocompatibilidad.
`youtube`	Divergente	Panel 7	Misma observación.
`tiktok`	Divergente	Panel 7	Misma observación.
`logoUrl`	Alineado	`lap-16-storage-archivos.md`: "Logo de la organización (FI, FS, FD)"; bucket público `logos`	Coherente.
`emailConsent`	Nuevo (schema)	N/A — columna Prisma DEFAULT false	Flag de consentimiento. No mencionado en instrucciones activas (flujo legal estándar).
`contactEmail`	Alineado	FS + FD Panel 1 — schema NOT NULL	Requerido para el registro.
`contactPhone`	Nuevo (schema)	N/A — columna Prisma opcional	Presente en FD; no destacado en instrucciones.
`industries` (m-to-m)	Alineado	Instrucciones 2026-04-18 21:38 y 22:06: "12 categorías de industrias tech + tradicional + agnóstica"	Tabla `StartupIndustry`. Frank ya aprobó la taxonomía.
`operatingCountries`	Alineado	Tabla `StartupOperatingCountry` (country+region)	Coherente.
`businessNeeds`	Alineado	Tabla `StartupBusinessNeed` Panel 4	Coherente.
`socialMedia` (aux)	Divergente	Tabla `StartupSocialMedia` — duplicada con columnas escalares	Duplicación semántica: misma data en dos lugares. Mi nota ya lo advierte; decidir cuál es la fuente canónica en Fase 2.
`founders`	Alineado	Tabla `StartupFounder` — Panel 5C original ("Fundadores y equipo directivo")	Peso 12 heredado de `profileScore.ts`.

31 Alineados · 14 Divergentes · 12 Nuevos (schema BD) · 8 Legacy Total: 65 campos

Sección 2 — ICG (67 campos)

Campo	Estado	Fuente	Nota
`registeredById`	Nuevo (schema)	N/A — FK Profile	Server-side.
`status`	Nuevo (schema)	N/A — enum EntityStatus	Admin-only.
`isPublic`	Nuevo (schema)	N/A — DEFAULT true	Flag directorio público.
`icgType`	Divergente	Panel 1 — enum Prisma (7 valores)	Divergencia de semántica: mi FieldDef nota que es "derivado de icgRoleCategory via categoryToIcgType". Instrucción 2026-04-19 19:30 y 19:33 dice explícitamente: "respeta el diseño aprobado para el orden de las categorías de rol". Validar que el mapping categoryToIcgType conserva el orden pedido.
`icgRole`	Divergente	Panel 1 — `analisis-alcance-honesto.md`: "Taxonomía Rol en ecosistema (~40 subcategorías)"; QA-LAP218: "Family Office"	Discrepancia de peso: mi FieldDef asigna 1.5 pts. Dado que Frank trata el rol como campo crítico (varias instrucciones sobre orden 2026-04-19), validar si el peso debe subir.
`icgRoleCategory`	Divergente	Panel 1 — instrucciones 2026-04-19 19:30 y 19:33	Discrepancia de orden: Frank fue explícito: "en los formularios las categorías deben mostrarse en el orden que ya habíamos aprobado, no alfabético". Mi FieldDef no captura el orden — vive en otro lado. Confirmar dónde se renderiza el orden.
`organizationName`	Alineado	Panel 1 — NOT NULL schema	Coherente. Nota explícita sobre excepción Inversionista Individual.
`investorFirstName`	Alineado	Panel 1 — derivación para Inversionista Individual	Coherente con icgRoleCategory.
`investorLastName`	Alineado	Panel 1	Coherente.
`presentation`	Alineado	Panel 1 — "Presentación / acerca del ICG"	Sin discrepancia.
`country`	Alineado	Panel 1 — schema NOT NULL	Coherente.
`city`	Divergente	Panel 1 — schema NOT NULL	Misma discrepancia que Startup.city: submit inserta `""` hoy. Score = 0. Decidir si es obligatorio de facto.
`operatingCountries`	Divergente	Panel 1 — columna escalar + tabla aux IcgOperatingCountry	Duplicación semántica: escalar y tabla aux almacenan lo mismo. Consolidar en Fase 2.
`interestIndustries`	Divergente	Panel 1 — instrucción 2026-04-19 00:26: "En FI Panel 1 es obligación del ICG seleccionar al menos una subindustria entre los dos listados (Tech y tradicional)"	Discrepancia triple: (1) Frank exige al menos 1 subindustria — no capturado como regla compuesta. (2) duplicado semánticamente con `interestIndustriesP3` y con `IcgIndustry`. (3) instrucción 2026-04-19 00:32: "antes del mensaje de apoyo pon el título 'Industrias en las que opera el ICG*'" — el asterisco marca obligatoriedad; mi FieldDef dice `required: false`.
`contactEmail`	Alineado	Panel 1 — NOT NULL	Coherente.
`contactPhone`	Alineado	Panel 2 FD	Coherente.
`industryId`	Legacy	N/A — superseded	Deuda.
`subIndustryId`	Legacy	N/A	Deuda.
`emailConsent`	Nuevo (schema)	N/A — columna Prisma	Flag.
`termsAccepted`	Nuevo (schema)	N/A — legal	Estándar.
`privacyAccepted`	Nuevo (schema)	N/A — legal	Estándar.
`contactFirstName`	Alineado	Panel 2 datos de contacto FI	Sin discrepancia.
`contactLastName`	Alineado	Panel 2 FI	Sin discrepancia.
`contactPosition`	Alineado	Panel 2 FI	Sin discrepancia.
`contactPersonalEmail`	Alineado	Panel 2 FI	Distinto del corporativo.
`contactLinkedIn`	Alineado	Panel 2 FI	Sin discrepancia.
`contactUserId`	Nuevo (schema)	N/A — FK opcional a Profile	Resuelta server-side por email match.
`valuePropositionP4`	Divergente	Panel 3 propuesta de valor FI (jsonb)	Discrepancia de panel: mi FieldDef lo mete al panel 3 con peso 10 y nombre `valuePropositionP4` (sufijo P4) porque históricamente era panel 4. El nombre del campo ya refleja el drift — decidir si se renombra al consolidar el stepper 6-paneles.
`investmentSourcesP4`	Divergente	Panel 3 — mismo sufijo confuso	Misma observación: nombre P4 en panel 3 es confuso. Renombrar en Fase 2.
`investmentRounds`	Alineado	Panel 3 FI	Sin discrepancia.
`debtFinancingSources`	Alineado	Panel 3 FI — condicional a financiamiento-deuda	Coherente.
`ticketValue`	Alineado	Panel 3 FI	Array de rangos.
`hasActiveCall`	Alineado	Panel 3 FI	Coherente.
`callClosingDate`	Alineado	Panel 3 FI — condicional	Coherente.
`isPermanentCall`	Alineado	Panel 3 FI — subordinado a hasActiveCall	Coherente.
`activeProcesses`	Legacy	N/A — text legacy	Deuda.
`selectedCompanyTypes`	Alineado	Panel 4 empresas de interés FI — controla visibilidad de TRL/CRL	Coherente.
`interestIndustriesP3`	Divergente	Panel 4 — duplicado con interestIndustries y con IcgIndustry (tabla aux)	Triple duplicación. Además sufijo P3 en Panel 4 es confuso. Renombrar + consolidar en Fase 2.
`brlLevels`	Alineado	Panel 4 FI	Array.
`trlLevels`	Alineado	Panel 4 FI — solo Startup/Scaleup	Coherente.
`crlLevels`	Alineado	Panel 4 FI	Coherente.
`revenueRange` (ICG)	Divergente	Panel 4 FI — columna BD `revenue_range_icg`	Discrepancia de nombre: en Startup es `revenue_range` (string enum), en ICG es `revenue_range_icg` (array). Mi nota ya lo anota. Semánticamente confunden.
`teamCompositionP3`	Alineado	Panel 4 FI	Array.
`legalConstitution`	Alineado	Panel 4 FI	Coherente.
`fiscalCountries`	Alineado	Panel 4 FI	Array.
`strategicNeedsP5`	Alineado	Panel 5 necesidades estratégicas FI (jsonb)	Peso 8.
`idealAllyP5`	Alineado	Panel 5 FI (jsonb)	Peso 6.
`otherStrategicNeed`	Alineado	Panel 5 FI — condicional a subcategoryId "otra"	Coherente.
`website`	Divergente	Panel 6 presencia digital FI	Misma instrucción 2026-04-16 12:30 sobre "al menos 1 red social" aplica también a FI. Regla compuesta no representada.
`linkedIn`	Divergente	Panel 6 FI	Misma observación.
`instagram`	Divergente	Panel 6 FI	Misma observación.
`facebook`	Divergente	Panel 6 FI	Misma observación.
`twitter`	Divergente	Panel 6 FI	Misma observación.
`tiktok`	Divergente	Panel 6 FI	Misma observación.
`youtube`	Divergente	Panel 6 FI	Misma observación.
`logoUrl`	Alineado	Panel 6 — `lap-16-storage-archivos.md`	Coherente.
`valuePropositionLegacy`	Legacy	N/A — text superseded	Deuda.
`idealAllyLegacy`	Legacy	N/A — text superseded	Deuda.
`investmentSourcesLegacy`	Legacy	N/A	Deuda.
`financing` (ICG)	Legacy	N/A	Deuda.
`investmentTicketLegacy`	Legacy	N/A	Deuda.
`previousRoundsLegacy`	Legacy	N/A	Deuda.
`teamSize` (ICG)	Legacy	N/A	Deuda.
`teamComposition` (ICG)	Legacy	N/A — superseded por teamCompositionP3	Deuda.
`strategicNeedsAux`	Divergente	Tabla StrategicNeed — enum StrategicNeedCategory	Duplicación: con `strategic_needs_p5` (jsonb). Consolidar.
`icgIndustries`	Divergente	Tabla IcgIndustry — duplica interestIndustries	Duplicación semántica triple (con interestIndustries + interestIndustriesP3).
`icgOperatingCountries`	Divergente	Tabla IcgOperatingCountry — duplica operatingCountries	Duplicación: mismo dato en columna escalar y tabla aux.

29 Alineados · 20 Divergentes · 7 Nuevos (schema BD) · 11 Legacy Total: 67 campos

Sección 3 — Resumen ejecutivo

Total alineados: 60 de 132 (45%). Casi la mitad de los campos ya coincide con lo que Frank instruyó en el log de instrucciones activas y con lo que está documentado en la biblia del Hub Central. Divergentes: 34. Nuevos (schema BD, sin instrucción explícita): 19. Legacy/deuda: 19.
Divergencias por tipo:
- Obligatoriedad / validación compuesta (8): la regla "al menos 1 red social" en el Panel 7/6 está en instrucciones-activas.md desde 2026-04-16 12:30 pero mi archivo no la captura como regla cross-field; cada red aparece como required:false individual. Igual pasa con "al menos 1 subindustria" en FI Panel 1 (instrucción 2026-04-19 00:26).
- Panel / stepper (4): TMRL, CRL, valuePropositionP4 e interestIndustriesP3 tienen panel en mi archivo que no coincide con donde Frank los tiene en el UI histórico (FD tiene 7 paneles, FI tiene 6 — los sufijos P3/P4/P5 del código delatan drift).
- Duplicación semántica (7): industries (3 lugares en ICG), operatingCountries (escalar + tabla aux), socialMedia (columnas + tabla), strategicNeeds (jsonb + tabla). Todos marcados como deuda a consolidar en Fase 2.
- Score weight no documentado (4): teamSize=0, aboutCompany=0, city=0 y revenueRange — Frank no ha dicho explícitamente qué valor debe aportar cada uno; mi archivo refleja lo que hoy hace profileScore.ts.
- Orden de listas (1 crítica): instrucción 2026-04-19 19:30 y 19:33: "en los formularios las categorías de rol deben mostrarse en el orden que ya habíamos aprobado". Mi FieldDef no captura ese orden (vive en el componente UI).
Campos nuevos agregados por cubrir schema BD (19): registeredById, status, isPublic, 4 flags de consentimiento Startup, 3 flags legales ICG, teamVerified, contactUserId, revenueYear, previousInvestments, previousRounds, totalCapitalRaised, pitchDeckConsent, ceoContactConsent, emailConsent (Startup), contactPhone. Son mayoría flags/metadata — ninguno cambia la UX que Frank ya aprobó.
Campos de instrucciones que YO NO TENGO: ver Sección 4. La búsqueda no encontró campos totalmente ausentes, pero sí reglas que no están representadas como metadata (ver hallazgos críticos abajo).
Recomendación — decisiones que requieren Frank:
- (a) La regla "al menos 1 red social" (FS/FD/FI/FUD) — ¿la implementamos como validación cross-field explícita en el motor de formularios?
- (b) Panel definitivo de TMRL y CRL — ¿van en "Nivel de madurez" (stepper 3) o siguen en "Equipo" / "Perfil de compañía"?
- (c) Score: ¿aboutCompany, teamSize, city deben aportar peso o quedan en 0?
- (d) Orden aprobado de "Rol en el ecosistema" — ¿dónde está documentado? Instrucción 2026-04-19 19:30 lo menciona como "ya habíamos aprobado" pero no está pegado en basic-memory.
- (e) Duplicaciones industries + operatingCountries + socialMedia + strategicNeeds — autorización para consolidar en Fase 2.

Sección 4 — Campos en instrucciones NO cubiertos

Hallazgo positivo

No encontré ningún campo individual mencionado en las instrucciones de Frank que esté totalmente ausente de STARTUP_FIELDS o ICG_FIELDS. Eso quiere decir que la Fase 1 sí cubre la superficie de data que el formulario pide hoy.

Lo que sí falta — no son campos, son reglas:

Regla "al menos 1 red social" en el panel de Presencia Digital (instrucción 2026-04-16 12:30, aplica a FS, FD, FI y FUD). Mi metadata actual no tiene un lugar para expresar validaciones cross-field — cada campo es required:true o false en aislamiento. Fase 2 va a necesitar un mecanismo (ej: validators: ['atLeastOneOf:social*']).
Regla "al menos 1 subindustria entre Tech y Tradicional" en FI Panel 1 (instrucción 2026-04-19 00:26). Misma naturaleza: validación cross-field que hoy está en código imperativo del formulario.
Orden aprobado de categorías de "Rol en el ecosistema" (instrucción 2026-04-19 19:30 / 19:33). El orden "ya había sido aprobado" según Frank pero no está documentado en basic-memory — vive solo en el componente Svelte. Riesgo: si el componente se regenera desde mi archivo, el orden se pierde.
Lista aprobada de 12 industrias tech + tradicionales + Agnóstica (instrucciones 2026-04-18 21:38 y 22:06). Frank la mandó completa y está en Supabase, no en basic-memory. Al regenerar desde el archivo TS, tenemos que seedear desde la BD o anotar el enum exacto.
Propósito de los recursos + TMRL — instrucción 2026-04-19 15:30: "agrega esas dos listas a la BD". Los valores están en Supabase; las opciones enum de investmentPurpose y tmrlLevel no están en mi FieldDef (mi tipo los declara como string, no enum con valores).
Tuteo vs voseo (instrucción 2026-04-22 15:00): "Cambia ¿Qué querés hacer? por ¿Qué quieres hacer?. Nuestra comunicación es por tuteo". Afecta los labels y textos de apoyo de los campos — hoy mis labels están en tuteo neutro pero es una regla de lenguaje que atraviesa todos los campos.
Campo de score de completitud del perfil — la biblia del Hub Central menciona "barra de progreso con el mismo sistema de colores que el scoring de FI y FD (el del círculo con porcentajes)". Mi archivo tiene scoreWeight por campo pero no tiene una regla top-level que declare los umbrales 34/67 del círculo (están en scoreColor.ts, instrucción que aplica del QA LAP-218). No es un campo nuevo, es metadata de presentación.

Interpretación para Frank: el archivo de Fase 1 captura bien el "qué" (qué columnas existen y dónde viven) pero todavía no captura bien el "cómo se valida" (reglas cross-field) ni el "cómo se presenta" (orden de opciones, enum values, umbrales de color). Fase 2 debería extender la metadata con esos tres ejes antes de regenerar los consumidores.