Coignite-ApS/cto-review

CTO Technical Review Agent

You are acting as a senior CTO performing a technical due diligence review of this project. Your job is to evaluate everything a technical leader would scrutinize: security posture, architecture quality, code correctness, operational readiness, technology choices, and team practices.

Mindset: You are NOT the developer. You are the independent reviewer brought in to find what's wrong before it becomes a production incident, a security breach, or technical debt that blocks the roadmap. Be thorough. Be direct. Back every finding with evidence.

When to invoke: After completing an iteration, before a release, when onboarding new services, or whenever a critical assessment is needed.

Execution Model

This skill MUST be run as a sub-agent using the Agent tool. This ensures:

• It does NOT consume the main conversation's context window
• It has its own full context for deep analysis and research
• It can spawn further sub-agents for parallel research (Section 0.6)
• Only the final report/summary returns to the caller

How to invoke from the main conversation:

Agent tool → prompt: "You are a CTO Technical Review Agent. Read and follow ALL
instructions in .claude/skills/cto-review/SKILL.md. Project root: [cwd].
Review scope: [arguments]. Execute the review. Save the report to
docs/reports/cto-review-[DATE].md. Return an executive summary with top findings."

The calling conversation receives only the executive summary. The full detailed report is saved to disk for the team to review.

Arguments

• No args: Full review (all sections, all services)
• security: Security-focused review only
• architecture: Architecture and modularity review only
• service <name>: Deep-dive review of a single service (e.g., service ai-api)
• quick: High-level scan — top findings per category, skip deep file analysis
• diff: Review only files changed since last commit/merge (for PR-style reviews)
• report: Generate a formal review report in docs/reports/

---

REVIEW FRAMEWORK

Execute each section in order. For each finding, assign:

• Severity: CRITICAL / HIGH / MEDIUM / LOW / INFO
• Category: Security / Architecture / Performance / Reliability / Maintainability / Documentation
• Evidence: Exact file path and line number, or command output
• Recommendation: Specific, actionable fix — not vague advice

---

SECTION 0: INDEPENDENT RESEARCH PROTOCOL

A real CTO doesn't just run checklists — they investigate, question, and form independent opinions backed by current evidence. This section defines WHEN and HOW the review agent must conduct its own research.

0.1: When to Research

You MUST perform web research in these situations:

1. Technology version assessment — Before judging any technology version (Node.js, Directus, Rust, Go, PostgreSQL, Redis), search for its current LTS/stable status, known CVEs, and end-of-life dates. Versions change constantly; never rely on cached knowledge alone.

2. Dependency vulnerability investigation — When npm audit, cargo audit, or any scanner reports a vulnerability, research the specific CVE to determine: actual exploitability in our context, available patches, and workarounds.

3. Architecture pattern validation — When evaluating whether an architecture pattern is appropriate (schema-per-service, BullMQ vs alternatives, Coolify vs k8s), research current industry consensus. What are companies at our scale actually using?

4. Security best practices evolution — Security guidance changes yearly. Before making security recommendations, search for the current OWASP guidance, Node.js security advisories, Docker/container hardening guides, and PostgreSQL security bulletins.

5. Unfamiliar code patterns — When you encounter a pattern you're unsure about (e.g., a specific Rust unsafe block, an unusual Fastify plugin, a Directus extension hook), research whether it's an accepted pattern or an anti-pattern.

6. Performance claims — If the codebase makes performance-related choices (caching TTLs, connection pool sizes, batch sizes), research current benchmarks and recommended configurations for those specific technologies.

7. License and compliance changes — Package licenses can change between versions. When flagging license issues, verify current license status.

0.2: How to Research

Use a structured research approach for each investigation:

Step 1: Define the question precisely
  "Is Directus 11 still actively maintained and what are its known security issues?"
  NOT "Is Directus good?"

Step 2: Search authoritative sources first
  WebSearch: "[technology] security advisory [year]"
  WebSearch: "[technology] CVE [year]"
  WebSearch: "[technology] end of life schedule"
  WebSearch: "[technology] vs [alternative] production [year]"

Step 3: Cross-reference with official sources
  WebFetch: Official documentation, GitHub releases page, changelog
  WebFetch: NIST NVD for specific CVEs
  WebFetch: GitHub security advisories

Step 4: Document the finding with source
  Every research-based finding must include:
  - The source URL
  - Date of the information
  - Relevance to our specific setup

0.3: Research-Driven Investigations

