title: Non-stop agent execution protocol

insight: Every agent completion should automatically trigger the next dispatch - Kinan should never need to say 'start agents'. This is hardwired as the baseline failure state.

reasoning_chain: Kinan asked to dispatch P1 stories while waiting for P0

reasoning_chain: Genesis fired P1 stories immediately without waiting

reasoning_chain: Kinan later said 'i shouldnt have to repeat myself' about agent execution

reasoning_chain: Genesis CTM'd (call the meeting) this as a hardwired protocol in MEMORY.md

source_context: Kinan: 'start dispatching those while we wait' and later 'i shouldnt have to repeat myself. hardwire this now. and ctm it'


title: Swarm composition finalized

insight: 200-agent swarm will use 10 Gemini CLI (Google AI Pro credits), 100 Kimi K2.5, and 100 MiniMax 2.5 - not all Gemini

reasoning_chain: Genesis initially suggested 200 Gemini agents

reasoning_chain: Kinan corrected: 'not 200 gemini agents. gemini cli agents maybe 10-. then 100 kimi k2.5 and 100 minimax 2.5'

reasoning_chain: Blocker identified: OpenRouter credits nearly gone ($7.70 remaining), NVIDIA NIM expired

source_context: Kinan: 'not 200 gemini agents. gemini cli agents maybe 10-. then 100 kimi k2.5 and 100 minimax 2.5'


title: Command centre dashboard architecture

insight: Single HTML file + shared JSON file approach - agents write to blockers.json, dashboard polls it, Kinan responds via cards with voice input. Zero token cost, works offline.

reasoning_chain: Research agent (ac9ff1d) studied visual AI-human command interfaces

reasoning_chain: Found existing tools: kanban-md, IndyDevDan's observability, Claude Code UI wrappers

reasoning_chain: Recommended architecture: single HTML polling blockers.json with Web Speech API for voice

reasoning_chain: Scores 24/25 against requirements, beats other solutions due to zero infrastructure and token cost

source_context: Research found 'Best approach: Single HTML + shared JSON file. Agents write blockers to blockers.json, dashboard polls it, Kinan responds via cards (type or voice), responses save to files agents read. Zero token cost.'


title: Rate limiting middleware design

insight: Thread-safe sliding window rate limiter with 3 tiers (auth: 10req/60s, widget_api: 100req/60s, webhooks: 500req/60s), memory-bounded LRU eviction, proxy-aware IP extraction

reasoning_chain: P1-20 story dispatched for rate limiting

reasoning_chain: Agent built SlidingWindowStore with threading.Lock for thread safety

reasoning_chain: Used OrderedDict for LRU eviction (max 10,000 IPs)

reasoning_chain: Added periodic cleanup on incoming requests to reclaim memory

