Qué es el registro

Cada clase recurrente de bug en el historial de FlareWatch se ha destilado en una salvaguarda numerada: una regla de un párrafo, una justificación y un puntero al lugar en el código que la aplica. Se añaden nuevas salvaguardas cuando surge una clase de bug o patrón que debe prevenirse de repetirse.

El registro es un documento de trabajo, no material de marketing. Su propósito es mantener al equipo — y al bucle de revisión audit-first que el equipo utiliza — honesto acerca de qué reglas se aplican dónde. El registro se referencia desde comentarios de código en línea (por ejemplo, // Safeguard 24) para que un lector de cualquier archivo individual pueda encontrar la regla que rige las líneas circundantes.

Esta página es el resumen público. El registro completo vive en el repositorio de fuentes junto al código que rige. El propósito aquí es darle a un investigador de seguridad, revisor de subvenciones o contribuidor prospectivo una idea de las categorías que cubre el registro y el tipo de disciplina que aplica.

Por qué un registro

Un registro de salvaguardas solo se justifica si previene el mismo bug dos veces. El historial del registro es la respuesta:

Cada salvaguarda nombra el bug que previene. Una regla sin un incidente recordado detrás de ella no es una salvaguarda, es una preferencia de estilo. Las preferencias de estilo pertenecen a las reglas de lint, no al registro.
Las salvaguardas se referencian desde el código, no solo desde la documentación. Un cambio de código que viola una salvaguarda se lee como una bandera en el momento de la revisión porque el número de salvaguarda está en los comentarios circundantes.
Algunas medidas de seguridad se aplican automáticamente. Un subconjunto se aplica mediante reglas ESLint o scripts de shell que se ejecutan en CI. El resto se basa en la disciplina del autor más el patrón de revisión prioritaria de auditoría, que ha funcionado bien en la práctica.
El registro se mantiene honesto mediante pruebas. Varias medidas de seguridad están fijadas por pruebas de regresión que leen archivos fuente como cadenas de texto y aseguran que no aparezcan anti-patrones. La fragilidad es la característica: un refactorizado futuro que revierta a un anti-patrón hace fallar la prueba antes de que la regresión llegue a producción.

Categorías

El registro se organiza por dominio. Las categorías a continuación son estables; medidas de seguridad específicas dentro de cada una se añaden conforme se descubren nuevos modos de fallo.

Categoría	Qué cubre
Autenticación y autorización	Punto de control único para validación de sesión, verificaciones de propiedad por billetera en cada ruta, rechazo de tokens cruzados entre tokens de acceso y actualización, control de acceso de rutas administrativas.
Integridad de datos	Normalización de direcciones, contratos de conversión de unidades en límites productor/consumidor, disciplina en constructores de claves, y reglas contra la fusión silenciosa de fallos en valores cero.
Lecturas en cadena	Reglas de implementación única para cualquier valor leído de un contrato inteligente, resolución de direcciones de contrato desde el registro en cadena, y reglas contra la duplicación de lógica de recompensas.
Precisión de visualización	Formato centralizado de números, divisas y fechas; seguridad nula en toda visualización numérica; disciplina en el etiquetado de APR vs. APY; disciplina en tasa fiscal como tasa efectiva.
Alertas y notificaciones	Fuente única de verdad para evaluación de alertas entre cliente y servidor; listas de permisos explícitas para qué alertas se propagan a billeteras monitoreadas; reglas de supersesión para que una alerta de "recompensas recibidas" cancele una alerta obsoleta de "recompensas disponibles"; sincronización de descarte entre dispositivos.
Persistencia y caché	Reglas para cuándo el almacén canónico es el backend de clave-valor versus localStorage; disciplina en migraciones; caché del service worker con alcance de despliegue; exclusión dinámica explícita para rutas que leen estado en vivo.
UI y ciclo de vida	Compuertas de disponibilidad de página, pisos monótonos que evitan que ceros transitorios desplacen saldos conocidos, y reglas para renderizado esquelético durante ventanas de carga fría.
Proceso y herramientas	Reglas para consentimiento explícito de lanzamiento de características, ejecuciones de pruebas completas en cambios de superficie de alertas, registro estructurado en código del lado del servidor, y disciplina de revisión contra correcciones de estilo atajo.

Un puñado de reglas representativas

Estos son resúmenes públicamente seguros de salvaguardas que ilustran el carácter del registro. Están parafraseados y abreviados; el texto canónico se encuentra junto al código.

Fuente única de verdad para lecturas en cadena

Cualquier valor leído de un contrato inteligente —recompensas reclamables, saldos, estado de stake, datos de época, precios— es computado por exactamente una función en la capa de servicios. Cada característica que necesita ese valor importa la misma función. Si dos funciones computan el mismo valor, una de ellas está mal; la regla es eliminarla, no agregar una tercera.

Punto único de estrangulamiento para validación de sesión

Cada ruta autenticada en FlareWatch valida cookies de sesión a través de un único auxiliar. Ningún manejador de ruta verifica tokens de sesión de forma independiente. Este invariante es lo que hace que la revocación del lado del servidor sea universal —no hay puertas traseras que eluden la verificación.

Control de propiedad por billetera en ambos lados

Las rutas por billetera verifican la propiedad del lado del servidor, no del lado del cliente. La auditoría original estableció la regla porque trabajos anteriores habían cerrado las compuertas del lado del cliente pero dejaron los endpoints del lado del servidor completamente sin protección. Las dos mitades ahora se rastrean como entregables explícitas separadas —cerradas en el cliente, cerradas en el servidor— para evitar que ese modo de fallo se repita.

Usar formateadores centralizados, nunca en línea

Todo el formato de números, moneda y fecha pasa por un pequeño conjunto de auxiliares centralizados. Ningún componente formatea en línea. La regla no tiene nada que ver con estilo: cuando una definición de configuración regional o moneda única cambia, todas las superficies en la aplicación se actualizan con ella. La divergencia entre superficies es silenciosa y difícil de detectar hasta que un usuario lo nota.

Las conversiones de unidades están documentadas en ambos extremos

Cuando dos partes del sistema intercambian valores cuya unidad podría ser ambigua (segundos vs. milisegundos, decimal vs. porcentaje, direcciones en minúsculas vs. direcciones con suma de verificación), la convención se documenta tanto en el productor como en el consumidor. Un comentario en solo un extremo se deteriora; solo un contrato de límite que se valida en ambos extremos sobrevive a una refactorización.

Una implementación por acción del usuario

Cada acción iniciada por el usuario —agregar una cartera monitoreada, cambiar una tasa fiscal, descartar una alerta, cerrar sesión— tiene exactamente una implementación. La regla existe porque las acciones desencadenadas desde diferentes partes de la interfaz de usuario solían divergir de formas sutiles: un punto de entrada borraría una caché, otro no lo haría, y resultaría una clase de errores "valor obsoleto después de la operación X".

Modos de fallo que deben ser ruidosos

Algunos modos de fallo son silenciosos por naturaleza —una recompensa mal clasificada, una falta de coincidencia de unidad que convierte una notificación en una no-operación, un registro de descarte que nunca llega al almacén clave-valor. Cuando es posible, el registro requiere que los productores de estos valores declaren su contrato lo suficientemente alto para que un cambio futuro que lo viole falle ruidosamente, en las pruebas, antes de llegar a producción.

Cómo evoluciona el registro

Nuevas salvaguardas. Agregadas cuando una clase de error se repite o un solo error cuesta lo suficiente para justificar una regla permanente.
Salvaguardas reemplazadas. Mantenidas en el registro con un marcador "reemplazado" y un puntero al reemplazo, de modo que las referencias históricas en el código sigan siendo interpretables.
Promovidas desde notas de trabajo. Algunas salvaguardas comienzan como reglas informales en un documento de traspaso de sesión y se promueven al registro una vez que han demostrado su valor.
Revisión trimestral. Las excepciones de lint temporales y los marcadores "por hacer el próximo trimestre" se verifican en una cadencia trimestral. Cualquier cosa que haya envejecido se resuelve o se extiende explícitamente.

Por qué se publica esto

FlareWatch publica esta descripción general, en lugar del registro interno completo, por dos razones.

El registro interno contiene detalles a nivel de código (rutas de archivo, nombres de esquemas de almacén clave-valor, marcas de tiempo de incidentes) que son útiles para el equipo y para un revisor de seguridad con acceso al código, pero no es apropiado publicar sin ese acceso.
Las categorías y la disciplina son la historia real. Un revisor de subvención o un investigador de seguridad que evalúe FlareWatch desea saber qué tipo de proyecto es, cuán en serio toma la corrección y cómo se ve su ciclo de trabajo —no qué archivo contiene la regla #91.

Los investigadores que deseen discutir una salvaguarda específica, proponer una nueva o reportar una brecha son bienvenidos a comunicarse en [email protected].

Lecturas complementarias

Arquitectura — cómo se construye FlareWatch.
Características de Seguridad — autenticación, autorización, encabezados, historial de auditoría.