¿Qué hace Ingeniería de Frontend?
Lee anti-ai-writing antes de redactar textos, comentarios o informes. Lee las instrucciones del repositorio, pantallas y componentes existentes, tokens de diseño, versiones de framework/dependencias, enrutamiento, contratos de datos y convenciones de prueba. Usa el stack y utilidades existentes; verifica APIs desconocidas contra la documentación oficial de esa versión. Preserva el trabajo no relacionado y el comportamiento establecido del producto.
Establecer el Propósito y Diseño de la Pantalla
Identifica la audiencia, la tarea del usuario, la acción principal, la jerarquía de contenido, los estados requeridos y los criterios de aceptación. Usa primero los diseños proporcionados y los patrones de producto existentes. Para interfaces nuevas sustanciales, aclara los requisitos faltantes consecuentes y usa agent-planning cuando un plan sea útil. No requieras una ceremonia de diseño para un cambio pequeño y entendido.
Cuando se necesita una nueva dirección visual, estudia referencias relevantes y traduce su jerarquía útil, densidad, navegación y principios de interacción al lenguaje propio del producto. No copies marcas registradas, texto, activos o diseños exactos. Registra suficientes decisiones de diseño para guiar la implementación sin inventar un sistema de diseño completo para una sola pantalla.
Usa tipografía, espaciado, colores, bordes redondeados y énfasis coherentes de los tokens del proyecto. Prioriza la acción e información del usuario en lugar de usar por defecto secciones de héroe genéricas, tarjetas uniformes, espaciado excesivo o degradados decorativos. Estos patrones pueden ser apropiados cuando el producto los requiera; no impongas prohibiciones estéticas. Usa contenido realista, incluyendo etiquetas largas y datos dispersos/densos. Elimina detalles de implementación no relacionados del texto del producto. Mantén todos los controles expuestos funcionales o claramente identificados como no disponibles; nunca disfraces un marcador de posición como una característica funcional.
Implementar Componentes y Estado Claros
Para contratos frontend/backend cambiados, usa api-design y preserva los consumidores compatibles. No infieras un contrato backend a partir de componentes ficticios.
Usa writing-clean-simple-code para responsabilidades enfocadas y abstracciones justificadas. Prefiere composición y APIs de componentes establecidas sobre una gran matriz de banderas no relacionadas. Divide por responsabilidad, no por recuentos arbitrarios de líneas. Mantén la propiedad de datos y presentación clara sin forzar un contenedor o hook separado para cada componente.
Coloca el estado donde se gestiona: estado de interacción local, estado compartido, estado de URL para vistas navegables/compartibles, y herramientas de estado de servidor existentes para datos remotos. Evita estado derivado duplicado y booleanos contradictorios. No introduzcas un almacén global solo para evitar algunos props. Preserva la identidad estable de los elementos, la navegación del historial, los enlaces profundos y los contratos de renderizado/hidratación del framework cuando sea relevante.
Maneja los estados aplicables de carga, vacío, éxito, error, deshabilitado, pendiente y permiso. Distingue sin datos de resultados filtrados. Preserva los datos ingresados después de errores recuperables, explica cómo proceder y previene envíos duplicados. Para actualizaciones optimistas, considera fallos, cambios concurrentes, respuestas obsoletas y reconciliación. Rastrea la propiedad de cancelación antes de cancelar solicitudes compartidas. No uses controles ocultos como autorización; la aplicación en el lado del servidor sigue siendo necesaria.
Hacer el Diseño y la Interacción Inclusivos
Lee accessibility and responsive checks. Prefiere HTML semántico nativo y primitivas accesibles probadas. La interacción personalizada debe implementar su contrato completo de teclado, enfoque y estado. Las etiquetas, errores y comentarios de estado deben ser comprensibles sin depender del color o la animación.
Elige puntos de interrupción donde el contenido los necesite y respeta los tokens de diseño existentes. Usa diseños flexibles, límites de ancho apropiados y activos responsivos. Verifica vistas estrechas y anchas, zoom, texto largo, estados vacíos y desbordamiento. Preserva contenido y acciones significativos en pantallas pequeñas en lugar de ocultarlos para que quepa en una captura de pantalla.
Preservar Seguridad y Rendimiento
Trata el contenido remoto y las URLs como no confiables. Usa renderizado seguro del framework; desinfecta solo a través de mecanismos probados cuando se requiera HTML enriquecido. No expongas secretos o registros privados en paquetes del cliente, telemetría o mensajes de error. Limita los datos en caché a identidad/inquilino y límpialos o invalíidalos en cambios de contexto relevantes.
Evita cascadas de fetch innecesarias, trabajo repetido costoso, dependencias demasiado grandes y cambios de diseño. Usa las convenciones de activos, renderizado y carga del framework. Optimiza a partir de evidencia medida y presupuestos del producto; no agregues memorización, virtualización o división de código mecánicamente. Los resultados de laboratorio y el rendimiento en campo son evidencia diferente y deben reportarse por separado.
Verificar el Resultado Renderizado
Usa test-authoring para la cobertura de comportamiento. Ejecuta las comprobaciones relevantes del repositorio e inspecciona la aplicación en un navegador disponible con datos realistas. Ejercita las acciones afectadas y transiciones de estado, navegación por teclado, enfoque, validación, diseño responsivo y objetivos de navegador aplicables. Inspecciona fallos de consola y red relevantes para el cambio. Las capturas de pantalla establecen la apariencia, no la corrección de la interacción; los escaneos automatizados de accesibilidad no establecen conformidad.
Compara la salida renderizada con los diseños aceptados o las pantallas establecidas del proyecto. Corrige problemas descubiertos de recorte, espaciado, contraste o interacción y vuelve a verificar los estados afectados. No ejecutes acciones destructivas en vivo solo para verificar una UI; usa componentes seguros o un entorno de prueba autorizado. Si el acceso al navegador no está disponible, indica exactamente qué permanece sin verificar en lugar de llamar validada visualmente a la interfaz.
Reporta cambios reales, flujos/puertos de vista probados y limitaciones materiales. Usa code-review cuando se justifique, esté disponible y sea autorizada una revisión independiente. Para commit, push y publicación, usa git-delivery autorizado.