Operational Guide · Stadium Assistant

Complete protocol after restarting the computer

How to prepare PowerShell and Node.js again to continue exactly with the Walking Skeleton tests and the diagnosis of the 503 errors.

Windows + PowerShell AWS us-east-1 DEV Project

13steps

3diagnostic windows

1reusable protocol

Original prompt

Exact point in the chat

“Okay, I restarted the machine and obviously PowerShell closed, and I assume it disconnected from the platforms and everything that was connected, since I entered the commands indicated in Phase 1 — Identify exactly the cause of the ten 503s, / Step 1. Review the Lambda logs and in Step 2 it did not return anything; it only showed the command line again. What do I need to do, or what protocol or process do I need to follow in PowerShell and/or Node to reconnect to everything?”

Response

AWS, Lambda, API Gateway, CloudWatch, and OpenAI were not disconnected

AWS, Lambda, API Gateway, CloudWatch, and OpenAI were not disconnected. Restarting the computer only closed the local PowerShell sessions, Node.js processes, and variables that existed only in memory.

What still exists

Lambda sa-dev-orchestrator-chat.
API Gateway w7jtrco599.
Stage /dev.
CloudWatch Logs.
Variables configured inside Lambda.

What you need to prepare locally again

The PowerShell session.
Node.js processes.
$DevBaseUrl, $ApiId, $FunctionName and the other PowerShell variables.
$env:OPENAI_API_KEY y $env:OPENAI_MODEL when you run local tests.

Important: a command aws logs tail --since 30m without --follow ends and returns to the command prompt if it finds no events in that period. This does not mean AWS was disconnected.

Step 1

Open PowerShell

First confirm that the local tools are still available.

Completed

Run one line at a time

aws --version
node -v
npm -v

Values confirmed in this environment:

AWS CLI: version 2.
Node.js: v24.16.0.
npm: 12.0.1.

Step 2

Go to the project

Put PowerShell back in the working folder.

Completed

Enter the Walking Skeleton

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

Confirm that you are in the correct folder:

Validate location and files

Get-Location
Get-ChildItem

Step 3

Define the project context again

These variables existed in the previous session and were lost when PowerShell was closed.

Completed

DEV context

$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"

Web publishing: the value of $AwsAccountId is left as a placeholder so an account identifier is not published on a public page. In your local PowerShell, use your account value.

Review the loaded context

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

Step 4

Verify that the AWS profile is still registered

Restarting Windows does not delete profiles saved by the AWS CLI.

Completed

Profiles configured with the AWS CLI normally remain in the user configuration and credentials files, so restarting Windows does not delete them. The parameter --profile explicitly selects one of those profiles.

List profiles

aws configure list-profiles

You should see:

Expected result

sa-dev

Then:

Review profile configuration

aws configure list --profile $AwsProfile

It should show the region and credential source. The key appears partially hidden.

Step 5

Confirm AWS identity

Confirm that the profile can actually authenticate against AWS.

Completed

STS GetCallerIdentity

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

It should return an object with UserId, Account y Arn. If this command responds correctly, PowerShell again has valid communication with AWS through the profile sa-dev.

Step 6

Verify the Lambda function

Confirm the actual status of the deployed function.

Completed

Lambda configuration

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

It should show:

Expected result

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

Step 7

Verify API Gateway

Confirm that the HTTP API remains deployed.

Completed

Query API Gateway

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

Expected result:

API confirmed

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

Step 8

Test `/health`

Verify API Gateway → Lambda end to end.

Completed

Health check with trace_id

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

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

$HealthResult

It should show values such as:

Expected result

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

Compare the trace sent with the one received:

Validate trace_id

$HealthTraceId -eq $HealthResult.trace_id

It should return:

Result

True

Step 9

Retrieve the previous logs for the 503 errors

The errors probably occurred more than 30 minutes ago; therefore, a search limited to --since 30m may show nothing.

Completed

Search for events `chat_failed`

Lambda · last 7 days

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

Search for upstream rate limits

upstream_rate_limited

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

Search for upstream service errors

upstream_service_error

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

Interpretation: if the command ends and returns to the prompt without printing lines, it means it found no matches for that filter and period. It does not mean CloudWatch was disconnected.

Step 10

Review Lambda logs live

This will be the first permanent window for observing the backend.

Completed

Open a first window of PowerShell.

Define at least the following there again:

Minimum variables

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

Then:

Tail Lambda

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

The window should remain waiting. It will not return to the command prompt until you press:

Stop following

Ctrl + C

Step 11

Review API Gateway logs live

This will be the second permanent window.

Completed

Open a second window of PowerShell.

Define:

Minimum variables

$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

The window should remain waiting.

Step 12

Generate requests in a third window

While the other two windows monitor the logs, use a third window to generate traffic.

Completed

Define endpoint

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

Generate a health request

GET /health

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

Generate a chat request

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

While running these requests, simultaneously observe the first Lambda window and the second API Gateway window.

Step 13

Prepare Node.js again for local tests

Only local tests need to restore the API key inside the new session.

Completed

Tests against API Gateway do not need OPENAI_API_KEY locally because OpenAI is called from Lambda and the key is configured inside AWS.

But to run:

Local test

npm run test:local

you do need to set the local variables again.

Set the model

Local variables

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

Enter the key without leaving it visible in the history

Capture API key

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

Pass the key to the environment variable

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

Check that it is present without displaying it:

Safe validation

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

Then you can run again:

Project tests

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

Automation

Create a reusable protocol

To avoid manually rewriting the context every time you restart, you can save a script in:

File

scripts/start-dev-session.ps1

Base content

$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"

Load it in a new PowerShell session with:

Load protocol

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

Closeout

Quick daily sequence

Reconnection progress

Complete the checklist to confirm that the environment is ready.

Result

Complete protocol after restarting the computer

Exact point in the chat

AWS, Lambda, API Gateway, CloudWatch, and OpenAI were not disconnected

What still exists

What you need to prepare locally again

Open PowerShell

Go to the project

Define the project context again

Verify that the AWS profile is still registered

Confirm AWS identity

Verify the Lambda function

Verify API Gateway

Test /health

Retrieve the previous logs for the 503 errors

Search for events chat_failed

Search for upstream rate limits

Search for upstream service errors

Review Lambda logs live

Review API Gateway logs live

Generate requests in a third window

Generate a health request

Generate a chat request

Prepare Node.js again for local tests

Set the model

Enter the key without leaving it visible in the history

Create a reusable protocol

Quick daily sequence

The environment is ready to resume Phase 1 and continue identifying the exact cause of the 503 errors.

Test `/health`

Search for events `chat_failed`