Guía operativa · Stadium Assistant

Protocolo completo después de reiniciar la computadora

Cómo volver a preparar PowerShell y Node.js para continuar exactamente con las pruebas del Walking Skeleton y el diagnóstico de los errores 503.

Windows + PowerShell AWS us-east-1 Proyecto DEV

13pasos

3ventanas para diagnóstico

1protocolo reutilizable

Prompt original

Punto exacto del chat

“ok, reinicie la maquina y obvio, se cerro powershel y asumo que se desconecto de las plataformas y de todo lo que estaba conectado, ya que le dí los comandos indicados en Fase 1 — Identificar exactamente la causa de los diez 503, / Paso 1. Revisar los logs de Lambda y en el Paso 2 y No me arrojo nada, solo me volvio a aparecer la linea de comandos. Que necesito hacer o cual es el protocolo o proceso que tengo que hacer en Powershell y/o node para volverme a conectar a todo?”

Respuesta

No se desconectaron AWS, Lambda, API Gateway, CloudWatch ni OpenAI

No se desconectaron AWS, Lambda, API Gateway, CloudWatch ni OpenAI. Al reiniciar la computadora se cerraron únicamente las sesiones locales de PowerShell, los procesos de Node.js y las variables que existían solo en memoria.

Lo que sigue existiendo

Lambda sa-dev-orchestrator-chat.
API Gateway w7jtrco599.
Stage /dev.
CloudWatch Logs.
Variables configuradas dentro de Lambda.

Lo que debes volver a preparar localmente

La sesión de PowerShell.
Procesos de Node.js.
$DevBaseUrl, $ApiId, $FunctionName y demás variables de PowerShell.
$env:OPENAI_API_KEY y $env:OPENAI_MODEL cuando hagas pruebas locales.

Importante: un comando aws logs tail --since 30m sin --follow termina y regresa a la línea de comandos si no encuentra eventos en ese periodo. Eso no significa que AWS se haya desconectado.

Paso 1

Abrir PowerShell

Primero confirma que las herramientas locales siguen disponibles.

Completado

Ejecuta una línea a la vez

aws --version
node -v
npm -v

Valores confirmados en este ambiente:

AWS CLI: versión 2.
Node.js: v24.16.0.
npm: 12.0.1.

Paso 2

Ir al proyecto

Vuelve a colocar PowerShell en la carpeta de trabajo.

Completado

Entrar al Walking Skeleton

cd "C:\Users\gerar\Documents\VSFRepositoryLocal\Dev_Platforms\NodeProjects\Project_SA_WalkingSkeleton_V2.0"

Confirma que estás en la carpeta correcta:

Validar ubicación y archivos

Get-Location
Get-ChildItem

Paso 3

Volver a definir el contexto del proyecto

Estas variables existían en la sesión anterior y se perdieron al cerrar PowerShell.

Completado

Contexto DEV

$AwsProfile = "sa-dev"
$AwsRegion = "us-east-1"
$AwsAccountId = "TU_AWS_ACCOUNT_ID"
$ApiId = "w7jtrco599"
$FunctionName = "sa-dev-orchestrator-chat"
$DevBaseUrl = "https://w7jtrco599.execute-api.us-east-1.amazonaws.com/dev"
$LambdaLogGroup = "/aws/lambda/sa-dev-orchestrator-chat"
$ApiLogGroup = "/aws/apigateway/sa-dev-http-api"
$ProjectPath = "C:\Users\gerar\Documents\VSFRepositoryLocal\Dev_Platforms\NodeProjects\Project_SA_WalkingSkeleton_V2.0"

Publicación web: el valor de $AwsAccountId se deja como marcador para no publicar un identificador de cuenta en una página pública. En tu PowerShell local usa el valor de tu cuenta.

Revisar el contexto cargado

