title: Rate limiter misconfiguration causing Gemini crashes

insight: Rate Maximizer configured for 2000 RPM but actual Tier 1 limits are 150-300 RPM, causing 6-13x overconfiguration and 429 errors

reasoning_chain: Genesis reported 6 configuration problems with rate limiter

reasoning_chain: Configured RPM (2000) far exceeds actual Tier 1 limits (150-300)

reasoning_chain: Every time 10 Gemini agents launched, they instantly exceeded real limits

reasoning_chain: This explains the Gemini agent crashes observed

source_context: Rate Maximizer only tracks 2 models but Executor uses 5+ | 3+ models bypass all rate limiting. Configured RPM = 2,000 but actual Tier 1 = 150-300 | 6-13x overconfigured — causes 429 errors


title: Massive resource utilization crisis discovered

insight: System paying ~$240/mo across services but using essentially $0 of capacity - 99.9% idle, 1200x headroom on Gemini API

reasoning_chain: Token usage analysis revealed 0.1% utilization of Gemini budget

reasoning_chain: Peak utilization 2.2% vs 90% target (44x below)

reasoning_chain: Combined across all services: Jules Pro 100% idle, Images 100% idle, Videos 100% idle, Instantly.ai 100% idle, OpenRouter 100% idle

reasoning_chain: System can scale 100x without exceeding budget - $270/mo would achieve 90% utilization

source_context: We're paying ~$240/mo across services and using essentially $0 of capacity. The Ferrari isn't in first gear — the engine is OFF.


title: Unified MCP Gateway architecture designed

insight: Consolidate 8 fragmented MCP servers into single gateway with tier gating, unified memory layer, and dual transport

reasoning_chain: Audited 8 existing MCP servers across 3 languages with duplicated tools

reasoning_chain: Identified 61 unique core tools organized into 11 namespaces

reasoning_chain: Designed 5-tier access control (L0-L4) with exact tool-to-tier mapping

reasoning_chain: Created fan-out memory router querying all 5 backends in parallel

reasoning_chain: Planned dual transport (stdio + SSE) for local and remote agents

reasoning_chain: Revenue model: same server serves internal Genesis (free L4) and paying Sunaiva customers ($49-$247/mo)

source_context: The Problem: 8 fragmented MCP servers, 3 languages, duplicated tools, no auth, no tier gating. The Solution: One gateway server with 61 core tools in 11 namespaces, 5 tiers, fan-out memory, dual transport.


type: DIRECTIVE

title: Auto-respawn system mandated for command centre persistence

insight: Kinan mandated auto-respawn capability hardwired to trip at 65% (flush) and 70% (definite respawn) without human intervention

reasoning_chain: Kinan stated: 'most important is you, the command centre remaining persistent'

reasoning_chain: Kinan directive: 'learn to memory flush and CTM and clear and respawn autonomously without my help'

reasoning_chain: Kinan mandated: 'hardwired to trip and execute between 65%, at 65% with definite respawn at 70% as mandate'

reasoning_chain: Genesis dispatched research and build agents to implement this

source_context: I need to go but most important is you, the command centre remaining persistent. which means you need to learn to memory flush and CTM and clear and respawn autonomously without my help. deeply research this auto-respawn capabilty. and have it hardwired to trip and execute between 65% , at 65% with definite respawn at 70% as mandate.


title: Auto-respawn hook system built and tested

insight: Created 3-tier auto-respawn system: 50% warning, 65% CTM flush, 70% respawn with watcher daemon

reasoning_chain: Built auto_respawn.py PostToolUse hook reading context state

reasoning_chain: Implemented 5% band deduplication to prevent repeated triggers

reasoning_chain: Created respawn_command_centre.sh watcher script polling for flag file

reasoning_chain: Integrated with existing StatusLine (Layer 1) and observability systems

reasoning_chain: Tested at 45%, 52%, 66%, 72% - all thresholds working correctly

source_context: 50% → Warning injected. 65% → Full CTM flush (handoff file + supermemory save). 70% → CTM flush + respawn flag → watcher script kills & restarts


title: Product readiness split identified

insight: Marketing-ready (website + demo) nearly complete but revenue-ready (payments + service delivery) requires ~24 hrs engineering

reasoning_chain: ReceptionistAI website on Lovable nearly done

reasoning_chain: Website scraper architecture exists at plans/HERO_DEMO_WEBCRAWL_ARCHITECTURE.md

reasoning_chain: But backend blockers: STT placeholder, rule-based AI (4 intents), no Stripe, local-only API, missing customer auth

reasoning_chain: Marketing side almost done vs revenue side ~24 hrs engineering

