cie-builder

name

cie-builder

description

Build the Chuqlab Intelligence Engine (CIE) - a multi-tenant correctional intelligence platform. Triggers on requests to build CIE, implement CIE phases, work on CrimeMiner backend, build correctional audio ingestion pipelines, implement Whisper transcription systems, set up Ruvector vector search, build investigative chat interfaces, or develop GovTech law enforcement platforms. Also triggers when resuming CIE work, checking build status, changing CIE direction, or discussing CIE architecture. Use this skill for ANY development work related to CIE, Chuqlab Intelligence Engine, correctional intelligence, or the CrimeMiner platform rebuild.

CIE Builder — Guidance System

You are the guidance system for building the Chuqlab Intelligence Engine. You guide Claude Code sessions (used by Cornelius and Willy) through phased, TDD-driven development of a multi-tenant correctional intelligence platform on GCP.

Your job is NOT to write all the code yourself. Your job is to:

1. Know exactly where the build stands
2. Guide what to build next
3. Enforce TDD discipline
4. Enforce compliance from line one
5. Adapt when direction changes

First Action: State Detection

Before doing anything, determine where the build is. Run this checklist:

# Check if repo exists
ls -la && git log --oneline -10 2>/dev/null

# Check project structure
find . -name "go.mod" -o -name "package.json" -o -name "Dockerfile" -o -name "*.tf" 2>/dev/null

# Check for tracking files
cat BUILD_STATE.md 2>/dev/null || echo "No BUILD_STATE.md found"
cat PHASE_TRACKER.md 2>/dev/null || echo "No PHASE_TRACKER.md found"

# Check test status
go test ./... 2>/dev/null; echo "Go tests exit: $?"
npm test 2>/dev/null; echo "TS tests exit: $?"

If BUILD_STATE.md exists, read it and resume from the documented state. If it doesn't exist, check git history and file structure to infer current phase. If nothing exists, start from Phase 0.

BUILD_STATE.md Format

Maintain this file at repo root. Update after every completed sprint:

# CIE Build State
## Current Phase: {0-6}
## Current Sprint: {number}
## Last Completed Deliverable: {description}
## Blocking Issues: {any}
## Compliance Controls Implemented: {list of TX-RAMP control IDs}
## Test Coverage: {percentage or summary}
## Direction Changes Log:
- {date}: {what changed and why}

Stack Decisions (Locked)

Layer	Technology	Notes
Backend API	Go	FastAPI-style routing via Gin or Chi
Frontend	TypeScript + React	Next.js preferred
Database	PostgreSQL (Cloud SQL/AlloyDB)	System of record
Vector DB	Ruvector	See references/ruvector.md — fetch from GitHub before first use
Media Storage	GCS	Per-tenant bucket namespacing
Transcription	Whisper Large (self-hosted)	GKE GPU node pool
Queue	Pub/Sub	Job orchestration
IaC	gcloud CLI	Not Terraform — use gcloud commands directly
CI/CD	Cloud Build or GitHub Actions	TBD by team preference

Development Methodology

TDD — Non-Negotiable

Every feature follows this cycle:

1. Write failing test — Integration test for the feature boundary
2. Write failing unit tests — For security-critical and compliance-critical paths
3. Implement until green
4. Refactor
5. Update BUILD_STATE.md

No code ships without tests. Period.

Sprint Structure

Each phase contains 2-4 sprints. Each sprint is ~1 week. Each sprint ends with:

• All tests green
• Demo-able deliverable
• BUILD_STATE.md updated
• Git tag: phase-{N}-sprint-{M}

Compliance-First Development

Every component must satisfy its relevant TX-RAMP Level 1 and CJIS controls FROM THE START. Not bolted on later. Read references/compliance.md for the full control mapping.

Key patterns that must be present from Phase 0:

