BennyKok/omg.dev

Construir y entregar una aplicación omg.dev

Convierte la descripción del producto del usuario en un resultado funcional y verificado. Mantén el trabajo de configuración con el agente. Pregunta solo sobre las elecciones del producto que cambien materialmente el resultado.

Haz una pregunta por llamada de pregunta y pon como máximo una decisión en ella. Una segunda pregunta en la misma llamada no se muestra al usuario en todos los clientes. Si el usuario no ha dicho qué debe hacer la aplicación, pregúntalo en palabras simples y espera la respuesta. No construyas un producto placeholder en su lugar. Si una pregunta agota el tiempo de espera, vuelve a preguntar una vez en un mensaje normal y termina el turno.

Establecer el proyecto

• En Chat Rápido, llama a omg_create_project una vez con un nombre corto descriptivo. Establece template a expo para una aplicación Expo o móvil universal. La plantilla Expo ya contiene un flujo de tareas funcional con datos almacenados en el teléfono, Expo Router, Liquid Glass, iconos Lucide, soporte web y configuración EAS. Usa el repo.cwd devuelto para cada comando, edición, verificación e implementación. Inspecciona omg_list_repos antes de reintentar una llamada de creación incierta.
• En una sesión de Nuevo Proyecto, el directorio actual ya es el proyecto. Contiene Git, un README y esta habilidad. No crees un segundo proyecto.
• Conserva .git. No sobrescribas una carpeta existente ni muevas el Chat Rápido actual al nuevo proyecto.

Elegir la ruta de entrega

• Para un sitio web, aplicación web o API, usa el runtime omg.dev compatible a menos que el usuario solicite otra plataforma. En un proyecto en blanco, andamia la plantilla React oficial de omg.dev antes de escribir código de producto. El directorio actual ya contiene Git e instrucciones de omg.dev, así que genera en un directorio temporal dentro de él, copia el andamiaje en el proyecto y elimina solo ese directorio temporal:

  scaffold="$(mktemp -d .omg-web-scaffold-XXXXXX)"
  bunx --bun create-omg@latest "$scaffold" --template react-ts --no-install
  cp -a "$scaffold"/. .
  rm -rf "$scaffold"
  bun install
  

  Esta plantilla proporciona @omg-dev/vite-plugin, vibes-build, funciones de servidor, soporte de base de datos y análisis. No sustituyas create-vite ni un andamiaje Vite escrito a mano. Lee https://docs.omg.dev/llms.txt y solo las partes relevantes de https://docs.omg.dev/llms-full.txt antes de elegir paquetes adicionales o contratos de API.

• Para un juego (carreras, arcade, rompecabezas, aprendizaje infantil, palabras, 3D), crea el proyecto con template: "web-game" y lee .agents/skills/omg-web-game-builder/SKILL.md en lugar de diseñar un motor. Su paso 1 viene antes de cualquier edición de código: bun run dev en segundo plano en el puerto 5174, luego omg_expose_port con puerto 5174 y sin expoGo, luego dile al usuario que la vista previa está lista en la tarjeta de abajo. Los pasos de vista previa de Expo en esta habilidad (puerto 8081, expoGo: true) no se aplican a un juego web. Usa template: "expo-game" y .agents/skills/omg-game-builder/SKILL.md solo cuando el usuario pida un juego para instalar en iPhone o Android, o nombre Expo o una aplicación nativa.

• Para una aplicación Expo, comienza desde la plantilla administrada expo y sigue "Aplicación Expo: la ruta rápida" a continuación. Adapta sus pantallas y su almacén de datos en lugar de reconfigurar. Mantén los secretos en rutas de servidor alojadas. Una compilación nativa de producción necesita cualquier servidor implementado en un origen seguro; no trates un túnel sandbox como alojamiento de producción.

• Usa un servidor Metro en vivo para Expo Web y Expo Go en una Computadora en la Nube. Expón su puerto a través de omg_expose_port; no asumas un CLI de Expo global, Xcode, un simulador o herramientas específicas de la máquina.

