ali-ali18/agent-skills

Desarrollo de Roblox con Rojo (Luau)

Construyes experiencias de Roblox como archivos de texto plano dentro de la VM, las compilas a un archivo de lugar con Rojo y, solo cuando se te pida, subes ese archivo a un lugar de PRUEBA a través de Roblox Open Cloud. Responde al usuario en su idioma (pt-BR por defecto).

0. Reglas básicas

• Nunca imprimas, hagas eco, registres o escribas una clave API. Usa únicamente el marcador de bóveda {{secret:<nombre>}} dentro de una llamada a shell; el entorno reemplaza el valor y lo oculta en la salida.
• Publica SOLO en el lugar de prueba que el usuario te haya proporcionado (universeId + placeId). Nunca adivines IDs ni reutilices IDs de otra conversación. Si el usuario da un lugar en vivo/producción, detente y confirma que sea intencional.
• El versionType por defecto es Saved (una nueva versión en el historial de versiones, no en vivo). Usa Published solo cuando el usuario pida explícitamente publicar en vivo.
• ¿Faltan universeId, placeId o el nombre del secreto? Pregunta con propose_questionnaire (un formulario breve). ¿Falta el secreto por completo? Llama a secret_request (nombre sugerido: ROBLOX_API_KEY). Nunca pidas la clave en el chat.

1. Instalar Rojo (una vez por VM)

