The Trinity Beast — Kiro Command Center (KCC)

1. What Is the Kiro Command Center?

The Kiro Command Center (KCC) is a set of pre-built operational routines that Kiro uses to manage The Trinity Beast Infrastructure (TBI). It consists of a bash script (scripts/kcc.sh) with 13 commands, a steering file (.kiro/steering/kiro-command-center.md) that loads automatically at the start of every session, and a live web dashboard at cpmp-site.org/docs/dashboard.html.

Instead of building curl commands from scratch for every health check, deployment, or verification, Kiro calls the KCC script. This eliminates repetitive command construction, ensures consistency, and reduces the chance of errors during operations.

2. Why It Exists

During a typical session, Kiro performs dozens of operations against The TBI — health checks after deployments, endpoint verification after code changes, cluster stats during monitoring, payment link status checks, and feed status reviews. Each of these requires:

• The correct base URL (https://api.cpmp-site.org for LPO, https://lrs.cpmp-site.org for LRS)
• The admin API key in the X-Admin-Key header
• The correct endpoint path and query parameters
• JSON parsing to extract meaningful data from the unified envelope

Without the KCC, every operation is a hand-built curl command. With the KCC, it's a single call:

# Without KCC (manual)
curl -s -H "X-Admin-Key: tbmc-admin-..." https://api.cpmp-site.org/admin/cluster-stats | python3 -m json.tool

# With KCC (one command)
bash scripts/kcc.sh cluster-stats

The steering file ensures Kiro always has the admin key, resource names, and operational procedures loaded in context — even after a session restart or context compaction.

3. Architecture — Two Components

Component 1 — Steering File

Located at .kiro/steering/kiro-command-center.md with inclusion: auto. This means it is loaded into Kiro's context at the start of every session — no manual activation required. It contains:

• The admin API key
• All base URLs (LPO, LRS, S3, CloudFront, ECR, ECS)
• Service names for all 3 ECS services
• Quick reference for common operations
• Operational rules (always health check after deploy, always verify after changes)

Component 2 — KCC Script

Located at scripts/kcc.sh. A standalone bash script that encapsulates all operational API calls. Each command:

• Sets the correct headers (admin key, content type)
• Calls the appropriate endpoint(s)
• Parses the JSON response through the unified envelope (resp.data)
• Formats the output with color-coded indicators (✅ green, 🛑 red, ℹ️ blue)

4. Command Reference

All commands are invoked as bash scripts/kcc.sh <command>.

bash scripts/kcc.sh health

# Output:
# LPO:  ✅ [LPO] [us-east-2] [BeastMirror] [/health] [200]
# LRS:  ✅ [LRS] [us-east-2] [BeastLRS] [/health] [200]
# Cluster: Nodes: 3/3
#   BeastMain: published 2026-04-26T19:04:29Z
#   BeastMirror: published 2026-04-26T19:04:29Z
#   BeastLRS: published 2026-04-26T19:04:28Z

bash scripts/kcc.sh sync-check

# Output:
# Run Time:   April 28, 2026 at 01:00 AM EST
#
# Status:     ✅ Sync complete
# Duration:   186.909018ms
# Cache:      3285260 logs in Cache
#
# Sync Results:
#   Price logs:    72 new logs loaded
#   Usage logs:    19 entries written to Cache
#   API keys:      2 keys written to Cache
#   App params:    60 params written to Cache
#   Cleanup:       🟢 Pruned 0 old logs (>93 days)

bash scripts/kcc.sh verify

# Output:
# Public Endpoints:
#   ✅ GET /health (LPO) — 200
#   ✅ GET /health (LRS) — 200
#   ✅ GET /exchanges — 200
#   ✅ GET /asset-categories — 200
#   ...
# Admin Endpoints:
#   ✅ GET /admin/config — 200
#   ✅ GET /admin/cluster-stats — 200
#   ...

bash scripts/kcc.sh cluster-stats

bash scripts/kcc.sh payment-links

# Output:
# Total: 16 links
# Type            Tier                 Enabled    Clicks   URL
# subscription    pro                  ✅          42       https://buy.stripe.com/xxx...

bash scripts/kcc.sh feed-status

# Output:
# coinbase_ws     ✅ Connected          Subs: 12  Stale: 0
# gemini_ws       ✅ Connected          Subs: 12  Stale: 0
# kraken_ws       ✅ Connected          Subs: 12  Stale: 0
# gateio_ws       ✅ Connected          Subs: 12  Stale: 0
# bybit_ws        ✅ Connected          Subs: 12  Stale: 0
# okx_ws          ✅ Connected          Subs: 12  Stale: 0

bash scripts/kcc.sh deploy-ecs

# Builds → Tags → Pushes → Force deploys main, mirror, LRS
# Then: bash scripts/kcc.sh health (after ~40s)

bash scripts/kcc.sh deploy-site cpmp-redesign/docs/Trinity-Beast-API-Reference.html
bash scripts/kcc.sh deploy-site cpmp-redesign/subscribe-listener.html cpmp-redesign/docs/index.html

bash scripts/kcc.sh profiles

bash scripts/kcc.sh config

bash scripts/kcc.sh daily-collect

bash scripts/kcc.sh daily

# Output:
# ════════════════════
#  KCC — May 02 02:11PM EDT
# ════════════════════
# ─── Services ───
# ✅ LPO  ✅ LRS  ✅ Web
# Cluster: 3/3
# ─── SQS Usage Queue ───
# ✅ Pending: 0  In-flight: 0
# ─── Website (7d) ───
# Total 14,250 2.2GB  Avg 2,035/day

bash scripts/kcc.sh security

5. Steering File — Session Context

The steering file at .kiro/steering/kiro-command-center.md is marked with inclusion: auto, which means it is loaded into Kiro's context automatically at the start of every session. This ensures Kiro always has access to:

6. Typical Workflow

A typical day starts with a morning check, then moves into the code change → deploy → verify cycle:

Morning Check

1. Daily collect + render — bash scripts/kcc.sh daily-collect then bash scripts/kcc.sh daily (full infrastructure snapshot — services, ECS, Valkey, Lambda, sync, SQS queue, analytics)
2. Health check — bash scripts/kcc.sh health (confirm 3/3 nodes, per-container status, LPO + LRS connectivity)
3. Review dashboard — cpmp-site.org/docs/dashboard.html (visual dashboard with auto-refresh)

Code Change → Deploy → Verify

1. Make code changes — edit Go handlers, HTML pages, or documentation
2. Build and verify locally — go build ./cmd/server/
3. Deploy to ECS — bash scripts/kcc.sh deploy-ecs
4. Wait ~40 seconds for ECS rolling deployment
5. Health check — bash scripts/kcc.sh health (confirm 3/3 nodes)
6. Verify endpoints — bash scripts/kcc.sh verify (confirm all 200s)
7. Deploy website changes — bash scripts/kcc.sh deploy-site cpmp-redesign/docs/...

This entire cycle takes about 3 minutes of active work plus ~40 seconds of waiting for ECS. Without the KCC, each step would require constructing individual commands with the correct URLs, headers, and parameters.

7. KCC Live Dashboard

The KCC Live Dashboard is a browser-based visual interface at cpmp-site.org/docs/dashboard.html that renders the same data collected by daily-collect. It provides:

• Service health — LPO, LRS, Website with response times
• Exchange feeds — all 6 WebSocket connections with subscription counts
• Valkey metrics — version, items, hit rate, memory/CPU bars
• Lambda status — state, memory, package size, deploy date
• Nightly sync — last run time, duration, cache totals
• SQS usage queue — pending, in-flight, delayed message counts
• ECS cluster table — per-node uptime, TCP/UDP counts, SyncMap/Cache hit rates, error counts
• Website analytics — 7-day bar chart with peak day, average, and bandwidth

The dashboard is also linked from the TBCC CloudWatch Monitoring widget for quick access during operations.

8. KCC vs TBCC — Two Command Centers

The Trinity Beast Infrastructure has two command centers, each designed for a different operator:

8. API Endpoints Used

The KCC calls these endpoints through the unified messaging envelope. All admin endpoints require the X-Admin-Key header.