• Cuando la aplicación sea compatible con Expo Go, omg_expose_port coloca el enlace exps:// de Expo Go en una tarjeta de vista previa en la aplicación omg.dev. Dile al usuario que la vista previa está lista y que la abra desde la tarjeta de abajo. No pegues la URL exps:// sin procesar en tu respuesta; la tarjeta ya la muestra. Pégala solo donde el usuario no pueda ver la tarjeta, como una respuesta enviada con omg_send_to_origin a un canal de mensajería, o cuando el usuario solicite el enlace. No uses túnel Expo, exposición LAN, exp.direct o ngrok. Si Expo Go no puede cargar un módulo nativo requerido, usa una compilación de desarrollo cuando esté autorizado o informa ese límite claramente.

• TestFlight, envío a la App Store, servicios pagos, dominios y cuentas de producción de terceros son acciones de entrega separadas. Hazlos solo cuando el usuario los solicite y la cuenta requerida esté disponible. TestFlight necesita la cuenta de Expo del usuario y una cuenta de Apple Developer paga, pero una compilación en la nube de EAS no necesita Xcode ni una Mac en el sandbox. Usa flujos de inicio de sesión compatibles y nunca solicites contraseñas o tokens en el chat.

Aplicación Expo: la ruta rápida

Un nuevo usuario está esperando. La primera pantalla debe llegar a su teléfono en unos 3 minutos, antes de cualquier trabajo de funcionalidad. Sigue estos pasos en orden:

1. omg_create_project con template: "expo". Si falta node_modules, ejecuta bun install una vez.
2. Vista previa antes de escribir cualquier código. Llama a omg_expose_port con el puerto 8081 y expoGo: true. Luego ejecuta bash scripts/start-expo-preview.sh <expoGo.proxyUrl> 8081 desde el directorio del proyecto, con un tiempo de espera de shell de 240000 ms. Cuando imprima "Sandbox proxy answers: HTTP 200", presenta primero la vista previa web: "Tu aplicación está lista. La tarjeta de abajo la muestra funcionando, y funciona en cualquier dispositivo." Luego menciona el teléfono en una oración: "Para probarla en tu propio teléfono, toca Tu teléfono en la tarjeta." Cuando el resultado de omg_expose_port tenga simulatorAvailable: true, agrega una oración más: "También puedes probarla en un iPhone directamente en la tarjeta: toca Simulador." No prometas el simulador cuando ese campo sea falso o falte. No pegues expoGo.url; la tarjeta lo muestra. Metro recarga la aplicación en cada guardado, por lo que la vista previa sigue tus ediciones a partir de aquí.
3. Escribe las pantallas, en unas pocas ediciones grandes en lugar de una edición pequeña por turno. Reemplaza la pantalla de inicio de la plantilla en src/app/index.tsx; no agregues una segunda ruta de índice.
4. Ejecuta bun run typecheck y corrige lo que informe. También verifica las rutas y falla en una segunda pantalla de inicio o una carpeta app/ raíz. Luego ejecuta bun run check:ui, abre sus PNG y corrige lo que esté mal (ver Paso de compilación 4). No escribas pruebas automatizadas a menos que el usuario lo solicite.
5. Despliega una vez con omg_deploy (ver más abajo). Los datos permanecen en el teléfono, por lo que esta es una compilación web estática.
6. Termina con omg_ship.

No navegues por node_modules, obtengas documentación ni leas el archivo de plantilla por archivo antes de la primera vista previa: el resumen a continuación es suficiente. No escribas tus propios bucles de prueba de navegador o scripts de captura de pantalla: bun run check:ui hace eso. Si no puedes ver imágenes, lee solo su informe de texto.

La plantilla:

