## Por qué importa

Las evaluaciones escritas de memoria infravaloran de forma sistemática a quien entrega con constancia y sin ruido, y sobrevaloran a quien fue visible el último mes. La solución no es la vigilancia — es dejar que el [redactor de IA](/docs/performance-ai-drafted-reviews) *cite* trabajo real al redactar el borrador: las merge requests que alguien entregó y las revisiones que hizo para otros, como títulos y enlaces que después sopesa un evaluador humano.

La capa de señales de Kit se apoya en una decisión arquitectónica firme: **obtención bajo demanda, cero persistencia**. Las señales se consultan en vivo cuando un evaluador genera un borrador, se destilan en el resumen de transparencia de ese borrador y se descartan. Kit nunca se convierte en un almacén de actividad: no hay panel de recuentos de commits, no hay clasificación y, estructuralmente, no hay forma de comparar personas, porque los datos no se guardan para poder compararlos.

> [!WARNING]
> Las señales producen evidencia narrativa, nunca puntuaciones. No se recogen métricas de volumen ni estadísticas de diffs, no existe ninguna superficie de comparación entre personas y la redacción es opt-in por borrador con transparencia total hacia la persona evaluada. Si buscas una clasificación de productividad, esta función te va a decepcionar activamente — por diseño.

## Conectar GitLab

GitLab es el proveedor de la v0 (una conexión por cuenta). Ve a [Performance > Work signals](/performance/signal_source):

| Campo | Valor |
|-------|-------|
| GitLab URL | `https://gitlab.com`, o la URL de tu instancia autoalojada — el autoalojamiento es totalmente compatible (HTTPS, host accesible públicamente) |
| Group access token | Un Group Access Token **read_api** con el rol **Reporter** — o un PAT de cuenta de servicio en el plan Free |

Pulsa **Connect GitLab** (conectar GitLab). El token se cifra en reposo y después solo se muestra enmascarado. Kit usa acceso de API de solo lectura; nunca escribe en tu GitLab. Si la conexión falla más adelante (token revocado, host inaccesible), la fuente pasa a **Error** con el mensaje del fallo visible — vuelve a introducir las credenciales para reconectar. Los borradores generados con la fuente caída simplemente continúan sin señales, anotando que la fuente no estaba disponible.

## Confirmar identidades

Las señales se obtienen por persona, así que cada miembro del equipo debe estar asociado a su nombre de usuario de GitLab — y la asociación debe estar **confirmada por un administrador** antes de usarse siquiera una vez. Esta es la valla contra el fallo obvio: un nombre de usuario con una errata jamás debe traer la actividad de un desconocido a la evaluación de alguien. Las asociaciones sin confirmar se rechazan en el momento de la consulta, sin excepciones.

En **Identity mapping** (asociación de identidades), añade el nombre de usuario de GitLab de cada miembro — Kit sugiere uno buscando a la persona por correo en tu GitLab cuando puede — y confírmalo después. Los miembros sin asociación confirmada se omiten en silencio al redactar; no se consulta nada sobre ellos.

## Qué se obtiene

Al redactar el borrador, con el opt-in de ese borrador marcado, Kit consulta para el periodo evaluado (el periodo del ciclo o, si no está definido, los últimos 6 meses):

| Señal | Significado |
|-------|-------------|
| Merge requests fusionadas | El trabajo que la persona entregó |
| Actividad de revisión | Las MR que la persona revisó para otros — el trabajo de cohesión que la mayoría de las herramientas ignora |

Cada señal es **título, enlace, fecha y repositorio — nada más**. Ni tamaños de diff, ni recuentos de líneas, ni frecuencias de commits. Sobre la marcha se derivan dos anotaciones de la era de la IA: **autoría de IA** (trailers de commit como `Assisted-by:`/`Co-Authored-By:` que nombran agentes de código — el redactor reconoce la dirección y el rigor de revisión, nunca el volumen inflado) y **trabajo de habilitación de IA** (cambios en skills, configuraciones de agentes, herramientas MCP, prompts — trabajo multiplicador que el redactor tiene instrucciones de reconocer de forma explícita).

## Opt-in, transparencia y rechazo

- **Opt-in por borrador** — las señales se usan solo cuando el evaluador marca «Include work signals from GitLab (opt-in for this draft)». Nunca por defecto, nunca de forma encubierta.
- **Transparencia hacia la persona evaluada** — cada señal usada se lista en el panel de transparencia de la evaluación, visible para la persona evaluada antes de la finalización: exactamente qué elementos, obtenidos cuándo, con la nota de que no se almacenaron métricas ni datos de actividad.
- **Barrera humana aguas abajo** — un borrador informado por señales sigue pasando por la [barrera de envío de editar-o-asumir](/docs/performance-ai-drafted-reviews); las señales informan la valoración de una persona, nunca se convierten en la valoración.
- **El trabajo invisible para las herramientas tiene su canal** — el campo **Your own notes** de la autoevaluación existe precisamente porque la mentoría, los incidentes y desbloquear a otros no aparecen en un repositorio de código.

> [!NOTE]
> Para clientes en Alemania: la cogestión del comité de empresa (BetrVG §87(1) Nr. 6) cubre los sistemas *capaces* de monitorizar el desempeño. El diseño de Kit — obtención bajo demanda, sin almacén — es el punto de partida correcto, pero involucra a tu comité de empresa antes de conectar una fuente.

## En resumen

- [ ] Crea en GitLab un Group Access Token read_api (rol Reporter)
- [ ] Conéctalo en [Performance > Work signals](/performance/signal_source) — gitlab.com o autoalojado
- [ ] Asocia y **confirma** el nombre de usuario de GitLab de cada miembro
- [ ] Cuenta al equipo que las señales existen y son opt-in por borrador — nunca un uso encubierto
- [ ] Recuerda a las personas evaluadas que usen **Your own notes** para el trabajo que GitLab no ve

## Y ahora qué

- [Evaluaciones redactadas con IA](/docs/performance-ai-drafted-reviews) — donde las señales realmente afloran
- [Descripción general de las evaluaciones de desempeño](/docs/performance-reviews-overview) — cómo encaja la capa de señales en el módulo completo