[PSCustomObject]@{
  AwsProfile     = $AwsProfile
  AwsRegion      = $AwsRegion
  ApiId          = $ApiId
  FunctionName   = $FunctionName
  DevBaseUrl     = $DevBaseUrl
  LambdaLogGroup = $LambdaLogGroup
  ApiLogGroup    = $ApiLogGroup
  ProjectPath    = $ProjectPath
}

Paso 4

Verificar que el perfil AWS sigue registrado

Reiniciar Windows no elimina los perfiles guardados por AWS CLI.

Completado

Los perfiles configurados con AWS CLI normalmente permanecen en los archivos de configuración y credenciales del usuario, por lo que reiniciar Windows no los elimina. El parámetro --profile selecciona explícitamente uno de esos perfiles.

Listar perfiles

aws configure list-profiles

Debe aparecer:

Resultado esperado

sa-dev

Después:

Revisar configuración del perfil

aws configure list --profile $AwsProfile

Debe mostrar región y origen de las credenciales. La clave aparece parcialmente oculta.

Paso 5

Confirmar la identidad AWS

Comprueba que el perfil realmente puede autenticarse contra AWS.

Completado

STS GetCallerIdentity

aws sts get-caller-identity `
--profile $AwsProfile `
--region $AwsRegion

Debe devolver un objeto con UserId, Account y Arn. Si este comando responde correctamente, PowerShell vuelve a tener comunicación válida con AWS mediante el perfil sa-dev.

Paso 6

Verificar la Lambda

Confirma el estado real de la función desplegada.

Completado

Configuración Lambda

aws lambda get-function-configuration `
--function-name $FunctionName `
--query "{
FunctionName:FunctionName,
FunctionArn:FunctionArn,
Runtime:Runtime,
Handler:Handler,
Timeout:Timeout,
MemorySize:MemorySize,
State:State,
LastUpdateStatus:LastUpdateStatus
}" `
--profile $AwsProfile `
--region $AwsRegion

Debe mostrar:

Resultado esperado

FunctionName: sa-dev-orchestrator-chat
Runtime: nodejs24.x
Handler: index.handler
Timeout: 15
MemorySize: 512
State: Active
LastUpdateStatus: Successful

Paso 7

Verificar API Gateway

Confirma que la HTTP API continúa desplegada.

Completado

Consultar API Gateway

aws apigatewayv2 get-api `
--api-id $ApiId `
--query "{Name:Name,ApiId:ApiId,ApiEndpoint:ApiEndpoint,ProtocolType:ProtocolType}" `
--profile $AwsProfile `
--region $AwsRegion

Resultado esperado:

API confirmada

Name: HTTP API MVP SAVSF
ApiId: w7jtrco599
ApiEndpoint: https://w7jtrco599.execute-api.us-east-1.amazonaws.com
ProtocolType: HTTP

Paso 8

Probar `/health`

Comprueba de punta a punta API Gateway → Lambda.

Completado

Health check con trace_id

$HealthTraceId = "restart-health-" + [guid]::NewGuid().ToString("N")

$HealthResult = Invoke-RestMethod `
-Uri "$DevBaseUrl/health" `
-Method GET `
-Headers @{"x-trace-id" = $HealthTraceId}

$HealthResult

Debe mostrar valores como:

Resultado esperado

ok : True
service : stadium-assistant-orchestrator
environment : dev
version : ws-1.0.0
trace_id : restart-health-...

Compara el trace enviado contra el recibido:

Validar trace_id

$HealthTraceId -eq $HealthResult.trace_id

Debe devolver:

Resultado

True

Paso 9

Recuperar los logs anteriores de los errores 503

Los errores probablemente ocurrieron hace más de 30 minutos; por eso una búsqueda limitada a --since 30m puede no mostrar nada.

Completado

Buscar eventos `chat_failed`

Lambda · últimos 7 días