• src/app/index.tsx: la pantalla de inicio, y el único archivo para /. Reemplaza su contenido con tu pantalla de inicio. Mantén cada pantalla en src/app/: Expo Router ignora una carpeta app/ raíz mientras exista src/app. Para pestañas, mueve la pantalla de inicio a src/app/(tabs)/index.tsx y elimina src/app/index.tsx, porque ambas responden a / y gana la antigua. El archivo de plantilla tiene un encabezado, una entrada con un botón de agregar, una lista con alternar y eliminar, una tarjeta de error y un botón de recargar. Los estilos están en un StyleSheet al final; las constantes de tema están en la parte superior (INK, CORAL, BACKGROUND, SURFACE, SURFACE_BORDER).
• src/app/_layout.tsx: una pila de Expo Router sin encabezado, dentro de KeyboardProvider. Una nueva pantalla es un nuevo archivo en src/app/ (stats.tsx es /stats). Navega con router.push("/stats") o <Link href="/stats"> de expo-router.
• src/lib/tasks.ts: los datos, almacenados en el teléfono con AsyncStorage (localStorage en la web). tasksApi.list(), create(title), update(id, patch), remove(id). Mantén este archivo. Para cada nuevo tipo de elemento, copia su forma con su propia clave de almacenamiento.
• Iconos: lucide-react-native, por ejemplo <Plus color={CORAL} size={22} />. Superficies de vidrio: GlassView de expo-glass-effect.
• Colores: establece cada constante de tema desde el diseño antes de diseñar las pantallas. Las tarjetas, filas y hojas usan el color de superficie del diseño. El SURFACE blanco translúcido de la plantilla solo se adapta a su iniciador claro; si se deja en un diseño oscuro o de color, cada tarjeta sale blanca. Usa GlassView solo donde el diseño muestre vidrio esmerilado. En Android no dibuja vidrio, así que asígnale un color de fondo.
• Áreas seguras: envuelve cada pantalla en SafeAreaView de react-native-safe-area-context con edges={["top", "bottom"]}, o usa useSafeAreaInsets(). Nunca importes SafeAreaView de react-native: es solo para iOS, por lo que en Android el encabezado va debajo de la barra de estado y la barra de pestañas debajo de la barra de gestos.
• Teclado: coloca las pantallas con una entrada de texto en KeyboardAwareScrollView de src/lib/keyboard (bottomOffset={24}, keyboardShouldPersistTaps="handled"), como hace la plantilla. Para un campo fijado en la parte inferior, usa KeyboardStickyView del mismo archivo. Impórtalos de src/lib/keyboard, nunca de react-native-keyboard-controller directamente: su gemelo .web.tsx mantiene la exportación web estática funcionando. No uses KeyboardAvoidingView de React Native: en iOS la pantalla se mueve después del teclado, lentamente.

Datos: almacénalos en el teléfono por defecto, con el patrón tasks.ts. Usa datos alojados solo cuando el usuario solicite cuentas o datos compartidos entre personas. Luego agrega inicio de sesión con @omg-dev/sdk y colecciones .scoped("user") en schema.ts. Nunca llames a /api/... con un fetch sin procesar: una colección alojada responde a un teléfono anónimo con 401 Authentication required.

Para datos alojados, instala la última versión de @omg-dev/sdk y despliega el backend antes de probar sus datos compartidos en Metro. Mantén .omg/project.json en el directorio del proyecto. La vista previa web alojada usa esa identidad de aplicación registrada y firma a su propietario a través del SDK. Usa <VibesAuthProvider> y solicitudes del SDK. No agregues un inicio de sesión de vista previa separado, reenvíes cookies del panel de control ni reemplaces los permisos de la aplicación del usuario. Un teléfono físico aún necesita el inicio de sesión normal de la aplicación y el origen del backend implementado.

Reglas de Metro: usa solo los puertos 8081 a 8099, porque los enlaces de Expo Go funcionan solo en ese rango. Inicia Metro solo con el script; npx y ss no están instalados en todas las Computadoras.

Bloques de construcción (Expo)

La plantilla incluye ayudantes probados en src/kit/. Impórtalos; no los reescribas. Funcionan en iOS, Android y web. Cada archivo comienza con un comentario que muestra su uso.

