The Trinity BeastKiro Command Center (KCC)

How Kiro operates The Trinity Beast Infrastructure — pre-built API routines, deployment automation, and session-persistent context.

Operator: Kiro (AI Development Environment) Script: scripts/kcc.sh Steering: .kiro/steering/kiro-command-center.md Updated: June 2026

Table of Contents

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 dispatcher (scripts/kcc.sh) with 35+ commands, a Python module layer (scripts/kcc_helpers/ — 14 scripts sharing ume.py), 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.

In short: The TBCC is Cory's Command Center (browser-based, WebSocket relay to Neo). The KCC is Kiro's Command Center (script-based, direct API calls from the development environment). Both operate the same infrastructure through the same API endpoints with the same admin key.

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:

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 — Three Components

.kiro/steering/
  kiro-command-center.md — auto-loaded steering file (session context)
scripts/
  kcc.sh — bash dispatcher (routes commands to Python helpers or runs inline)
  kcc_helpers/ — Python module layer (14 scripts)
    ume.py — shared module: admin key, HTTP helpers, UME unwrap, valkey()
    daily_collect.py — metrics collector → Valkey
    prewarm_audit.py — 4-layer asset integrity check
    session_close.py — report upload + registry
    translate_pending.py — batch translation submission
    asset_rebalance.py — exchange asset discovery + EAM upsert
    security.py — WAF/GuardDuty/alarm dashboard
    ... — 7 more (sync_eam, sync_icons, build_search, etc.)

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:

Component 2 — KCC Script

Located at scripts/kcc.sh. A bash dispatcher that routes commands to the appropriate Python helper or executes inline bash logic. Each command:

Component 3 — Python Helpers (scripts/kcc_helpers/)

A directory of 14 Python scripts that handle the heavy lifting. All share a single module: ume.py (Unified Messaging Envelope helper).

Single source of truth: The admin key lives in exactly ONE Python file (ume.py) + ONE shell script (kcc.sh). All 14 helper scripts import from ume.py — zero hardcoded keys elsewhere. On key rotation, update those 2 files. Everything downstream inherits automatically.

The shared ume.py module provides:

FunctionPurpose
admin_get(path)GET with admin key, returns raw UME envelope dict
admin_post(path, body)POST with admin key, returns raw UME envelope dict
valkey(command)POST /admin/valkey shorthand — one-liner for any Valkey command
ume_unwrap(envelope, label)Strict unwrap: check 2xx, return .data, raise UMEError on failure
ume_get(path, label)admin_get + ume_unwrap in one call
ume_post(path, body, label)admin_post + ume_unwrap in one call
ume_get_or_exit(path)Like ume_get but prints error and exits on failure

New KCC helpers always import from ume.py — never hardcode credentials or re-implement the envelope unwrap logic.

Credential Centralization — Admin Key Architecture

The admin API key (tbcc-admin-*) authenticates every operational request against the TBI admin endpoints. As of June 2026, the key is fully centralized — no hardcoded copies exist outside the two canonical source files.

Two files own the key. Everything else inherits.

