Saltar al contenido

Preguntas frecuentes

Respuestas basadas en el código de Scuda: cómo funciona el modo prueba, qué acciones se pueden revertir, cómo se protege la whitelist y qué vigila cada módulo.

Modos · Accesos · Módulos

Modos

Modo prueba y actuación

Cómo arranca Scuda, qué medidas toma en cada modo y qué se puede revertir tras un incidente.

¿Qué ocurre en modo prueba y cómo se pasa a modo real?

Scuda arranca en modo prueba, que viene activado por defecto. Vigila el servidor y publica los informes de incidentes en el canal de logs, pero no ejecuta ninguna acción sobre miembros ni canales. En el informe aparecen como simuladas.

Hay dos matices. La alerta solo avisa. Y completar una verificación ya iniciada solo libera a la persona, quitándole la cuarentena y dándole el rol verificado.

Entre 24 y 72 horas tras el asistente de configuración, Scuda publica un resumen de lo que habría hecho en modo real. Pasar a modo real exige confirmación explícita: el comando /scuda mode mode:live confirm:true, o el botón de confirmación en dos pasos de ese resumen.

Ver cómo funciona el paso a modo real →

¿Qué medidas se pueden deshacer y cuáles no tienen marcha atrás?

El botón Deshacer del informe y el comando /scuda undo revierten las cuarentenas, el bloqueo de canales, el modo lento y la pausa de invitaciones. Las expulsiones no se pueden revertir automáticamente: la persona debe volver a recibir una invitación.

Los recortes de permisos del módulo nuke tienen una condición más. Solo los restaura el dueño del servidor o un Administrator, con /scuda undo, indicando a la persona y con confirmación expresa.

En modo prueba no hay medidas que revertir: el botón Deshacer responde «Ese incidente no tiene cambios reales que deshacer» y /scuda undo responde «Deshacer completado: 0 liberado(s), 0 omitido(s)».

Ver la actuación y el informe de incidentes →

¿Qué ocurre con el modo prueba y el estado del bot al arrancar o reiniciar?

Los ajustes de cada servidor se guardan en la base de datos del bot y se conservan al reiniciar el proceso: modo prueba o modo real, módulos activos, umbrales, whitelist y roles de staff.

Al arrancar, Scuda recupera el estado de amenaza y los registros de deshacer pendientes de cada servidor. No relanza acciones pasadas: no duplica sanciones ni reenvía cuarentenas. Después reanuda la vigilancia.

Ver el flujo de configuración guiada →

Accesos

Protección y permisos

Quién queda eximido de las sanciones, cómo se gestiona la whitelist y quién puede usar los comandos.

¿Qué hace el bot con el dueño del servidor, la whitelist y la jerarquía de roles?

El propietario del servidor y los miembros, bots o roles registrados en la whitelist están protegidos de forma permanente: ninguna regla automática les aplica sanciones, cuarentenas ni recortes.

Scuda respeta la jerarquía de roles de Discord: solo puede actuar sobre miembros cuyos roles estén estrictamente por debajo del rol más alto de Scuda. Si un objetivo está al mismo nivel o por encima, la acción se omite por jerarquía y se avisa en el canal de logs.

Ver las reglas fijas de los comandos →

¿Por qué los roles de la whitelist tienen un límite de 50 miembros y cuándo se revisan?

Un rol en la whitelist exime a todas las personas que lo lleven. Admitir roles masivos anularía la protección del servidor.

Por eso, al añadir un rol con /scuda whitelist add, Scuda comprueba cuántos miembros tiene en Discord. Lo rechaza si supera los 50 miembros o si el recuento no se puede comprobar. Tampoco admite @everyone ni roles gestionados.

Además, un guardián en segundo plano revisa automáticamente cada 10 minutos el tamaño real de todos los roles de la whitelist. Si un rol ha crecido y supera los 50 miembros, lo retira de la lista y registra la retirada en el canal de logs.

Ver el comando de whitelist y sus opciones →

¿Quién tiene autorización para ejecutar los comandos del bot?

Hay dos niveles de acceso. Admin está reservado a quien tenga el permiso «Gestionar servidor» o a la persona propietaria del servidor. Permite configurar módulos, cambiar ajustes, presets y modos, y gestionar la whitelist y los roles de staff.

Staff incluye a admin y a cualquier persona con uno de los hasta 10 roles autorizados con /scuda staff add. Puede consultar el estado (/scuda status), ver el historial (/scuda logs), activar el pánico (/scuda panic) y deshacer incidentes (/scuda undo).

Por defecto, /scuda está oculto a quien no tenga Gestionar servidor. Para que los roles de staff lo vean, la administración debe habilitarles el comando en Ajustes del servidor → Integraciones.

Ver la lista completa de comandos y permisos →

Módulos

Qué vigila cada módulo

Las señales específicas que observa cada uno de los cuatro módulos del bot.

¿Qué vigila exactamente cada uno de los cuatro módulos de protección?

Scuda divide la protección en cuatro módulos especializados. joins evalúa oleadas de uniones pesando la antigüedad de las cuentas y la falta de avatar. flood detecta spam y ráfagas de mensajes, contenido repetido, menciones excesivas, uso no autorizado de @everyone y enlaces de invitación si el bloqueo está activo.

nuke audita borrados de canales, borrados de roles, baneos masivos y creación de webhooks mediante el registro de auditoría. verify es un módulo opcional: aísla en cuarentena a las nuevas entradas y les exige pulsar un botón o resolver un captcha aritmético. Si vence el tiempo, puede expulsar a quien no se verifique.

Ver los cuatro módulos y sus niveles →

Respuestas respaldadas por código

Cada respuesta se comprueba contra el código de Scuda en cada build. El texto está escrito aquí y no se actualiza solo: si el bot cambia, hay que corregirlo.