• overlay.tsx: useConfirm() y useSheet(). <OverlayProvider> ya está en _layout.tsx. Usa if (await confirm({ title, destructive: true })) para cada eliminación o confirmación. Alert.alert con botones no hace nada en la web. Usa useSheet().open(node) para hojas y formularios. No apiles componentes Modal: el segundo se dibuja detrás del primero en la web.
• ActionRow.tsx: una fila presionable con una acción de eliminación u otra a su lado. Un botón anidado dentro de una fila presionable también activa la fila en la web.
• image.ts: await toPersistentImage(pickerAsset). Llama al selector con base64: true, quality: 0.5 y almacena la cadena devuelta. Una URI del selector en la web es una URL blob: que desaparece después de una recarga.
• use-timer.ts: usePersistedTimer(key, durationMs) con start, pause, resume, reset y formatClock. Almacena la hora de finalización, por lo que una recarga no la restablece. Úsalo para cada temporizador o cuenta regresiva.
• use-viewport.ts: useViewport() y useIsWide(). En la exportación web estática, useWindowDimensions() puede dar un ancho de 0 en el primer renderizado. Prefiere flex y maxWidth; usa el hook solo cuando necesites un número.

Datos compartidos entre personas (una lista compartida, un intercambio, un grupo): usa la ruta alojada de @omg-dev/sdk en "Datos" arriba. No escribas un servidor local. Si un servidor local es inevitable, responde OPTIONS y envía estos encabezados en cada respuesta: Access-Control-Allow-Origin con el Origin de la solicitud (o *), Access-Control-Allow-Methods: GET,POST,PUT,PATCH,DELETE,OPTIONS, y Access-Control-Allow-Headers: content-type,authorization. Un PUT o DELETE faltante falla solo en el navegador.

Compilación

1. Convierte la solicitud en una pequeña condición de finalización observable. Toma decisiones visuales y técnicas razonables cuando el usuario no las haya especificado.
2. Andamia dentro del directorio del proyecto. Para una plantilla Expo administrada, instala sus dependencias fijadas y conserva .omg/template.json; no lo reemplaces con otro iniciador. Para un proyecto en blanco, instala las dependencias y la configuración documentadas actuales. No instales un CLI de omg.dev retirado ni pidas al usuario tokens de infraestructura; las herramientas de runtime proporcionan la credencial de la Nube.
3. Implementa la ruta real. Si el producto necesita datos compartidos, autenticación, cargas o trabajo de servidor, usa las API alojadas documentadas y verifica la persistencia y el control de acceso. No reemplaces el comportamiento compartido solicitado con datos simulados o almacenamiento solo del navegador.
4. No escribas pruebas automatizadas a menos que el usuario las solicite. Verifica con la autocomprobación en su lugar: ejecuta bun run typecheck, luego bun run check:ui. La comprobación construye la exportación web, inicia el script server o backend de la aplicación si lo hay, abre cada ruta a 390x844 y guarda un PNG por ruta en .omg/ui-check/. Informa páginas en blanco, límites de error, errores de consola, solicitudes fallidas, un servidor bloqueado y botones o enlaces que otro elemento cubre (por ejemplo, un botón "Agregar" debajo de una barra de pestañas). Luego abre cada PNG con el visor de imágenes y compáralo con la solicitud y cualquier referencia de diseño. Corrige lo que esté mal y ejecuta la comprobación nuevamente hasta que el informe esté limpio. Indica qué superficie verificaste; una ejecución web no es prueba del comportamiento nativo.
5. Actualiza el README con el propósito del producto, el comando de ejecución local, la arquitectura y las notas de entrega. Confirma el código fuente terminado localmente para que las sesiones posteriores de omg.dev comiencen desde una línea base completa.

Inicio de sesión para una aplicación web alojada

omg.dev es dueño del inicio de sesión para aplicaciones en <slug>.omgs.app. Nunca construyas un formulario de inicio de sesión, un campo de contraseña ni tu propio almacén de sesión.

• Privado (predeterminado): cada visitante inicia sesión en omg.dev antes de que se abra la aplicación. La aplicación no necesita UI de inicio de sesión.
• Público con inicio de sesión: usa esto cuando el usuario quiera una página de aterrizaje para visitantes. Establece la aplicación como public con...