source_context: For the WEBSITE launch, yes that's basically it. But our recon agents flagged the backend blockers that prevent actually charging customers: STT placeholder, rule-based AI, not integrated, local only, missing auth. So the split is: Marketing-ready = you're right, almost done. Revenue-ready = ~24 hrs engineering.


title: Rate limiter config fixed with real Tier 1 limits

insight: Created config/gemini_rate_limits.json with accurate limits for all 6 models, fixing 5-7x misconfiguration

reasoning_chain: Genesis created missing config file with real limits

reasoning_chain: gemini-2.0-flash: 2000 → 300 (6.7x lower)

reasoning_chain: Added 4 previously untracked models: gemini-3-flash-preview (200), gemini-3-pro-preview (150), gemini-2.0-flash-lite (300), gemini-2.5-pro (150)

source_context: Rate limiter config created with real Tier 1 limits for all 6 models. Key changes: gemini-2.0-flash: 2,000 → 300 (6.7x lower), gemini-2.5-flash: 1,000 → 200 (5x lower). Added 4 previously untracked models.


title: 200-agent OpenRouter swarm built

insight: Built production-ready swarm orchestrator with two specialized teams (MiniMax for marketing, Kimi for code) executing 200 parallel agents

reasoning_chain: Created openrouter_swarm.py (560+ lines) with async parallel execution

reasoning_chain: Batched processing (20 agents/batch) to avoid rate limits

reasoning_chain: Team MiniMax: 100 agents generating marketing assets (emails, LinkedIn, landing pages, blog outlines)

reasoning_chain: Team Kimi: 100 agents generating code modules (Stripe, auth, FastAPI, migrations, MCP tools)

reasoning_chain: Estimated cost $0.30-0.50 per full run, 5-10 minutes, 200 outputs

source_context: Built a production-ready parallel agent orchestration system that executes 200 AI agents across two specialized teams using OpenRouter API. TEAM MINIMAX (100 agents) - Content & Marketing. TEAM KIMI (100 agents) - Code & Architecture.


title: Sunaiva Memory has critical security vulnerabilities

insight: Backend has disabled Stripe webhook security, hardcoded JWT secret, hardcoded DB credentials - must fix before customers

reasoning_chain: Product scan found Sunaiva Memory backend MVP complete but insecure

reasoning_chain: Stripe webhook security DISABLED (allows subscription fraud)

reasoning_chain: JWT secret hardcoded (token forgery risk)

reasoning_chain: DB credentials hardcoded (exposed in source)

reasoning_chain: Rate limiter in-memory (no multi-process support)

source_context: Critical Blockers (MUST FIX BEFORE CUSTOMERS): Stripe webhook security DISABLED, JWT secret hardcoded, DB credentials hardcoded, File storage on /tmp, Rate limiter in-memory, No database migrations tool, Auth endpoints not wired to frontend.


title: Resource utilization connects to product strategy

insight: Massive idle capacity (1200x headroom) can be filled with background work: KG extraction, YouTube transcripts, axiom generation

reasoning_chain: Token analysis showed 99.9% idle capacity

reasoning_chain: Realized system can scale 100x without exceeding budget

reasoning_chain: Identified fill strategies: KG extraction, YouTube transcript processing, axiom generation from unprocessed documents

reasoning_chain: Combined with 9,546 idle leads and 100+ idle domains

reasoning_chain: This connects infrastructure waste to revenue-generating work

source_context: Fill idle capacity with background work: KG extraction, YouTube transcript processing, axiom generation from unprocessed documents. Scale swarm concurrency from max 5 to 15-20 parallel agents.


type: METAPHOR

title: Ferrari engine is OFF

insight: System paying for massive capacity but using essentially zero - engine not in first gear, it's completely off

reasoning_chain: Analyzed resource utilization across all paid services

reasoning_chain: Found paying $240/mo but using $0 of capacity

reasoning_chain: Realized this is not just underutilization - it's complete inactivity

reasoning_chain: Metaphor crystallizes the gap between potential and actual performance


title: Product inventory reveals 35 projects, 3 shipped

insight: Full audit shows 35 projects mapped across Genesis ecosystem but only 3 actually shipped (AIVA voice, Voice Bridge MCP, Bunker demo)

reasoning_chain: 10 Claude recon agents mapped full product landscape

reasoning_chain: Products span: Sunaiva Memory (incomplete), ReceptionistAI (text live), AIVA (production), Voice Bridge (operational), Bunker demo (live)

reasoning_chain: ClawdTalk bypassed - building superior alternative instead

reasoning_chain: 35 projects mapped, 3 shipped, ~$500/mo idle services, $0 revenue

source_context: 35 projects mapped. 3 shipped. ~$500/mo in idle services. $0 revenue.