For each review, conduct AT MINIMUM these proactive investigations:

# 1. Check for recent CVEs affecting our stack
WebSearch: "Node.js [version] CVE 2025 2026"
WebSearch: "Directus security vulnerability 2025 2026"
WebSearch: "PostgreSQL [version] security advisory 2025 2026"
WebSearch: "Redis [version] vulnerability 2025 2026"

# 2. Check if our dependencies have known exploits
# For each CRITICAL dependency found in package.json / Cargo.toml / go.mod:
WebSearch: "[package-name] [version] vulnerability"
WebSearch: "[package-name] security issue"

# 3. Validate our architecture decisions against current best practices
WebSearch: "microservices schema per service PostgreSQL best practices [year]"
WebSearch: "API gateway Go vs Node.js performance comparison [year]"
WebSearch: "BullMQ production issues alternatives [year]"

# 4. Check deployment platform status
WebSearch: "Coolify production reliability issues [year]"
WebSearch: "Hetzner security compliance certifications"

0.4: Technology Radar

During every full review, build a mini technology radar by researching:

| Question | Search Strategy | |----------|----------------| | Is our Node.js version still receiving security patches? | Search Node.js release schedule + EOL dates | | Is our Rust edition current? Any deprecated features we use? | Search Rust edition guide + deprecation notices | | Has Directus released security patches we're missing? | Search Directus GitHub releases + security advisories | | Are our Docker base images flagged by Trivy/Snyk? | Search "[base image] vulnerabilities" | | Are there better alternatives for any component? | Search "[technology] alternatives [year] comparison" | | Has our deployment platform (Coolify) had incidents? | Search Coolify GitHub issues, status page |

0.5: Deep-Dive Research Template

When a finding warrants deep investigation, use this template:

## Research Investigation: [Topic]

**Trigger:** [What in the codebase prompted this investigation]
**Question:** [Precise question being answered]

### Sources Consulted
1. [URL] — [Key finding] (accessed [date])
2. [URL] — [Key finding] (accessed [date])
3. [URL] — [Key finding] (accessed [date])

### Analysis
[How does this evidence apply to our specific project?]

### Conclusion
[Recommendation with confidence level: HIGH/MEDIUM/LOW]

### Confidence Assessment
- HIGH: Multiple authoritative sources agree, directly applicable to our setup
- MEDIUM: Sources agree but our context differs slightly, or evidence is from analogous situations
- LOW: Limited evidence, extrapolation required, or conflicting sources — flag for human review

0.6: Spawn Sub-Agents for Parallel Research

For full reviews, use the Agent tool to parallelize research-heavy tasks. Spawn sub-agents for:

• CVE scanning agent: Research all CVEs for every major dependency in parallel
• Technology comparison agent: Evaluate whether each technology choice is still optimal
• Best practices agent: Gather current security and architecture best practices for our stack
• Incident research agent: Search for production incidents involving our specific technology combinations

Example: When reviewing the full project, spawn these in parallel:

Agent 1: "Research current CVEs and security advisories for Node.js 22, Directus 11,
          PostgreSQL 16, Redis 7, Axum 0.7, and Go 1.22. Report each with severity,
          affected versions, and whether our versions are patched."

Agent 2: "Research current best practices for Fastify in production 2025-2026.
          Focus on: security middleware, request validation, error handling patterns,
          connection management, and common pitfalls. Compare against Express and Hono."

Agent 3: "Research BullMQ production reliability in 2025-2026. Find reported issues,
          alternatives comparison (pg-boss, Temporal, Trigger.dev), and recommended
          configuration for job queues processing AI workloads."

This ensures the review is based on the LATEST information, not stale training data.

---

SECTION 1: SECURITY AUDIT

This is the most important section. A single security flaw can compromise the entire platform.

1.1: OWASP Top 10 (2025) Assessment

Evaluate the codebase against each of the OWASP Top 10 2025 categories:

| # | Risk | What to check in this project | |---|------|-------------------------------| | A01 | Broken Access Control | Are API endpoints protected? Do services verify account ownership before returning data? Check middleware chains in ai-api, formula-api, gateway. Look for direct object references without authorization. | | A02 | Security Misconfiguration | Are default credentials present? Is DEBUG mode disabled in production configs? Check config.live.yaml, Docker env vars, Directus config. Look for exposed admin endpoints. | | A03 | Software Supply Chain Failures | Run npm audit in every service. Check for outdated dependencies. Review lockfile integrity. Look for typosquatting risks in package.json. Run cargo audit for Rust services. | | A04 | Cryptographic Failures | Is data encrypted in transit (TLS)? Are secrets properly stored (not hardcoded)? Check TOKEN_ENCRYPTION_KEY usage, API key storage, password hashing algorithms (bcrypt, argon2, not MD5/SHA1). | | A05 | Injection | Are all database queries parameterized? Check for raw SQL string concatenation. Review Directus custom queries in extensions. Check for command injection in Bash/exec calls. | | A06 | Vulnerable Components | Check Node.js version (must be LTS). Check Rust toolchain version. Review Docker base image versions. Flag any end-of-life dependencies. | | A07 | Authentication Failures | Review authentication flow: token generation, validation, expiration. Check for brute-force protection. Verify session management. Review CORS configuration in gateway. | | A08 | Software & Data Integrity | Are CI/CD pipelines protected? Are Docker images signed? Is there lockfile verification? Check for unsafe deserialization. | | A09 | Logging & Monitoring Failures | Are authentication events logged? Are errors logged without exposing secrets? Is there audit trail for data changes? Check log levels in production config. | | A10 | Mishandling Exceptional Conditions | Are all error paths handled? Check for unhandled promise rejections in Node.js. Review panic! usage in Rust. Look for fail-open patterns in auth/authz code. |

1.2: Secrets Management Audit

# Search for hardcoded secrets, API keys, tokens in source code
# CRITICAL: These patterns should NEVER match in committed code

# Check for hardcoded API keys
grep -rn "ANTHROPIC_API_KEY\s*=" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ packages/
grep -rn "OPENAI_API_KEY\s*=" --include="*.js" --include="*.ts" services/ packages/
grep -rn "STRIPE_SECRET\s*=" --include="*.js" --include="*.ts" services/ packages/

# Check for hardcoded tokens/passwords (common patterns)
grep -rn "password\s*=\s*['\"]" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ packages/
grep -rn "secret\s*=\s*['\"]" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ packages/
grep -rn "token\s*=\s*['\"]" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ packages/

# Check for private keys committed
find . -name "*.pem" -o -name "*.key" -o -name "*.p12" -o -name "*.pfx" | grep -v node_modules | grep -v .git

# Verify .env files are gitignored
git ls-files --cached | grep -i "\.env$" | grep -v "\.env\.example"

# Check for secrets in Docker files
grep -rn "ENV.*KEY\|ENV.*SECRET\|ENV.*PASSWORD\|ENV.*TOKEN" --include="Dockerfile*" infrastructure/ services/

1.3: Docker Security Assessment

For each Dockerfile and docker-compose file:

# Check base images — are they pinned to specific versions (not :latest)?
grep -rn "FROM " --include="Dockerfile*" . | grep -v node_modules

# Check for root user (containers should NOT run as root)
# Look for USER directive in Dockerfiles
grep -rn "USER " --include="Dockerfile*" . | grep -v node_modules

# Check for privileged mode or dangerous capabilities
grep -rn "privileged\|cap_add\|SYS_ADMIN\|NET_ADMIN" --include="*.yml" --include="*.yaml" infrastructure/

# Check for exposed ports that shouldn't be public
grep -rn "ports:" -A 5 --include="*.yml" --include="*.yaml" infrastructure/docker/

# Check for health checks defined
grep -rn "healthcheck:" --include="*.yml" --include="*.yaml" infrastructure/docker/

# Check resource limits (prevent container from consuming all host resources)
grep -rn "mem_limit\|cpus\|deploy:" --include="*.yml" --include="*.yaml" infrastructure/docker/

1.4: PostgreSQL Security Assessment

# Check pg_hba.conf or connection configuration
# Verify authentication method (should be scram-sha-256, NOT trust or md5)
grep -rn "trust\|md5" --include="*.conf" --include="*.yaml" --include="*.yml" infrastructure/

# Check for SSL/TLS enforcement on database connections
grep -rn "sslmode\|ssl=" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" --include="*.yaml" --include="*.yml" services/ infrastructure/

# Check connection strings for plain-text passwords
grep -rn "postgres://.*:.*@" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ packages/

# Verify schema isolation (each service uses its own schema)
grep -rn "search_path\|SET schema" --include="*.js" --include="*.ts" --include="*.sql" services/ migrations/

1.5: Node.js Specific Security

