Disciplina de privacidad y PII
Los artefactos de ZeroClaw son públicos: el historial de git, las versiones publicadas, los fixtures, los snapshots, el libro de documentación, cada configuración regional renderizada. Todo lo que confirmes se distribuye con el proyecto para siempre. Trata la privacidad como una condición obligatoria para el merge, no como un esfuerzo de buena voluntad.
Nunca hagas commit de ninguno de estos
En código, documentación, pruebas, fixtures, instantáneas, registros, ejemplos, mensajes de error o mensajes de commit:
- Nombres reales
- Direcciones de correo electrónico personales
- Números de teléfono, direcciones
- Tokens de acceso, claves de API, credenciales
- IDs de cuenta, IDs de sesión, cualquier cosa que identifique a una persona real o a una cuenta
- URLs privadas (nombres de host internos, URLs firmadas de S3, cualquier cosa que no esté destinada a ser pública)
Esta lista no es exhaustiva. El principio es: si algo podría identificar a una persona real o conceder acceso a algo, no debe estar en el repositorio.
Utiliza marcadores de posición neutros
Los fixtures de prueba, ejemplos, mensajes de error y capturas de pantalla utilizan marcadores de posición genéricos del proyecto en lugar de datos de identidad reales. Paleta recomendada:
| Caso de uso | Ejemplos |
|---|---|
| Etiquetas de actor | zeroclaw_user, zeroclaw_operator, zeroclaw_maintainer, test_user, user_a, project_bot |
| Etiquetas de servicio / tiempo de ejecución | zeroclaw_bot, zeroclaw_service, zeroclaw_runtime, zeroclaw_node |
| Etiquetas de entorno | zeroclaw_project, zeroclaw_workspace, zeroclaw_channel |
| Nombres de host | example.com, host.invalid, 192.0.2.x (rango de documentación RFC 5737) |
| Direcciones de correo electrónico | user@example.com, bot@zeroclaw.invalid |
Los nombres de las pruebas, los mensajes de aserción y el contenido de los fixtures se mantienen impersonales y centrados en el sistema: evite el lenguaje en primera persona y los enfoques específicos de identidad.
Cuando tengas que hacer referencia a la identidad
Si una prueba o documentación genuinamente necesita una identidad con forma de rol, usa únicamente roles con ámbito de ZeroClaw: ZeroClawAgent, ZeroClawOperator, ZeroClawMaintainer. No tomes prestados nombres reales, ni siquiera seudónimos: los seudónimos tienden a volver a convertirse en reales con el tiempo.
Las menciones con @ de GitHub en comentarios de PR/issues son diferentes: dirigirse a un colaborador por su nombre de usuario es la forma de hablar con las personas en GitHub, y @WareWolf-MoonWall no es una violación de privacidad. La regla trata sobre el contenido almacenado en el repositorio (código, tests, fixtures, documentación), no sobre las conversaciones en los hilos de PR/issues.
Reproducción de incidentes externos
Si estás capturando un rastro de incidente, carga útil de registro o respuesta externa en un fixture de prueba: redacta y anonimiza antes de hacer el commit. Los IDs de sesión reales, IDs de usuario reales, nombres de host reales y tokens de autenticación reales deben pasar por un proceso de limpieza primero. La versión redactada es la que se envía; la original permanece fuera de git.
Lista de verificación antes de enviar
Antes de hacer push, escanea el diff en fase específicamente en busca de fugas de identidad:
sh
git diff --cached
Las formas que debes buscar: cualquier cosa que parezca un correo electrónico, una URL con un nombre de host no público, una cadena larga y aleatoria que podría ser un token, un nombre que no sea el tuyo y que no provenga de un marcador de posición del ámbito del proyecto.
Si una ejecución de CI capturó un valor real (un ID de sesión real en un snapshot, una cadena de user agent real con información identificable, etc.) y se confirmó en un commit, es un incidente de privacidad: abre un issue, elimina los datos, haz force-push si acaba de incorporarse, y contacta a los mantenedores si llegó a master.
¿Por qué esto es estricto?
La última categoría, confirmar accidentalmente una identidad real, es difícil de deshacer. Una vez que un nombre o correo electrónico real llega a master, se propaga inmediatamente a través de forks, mirrors y clones. Hacer squash o force-push corrige la rama pública pero no alcanza las copias. La solución más económica es el escaneo pre-commit; todo lo que viene después es reducción de daños.