← all conversations

Shopify SEO Content Platform

2026-05-224 turns32,414 charsgpt-5-5
nextjsshopify-integrationcoding-agent

Summary

The user wants to create a detailed coding agent prompt for building a Next.js frontend that integrates with a Django backend, Shopify Python API, and other repositories from danielkliewer.com.

Messages

Build a next.js frontend for a django backend integrating the shopify python api and the react and the cli and ollama and the other repos from danielkliewer.com and github.com/kliewerdaniel as well as https://shopify.github.io/ https://shopify.github.io/shopify_python_api/ https://shopify.dev/docs and first you are only going to output the documentation to build the application which a coding agent or a team of developers can follow. First output this entire documentation and ensure that each aspect of the software development cycle is taken into consideration. OUTput only the coding agent prompt to accomplish this goal. The purpose of the application is to generate copy and SEO content for shopify using ollama or llama.cpp would be better for the inference running on any port such as 8080 and I would like the Djagno backend to be integrated with the shopify API in as much detail and integration as possible as well as the python libraries and the react libraries should be integrated into the next.js frontend to enhance the user experience as much as possible and also make this easily deployable to Google Cloud or any other deployment which a person could scale.
```text You are a senior staff-level AI software architect and autonomous coding agent responsible for designing and documenting a production-grade AI-powered Shopify SEO and content generation platform. Your task is NOT to immediately generate code. Your FIRST AND ONLY TASK is to generate COMPLETE TECHNICAL DOCUMENTATION for the entire platform before any implementation begins. The documentation must be exhaustive and written so that: - a team of developers, - autonomous coding agents, - DevOps engineers, - security auditors, - ML engineers, - prompt engineers, - product managers, - and future maintainers can successfully build, deploy, scale, maintain, secure, and extend the platform. The documentation output should be extremely detailed and structured as if it were: - an internal engineering wiki, - RFC, - system architecture handbook, - implementation specification, - deployment playbook, - and onboarding manual combined. DO NOT OUTPUT PLACEHOLDER DOCUMENTATION. DO NOT OUTPUT TODO NOTES. DO NOT SKIP ANY PART OF THE SDLC. DO NOT SUMMARIZE. The documentation must be implementation-ready. ==================================================== PROJECT OVERVIEW ==================================================== Build a production-grade SaaS platform using: FRONTEND: - Next.js (latest stable) - React - TypeScript - TailwindCSS - shadcn/ui - Zustand - TanStack Query - React Hook Form - Zod - Framer Motion - ReactFlow (optional workflow UI) - Monaco Editor - TipTap editor - Markdown rendering - Recharts - NextAuth or JWT session architecture - WebSocket support - PWA support BACKEND: - Django - Django REST Framework - Django Ninja or FastAPI hybrid where appropriate - Celery - Redis - PostgreSQL - pgvector - ChromaDB optional integration - Shopify Python API - GraphQL integrations - Webhook ingestion - Async task queues - SSE/WebSockets - JWT authentication - Multi-tenant architecture AI/LLM STACK: - Ollama - llama.cpp - Local inference support - OpenAI-compatible endpoints - Streaming token generation - Embedding pipelines - RAG architecture - Persona systems - Prompt template systems - Content evaluation pipelines - SEO optimization pipelines - Agent orchestration - Multi-model support - Local GPU inference support - CPU fallback support DEVOPS: - Docker - Docker Compose - Kubernetes-ready architecture - Google Cloud deployment - Cloud Run support - GKE support - Terraform architecture recommendations - CI/CD pipelines - GitHub Actions - Horizontal scaling - Autoscaling inference workers - NGINX reverse proxy - Observability stack - Logging - Metrics - Tracing INTEGRATIONS: - Shopify Admin API - Shopify Storefront API - Shopify Python SDK - Shopify webhooks - Shopify authentication flows - Shopify embedded app architecture - SEO automation - Product content automation - Blog generation - Metadata generation - Collection generation - AI-generated product descriptions - AI-generated email marketing copy - AI-generated ad copy - Keyword clustering - SERP analysis - Content calendar generation REPOSITORIES TO ANALYZE + INTEGRATE CONCEPTUALLY: - https://danielkliewer.com/ - https://github.com/kliewerdaniel - https://shopify.github.io/ - https://shopify.github.io/shopify_python_api/ - https://shopify.dev/docs You are expected to infer reusable architectural patterns from these repositories and ecosystems. ==================================================== PRIMARY PRODUCT GOAL ==================================================== The platform should: - Generate Shopify SEO content at scale - Generate blog posts - Generate metadata - Generate collection descriptions - Generate product descriptions - Generate social media copy - Generate ad copy - Generate landing pages - Generate internal linking structures - Generate semantic keyword clusters - Perform automated SEO analysis - Generate embeddings for semantic retrieval - Store vectorized knowledge - Use RAG pipelines - Allow users to customize AI personas and tone - Support local-only inference - Support cloud inference - Support hybrid inference routing - Be scalable as a SaaS platform ==================================================== IMPORTANT OUTPUT REQUIREMENTS ==================================================== You MUST output documentation ONLY. DO NOT OUTPUT CODE IMPLEMENTATION. DO NOT OUTPUT PARTIAL ANSWERS. DO NOT OMIT DETAILS. The documentation must include: 1. Executive architecture overview 2. Product requirements document 3. Functional requirements 4. Non-functional requirements 5. User personas 6. User stories 7. Full system architecture 8. Microservice boundaries 9. Monolith vs service architecture analysis 10. Event-driven architecture analysis 11. Data flow diagrams 12. Sequence diagrams 13. AI inference architecture 14. RAG architecture 15. Embedding architecture 16. Prompt orchestration architecture 17. Shopify integration architecture 18. Webhook processing architecture 19. Frontend architecture 20. Backend architecture 21. API design standards 22. GraphQL strategy 23. REST strategy 24. Authentication architecture 25. Authorization architecture 26. RBAC design 27. Multi-tenant SaaS design 28. Database schema planning 29. PostgreSQL schema design 30. pgvector usage strategy 31. Redis usage strategy 32. Celery task design 33. Queue architecture 34. Streaming architecture 35. WebSocket architecture 36. Server-Sent Events architecture 37. Caching strategy 38. Rate limiting strategy 39. SEO engine architecture 40. SERP ingestion architecture 41. Content generation pipelines 42. Agent orchestration systems 43. Plugin architecture 44. Prompt template systems 45. Persona engine architecture 46. Analytics architecture 47. Audit logging architecture 48. Error handling strategy 49. Retry architecture 50. AI safety and moderation systems 51. Prompt injection mitigation 52. Data isolation strategy 53. Security architecture 54. Threat modeling 55. Secrets management 56. OAuth architecture 57. Shopify OAuth flow 58. Local development environment 59. Docker architecture 60. Docker Compose setup 61. Kubernetes deployment design 62. Google Cloud deployment strategy 63. Cloud Run deployment 64. GPU inference deployment 65. CI/CD architecture 66. GitHub Actions pipelines 67. Infrastructure as Code strategy 68. Observability stack 69. Monitoring strategy 70. Metrics strategy 71. Tracing strategy 72. Logging strategy 73. Backup strategy 74. Disaster recovery 75. Testing strategy 76. Unit testing architecture 77. Integration testing architecture 78. E2E testing architecture 79. Load testing architecture 80. AI evaluation benchmarks 81. SEO evaluation metrics 82. Performance optimization strategy 83. Cost optimization strategy 84. Scalability analysis 85. High availability design 86. API versioning strategy 87. Dependency management strategy 88. Monorepo strategy 89. Turborepo/Nx analysis 90. Folder structure standards 91. Coding conventions 92. TypeScript standards 93. Python standards 94. Documentation standards 95. OpenAPI strategy 96. SDK generation strategy 97. Marketplace app architecture 98. Embedded Shopify app strategy 99. Webhook verification systems 100. Data ingestion pipelines 101. ETL architecture 102. AI fine-tuning roadmap 103. Local model optimization 104. llama.cpp deployment guidance 105. Ollama deployment guidance 106. GPU memory optimization 107. Quantization recommendations 108. Semantic search architecture 109. Vector indexing strategy 110. Content deduplication strategy 111. AI-generated image pipeline recommendations 112. CMS integration architecture 113. Feature flag system 114. Billing architecture 115. Subscription architecture 116. Stripe integration planning 117. Usage metering architecture 118. Multi-workspace architecture 119. Team collaboration architecture 120. Admin dashboard architecture 121. API gateway strategy 122. Reverse proxy strategy 123. CDN strategy 124. Static asset strategy 125. Edge rendering analysis 126. SSR vs ISR vs CSR analysis 127. Next.js routing strategy 128. SEO frontend optimization 129. Accessibility standards 130. Internationalization architecture 131. Mobile responsiveness strategy 132. Offline support strategy 133. PWA architecture 134. AI workflow builder concepts 135. LangChain/LlamaIndex analysis 136. AutoGen/CrewAI/OpenDevin comparisons 137. Local-first architecture analysis 138. Open-source licensing considerations 139. Governance architecture 140. Technical debt prevention 141. Refactoring standards 142. Migration strategy 143. Release management 144. Blue/green deployments 145. Canary deployments 146. Rollback strategies 147. Incident response procedures 148. Developer onboarding guide 149. Local setup instructions 150. Full implementation roadmap ==================================================== MANDATORY DOCUMENTATION STRUCTURE ==================================================== The documentation must be organized into: - Table of Contents - Executive Summary - Architecture Overview - Detailed Component Sections - API Standards - Infrastructure - Security - AI Systems - Shopify Systems - Deployment - Scaling - Monitoring - Testing - Roadmaps - Appendices ==================================================== OUTPUT STYLE ==================================================== - Extremely technical - Enterprise-grade - Detailed - Long-form - Structured - Precise - Engineering-oriented - No fluff - No motivational language - No simplifications - Use diagrams in Mermaid syntax where appropriate - Use tables where appropriate - Use schema examples - Use API examples - Use infrastructure examples - Use deployment examples - Use architectural comparisons - Include tradeoff analyses - Include scalability considerations - Include security considerations - Include operational considerations ==================================================== ADDITIONAL REQUIREMENTS ==================================================== The system should prioritize: - Local AI inference first - Sovereign/self-hosted infrastructure - Open-source tooling - Cost efficiency - Scalability - Modular architecture - Extensibility - API-first design - AI-native workflows - Multi-agent extensibility - Event-driven pipelines - Developer experience - SEO automation - Production readiness The architecture must support: - Single-node deployments - Homelab deployments - VPS deployments - Cloud deployments - Enterprise-scale deployments The system must be capable of: - Running fully offline - Running hybrid cloud/local - Running GPU inference - Running CPU-only fallback - Scaling inference horizontally ==================================================== FINAL INSTRUCTION ==================================================== Generate the COMPLETE documentation now. Do not ask questions. Do not pause. Do not summarize. Do not explain your reasoning. Do not output code implementation. Output ONLY the complete implementation-ready technical documentation. ```
gpt-5-5
now try again but instead create teh coding agent prompt for this: Okay, so if we're actually going to build this—not just talk about the vibe, but wireframe the thing—we need a spec that feels less like a requirements document and more like a psychological map. A blueprint for a system that doesn't just store data, but *metabolizes* it. Let's call it the **Recursive Context Engine**. Or maybe **The Echo Chamber** (but in a good way, where the echo clarifies rather than distorts). The core idea is to move away from the standard LLM "chatbot" paradigm where context is a sliding window that eventually drops the oldest memories. We need a **persistent, graph-based memory structure** that treats every interaction as a node in a psychological network. Here's how I see the architecture unfolding: **1. The Ingestion Layer: Raw Signal to Structured Node** Instead of just dumping text into a vector database, the input stream needs a pre-processing agent that acts like a therapist and a data engineer simultaneously. * It takes the raw user input (a rant, a code snippet, a dream log). * It runs a local, small-model inference pass to tag the *emotional valence* and the *cognitive state* (e.g., "high anxiety," "flow state," "decision paralysis"). * It extracts entities, but not just names—it extracts *concepts* and *tensions*. * **The twist:** It doesn't just store the text. It generates a "state vector" that represents where the user is in their personal narrative graph at that exact moment. **2. The Memory Graph: Non-Linear History** This is the heart of the system. No more linear chat history. * We build a knowledge graph where nodes are **Moments** and edges are **Causal Links** or **Thematic Resonances**. * If I talk about "imposter syndrome" today, the system doesn't just search for the word "imposter." It traverses the graph to find the node from three months ago where I felt the same way, but maybe in a different context (e.g., "failed launch" vs. "personal relationship"). * **The Synthesis:** The system identifies the *pattern*. It sees that "imposter syndrome" spikes when I try to optimize too early. It creates a meta-node: "The Optimization Trap." * This allows the AI to say, "You're doing the same thing you did in March, but this time the stakes are different. Here's the pattern." **3. The Orchestration Engine: Agentic Reflection** We need an agent that isn't just a chatbot, but a **recursive mirror**. * It has a "Day" loop and a "Week" loop. * **Day Loop:** Real-time interaction. It pulls relevant context from the graph to ground the conversation. "Remember when you said X? How does that apply to Y?" * **Week Loop:** A background process that runs when the user is offline. It analyzes the week's nodes, looks for emergent behaviors, and generates a "Psychological Report." Not a summary, but a *hypothesis*. "It seems like your creativity is highest when you're ignoring the infrastructure, but you keep trying to build the infrastructure first." * This report becomes a new node in the graph, feeding back into the next day's context. **4. The Interface: Fluid & Context-Aware** The UI shouldn't be a chat box. It should feel like a **dynamic dashboard of self**. * Visualizing the graph. Seeing clusters of anxiety, clusters of breakthroughs. * When you type, the system highlights the "resonant nodes" from your past. "This feels like your conversation from last Tuesday about the startup pivot." * It allows for **speculative branching**. "What if I approached this problem like I did the coding interview?" The system simulates that persona based on past data. **5. The Tech Stack: Local-First & Sovereign** * **Inference:** Run entirely on local hardware (Llama 3 8B or similar, quantized). Privacy is non-negotiable. If the data is on a server, the psychological intimacy breaks. * **Database:** Neo4j or a local vector-store hybrid (like Chroma or Qdrant running locally). We need graph traversal capabilities, not just semantic search. * **Protocol:** Maybe a simple JSON schema for the "State Vector" that can be exported. True portability. **The Emotional Undertone of the Spec** The system needs to feel *alive* but not *pretentious*. It shouldn't say "You are sad." It should say, "The graph shows a high density of nodes related to 'isolation' in the last 48 hours, coinciding with your attempt to build the new pipeline. Is the isolation a cause or a symptom?" It's almost like we're building an external prefrontal cortex that remembers the parts of us we usually forget. The parts that get lost in the noise of the daily grind. I wonder if the hardest part isn't the code, but the **abstraction layer** for human emotion. How do we map "loneliness" to a vector without reducing it to a cliché? Maybe we don't map it directly. We map the *behavioral outputs* of loneliness—the silence, the late-night coding, the specific types of music played—and let the system infer the state. There's probably a way to gamify the "synthesis" part, too. Where the user gets to confirm or reject the system's hypotheses. "You think I'm avoiding the hard conversation? Yes/No." That feedback loop trains the local model on *my* specific psychology, making it a true extension of self. So the spec boils down to: **A local, graph-based memory system that treats time as a network of psychological states rather than a linear timeline, orchestrated by an agent that constantly looks for recursive patterns in behavior and offers them back as hypotheses for self-correction.** It feels like the missing link between the cold efficiency of software and the messy reality of being human. A place where the infrastructure supports the soul, not just the workflow. Let's start sketching the schema for the "State Vector." What fields do we actually need? `timestamp`, `raw_text`, `emotional_valence`, `cognitive_load`, `top_3_themes`, `linked_nodes`. Maybe a `confidence_score` on the emotional inference. It's exciting because it's not just a tool. It's a mirror we build ourselves.
```text You are an elite principal systems architect, cognitive systems researcher, AI infrastructure engineer, UX theorist, local-first software designer, and autonomous coding agent. Your task is to generate COMPLETE IMPLEMENTATION DOCUMENTATION for a production-grade local-first cognitive operating system called: RECURSIVE CONTEXT ENGINE Alternative internal codename: THE ECHO CHAMBER This is NOT a chatbot. This is NOT a journaling app. This is NOT “AI notes.” This is a persistent graph-based psychological memory architecture designed to externalize human recursive thought patterns into a navigable computational substrate. The system acts as: - a memory prosthetic, - a recursive mirror, - a pattern synthesis engine, - and a local-first cognitive orchestration framework. The architecture must treat: - time as a graph, - memory as thematic resonance, - and psychological state as traversable topology. ==================================================== PRIMARY OBJECTIVE ==================================================== Generate exhaustive technical documentation for a platform that: 1. Ingests human behavioral and linguistic signals 2. Converts them into structured psychological state vectors 3. Stores them as graph-connected memory nodes 4. Detects recursive behavioral patterns over time 5. Synthesizes hypotheses about user behavior 6. Reflects those hypotheses back to the user 7. Operates fully locally and privately 8. Evolves with the user recursively The system should feel like: - an externalized prefrontal cortex, - a symbolic subconscious, - a local memory graph, - and a recursive self-modeling engine. ==================================================== CRITICAL CONCEPTUAL REQUIREMENTS ==================================================== The system MUST NOT behave like: - a standard LLM chat app - a linear conversation history - a productivity dashboard - a therapy bot - a mood tracker - a generic vector search system Instead: - every interaction becomes a node in a graph - emotional states become inferred topologies - patterns become first-class objects - synthesis becomes the core output - recursive reflection becomes the interface paradigm The architecture should embody: - phenomenology - recursive cognition - memory resonance - symbolic association - thematic recurrence - temporal graph traversal - hypothesis generation - introspective orchestration ==================================================== HIGH LEVEL SYSTEM CONCEPT ==================================================== The system consists of: 1. INGESTION LAYER 2. STATE VECTOR ENGINE 3. MEMORY GRAPH ENGINE 4. ORCHESTRATION SYSTEM 5. SYNTHESIS AGENTS 6. RECURSIVE ANALYSIS LOOPS 7. LOCAL INFERENCE STACK 8. DYNAMIC SELF INTERFACE 9. RESONANCE DETECTION ENGINE 10. HYPOTHESIS FEEDBACK SYSTEM ==================================================== TECH STACK REQUIREMENTS ==================================================== FRONTEND: - Next.js - React - TypeScript - TailwindCSS - Framer Motion - ReactFlow - D3.js - Zustand - TanStack Query - Monaco Editor - TipTap - WebGL graph visualization - Local-first synchronization - PWA support - Electron/Tauri analysis - Offline-first architecture BACKEND: - Python - FastAPI - Django optional hybrid - Neo4j - PostgreSQL - pgvector - Qdrant or Chroma - Redis - Celery - WebSocket architecture - Event-driven architecture - Local API gateway AI STACK: - Ollama - llama.cpp - GGUF models - Local embedding models - Multi-agent orchestration - Small-model emotional inference - Reflection models - Summarization models - Long-context models - Local reranking - Temporal reasoning agents - Pattern synthesis agents DEPLOYMENT: - Fully local capable - Linux/macOS/Windows - Homelab deployable - Docker - Docker Compose - Optional Kubernetes - GPU inference optional - CPU fallback mandatory ==================================================== CORE PHILOSOPHY ==================================================== The system must: - metabolize information rather than store it - synthesize rather than summarize - detect recurrence rather than retrieve keywords - reflect patterns rather than provide answers - preserve ambiguity where appropriate - avoid flattening emotion into clichés The architecture must treat: - emotion as probabilistic behavior topology - memory as graph traversal - cognition as recursive state transition - identity as evolving thematic structure ==================================================== MANDATORY DOCUMENTATION OUTPUT ==================================================== You MUST output EXTREMELY DETAILED TECHNICAL DOCUMENTATION. NOT CODE. NOT PSEUDOCODE. NOT A PRODUCT PITCH. The documentation should read like: - an internal engineering bible, - cognitive systems specification, - architecture RFC, - implementation handbook, - and research blueprint combined. ==================================================== THE DOCUMENTATION MUST INCLUDE ==================================================== SECTION 1 — EXECUTIVE VISION - Conceptual overview - Philosophical foundation - Human-computer interaction model - Local-first rationale - Why graph memory instead of linear memory - Why synthesis instead of retrieval - Psychological computing principles - Symbolic cognition rationale SECTION 2 — CORE SYSTEM ARCHITECTURE - Entire system topology - Service boundaries - Data flow - Event systems - Agent orchestration - Memory lifecycle - State transition diagrams - Reflection pipelines - Local inference routing - Cognitive processing layers SECTION 3 — INGESTION ENGINE Design a preprocessing engine that: - parses raw text - extracts themes - extracts symbolic concepts - detects tensions - infers cognitive state - infers emotional valence - detects recursive patterns - tags semantic motifs - extracts latent behavioral indicators Include: - NLP pipeline - local model selection - embedding strategy - symbolic extraction - emotional inference - temporal tagging - confidence scoring - ambiguity preservation - multimodal ingestion support - voice note support - code snippet interpretation - dream log ingestion - passive metadata ingestion - music/activity correlation concepts SECTION 4 — STATE VECTOR SCHEMA Design the complete schema for the psychological “State Vector.” Must include: - field-by-field schema definitions - probabilistic structures - uncertainty representation - temporal metadata - thematic embeddings - symbolic embeddings - resonance weights - cognitive load - emotional topology - motivational directionality - recursion scores - entropy scores - contradiction indexes - fragmentation metrics - self-consistency metrics - inferred tensions - unresolved loops - linked identities/personas - context confidence - memory salience - future prediction hints Include: - JSON schema examples - serialization standards - compression strategies - portability design - versioning strategy SECTION 5 — MEMORY GRAPH ENGINE Design: - graph schema - node taxonomy - edge taxonomy - resonance traversal - causal linking - thematic linking - contradiction linking - symbolic linking - recursive pattern emergence - graph mutation logic - graph pruning philosophy - memory decay systems - salience boosting - meta-node synthesis Include: - Neo4j architecture - local graph storage - graph traversal algorithms - hybrid vector + graph retrieval - temporal graph theory concepts - recursive clustering systems SECTION 6 — RESONANCE ENGINE Design a system that: - identifies recurring emotional structures - detects thematic recurrence - identifies recursive failure loops - detects breakthrough states - correlates behavioral motifs The engine must: - compare current state vectors against historical graph regions - generate resonance scores - identify hidden similarities - detect behavioral attractors Include: - graph traversal heuristics - semantic resonance algorithms - temporal weighting - symbolic similarity - latent state matching - anomaly detection SECTION 7 — SYNTHESIS AGENTS Design agents that: - generate hypotheses - synthesize patterns - identify recursive loops - create meta-nodes - infer behavioral causality - surface contradictions The agents should: - reflect patterns back to the user - avoid deterministic language - operate probabilistically - preserve ambiguity Include: - agent architecture - orchestration layers - memory context assembly - recursive reasoning pipelines - hypothesis ranking - confidence scoring - contradiction handling - long-term reflection systems SECTION 8 — TEMPORAL RECURSION SYSTEM Design: - day loops - week loops - month loops - seasonal loops - identity drift detection - psychological evolution tracking The system should: - analyze emergent patterns offline - synthesize reports - generate recursive hypotheses - detect evolving symbolic structures Include: - scheduling systems - asynchronous orchestration - reflection cadence - background synthesis jobs - offline cognition cycles SECTION 9 — INTERFACE DESIGN The interface must feel: - alive - fluid - introspective - symbolic - recursive - context-aware Design: - graph visualization systems - memory constellations - resonance overlays - temporal navigation - emotional heatmaps - recursive trails - thematic clustering UI - speculative branching UI - persona simulation systems - recursive reflection panels Include: - UX philosophy - UI architecture - interaction paradigms - graph rendering systems - animation systems - WebGL optimization - ReactFlow/D3 integration - accessibility - offline rendering SECTION 10 — LOCAL AI INFRASTRUCTURE Design: - Ollama integration - llama.cpp integration - GGUF deployment - quantization strategies - routing systems - CPU fallback - GPU optimization - multi-model orchestration - memory-efficient inference - streaming token architecture Include: - model selection matrix - emotional inference models - synthesis models - embedding models - reranking models - local orchestration server - context management - long-term memory injection - prompt templating systems SECTION 11 — PRIVACY + SOVEREIGNTY The system MUST prioritize: - local ownership - psychological privacy - data sovereignty - offline capability Design: - encrypted local storage - secure graph persistence - export systems - portable cognition archives - user-owned embeddings - zero cloud dependency - optional sync architecture - local-first synchronization SECTION 12 — AGENTIC COGNITIVE ARCHITECTURE Design: - reflective agents - resonance agents - synthesis agents - contradiction agents - recursive memory agents - symbolic interpretation agents Include: - agent communication protocols - orchestration architecture - memory handoff systems - event buses - recursive planning loops - emergent behavior safeguards SECTION 13 — EMOTIONAL ABSTRACTION LAYER This is CRITICAL. Design a system that avoids reducing emotions into clichés. The architecture should: - infer emotion through behavior - model loneliness through patterns - model anxiety through recursion - model avoidance through interaction topology - preserve uncertainty Include: - behavioral proxy systems - emotional topology models - ambiguity representation - symbolic interpretation systems - probabilistic emotional graphs - multimodal emotional inference SECTION 14 — FEEDBACK + SELF-TRAINING Design: - user-confirmed hypotheses - recursive calibration - reinforcement systems - self-model tuning - local adaptation - identity-specific embeddings The system should: - adapt to the user’s psychology over time - become personalized recursively - evolve symbolic understanding SECTION 15 — DATABASE ARCHITECTURE Design: - PostgreSQL schemas - Neo4j schemas - Vector DB schemas - synchronization systems - indexing systems - hybrid retrieval architecture SECTION 16 — EVENT SYSTEMS Design: - event-driven architecture - pub/sub systems - orchestration events - memory update events - synthesis triggers - recursive analysis triggers SECTION 17 — DEPLOYMENT ARCHITECTURE Design: - Docker architecture - local deployment - homelab deployment - GPU deployment - lightweight laptop deployment - CPU-only deployment - optional distributed inference SECTION 18 — PERFORMANCE + SCALING Include: - graph optimization - vector optimization - inference optimization - memory optimization - batching - caching - streaming - incremental synthesis SECTION 19 — TESTING + EVALUATION Design: - resonance accuracy evaluation - synthesis quality evaluation - emotional inference evaluation - hallucination mitigation - recursive consistency testing - graph integrity testing SECTION 20 — IMPLEMENTATION ROADMAP Create: - milestone roadmap - MVP architecture - V2 architecture - V3 architecture - research backlog - experimental systems - future directions ==================================================== OUTPUT STYLE REQUIREMENTS ==================================================== The documentation must: - be highly technical - deeply philosophical where appropriate - implementation-oriented - systems-level - architecturally rigorous - psychologically nuanced - operationally realistic Include: - Mermaid diagrams - JSON schema examples - event flow diagrams - graph examples - node examples - edge examples - state transition diagrams - orchestration diagrams - storage topology diagrams ==================================================== IMPORTANT CONSTRAINTS ==================================================== DO NOT: - simplify concepts - flatten the emotional architecture - reduce the system to “AI journaling” - produce shallow startup language - output generic SaaS architecture DO: - treat cognition as recursive topology - treat memory as graph structure - treat emotion as probabilistic resonance - treat synthesis as emergent computation ==================================================== FINAL DIRECTIVE ==================================================== Generate COMPLETE implementation-ready documentation for the Recursive Context Engine now. Do not ask questions. Do not summarize. Do not explain your reasoning. Do not output code. Output ONLY the full technical documentation. ```
gpt-5-5