aws logs tail $LambdaLogGroup `
--since 7d `
--filter-pattern '"chat_failed"' `
--format short `
--profile $AwsProfile `
--region $AwsRegion

Buscar rate limits upstream

upstream_rate_limited

aws logs tail $LambdaLogGroup `
--since 7d `
--filter-pattern '"upstream_rate_limited"' `
--format short `
--profile $AwsProfile `
--region $AwsRegion

Buscar errores del servicio upstream

upstream_service_error

aws logs tail $LambdaLogGroup `
--since 7d `
--filter-pattern '"upstream_service_error"' `
--format short `
--profile $AwsProfile `
--region $AwsRegion

Interpretación: si el comando termina y vuelve al prompt sin imprimir líneas, significa que no encontró coincidencias para ese filtro y periodo. No significa que CloudWatch se haya desconectado.

Paso 10

Revisar en vivo los logs de Lambda

Esta será la primera ventana permanente para observar el backend.

Completado

Abre una primera ventana de PowerShell.

Vuelve a definir allí, como mínimo:

Variables mínimas

$AwsProfile = "sa-dev"
$AwsRegion = "us-east-1"
$LambdaLogGroup = "/aws/lambda/sa-dev-orchestrator-chat"

Después:

Tail Lambda

aws logs tail `
$LambdaLogGroup `
--since 5m `
--follow `
--format short `
--profile $AwsProfile `
--region $AwsRegion

La ventana debe quedar esperando. No regresará a la línea de comandos hasta que presiones:

Detener seguimiento

Ctrl + C

Paso 11

Revisar en vivo los logs de API Gateway

Esta será la segunda ventana permanente.

Completado

Abre una segunda ventana de PowerShell.

Define:

Variables mínimas

$AwsProfile = "sa-dev"
$AwsRegion = "us-east-1"
$ApiLogGroup = "/aws/apigateway/sa-dev-http-api"

Tail API Gateway

aws logs tail `
$ApiLogGroup `
--since 5m `
--follow `
--format short `
--profile $AwsProfile `
--region $AwsRegion

La ventana debe quedarse esperando.

Paso 12

Generar solicitudes en una tercera ventana

Mientras las otras dos ventanas observan los logs, utiliza una tercera para generar tráfico.

Completado

Definir endpoint

$DevBaseUrl = "https://w7jtrco599.execute-api.us-east-1.amazonaws.com/dev"

Generar una solicitud de health

GET /health

Invoke-RestMethod `
-Uri "$DevBaseUrl/health" `
-Method GET `
-Headers @{"x-trace-id"="live-health-001"}

Generar una solicitud de chat

Body

$ChatBody = @{
message = "Hola"
locale = "es"
session_id = "restart-session-001"
} | ConvertTo-Json

POST /chat

Invoke-RestMethod `
-Uri "$DevBaseUrl/chat" `
-Method POST `
-ContentType "application/json" `
-Headers @{
"x-trace-id"="live-chat-001"
"x-session-id"="restart-session-001"
} `
-Body $ChatBody

Mientras ejecutas estas solicitudes, observa simultáneamente la primera ventana de Lambda y la segunda ventana de API Gateway.

Paso 13

Volver a preparar Node.js para pruebas locales

Solo las pruebas locales necesitan recuperar la API key dentro de la nueva sesión.

Completado

Las pruebas contra API Gateway no necesitan OPENAI_API_KEY local porque OpenAI es llamado desde Lambda y la clave está configurada dentro de AWS.

Pero para ejecutar:

Prueba local

npm run test:local

sí debes volver a establecer las variables locales.

Colocar el modelo

Variables locales

$env:OPENAI_MODEL = "gpt-5.6-luna"
$env:APP_ENV = "dev"
$env:APP_VERSION = "ws-1.0.0"
$env:ASSISTANT_ENABLED = "true"

Introducir la clave sin dejarla visible en el historial

Capturar API key

$SecureOpenAIKey = Read-Host `
"Introduce OPENAI_API_KEY" `
-AsSecureString

Pasar la clave a la variable de entorno

$env:OPENAI_API_KEY = `
[System.Net.NetworkCredential]::new(
"",
$SecureOpenAIKey
).Password

