Fuentes de señales de trabajo
Conecta GitLab para que los borradores de IA citen trabajo real entregado — obtención bajo demanda, con privacidad acotada, opt-in por borrador y nunca un almacén de vigilancia.
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 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:
| 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; 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 — 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 — donde las señales realmente afloran
- Descripción general de las evaluaciones de desempeño — cómo encaja la capa de señales en el módulo completo