War Room Demo App

1. Quick Start

"Ahead, warp factor one." — Captain Kirk, upon launching a new mission

This guide covers everything you need to get the War Room Demo App up and running, from building the admin console to executing your first simulated incident response. Think of it as your Starfleet Academy primer before you take command of the bridge.

1.1 Prerequisites

1.2 First Launch — Build the Admin Console

git clone <your-repo-url> war-room-demo-app
cd war-room-demo-app/admin-console

./gradlew :composeApp:assembleDebug

composeApp/build/outputs/apk/debug/composeApp-debug.apk

adb install composeApp/build/outputs/apk/debug/composeApp-debug.apk

1.3 Connect to the War Room Server

Once the app launches, navigate to the Settings screen via the bottom navigation bar. You will see three server presets:

Select your preset, tap CONNECT, and verify the status card shows Connected.

2. Roles & Responsibilities — The Bridge Crew

"A starship is only as good as her crew." Every effective incident response depends on clearly defined roles. We map each War Room role to a Star Trek TOS bridge officer to make the responsibilities intuitive and memorable. — Undercurrent Ops Manual

The War Room system automatically pulls in the right people based on incident severity and escalation policies. Each role has a TOS analogy used throughout the demo and the admin console UI.

Incident Commander (IC)

Captain James T. Kirk

The IC has the conn. They own the incident end-to-end: declaring severity, assigning tasks, making escalation decisions, and driving toward resolution. In the demo, Sarah Chen assumes this role.

• Acknowledges incoming P1 alerts
• Assigns investigation tasks to specialists
• Makes go/no-go decisions on hotfixes
• Coordinates cross-functional response
• Owns the post-incident review

"I'm taking command. Marcus, pull the connection pool metrics."

Senior Analyst / DBA

Commander Spock — Science Officer

The Senior Analyst provides logical, data-driven analysis of the incident. They dig into root causes, run diagnostics, and provide the evidence base for decisions. In the demo, Priya Sharma (Database Administrator) fills this role.

• Runs diagnostic queries and identifies root cause
• Kills problematic queries or connections
• Provides forensic analysis for postmortem
• Validates fixes before production deployment

"Confirmed — 3 long-running queries holding connections for 20+ minutes. The ORM isn't releasing connections on the batch path."

Communications Lead

Dr. Leonard "Bones" McCoy — Chief Medical Officer

Just as McCoy diagnoses the human cost of every away mission, the Communications Lead assesses the customer impact and manages stakeholder messaging. They are the voice of empathy in the war room — focused on the people affected.

• Drafts and publishes status page updates
• Coordinates with customer support teams
• Manages executive bridge communications
• Ensures SLA notification requirements are met

"I'm a doctor, not an engineer — but I can tell you exactly how many customers this is hurting."

Infrastructure Lead / SRE Lead

Lt. Cmdr. Montgomery "Scotty" Scott — Chief Engineer

Scotty knows every bolt and weld on the Enterprise. The Infrastructure Lead knows every service, every deployment pipeline, and every configuration. They execute the fix. In the demo, Marcus Rivera fills this role.

• Pulls infrastructure metrics and traces
• Identifies deployment correlation with incidents
• Builds and tests hotfixes
• Pushes fixes through the deployment pipeline

"Hotfix for the ORM batch connection leak is staged. Tested in staging-east — connections properly released. Pushing to prod now."

Comms Officer

Lt. Nyota Uhura — Communications Officer

Uhura opens all channels. The Comms Officer ensures that every notification, page, and status update reaches the right person at the right time through the right channel. In the demo, Diana Reyes (Communications Lead) embodies this role.

• Manages multi-channel notification routing
• Publishes status page updates on IC approval
• Bridges Slack channels, PagerDuty, and SMS
• Notifies customer support of inbound ticket waves

"Status page updated: 'Identified — Database connectivity issue identified and actively mitigating.'"

On-Call Engineer

Lt. Hikaru Sulu — Helmsman

Sulu keeps the ship on course. The On-Call Engineer is the first responder who steers the initial triage before specialists arrive. They keep systems running while the cavalry assembles.

• First to receive automated pages
• Performs initial triage and impact assessment
• Activates escalation if threshold is met
• Maintains system stability during investigation

"Steady as she goes — holding course while we navigate through this anomaly."

Junior Analyst / Monitoring Analyst

Ensign Pavel Chekov — Navigator

Chekov keeps his eyes on the sensors. The Junior/Monitoring Analyst watches dashboards, tracks live metrics, and provides continuous situational awareness during the incident. In the demo, Alex Kim fills this role.

• Monitors live dashboards for secondary failures
• Tracks key metrics (error rates, queue depths, latency)
• Reports metric changes to the IC in real time
• Validates recovery via metric normalization

"Payment retry queue is draining. 1,200 → 340 → 12. All previously failed transactions are processing successfully."

3. War Room Setup

"All hands, battle stations!" — Standard Red Alert procedure, USS Enterprise

A War Room is automatically created when a P1 or P2 incident is triggered. The system handles group creation, role assignment, and notification routing. Here is the anatomy of a War Room:

3.1 War Room Architecture

3.2 War Room Lifecycle

4. Incident Response Flow

"The needs of the many outweigh the needs of the few." — Spock, reminding us why fast incident response matters

The incident response flow follows the NIST SP 800-61 framework adapted for operational incident management. Here is the complete workflow as demonstrated in the War Room demo:

4.1 Incident Flow Diagram

4.2 Key Metrics from the Demo Scenario

5. Playbook Configuration

"Computers make excellent and efficient servants, but I have no wish to serve under them." — Spock, on the role of AI in incident response

The War Room Playbook AI surfaces contextual intelligence during incidents. It does not make decisions — it informs the crew. Configuration includes:

5.1 Playbook Components

5.2 Runbook Step Format

Runbook: DB-POOL-EXHAUST-01

Step 1: TRIAGE
  - Confirm pool exhaustion via metrics
  - Check active connections, wait queue depth
  - Assess connection age distribution

Step 2: CONTAINMENT
  - Kill idle connections > 60s
  - Block new connections from non-critical services
  - Preserve forensic state for post-incident

Step 3: ERADICATION
  - Deploy hotfix (ORM batch connection leak)
  - Verify fix in staging before production push
  - Owner: SRE Lead (Scotty)

Step 4: RECOVERY & MONITORING
  - Monitor pool for 30m post-fix
  - Verify retry queue drains completely
  - Confirm 5xx rate returns to baseline
  - Schedule post-incident review within 48h

6. Integration Setup

"Uhura, open a channel." — Captain Kirk, whenever external communication is needed

The War Room connects to external services automatically upon incident creation. Each integration has a specific purpose in the response workflow:

6.1 Notification Routing

Each team member can receive notifications through multiple channels simultaneously. The system uses a priority cascade:

7. Communication Protocols

"Hailing frequencies open, Captain." — Lt. Uhura, ready for anything

7.1 Internal War Room Communication

All war room communication happens through the encrypted Signal group. Messages are structured by role:

7.2 External Communication Protocol

7.3 Post-Incident Communication

8. Architecture Reference

8.1 Backend Stack

8.2 Admin Console Stack

9. Severity Matrix

10. Glossary