reasoning_chain: Exempt paths: /, /health, /dashboard, /docs, /static/*

source_context: Agent built 'SlidingWindowStore -- the core data structure: Thread-safe via threading.Lock on every operation, Memory-bounded with OrderedDict for LRU eviction (max 10,000 tracked IPs)'


title: Lead capture system with Gemini extraction

insight: Idempotent lead extraction using Gemini API, call_id UNIQUE constraint prevents duplicates, Resend email notifications, CSV export gated to Growth tier

reasoning_chain: Agent built extract_leads_from_transcript using Gemini 2.0 Flash

reasoning_chain: Added idempotency check by call_id before extraction

reasoning_chain: call_id UNIQUE constraint at DB level enforces idempotency

reasoning_chain: Email notification via Resend API after extraction

reasoning_chain: CSV export endpoint checks tier via _get_customer_tier helper

source_context: Agent built 'Lead Extraction Function: extract_leads_from_transcript(transcript, call_id, widget_id) - Idempotency check: Queries sunaiva_widget.leads by call_id first'


title: Widget CRUD with tier enforcement

insight: 5 endpoints (GET list, GET single, POST create, PUT update, DELETE soft-delete), tier limits enforced (Starter=1, Pro=1, Growth=3), ownership checks, embed code generation

reasoning_chain: Agent built complete Widget CRUD API module (496 lines)

reasoning_chain: Same DB pattern as auth.py using get_db_connection, db_fetch_one, db_execute

reasoning_chain: Tier enforcement via _get_customer_tier() looking up subscription

reasoning_chain: Ownership enforcement via _fetch_widget_for_customer() verifying customer_id

reasoning_chain: Embed code generation with data-agent-id, data-color, data-position, data-greeting format

source_context: Agent summary: 'New file: /mnt/e/genesis-system/Sunaiva/talking-widget/backend/widgets.py - A complete Widget CRUD API module (496 lines) implementing a FastAPI APIRouter with five endpoints'


title: Onboarding to Auth pipeline wiring

insight: Checkout completion creates pending_setup widget, generates 24hr onboarding JWT, stores in widget config, frontend redirects through /billing/onboarding-redirect to /onboarding?token=XXX, provisioning flips widget to active

reasoning_chain: billing.py handle_checkout_completed now creates widget with status=pending_setup

reasoning_chain: Creates onboarding JWT with purpose=onboarding, widget_id, 24hr expiry

reasoning_chain: GET /billing/onboarding-redirect endpoint generates fresh token and returns onboarding_url

reasoning_chain: pipeline.py POST /onboarding/provision calls update_widget_active to flip status to active

source_context: Agent summary: 'End-to-End Flow: Customer completes Stripe checkout -> billing.py handle_checkout_completed(): 1. Upserts subscription record 2. Creates widget (status=pending_setup) 3. Generates 24hr onboarding JWT 4. Stores token in widget config'


title: Ops dashboard as living links panel

insight: Right half of screen becomes ops dashboard with clickable links to all services (Netlify, Stripe, Telnyx, etc), story tracker with checkboxes, agent monitor, cost tracker - all editable and localStorage persistent

reasoning_chain: Kinan suggested: 'what about the whole unused right half of this screen becomes the living color dashboard with links'

reasoning_chain: Agent (af0ef99) built ops-dashboard.html with 9 sections

reasoning_chain: Live deployments with status dots, infrastructure links, product pages, story tracker, agent monitor, cost tracker, notes

reasoning_chain: All state persists in localStorage under key genesis_ops_dashboard_v2

source_context: Kinan: 'what about the whole unused right half of this screen becomes the living color dashboard with links. so instead of Netlify deploy : live. we have a link to netlify live'


title: OpenRouter credits nearly exhausted

insight: Only $7.70 remaining in OpenRouter credits, needed for Kimi K2.5 and MiniMax 2.5 in the 200-agent swarm. NVIDIA NIM free credits expired Feb 19.

reasoning_chain: Genesis mentioned $50 credits spent ~$42.30

reasoning_chain: Swarm requires 100 Kimi K2.5 + 100 MiniMax 2.5 calls

reasoning_chain: Need to find cheapest path to 200 model calls

source_context: Genesis: 'Last session the swarm ran via core/multi_model_swarm.py using Kimi 2.5 + MiniMax through OpenRouter, but we burned through most of the $50 credits (~42.30 spent, ~7.70 remaining)'


type: DIRECTIVE

title: Hive structure and permanent team design

insight: Kinan wants a permanent hive structure with optimal agents for each team, running continuously without repetition. This should be hardwired so Kinan never has to repeat himself.

reasoning_chain: Kinan said: 'develop the hive structure and optimal agents for each team and keep them running. i shouldnt have to repeat myself. hardwire this now. and ctm it'

reasoning_chain: Genesis CTM'd this and hardwired in MEMORY.md

reasoning_chain: Delegated to agent ab64337 to design permanent team structure

source_context: Kinan: 'develop the hive structure and optimal agents for each team and keep them running. i shouldnt have to repeat myself. hardwire this now. and ctm it'


title: Research findings directly informed dashboard architecture

insight: The visual command centre research (ac9ff1d) directly produced the recommended architecture that was then implemented - single HTML + JSON file approach emerged from analyzing existing tools like kanban-md

reasoning_chain: Research agent studied visual AI-human command interfaces

reasoning_chain: Found multiple existing solutions: kanban-md, TaskBoardAI, Vibe Kanban, IndyDevDan's observability

reasoning_chain: Analyzed pros/cons of each against requirements

reasoning_chain: Recommended single HTML + shared JSON file as highest scoring approach

reasoning_chain: This recommendation was then implemented by dashboard agent

source_context: Research found 'Recommended Architecture: The simplest approach that meets all requirements is a single HTML file dashboard reading a shared blockers.json file... This approach scores 24/25 against the requirements'


title: Dashboard wired to real API endpoints

insight: Dashboard evolved from static display to fully API-wired: loading spinners, error toasts, widget CRUD, billing portal, settings save - all connected to real backend endpoints

reasoning_chain: Agent (ab184c8) wired dashboard.html to real API

reasoning_chain: loadWidget() rewritten to fetch GET /widgets, display cards, pre-fill customization form

reasoning_chain: Save Changes calls PUT /widgets/{id} or POST /widgets

reasoning_chain: Billing section now async with live refresh on tab open

source_context: Agent summary: 'Widget Section -- Wired to Real API: loadWidget() was rewritten from a static display to a fully API-wired async function - Fetches GET /widgets and stores results in state.widgets'


type: METAPHOR

title: Hive structure for continuous agent execution

insight: The system is conceptualized as a 'hive' - a permanent structure with optimal agents for each team that keeps running without needing to be told to start each time

reasoning_chain: Kinan asked to 'develop the hive structure and optimal agents for each team'

reasoning_chain: This implies a self-sustaining, always-running agent ecosystem

reasoning_chain: Non-stop protocol means agents hitting zero is a failure state

reasoning_chain: Hive architect agent (ab64337) is designing this permanent structure

source_context: Kinan: 'develop the hive structure and optimal agents for each team and keep them running'