​

Stage 3 — Panel Discussion (Los actores discuten qué llenar)

​

Responsabilidad

​

Actores (todos reviewers; ninguno redactó el borrador, para evitar autocomplacencia)

1. persona-trebol-cpo-reviewer — producto, experiencia del cliente, precedente, escalabilidad y mantenibilidad de la plantilla.
2. persona-trebol-template-engineer — corrección técnica de cada variable: que exista, numeración correcta, bucle vs PDF, fuentes/inversos, gotchas (delegate, x_mark, separadores Colombia, espacios/mayúsculas en llaves).
3. persona-trebol-legal-dictamen — corrección jurídica del mapeo: que cada variable corresponda al concepto legal correcto del dictamen (no confundir poder de dominio con administración, que la FUENTE cite folio/RPPC adecuadamente, suficiencia regulatoria).

​

Proceso

​

Paso 1 — Dictamen independiente

​

Paso 2 — Conciliación por campo

• Consenso (los 3 coinciden) → decision = variable acordada.
• Desacuerdo técnico (el ingeniero corrige la variable) → prevalece el ingeniero en lo técnico (qué variable existe y cómo se escribe), pero el legal puede vetar si la variable correcta técnicamente no corresponde al concepto legal del campo (entonces ask_user o SIN_VARIABLE).
• Desacuerdo legal (la variable existe pero el legal dice que no corresponde al concepto) → prevalece el criterio legal sobre el “encaja técnicamente”; registrar disenso del ingeniero si lo hay.
• Preocupación de producto/precedente (CPO) → no bloquea una variable correcta, pero se registra como nota para el racional (ej. “este campo crea precedente: futuros clientes esperarán lo mismo”).
• No se resuelve internamente (ambigüedad real, decisión de negocio, campo sin variable cuya intención no está clara) → decision = ask_user con la pregunta concreta para Stage 4.

​

Paso 3 — Decisión por campo

• FINAL + token(s) definitivos.
• SIN_VARIABLE + tratamiento sugerido (texto fijo / dejar en blanco) + motivo.
• ASK_USER + pregunta cerrada para Stage 4.

​

Paso 4 — Registrar disensos y notas

​

Output (markdown para Stage 4/5)

# Panel Decisions
## Resumen
- total_fields: N
- FINAL: n1
- SIN_VARIABLE: n2
- ASK_USER: n3

## F014  "FACULTADES DEL APODERADO"
- decision: FINAL
- variable: {key_person_1_power_administration_x_mark} ... (6 poderes, 1-based)
- dissent: []
- notes: "Ingeniero: 'delegate' no está en doc web; se mantiene porque la referencia lo usa, pendiente verificar contra verificación real (candidato a corrections)."
- rationale: "Legal confirma que las 6 facultades corresponden al concepto de poderes del dictamen; ingeniero confirma sintaxis x_mark y numeración 1-based."

## F051  "TIPO DE GARANTÍA OTORGADA"
- decision: ASK_USER
- question: "¿Este campo debe llenarse con la capacidad estatutaria {legal_businessAssetPledging} (sí/no que extrae Trébol) o es un dato operativo que captura el cliente manualmente?"
- rationale: "El ingeniero ve una variable cercana; el legal duda que corresponda al mismo concepto. Decisión de negocio → usuario."

​

Reglas duras

1. El ingeniero manda en lo técnico (existencia y escritura de la variable); el legal manda en la correspondencia conceptual (que la variable signifique lo que el campo del dictamen pide). Si chocan, gana el legal en “qué concepto” y el ingeniero en “cómo se escribe la variable de ese concepto”.
2. No inventar variables en la conciliación, igual que Stage 2.
3. Todo desacuerdo no resuelto → ASK_USER, no un mapeo a la fuerza.
4. Racional y disensos siempre registrados. Invariante del pipeline.
5. No edites el archivo. Solo decides. Stage 5 inserta.
6. Si un actor no está disponible, continúa con los otros dos y marca explícitamente cuál faltó en notes.

​

Manejo de errores

• Variable que ningún actor logra confirmar que existe: SIN_VARIABLE o ASK_USER (nunca FINAL con una variable dudosa). Sugiere verificar contra la doc web / una verificación real.
• El cliente ya tokenizó mal un campo: decisión FINAL con el token corregido + notes explicando la corrección.
• Plantilla con secciones que Trébol no soporta (consulta externa nueva): SIN_VARIABLE con nota; candidato a futura variable.

​

Checklist

• Los 3 actores dieron dictamen (o se marcó cuál faltó).
• Cada campo tiene decisión FINAL/SIN_VARIABLE/ASK_USER.
• Desacuerdos registrados como dissent.
• Preocupaciones de precedente/mantenibilidad en notes.
• Ninguna decisión FINAL usa una variable no confirmada.
• Preguntas de ASK_USER formuladas cerradas para Stage 4.