Comprueba su presencia sin mostrarla:

Validación segura

[PSCustomObject]@{
OPENAI_API_KEY_Present =
-not [string]::IsNullOrWhiteSpace(
$env:OPENAI_API_KEY
)
OPENAI_MODEL =
$env:OPENAI_MODEL
}

Después puedes volver a ejecutar:

Pruebas del proyecto

npm run test:health
npm run test:injection
npm run test:local

Automatización

Crear un protocolo reutilizable

Para no volver a escribir manualmente el contexto cada vez que reinicies, puedes guardar un script en:

Archivo

scripts/start-dev-session.ps1

Contenido base

$Global:AwsProfile = "sa-dev"
$Global:AwsRegion = "us-east-1"
$Global:AwsAccountId = "TU_AWS_ACCOUNT_ID"
$Global:ApiId = "w7jtrco599"
$Global:FunctionName = "sa-dev-orchestrator-chat"
$Global:DevBaseUrl = `
"https://w7jtrco599.execute-api.us-east-1.amazonaws.com/dev"
$Global:LambdaLogGroup = `
"/aws/lambda/sa-dev-orchestrator-chat"
$Global:ApiLogGroup = `
"/aws/apigateway/sa-dev-http-api"
$Global:ProjectPath = `
"C:\Users\gerar\Documents\VSFRepositoryLocal\Dev_Platforms\NodeProjects\Project_SA_WalkingSkeleton_V2.0"

Set-Location $Global:ProjectPath

$env:OPENAI_MODEL = "gpt-5.6-luna"
$env:APP_ENV = "dev"
$env:APP_VERSION = "ws-1.0.0"
$env:ASSISTANT_ENABLED = "true"

Write-Host "Stadium Assistant DEV session loaded"
Write-Host "Project: $Global:ProjectPath"
Write-Host "AWS profile: $Global:AwsProfile"
Write-Host "Region: $Global:AwsRegion"
Write-Host "API: $Global:DevBaseUrl"

Cárgalo en una nueva sesión de PowerShell con:

Cargar protocolo

. .\scripts\start-dev-session.ps1

Cierre

Secuencia rápida diaria

Abrir PowerShell. Ir al proyecto. Ejecutar el protocolo / cargar variables. Confirmar identidad AWS. Confirmar /health. Abrir live tail de Lambda. Abrir live tail de API Gateway. Probar desde otra ventana. Configurar OPENAI_API_KEY solo si vas a ejecutar pruebas locales.

Progreso de reconexión

Completa el checklist para confirmar que el ambiente está listo.

Resultado

El ambiente queda preparado para retomar la Fase 1 y continuar identificando exactamente la causa de los errores 503.

Volver al inicio

Protocolo completo después de reiniciar la computadora

Punto exacto del chat

No se desconectaron AWS, Lambda, API Gateway, CloudWatch ni OpenAI

Lo que sigue existiendo

Lo que debes volver a preparar localmente

Abrir PowerShell

Ir al proyecto

Volver a definir el contexto del proyecto

Verificar que el perfil AWS sigue registrado

Confirmar la identidad AWS

Verificar la Lambda

Verificar API Gateway

Probar /health

Recuperar los logs anteriores de los errores 503

Buscar eventos chat_failed

Buscar rate limits upstream

Buscar errores del servicio upstream

Revisar en vivo los logs de Lambda

Revisar en vivo los logs de API Gateway

Generar solicitudes en una tercera ventana

Generar una solicitud de health

Generar una solicitud de chat

Volver a preparar Node.js para pruebas locales

Colocar el modelo

Introducir la clave sin dejarla visible en el historial

Crear un protocolo reutilizable

Secuencia rápida diaria

El ambiente queda preparado para retomar la Fase 1 y continuar identificando exactamente la causa de los errores 503.

Probar `/health`

Buscar eventos `chat_failed`