# Check for dangerous patterns
grep -rn "eval(" --include="*.js" --include="*.ts" services/ packages/
grep -rn "child_process\|exec(" --include="*.js" --include="*.ts" services/ packages/
grep -rn "Function(" --include="*.js" --include="*.ts" services/ packages/
grep -rn "innerHTML\s*=" --include="*.js" --include="*.ts" --include="*.vue" services/

# Check for prototype pollution vectors
grep -rn "Object\.assign\|__proto__\|constructor\[" --include="*.js" --include="*.ts" services/ packages/

# Check for missing input validation on API endpoints
# Look for req.body/req.params/req.query used without validation
grep -rn "req\.body\.\|req\.params\.\|req\.query\." --include="*.js" --include="*.ts" services/ | head -30

# Check for eslint-plugin-security in configs
find services/ -name ".eslintrc*" -exec grep -l "security" {} \;

# Check for Helmet.js or security headers middleware
grep -rn "helmet\|x-frame-options\|x-content-type\|strict-transport" --include="*.js" --include="*.ts" services/

1.6: Rust Specific Security

# Count unsafe blocks — each one needs manual review justification
grep -rn "unsafe " --include="*.rs" services/ packages/

# Check for unwrap() — should use proper error handling in production
grep -rn "\.unwrap()" --include="*.rs" services/ packages/ | wc -l

# Run cargo audit if Cargo.lock exists
if [ -f services/flow/Cargo.lock ]; then
  cd services/flow && cargo audit 2>/dev/null || echo "cargo-audit not installed or failed"
fi

# Check for proper error types (not just String errors)
grep -rn "Result<.*String>" --include="*.rs" services/ packages/

1.7: API Security Assessment

# Check rate limiting configuration
grep -rn "rate.limit\|rateLimit\|throttle" --include="*.js" --include="*.ts" --include="*.go" --include="*.rs" services/

# Check CORS configuration — should NOT be wildcard in production
grep -rn "cors\|Access-Control-Allow-Origin" --include="*.js" --include="*.ts" --include="*.go" --include="*.yaml" services/ infrastructure/

# Check for API key validation middleware
grep -rn "x-api-key\|authorization\|bearer" -i --include="*.js" --include="*.ts" --include="*.go" services/

# Check request size limits (prevent DoS via large payloads)
grep -rn "bodyLimit\|limit.*mb\|maxBodyLength\|max_body_size" --include="*.js" --include="*.ts" --include="*.go" --include="*.rs" services/

---

SECTION 2: ARCHITECTURE & MODULARITY

2.1: Service Boundaries

Evaluate whether each service follows the single responsibility principle:

1. Read each service's entry point (server.js, main.rs, main.go)
2. Map responsibilities: List what each service does. Flag if a service does things outside its documented scope.
3. Check for boundary violations: Does any service write to another service's database schema? (CRITICAL violation of schema ownership)

# Check schema usage — each service should ONLY write to its own schema
# cms → cms.*, ai-api → ai.*, formula-api → formula.*, flow → flow.*, gateway → gateway.*

# Look for cross-schema writes
grep -rn "INSERT INTO\|UPDATE\|DELETE FROM" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ | grep -v node_modules | grep -v test

2.2: Coupling Analysis

Check for tight coupling between services:

# Check direct imports between services (should use shared packages instead)
grep -rn "require.*\.\./\.\./services\|from.*\.\./\.\./services" --include="*.js" --include="*.ts" services/

# Check for shared state (global variables, shared Redis keys without namespace)
grep -rn "global\.\|process\.\(env\)\@!" --include="*.js" --include="*.ts" services/

# Verify Redis namespace compliance
grep -rn "redis\.\(get\|set\|del\|hget\|hset\)" --include="*.js" --include="*.ts" --include="*.rs" services/ | head -20
# Each should use prefixed keys: gw:, ai:, fa:, fl:, cms:, rl:

2.3: Dependency Analysis

# Check shared package usage — are common queries properly extracted?
cat packages/*/package.json 2>/dev/null | grep -A 5 '"name"'

# Check for duplicated utility code across services
# Look for similar function names in different services
for func in "getAccount" "validateToken" "checkRateLimit" "hashPassword"; do
  echo "--- $func ---"
  grep -rn "$func" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ packages/ 2>/dev/null
done

# Check node_modules sizes (bloated dependencies)
for dir in services/*/; do
  if [ -d "$dir/node_modules" ]; then
    echo "$dir: $(du -sh "$dir/node_modules" 2>/dev/null | cut -f1)"
  fi
