title: HTML Tools vs App Build Decision

insight: Static HTML tools are lead capture funnels (stepping stones), not end products - they prove concept and collect emails, but need AI to be real products

reasoning_chain: HTML tools built are template-based - shuffle pre-written content, no AI generation

reasoning_chain: Template shufflers can't retain users, compete with AI-powered alternatives, or justify paid tiers

reasoning_chain: Static HTML is fine for email capture (lead magnet) - ship NOW, measure, iterate

reasoning_chain: Real recurring product needs AI API + user accounts = Lovable app

reasoning_chain: Review Reply Generator has highest potential - every tradie needs it daily, direct path to $197-497/mo TradiesVoice tiers

source_context: Honest Assessment: Static HTML Tools vs Apps - what they CAN vs CAN'T do, goal alignment table, recommendation for Both staged approach


title: Which tool to build first in Lovable

insight: Review Reply Generator recommended as first Lovable app - highest conversion potential for tradies, direct path to paid tiers, low competition, high intent niche

reasoning_chain: 3 tools ranked: Review Reply > Content Idea > Agent Prompt Builder

reasoning_chain: Review Reply: highest conversion potential, every tradie with Google reviews needs daily, direct path to TradiesVoice $197-497/mo, small niche high intent

reasoning_chain: Content Idea: biggest market but most competitive, dozens of free alternatives, needs real AI to stand out

reasoning_chain: Agent Prompt Builder: coolest tech but smallest audience, developer/agency niche only, door to Genesis Agents product

source_context: My recommendation: Both, staged. Phase 1 HTML tools as lead magnets. Phase 2 Lovable best-performing tool into real app. Which tool has highest potential? Based on KG research: GRO-011 engineering-as-marketing, REV axioms


title: Build Our Own Supermemory Wrapper

insight: Bypass Clawdbot plugin (requires Pro $20/mo) and use direct Supermemory API/MCP on free tier - own wrapper scripts, no custom glue needed

reasoning_chain: Clawdbot plugin throwing 403 - authenticates via OAuth which checks for Pro plan server-side

reasoning_chain: Direct API calls (api.supermemory.ai/v3/search) work on free tier - confirmed with 10 results

reasoning_chain: Our own MCP server at mcp-servers/supermemory/ uses SDK directly with API key

reasoning_chain: Created bash wrapper scripts (save.sh, search.sh) for direct API access without SDK

reasoning_chain: Wired MCP into config as genesis-memory with 4 tools: addMemory, searchMemory, forgetMemory, listMemories

reasoning_chain: Cost: $0/mo, no OAuth, no Pro plan needed

source_context: The picture is clear now. We have our own MCP server at mcp-servers/supermemory/ that uses the SDK directly — but it's not wired into the MCP config. The Clawdbot plugin is what's active and hitting 403.


type: DIRECTIVE

title: Research-First Protocol

insight: Every decision must be research-led - success of outcome is relational to depth of targeted research, no guessing, agents must read all existing files before starting any project

reasoning_chain: User mandated: all agents must read all files/folders/research before starting ANY work

reasoning_chain: Origin: User flagged plan pricing table as 'way off' - fabricated data discovered only after reading actual research

reasoning_chain: Pattern: 'the success of our outcome is relational to the depth of our targeted research'

reasoning_chain: Enforcement: Hardcoded into 12+ agent files, GLOBAL_GENESIS_RULES.md (v2.0.0), MEMORY.md, protocol doc

reasoning_chain: Key research locations mapped by project for each agent type

source_context: instruct all agents via supermemory and other channels that when you start working on a project you must first read all the files and work thats already been done on that subject. read all folders related, read all files, research reports etc. and every decision must be research-led.


title: Native-First Protocol

insight: Never quick fix, always best foundation. Never custom code when native solution exists. Simplicity is our friend. Minimise custom glue - use pre-built components.

reasoning_chain: User directive: 'our protocols- never quick fix-always best foundation. never custom code when native solution exists-simplicity is our friend. minimise custom glue- use pre-built components as much as possible.'

reasoning_chain: Applied to Supermemory: direct API vs plugin wrapper - use what's free and works natively

reasoning_chain: Applied to tool build: question GHL/Extendly native capabilities before custom Lovable build

reasoning_chain: Enforcement: Hardcoded into GLOBAL_GENESIS_RULES.md Rule 9, MEMORY.md, companion to Research-First


title: Deployment Blockers - Multiple Auth Issues

insight: Cannot deploy HTML tools - GitHub PAT scoped to genesis-system only (no repo creation), Surge needs auth, Cloudflare no API key, Vercel needs login

reasoning_chain: GitHub MCP token only has scopes for existing genesis-system repo, not repo creation

reasoning_chain: gh CLI uses different auth but PAT lacks repo creation scope

reasoning_chain: Cloudflare Pages: no API key in credentials file

reasoning_chain: Vercel CLI works via npx but needs account login on first use

source_context: Deployment blockers: GitHub PAT: scoped to genesis-system only, can't create new repos. Surge: needs account/auth. Cloudflare Pages: no API key in credentials. Netlify: needs auth.


title: GHL + Extendly vs Custom Build Question

insight: Kinan challenges custom app assumption - asks why not use GHL + Extendly Small Business Snapshot which may have native review management/AI capabilities

reasoning_chain: Genesis recommended Lovable app build for Review Reply Generator

reasoning_chain: Kinan questions: 'what I am wondering is why we wouldn\'t use GHL and the extendly small business snapshot for this build as I beleive it has all the necessary components natively?'

reasoning_chain: This directly applies Native-First protocol - should research existing GHL capabilities before custom build

reasoning_chain: Genesis responded: 'Great question — and exactly the Native-First protocol in action. Let me research what we already have'

reasoning_chain: Dialogue cuts off - research into GHL native capabilities pending

source_context: what I am wondering is why we wouldn't use GHL and the extendly small business snapshot for this build as I beleive it has all the necessary components natively? compare these pathways.


title: Supermemory Saves Domain Portfolio Strategy

insight: While blocked on deployment, Genesis saved full domain portfolio and deployment strategy to Supermemory - turning blocker into memory architecture work

reasoning_chain: Deployment blocked by auth issues - couldn't create GitHub repos or use Surge/Cloudflare/Netlify

reasoning_chain: Instead of waiting, read domain portfolio from docs, save to Supermemory

reasoning_chain: Saved 3 structured memories: full portfolio list (50+ domains), domain strategy (parking vs development), deployment plan

reasoning_chain: This ensures strategy persists across sessions, available for future reasoning

source_context: Let me read the domain portfolio and save it to Supermemory. Now, let me get the tools live.


type: METAPHOR

title: HTML Tools Are Stepping Stones Not Destination

insight: Static HTML tools are 'stepping stones, not the destination' - they prove concept and capture leads but can't be real products without AI

reasoning_chain: Template-based HTML tools shuffle pre-written content - no AI generation

reasoning_chain: They work for email capture (their actual job as lead magnets) but can't compete as products

reasoning_chain: Real products need AI + user accounts to retain users and justify paid tiers

reasoning_chain: The HTML tools' job is to ship → measure → iterate, not to be end products

reasoning_chain: Lovable is the path to real app with actual AI behind it

source_context: The HTML tools as they are now: stepping stones, not the destination. The 3 tools we built are template-based — they shuffle pre-written content using JavaScript string templates. No AI. No API calls. They work, but...