Versión fijada: Rojo 7.7.1 (revisa https://github.com/rojo-rbx/rojo/releases para versiones 7.x más recientes e informa al usuario antes de cambiar la fijación). Instala el binario precompilado para Linux x86_64 en la carpeta personal, sin necesidad de root:

mkdir -p "$HOME/.local/bin" && cd "$(mktemp -d)"
curl -fsSL -o rojo.zip https://github.com/rojo-rbx/rojo/releases/download/v7.7.1/rojo-7.7.1-linux-x86_64.zip
unzip -o rojo.zip && install -m 0755 rojo "$HOME/.local/bin/rojo"
export PATH="$HOME/.local/bin:$PATH"
rojo --version   # esperado: rojo 7.7.1

Primero verifica con command -v rojo; omite la instalación si ya imprime 7.x. En una VM ARM usa el assets linux-aarch64. Alternativa cuando ya hay un gestor de herramientas: rokit add rojo-rbx/rojo && rokit install. No ejecutes instaladores desde ninguna otra URL.

2. Estructura del proyecto

my-game/
  default.project.json
  src/
    server/     -> ServerScriptService.Server   (código solo del servidor)
    client/     -> StarterPlayer.StarterPlayerScripts.Client
    shared/     -> ReplicatedStorage.Shared      (módulos que ambos lados pueden requerir)

default.project.json:

{
  "name": "my-game",
  "tree": {
    "$className": "DataModel",
    "ServerScriptService": { "Server": { "$path": "src/server" } },
    "ReplicatedStorage": { "Shared": { "$path": "src/shared" } },
    "StarterPlayer": {
      "$className": "StarterPlayer",
      "StarterPlayerScripts": { "Client": { "$path": "src/client" } }
    }
  }
}

Nombres de archivo que Rojo entiende: init.server.luau (un Script para la carpeta), *.server.luau (Script), *.client.luau (LocalScript), *.luau simple (ModuleScript), init.luau (la carpeta se convierte en un ModuleScript). Añade un .gitignore con *.rbxl, *.rbxlx, Packages/. Crea el proyecto solo cuando la carpeta no tenga un default.project.json; nunca sobrescribas una estructura existente, adáptate a ella.

3. Convenciones de código

• Luau con --!strict al inicio de cada archivo. Tipifica las firmas de funciones y las tablas exportadas.
• Una responsabilidad por ModuleScript, que devuelve una tabla. Sin globales, sin _G, sin shared. Usa require con referencias directas (script.Parent.Module o ReplicatedStorage.Shared.Module).
• Mantén los puntos de entrada pequeños: un init.server.luau y un punto de entrada del cliente que require servicios/controladores y los inicie en orden.
• Obtén los servicios al inicio: local Players = game:GetService("Players"). Prefiere task.wait, task.spawn, task.delay sobre wait/spawn/delay. Desconecta las conexiones por jugador en Players.PlayerRemoving.
• Nunca confíes en el cliente. El servidor posee el estado del juego (moneda, inventario, daño, teletransportes, progresión). El cliente solo envía intención y renderiza resultados.

Lista de verificación de seguridad para Remotos

• Crea instancias de RemoteEvent/RemoteFunction bajo ReplicatedStorage desde el servidor con un nombre fijo; nunca las crees desde el cliente.
• En cada OnServerEvent/OnServerInvoke: valida la cantidad y tipos de argumentos (typeof), limita rangos, rechaza NaN/inf, acota la longitud de cadenas, verifica que el jugador esté permitido (cooldown, propiedad, distancia, vivo).
• Limita la tasa por jugador (token bucket o marca de tiempo de última llamada). Un remoto nunca debe transportar un precio, cantidad de daño o cualquier valor que el cliente pueda elegir en su beneficio.
• RemoteFunction: nunca uses InvokeClient (un cliente malicioso puede bloquear el hilo del servidor).
• DataStore: envuelve en pcall, reintenta con retroceso, guarda en PlayerRemoving y game:BindToClose; bloquea por sesión los datos valiosos.
• Los secretos y parámetros de ajuste solo viven en ServerScriptService/ServerStorage, nunca en ReplicatedStorage.

4. Compilación

rojo build default.project.json -o place.rbxl
ls -l place.rbxl

Corrige primero los errores de compilación (falta $path, JSON malo, nombres duplicados). No hagas commit de place.rbxl. selene / stylua --check son opcionales; no los instales a menos que se te pida. Un lugar construido solo a partir de archivos es un esqueleto de scripts: los assets, el terreno y la interfaz hechos en Studio viven en el lugar que ya existe, por lo que subir REEMPLAZA el contenido de la versión destino. Esto es exactamente por qué el destino debe ser un lugar de prueba.

5. Publicar mediante Open Cloud (lugar de prueba)

Endpoint (Publicación de Lugares de Roblox Open Cloud, universos v1):

POST https://apis.roblox.com/universes/v1/{universeId}/places/{placeId}/versions?versionType=Saved|Published

• Cabecera x-api-key: <key>; Content-Type: application/octet-stream para .rbxl (binario), application/xml para .rbxlx.
• Cuerpo: el archivo de lugar sin procesar. Respuesta exitosa: { "versionNumber": 7 }.
• La clave API necesita el permiso universe-places con Escritura en la experiencia destino (creado en el Panel de Creador).
• Solo HTTPS. La API no actualiza algunos tipos de instancia (EditableImage, EditableMesh, PartOperation, SurfaceAppearance, BaseWrap): informa al usuario que publique esos desde Studio.
• Documentación: https://create.roblox.com/docs/en-us/cloud/guides/usage-place-publishing

Ejecútalo con el marcador de bóveda (el marcador va dentro del comando shell, nunca en el texto de tu mensaje):

curl -sS -X POST \
  "https://apis.roblox.com/universes/v1/$UNIVERSE_ID/places/$PLACE_ID/versions?versionType=Saved" \
  -H "x-api-key: {{secret:ROBLOX_API_KEY}}" \
  -H "Content-Type: application/octet-stream" \
  --data-binary @place.rbxl

Reemplaza $UNIVERSE_ID y $PLACE_ID con los números que dio el usuario, y el nombre del secreto con el nombre real de la bóveda (secret_list solo muestra nombres). Maneja los errores sin exponer la clave: 401/403 = clave inválida o falta el permiso/experiencia; 404 = par universo/lugar incorrecto; 400 = archivo malo (recompilar); 429 = espera y reintenta una vez. Cita solo el estado HTTP y el cuerpo de la respuesta, que nunca contiene la clave.

6. Informe

Termina cada tarea con un breve informe en el idioma del usuario:

1. Qué cambió (archivos y comportamiento), en palabras sencillas.
2. El resultado de rojo build y, si se publicó, el versionNumber, el versionType usado y que fue al lugar de prueba <placeId>.
3. Cómo probar en Studio: abre el lugar de prueba, abre el Historial de Versiones para cargar la nueva versión Guardada, presiona Reproducir (F5) y las cosas exactas que probar con los mensajes de Salida esperados.
4. Qué NO hiciste (publicación en vivo, assets o terreno que necesiten Studio).

7. Opción de sincronización local

Para edición en vivo, el usuario puede ejecutar rojo serve en su propia computadora con el plugin de Rojo para Studio (https://rojo.space/docs/v7/getting-started/installation/). No se puede acceder a la VM desde su Studio, por lo que dentro de la VM quédate con la compilación y la subida por Open Cloud.