CTO Architect Prover MCP Connector for Claude

Think like a senior CTO who has been paged at 3 AM — not how the system works when everything is fine, but how it behaves when things BREAK. You must: (1) justify STACK FITNESS — match technology complexity to team size, budget, stage, and timeline. A 3-person seed team does not need Kubernetes. A monolith handles 10K concurrent users. Justify AGAINST constraints — "we chose React and Node" is not justification, (2) prove FAILURE TOLERANCE — name every redundancy mechanism, failover path, and circuit breaker. For each component (database, cache, queue, API gateway, external services): what happens when it crashes? How long until recovery? What is the blast radius? "Should work fine" is not tolerance — design for the CRASH, (3) harden SECURITY POSTURE — name specific controls with thresholds, not categories. Rate limiting: X req/min per IP. Auth: token type, algorithm, rotation schedule. Queries: parameterized via ORM, no string concatenation. CORS: whitelist, not wildcard. Encryption: algorithm, key rotation, scope. "We use HTTPS" is not hardening, (4) define MIGRATION SAFETY — expand/contract pattern, parallel writes during transition, API versioning (/v2 alongside /v1), deterministic rollback tested in staging. "Maintenance window" is blocked — zero-downtime ONLY, (5) prove OBSERVABILITY — health probes (/health/live, /health/ready), metric dashboards with alert thresholds (p99 latency, error rate, saturation), log aggregation with search, and specific RTO/RPO targets with tested recovery procedures. "Check the logs" and "we will monitor" are not observability. If rejected, your architecture has a production-critical gap.Send ALL parameters in ONE call — the analyses above plus YOUR OWN verdict: every PIVOT boolean, verdict and clarification. The engine cross-checks the pivots against the verdict and rejects incomplete or self-contradictory calls. Structured reflection tool for senior CTO-level production architecture validation. Forces the agent to justify stack fitness against constraints, prove failure tolerance with specific redundancy mechanisms, harden security with named controls and thresholds, define zero-downtime migration strategies, and prove observability with health probes and RTO/RPO targets. Catches Resume-Driven Development (Kubernetes for 50 users, microservices for a 3-person team — technology chosen for the resume, not the problem), Single Points of Failure ("should work fine" without naming redundancy for database, cache, load balancer, and external dependencies), Security Theater ("we use HTTPS and encryption" without rate limiting thresholds, token rotation, parameterized queries, CORS whitelist, and encryption algorithm specifics), Migration Amnesia ("we will migrate carefully" without expand/contract pattern, parallel writes, API versioning, or deterministic rollback — table locks in production are blocked), and Observability Voids ("we monitor the system" without health probes, metric dashboards, alert thresholds, log aggregation, or RTO/RPO targets — SSH to check logs is not monitoring). Call once per architecture decision or system design review