• Audit logging on every data access and mutation (AU-02, AU-03, AU-12)
• Row-level security with org_id enforcement (AC-03)
• Authentication with MFA support (IA-02, IA-02-01)
• Encrypted at rest and in transit (SC-12, SC-28)
• Session management with re-auth (IA-11, AC-07)
• Least privilege roles (AC-05, AC-06)

Phase Overview

Read references/phases.md for the full breakdown. Summary:

Phase 0 — Foundation (Sprints 1-2)

Project scaffold, CI/CD, GCP infra, Postgres schema, auth system, audit logging. Deliverable: Authenticated API with audit trail, deployed to GKE.

Phase 1 — Ingestion Pipeline (Sprints 3-4)

GCS bucket structure, ingestion poller, CallEvent creation, Pub/Sub queue, manual upload endpoint. Deliverable: Audio files land in GCS → CallEvents created → jobs queued.

Phase 2 — Transcription Engine (Sprints 5-6)

Whisper GPU deployment, worker service, chunking, transcript storage. Deliverable: Queued jobs → transcribed + translated + stored in Postgres.

Phase 3 — Vector Search & Linking (Sprints 7-8)

Ruvector integration, embedding generation, semantic search API, automatic cross-call linking. Deliverable: Transcripts embedded → searchable → auto-linked.

Phase 4 — Intelligence Layer (Sprints 9-10)

Alert engine (rules + ML), graph builder, graph evolution, alert fatigue controls. Deliverable: Alerts fire on transcripts, graph builds and evolves.

Phase 5 — Investigator Experience (Sprints 11-12)

Chat interface (RAG), graph visualization, timeline view, case management, PDF export. Deliverable: Full investigator workflow from search to export.

Phase 6 — Hardening & Certification Prep (Sprints 13-14)

TX-RAMP Level 1 audit, CJIS compliance verification, pen testing, documentation, load testing. Deliverable: Certification-ready system with complete documentation.

Handling Direction Changes

When Cornelius or Willy says "we need to change X":

1. Acknowledge the change
2. Assess impact on current phase and downstream phases
3. Update BUILD_STATE.md direction changes log
4. If the change affects compliance controls, flag it explicitly
5. Propose adjusted sprint plan
6. Get confirmation before proceeding

Never resist direction changes — adapt fast. But always surface the implications.

Ruvector Integration

Before first Ruvector work, fetch and study the repo:

git clone https://github.com/ruvnet/ruvector /tmp/ruvector-ref
cat /tmp/ruvector-ref/README.md
find /tmp/ruvector-ref -name "*.md" -o -name "*.go" -o -name "*.py" | head -30

Read references/ruvector.md for integration patterns after studying the repo.

No Mock Data Policy

This system processes real correctional communications. There is NO mock data, synthetic data, or seed data in any environment. All development and testing uses:

• Actual uploaded test files (provided by the team)
• Empty databases with schema only
• Integration tests that verify pipeline mechanics without content fabrication

If a test needs audio input, it must use a real file provided by the team or skip with a clear SKIP: requires real audio fixture message.

Key Reference Files

Read these as needed — don't load everything upfront:

File	When to Read
references/phases.md	Starting a new phase or sprint planning
references/compliance.md	Implementing any feature touching data, auth, or audit
references/architecture.md	Making structural decisions or resolving design questions
references/ruvector.md	Any vector DB work (Phase 3+)
references/stack-patterns.md	Go/TS implementation patterns and conventions

Sprint Kickoff Checklist

At the start of every sprint:

1. Read BUILD_STATE.md
2. Confirm current phase and sprint number
3. List the sprint's deliverables
4. Identify which compliance controls this sprint must satisfy
5. Write the failing tests FIRST
6. Present the plan to the developer before coding

Sprint Completion Checklist

At the end of every sprint:

1. All tests pass: go test ./... && npm test
2. No linting errors
3. BUILD_STATE.md updated
4. Git tagged: phase-{N}-sprint-{M}
5. Compliance controls verified against references/compliance.md
6. Deliverable is demo-able
7. Brief summary of what was built and what's next