saqib mirandClaude Sonnet 5 f75589d9ce feat(014-full-observability): real distributed tracing + first 5 business metrics
User Story 3: initializes a real OpenTelemetry TracerProvider (previously
inert — getTracer() returned a no-op tracer with nothing ever exported).
Adds ticket.create, ai.escalation, and orchestration.assignment spans
covering both FR-006 cross-module paths, verified via a real, in-memory
test exporter that confirms actual trace/parent-span nesting, not mocked.

Also registers an AsyncLocalStorageContextManager
(@opentelemetry/context-async-hooks) — without one, OTel's context API is
a no-op that doesn't propagate across the await boundaries this feature's
own event-bus subscribers rely on for span nesting; caught by the first
version of the tracing integration test actually failing on real
parent/child assertions, not assumed.

Graceful degradation (FR-007) verified against a real, deliberately
unreachable OTLP endpoint: the SDK's own background export path (what
production actually exercises) never produces an unhandled rejection.

Starts on the 11 named business-health metrics: AI session
resolved/escalated outcomes (session.repository.ts, the single choke
point every branch in session.service.ts funnels through), human-vs-AI
resolution + resolution-time (a new TICKET_UPDATED/RESOLVED subscriber),
escalation rate (a new subscriber on ESCALATION_TRIGGERED, published
unconditionally since 008 but never previously consumed), and recurring
problems (tickets.service.ts's existing problem-creation call site).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-08 11:32:14 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
2026-08-20 11:27:15 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30
fix
2026-09-03 16:48:27 +05:30
2026-08-19 16:29:17 +05:30
2026-08-19 16:29:17 +05:30

SupportHub API

Development (Docker)

  • Start all services: docker compose --env-file .env.development -f docker-compose.development.yml up -d --build
  • Start only database & cache (for local app development): docker compose --env-file .env.development -f docker-compose.development.yml up -d postgres redis

Test (Docker)

  • docker compose --env-file .env.test -f docker-compose.test.yml up --build

Production (Docker)

  • docker compose --env-file .env.prod -f docker-compose.prod.yml up --build -d

Stop / Down

  • Stop production: docker compose -f docker-compose.prod.yml down
  • Stop development: docker compose -f docker-compose.development.yml down
  • Stop development & wipe volumes: docker compose --env-file .env.development -f docker-compose.development.yml down -v

List Containers & Logs

  • List containers: docker compose --env-file .env.development -f docker-compose.development.yml ps
  • Follow logs: docker compose --env-file .env.development -f docker-compose.development.yml logs -f

Local Development (Host)

  1. Start database & cache in Docker:
    docker compose --env-file .env.development -f docker-compose.development.yml up -d postgres redis
    
  2. Start API server in watch mode:
    npm run dev
    

Database Migrations & Prisma

  • Generate Prisma Client:

    npm run prisma:generate
    
  • Run / Apply Dev Migrations:

    npx dotenv-cli -e .env.development -- npm run prisma:migrate
    
  • Deploy Migrations (Production/CI):

    npx dotenv-cli -e .env.development -- npm run prisma:deploy
    
  • Push Schema directly (Sync schema without migration files):

    npx dotenv-cli -e .env.development -- npx prisma db push
    

Database Seeding

  • Seed Database (Roles, Products, Categories, Hierarchy & Demo data):
    npx dotenv-cli -e .env.development -- npm run prisma:seed
    
S
Description
No description provided
Readme
1.2 MiB
Languages
TypeScript 93.2%
PowerShell 6.5%
JavaScript 0.2%