tobby168/pipeline-de-evaluacion

Evaluación de currículums (embudo de 3 puertas)

Un currículum no está terminado hasta que haya pasado un embudo independiente de 3 puertas y se haya registrado la tarjeta de puntuación. Las puertas reflejan la contratación real: reclutador -> ingeniero senior -> gerente de contratación. Cada una es una mirada diferente que juzga solo lo que puede percibir. Todas las personas, rúbricas, pesos y umbrales viven en config/scoring_panel.yaml — úsalo textualmente; no los codifiques aquí.

Principios

• Una pizarra en blanco, cada vez. Un subagente por puerta, cada uno en un contexto nuevo: nunca ha visto a este candidato y lo conoce por primera vez solo a través del currículum. Recibe ÚNICAMENTE la descripción del puesto (JD), el texto del currículum y su propio read_mode/rúbrica. Nunca le pases nuestro análisis de ajuste, notas de decisión o una puntuación anterior (efecto ancla).
• Ojos diferentes, rúbricas diferentes. No entregues a las tres puertas una rúbrica compartida.
• No promedies. El veredicto es el peor nivel, etiquetado en la primera puerta que falla; el número de seguimiento es la mínima puntuación de puerta. Un 65 del reclutador y un 82 del gerente de contratación promedian un cómodo 73,5 — pero el currículum murió en la primera puerta y el gerente nunca lo ve.
• Juzga lo que se lee, no lo que es verdad. Un revisor que se encuentra con el currículum de un desconocido no tiene verdad absoluta, por lo que puntúa lo convincente que es el documento — una afirmación inflada simplemente no convence. La veracidad es responsabilidad del autor: por eso este repositorio nunca inventa experiencia (ver la habilidad de construcción).
• Puntúa el documento real. Extrae el texto del .docx construido una vez, verifica que no esté vacío, y pásalo en línea a las tres puertas (una puerta que recibe una lectura vacía alucinará y puntuará basura).
• Los hallazgos no son ediciones. Actuar sobre un hallazgo nunca debe inventar. Una palabra clave de la JD necesita una viñeta de respaldo de experiencia real; de lo contrario, es una brecha honesta.

Proceso

1. Cargar config/scoring_panel.yaml.
2. Reunir entradas: la JD (del registro), el texto extraído del currículum, confirmar que sea una página.
3. Despachar las tres puertas en un mismo mensaje (en paralelo), cada una construida desde reviewer-prompt-template.md.
4. Componer: clasificar cada puerta según su propio pass / borderline; veredicto = peor nivel en la puerta más temprana (NO@reclutador, BORDERLINE@gerente_de_contratacion, o PASS); número de seguimiento = min(puntuaciones de puerta); consenso = lo que marquen >= 2 puertas de forma independiente; clasificar cada deducción como corregible vs inherente.
5. Escribir una sección ## Scorecard en el registro de la aplicación (formato abajo) y una línea en su registro.

Formato del Scorecard

## Scorecard — YYYY-MM-DD  (currículum: <output>.pdf)
**Embudo: Reclutador ✅ NN → Staff ⚠️ NN → HM ❌ NN → NO@gerente_de_contratacion**
**Puerta más débil: NN/100**

| Puerta | Puntuación | Subpuntuaciones | Veredicto |
|---|---|---|---|
| Reclutador | NN/100 | stack NN/45, seniority NN/30, escaneo NN/25 | ✅ |
| Staff eng | NN/100 | tecnología NN/35, proyectos NN/30, jd NN/35 | ⚠️ |
| HM        | NN/100 | trabajo NN/65, nivel NN/35 | ❌ |

**Lista de sondeos (staff):** 1) … 2) … 3) …      **Memo de riesgo (HM):** …
**Consenso (>=2 puertas):** …
**Deducciones:** corregibles: … · inherentes (narrativa de entrevista): …
**Próximas ediciones priorizadas:** 1) … 2) … 3) …

Errores comunes

• Anclar las puertas con nuestro propio análisis o una puntuación anterior.
• Promediar las tres puntuaciones.
• Pedir a un revisor que califique la veracidad (solo puede calificar la capacidad de persuasión).
• Dejar que una puerta deduzca cosas que el formulario de solicitud pregunta por separado (ver out_of_scope en la configuración).
• Tratar una brecha inherente como corregible mediante reformulación.
• Aumentar la puntuación inventando información.