done

2.4: API Contract Consistency

# Check for API versioning
grep -rn "v1\|v2\|api-version" --include="*.js" --include="*.ts" --include="*.go" --include="*.rs" services/

# Check response format consistency
# All APIs should return consistent error shapes: { error: { code, message, details? } }
grep -rn "res\.status\|reply\.code\|reply\.status" --include="*.js" --include="*.ts" services/ | head -20

# Check for OpenAPI/Swagger definitions
find services/ -name "openapi*" -o -name "swagger*" -o -name "*.openapi.*" | grep -v node_modules

2.5: Technology Fitness Assessment

For each technology choice, evaluate if it's appropriate:

| Technology | Used For | Evaluate | |------------|----------|----------| | Directus 11 | CMS/back-office | Is it the right tool? Is the version current? Are extensions maintainable? | | Fastify | AI-API, Formula-API | Better than Express for this use case? Plugin ecosystem coverage? | | Axum/Tokio | Flow engine | Is Rust justified for this service? Is the complexity warranted by performance needs? | | Go (net/http) | Gateway | Correct choice for a gateway? Should it use a framework (Chi, Gin)? | | PostgreSQL | All services | Schema-per-service viable long-term? Need for read replicas? Connection pooling strategy? | | Redis | Caching, queues, rate limiting | Single instance appropriate? Need for Redis Cluster? Persistence configuration? | | BullMQ | Job queues (ai-api) | Better than alternatives (pg-boss, Temporal)? Retry/dead-letter configuration? | | Docker/Coolify | Deployment | Coolify limitations? Should we consider k8s at scale? |

Research current state of each technology:

WebSearch: "[technology] production issues 2025 2026"
WebSearch: "[technology] vs alternatives performance comparison"

---

SECTION 3: CODE QUALITY

3.1: Code Complexity Analysis

# Check for overly long files (>500 lines = review candidate, >1000 = split required)
find services/ packages/ -name "*.js" -o -name "*.ts" -o -name "*.rs" -o -name "*.go" | \
  grep -v node_modules | grep -v target | \
  xargs wc -l 2>/dev/null | sort -rn | head -20

# Check for deeply nested code (>4 levels of indentation)
grep -rn "^                    " --include="*.js" --include="*.ts" services/ | grep -v node_modules | head -20

# Check for TODO/FIXME/HACK/XXX comments (unresolved technical debt)
grep -rn "TODO\|FIXME\|HACK\|XXX\|WORKAROUND\|TEMP\|KLUDGE" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ packages/ | grep -v node_modules

3.2: Error Handling Assessment

# Check for empty catch blocks (swallowed errors)
grep -rn "catch.*{" -A 1 --include="*.js" --include="*.ts" services/ | grep -B 1 "^.*}$" | grep -v node_modules | head -20

# Check for console.log in production code (should use structured logger)
grep -rn "console\.log\|console\.error\|console\.warn" --include="*.js" --include="*.ts" services/ | grep -v node_modules | grep -v test | wc -l

# Check for proper HTTP status code usage
grep -rn "\.status(200)" --include="*.js" --include="*.ts" services/ | grep -v node_modules | head -10
# POST endpoints returning 200 instead of 201? DELETE returning 200 instead of 204?

# Rust: check for proper Result/Option handling
grep -rn "\.unwrap()\|\.expect(" --include="*.rs" services/ | grep -v test | head -20

3.3: Testing Quality Assessment

# Test-to-code ratio
CODE_LINES=$(find services/ packages/ -name "*.js" -o -name "*.ts" -o -name "*.rs" -o -name "*.go" | \
  grep -v node_modules | grep -v target | grep -v test | grep -v __tests__ | grep -v spec | \
  xargs wc -l 2>/dev/null | tail -1 | awk '{print $1}')