LayerFileHow It Gets the Key
Python (canonical)scripts/kcc_helpers/ume.pyos.environ.get("ADMIN_KEY", "<fallback>") — env override supported, fallback is the current key
Shell (canonical)scripts/kcc.shLine 48: ADMIN_KEY="tbcc-admin-..." — exported to env for child processes
Python helpers (14)scripts/kcc_helpers/*.pyfrom ume import ADMIN_KEY — zero local definitions
External scriptsscripts/seed_prewarm_traffic.pysys.path.insert + from ume import ADMIN_KEY
Legacy shell scriptsscripts/{backfill,seed-valkey-langs,...}.sh${ADMIN_KEY:-fallback} — reads env var with inline fallback
Steering file.kiro/steering/kiro-command-center.mdPlaintext reference (loaded into Kiro's context)
Lambda functions (6)Environment variablesADMIN_KEY env var on each function config
ECS tasks (2)Task definition envADMIN_KEY in container environment (sync job + translate worker)

On key rotation (bash scripts/kcc.sh rotate-admin-key):

  1. kcc.sh self-updates (automated by the rotation command)
  2. scripts/kcc_helpers/ume.py — manual update (single line)
  3. .kiro/steering/kiro-command-center.md — manual update
  4. 6 Lambda functions — aws lambda update-function-configuration (no rebuild needed)
  5. 2 ECS task definitions — register new revision with updated env var

All 14 Python helpers, all legacy scripts, and all external consumers inherit the new key immediately — no additional files to touch.

Key rotation race condition: When rotate-admin-key updates Aurora and calls reload-params, the reload request authenticates with the OLD key. Once the first container reloads, it rejects the old key — so subsequent reload calls to other containers may fail. The command mitigates this by calling reload rapidly in a loop so the ALB round-robins across all nodes before propagation completes.

4. Command Reference

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

health

Checks all services — LPO health, LRS health, and cluster stats (3/3 nodes reporting). This is the first command run after every ECS deployment.

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

sync-check

Verifies the last nightly sync job ran successfully. Pulls the most recent log stream from CloudWatch (/aws/ecs/trinity-beast-sync) and displays run time (EST), completion status, duration, cache totals, and per-category sync counts (price logs, usage logs, API keys, app params, cleanup). Run this every morning right after health.

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)

verify

Hits 16 key endpoints (6 public + 10 admin) and reports the HTTP status code for each. Used after major changes to confirm nothing is broken.

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
#   ...

cluster-stats

Returns the full cluster-wide metrics snapshot — all 24 counters aggregated across all 4 containers via ElastiCache pipeline read.

bash scripts/kcc.sh cluster-stats

payment-links

Shows all 16 payment links with their enabled status, click counts, and Stripe URLs. Used to verify link configuration before and after Stripe setup.

bash scripts/kcc.sh payment-links

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

feed-status

Shows the connection status of all 6 exchange WebSocket feeds with subscription counts and stale asset counts.

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
# cryptocom_ws        ✅ Connected          Subs: 12  Stale: 0
# okx_ws          ✅ Connected          Subs: 12  Stale: 0

deploy-ecs

Full ECS deployment pipeline — Docker build (no-cache), ECR tag, ECR push, force deploy all 4 services. The most common deployment command.

bash scripts/kcc.sh deploy-ecs

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

deploy-site <file(s)>

Uploads HTML files to S3 and invalidates CloudFront. Automatically strips the cpmp-redesign/ prefix to determine the S3 path.

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

profiles

Lists all 16 system profiles with their key parameters (QPS, burst, TTL, DB pool size).

bash scripts/kcc.sh profiles

config

Shows the current application parameters — cache TTL, prewarm intervals, pool sizes, demo key, etc.

bash scripts/kcc.sh config

daily-collect

Collects all infrastructure metrics (endpoints, feeds, cluster, Valkey, Lambda, sync, SQS queue, website analytics) and stores them as a single JSON blob in Valkey (kcc:daily key, 24h TTL). This is the data source for both the CLI daily command and the KCC Live Dashboard.

bash scripts/kcc.sh daily-collect

daily

Renders the compact daily status dashboard from the Valkey cache. If no cached data exists, it auto-runs daily-collect first. Shows services, ECS nodes, Valkey health, Lambda, nightly sync, SQS queue depth, and 7-day website analytics.

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

security

Security dashboard — CloudFront WAF (24h blocks), API WAF (per-rule breakdown), GuardDuty threat detection, CloudWatch security alarms, and application rate limiting stats.

bash scripts/kcc.sh security

force-deploy

Reloads all application parameters from Aurora → local cache + ElastiCache, re-parses prewarm asset lists, flushes prices, and resets all timers across all containers. Use after changing application_parameters in the database.

bash scripts/kcc.sh force-deploy

prewarm-audit

Validates all 169 prewarm assets across 6 exchanges against their live APIs. Reports any dead/delisted assets that need replacement. Run periodically — exchanges delist and rebrand assets more often than expected.

Also available in the browser: The EAM Admin Panel runs the same 4-layer audit via GET /admin/eam/audit (async, results in ~12s) and renders results visually — per-exchange bars, inline Disable/Replace buttons for dead assets, and one-click drift remediation. Use the CLI command for terminal sessions; use the panel for interactive maintenance.
bash scripts/kcc.sh prewarm-audit

# Output:
# ✅ COINBASE   26/26 OK
# ✅ CRYPTOCOM  24/24 OK
# ✅ GATEIO     24/24 OK
# ✅ GEMINI     25/25 OK
# ✅ KRAKEN     26/26 OK
# ✅ OKX        36/36 OK

sync-icons

Fetches the top 750 coins by market cap from CoinGecko's free API, matches by symbol against enabled EAM assets, and populates icon_url for any asset missing one. Icons are served to subscribers via the /asset-categories response and displayed in the demo dropdown.

bash scripts/kcc.sh sync-icons

# Output:
#   Mode: Fill missing icons only
#   Assets needing icons: 37
#   Fetching CoinGecko market data...
#     Page 1/3... 250 coins
#     Page 2/3... 250 coins
#     Page 3/3... 250 coins
#   CoinGecko unique symbols: 712
#   Matched: 28 | Still missing: 9
#   Writing 28 icon URLs to Aurora... ✅ 28 rows updated (42ms)

# Use --force to overwrite all existing icon URLs:
bash scripts/kcc.sh sync-icons --force

build-search

Rebuilds the multi-lingual full-text search index from all 32 documents across 12 languages (384 total) plus daily operations reports (English only, 30-day rolling archive). Fetches each doc from CloudFront, parses HTML into sections, and stores per-language indexes in Valkey. Run after deploying new or updated documents. The nightly sync also triggers this automatically.

Search features: Paginated results (9 per page), multi-lingual scoring, daily report indexing, and an interactive Search Demo showing the English → Japanese flow.

bash scripts/kcc.sh build-search

push-langs

Pushes all 12 language JSON files from cpmp-redesign/lang/ to Valkey (lang:{code} keys). The i18n system's primary source is the API (/public/lang/{code}), which reads from Valkey. If language files are edited locally and deployed to S3 but NOT pushed to Valkey, the API serves stale data and new i18n keys won't appear on the website. Run after any edit to language JSON files.

bash scripts/kcc.sh push-langs

delta-validate <doc>

Validates that TBI-CHUNK markers are preserved through the translation reassembly pipeline for a given document. Checks that chunk count in the source matches chunk count in the reassembled output. Run before submitting a document to the translation engine to confirm chunk integrity.

bash scripts/kcc.sh delta-validate Trinity-Beast-API-Reference.html

# Output:
# Source chunks:  12
# Output chunks:  12
# ✅ Chunk markers preserved — safe to submit

chunk-size <doc>

Scans a document and reports the size of each chunk between TBI-CHUNK markers. Flags any chunks that exceed the translation engine's size policy (15 KB baseline, 18 KB max, 12 KB for dense/code-heavy sections). Also suggests where to add new markers if any chunk is over-limit. Run before submitting large or recently updated documents to the translation engine.

bash scripts/kcc.sh chunk-size cpmp-redesign/docs/Trinity-Beast-API-Reference.html

# Output:
# Chunk 1:  11.2 KB  ✅
# Chunk 2:  14.8 KB  ✅
# Chunk 3:  17.1 KB  ⚠️  approaching limit
# Chunk 4:   9.3 KB  ✅
# Chunk 5:  19.4 KB  🛑  OVER LIMIT — add TBI-CHUNK near line 412

Threat Response

trace-ip <ip_address>

Forensic trace of an IP address — WAF blocks (last 24h sampled requests) and usage logs from Aurora. Shows what the IP was doing and whether WAF caught it.

bash scripts/kcc.sh trace-ip 45.148.10.247

trace-key <api_key_id>

Forensic trace of an API key — owner details (email, name, tier), recent activity (last 50 calls), and unique IPs used.

bash scripts/kcc.sh trace-key demo-public-2026-03-01-abc123

trace-email <email>

Full account trace — user account, API keys, transactions, and support tickets for an email address.

bash scripts/kcc.sh trace-email user@example.com

threat-log

Shows WAF blocks by rule (last 24h) and GuardDuty findings (severity ≥ MEDIUM). Quick threat visibility without the full security dashboard.

bash scripts/kcc.sh threat-log

threat-status

Current defense posture — manually blocked IPs (WAF IP set) and any firing CloudWatch alarms.

bash scripts/kcc.sh threat-status

block-ip <ip_address>

Adds an IP to the WAF block list (trinity-beast-blocked-ips IP set). Creates the IP set if it doesn't exist. Immediate effect — all requests from this IP get 403.

bash scripts/kcc.sh block-ip 1.2.3.4

unblock-ip <ip_address>

Removes an IP from the WAF block list.

bash scripts/kcc.sh unblock-ip 1.2.3.4

kill-key <api_key_id>

Immediately revokes an API key — sets status to 'revoked' in Aurora and deletes the cached key from ElastiCache. All subsequent requests with this key get 403 Forbidden.

bash scripts/kcc.sh kill-key abc123-compromised-key

warn-subscriber <api_key_id> "reason"

Sends a threat warning email to the subscriber who owns the specified API key. Uses the ThreatWarning SES template. Does not revoke the key — this is a first-strike warning.

bash scripts/kcc.sh warn-subscriber abc123-key "Unusual request patterns detected from your API key"

terminate-subscriber <api_key_id> "reason"

Full subscriber termination — revokes key, cancels Stripe subscription (prorated refund), blocks all source IPs, and sends termination notice via SES. Irreversible. Generates a violation ID for audit trail.

bash scripts/kcc.sh terminate-subscriber abc123-key "Repeated abuse after warning"

Security Escalation

rotate-admin-key

Generates a new admin key, updates Aurora application_parameters, flushes the old key from Valkey, force-deploys params to all containers, and self-updates the KCC script. The old key is immediately invalid. Use when the admin key may be compromised.

After rotation, only 2 files need manual update: ume.py (Python canonical source) and the steering file. All 14 helpers and legacy scripts inherit automatically. See Section 3 — Credential Centralization for the full propagation map.

bash scripts/kcc.sh rotate-admin-key

# Output:
# Old key: tbcc-admin-ec...e380
# New key: tbcc-admin-7f3a...b291
# [1/4] Updating Aurora application_parameters...
# [2/4] Flushing old key from Valkey...
# [3/4] Force deploying params to all containers...
# [4/4] Updating KCC script with new key...
# ✅ Admin key rotated successfully
#
# Post-rotation (manual):
#   1. Update ume.py fallback value
#   2. Update kiro-command-center.md steering
#   3. Update 6 Lambda env vars (aws lambda update-function-configuration)
#   4. Update 2 ECS task definitions (sync job + translate worker)

lockdown-admin <your_ip>

Creates a WAF rule (priority 0 — highest) that blocks ALL /admin/* requests unless they originate from the specified IP. Emergency use — locks out everyone except you. To find your IP: curl -s ifconfig.me

bash scripts/kcc.sh lockdown-admin 73.42.156.89

# Only 73.42.156.89 can now reach /admin/* endpoints
# All other IPs get blocked at WAF before reaching the server

unlock-admin

Removes the admin lockdown WAF rule, restoring normal admin access for all authenticated requests.

bash scripts/kcc.sh unlock-admin

block-country "<country_codes>"

Adds a geo-match WAF rule to the ALB that blocks ALL traffic from specified countries (ISO 3166-1 alpha-2 codes). Idempotent — running again replaces the previous list. Use during sustained regional attacks.

bash scripts/kcc.sh block-country "RU CN"
bash scripts/kcc.sh block-country "RU CN IR KP"

unblock-country

Removes the country geo-block rule entirely, allowing all geographic traffic.

bash scripts/kcc.sh unblock-country

Newsletter

release-notes "<note>"

Appends a release note to the weekly accumulator in Valkey (autoops:release-notes:week). These notes are read by the digest Lambda on Monday morning and included as a "What's New" section in the weekly subscriber newsletter. Run at the end of each session to capture subscriber-facing improvements.

bash scripts/kcc.sh release-notes "Branded HTML email notifications for all AutoOps alerts"

# Output:
# ✅ Release note added (#3 this week)
#    Branded HTML email notifications for all AutoOps alerts

release-notes-show

Shows all accumulated release notes for the current week. Use to review what will appear in Monday's newsletter.

bash scripts/kcc.sh release-notes-show

# Output:
# 1. [2026-05-10] Branded HTML email notifications via SES
# 2. [2026-05-10] SNS-to-Lambda notification pipeline
# 3. [2026-05-10] Weekly newsletter Gmail-compatible dark theme
#
# Total: 3 notes

release-notes-clear

Clears all accumulated release notes. Done automatically after the weekly newsletter sends successfully. Manual use only needed if you want to start fresh mid-week.

bash scripts/kcc.sh release-notes-clear

Document Lifecycle

doc-publish <file> --reason "what changed"

Deploys an English document to S3, invalidates CloudFront, updates the doc registry in Valkey, queues for translation, and triggers a search index rebuild. One command handles the entire publish pipeline.

bash scripts/kcc.sh doc-publish Trinity-Beast-API-Reference.html --reason "Added EAM endpoints"

session-close <N> "<summary>"

Finalizes a session report — uploads to S3, appends to the session log in Valkey (docs:session:log), and writes the plain-text version for the weekly newsletter (report:text:YYYY-MM-DD).

bash scripts/kcc.sh session-close 2 "UME helper migration, doc updates, steering cleanup"

translate-pending [--list]

Without flags: validates all queued docs' Mermaid diagrams, then submits to the translation engine in batches of 6. With --list: shows the pending queue without submitting. Reads from docs:pending:translation sorted set.

bash scripts/kcc.sh translate-pending --list

# Output:
# 39 docs pending translation:
#   Trinity-Beast-API-Reference.html — "Added EAM endpoints" (2026-06-11)
#   Trinity-Beast-Go-Application-Features.html — "Multi-provider Bedrock" (2026-06-07)
#   ...

doc-registry [--pending | --status <file>]

Shows the full document registry (44 docs: ✓ current / ⏳ pending / ★ new). Use --pending to see only docs queued for translation, or --status <file> for a single doc's entry.

bash scripts/kcc.sh doc-registry --pending

Escalation Sequence (Admin Key Compromise):

  1. bash scripts/kcc.sh lockdown-admin $(curl -s ifconfig.me) — lock everyone else out NOW
  2. bash scripts/kcc.sh rotate-admin-key — invalidate the compromised key
  3. bash scripts/kcc.sh threat-log — check what damage was done
  4. bash scripts/kcc.sh trace-ip <attacker_ip> — forensics
  5. bash scripts/kcc.sh block-ip <attacker_ip> — permanent ban
  6. bash scripts/kcc.sh unlock-admin — restore normal access once safe

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:

InformationPurpose
Admin API KeyAuthenticate against all admin endpoints without asking
LPO / LRS Base URLsConstruct API calls without looking up DNS
S3 Bucket NameDeploy website files to the correct bucket
CloudFront Distribution IDInvalidate the CDN cache after deployments
ECR RepositoryPush Docker images to the correct registry
ECS Cluster + Service NamesForce deploy the correct services
Operational RulesAlways health check after deploy, always verify after changes

Context Persistence: Even if the conversation is compacted due to context window limits, the steering file is reloaded automatically. This means Kiro never loses access to the operational essentials — the admin key, resource names, and procedures survive context compaction.

6. Typical Workflow

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

Morning Check

  1. Read previous session report — open ~/daily-reports/tbi-ops-YYYY-MM-DD-session-N.html from the last session to pick up context, pending items, and roadmap ideas
  2. Daily collect + renderbash scripts/kcc.sh daily-collect then bash scripts/kcc.sh daily (full infrastructure snapshot — services, ECS, Valkey, Lambda, sync, SQS queue, analytics)
  3. Prewarm asset auditbash scripts/kcc.sh prewarm-audit (validate 169 assets across 6 exchanges)
  4. Security & threat checkbash scripts/kcc.sh threat-log + bash scripts/kcc.sh threat-status (WAF blocks, GuardDuty, alarms, block list)
  5. Generate ops report — compile all data into an HTML report, save to ~/daily-reports/tbi-ops-YYYY-MM-DD-session-N.html and S3, open in browser

Daily Ops Report (tbi-ops-*)

Every session produces an operational report — an HTML document that serves as both a health snapshot and a session log. Reports are stored locally and on S3, accessible via cpmp-site.org/daily-reports/.

AttributeValue
Namingtbi-ops-YYYY-MM-DD-session-N.html
Local path~/daily-reports/
S3 paths3://trinity-beast-website-east2/daily-reports/
Public URLcpmp-site.org/daily-reports/
LanguageEnglish (Google Translate widget on every report for 130+ languages)
Retention30 days (default — extensible, not hardcoded)

Each report contains:

Persistent Memory Architecture: AI agents have no memory between sessions — every new conversation starts from zero. The daily report system solves this. These reports form a revolving 30-day operational memory that gives Kiro persistent context across sessions. At session start, Kiro reads recent reports' closing sections (Pending Items, Notes to Self, Decisions Made) to establish continuity — picking up exactly where the last session left off. No context is lost. Decisions, pending work, and architectural choices carry forward automatically. The 30-day retention window is not hardcoded — it can be extended at any time.
Weekly Subscriber Newsletter: Every Monday at 7 AM EST, the AutoOps digest Lambda reads the past 7 days of session reports from Valkey and generates a "Week in Review" newsletter via Bedrock. This is automatically translated into 11 languages and sent to all subscribers via SES — giving the community a narrative summary of what was built, fixed, and improved each week. The session reports are the primary source of truth for the weekly newsletter.
Multi-Lingual Access: All session reports include a Google Translate widget (top-right corner) supporting 130+ languages. The reports themselves are authored in English, but any visitor can read them in their preferred language instantly. The daily reports landing page also includes the translate widget.

Code Change → Deploy → Verify

  1. Make code changes — edit Go handlers, HTML pages, or documentation
  2. Build and verify locallygo build ./cmd/server/
  3. Deploy to ECSbash scripts/kcc.sh deploy-ecs
  4. Wait ~40 seconds for ECS rolling deployment
  5. Health checkbash scripts/kcc.sh health (confirm 3/3 nodes)
  6. Verify endpointsbash scripts/kcc.sh verify (confirm all 200s)
  7. Deploy website changesbash 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:

Auto-Refresh: The dashboard has a 30-second auto-refresh toggle. When enabled, it pulls live data from the admin endpoints (services, feeds, cluster, ECS) and preserves AWS-side metrics (Lambda, sync, analytics, SQS) from the last CLI collect. A green freshness dot indicates data age.

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:

AspectTBCC (Cory's)KCC (Kiro's)
OperatorCory Dean KalaniKiro (AI Development Environment)
InterfaceBrowser-based dashboardBash script + steering file + Live Dashboard
Access MethodWebSocket relay to Neo MacBookDirect API calls from dev environment
TerminalBuilt-in browser terminalIDE terminal (Kiro's tool execution)
WidgetsNewsletter, Support, Email, CloudWatch, Stripe, Testing, AWS Ops, Partners, Exchange Manager, Cluster Health35+ bash/Python commands covering health, deploy, security, translation, analytics, and more
AuthenticationAdmin key stored in localStorageAdmin key in ume.py (single source) + steering file (auto-loaded)
DeploymentCopy commands → paste in local terminalDirect execution via deploy-ecs and deploy-site
PersistenceBrowser sessionSteering file survives context compaction
URLcpmp-site.org/admin/trinity-beast-command-center.htmlscripts/kcc.sh

Same API, different interfaces. Both command centers call the same endpoints with the same admin key. The TBCC is optimized for visual monitoring and manual operations. The KCC is optimized for automated, repeatable operations during development sessions.

9. Document Translation Engine

The KCC includes a full set of commands for operating the custom Bedrock-powered translation engine. This engine translates all 32 technical documents into 11 languages using sentinel preprocessing to protect code blocks, Mermaid diagrams, and brand terms. Never use AWS Translate for document translation — it corrupts code blocks and brand terms.

Cost guardrails: $600/day spend cap (autoops:bedrock:spend:daily) + 50M combined token/day secondary cap (autoops:bedrock:tokens:input:daily + autoops:bedrock:tokens:output:daily). Both reset at midnight UTC via 24h TTL. Kill switch: SET autoops:bedrock:kill 1 in Valkey to halt all translation immediately.

Submit & Monitor

POST /admin/translate — Submit a Translation Job

Enqueues a translation job. The engine handles everything: sentinel preprocessing, Bedrock translation, S3 deployment, CloudFront invalidation, search index rebuild, and email notification. Fire and forget — one API call does it all.

# Single document, all 11 languages
curl -s -X POST -H "X-Admin-Key: $ADMIN_KEY" -H "Content-Type: application/json" \
  -d '{"docs":["Trinity-Beast-API-Reference.html"],"langs":"all"}' \
  "$LPO_BASE/admin/translate" | jq .

# Multiple documents, specific languages
curl -s -X POST -H "X-Admin-Key: $ADMIN_KEY" -H "Content-Type: application/json" \
  -d '{"docs":["Trinity-Beast-API-Reference.html","Trinity-Beast-Architecture-Guide.html"],"langs":["es","pt","fr"]}' \
  "$LPO_BASE/admin/translate" | jq .

# Delta mode — skip pairs where translated S3 file is newer than source (saves up to 90%)
curl -s -X POST -H "X-Admin-Key: $ADMIN_KEY" -H "Content-Type: application/json" \
  -d '{"docs":["Trinity-Beast-API-Reference.html"],"langs":"all","options":{"delta":true}}' \
  "$LPO_BASE/admin/translate" | jq .

# With idempotency key (safe to retry)
curl -s -X POST -H "X-Admin-Key: $ADMIN_KEY" -H "X-Idempotency-Key: api-ref-2026-05-27" \
  -H "Content-Type: application/json" \
  -d '{"docs":["Trinity-Beast-API-Reference.html"],"langs":"all"}' \
  "$LPO_BASE/admin/translate" | jq .

Limits: Max 6 docs per request (multiples-of-3 convention). Max 3 active jobs (additional queue in SQS, depth 12). Max 12 languages per request. Typical cost: ~$1.65 per doc-language pair, ~$18 for 1 doc × 11 langs.

GET /admin/translate/status/{job_id} — Monitor Progress

Real-time per-pair progress from Valkey. Shows each language pair's status (pending, in_progress, completed, failed), token counts, and cost.

curl -s -H "X-Admin-Key: $ADMIN_KEY" "$LPO_BASE/admin/translate/status/{job_id}" | jq .

GET /admin/translate/queue — Active Queue

Shows all active and queued jobs with their current state.

curl -s -H "X-Admin-Key: $ADMIN_KEY" "$LPO_BASE/admin/translate/queue" | jq .

GET /admin/translate/health — System Health

Translation engine health snapshot — daily spend, token usage (input + output vs 50M limit), active job count, queue depth. The KCC Live Dashboard also shows this data in the Translation Engine card.

curl -s -H "X-Admin-Key: $ADMIN_KEY" "$LPO_BASE/admin/translate/health" | jq .

# Key fields in response:
# daily_spend_usd        — dollars spent today
# daily_input_tokens     — input tokens consumed today
# daily_output_tokens    — output tokens consumed today
# daily_token_limit      — 50,000,000 (50M combined cap)
# active_jobs            — currently running Step Functions
# queue_depth            — jobs waiting in SQS

GET /admin/translate/history — Job History

Last 50 completed jobs from Aurora — the permanent ledger. Includes job ID, docs, languages, total cost, duration, and completion time.

curl -s -H "X-Admin-Key: $ADMIN_KEY" "$LPO_BASE/admin/translate/history" | jq .

Control

POST /admin/translate/cancel/{job_id} — Cancel a Job

Stops the Step Function immediately. Already-completed pairs are not rolled back — S3 files written before cancellation remain.

curl -s -X POST -H "X-Admin-Key: $ADMIN_KEY" "$LPO_BASE/admin/translate/cancel/{job_id}"

POST /admin/translate/retry-failed/{job_id} — Retry Failed Pairs

Retries only the failed language pairs from a partial job. Successful pairs are not re-translated. Cost-efficient recovery from partial failures.

curl -s -X POST -H "X-Admin-Key: $ADMIN_KEY" "$LPO_BASE/admin/translate/retry-failed/{job_id}"

Pre-Submission Checklist

Before submitting any document to the translation engine, run these two checks:

chunk-size <doc> — Verify Chunk Sizes

Reports the size of each chunk between TBI-CHUNK markers. Policy: 15 KB baseline, 18 KB max, 12 KB for dense/code-heavy sections. Flags over-limit chunks and suggests where to add markers. Do not submit and hope — verify first.

bash scripts/kcc.sh chunk-size cpmp-redesign/docs/Trinity-Beast-API-Reference.html

delta-validate <doc> — Verify Chunk Marker Integrity

Confirms that TBI-CHUNK markers survive the translation reassembly pipeline. Chunk count in source must match chunk count in output. Run before submitting documents that have been recently edited.

bash scripts/kcc.sh delta-validate Trinity-Beast-API-Reference.html

Infrastructure

ComponentResourcePurpose
WorkerECS Fargate service tbi-translate-worker-service (Python 3.11, 2 vCPU / 6 GB, persistent)Polls SQS directly, sentinel preprocessing, Bedrock translation, batch job polling, validation
Deploy Lambdatbi-translate-deploy (Go, 1770 MB, 60s)Batch CloudFront invalidation
Finalize Lambdatbi-translate-finalize (Go, 1770 MB, 180s)Search rebuild, SNS notification, state transition
Step Functiontbi-translation-orchestrator (v3.0: PerLang Map)One container per language, all docs sequentially
SQS Queuetrinity-beast-translation-queueDecouples submission from execution
Batch ArtifactsS3 trinity-beast-translation-jobsBedrock batch inference JSONL input/output
Aurora Tablestranslation_jobs, translation_job_events, translation_parametersPermanent ledger + audit log + cost/pricing params
Valkey Keystx:job:{id}, tx:active, tx:history, autoops:bedrock:spend:dailyLive state + cost tracking

10. API Endpoints Used

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

CommandEndpoints CalledAuth
healthGET /health (LPO + LRS), GET /admin/cluster-statsNone + Admin
sync-checkCloudWatch Logs: describe-log-streams, get-log-events on /aws/ecs/trinity-beast-syncAWS credentials
verify16 endpoints (6 public + 10 admin)Mixed
cluster-statsGET /admin/cluster-statsAdmin
payment-linksGET /admin/payment-linksAdmin
feed-statusGET /admin/feed-statusAdmin
deploy-ecsDocker + ECR + ECS (AWS CLI, not HTTP)AWS credentials
deploy-siteS3 + CloudFront (AWS CLI, not HTTP)AWS credentials
profilesGET /admin/profilesAdmin
configGET /admin/configAdmin
trace-ipWAF get-sampled-requests + POST /admin/sqlAWS + Admin
trace-keyPOST /admin/sql (2 queries)Admin
trace-emailPOST /admin/sql (4 queries)Admin
kill-keyPOST /admin/sql-batch + POST /admin/valkeyAdmin
terminate-subscriberPOST /admin/sql + Stripe API + WAF + SESAdmin + AWS + Stripe
rotate-admin-keyPOST /admin/sql-batch + POST /admin/valkey + GET /admin/force-deploy-paramsAdmin
lockdown-adminWAF create-ip-set / update-web-aclAWS credentials
block-countryWAF update-web-acl (geo-match rule)AWS credentials
push-langsS3 sync + POST /admin/valkey (SET lang:{code})AWS + Admin
build-searchPOST /admin/build-search-indexAdmin
doc-publishS3 + CloudFront + POST /admin/doc-registry/set + POST /admin/doc-pending/addAWS + Admin
session-closeS3 + POST /admin/doc-session/log + POST /admin/valkeyAWS + Admin
doc-registryGET /admin/doc-registry + GET /admin/doc-pendingAdmin
asset-rebalanceExchange public APIs + POST /admin/sql-batch + force-deployAdmin
sync-eamPOST /admin/sql + POST /admin/sql-batchAdmin
sync-iconsCoinGecko API + POST /admin/sql-batchAdmin
seed-trafficGET /price + GET /prices (demo key, ~173 calls)None (public API)
translate-worker-statusECS describe-services + SQS get-queue-attributesAWS credentials
translate-scaleECS update-service (desired count)AWS credentials
refresh-token-ratiosPOST /admin/sql + POST /admin/valkeyAdmin
delta-validateLocal file read + chunk marker count comparisonNone
chunk-sizeLocal file read + awk chunk size analysisNone
translate (submit)POST /admin/translateAdmin
translate (status)GET /admin/translate/status/{id}Admin
translate (queue)GET /admin/translate/queueAdmin
translate (health)GET /admin/translate/healthAdmin
translate (history)GET /admin/translate/historyAdmin
translate (cancel)POST /admin/translate/cancel/{id}Admin
translate (retry)POST /admin/translate/retry-failed/{id}Admin