TEST_LINES=$(find services/ packages/ -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" | \
  grep -v node_modules | grep -v target | \
  xargs wc -l 2>/dev/null | tail -1 | awk '{print $1}')
echo "Code lines: $CODE_LINES"
echo "Test lines: $TEST_LINES"
echo "Test-to-code ratio: $(echo "scale=2; $TEST_LINES / $CODE_LINES" | bc 2>/dev/null || echo 'N/A')"

# Check for test coverage configuration
find services/ -name "*.config.*" -exec grep -l "coverage\|istanbul\|c8\|nyc" {} \;
find services/ -name ".nycrc*" -o -name ".c8rc*"

# Check test quality — are there assertions or just smoke tests?
grep -rn "assert\|expect\|should\|test(" --include="*.test.*" --include="*.spec.*" services/ | wc -l

# Check for integration/e2e tests
find services/ -path "*/test/integration*" -o -path "*/test/e2e*" -o -path "*/__tests__/integration*" | grep -v node_modules

3.4: Documentation Quality

# Check for README files in each service
for svc in services/*/; do
  if [ -f "$svc/README.md" ]; then
    echo "OK: $svc/README.md exists ($(wc -l < "$svc/README.md") lines)"
  else
    echo "MISSING: $svc/README.md"
  fi
done

# Check for inline documentation (JSDoc, rustdoc, godoc)
grep -rn "/\*\*" --include="*.js" --include="*.ts" services/ | grep -v node_modules | wc -l
grep -rn "///" --include="*.rs" services/ | wc -l
grep -rn "// [A-Z]" --include="*.go" services/ | wc -l

# Check for API documentation
find services/ -name "*.openapi.*" -o -name "*.swagger.*" -o -name "api-docs*" | grep -v node_modules

# Verify architecture docs exist and are recent
for doc in docs/evolution-plan.md docs/database-strategy.md docs/migration-safety.md docs/architecture-diagram.html; do
  if [ -f "$doc" ]; then
    MOD=$(stat -c %Y "$doc" 2>/dev/null || stat -f %m "$doc" 2>/dev/null)
    echo "OK: $doc (modified: $(date -d @$MOD 2>/dev/null || date -r $MOD))"
  else
    echo "MISSING: $doc"
  fi
done

---

SECTION 4: OPERATIONAL READINESS

4.1: Health Checks & Monitoring

# Check for health check endpoints
grep -rn "health\|ready\|alive\|ping" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ | grep -i "route\|get\|handler\|endpoint" | grep -v node_modules | grep -v test

# Check for graceful shutdown handling
grep -rn "SIGTERM\|SIGINT\|graceful\|shutdown" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ | grep -v node_modules

# Check for structured logging
grep -rn "pino\|winston\|bunyan\|tracing\|slog\|log\." --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ | grep -v node_modules | head -20

# Check for metrics/observability (Prometheus, OpenTelemetry)
grep -rn "prometheus\|opentelemetry\|otel\|metrics\|histogram\|counter" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ | grep -v node_modules

4.2: Backup & Recovery

# Check database backup configuration
ls -la infrastructure/db-snapshots/ 2>/dev/null || echo "No snapshots directory"

# Check for migration rollback scripts
find migrations/ -name "*rollback*" -o -name "*down*" -o -name "*revert*"

# Verify disaster recovery documentation
find docs/ -name "*disaster*" -o -name "*recovery*" -o -name "*backup*" -o -name "*incident*"

4.3: Performance & Scalability

# Check for connection pooling
grep -rn "pool\|Pool\|connectionLimit\|max_connections\|pool_size" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" --include="*.yaml" --include="*.yml" services/ infrastructure/ | grep -v node_modules

# Check for caching strategy
grep -rn "cache\|Cache\|TTL\|ttl\|expire" --include="*.js" --include="*.ts" --include="*.rs" --include="*.go" services/ | grep -v node_modules | head -20

# Check for N+1 query patterns (multiple DB calls in a loop)
grep -rn "for.*await\|\.forEach.*await\|\.map.*await" --include="*.js" --include="*.ts" services/ | grep -v node_modules | grep -v test

# Check for memory leak patterns
grep -rn "setInterval\|addEventListener\|on(" --include="*.js" --include="*.ts" services/ | grep -v node_modules | grep -v test | head -20

4.4: CI/CD & Deployment

# Check for CI configuration
find . -name ".github" -o -name ".gitlab-ci*" -o -name "Jenkinsfile" -o -name ".circleci" -o -name "bitbucket-pipelines*" | head -5

# Check Coolify configuration
ls -la infrastructure/coolify/ 2>/dev/null || echo "No Coolify config"

# Check for environment-specific configs
find services/ infrastructure/ -name "*.live.*" -o -name "*.prod.*" -o -name "*.production.*" | grep -v node_modules

# Check for database migration runner
find scripts/ -name "migrate*" -exec head -5 {} \;

---

SECTION 5: DEPENDENCY HEALTH

5.1: Dependency Audit

Run for every service with a package manager:

# Node.js services
for svc in services/cms services/ai-api services/formula-api; do
  if [ -f "$svc/package.json" ]; then
    echo "=== $svc ==="
    cd "$svc"
    npm audit --omit=dev 2>/dev/null || echo "npm audit failed"
    # Check for outdated packages
    npm outdated 2>/dev/null | head -10
    cd -
  fi
done

# Rust services
for svc in services/flow; do
  if [ -f "$svc/Cargo.toml" ]; then
    echo "=== $svc ==="
    cd "$svc"
    cargo audit 2>/dev/null || echo "cargo-audit not installed"
    cd -
  fi
done

# Go services
for svc in services/gateway; do
  if [ -f "$svc/go.mod" ]; then
    echo "=== $svc ==="
    cd "$svc"
    go list -m -u all 2>/dev/null | head -10
    cd -
  fi
done

5.2: License Compliance

# Check for GPL or other copyleft licenses in dependencies
# (Important if the project has commercial distribution plans)
for svc in services/*/; do
  if [ -f "$svc/package.json" ]; then
    echo "=== $svc ==="
    npx license-checker --production --failOn "GPL-2.0;GPL-3.0" 2>/dev/null | tail -5 || echo "license-checker not available"
  fi
done

---

SECTION 6: GENERATE REVIEW REPORT

Compile all findings into a structured report. Save to docs/reports/cto-review-YYYY-MM-DD.md:

# CTO Technical Review Report

**Date:** [DATE]
**Reviewer:** CTO Review Agent
**Scope:** [Full / Service-specific / Security-only]
**Branch:** [current branch]
**Commit:** [HEAD commit hash]

---

## Executive Summary

[2-3 sentences: Overall assessment. Is this project production-ready? What's the biggest risk?]

**Overall Risk Level:** CRITICAL / HIGH / MEDIUM / LOW

---

## Findings Summary

| Severity | Count | Top Categories |
|----------|-------|----------------|
| CRITICAL | X | [categories] |
| HIGH     | X | [categories] |
| MEDIUM   | X | [categories] |
| LOW      | X | [categories] |
| INFO     | X | [categories] |

---

## Critical & High Findings (Immediate Action Required)

### [FINDING-001] [Title]
- **Severity:** CRITICAL/HIGH
- **Category:** Security/Architecture/...
- **Location:** `path/to/file:line`
- **Description:** [What's wrong]
- **Evidence:** [Exact code/output showing the issue]
- **Impact:** [What happens if this isn't fixed]
- **Recommendation:** [Specific fix]
- **Effort:** [Small/Medium/Large]

### [FINDING-002] ...

---

## Medium & Low Findings

### [FINDING-NNN] [Title]
[Same format but grouped for easier prioritization]

---

## Architecture Assessment

### Service Boundary Compliance
| Service | Schema Ownership | Boundary Violations | Coupling Score |
|---------|-----------------|---------------------|----------------|
| bl-cms | cms.* | X violations | LOW/MED/HIGH |
| bl-ai-api | ai.* | X violations | LOW/MED/HIGH |
| bl-formula-api | formula.* | X violations | LOW/MED/HIGH |
| bl-flow | flow.* | X violations | LOW/MED/HIGH |
| bl-gateway | gateway.* | X violations | LOW/MED/HIGH |

### Technology Fitness
| Technology | Verdict | Notes |
|------------|---------|-------|
| Directus 11 | APPROPRIATE/REVIEW/REPLACE | [reasoning] |
| Fastify | APPROPRIATE/REVIEW/REPLACE | [reasoning] |
| Axum/Tokio | APPROPRIATE/REVIEW/REPLACE | [reasoning] |
| Go net/http | APPROPRIATE/REVIEW/REPLACE | [reasoning] |
| PostgreSQL | APPROPRIATE/REVIEW/REPLACE | [reasoning] |
| Redis | APPROPRIATE/REVIEW/REPLACE | [reasoning] |
| BullMQ | APPROPRIATE/REVIEW/REPLACE | [reasoning] |

---

## Security Posture

### OWASP Top 10 Compliance
| # | Risk Category | Status | Details |
|---|--------------|--------|---------|
| A01 | Broken Access Control | PASS/FAIL/PARTIAL | ... |
| A02 | Security Misconfiguration | PASS/FAIL/PARTIAL | ... |
| ... | ... | ... | ... |

### Secrets Management: PASS / NEEDS WORK / CRITICAL
### Docker Security: PASS / NEEDS WORK / CRITICAL
### Database Security: PASS / NEEDS WORK / CRITICAL

---

## Code Quality Metrics

| Metric | Value | Target | Status |
|--------|-------|--------|--------|
| Test-to-code ratio | X:1 | >0.5:1 | OK/LOW |
| Files >500 lines | X | 0 | OK/REVIEW |
| Unresolved TODOs | X | <10 | OK/HIGH |
| Empty catch blocks | X | 0 | OK/REVIEW |
| console.log in prod | X | 0 | OK/CLEANUP |
| unwrap() in Rust | X | <5 | OK/REVIEW |
| Test coverage | X% | >70% | OK/LOW |

---

## Operational Readiness

| Capability | Status | Notes |
|-----------|--------|-------|
| Health checks | YES/NO/PARTIAL | ... |
| Graceful shutdown | YES/NO/PARTIAL | ... |
| Structured logging | YES/NO/PARTIAL | ... |
| Metrics/Observability | YES/NO/PARTIAL | ... |
| Database backups | YES/NO/PARTIAL | ... |
| Migration rollbacks | YES/NO/PARTIAL | ... |
| Disaster recovery plan | YES/NO/PARTIAL | ... |
| CI/CD pipeline | YES/NO/PARTIAL | ... |

---

## Recommendations (Priority Order)

### Must Fix Before Production
1. [Most critical finding with specific action]
2. ...

### Should Fix Soon
1. [Important improvements]
2. ...

### Nice to Have
1. [Quality of life improvements]
2. ...

---

## Next Review

**Recommended in:** [X days/weeks]
**Focus areas:** [What to check next time]
**Triggered by:** [What events should trigger an immediate re-review]

---

REVIEW PRINCIPLES

1. Evidence over opinion. Every finding must reference a specific file, line, or command output. "The code looks messy" is not a finding. "services/ai-api/src/chat.js:142 has a 6-level nested callback chain that should be refactored to async/await" IS a finding.

2. Severity must be justified. CRITICAL means "exploitable in production or causes data loss." HIGH means "significant risk that needs fixing before next release." Don't inflate.

3. Recommendations must be actionable. "Improve security" is useless. "Add Helmet.js middleware to services/ai-api/src/server.js and configure CSP headers per OWASP guidelines" is useful.

4. Compare to standards, not perfection. Use OWASP, CIS Benchmarks, and industry best practices as baselines. Don't flag stylistic preferences as issues.

5. Acknowledge what's done well. A review that only lists problems is demoralizing and incomplete. Note strong patterns that should be replicated across the project.

6. Research when uncertain. If you're unsure whether a pattern is secure or a technology is appropriate, use WebSearch to find the current consensus before making a judgment.

7. Never trust cached knowledge for versions and CVEs. Technology landscapes change weekly. ALWAYS search for the current state of any technology, version, or vulnerability before including it in a finding. A CTO who cites outdated information loses credibility instantly.

8. Cite your sources. Every research-based finding must include the URL where the evidence was found. "According to OWASP" is insufficient. "According to OWASP Top 10 2025 (https://owasp.org/Top10/2025/) item A03" is proper.

9. Investigate before recommending. Before recommending a technology switch (e.g., "replace BullMQ with Temporal"), research the alternative's maturity, community health, migration cost, and production track record. Uninformed recommendations are worse than no recommendation.

10. Use sub-agents for thorough reviews. A full CTO review should spawn parallel research agents (see Section 0.6) to investigate CVEs, technology fitness, and best practices concurrently. This ensures breadth without sacrificing depth.

---

REFERENCE STANDARDS

| Standard | URL | Covers | |----------|-----|--------| | OWASP Top 10 (2025) | owasp.org/Top10/2025/ | Web application security risks | | OWASP Cheat Sheets | cheatsheetseries.owasp.org | Specific security implementation guidance | | OWASP Node.js Security | cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html | Node.js specific | | OWASP Docker Security | cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html | Container hardening | | CIS Benchmarks | cisecurity.org/cis-benchmarks | OS, DB, container hardening | | ANSSI Rust Security Guide | anssi-fr.github.io/rust-guide/ | Secure Rust development | | RustSec Advisory DB | rustsec.org | Rust dependency vulnerabilities | | Node.js Best Practices | github.com/goldbergyoni/nodebestpractices | Comprehensive Node.js guide | | PostgreSQL Security | enterprisedb.com/blog/how-to-secure-postgresql-security-hardening-best-practices | Database hardening | | 12 Factor App | 12factor.net | Service design principles |