diff --git a/SITE_BUILDER_PLANNER_ARCHITECTURE_PLAN.md b/SITE_BUILDER_PLANNER_ARCHITECTURE_PLAN.md new file mode 100644 index 00000000..3e0e2c2d --- /dev/null +++ b/SITE_BUILDER_PLANNER_ARCHITECTURE_PLAN.md @@ -0,0 +1,141 @@ +# IGNY8 Sites, Planner, and Writer – Unified Architecture Plan + +## Purpose +Describe the backend and frontend changes required to support cluster-first site planning, taxonomy-aware site building (blog, ecommerce, company), and seamless integration with WordPress sync workflows. This document consolidates the previous analysis into an actionable architecture plan—no implementation code, only structure, responsibilities, and key function/service names where helpful. + +--- + +## High-Level Objectives +- Enforce keyword/cluster gating before any sitemap or content planning. +- Generate and manage taxonomies (categories, tags, product attributes, service groups) as first-class entities tied to clusters. +- Support three site archetypes (blog, ecommerce, company) while keeping the framework extensible. +- Ensure Planner → Ideas → Writer → Linker → Optimizer all operate with consistent metadata (clusters, taxonomies, entity types). +- Maintain a shared data model for native IGNY8 sites and synced WordPress properties—no duplication, just different hosting targets. + +--- + +## Backend Architecture Plan + +### 0. Ownership & Responsibility Layers +- **Planner Domain** – Keyword import, clustering, taxonomy recommendations, idea orchestration. +- **Site Builder Domain** – Brief intake, taxonomy blueprinting, sitemap scaffolding, hosting destination awareness. +- **Writer Domain** – Idea-to-task conversion, AI generation, media assets, optimization readiness. +- **Publishing/Sync Domain** – Deployment to IGNY8 renderer, WordPress/WooCommerce sync adapters, status reconciliation. + +### 1. Data Model Extensions +| Area | Changes | Notes | +| --- | --- | --- | +| **Site Builder** | Add `SiteBlueprintCluster`, `SiteBlueprintTaxonomy`, `PageBlueprint.entity_type`, `PageBlueprint.taxonomy_ref_id`. Support taxonomy types (`blog_category`, `blog_tag`, `product_category`, `product_tag`, `product_attribute`, `service_category`). Track cluster role (hub, pillar, supporting). | Enables sitemap to reference clusters/taxonomies explicitly. | +| **Planner (Keywords/Clusters/Ideas)** | Enhance `Clusters` with `context_type` (`topic`, `attribute`, `service_line`), `dimension_meta` JSON. Extend `Keywords` with `attribute_values`. Expand `ContentIdeas` to include `site_entity_type`, `taxonomy_id`, `cluster_role`. | Allows multi-dimensional clustering (topic + attribute) and taxonomy seeding. | +| **Writer (Tasks/Content/Images)** | Add `Tasks.entity_type`, `Tasks.taxonomy_id`, `Tasks.cluster_role`, `Tasks.product_data`. Introduce `ContentClusterMap`, `ContentTaxonomyMap`, `ContentAttributeMap` tables. Expand `Images` with `usage_context`. | Gives structured metadata for publishing, linking, and optimization. | +| **Linker & Optimizer** | Update services to rely on new mapping tables and cluster dimensions for auto-linking and scoring. | No schema change beyond indices referencing new relations. | +| **WordPress Sync** | Store external taxonomy IDs within `SiteBlueprintTaxonomy`, `ContentTaxonomyMap`, etc., so synced content maps cleanly. | Requires metadata fields like `external_reference`. | + +### 2. Service / Workflow Updates +- **StructureGenerationService.generate_structure**: extend prompts to consume cluster lists, taxonomy seeds, and site type; output page → cluster/taxonomy assignments. +- **TaxonomyService (new)**: handles CRUD of blueprint taxonomies, ties them to clusters/keywords, imports from WordPress/WooCommerce. +- **ClusteringService**: upgrade to produce topic + attribute layers, propose taxonomy seeds, flag uncovered product/service dimensions. +- **IdeasService & ContentGeneration pipeline**: ensure all tasks carry cluster/taxonomy metadata; enforce “no cluster, no idea/task” rule. +- **LinkingService / OptimizerService**: leverage `ContentClusterMap` and `ContentAttributeMap` to generate hub ↔ attribute links, evaluate dimension coverage. +- **WordPressSyncService**: fully implement taxonomy + product fetching, map to IGNY8 schema, and reuse TaxonomyService for storage. +- **WorkflowStateService (new)**: persists user progress for each site build (step status, prerequisites met) to drive state-aware frontend. +- **Validation hooks**: per-step API validators (e.g., `validate_clusters_attached(site_blueprint_id)`) exposed to frontend for gating buttons. + +### 3. API & Validation +- Builder endpoints must require cluster selection and taxonomy definition before allowing `generate_structure`. +- Planner/Ideas endpoints validate that requested entity types align with available taxonomies (e.g., product ideas require product categories/attributes). +- Writer endpoints include entity metadata in serializers to surface context in dashboards. + +### 4. End-to-End Backend Flow (Self-Guided) +1. **Wizard Initiation** + - `POST /site-builder/blueprints/` creates draft blueprint + workflow state record (step = `business_details`). +2. **Cluster Attachment** + - `POST /site-builder/blueprints/{id}/clusters/attach` validates at least one planner cluster; updates workflow state → `clusters_ready`. +3. **Taxonomy Blueprinting** + - `POST /site-builder/blueprints/{id}/taxonomies/` uses `TaxonomyService`. Each taxonomy row stored with cluster references; workflow state → `taxonomies_ready` when required types filled per site archetype. +4. **Sitemap Generation** + - `POST /site-builder/blueprints/{id}/generate_structure/` allowed only if previous flags true. Service writes `structure_json`, `PageBlueprint` rows, `SiteBlueprintCluster` coverage map; workflow state → `sitemap_ready`. +5. **Coverage Check** + - `POST /site-builder/blueprints/{id}/coverage/confirm` ensures each cluster has hub + at least one supporting entity; sets state → `ideas_ready`. +6. **Ideas Creation** + - `POST /planner/content-ideas/bulk_from_blueprint/` generates ideas referencing blueprint/page IDs; state → `ideas_in_progress`. +7. **Writer Tasks** + - `PageGenerationService.generate_all_pages` creates `Tasks` with entity metadata; `Content` pipeline runs as today but includes cluster/taxonomy associations. +8. **Link/Optimize** + - Linker/optimizer services query new mapping tables to produce suggestions and scorecards; statuses fed back to workflow to show completion percentages. +9. **Publish/Sync** + - `SitesRendererAdapter` or `WordPressAdapter` reads structured metadata for deployment, ensuring taxonomies exist upstream (adapter auto-creates if missing). + +--- + +## Frontend Architecture Plan + +### 1. Wizard & Sites Module +| Step | Enhancements | +| --- | --- | +| Business Details | Site type selector (blog/ecommerce/company) with hosting options (IGNY8, WordPress); auto-detect hosting if WP integration exists. | +| Cluster Assignment | Dedicated step to select/attach planner clusters (with search/filter); block progress until at least one cluster chosen; show metrics (keywords, volume). | +| Taxonomy Builder | Visual editor for categories/tags/product attributes/service groups. Allow suggestions from clustering results and imports from WP. Support linking each taxonomy item to a cluster (hub or attribute). | +| Sitemap Review | Present AI-generated pages grouped by cluster/taxonomy; allow manual adjustments; highlight uncovered clusters or orphaned taxonomies. Show checklist for required hub/supporting pages per cluster. | +| Ideas Hand-off | Provide UI to send selected pages to Ideas module with optional guidance prompt (2nd prompt requirement). Display confirmation modal summarizing clusters + page counts. | + +### 1.1 Wizard State Management (Self-Guided UX) +- Use a dedicated Zustand/Redux slice `builderWorkflowStore` to track: `currentStep`, `completedSteps`, `blockingIssues`, `blueprintState`. +- Each step component fetches validation status via `/site-builder/workflow/{blueprintId}` to decide if Next button is enabled. +- Inline “Why disabled?” tooltips list missing requirements (e.g., “Attach ≥1 cluster with ≥3 keywords each”). +- Breadcrumb/progress indicator shows step numbers + completion badges. +- Autosave after each interaction; resume wizard lands user back on last incomplete step. + +### 2. Planner & Keyword UI +- Update cluster list views to show context type and associated taxonomies. +- Add attribute dimension visualization (e.g., matrix of clusters vs attributes). +- Ensure keyword table supports attribute tagging and multi-dimensional filtering. + +### 3. Ideas & Writer Dashboards +- Surfaces for entity types (blog post, product, service, taxonomy page) with filters. +- Editors receive context chips (cluster, taxonomy, attribute). Provide quick links to hub pages and attribute groups. +- Validation states: warn if content lacks required taxonomy or attribute coverage before publishing. +- Task list views grouped by blueprint/site; show progress bars (e.g., “Products: 5/12 drafted”). +- Writer editor side panel summarises: assigned cluster, target taxonomy, keyword cluster metrics, attribute list. + +### 4. Linker & Optimizer UI +- Linker suggestion panel grouped by cluster role (hub → supporting, hub → attribute). +- Optimizer scorecards showing coverage per cluster dimension (topic, attribute, intent). + +### 5. WordPress Sync Screens +- Integration settings show detected taxonomies and site type. +- Sync dashboard lists imported posts/products/services with their cluster/taxonomy assignments; allow manual re-mapping. +- Provide “Sync health” panel: taxonomy parity, cluster coverage, last sync time. Buttons disabled if prerequisites unmet (e.g., no clusters mapped). + +### 6. UX Guardrails & Guidance +- **Contextual Helpers**: Each wizard step includes collapsible explainer matching backend validations (“Clusters drive sitemap; select clusters to continue.”). +- **Empty States**: Planner/writer views show CTA buttons to jump back into wizard steps when prerequisites missing. +- **Notifications**: System toasts (or inline callouts) when backend rejects action—links take user to offending step. +- **Review Mode**: After completion, a read-only summary page lists all steps with “Edit” buttons, ensuring users never feel lost. + +--- + +## Workflow Alignment Summary +1. **Site Brief Intake** → choose site type + hosting, gather business data. +2. **Cluster Gating** → attach keyword clusters/keywords; enforce before sitemap. +3. **Taxonomy Blueprint** → define or import taxonomies linked to clusters. +4. **AI Sitemap Generation** → produce pages with entity types + cluster/taxonomy refs. +5. **Coverage Validation** → ensure no cluster/taxonomy gaps before moving on. +6. **Ideas Creation** → push sitemap nodes into Ideas with cluster/taxonomy metadata; capture secondary prompt. +7. **Writer Flow** → existing pipeline enhanced with entity metadata, rich product/service attributes, and multi-dimensional content blocks. +8. **Linking & Optimization** → leverage new relations for automatic internal linking and SEO scoring. +9. **Deployment / Sync** → IGNY8 hosting deploys enriched content; WordPress adapter syncs posts/products/services with matching taxonomies (no duplication, just publishing). + +--- + +## Implementation Notes +- Prioritize schema migrations and service updates before UI changes to ensure APIs provide necessary data. +- Keep prompts/configs environment-driven for easy tuning as new site types (e.g., SaaS portals) are added later. +- Maintain backward compatibility by auto-populating default values for existing blueprints/tasks until users opt into the new flow. +- Testing should cover: multi-site types, imported WordPress data, planner → writer gating, and deployment outputs. + +--- + +*Document owner: Architecture team.* +*Last updated: {{DATE}} (replace during edits).* + diff --git a/backend/celerybeat-schedule b/backend/celerybeat-schedule index 2116665f..4aa3913c 100644 Binary files a/backend/celerybeat-schedule and b/backend/celerybeat-schedule differ diff --git a/master-docs/DIAGNOSIS-AUTHENTICATION-ISSUE.md b/master-docs/DIAGNOSIS-AUTHENTICATION-ISSUE.md deleted file mode 100644 index 8a16b53a..00000000 --- a/master-docs/DIAGNOSIS-AUTHENTICATION-ISSUE.md +++ /dev/null @@ -1,273 +0,0 @@ -# Authentication & Account Context Diagnosis - -## Issue Summary -**Problem**: Wrong user showing without proper rights - authentication/account context mismatch - -## Architecture Overview - -### Request Flow -``` -1. Request arrives - ↓ -2. Django Middleware Stack (settings.py:74-88) - - SecurityMiddleware - - WhiteNoiseMiddleware - - CorsMiddleware - - SessionMiddleware - - CommonMiddleware - - CsrfViewMiddleware - - AuthenticationMiddleware (sets request.user from session) - ↓ -3. AccountContextMiddleware (line 83) - - Extracts account from JWT token OR session - - Sets request.account - ↓ -4. DRF Authentication Classes (settings.py:210-214) - - JWTAuthentication (runs first) - - CSRFExemptSessionAuthentication - - BasicAuthentication - ↓ -5. View/ViewSet - - Uses request.user (from DRF auth) - - Uses request.account (from middleware OR JWTAuthentication) -``` - -## Critical Issues Found - -### Issue #1: Duplicate Account Setting Logic -**Location**: Two places set `request.account` with different logic - -1. **AccountContextMiddleware** (`backend/igny8_core/auth/middleware.py:99-106`) - ```python - if account_id: - account = Account.objects.get(id=account_id) - # If user's account changed, use the new one from user object - if user.account and user.account.id != account_id: - request.account = user.account # Prioritizes user's current account - else: - request.account = account # Uses token's account - ``` - -2. **JWTAuthentication** (`backend/igny8_core/api/authentication.py:64-80`) - ```python - account_id = payload.get('account_id') - account = None - if account_id: - account = Account.objects.get(id=account_id) # Always uses token's account - - if not account: - account = getattr(user, 'account', None) # Fallback only if no account_id - - request.account = account # OVERWRITES middleware's account - ``` - -**Problem**: -- Middleware validates if user's account changed and prioritizes `user.account` -- JWTAuthentication runs AFTER middleware and OVERWRITES `request.account` without validation -- This means middleware's validation is ignored - -### Issue #2: User Object Loading Mismatch -**Location**: Different user loading strategies - -1. **AccountContextMiddleware** (line 98) - ```python - user = User.objects.select_related('account', 'account__plan').get(id=user_id) - ``` - - Loads user WITH account relationship (efficient, has account data) - -2. **JWTAuthentication** (line 58) - ```python - user = User.objects.get(id=user_id) - ``` - - Does NOT load account relationship - - When checking `user.account`, it triggers a separate DB query - - If account relationship is stale or missing, this can fail - -**Problem**: -- JWTAuthentication's user object doesn't have account relationship loaded -- When `/me` endpoint uses `request.user.id` and then serializes with `UserSerializer`, it tries to access `user.account` -- This might trigger lazy loading which could return wrong/stale data - -### Issue #3: Middleware Updates request.user (Session Auth) -**Location**: `backend/igny8_core/auth/middleware.py:32-46` - -```python -if hasattr(request, 'user') and request.user and request.user.is_authenticated: - user = UserModel.objects.select_related('account', 'account__plan').get(id=request.user.id) - request.user = user # OVERWRITES request.user - request.account = user_account -``` - -**Problem**: -- Middleware is setting `request.user` for session authentication -- But then JWTAuthentication runs and might set a DIFFERENT user (from JWT token) -- This creates a conflict where middleware's user is overwritten - -### Issue #4: Token Account vs User Account Mismatch -**Location**: Token generation vs user's current account - -**Token Generation** (`backend/igny8_core/auth/utils.py:30-57`): -```python -def generate_access_token(user, account=None): - if account is None: - account = getattr(user, 'account', None) - - payload = { - 'user_id': user.id, - 'account_id': account.id if account else None, # Token stores account_id at login time - ... - } -``` - -**Problem**: -- Token is generated at login with `user.account` at that moment -- If user's account changes AFTER login (e.g., admin moves user to different account), token still has old `account_id` -- Middleware tries to handle this (line 103-104), but JWTAuthentication overwrites it - -### Issue #5: /me Endpoint Uses request.user Without Account Relationship -**Location**: `backend/igny8_core/auth/urls.py:188-197` - -```python -def get(self, request): - user = UserModel.objects.select_related('account', 'account__plan').get(id=request.user.id) - serializer = UserSerializer(user) - return success_response(data={'user': serializer.data}, request=request) -``` - -**Problem**: -- `/me` endpoint correctly loads user with account relationship -- BUT `request.user` (from JWTAuthentication) doesn't have account relationship loaded -- If other code uses `request.user.account` directly, it might get wrong/stale data - -## Root Cause Analysis - -### Primary Root Cause -**JWTAuthentication overwrites `request.account` set by middleware without validating if user's account changed** - -### Secondary Issues -1. JWTAuthentication doesn't load user with account relationship (inefficient + potential stale data) -2. Middleware sets `request.user` for session auth, but JWTAuthentication might overwrite it -3. Token's `account_id` can become stale if user's account changes after login - -## Data Flow Problem - -### Current Flow (BROKEN) -``` -1. Request with JWT token arrives - ↓ -2. AccountContextMiddleware runs: - - Decodes JWT token - - Gets user_id=5, account_id=10 - - Loads User(id=5) with account relationship - - Checks: user.account.id = 12 (user moved to account 12) - - Sets: request.account = Account(id=12) ✅ CORRECT - ↓ -3. JWTAuthentication runs: - - Decodes JWT token (again) - - Gets user_id=5, account_id=10 - - Loads User(id=5) WITHOUT account relationship - - Gets Account(id=10) from token - - Sets: request.account = Account(id=10) ❌ WRONG (overwrites middleware) - - Sets: request.user = User(id=5) (without account relationship) - ↓ -4. View uses request.account (WRONG - account 10 instead of 12) -5. View uses request.user.account (might trigger lazy load, could be stale) -``` - -### Expected Flow (CORRECT) -``` -1. Request with JWT token arrives - ↓ -2. AccountContextMiddleware runs: - - Sets request.account based on token with validation - ↓ -3. JWTAuthentication runs: - - Sets request.user with account relationship loaded - - Does NOT overwrite request.account (respects middleware) - ↓ -4. View uses request.account (CORRECT - from middleware) -5. View uses request.user.account (CORRECT - loaded with relationship) -``` - -## Database Schema Check - -### User Model -- `User.account` = ForeignKey to Account, `db_column='tenant_id'`, nullable -- Relationship: User → Account (many-to-one) - -### Account Model -- `Account.owner` = ForeignKey to User -- Relationship: Account → User (many-to-one, owner) - -### Potential Database Issues -- If `User.account_id` (tenant_id column) doesn't match token's `account_id`, there's a mismatch -- If user's account was changed in DB but token wasn't refreshed, token has stale account_id - -## Permission System Check - -### HasTenantAccess Permission -**Location**: `backend/igny8_core/api/permissions.py:25-67` - -```python -def has_permission(self, request, view): - account = getattr(request, 'account', None) - - # If no account in request, try to get from user - if not account and hasattr(request.user, 'account'): - account = request.user.account - - # Check if user belongs to this account - if account: - user_account = request.user.account - return user_account == account or user_account.id == account.id -``` - -**Problem**: -- Permission checks `request.account` vs `request.user.account` -- If `request.account` is wrong (from JWTAuthentication overwrite), permission check fails -- User gets 403 Forbidden even though they should have access - -## Recommendations (Diagnosis Only - No Code Changes) - -### Fix Priority - -1. **CRITICAL**: Make JWTAuthentication respect middleware's `request.account` OR remove duplicate logic - - Option A: JWTAuthentication should check if `request.account` already exists and not overwrite it - - Option B: Remove account setting from JWTAuthentication, let middleware handle it - -2. **HIGH**: Load user with account relationship in JWTAuthentication - - Change `User.objects.get(id=user_id)` to `User.objects.select_related('account', 'account__plan').get(id=user_id)` - -3. **MEDIUM**: Don't set `request.user` in middleware for JWT auth - - Middleware should only set `request.user` for session auth - - For JWT auth, let JWTAuthentication handle `request.user` - -4. **LOW**: Add validation in token generation to ensure account_id matches user.account - - Or add token refresh mechanism when user's account changes - -### Architecture Decision Needed - -**Question**: Should `request.account` be set by: -- A) Middleware only (current middleware logic with validation) -- B) JWTAuthentication only (simpler, but loses validation) -- C) Both, but JWTAuthentication checks if middleware already set it - -**Recommendation**: Option C - Middleware sets it with validation, JWTAuthentication only sets if not already set - -## Files Involved - -1. `backend/igny8_core/auth/middleware.py` - AccountContextMiddleware -2. `backend/igny8_core/api/authentication.py` - JWTAuthentication -3. `backend/igny8_core/auth/urls.py` - MeView endpoint -4. `backend/igny8_core/auth/utils.py` - Token generation -5. `backend/igny8_core/api/permissions.py` - HasTenantAccess permission -6. `backend/igny8_core/settings.py` - Middleware and authentication class order - -## Testing Scenarios to Verify - -1. **User with account_id in token matches user.account** → Should work -2. **User's account changed after login (token has old account_id)** → Currently broken -3. **User with no account in token** → Should fallback to user.account -4. **Developer/admin user** → Should bypass account checks -5. **Session auth vs JWT auth** → Both should work consistently - diff --git a/part2-dev/IGNY8-HOLISTIC-ARCHITECTURE-PLAN.md b/part2-dev/IGNY8-HOLISTIC-ARCHITECTURE-PLAN.md deleted file mode 100644 index 9bcf1b3f..00000000 --- a/part2-dev/IGNY8-HOLISTIC-ARCHITECTURE-PLAN.md +++ /dev/null @@ -1,1025 +0,0 @@ -# IGNY8 HOLISTIC ARCHITECTURE PLAN -**Complete System Architecture, Implementation Strategy, and Structure** - -**Last Updated:** 2025-01-XX -**Purpose:** Comprehensive architecture plan combining existing system, Phase 2 requirements, automation, multi-site management, and best practices. - ---- - -## TABLE OF CONTENTS - -1. [Architecture Overview](#1-architecture-overview) -2. [Container Architecture](#2-container-architecture) -3. [Backend Layer Structure](#3-backend-layer-structure) -4. [Frontend Structure](#4-frontend-structure) -5. [Automation System](#5-automation-system) -6. [Multi-Site Management](#6-multi-site-management) -7. [Volume & Storage Strategy](#7-volume--storage-strategy) -8. [Repository Structure](#8-repository-structure) -9. [Implementation Phases](#9-implementation-phases) -10. [Limits & Boundaries](#10-limits--boundaries) - ---- - -## 1. ARCHITECTURE OVERVIEW - -### 1.1 Core Principles - -| Principle | Description | Implementation | -|-----------|-------------|----------------| -| **Domain-Driven Design** | Organize by business domains, not technical layers | `business/` folder with content, planning, linking, optimization, publishing domains | -| **Service Layer Pattern** | Business logic in services, not ViewSets | All modules delegate to domain services | -| **Single Responsibility** | Each layer has one clear purpose | Core → Domain → Module → Infrastructure | -| **No Duplication** | Reuse services across modules | ContentGenerationService used by Writer + Site Builder | -| **Multi-Tenancy First** | All features respect account/site/sector boundaries | All models inherit AccountBaseModel or SiteSectorBaseModel | -| **Automation Ready** | All functions can be automated via Celery | All AI functions exposed as Celery tasks with scheduling support | - -### 1.2 System Boundaries - -| System | Purpose | Technology | Container | -|--------|---------|------------|-----------| -| **IGNY8 Core App** | Main backend API (all domains) | Django 5.2+ | `igny8_backend` | -| **IGNY8 Main App** | Dashboard UI | React 19 + Vite | `igny8_frontend` | -| **IGNY8 Site Builder** | Site creation wizard | React 19 + Vite | `igny8_site_builder` (NEW) | -| **IGNY8 Sites** | Public site renderer | React 19 + Vite/Next.js | `igny8_sites` (NEW) | -| **IGNY8 Marketing** | Marketing website | React 19 + Vite | `igny8_marketing_dev` (can merge with Sites) | -| **Celery Workers** | Async task processing | Celery + Redis | `igny8_celery_worker` | -| **Celery Beat** | Scheduled automation | Celery Beat | `igny8_celery_beat` | - ---- - -## 2. CONTAINER ARCHITECTURE - -### 2.1 Container Structure - -| Container | Port | Purpose | Volumes | Dependencies | -|-----------|------|---------|---------|--------------| -| `igny8_backend` | 8011:8010 | Django API server | `/data/app/igny8/backend:/app`, `/data/app/logs:/app/logs`, `/data/app/storage:/app/storage` | postgres, redis | -| `igny8_frontend` | 8021:5173 | Main app UI (dev) | `/data/app/igny8/frontend:/app` | igny8_backend | -| `igny8_site_builder` | 8022:5175 | Site Builder UI (NEW) | `/data/app/igny8/site-builder:/app` | igny8_backend | -| `igny8_sites` | 8024:5176 | Sites renderer (NEW) | `/data/app/igny8/sites:/app`, `/data/app/sites-data:/sites` | igny8_backend | -| `igny8_marketing_dev` | 8023:5174 | Marketing site | `/data/app/igny8/frontend:/app` | igny8_backend | -| `igny8_celery_worker` | - | Async tasks | `/data/app/igny8/backend:/app`, `/data/app/logs:/app/logs` | postgres, redis | -| `igny8_celery_beat` | - | Scheduled tasks | `/data/app/igny8/backend:/app`, `/data/app/logs:/app/logs` | postgres, redis | - -### 2.2 Volume Strategy - -| Volume Path | Purpose | Mount Type | Backup Strategy | -|-------------|---------|------------|-----------------| -| `/data/app/igny8/backend` | Backend code (dev) | Bind mount (rw) | Git repo | -| `/data/app/igny8/frontend` | Frontend code (dev) | Bind mount (rw) | Git repo | -| `/data/app/igny8/site-builder` | Site Builder code (NEW) | Bind mount (rw) | Git repo | -| `/data/app/igny8/sites` | Sites renderer code (NEW) | Bind mount (rw) | Git repo | -| `/data/app/storage` | Generated files, images | Named volume | Daily backup | -| `/data/app/sites-data` | Rendered site files (NEW) | Named volume | Daily backup | -| `/data/app/logs` | Application logs | Named volume | Rotate weekly | -| `/data/app/cache` | Redis cache (optional) | Named volume | No backup | - -**Volume Improvements:** -- Use named volumes for data (storage, sites-data, logs) - better performance, easier backup -- Use bind mounts only for code (development) -- Production: Use named volumes for all, code deployed via images - ---- - -## 3. BACKEND LAYER STRUCTURE - -### 3.1 Complete Backend Structure - -``` -backend/igny8_core/ -├── core/ # CORE LAYER (Foundation) -│ ├── auth/ # Multi-tenancy, users, accounts -│ │ ├── models.py # Account, User, Plan, Site, Sector -│ │ ├── serializers.py -│ │ ├── views.py -│ │ └── urls.py -│ │ -│ ├── base/ # BASE CLASSES (Shared) -│ │ ├── models.py # AccountBaseModel, SiteSectorBaseModel -│ │ ├── viewsets.py # AccountModelViewSet, SiteSectorModelViewSet -│ │ └── serializers.py # Base serializers -│ │ -│ └── api/ # API INFRASTRUCTURE -│ ├── base.py # Base ViewSets -│ ├── response.py # success_response, error_response -│ ├── exceptions.py # Unified exception handler -│ ├── pagination.py # CustomPageNumberPagination -│ ├── permissions.py # IsAuthenticatedAndActive, HasTenantAccess -│ └── throttles.py # DebugScopedRateThrottle -│ -├── business/ # BUSINESS LAYER (Business Logic) -│ ├── content/ # Content domain -│ │ ├── models.py # Content, Tasks, Images (unified, extended) -│ │ ├── services/ -│ │ │ ├── content_generation_service.py # Unified generation -│ │ │ ├── content_pipeline_service.py # Pipeline orchestration -│ │ │ └── content_versioning_service.py # Version management -│ │ └── repositories.py # ContentRepository (if needed) -│ │ -│ ├── planning/ # Planning domain -│ │ ├── models.py # Keywords, Clusters, Ideas -│ │ └── services/ -│ │ ├── clustering_service.py -│ │ └── ideas_service.py -│ │ -│ ├── linking/ # Linking domain (NEW) -│ │ ├── models.py # InternalLinks, LinkGraph -│ │ └── services/ -│ │ └── linker_service.py -│ │ -│ ├── optimization/ # Optimization domain (NEW) -│ │ ├── models.py # OptimizationTask, OptimizationScores -│ │ └── services/ -│ │ └── optimizer_service.py -│ │ -│ ├── publishing/ # Publishing domain (NEW) -│ │ ├── models.py # PublishingRecord, DeploymentRecord -│ │ └── services/ -│ │ ├── publisher_service.py -│ │ ├── adapters/ -│ │ │ ├── base_adapter.py -│ │ │ ├── wordpress_adapter.py -│ │ │ └── sites_renderer_adapter.py -│ │ └── deployment_service.py -│ │ -│ ├── site_building/ # Site Building domain (NEW) -│ │ ├── models.py # SiteBlueprint, PageBlueprint -│ │ └── services/ -│ │ ├── structure_generation_service.py -│ │ └── site_deployment_service.py -│ │ -│ └── billing/ # Billing domain -│ ├── models.py # Credits, Transactions -│ └── services/ -│ └── credit_service.py -│ -├── modules/ # MODULE LAYER (API/UI Interface) -│ ├── planner/ # Planner API endpoints -│ │ ├── views.py # ViewSets (thin, delegates to services) -│ │ ├── serializers.py # Request/Response serializers -│ │ └── urls.py -│ │ -│ ├── writer/ # Writer API endpoints (legacy name) -│ │ ├── views.py -│ │ ├── serializers.py -│ │ └── urls.py -│ │ -│ ├── content/ # Unified content API (NEW) -│ │ ├── views.py -│ │ ├── serializers.py -│ │ └── urls.py -│ │ -│ ├── site_builder/ # Site Builder API (NEW) -│ │ ├── views.py -│ │ ├── serializers.py -│ │ └── urls.py -│ │ -│ ├── linker/ # Linker API (NEW) -│ │ ├── views.py -│ │ └── urls.py -│ │ -│ ├── optimizer/ # Optimizer API (NEW) -│ │ ├── views.py -│ │ └── urls.py -│ │ -│ ├── publisher/ # Publisher API (NEW) -│ │ ├── views.py -│ │ └── urls.py -│ │ -│ ├── integration/ # Site Integration API (NEW) -│ │ ├── views.py -│ │ └── urls.py -│ │ -│ ├── automation/ # Automation API (NEW) -│ │ ├── views.py -│ │ ├── serializers.py -│ │ └── urls.py -│ │ -│ ├── system/ # System API -│ │ ├── views.py -│ │ └── urls.py -│ │ -│ └── billing/ # Billing API -│ ├── views.py -│ └── urls.py -│ -├── infrastructure/ # INFRASTRUCTURE LAYER -│ ├── ai/ # AI Framework (existing) -│ │ ├── engine.py -│ │ ├── functions/ -│ │ │ ├── auto_cluster.py -│ │ │ ├── generate_ideas.py -│ │ │ ├── generate_content.py -│ │ │ ├── generate_image_prompts.py -│ │ │ ├── generate_images.py -│ │ │ ├── generate_site_structure.py # NEW for Site Builder -│ │ │ └── optimize_content.py # NEW for Optimizer -│ │ ├── registry.py -│ │ └── tasks.py # run_ai_task -│ │ -│ ├── external/ # External integrations -│ │ ├── wordpress.py # WordPress client -│ │ ├── sites_renderer.py # Sites renderer client (NEW) -│ │ └── shopify.py # Shopify client (Future) -│ │ -│ ├── storage/ # Storage abstractions -│ │ └── file_storage.py -│ │ -│ └── messaging/ # Async messaging -│ ├── celery_tasks.py # Celery task definitions -│ └── automation_tasks.py # Automation tasks (NEW) -│ -└── shared/ # SHARED LAYER - ├── schemas/ # Shared schemas - │ ├── blocks.py # Block component schema - │ └── content_types.py # Content type definitions - │ - ├── utils/ # Shared utilities - │ ├── content_normalizer.py - │ └── queue_manager.py - │ - └── middleware/ # Middleware - ├── account.py # AccountContextMiddleware - └── request_id.py # RequestIDMiddleware -``` - -### 3.2 Model Extensions - -| Model | Current Location | New Location | Extensions Needed | -|-------|------------------|-------------|-------------------| -| `Content` | `modules/writer/models.py` | `business/content/models.py` | Add: `entity_type`, `json_blocks`, `structure_data`, `linker_version`, `optimizer_version`, `internal_links`, `optimization_scores`, `published_to`, `external_ids`, `source`, `sync_status`, `external_id`, `external_url`, `sync_metadata` | -| `Tasks` | `modules/writer/models.py` | `business/content/models.py` | Add: `entity_type` choices (product, service, taxonomy, etc.) | -| `Keywords` | `modules/planner/models.py` | `business/planning/models.py` | No changes | -| `Clusters` | `modules/planner/models.py` | `business/planning/models.py` | No changes | -| `ContentIdeas` | `modules/planner/models.py` | `business/planning/models.py` | Add: `entity_type` support | -| `InternalLinks` | - | `business/linking/models.py` | NEW: `source_id`, `target_id`, `anchor`, `position`, `link_type` | -| `OptimizationTask` | - | `business/optimization/models.py` | NEW: `content_id`, `type`, `target_keyword`, `scores_before`, `scores_after`, `html_before`, `html_after` | -| `SiteBlueprint` | - | `business/site_building/models.py` | NEW: `tenant`, `site`, `config_json`, `structure_json`, `status`, `hosting_type` | -| `PageBlueprint` | - | `business/site_building/models.py` | NEW: `site_blueprint`, `slug`, `type`, `blocks_json`, `status` | -| `SiteIntegration` | - | `business/integration/models.py` | NEW: `site`, `platform`, `platform_type`, `config_json`, `credentials`, `is_active`, `sync_enabled` | -| `PublishingRecord` | - | `business/publishing/models.py` | NEW: `content_id`, `destination`, `destination_type`, `status`, `external_id`, `published_at`, `sync_status` | -| `DeploymentRecord` | - | `business/publishing/models.py` | NEW: `site_blueprint`, `version`, `status`, `build_url`, `deployed_at`, `deployment_type` | -| `AutomationRule` | - | `business/automation/models.py` | NEW: `name`, `trigger`, `conditions`, `actions`, `schedule`, `is_active` | -| `ScheduledTask` | - | `business/automation/models.py` | NEW: `automation_rule`, `scheduled_at`, `status`, `executed_at` | - ---- - -## 4. FRONTEND STRUCTURE - -### 4.1 Main App Structure (igny8_frontend) - -``` -frontend/src/ -├── pages/ -│ ├── Planner/ # Existing -│ ├── Writer/ # Existing -│ ├── Thinker/ # Existing -│ ├── Billing/ # Existing -│ ├── Settings/ # Existing -│ ├── Automation/ # EXISTING (placeholder) - IMPLEMENT -│ │ ├── Dashboard.tsx # Automation overview (includes schedules functionality) -│ │ ├── Rules.tsx # Automation rules management -│ │ ├── Workflows.tsx # Workflow templates -│ │ └── History.tsx # Automation execution history -│ ├── Linker/ # NEW -│ │ ├── Dashboard.tsx -│ │ ├── Candidates.tsx -│ │ └── Graph.tsx -│ ├── Optimizer/ # NEW -│ │ ├── Dashboard.tsx -│ │ ├── Analyze.tsx -│ │ └── Compare.tsx -│ └── SiteBuilder/ # NEW (if integrated, else separate container) -│ -├── modules/ # NEW: Feature modules -│ ├── automation/ -│ │ ├── components/ -│ │ ├── hooks/ -│ │ └── stores/ -│ ├── linker/ -│ ├── optimizer/ -│ └── publisher/ -│ -└── services/ - ├── automation.api.ts # NEW - ├── linker.api.ts # NEW - ├── optimizer.api.ts # NEW - └── publisher.api.ts # NEW -``` - -### 4.2 Site Builder Structure (NEW Container) - -``` -site-builder/src/ -├── pages/ -│ ├── wizard/ # Wizard steps -│ │ ├── Step1TypeSelection.tsx -│ │ ├── Step2BusinessBrief.tsx -│ │ ├── Step3Objectives.tsx -│ │ └── Step4Style.tsx -│ ├── preview/ # Preview renderer -│ │ └── PreviewCanvas.tsx -│ └── dashboard/ # Site management -│ └── SiteList.tsx -│ -├── components/ -│ ├── blocks/ # Block components -│ ├── forms/ # Form components -│ └── preview-canvas/ # Preview renderer -│ -├── state/ -│ ├── builderStore.ts # Zustand store -│ └── siteDefinitionStore.ts -│ -└── api/ - ├── builder.api.ts - └── sites.api.ts -``` - -### 4.3 Sites Renderer Structure (NEW Container) - -``` -sites/src/ -├── renderer/ -│ ├── index.html -│ ├── main.tsx -│ ├── router.tsx -│ └── components/ -│ ├── Layout/ -│ ├── Blocks/ # Block components (shared schema) -│ └── UI/ -│ -├── loaders/ -│ └── loadSiteDefinition.ts -│ -└── config/ - ├── themes/ - └── block-schema/ # Shared with WP theme -``` - ---- - -## 5. AUTOMATION SYSTEM - -### 5.1 Automation Architecture - -| Component | Purpose | Implementation | -|-----------|---------|----------------| -| **AutomationRule Model** | Store automation rules | `business/automation/models.py` | -| **AutomationService** | Execute automation rules | `business/automation/services/automation_service.py` | -| **Celery Beat Tasks** | Scheduled automation | `infrastructure/messaging/automation_tasks.py` | -| **Automation API** | CRUD for rules | `modules/automation/views.py` | -| **Automation UI** | Manage rules | `frontend/src/pages/Automation/` | - -### 5.2 Automation Rule Structure - -```python -class AutomationRule(SiteSectorBaseModel): - name = models.CharField(max_length=255) - trigger = models.CharField(choices=[ - ('schedule', 'Scheduled'), - ('keyword_added', 'Keyword Added'), - ('cluster_created', 'Cluster Created'), - ('idea_created', 'Idea Created'), - ('content_generated', 'Content Generated'), - ]) - conditions = models.JSONField() # {field: value, operator: 'eq', 'gt', etc.} - actions = models.JSONField() # [{type: 'generate_ideas', params: {...}}] - schedule = models.JSONField() # {cron: '0 9 * * *', timezone: 'UTC'} - is_active = models.BooleanField(default=True) - max_executions_per_day = models.IntegerField(default=10) - credit_limit_per_execution = models.IntegerField(default=100) -``` - -### 5.3 Automation Workflows - -| Workflow | Trigger | Actions | Schedule | -|----------|---------|---------|----------| -| **Auto Cluster Keywords** | New keywords added | Run clustering AI | Daily at 2 AM | -| **Auto Generate Ideas** | Cluster created | Generate ideas for cluster | Immediate or scheduled | -| **Auto Create Tasks** | Ideas created | Create tasks from ideas | Daily at 9 AM | -| **Auto Generate Content** | Tasks queued | Generate content for tasks | Hourly (respects daily limit) | -| **Auto Generate Images** | Content generated | Generate images for content | Immediate | -| **Auto Link Content** | Content generated | Run linker on content | After content generation | -| **Auto Optimize Content** | Content linked | Run optimizer on content | After linking | -| **Auto Publish** | Content optimized | Publish to WordPress/Sites | Daily at 10 AM | - -### 5.4 Automation Implementation - -| Task | File | Implementation | -|------|------|----------------| -| **AutomationRule Model** | `business/automation/models.py` | Create model with trigger, conditions, actions, schedule | -| **AutomationService** | `business/automation/services/automation_service.py` | `execute_rule()`, `check_conditions()`, `execute_actions()` | -| **Celery Beat Tasks** | `infrastructure/messaging/automation_tasks.py` | `@periodic_task` decorators for scheduled rules | -| **Automation API** | `modules/automation/views.py` | CRUD ViewSet for AutomationRule | -| **Automation UI** | `frontend/src/pages/Automation/` | Dashboard, Rules management, History | - ---- - -## 6. MULTI-SITE MANAGEMENT - -### 6.1 Site Isolation Strategy - -| Aspect | Implementation | Purpose | -|--------|----------------|---------| -| **Database Filtering** | All models inherit AccountBaseModel/SiteSectorBaseModel | Automatic site isolation | -| **API Filtering** | ViewSets use base classes | Automatic filtering by site_id | -| **Storage Isolation** | `/data/app/storage/{site_id}/` | Separate storage per site | -| **Site-Specific Limits** | Plan limits enforced per site | Prevent one site from overwhelming system | -| **Queue Isolation** | Celery queues per site (optional) | Prevent site blocking | -| **Rate Limiting** | Per-site rate limits | Prevent abuse | - -### 6.2 Site Resource Management - -| Resource | Limit Type | Enforcement | Location | -|-----------|------------|-------------|----------| -| **Daily Content Tasks** | Per site | `Plan.daily_content_tasks` | `business/content/services/content_generation_service.py` | -| **Daily AI Requests** | Per site | `Plan.daily_ai_requests` | `infrastructure/ai/engine.py` | -| **Monthly Word Count** | Per site | `Plan.monthly_word_count_limit` | `business/content/services/content_generation_service.py` | -| **Daily Image Generation** | Per site | `Plan.daily_image_generation_limit` | `infrastructure/ai/functions/generate_images.py` | -| **Storage Quota** | Per site | Configurable (default: 10GB) | `infrastructure/storage/file_storage.py` | -| **Concurrent Tasks** | Per site | Configurable (default: 5) | Celery queue configuration | - -### 6.3 Site Performance Optimization - -| Optimization | Implementation | Benefit | -|---------------|----------------|---------| -| **Database Indexing** | Indexes on `site_id`, `sector_id`, `account_id` | Faster queries | -| **Query Optimization** | `select_related()`, `prefetch_related()` | Reduce DB queries | -| **Caching** | Redis cache per site | Faster responses | -| **Background Processing** | Celery for heavy operations | Non-blocking | -| **Resource Throttling** | Per-site rate limits | Prevent overload | - ---- - -## 7. VOLUME & STORAGE STRATEGY - -### 7.1 Volume Structure - -``` -/data/app/ -├── igny8/ # Code (bind mount, git repo) -│ ├── backend/ -│ ├── frontend/ -│ ├── site-builder/ # NEW -│ └── sites/ # NEW -│ -├── storage/ # Named volume (data) -│ ├── {site_id}/ -│ │ ├── images/ -│ │ ├── content/ -│ │ └── exports/ -│ └── shared/ -│ └── templates/ -│ -├── sites-data/ # Named volume (NEW - rendered sites) -│ ├── marketing/ -│ └── clients/ -│ ├── {site_id}/ -│ │ └── v{version}/ -│ │ ├── site.json -│ │ ├── pages/ -│ │ └── assets/ -│ -├── logs/ # Named volume -│ ├── backend/ -│ ├── celery/ -│ └── nginx/ -│ -└── cache/ # Named volume (optional) - └── redis/ -``` - -### 7.2 Volume Mounting Strategy - -| Volume | Type | Purpose | Backup | -|--------|------|---------|--------| -| **Code directories** | Bind mount (dev) / Image (prod) | Source code | Git repo | -| **storage/** | Named volume | Generated files, images | Daily backup | -| **sites-data/** | Named volume | Rendered site files | Daily backup | -| **logs/** | Named volume | Application logs | Weekly rotation | -| **cache/** | Named volume | Redis cache | No backup | - -### 7.3 Storage Service Implementation - -```python -# infrastructure/storage/file_storage.py -class FileStorageService: - def get_site_storage_path(self, site_id: int) -> str: - return f"/data/app/storage/{site_id}/" - - def get_site_quota(self, site_id: int) -> int: - # Get from Plan or Site model - return site.plan.storage_quota_gb * 1024 * 1024 * 1024 - - def check_quota(self, site_id: int, file_size: int) -> bool: - current_size = self.get_site_storage_size(site_id) - quota = self.get_site_quota(site_id) - return (current_size + file_size) <= quota -``` - -### 7.4 Sites Folder Access for Site Builder - -**User-Level File Management**: -- Each user has access to their account's sites folder: `/data/app/sites-data/clients/{site_id}/` -- Site Builder users can manage files for sites they have access to (via `SiteUserAccess`) -- File operations (upload, delete, organize) scoped to user's accessible sites -- Storage quota enforced per site (from Plan) -- File permissions: Owner/Admin (full access), Editor (upload/edit), Viewer (read-only) - -**Site Builder File Management**: -```python -# business/site_building/services/file_management_service.py -class SiteBuilderFileService: - def get_user_accessible_sites(self, user) -> List[Site]: - """Get sites user can access for file management""" - return user.get_accessible_sites() - - def get_site_files_path(self, site_id: int) -> str: - """Get site's files directory""" - return f"/data/app/sites-data/clients/{site_id}/v{version}/assets/" - - def check_file_access(self, user, site_id: int) -> bool: - """Check if user can access site's files""" - accessible_sites = self.get_user_accessible_sites(user) - return any(site.id == site_id for site in accessible_sites) - - def upload_file(self, user, site_id: int, file) -> str: - """Upload file to site's assets folder""" - if not self.check_file_access(user, site_id): - raise PermissionDenied("No access to this site") - # Upload logic -``` - ---- - -## 8. REPOSITORY STRUCTURE - -### 8.1 Main Repository Structure - -``` -igny8/ # Main Git repository -├── backend/ # Django backend -├── frontend/ # React frontend (main app + marketing) -├── site-builder/ # Site Builder (NEW - separate or subfolder) -├── sites/ # Sites renderer (NEW - separate or subfolder) -├── docs/ # Documentation -├── docker-compose.app.yml # App stack -├── .gitignore # Excludes: node_modules, __pycache__, .env, logs, storage, sites-data -└── README.md -``` - -### 8.2 Branching Strategy - -| Branch | Purpose | Merge To | Protection | -|--------|---------|----------|------------| -| `main` | Production-ready code | - | Protected, requires PR | -| `develop` | Integration branch | `main` | Protected, requires PR | -| `feature/*` | Feature branches | `develop` | Not protected | -| `phase-2/*` | Phase 2 features | `develop` | Not protected | -| `hotfix/*` | Critical fixes | `main`, `develop` | Not protected | -| `release/*` | Release candidates | `main` | Protected | - -### 8.3 Repository Exclusions (.gitignore) - -``` -# Code dependencies -node_modules/ -**/node_modules/ -__pycache__/ -**/__pycache__/ -*.pyc -*.pyo - -# Build outputs -dist/ -build/ -.vite/ -*.tsbuildinfo - -# Environment -.env -.env.local -.env.*.local - -# Data (NEVER commit) -/data/app/storage/ -/data/app/sites-data/ -/data/app/logs/ -/data/app/cache/ - -# Generated files -*.log -*.tmp -*.temp - -# IDE -.vscode/ -.idea/ -*.swp -*.swo - -# Docker (if any) -docker-data/ -.docker/ -``` - -### 8.4 Separate Repositories (Optional) - -| Repository | Contents | Purpose | -|------------|----------|---------| -| `igny8-core` | Backend + Main frontend | Core platform | -| `igny8-site-builder` | Site Builder code | Separate deployment | -| `igny8-sites` | Sites renderer | Separate deployment | -| `igny8-wp-plugin` | WordPress plugin | External (separate) | -| `igny8-wp-theme` | WordPress theme | External (separate) | - -**Recommendation:** Keep all in one repo (`igny8`) with clear folder structure. Separate repos only if deployment cycles differ significantly. - ---- - -## 9. IMPLEMENTATION PHASES - -### 9.1 Phase 0: Foundation (Current + Immediate) - -| Task | Files | Status | Priority | -|------|-------|--------|-----------| -| **Extend Content Model** | `business/content/models.py` | TODO | HIGH | -| **Create Service Layer** | `business/*/services/` | TODO | HIGH | -| **Refactor ViewSets** | `modules/*/views.py` | TODO | HIGH | -| **Implement Automation Models** | `business/automation/models.py` | TODO | HIGH | -| **Implement Automation Service** | `business/automation/services/` | TODO | HIGH | -| **Implement Automation API** | `modules/automation/` | TODO | HIGH | -| **Implement Automation UI** | `frontend/src/pages/Automation/` | TODO | HIGH | -| **Note**: Schedules functionality will be integrated into Automation UI, not as a separate page | - | - | - | - -### 9.2 Phase 1: Site Builder - -| Task | Files | Dependencies | Priority | -|------|-------|--------------|----------| -| **Create Site Builder Container** | `docker-compose.app.yml` | Phase 0 | HIGH | -| **Site Builder Models** | `business/site_building/models.py` | Phase 0 | HIGH | -| **Structure Generation Service** | `business/site_building/services/` | Phase 0 | HIGH | -| **Structure Generation AI Function** | `infrastructure/ai/functions/generate_site_structure.py` | Phase 0 | HIGH | -| **Site Builder API** | `modules/site_builder/` | Phase 0 | HIGH | -| **Site Builder Frontend** | `site-builder/src/` | Phase 0 | HIGH | - -### 9.3 Phase 2: Linker & Optimizer - -| Task | Files | Dependencies | Priority | -|------|-------|--------------|----------| -| **Linker Models** | `business/linking/models.py` | Phase 0 | MEDIUM | -| **Linker Service** | `business/linking/services/` | Phase 0 | MEDIUM | -| **Linker API** | `modules/linker/` | Phase 0 | MEDIUM | -| **Linker UI** | `frontend/src/pages/Linker/` | Phase 0 | MEDIUM | -| **Optimizer Models** | `business/optimization/models.py` | Phase 0 | MEDIUM | -| **Optimizer Service** | `business/optimization/services/` | Phase 0 | MEDIUM | -| **Optimizer AI Function** | `infrastructure/ai/functions/optimize_content.py` | Phase 0 | MEDIUM | -| **Optimizer API** | `modules/optimizer/` | Phase 0 | MEDIUM | -| **Optimizer UI** | `frontend/src/pages/Optimizer/` | Phase 0 | MEDIUM | - -### 9.4 Phase 3: Sites Renderer - -| Task | Files | Dependencies | Priority | -|------|-------|--------------|----------| -| **Create Sites Container** | `docker-compose.app.yml` | Phase 1 | MEDIUM | -| **Sites Renderer Frontend** | `sites/src/` | Phase 1 | MEDIUM | -| **Publisher Service** | `business/publishing/services/` | Phase 0 | MEDIUM | -| **Sites Renderer Adapter** | `business/publishing/services/adapters/` | Phase 1 | MEDIUM | -| **Publisher API** | `modules/publisher/` | Phase 0 | MEDIUM | -| **Deployment Service** | `business/publishing/services/deployment_service.py` | Phase 1 | MEDIUM | - -### 9.5 Phase 4: Universal Content Types - -| Task | Files | Dependencies | Priority | -|------|-------|--------------|----------| -| **Extend Content Model** | `business/content/models.py` | Phase 0 | LOW | -| **Product Content Prompts** | `infrastructure/ai/prompts.py` | Phase 0 | LOW | -| **Service Page Prompts** | `infrastructure/ai/prompts.py` | Phase 0 | LOW | -| **Taxonomy Prompts** | `infrastructure/ai/prompts.py` | Phase 0 | LOW | -| **Content Type Support in Writer** | `business/content/services/` | Phase 0 | LOW | -| **Content Type Support in Linker** | `business/linking/services/` | Phase 2 | LOW | -| **Content Type Support in Optimizer** | `business/optimization/services/` | Phase 2 | LOW | - ---- - -## 10. CREDIT-BASED USAGE SYSTEM - -### 10.1 Core Principle - -**Credit-Only Model**: All features are unlimited. Only credits restrict usage. - -- ✅ All features unlocked for paid users -- ✅ No plan-based limits (keywords, clusters, tasks, etc.) -- ✅ Only credits control usage -- ✅ Operational limits only (50 keywords/request, 6 images/request) - -### 10.2 Plan Model (Simplified) - -| Field | Type | Purpose | -|-------|------|---------| -| `monthly_credits` | Integer | Credits added per month | -| `support_level` | CharField | Support tier (basic, priority, enterprise) | -| `billing_cycle` | CharField | 'monthly' or 'annual' | -| `price` | Decimal | Subscription price | -| `features` | JSONField | Feature flags (for future use) | - -**REMOVED FIELDS** (no longer needed): -- `max_keywords`, `max_clusters`, `max_content_ideas` -- `daily_content_tasks`, `monthly_word_count_limit` -- `daily_image_generation_limit`, `monthly_image_count` -- All other usage limits - -### 10.3 Credit Cost Structure - -| Operation | Credit Cost | Type | Notes | -|-----------|-------------|------|-------| -| **Clustering** | 10 credits | Fixed | Per clustering request | -| **Idea Generation** | 15 credits | Fixed | Per cluster → ideas request | -| **Content Generation** | 1 credit per 100 words | Variable | Based on word count | -| **Image Generation** | 5 credits | Fixed | Per image (user sees batch) | -| **Image Prompt Extraction** | 2 credits | Fixed | Per content piece | -| **Linking** | 8 credits | Fixed | Per content piece (NEW) | -| **Optimization** | 1 credit per 200 words | Variable | Per content piece (NEW) | -| **Site Structure Generation** | 50 credits | Fixed | Per site blueprint (NEW) | -| **Site Page Generation** | 20 credits | Fixed | Per page (NEW) | - -### 10.4 Credit Enforcement - -| Location | Check | Implementation | -|----------|-------|----------------| -| **AI Engine** | Before AI call | `infrastructure/ai/engine.py` - Check credits, deduct before request | -| **Content Generation** | Before generation | `business/content/services/content_generation_service.py` | -| **Image Generation** | Before generation | `infrastructure/ai/functions/generate_images.py` | -| **Linking** | Before linking | `business/linking/services/linker_service.py` (NEW) | -| **Optimization** | Before optimization | `business/optimization/services/optimizer_service.py` (NEW) | -| **Site Building** | Before structure gen | `business/site_building/services/structure_generation_service.py` (NEW) | - -### 10.5 Credit Logging - -| Log Type | Fields | Purpose | -|----------|--------|---------| -| **CreditUsageLog** | `account`, `operation_type`, `credits_used`, `related_object_type`, `related_object_id`, `metadata` | Track all credit consumption | -| **CreditTransaction** | `account`, `transaction_type`, `amount`, `description` | Track credit additions/deductions | - -**Usage Tracking**: -- Total credits used (account level) -- Credits per operation type (clustering, content, images, etc.) -- Credits per site (site level breakdown) -- Credits per user (user level breakdown) -- Historical usage trends - -### 10.6 Operational Limits (Technical Constraints) - -| Limit | Value | Type | Reason | -|-------|-------|-------|--------| -| **Keywords per request** | 50 | Technical | API payload size, processing time | -| **Images per request** | 6 | Technical | Queue management (user sees as batch) | -| **Images per AI call** | 1 | Technical | Image API limitation (internal) | - -These are **NOT** business limits - they're technical constraints for request processing. - -### 10.7 Credit System Features - -| Feature | Implementation | Location | -|---------|----------------|----------| -| **Credit Check** | Before every AI operation | `business/billing/services/credit_service.py` | -| **Credit Deduction** | After successful operation | `business/billing/services/credit_service.py` | -| **Credit Top-up** | On-demand purchase | `modules/billing/views.py` | -| **Monthly Replenishment** | Celery Beat task | `infrastructure/messaging/automation_tasks.py` | -| **Low Credit Warning** | When < 10% remaining | Frontend + Email notification | -| **Usage Dashboard** | Show credits by operation type | `frontend/src/pages/Billing/Usage.tsx` | - -### 10.8 Admin Boundaries - -| Boundary | Implementation | Location | -|----------|----------------|----------| -| **System Account** | `Account.is_system_account()` | `core/auth/models.py` | -| **Superuser Access** | `User.is_superuser` | `core/auth/models.py` | -| **Plan Management** | Admin-only ViewSet | `modules/system/views.py` | -| **User Management** | Role-based permissions | `core/api/permissions.py` | -| **Credit Management** | Admin-only actions | `modules/billing/views.py` | -| **Automation Management** | Role-based (Owner/Admin) | `modules/automation/views.py` | - -### 10.9 Multi-Tenancy Boundaries - -| Boundary | Implementation | Location | -|----------|----------------|----------| -| **Account Isolation** | `AccountBaseModel` | `core/base/models.py` | -| **Site Isolation** | `SiteSectorBaseModel` | `core/base/models.py` | -| **Sector Isolation** | `SiteSectorBaseModel` | `core/base/models.py` | -| **API Filtering** | Base ViewSets | `core/api/base.py` | -| **Storage Isolation** | Site-specific paths | `infrastructure/storage/file_storage.py` | -| **Queue Isolation** | Site-specific queues (optional) | Celery config | - ---- - -## 11. SITE INTEGRATION & MULTI-DESTINATION PUBLISHING - -### 11.1 Site Integration Model - -| Field | Type | Purpose | -|-------|------|---------| -| `site` | ForeignKey(Site) | Links to Site model | -| `platform` | CharField | Platform name ('wordpress', 'shopify', 'custom') | -| `platform_type` | CharField | Type: 'cms', 'ecommerce', 'custom_api' | -| `config_json` | JSONField | Platform-specific configuration | -| `credentials` | EncryptedField | Encrypted API keys, tokens, passwords | -| `is_active` | Boolean | Enable/disable integration | -| `sync_enabled` | Boolean | Enable two-way sync | -| `last_sync_at` | DateTime | Last successful sync | -| `sync_status` | CharField | 'success', 'failed', 'pending' | - -**Purpose**: -- Sites can be NEW (built via Site Builder) or EXISTING (already integrated) -- One site can have multiple integrations (WordPress + Shopify) -- Integration credentials stored securely -- Two-way sync support - -### 11.2 Site Types & Hosting - -| Site Type | Description | Integration | Hosting | -|-----------|-------------|-------------|---------| -| **NEW Site (IGNY8 Built)** | Created via Site Builder | None initially | IGNY8 Sites renderer | -| **EXISTING WordPress** | Already has WordPress site | WordPress integration | WordPress hosting | -| **EXISTING Shopify** | Already has Shopify store | Shopify integration | Shopify hosting | -| **EXISTING Custom** | Custom platform/API | Custom integration | External hosting | -| **Hybrid** | Built in IGNY8, also integrated | Multiple integrations | IGNY8 + External | - -### 11.3 Site Builder Structure - -``` -Site Builder Flow: -1. User creates SiteBlueprint (via wizard) -2. SiteBlueprint.hosting_type = 'igny8_sites' | 'wordpress' | 'shopify' | 'multi' -3. If 'wordpress' or 'shopify': - - User must configure SiteIntegration first - - Site Builder generates content compatible with platform -4. If 'igny8_sites': - - Site deployed to Sites renderer -5. If 'multi': - - Site can publish to multiple destinations -``` - -### 11.4 Multi-Destination Publishing - -| Content Type | Can Publish To | Implementation | -|--------------|----------------|----------------| -| **Blog Posts** | WordPress, IGNY8 Sites, Shopify Blog | PublisherService routes to adapters | -| **Pages** | WordPress, IGNY8 Sites, Shopify Pages | PublisherService routes to adapters | -| **Products** | Shopify, WooCommerce (WordPress), IGNY8 Sites | Product adapter per platform | -| **Categories** | WordPress, Shopify Collections, IGNY8 Sites | Taxonomy adapter per platform | -| **Site Blueprint** | IGNY8 Sites, WordPress (via plugin), Shopify (future) | DeploymentService routes to adapters | - -**Publishing Flow:** -```python -# Single content can publish to multiple destinations -publisher_service.publish( - content=content, - destinations=['wordpress', 'igny8_sites', 'shopify'] # Multiple destinations -) -``` - -### 11.5 Integration Adapters - -| Adapter | Platform | Purpose | Implementation | -|---------|----------|---------|-----------------| -| **WordPressAdapter** | WordPress | Publish content, sync status | Uses WordPress REST API | -| **SitesRendererAdapter** | IGNY8 Sites | Deploy site blueprints | Uploads to Sites container | -| **ShopifyAdapter** | Shopify | Publish products, pages, blog | Uses Shopify Admin API | -| **BaseAdapter** | Abstract | Common interface | All adapters inherit | - -### 11.6 Site Integration Service - -```python -# business/integration/services/integration_service.py -class IntegrationService: - def create_integration(self, site, platform, config, credentials): - """Create new site integration""" - - def test_integration(self, integration): - """Test integration connection""" - - def sync_site_data(self, integration, sync_type='full'): - """Sync site data from external platform""" - # Full: All posts/products - # Incremental: Only changes since last sync - - def get_available_platforms(self): - """Get list of supported platforms""" - return ['wordpress', 'shopify', 'custom_api'] -``` - -### 11.7 Site Model Extensions - -| Field | Type | Purpose | -|-------|------|---------| -| `site_type` | CharField | 'new', 'existing', 'hybrid' | -| `hosting_type` | CharField | 'igny8_sites', 'wordpress', 'shopify', 'custom', 'multi' | -| `integrations` | ManyToMany(SiteIntegration) | Multiple integrations per site | - -**Current Site Model** (needs extension): -- Already has: `wp_url`, `wp_username`, `wp_app_password` (WordPress specific) -- **NEW**: Move to `SiteIntegration` model for flexibility -- **NEW**: Add `site_type` and `hosting_type` fields - -### 11.8 Publishing Workflow - -``` -Content/Site Publishing Flow: - -1. User selects content/site to publish -2. System checks Site.integrations (available destinations) -3. User selects destinations (can be multiple) -4. PublisherService routes to appropriate adapters: - - WordPressAdapter.publish() - - SitesRendererAdapter.deploy() - - ShopifyAdapter.publish() -5. PublishingRecord created for each destination -6. Status tracked per destination -7. Two-way sync enabled if integration.sync_enabled = True -``` - -### 11.9 Implementation Files - -| Component | File | Purpose | -|-----------|------|---------| -| **SiteIntegration Model** | `business/integration/models.py` | Store integration configs | -| **IntegrationService** | `business/integration/services/integration_service.py` | Manage integrations | -| **SyncService** | `business/integration/services/sync_service.py` | Handle two-way sync | -| **WordPressAdapter** | `business/publishing/services/adapters/wordpress_adapter.py` | WordPress publishing | -| **SitesRendererAdapter** | `business/publishing/services/adapters/sites_renderer_adapter.py` | IGNY8 Sites deployment | -| **ShopifyAdapter** | `business/publishing/services/adapters/shopify_adapter.py` | Shopify publishing (future) | -| **Integration API** | `modules/integration/views.py` | CRUD for integrations | -| **Integration UI** | `frontend/src/pages/Settings/Integrations.tsx` | Manage integrations | - -### 11.10 Site Builder Integration Flow - -``` -Site Builder → Publishing Flow: - -1. User builds site via Site Builder wizard -2. SiteBlueprint created with hosting_type -3. If hosting_type = 'wordpress' or 'shopify': - a. User must configure SiteIntegration - b. Site Builder generates platform-compatible structure -4. User clicks "Deploy" -5. DeploymentService: - - If 'igny8_sites': Deploy to Sites renderer - - If 'wordpress': Publish via WordPressAdapter - - If 'shopify': Publish via ShopifyAdapter - - If 'multi': Publish to all configured destinations -6. DeploymentRecord created -7. Site available on selected platforms -``` - -### 11.11 Content Type Support Per Platform - -| Content Type | WordPress | IGNY8 Sites | Shopify | Notes | -|--------------|-----------|-------------|---------|-------| -| **Blog Posts** | ✅ | ✅ | ✅ (Blog) | All platforms support | -| **Pages** | ✅ | ✅ | ✅ (Pages) | All platforms support | -| **Products** | ✅ (WooCommerce) | ✅ | ✅ | Product adapter needed | -| **Product Categories** | ✅ (WooCommerce) | ✅ | ✅ (Collections) | Taxonomy mapping | -| **Product Attributes** | ✅ (WooCommerce) | ✅ | ✅ (Variants) | Attribute mapping | -| **Service Pages** | ✅ | ✅ | ❌ | Custom content type | -| **Taxonomy Terms** | ✅ | ✅ | ❌ | Blog-specific | - ---- - -## SUMMARY - -### Key Architectural Decisions - -1. **Domain-Driven Structure**: Organize by business domains, not technical layers -2. **Service Layer**: All business logic in services, ViewSets are thin -3. **Unified Content Model**: Extend existing `Content` model, don't create duplicates -4. **Automation First**: All functions can be automated via Celery + AutomationRule -5. **Multi-Site Ready**: All features respect site boundaries and limits -6. **Volume Strategy**: Named volumes for data, bind mounts for code (dev) -7. **Single Repository**: Keep all code in one repo with clear structure -8. **Container Separation**: Separate containers for different UIs (Main, Site Builder, Sites) - -### Implementation Order - -1. **Phase 0**: Foundation (Service layer, Automation, Model extensions) -2. **Phase 1**: Site Builder -3. **Phase 2**: Linker & Optimizer -4. **Phase 3**: Sites Renderer -5. **Phase 4**: Universal Content Types - -### Success Criteria - -- ✅ No code duplication -- ✅ All functions automatable -- ✅ Multi-site isolation working -- ✅ Limits enforced per site -- ✅ Volume strategy optimized -- ✅ Repository structure clean -- ✅ All placeholders implemented - ---- - -**END OF DOCUMENT** - diff --git a/part2-dev/IGNY8-IMPLEMENTATION-PLAN.md b/part2-dev/IGNY8-IMPLEMENTATION-PLAN.md deleted file mode 100644 index 408a4a61..00000000 --- a/part2-dev/IGNY8-IMPLEMENTATION-PLAN.md +++ /dev/null @@ -1,1152 +0,0 @@ -# IGNY8 IMPLEMENTATION PLAN -**Preserving Existing Functionality + Phase 2 Features** - -**Last Updated:** 2025-01-XX -**Purpose:** Step-by-step implementation plan that keeps everything working while adding Phase 2 features. - ---- - -## TABLE OF CONTENTS - -1. [Implementation Strategy](#1-implementation-strategy) -2. [Phase 0: Foundation & Credit System](#phase-0-foundation--credit-system) -3. [Phase 1: Service Layer Refactoring](#phase-1-service-layer-refactoring) -4. [Phase 2: Automation System](#phase-2-automation-system) -5. [Phase 3: Site Builder](#phase-3-site-builder) - - [3.0 Sites Folder Access & File Management](#30-sites-folder-access--file-management) -6. [Phase 4: Linker & Optimizer](#phase-4-linker--optimizer) -7. [Phase 5: Sites Renderer](#phase-5-sites-renderer) -8. [Phase 6: Site Integration & Multi-Destination Publishing](#phase-6-site-integration--multi-destination-publishing) -9. [Phase 7: UI Components & Module Settings](#phase-7-ui-components--module-settings) -10. [Phase 8: Universal Content Types](#phase-8-universal-content-types) -11. [Testing & Validation](#testing--validation) - ---- - -## 1. IMPLEMENTATION STRATEGY - -### 1.1 Core Principles - -| Principle | Implementation | -|-----------|----------------| -| **Backward Compatibility** | All existing APIs, workflows, and features continue working | -| **Incremental Changes** | Add new features without breaking existing ones | -| **Feature Flags** | Use flags to enable/disable new features during rollout | -| **Parallel Development** | New features developed alongside existing code | -| **Gradual Migration** | Move to new architecture gradually, not all at once | - -### 1.2 What's Currently Working (PRESERVE) - -| Module | Features | Status | -|--------|----------|--------| -| **Planner** | Keywords, Clusters, Ideas | ✅ Working | -| **Writer** | Tasks, Content Generation, Images | ✅ Working | -| **Thinker** | Prompts, Author Profiles, Strategies | ✅ Working | -| **Billing** | Credits, Transactions, Usage Logs | ✅ Working | -| **System** | Settings, Integration Settings | ✅ Working | -| **Auth** | Multi-tenancy, Users, Sites, Sectors | ✅ Working | -| **AI Framework** | 5 AI functions (cluster, ideas, content, prompts, images) | ✅ Working | -| **WordPress Publishing** | Content publishing to WordPress | ✅ Working | - -### 1.3 What Needs to Be Built (PHASE 2) - -| Feature | Status | Priority | -|---------|--------|----------| -| **Credit-Only System** | 🔨 Build | HIGH | -| **Automation System** | 🔨 Build | HIGH | -| **Service Layer** | 🔨 Build | HIGH | -| **Site Builder** | 🔨 Build | HIGH | -| **Linker** | 🔨 Build | MEDIUM | -| **Optimizer** | 🔨 Build | MEDIUM | -| **Sites Renderer** | 🔨 Build | MEDIUM | -| **Site Integration** | 🔨 Build | MEDIUM | -| **Universal Content Types** | 🔨 Build | LOW | - ---- - -## PHASE 0: FOUNDATION & CREDIT SYSTEM - -**Goal**: Migrate to credit-only model while preserving all existing functionality. - -### 0.0 Module Settings System (Enable/Disable Modules) - -| Task | Files | Dependencies | Risk | -|------|-------|--------------|------| -| **Add Module Enable/Disable** | `business/system/models.py` | EXISTING (ModuleSettings) | LOW - Extend existing | -| **Module Settings API** | `modules/system/views.py` | EXISTING | LOW - Extend existing | -| **Module Settings UI** | `frontend/src/pages/Settings/Modules.tsx` | EXISTING (placeholder) | LOW - Implement UI | -| **Frontend Module Loader** | `frontend/src/config/modules.config.ts` | None | MEDIUM - Conditional loading | -| **Route Guard** | `frontend/src/components/common/ModuleGuard.tsx` | None | LOW - New component | - -**Module Enable/Disable Logic**: -- Each module has `enabled` flag in ModuleSettings -- Frontend checks module status before loading routes -- Disabled modules don't appear in sidebar -- Disabled modules don't load code (lazy loading check) - -**Modules to Control**: -- Planner -- Writer -- Thinker -- Automation -- Site Builder (NEW) -- Linker (NEW) -- Optimizer (NEW) -- Publisher (NEW) - -### 0.1 Credit System Updates - -| Task | Files | Dependencies | Risk | -|------|-------|--------------|------| -| **Remove Plan Limit Fields** | `core/auth/models.py` | None | LOW - Add migration to set defaults | -| **Update Plan Model** | `core/auth/models.py` | None | LOW - Keep only monthly_credits, support_level | -| **Update CreditService** | `business/billing/services/credit_service.py` | None | MEDIUM - Add credit cost constants | -| **Add Credit Costs** | `business/billing/constants.py` | None | LOW - Define credit costs per operation | -| **Update AI Engine** | `infrastructure/ai/engine.py` | CreditService | MEDIUM - Check credits before AI calls | -| **Update Content Generation** | `business/content/services/` | CreditService | MEDIUM - Check credits before generation | -| **Update Image Generation** | `infrastructure/ai/functions/generate_images.py` | CreditService | MEDIUM - Check credits before generation | -| **Remove Limit Checks** | All services | None | MEDIUM - Remove all plan limit validations | -| **Update Usage Logging** | `business/billing/models.py` | None | LOW - Ensure all operations log credits | -| **Update Frontend Limits UI** | `frontend/src/pages/Billing/` | Backend API | LOW - Replace limits with credit display | - -**Credit Cost Constants**: -```python -# business/billing/constants.py -CREDIT_COSTS = { - 'clustering': 10, - 'idea_generation': 15, - 'content_generation': 1, # per 100 words - 'image_prompt_extraction': 2, - 'image_generation': 5, - 'linking': 8, # NEW - 'optimization': 1, # per 200 words, NEW - 'site_structure_generation': 50, # NEW - 'site_page_generation': 20, # NEW -} -``` - -### 0.2 Operational Limits (Keep) - -| Limit | Location | Implementation | -|-------|----------|----------------| -| **50 keywords per request** | `modules/planner/views.py` | Request validation | -| **6 images per request** | `modules/writer/views.py` | Request validation | - -### 0.3 Database Migrations - -| Migration | Purpose | Risk | -|-----------|---------|------| -| **Remove limit fields from Plan** | Clean up unused fields | LOW - Add defaults first | -| **Add credit cost tracking** | Enhance CreditUsageLog | LOW - Additive only | -| **Monthly credit replenishment** | Celery Beat task | LOW - New feature | - -### 0.4 Testing - -- ✅ All existing features work with credit checks -- ✅ Credit deduction happens correctly -- ✅ Insufficient credits show clear error -- ✅ Usage logging tracks all operations -- ✅ Frontend shows credit balance, not limits - -**Timeline**: 1-2 weeks - ---- - -## PHASE 1: SERVICE LAYER REFACTORING - -**Goal**: Extract business logic from ViewSets into services, preserving all existing functionality. - -### 1.1 Create Business Structure - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Create business/ folder** | `backend/igny8_core/business/` | None | -| **Move Content models** | `business/content/models.py` | Phase 0 | -| **Move Planning models** | `business/planning/models.py` | Phase 0 | -| **Create ContentService** | `business/content/services/content_generation_service.py` | Existing Writer logic | -| **Create PlanningService** | `business/planning/services/clustering_service.py` | Existing Planner logic | -| **Create IdeasService** | `business/planning/services/ideas_service.py` | Existing Planner logic | - -### 1.2 Refactor ViewSets (Keep APIs Working) - -| Module | Current | New | Risk | -|--------|---------|-----|------| -| **Planner ViewSets** | Business logic in views | Delegate to services | LOW - Internal refactor | -| **Writer ViewSets** | Business logic in views | Delegate to services | LOW - Internal refactor | -| **Billing ViewSets** | Already uses CreditService | Keep as-is | NONE | - -**Strategy**: -- ViewSets become thin wrappers -- All business logic moves to services -- APIs remain unchanged (backward compatible) - -### 1.3 Testing - -- ✅ All existing API endpoints work identically -- ✅ Response formats unchanged -- ✅ No breaking changes for frontend -- ✅ Services are testable independently - -**Timeline**: 2-3 weeks - ---- - -## PHASE 2: AUTOMATION SYSTEM - -**Goal**: Implement automation rules and scheduled tasks. - -### 2.1 Automation Models - -| Task | Files | Dependencies | -|------|-------|--------------| -| **AutomationRule Model** | `business/automation/models.py` | Phase 1 | -| **ScheduledTask Model** | `business/automation/models.py` | Phase 1 | -| **Automation Migrations** | `business/automation/migrations/` | Phase 1 | - -### 2.2 Automation Service - -| Task | Files | Dependencies | -|------|-------|--------------| -| **AutomationService** | `business/automation/services/automation_service.py` | Phase 1 services | -| **Rule Execution Engine** | `business/automation/services/rule_engine.py` | Phase 1 services | -| **Condition Evaluator** | `business/automation/services/condition_evaluator.py` | None | -| **Action Executor** | `business/automation/services/action_executor.py` | Phase 1 services | - -### 2.3 Celery Beat Tasks - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Scheduled Automation Task** | `infrastructure/messaging/automation_tasks.py` | AutomationService | -| **Monthly Credit Replenishment** | `infrastructure/messaging/automation_tasks.py` | CreditService | -| **Celery Beat Configuration** | `backend/igny8_core/celery.py` | None | - -### 2.4 Automation API - -| Task | Files | Dependencies | -|------|-------|--------------| -| **AutomationRule ViewSet** | `modules/automation/views.py` | AutomationService | -| **ScheduledTask ViewSet** | `modules/automation/views.py` | AutomationService | -| **Automation URLs** | `modules/automation/urls.py` | None | - -### 2.5 Automation UI - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Automation Dashboard** | `frontend/src/pages/Automation/Dashboard.tsx` | EXISTING (placeholder) | -| **Rules Management** | `frontend/src/pages/Automation/Rules.tsx` | NEW | -| **Schedules (within Automation)** | Integrated into Automation Dashboard | Part of automation menu | -| **Automation API Client** | `frontend/src/services/automation.api.ts` | NEW | - -### 2.6 Testing - -- ✅ Automation rules execute correctly -- ✅ Scheduled tasks run on time -- ✅ Credit replenishment works monthly -- ✅ UI shows automation status - -**Timeline**: 2-3 weeks - ---- - -## PHASE 3: SITE BUILDER - -**Goal**: Build Site Builder for creating sites via wizard. - -### 3.0 Sites Folder Access & File Management - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Site File Management Service** | `business/site_building/services/file_management_service.py` | Phase 1 | -| **User Site Access Check** | `business/site_building/services/file_management_service.py` | EXISTING (SiteUserAccess) | -| **File Upload API** | `modules/site_builder/views.py` | File Management Service | -| **File Browser UI** | `site-builder/src/components/files/FileBrowser.tsx` | NEW | -| **Storage Quota Check** | `infrastructure/storage/file_storage.py` | Phase 1 | - -**Sites Folder Structure**: -``` -/data/app/sites-data/ -└── clients/ - └── {site_id}/ - └── v{version}/ - ├── site.json - ├── pages/ - └── assets/ # User-managed files - ├── images/ - ├── documents/ - └── media/ -``` - -**User Access Rules**: -- Owner/Admin: Full access to all account sites -- Editor: Access to granted sites (via SiteUserAccess) -- Viewer: Read-only access to granted sites -- File operations scoped to user's accessible sites only - -### 3.1 Site Builder Models - -| Task | Files | Dependencies | -|------|-------|--------------| -| **SiteBlueprint Model** | `business/site_building/models.py` | Phase 1 | -| **PageBlueprint Model** | `business/site_building/models.py` | Phase 1 | -| **Site Builder Migrations** | `business/site_building/migrations/` | Phase 1 | - -### 3.2 Site Structure Generation - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Structure Generation AI Function** | `infrastructure/ai/functions/generate_site_structure.py` | Existing AI framework | -| **Structure Generation Service** | `business/site_building/services/structure_generation_service.py` | Phase 1, AI framework | -| **Site Structure Prompts** | `infrastructure/ai/prompts.py` | Existing prompt system | - -### 3.3 Site Builder API - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Site Builder ViewSet** | `modules/site_builder/views.py` | Structure Generation Service | -| **Site Builder URLs** | `modules/site_builder/urls.py` | None | -| **Site Builder Serializers** | `modules/site_builder/serializers.py` | None | - -### 3.4 Site Builder Frontend (New Container) - -**User-Friendly Name**: "Website Builder" or "Site Creator" - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Create Site Builder Container** | `docker-compose.app.yml` | None | -| **Wizard Steps** | `site-builder/src/pages/wizard/` | NEW | -| **Preview Canvas** | `site-builder/src/pages/preview/` | NEW | -| **Site Builder State** | `site-builder/src/state/builderStore.ts` | NEW | -| **Site Builder API Client** | `site-builder/src/api/builder.api.ts` | NEW | -| **Layout Selection** | `site-builder/src/components/layouts/` | NEW | -| **Template Library** | `site-builder/src/components/templates/` | NEW | -| **Block Components** | `site-builder/src/components/blocks/` | NEW (uses shared library) | - -### 3.7 Global Component Library - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Create Shared Component Library** | `frontend/src/components/shared/` | None | -| **Block Components** | `frontend/src/components/shared/blocks/` | NEW | -| **Layout Components** | `frontend/src/components/shared/layouts/` | NEW | -| **Template Components** | `frontend/src/components/shared/templates/` | NEW | -| **Component Documentation** | `frontend/src/components/shared/README.md` | None | - -**Component Library Structure**: -``` -frontend/src/components/shared/ -├── blocks/ -│ ├── Hero.tsx -│ ├── Features.tsx -│ ├── Services.tsx -│ ├── Products.tsx -│ ├── Testimonials.tsx -│ ├── ContactForm.tsx -│ └── ... -├── layouts/ -│ ├── DefaultLayout.tsx -│ ├── MinimalLayout.tsx -│ ├── MagazineLayout.tsx -│ ├── EcommerceLayout.tsx -│ └── ... -└── templates/ - ├── BlogTemplate.tsx - ├── BusinessTemplate.tsx - ├── PortfolioTemplate.tsx - └── ... -``` - -**Usage**: Site Builder, Sites Renderer, and Main App all use same components (no duplicates) - -### 3.5 Page Generation (Reuse Content Service) - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Extend ContentService** | `business/content/services/content_generation_service.py` | Phase 1 | -| **Add Site Page Type** | `business/content/models.py` | Phase 1 | -| **Page Generation Prompts** | `infrastructure/ai/prompts.py` | Existing prompt system | - -### 3.6 Testing - -- ✅ Site Builder wizard works end-to-end -- ✅ Structure generation creates valid blueprints -- ✅ Preview renders correctly -- ✅ Page generation reuses existing content service - -**Timeline**: 3-4 weeks - ---- - -## PHASE 4: LINKER & OPTIMIZER - -**Goal**: Add linking and optimization as post-processing stages with multiple entry points. - -### 4.0 Content Workflow & Entry Points - -**Content Sources**: -1. **IGNY8 Generated** - Content created via Writer module -2. **WordPress Synced** - Content synced from WordPress via plugin -3. **3rd Party Synced** - Content synced from external sources (Shopify, custom APIs) - -**Content Storage Strategy**: -- All content stored in unified `Content` model -- `source` field: `'igny8'`, `'wordpress'`, `'shopify'`, `'custom'` -- `sync_status` field: `'native'`, `'imported'`, `'synced'` -- Same location, filtered by source/sync_status - -**Workflow Entry Points**: - -``` -Entry Point 1: Writer → Linker → Optimizer → Publish -Entry Point 2: WordPress Sync → Optimizer → Publish -Entry Point 3: 3rd Party Sync → Optimizer → Publish -Entry Point 4: Manual Selection → Linker/Optimizer -``` - -### 4.0.1 Writer → Linker Handover - -| Step | Action | Implementation | -|------|--------|---------------| -| **1. Content Generated** | Writer generates content | `ContentService.generate()` | -| **2. Content Saved** | Content saved to DB | `Content` model with `source='igny8'` | -| **3. Linker Trigger** | Auto-trigger or manual | `LinkerService.process(content_id)` | -| **4. Links Injected** | Links added to content | `Content.internal_links` updated | -| **5. Content Updated** | Content version incremented | `Content.linker_version++` | -| **6. Optimizer Ready** | Content ready for optimization | Status: `'linked'` or `'ready_for_optimization'` | - -**Auto-Trigger Options**: -- Immediate (after content generation) -- Scheduled (via AutomationRule) -- Manual (user clicks "Add Links") - -### 4.0.2 Optimizer Entry Points - -| Entry Point | Source | Trigger | Content Status | -|-------------|--------|---------|----------------| -| **Writer → Optimizer** | IGNY8 generated | After linking or direct | `source='igny8'`, `status='draft'` | -| **WordPress Sync → Optimizer** | WordPress plugin | After sync or manual | `source='wordpress'`, `sync_status='synced'` | -| **3rd Party Sync → Optimizer** | External API | After sync or manual | `source='shopify'/'custom'`, `sync_status='imported'` | -| **Manual Selection** | Any content | User selects content | Any source, any status | - -**Optimizer Processing**: -- All entry points use same `OptimizerService` -- Content source doesn't matter - optimizer works on any content -- Results stored in `OptimizationTask` model -- Original content preserved, optimized version stored separately - -### 4.1 Content Model Extensions (For Synced Content) - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Add source field** | `business/content/models.py` | Phase 1 | -| **Add sync_status field** | `business/content/models.py` | Phase 1 | -| **Add external_id field** | `business/content/models.py` | Phase 1 | -| **Add sync_metadata field** | `business/content/models.py` | Phase 1 | -| **Content Migrations** | `business/content/migrations/` | Phase 1 | - -**Content Model Extensions**: -```python -class Content(SiteSectorBaseModel): - # Existing fields... - - # NEW: Source tracking - source = models.CharField( - max_length=50, - choices=[ - ('igny8', 'IGNY8 Generated'), - ('wordpress', 'WordPress Synced'), - ('shopify', 'Shopify Synced'), - ('custom', 'Custom API Synced'), - ], - default='igny8' - ) - - # NEW: Sync status - sync_status = models.CharField( - max_length=50, - choices=[ - ('native', 'Native IGNY8 Content'), - ('imported', 'Imported from External'), - ('synced', 'Synced from External'), - ], - default='native' - ) - - # NEW: External reference - external_id = models.CharField(max_length=255, blank=True, null=True) - external_url = models.URLField(blank=True, null=True) - sync_metadata = models.JSONField(default=dict) # Platform-specific metadata -``` - -### 4.2 Linker Models - -| Task | Files | Dependencies | -|------|-------|--------------| -| **InternalLink Model** | `business/linking/models.py` | Phase 1 | -| **LinkGraph Model** | `business/linking/models.py` | Phase 1 | -| **Linker Migrations** | `business/linking/migrations/` | Phase 1 | - -### 4.3 Linker Service - -| Task | Files | Dependencies | -|------|-------|--------------| -| **LinkerService** | `business/linking/services/linker_service.py` | Phase 1, ContentService | -| **Link Candidate Engine** | `business/linking/services/candidate_engine.py` | Phase 1 | -| **Link Injection Engine** | `business/linking/services/injection_engine.py` | Phase 1 | - -### 4.4 Content Sync Service (For WordPress/3rd Party) - -| Task | Files | Dependencies | -|------|-------|--------------| -| **ContentSyncService** | `business/integration/services/content_sync_service.py` | Phase 1, Phase 6 | -| **WordPress Content Sync** | `business/integration/services/wordpress_sync.py` | Phase 6 | -| **3rd Party Content Sync** | `business/integration/services/external_sync.py` | Phase 6 | -| **Content Import Logic** | `business/integration/services/import_service.py` | Phase 1 | - -**Sync Service Flow**: -```python -class ContentSyncService: - def sync_from_wordpress(self, site, sync_type='full'): - """Sync content from WordPress""" - # Fetch posts from WordPress - # Create Content records with source='wordpress', sync_status='synced' - # Store external_id, external_url - # Content ready for Optimizer - - def sync_from_shopify(self, site, sync_type='full'): - """Sync content from Shopify""" - # Fetch products/pages from Shopify - # Create Content records with source='shopify', sync_status='synced' - # Store external_id, external_url - # Content ready for Optimizer - - def import_content(self, content_data, source, external_id): - """Import content from any source""" - # Create Content record - # Mark with source and sync_status='imported' - # Content ready for Optimizer -``` - -### 4.5 Optimizer Models - -| Task | Files | Dependencies | -|------|-------|--------------| -| **OptimizationTask Model** | `business/optimization/models.py` | Phase 1 | -| **OptimizationScores Model** | `business/optimization/models.py` | Phase 1 | -| **Optimizer Migrations** | `business/optimization/migrations/` | Phase 1 | - -### 4.6 Optimizer Service (Multiple Entry Points) - -| Task | Files | Dependencies | -|------|-------|--------------| -| **OptimizerService** | `business/optimization/services/optimizer_service.py` | Phase 1, ContentService | -| **Content Analyzer** | `business/optimization/services/analyzer.py` | Phase 1 | -| **Entry Point Handler** | `business/optimization/services/entry_handler.py` | Phase 1 | -| **Optimization AI Function** | `infrastructure/ai/functions/optimize_content.py` | Existing AI framework | -| **Optimization Prompts** | `infrastructure/ai/prompts.py` | Existing prompt system | - -**Optimizer Entry Point Handler**: -```python -class OptimizerService: - def optimize_from_writer(self, content_id): - """Entry Point 1: Writer → Optimizer""" - content = Content.objects.get(id=content_id, source='igny8') - return self.optimize(content) - - def optimize_from_wordpress_sync(self, content_id): - """Entry Point 2: WordPress Sync → Optimizer""" - content = Content.objects.get(id=content_id, source='wordpress') - return self.optimize(content) - - def optimize_from_external_sync(self, content_id): - """Entry Point 3: External Sync → Optimizer""" - content = Content.objects.get(id=content_id, source__in=['shopify', 'custom']) - return self.optimize(content) - - def optimize_manual(self, content_id): - """Entry Point 4: Manual Selection → Optimizer""" - content = Content.objects.get(id=content_id) - return self.optimize(content) # Works for any source - - def optimize(self, content): - """Unified optimization logic""" - # Works the same regardless of source - # Analyzes content - # Generates optimized version - # Stores in OptimizationTask - # Updates content.optimizer_version -``` - -| Task | Files | Dependencies | -|------|-------|--------------| -| **OptimizerService** | `business/optimization/services/optimizer_service.py` | Phase 1, ContentService | -| **Content Analyzer** | `business/optimization/services/analyzer.py` | Phase 1 | -| **Optimization AI Function** | `infrastructure/ai/functions/optimize_content.py` | Existing AI framework | -| **Optimization Prompts** | `infrastructure/ai/prompts.py` | Existing prompt system | - -### 4.7 Content Pipeline Service - -| Task | Files | Dependencies | -|------|-------|--------------| -| **ContentPipelineService** | `business/content/services/content_pipeline_service.py` | LinkerService, OptimizerService | -| **Pipeline Orchestration** | `business/content/services/pipeline_service.py` | Phase 1 services | -| **Workflow State Machine** | `business/content/services/workflow_state.py` | Phase 1 services | - -**Pipeline Workflow States**: -``` -Content States: -- 'draft' → Generated, not processed -- 'linked' → Links added, ready for optimization -- 'optimized' → Optimized, ready for review -- 'review' → Ready for publishing -- 'published' → Published to destination(s) -``` - -**Pipeline Orchestration**: -```python -class ContentPipelineService: - def process_writer_content(self, content_id, stages=['linking', 'optimization']): - """Writer → Linker → Optimizer pipeline""" - content = Content.objects.get(id=content_id, source='igny8') - - if 'linking' in stages: - content = self.link_content(content) - - if 'optimization' in stages: - content = self.optimize_content(content) - - return content - - def process_synced_content(self, content_id, stages=['optimization']): - """Synced Content → Optimizer (skip linking if needed)""" - content = Content.objects.get(id=content_id) - - if 'optimization' in stages: - content = self.optimize_content(content) - - return content -``` - -### 4.8 Linker & Optimizer APIs - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Linker ViewSet** | `modules/linker/views.py` | LinkerService | -| **Optimizer ViewSet** | `modules/optimizer/views.py` | OptimizerService | -| **Linker URLs** | `modules/linker/urls.py` | None | -| **Optimizer URLs** | `modules/optimizer/urls.py` | None | - -### 4.9 Linker & Optimizer UI - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Linker Dashboard** | `frontend/src/pages/Linker/Dashboard.tsx` | NEW | -| **Optimizer Dashboard** | `frontend/src/pages/Optimizer/Dashboard.tsx` | NEW | -| **Linker API Client** | `frontend/src/services/linker.api.ts` | NEW | -| **Optimizer API Client** | `frontend/src/services/optimizer.api.ts` | NEW | -| **Content Selection UI** | `frontend/src/components/optimizer/ContentSelector.tsx` | NEW | -| **Entry Point Handler UI** | `frontend/src/components/optimizer/EntryPointHandler.tsx` | NEW | -| **Source Badge Component** | `frontend/src/components/content/SourceBadge.tsx` | NEW | - -**Optimizer UI Features**: -- Show content source (IGNY8, WordPress, Shopify badge) -- Show sync status (Native, Synced, Imported badge) -- Entry point selection (from Writer, from Sync, Manual) -- Content list with source filters -- "Send to Optimizer" button (works for any source) - -### 4.10 Content Filtering & Display - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Content Filter Component** | `frontend/src/components/content/ContentFilter.tsx` | NEW | -| **Source Filter** | `frontend/src/components/content/SourceFilter.tsx` | NEW | -| **Sync Status Filter** | `frontend/src/components/content/SyncStatusFilter.tsx` | NEW | -| **Content List with Filters** | `frontend/src/pages/Writer/Content.tsx` | EXISTING (update) | - -**Content Filtering**: -- Filter by source: IGNY8, WordPress, Shopify, Custom -- Filter by sync_status: Native, Imported, Synced -- Filter by optimization status: Not optimized, Optimized, Needs optimization -- Filter by linking status: Not linked, Linked, Needs linking - -### 4.11 Testing - -- ✅ Writer → Linker handover works -- ✅ Linker finds appropriate link candidates -- ✅ Links inject correctly into content -- ✅ Optimizer works from Writer entry point -- ✅ Optimizer works from WordPress sync entry point -- ✅ Optimizer works from 3rd party sync entry point -- ✅ Optimizer works from manual selection -- ✅ Synced content stored correctly with source flags -- ✅ Content filtering works (by source, sync_status) -- ✅ Pipeline orchestrates correctly -- ✅ All entry points use same optimization logic - -**Timeline**: 4-5 weeks (extended for multiple entry points) - ---- - -## PHASE 5: SITES RENDERER - -**Goal**: Build Sites renderer for hosting public sites. - -### 5.1 Sites Renderer Container - -**User-Friendly Name**: "My Websites" or "Published Sites" - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Create Sites Container** | `docker-compose.app.yml` | None | -| **Sites Renderer Frontend** | `sites/src/` | NEW | -| **Block Components** | `sites/src/components/blocks/` | NEW (imports from shared) | -| **Layout Components** | `sites/src/components/layouts/` | NEW (imports from shared) | -| **Template Components** | `sites/src/components/templates/` | NEW (imports from shared) | -| **Site Definition Loader** | `sites/src/loaders/loadSiteDefinition.ts` | NEW | -| **Multiple Layout Support** | `sites/src/utils/layoutResolver.ts` | NEW | -| **Template System** | `sites/src/utils/templateEngine.ts` | NEW | -| **CMS Styling** | `sites/src/styles/cms.css` | NEW | - -### 5.6 Multiple Layout Options - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Layout Configuration** | `business/site_building/models.py` | Phase 3 | -| **Layout Selector UI** | `site-builder/src/components/layouts/LayoutSelector.tsx` | Phase 3 | -| **Layout Renderer** | `sites/src/utils/layoutRenderer.ts` | Phase 5 | -| **Layout Preview** | `site-builder/src/components/preview/LayoutPreview.tsx` | Phase 3 | - -**Layout Types**: -- Default (Standard) -- Minimal (Clean, simple) -- Magazine (Editorial, content-focused) -- Ecommerce (Product-focused) -- Portfolio (Showcase) -- Blog (Content-first) -- Corporate (Business) - -### 5.2 Publisher Service - -| Task | Files | Dependencies | -|------|-------|--------------| -| **PublisherService** | `business/publishing/services/publisher_service.py` | Phase 1 | -| **SitesRendererAdapter** | `business/publishing/services/adapters/sites_renderer_adapter.py` | Phase 3 | -| **DeploymentService** | `business/publishing/services/deployment_service.py` | Phase 3 | - -### 5.3 Publishing Models - -| Task | Files | Dependencies | -|------|-------|--------------| -| **PublishingRecord Model** | `business/publishing/models.py` | Phase 1 | -| **DeploymentRecord Model** | `business/publishing/models.py` | Phase 3 | -| **Publishing Migrations** | `business/publishing/migrations/` | Phase 1 | - -### 5.4 Publisher API - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Publisher ViewSet** | `modules/publisher/views.py` | PublisherService | -| **Publisher URLs** | `modules/publisher/urls.py` | None | - -### 5.5 Testing - -- ✅ Sites renderer loads site definitions -- ✅ Blocks render correctly -- ✅ Deployment works end-to-end -- ✅ Sites are accessible publicly - -**Timeline**: 2-3 weeks - ---- - -## PHASE 6: SITE INTEGRATION & MULTI-DESTINATION PUBLISHING - -**Goal**: Support multiple publishing destinations (WordPress, Sites, Shopify). - -### 6.1 Site Integration Models - -| Task | Files | Dependencies | -|------|-------|--------------| -| **SiteIntegration Model** | `business/integration/models.py` | Phase 1 | -| **Integration Migrations** | `business/integration/migrations/` | Phase 1 | - -### 6.2 Integration Service - -| Task | Files | Dependencies | -|------|-------|--------------| -| **IntegrationService** | `business/integration/services/integration_service.py` | Phase 1 | -| **SyncService** | `business/integration/services/sync_service.py` | Phase 1 | - -### 6.3 Publishing Adapters - -| Task | Files | Dependencies | -|------|-------|--------------| -| **BaseAdapter** | `business/publishing/services/adapters/base_adapter.py` | Phase 5 | -| **WordPressAdapter** | `business/publishing/services/adapters/wordpress_adapter.py` | EXISTING (refactor) | -| **SitesRendererAdapter** | `business/publishing/services/adapters/sites_renderer_adapter.py` | Phase 5 | -| **ShopifyAdapter** | `business/publishing/services/adapters/shopify_adapter.py` | Phase 5 (future) | - -### 6.4 Multi-Destination Publishing - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Extend PublisherService** | `business/publishing/services/publisher_service.py` | Phase 5 | -| **Multi-destination Support** | `business/publishing/services/publisher_service.py` | Phase 5 | -| **Update PublishingRecord** | `business/publishing/models.py` | Phase 5 | - -### 6.5 Site Model Extensions - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Add site_type field** | `core/auth/models.py` | None | -| **Add hosting_type field** | `core/auth/models.py` | None | -| **Add integrations relationship** | `core/auth/models.py` | Phase 6.1 | -| **Migration** | `core/auth/migrations/` | None | - -### 6.6 Integration API - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Integration ViewSet** | `modules/integration/views.py` | IntegrationService | -| **Integration URLs** | `modules/integration/urls.py` | None | - -### 6.7 Integration UI (Update Existing) - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Update Integration Settings** | `frontend/src/pages/Settings/Integration.tsx` | EXISTING (update) | -| **Site Integration Management** | `frontend/src/pages/Settings/Integration.tsx` | EXISTING (update) | -| **Integration API Client** | `frontend/src/services/integration.api.ts` | NEW | -| **Multi-Platform Support** | `frontend/src/components/integration/PlatformSelector.tsx` | NEW | -| **Integration Status** | `frontend/src/components/integration/IntegrationStatus.tsx` | NEW | - -**Update Existing Integration Page**: -- Add SiteIntegration model support -- Show multiple integrations per site -- Add WordPress, Shopify, Custom API options -- Two-way sync toggle -- Connection testing - -### 6.8 Publishing Settings UI - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Publishing Settings Page** | `frontend/src/pages/Settings/Publishing.tsx` | NEW | -| **Destination Management** | `frontend/src/pages/Settings/Publishing.tsx` | Phase 6 | -| **Publishing Rules** | `frontend/src/components/publishing/PublishingRules.tsx` | NEW | -| **Auto-Publish Settings** | `frontend/src/components/publishing/AutoPublishSettings.tsx` | NEW | -| **Publishing API Client** | `frontend/src/services/publisher.api.ts` | NEW | - -### 6.9 Individual Site Management (CMS) - -**User-Friendly Name**: "Site Manager" or "Content Manager" - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Site Management Dashboard** | `frontend/src/pages/Sites/Manage.tsx` | NEW | -| **Site Content Editor** | `frontend/src/pages/Sites/Editor.tsx` | NEW | -| **Post Editor** | `frontend/src/pages/Sites/PostEditor.tsx` | NEW | -| **Page Manager** | `frontend/src/pages/Sites/PageManager.tsx` | NEW | -| **Add/Remove Pages** | `frontend/src/components/sites/PageManager.tsx` | NEW | -| **Content List** | `frontend/src/components/sites/ContentList.tsx` | NEW | -| **Site Settings** | `frontend/src/pages/Sites/Settings.tsx` | NEW | -| **Site API Client** | `frontend/src/services/sites.api.ts` | NEW | - -**Site Management Features**: -- View all pages/posts for a site -- Add new pages -- Remove pages -- Edit page content -- Manage page order -- Change page templates -- Update site settings -- Preview site - -### 6.11 WordPress Plugin Connection (API Only) - -| Task | Files | Dependencies | -|------|-------|--------------| -| **WordPress Sync Endpoints** | `modules/integration/views.py` | IntegrationService | -| **Two-way Sync Logic** | `business/integration/services/sync_service.py` | Phase 6.2 | -| **WordPress Webhook Handler** | `modules/integration/views.py` | Phase 6.2 | - -**Note**: WordPress plugin itself is built separately. Only API endpoints for plugin connection are built here. - -### 6.9 Testing - -- ✅ Site integrations work correctly -- ✅ Multi-destination publishing works -- ✅ WordPress sync works (when plugin connected) -- ✅ Two-way sync functions properly - -**Timeline**: 2-3 weeks - ---- - -## PHASE 7: UI COMPONENTS & MODULE SETTINGS - -**Goal**: Build comprehensive UI system with shared components, module settings, and site management. - -### 7.1 Global Component Library - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Component Library Structure** | `frontend/src/components/shared/` | None | -| **Block Components** | `frontend/src/components/shared/blocks/` | None | -| **Layout Components** | `frontend/src/components/shared/layouts/` | None | -| **Template Components** | `frontend/src/components/shared/templates/` | None | -| **Component Documentation** | `frontend/src/components/shared/README.md` | None | -| **Component Storybook** | `frontend/.storybook/` | Optional | -| **Component Tests** | `frontend/src/components/shared/**/*.test.tsx` | None | - -**Component Standards**: -- All components use TypeScript -- All components have props interfaces -- All components are responsive -- All components support dark mode -- All components are accessible (ARIA) -- No duplicate components - -### 7.2 Module Settings UI - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Module Settings Page** | `frontend/src/pages/Settings/Modules.tsx` | EXISTING (implement) | -| **Module Toggle Component** | `frontend/src/components/settings/ModuleToggle.tsx` | NEW | -| **Module Status Indicator** | `frontend/src/components/settings/ModuleStatus.tsx` | NEW | -| **Module Configuration** | `frontend/src/components/settings/ModuleConfig.tsx` | NEW | -| **Module Settings API** | `frontend/src/services/modules.api.ts` | NEW | - -**Module Settings Features**: -- Enable/disable modules per account -- Module-specific configuration -- Module status display -- Module usage statistics -- Module dependencies check - -### 7.3 Frontend Module Loader - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Module Config** | `frontend/src/config/modules.config.ts` | Phase 0 | -| **Module Guard** | `frontend/src/components/common/ModuleGuard.tsx` | Phase 0 | -| **Conditional Route Loading** | `frontend/src/App.tsx` | Phase 0 | -| **Sidebar Module Filter** | `frontend/src/layout/AppSidebar.tsx` | Phase 0 | - -**Module Loading Logic**: -```typescript -// Check if module is enabled before loading -const isModuleEnabled = (moduleName: string) => { - const settings = useSettingsStore(state => state.moduleSettings); - return settings[moduleName]?.enabled ?? true; // Default enabled -}; - -// Conditional route loading -{isModuleEnabled('site_builder') && ( - } /> -)} -``` - -### 7.4 Site Management UI - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Site List View** | `frontend/src/pages/Sites/List.tsx` | NEW | -| **Site Dashboard** | `frontend/src/pages/Sites/Dashboard.tsx` | NEW | -| **Site Content Manager** | `frontend/src/pages/Sites/Content.tsx` | NEW | -| **Post Editor** | `frontend/src/pages/Sites/PostEditor.tsx` | NEW | -| **Page Manager** | `frontend/src/pages/Sites/Pages.tsx` | NEW | -| **Site Settings** | `frontend/src/pages/Sites/Settings.tsx` | NEW | -| **Site Preview** | `frontend/src/pages/Sites/Preview.tsx` | NEW | - -**Site Management Features**: -- List all sites -- Site dashboard with stats -- Content management (posts, pages) -- Add/remove pages -- Edit content -- Change templates -- Update site settings -- Preview site - -### 7.5 Layout & Template System - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Layout Selector** | `frontend/src/components/sites/LayoutSelector.tsx` | NEW | -| **Template Library** | `frontend/src/components/sites/TemplateLibrary.tsx` | NEW | -| **Layout Preview** | `frontend/src/components/sites/LayoutPreview.tsx` | NEW | -| **Template Customizer** | `frontend/src/components/sites/TemplateCustomizer.tsx` | NEW | -| **Style Editor** | `frontend/src/components/sites/StyleEditor.tsx` | NEW | - -**Layout Options**: -- Default Layout -- Minimal Layout -- Magazine Layout -- Ecommerce Layout -- Portfolio Layout -- Blog Layout -- Corporate Layout - -**Template System**: -- Pre-built templates -- Custom templates -- Template customization -- Style presets -- Color schemes -- Typography options - -### 7.6 CMS Styling System - -| Task | Files | Dependencies | -|------|-------|--------------| -| **CMS Theme System** | `frontend/src/styles/cms/` | NEW | -| **Style Presets** | `frontend/src/styles/cms/presets.ts` | NEW | -| **Color Schemes** | `frontend/src/styles/cms/colors.ts` | NEW | -| **Typography System** | `frontend/src/styles/cms/typography.ts` | NEW | -| **Component Styles** | `frontend/src/styles/cms/components.ts` | NEW | - -**CMS Features**: -- Theme customization -- Color palette management -- Typography settings -- Component styling -- Responsive breakpoints -- Dark/light mode - -### 7.7 Testing - -- ✅ All components render correctly -- ✅ Module settings enable/disable modules -- ✅ Disabled modules don't load -- ✅ Site management works end-to-end -- ✅ Layout system works -- ✅ Template system works -- ✅ No duplicate components - -**Timeline**: 3-4 weeks - ---- - -## PHASE 8: UNIVERSAL CONTENT TYPES - -**Goal**: Extend content system to support products, services, taxonomies. - -### 8.1 Content Model Extensions - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Add entity_type field** | `business/content/models.py` | Phase 1 | -| **Add json_blocks field** | `business/content/models.py` | Phase 1 | -| **Add structure_data field** | `business/content/models.py` | Phase 1 | -| **Content Migrations** | `business/content/migrations/` | Phase 1 | - -### 8.2 Content Type Prompts - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Product Prompts** | `infrastructure/ai/prompts.py` | Existing prompt system | -| **Service Page Prompts** | `infrastructure/ai/prompts.py` | Existing prompt system | -| **Taxonomy Prompts** | `infrastructure/ai/prompts.py` | Existing prompt system | - -### 8.3 Content Service Extensions - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Product Content Generation** | `business/content/services/content_generation_service.py` | Phase 1 | -| **Service Page Generation** | `business/content/services/content_generation_service.py` | Phase 1 | -| **Taxonomy Generation** | `business/content/services/content_generation_service.py` | Phase 1 | - -### 8.4 Linker & Optimizer Extensions - -| Task | Files | Dependencies | -|------|-------|--------------| -| **Product Linking** | `business/linking/services/linker_service.py` | Phase 4 | -| **Taxonomy Linking** | `business/linking/services/linker_service.py` | Phase 4 | -| **Product Optimization** | `business/optimization/services/optimizer_service.py` | Phase 4 | -| **Taxonomy Optimization** | `business/optimization/services/optimizer_service.py` | Phase 4 | - -### 8.5 Testing - -- ✅ Product content generates correctly -- ✅ Service pages work -- ✅ Taxonomy pages work -- ✅ Linking works for all types -- ✅ Optimization works for all types - -**Timeline**: 2-3 weeks - ---- - -## TESTING & VALIDATION - -### Testing Strategy - -| Phase | Testing Focus | Validation | -|-------|--------------|------------| -| **Phase 0** | Credit system, existing features | All existing features work with credits | -| **Phase 1** | Service layer, API compatibility | APIs unchanged, services work | -| **Phase 2** | Automation execution | Rules execute, schedules work | -| **Phase 3** | Site Builder end-to-end | Sites build and deploy | -| **Phase 4** | Linker/Optimizer quality | Content improves, links work | -| **Phase 5** | Sites renderer | Sites render correctly | -| **Phase 6** | Multi-destination publishing | Content publishes to all destinations | -| **Phase 7** | UI components & module settings | Components work, modules can be disabled, site management works | -| **Phase 8** | Universal content types | All content types work | - -### Backward Compatibility Checklist - -- ✅ All existing API endpoints work -- ✅ All existing workflows function -- ✅ Frontend continues working -- ✅ Database migrations are safe -- ✅ No data loss during migration - -### Rollout Strategy - -1. **Feature Flags**: Enable new features gradually -2. **Beta Testing**: Test with select accounts first -3. **Gradual Rollout**: Enable for all users after validation -4. **Monitoring**: Track errors, performance, usage - ---- - -## SUMMARY - -### Implementation Timeline - -| Phase | Duration | Dependencies | -|-------|----------|--------------| -| **Phase 0: Credit System** | 1-2 weeks | None | -| **Phase 1: Service Layer** | 2-3 weeks | Phase 0 | -| **Phase 2: Automation** | 2-3 weeks | Phase 1 | -| **Phase 3: Site Builder** | 3-4 weeks | Phase 1, Phase 2 | -| **Phase 4: Linker/Optimizer** | 3-4 weeks | Phase 1 | -| **Phase 5: Sites Renderer** | 2-3 weeks | Phase 3 | -| **Phase 6: Site Integration** | 2-3 weeks | Phase 5 | -| **Phase 7: UI Components & Module Settings** | 3-4 weeks | Phase 0, Phase 3, Phase 5 | -| **Phase 8: Universal Types** | 2-3 weeks | Phase 4 | - -**Total Estimated Time**: 20-29 weeks (5-7 months) - -### Key Success Criteria - -- ✅ All existing features continue working -- ✅ Credit system is universal and consistent -- ✅ Automation system is functional -- ✅ Site Builder creates and deploys sites ("Website Builder" in UI) -- ✅ Sites Renderer hosts sites ("My Websites" in UI) -- ✅ Linker and Optimizer improve content -- ✅ Multi-destination publishing works -- ✅ Module settings enable/disable modules (modules don't load when disabled) -- ✅ Global component library (no duplicates, shared across all apps) -- ✅ Multiple layout options for sites (7 layout types) -- ✅ Site management UI (CMS) for content editing, page management -- ✅ Site Integration UI updated with new SiteIntegration model -- ✅ Publishing Settings UI functional -- ✅ All content types supported - ---- - -**END OF DOCUMENT** - diff --git a/part2-dev/Igny8-part-2-plan.md b/part2-dev/Igny8-part-2-plan.md deleted file mode 100644 index e7f3e42f..00000000 --- a/part2-dev/Igny8-part-2-plan.md +++ /dev/null @@ -1,1711 +0,0 @@ -✅ IGNY8 SITE BUILDER – Full Implementation Document -Module 1 of 5 -Status: Detailed Technical Specification -Container: igny8_site_builder_frontend (React/Vite) -Backend dependency: IGNY8 App (Django API) -Integration: Site definitions → IGNY8 Sites container -________________________________________ -1. PURPOSE & POSITION IN SYSTEM -The IGNY8 Site Builder is the AI-driven site creation system inside the IGNY8 ecosystem. -It enables users to generate: -• Blog sites -• Company sites -• Ecommerce sites -using IGNY8’s existing: -• Keyword → Cluster → Ideas → Writer → Image pipelines -• User accounts, tenants, sites -• Branding, colors, typography -• SEO structures and strategies -The builder lives inside the IGNY8 App, but runs in a separate frontend container because it: -• Uses a different router -• Requires live preview -• Needs its own static build -• Must not interfere with the dashboard UI -________________________________________ -2. HIGH-LEVEL FLOW -User → Builder Wizard → Structure Definition → AI Page Generation → Preview → Publish to IGNY8 Sites -Backend participation: -IGNY8 Backend: -- Receives builder config -- Generates site structure JSON -- Generates page content via Writer -- Generates image prompts + images -- Stores site definitions in DB -- Provides APIs to fetch site data -Renderer participation: -IGNY8 Sites Container: -- Receives final site definition -- Builds marketing + client sites -- Serves live sites publicly -________________________________________ -3. CORE FEATURES -1. Wizard Interface -2. AI-Generated Site Structure -3. Page Templates + Blocks -4. Preview Renderer -5. Site Settings Management -6. Deploy to “IGNY8 Sites” -7. Regeneration per section or page -8. Full integration with Planner/Writer/Image modules -9. Multi-tenant and multi-site support -________________________________________ -4. FRONTEND ARCHITECTURE (Site Builder Container) -Folder Layout -/site-builder-frontend/ - src/ - pages/ - wizard/ - preview/ - dashboard/ - components/ - layout/ - blocks/ - forms/ - preview-canvas/ - state/ - builderStore.ts (Zustand) - siteDefinitionStore.ts - api/ - builder.api.ts - sites.api.ts - utils/ - validation.ts - templates.ts - config/ - themePresets.ts - siteTypes.ts -Required Libraries -• React -• Vite -• Zustand -• React Router -• Tailwind -• ShadCN for UI -• Toast + Modal system (shared with main app) -• Monaco editor (optional for raw JSON editing) -• CodeMirror (optional for templates) -• Markdown/HTML parser for previews -________________________________________ -5. BACKEND ARCHITECTURE (Inside IGNY8 App) -New Module -Add to: -/backend/igny8_core/modules/site_builder/ -Files: -models.py -serializers.py -views.py -generator.py -structure.py -deployment.py -validations.py -New Django Models -1. SiteBlueprint -Stores AI-generated site structure. -Fields: -• tenant -• site -• config_json (wizard choices) -• structure_json (pages, blocks, menus) -• status (draft, generating, ready) -• created_at, updated_at -2. PageBlueprint -Stores individual page definitions. -• site_blueprint -• slug -• type (home, about, blog-index, post, ecommerce, etc.) -• blocks_json -• status -3. DeploymentRecord -Tracks deployment to IGNY8 Sites renderer. -• site_blueprint -• version -• status -• build_url -• deployed_at -API Endpoints -Base route: -/api/v1/site-builder/ -Endpoints: -POST /wizard/start/ → create initial blueprint -POST /wizard/structure/ → AI structure generation -POST /wizard/generate-pages/ → generate all page content -POST /wizard/preview/ → return preview JSON -POST /deploy/ → deploy to IGNY8 Sites -GET /blueprints/{id}/ → fetch blueprint -GET /page/{id}/ → fetch page -PATCH /page/{id}/regenerate/ → regenerate single page -Uses Planner/Writer/Image pipelines internally: -• cluster data -• ideas -• image prompts -• images -• content generation rules -All credit usage is logged through the IGNY8 billing module. -________________________________________ -6. AI INTEGRATION LOGIC -Phase 1: Site Structure Generation -Prompt uses: -• Business summary -• Site type -• Objectives -• Industry sector (from Planner) -• Cluster summaries -• IGNY8 layout rules -Outputs: -• page list -• sections per page -• block-level metadata -• SEO structure (titles, slugs, meta) -Phase 2: Page Content Generation -Uses Writer (existing code) but wrapped for: -• non-blog pages -• company pages -• ecommerce pages -• hero sections -• feature sections -• contact pages -Phase 3: Image Prompt Generation -Reuses your Thinker module’s image prompt extraction. -Phase 4: Deploy -Uploads: -• JSON site definition -• assets -• images -To IGNY8 Sites container. -________________________________________ -7. PREVIEW SYSTEM (In Builder Container) -• Builder renders JSON-driven pages using reusable components -• Each block component reads from structure JSON -• Preview uses a local "fake" renderer identical to the real IGNY8 Sites renderer -Preview path: -/preview?page=home -State: -• All content stored in siteDefinitionStore -• Live re-render on edit -________________________________________ -8. DEPLOYMENT TO IGNY8 SITES -Builder → Backend → Sites container -Steps: -1. Builder sends POST /deploy/ -2. Backend converts blueprints → renderer schema -3. Backend uploads files to: -o /igny8-sites/clients/{site-id}/v{version}/ -4. Sites container builds static output (if needed) -5. Caddy routes: -o clientdomain.com → site folder -o mysite.stuys.com → site folder -________________________________________ -9. MULTI-TENANCY -All builder blueprints must respect: -• Tenant ID -• Site ID -• Permissions -• Credit limits -So that each user can generate unlimited sites without conflict. -________________________________________ -10. EXECUTION PHASES -Phase 0 — Setup -• New Docker container -• New repo folder -• Domain: builder.igny8.com -• Vite + Tailwind environment -Phase 1 — Wizard -• Site type selection -• Business brief -• Objectives -• Sector selection -• Style presets (colors, fonts) -Phase 2 — Structure Generation -• Server-side AI logic -• Create SiteBlueprint and PageBlueprint models -• Store structure JSON -Phase 3 — Page Generation -• Generate content via Writer -• Extract image prompts -• Generate images -• Populate blueprint pages -Phase 4 — Preview -• Render blueprint JSON -• Allow editing -• Regenerate single sections -Phase 5 — Deploy to IGNY8 Sites -• Convert blueprint to renderer schema -• Push site version -• Done -________________________________________ -11. DELIVERABLES CHECKLIST -Backend -• Models (3) -• Endpoints (7) -• Page generator wrapper -• Structure generator -• Deployment engine -• Permissions + credit usage -Frontend (Builder) -• Wizard flow (Step-based) -• Preview renderer -• Page/block components -• JSON editing tools -• State management (Zustand) -• Publish/deploy dialog -Integration -• Writer function reuse -• Image generator reuse -• Thinker prompts reuse -• Renderer (Sites container) integration -________________________________________ -  -✅ IGNY8 SITES (Renderer + Marketing) – Full Implementation Document -Module 2 of 5 -Container: igny8_sites_frontend -Purpose: Host igny8.com + all client websites generated by IGNY8 Site Builder -Integration: Builder → Backend → Renderer -Type: Static/React rendering & hosting layer -________________________________________ -1. PURPOSE & ROLE IN THE TOTAL SYSTEM -IGNY8 Sites is the public website hosting engine for: -1. Marketing Website (igny8.com) -2. All Stuys/IGNY8-generated client sites -3. Any public output via IGNY8 Site Builder -It consolidates everything into one frontend container equal to: -• Webflow’s published sites -• Wix’s live sites -• Framer’s publishing engine -• Vercel’s multi-project host -IGNY8 Sites is NOT tied to the IGNY8 App UI or dashboard. -It is a separate rendering system whose only job is: -READ site JSON → RENDER → SERVE PUBLIC WEBSITE -________________________________________ -2. FINAL ARCHITECTURAL IDENTITY -✔ Dedicated container -igny8_sites_frontend -✔ Serves multiple domains -• Main domain: igny8.com -• Builder preview domains -• Client custom domains -✔ Uses static generation + dynamic JSON fetch -• React/Vite or Next.js (recommended) -• Loads site definition JSON at runtime -• Renders pages using block components -✔ Compatible with: -• SEO -• Caddy routing -• Multi-site deployments -• Cached CDN delivery -________________________________________ -3. HIGH-LEVEL PIPELINE -Builder → Backend Storage → IGNY8 Sites Renderer → Caddy Routing → Public Site -Detailed steps: -1. User builds site via IGNY8 Site Builder -2. Backend stores: -o SiteBlueprint -o PageBlueprints -o Images -3. Backend transforms blueprint JSON → Renderer Schema -4. Renderer receives versioned site folder: -5. /clients/{site-id}/v1/ -6. site.json -7. pages/ -8. images/ -9. assets/ -10. Caddy routes: -o clientdomain.com → folder -o mysite.igny8.com → folder -o igny8.com → marketing folder -________________________________________ -4. FOLDER + FILE STRUCTURE (Renderer Repo) -/igny8-sites/ - marketing/ (igny8.com) - index.html - assets/ - static/ - ... - - clients/ - 001/ - v1/ - site.json - pages/ - home.json - about.json - contact.json - blog-index.json - blog-post-1.json - assets/ - images/ - hero.webp - product1.webp - seo/ - sitemap.xml - robots.txt - - 002/ - v3/ - ... - - src/ - renderer/ - index.html - main.tsx - router.tsx - components/ - Layout/ - Blocks/ - UI/ - loaders/ - loadSiteDefinition.ts - utils/ - resolveRoutes.ts - mergeTheme.ts - hooks/ - useSiteVersion.ts - usePageData.ts - config/ - themes/ - block-schema/ - seo/ - pages/ - [dynamic Next.js or React Router structure] - - Dockerfile - vite.config.js or next.config.js -Renderer template uses: -• React 18 -• React Router / Next.js (recommended for SEO) -• Tailwind -• ShadCN/UI -• File-based component system -________________________________________ -5. RENDERER LOGIC -A. Load Site Definition -GET /clients/{siteId}/{version}/site.json -Includes: -• Global theme -• Typography -• Colors -• Navigation -• Footer layout -• Page map -• SEO settings -B. Load Page Definition -GET /clients/{siteId}/{version}/pages/{slug}.json -Contains: -• Page name -• Path -• Blocks array (json schema) -• SEO meta -• Image references -• Dynamic content (blog posts etc.) -C. Render Blocks -Each block has a type: -{ - type: "hero", - props: {...} -} -Mapped to component: - -Blocks library: -• Hero -• Features -• Services -• Product grid -• Stats -• Testimonials -• Blog list -• Contact form -• Footer -________________________________________ -6. MARKETING WEBSITE (igny8.com) -IGNY8 Sites will host your marketing website under: -/igny8-sites/marketing/ -Upgradation path: -• Controlled by the same block/renderer architecture -• Designed using IGNY8 Sites component library -• Built with same visual system as client sites -• Easily editable and extensible -This unifies your branding across all layers. -________________________________________ -7. DEPLOYMENT MECHANISM -A. Builder triggers deploy → Backend pushes new version -Backend stores: -/clients/{site-id}/v{n}/site.json -/pages/ -assets/ -Renderer automatically detects new version at runtime. -B. Caddy routing rules -Routes: -# Marketing -igny8.com → /igny8-sites/marketing/ - -# Client sites -mysalon.igny8.com → /clients/342/v4/ -amazingcars.com → /clients/417/v2/ -How Caddy resolves it: -Use: -• reverse_proxy for dynamic parts -• file_server for static -• try_files for routing -________________________________________ -8. MULTI-TENANCY LOGIC -Each site belongs to: -• Tenant -• Optional domain -• Site ID -• Version number -Backend sets: -siteId = uuid -version = incremental -Renderer resolves folder path: -/clients/{siteId}/v{version}/ -Caddy aliases domain → correct folder -________________________________________ -9. SEO FEATURES -Renderer handles: -• Meta tags -• OpenGraph -• Breadcrumb analysis -• Article schema -• LocalBusiness schema -• Product schema -• Blog posting schema -• Sitemap generation -• robots.txt per site -Backend provides SEO JSON per page. -Renderer applies: -{seo.title} - - -________________________________________ -10. RUNTIME REQUIREMENTS -• Caddy for multi-domain routing -• Local volume for sites storage -• Container-level static serving -• High caching -• SSR optional with Next.js -________________________________________ -11. DELIVERABLES CHECKLIST -Renderer Container -• Dockerfile -• Vite/Next.js setup -• Component library -• Block engine -• Theming system -• Page renderer -• SEO engine -• Custom domain resolver -• Site version resolver -• Error screens -Backend Module -• DeploymentRecord model -• Renderer schema converter -• Static asset uploader -• Version manager -• Caddy integration hooks -• Multi-site registry -Builder Integration -• Deploy button → triggers new version -• Version check → preview update -• Domain management -• Rebuild capability -________________________________________ -12. EXECUTION PHASES -Phase 1 -• Renderer skeleton -• Routing + dynamic loading -• Marketing home → Functional -• Basic block engine -Phase 2 -• Full component library -• SEO engine -• Theming system -Phase 3 -• Multi-site deployment system -• Versioned folder architecture -• Page types (home, about, blog, ecom) -Phase 4 -• Custom domain mapping -• Caddy rule automation -Phase 5 -• Full launch + integration with Site Builder -________________________________________ -  -✅ IGNY8 WORDPRESS PLUGIN – Full Implementation Document -Module 3 of 5 -Location: WordPress Container -Repo: /igny8-wp-plugin/ -Purpose: Bridge between IGNY8 App and WordPress for content publishing, media sync, site sync, semantic mapping, and two-way data flow. -This plugin is the official connector that enables: -• IGNY8 → WordPress content publishing -• WordPress → IGNY8 post status + metadata sync -• Media upload sync -• Keyword/Cluster metadata injection -• Full/Incremental site scans -• User authentication with IGNY8 App -• IGNY8 API client -• WP hooks integration -• Two-way sync events -Everything below references actual APIs in WORDPRESS-PLUGIN-INTEGRATION.md. -________________________________________ -1. PURPOSE IN THE IGNY8 ECOSYSTEM -IGNY8 WP Plugin represents all IGNY8-generated content inside WordPress. -Its responsibilities: -A. From IGNY8 → WordPress -• Create posts/pages from IGNY8 Writer output -• Attach images from IGNY8 Image Generator -• Map cluster/keyword metadata -• Assign category = cluster -• Insert block-structured HTML -• Maintain post-task relationship (task_id, content_id) -B. From WordPress → IGNY8 -• Sync post status (publish, draft, trash) -• Notify IGNY8 when user edits content -• Update keyword status (mapped) -• Sync assigned_post_id and post_url -• Batch sync posts via Cron -• WooCommerce product sync (optional) -C. WP Site → IGNY8 (Semantic Mapping Pipeline) -Using REST API and IGNY8 API: -• Fetch all posts -• Fetch taxonomies -• Fetch WooCommerce products -• Send complete site structure to IGNY8 -• Receive restructuring suggestions -• Track site import/sync jobs -________________________________________ -2. PLUGIN ARCHITECTURE -/igny8-wp-plugin/ - igny8.php - /admin/ - settings-page.php - notices.php - /api/ - class-igny8-api.php (API client) - /lib/ - sync-posts.php - sync-status.php - sync-products.php - sync-taxonomies.php - site-import.php - semantic-mapper.php - /hooks/ - post-hooks.php - cron-hooks.php - publish-hooks.php - /routes/ - wp-rest.php - /views/ - settings-form.php - sync-dashboard.php -________________________________________ -3. PLUGIN MODULES (Required) -A. Authentication Module -• Email + password login to IGNY8 API -• Stores access + refresh tokens in WordPress options -• Token auto-refresh system -• Error handling + user messages -API endpoints used: -POST /api/v1/auth/login/ -POST /api/v1/auth/refresh/ -________________________________________ -B. IGNY8 API Client (Core Class) -Class: Igny8API -Functions: -Function Purpose -login() Authenticate WP with IGNY8 -refresh_token() Refresh JWT -get() GET requests -post() POST requests -put() Update task data, keyword status, sync info -delete() Remove mappings or posts -parse_response() Unified API response parsing -get_headers() Bearer auth + JSON headers -All responses must follow your unified IGNY8 format. -________________________________________ -C. Content Publishing Module -(IGNY8 → WP) -Triggered when IGNY8 generates content and sends a “publish” action. -Flow: -1. Receive content JSON from IGNY8: -o title -o html_content (already block-optimized by IGNY8’s block parser) -o featured_image -o in-article images -o task_id -o cluster_id -o primary_keyword, secondary_keywords -2. Create WordPress post using: -wp_insert_post() -3. Save IGNY8 metadata: -_meta: - _igny8_task_id - _igny8_content_id - _igny8_primary_keyword - _igny8_secondary_keywords - _igny8_cluster_id -4. Assign cluster as category: -wp_set_post_terms($post_id, [$cluster_term_id], 'category') -5. Upload images with WordPress media API: -media_sideload_image() -________________________________________ -D. Post Status Sync Module -(WP → IGNY8) -Uses WP hooks: -save_post -publish_post -transition_post_status -draft_to_publish -future_to_publish -trash_post -Maps WordPress status → IGNY8 status: -WP IGNY8 -publish completed -draft draft -pending pending -private completed -future scheduled -trash archived -Sends request: -PUT /writer/tasks/{task_id}/ -Payload: -{ - "status": "completed", - "assigned_post_id": 123, - "post_url": "https://mysite.com/post-title" -} -________________________________________ -E. Keyword Sync Module -Triggered on publish: -publish_post -draft_to_publish -future_to_publish -Action: -• Fetch cluster_id from task -• Fetch all keywords in that cluster via: -GET /planner/keywords/?cluster_id=ID -• Update each to: -PUT /planner/keywords/{id}/ { "status": "mapped" } -________________________________________ -F. Full Site Import Module -(WP → IGNY8 Site Map) -Collects: -• All posts -• Pages -• Custom post types -• Categories -• Tags -• WooCommerce products -• Product categories -• Product attributes -Then sends: -POST /system/sites/{site_id}/import/ -Payload includes: -• site_data -• posts -• taxonomies -• products -• product_attributes -________________________________________ -G. Incremental Sync Module -Daily cron: -wp_schedule_event('daily') -Sends modified posts since last sync: -POST /system/sites/{site_id}/sync/ -For AI restructuring and semantic updates. -________________________________________ -H. IGNY8 → WP Events -Hook triggered when IGNY8 pushes content: -do_action('igny8_content_published', $content_data) -Then: -wp_insert_post($content_data) -update task in IGNY8 with post_url -________________________________________ -4. REQUIRED WORDPRESS ADMIN PAGES -1. IGNY8 Settings Page -• API login -• Test connection -• Token status -• Last sync timestamp -• Site ID -• Manual sync button -2. IGNY8 Content Dashboard -• List all IGNY8-managed posts -• Task status -• Keyword mapping -• Cluster assignment -• Manual re-sync button -3. IGNY8 Site Sync Dashboard -• Full scan -• Incremental scan -• Last run status -• Semantic map display -• Restructuring recommendations -________________________________________ -5. ENDPOINTS REQUIRED BY THE PLUGIN (IGNY8 API v1) -From your API documentation + integration file: -Authentication -POST /auth/login/ -POST /auth/refresh/ -Planner -GET /planner/keywords/ -PUT /planner/keywords/{id}/ -Writer -GET /writer/tasks/{task_id}/ -PUT /writer/tasks/{task_id}/ -POST /writer/tasks/{task_id}/publish/ -System (Site Import) -POST /system/sites/{site_id}/import/ -POST /system/sites/{site_id}/sync/ -GET /system/sites/{site_id}/recommendations/ -POST /system/sites/{site_id}/restructure/ -Misc -GET /auth/user/ -________________________________________ -6. PLUGIN EXECUTION PHASES -Phase 0: Setup -• Create repo -• Basic plugin file -• Register admin menu -• Enqueue scripts -• Create activation hooks -Phase 1: IGNY8 API Client -• Authentication -• Token refresh -• Unified response handler -• Error system -Phase 2: Content Publishing -• WordPress → IGNY8 mapping -• IGNY8 → WP post insertion -• Media download -• Metadata storage -Phase 3: Status Sync -• Post hooks (save_post, publish_post) -• Status mapping -• Keyword “mapped” update -Phase 4: Full Site Sync -• REST fetch: posts, pages, CPTs -• REST fetch: taxonomies -• WooCommerce (if available) -• Combined site_data -• Send to IGNY8 -Phase 5: Incremental Sync -• Cron job -• Modified posts -• Update IGNY8 -Phase 6: UI/UX for WP Dashboard -• IGNY8 settings -• Content dashboard -• Sync dashboard -Phase 7: Testing + Validation -• Unit tests for API client -• Post creation tests -• Sync tests -________________________________________ -7. WHAT THIS PLUGIN ACHIEVES -IGNY8 becomes a complete WordPress publishing engine. -WordPress becomes: -• A destination for content -• A “live CMS” for IGNY8 content -• A signal source for IGNY8 semantic restructuring -This plugin is the official bridge connecting two systems: -• IGNY8 App (AI-first CMS) -• WordPress (display CMS) -________________________________________ -  -IGNY8 WORDPRESS THEME -Full Implementation Document -Module 4 of 5 -1. Role in the IGNY8 Ecosystem -The IGNY8 WordPress Theme is the visual and structural layer for any site where: -• Content is generated by IGNY8 App -• Content is delivered into WordPress via the IGNY8 WP Plugin -• WordPress is used as the final display CMS -The theme: -• Does not run any AI logic -• Does not call IGNY8 APIs directly -• Does not manage jobs, credits, or clusters -It is a pure representation layer that: -1. Understands the content structure and metadata IGNY8 Plugin writes into WordPress. -2. Renders that content using consistent layouts optimized for IGNY8’s SEO strategy. -3. Provides predictable templates for cluster hubs, supporting posts, and product pages. -IGNY8 App and plugin handle logic. -The theme handles presentation, aligned to that logic. -________________________________________ -2. Design and Technical Principles -1. Gutenberg native block theme -o Uses theme.json -o Templates are block templates (.html files) under /templates -o Template parts under /parts -2. Content first -o Layout and styling assume IGNY8 structured content: long form editorial sections, internal links, images, FAQs -o No heavy reliance on shortcodes -3. Metadata aware -o Knows about these meta fields created by plugin: - _igny8_task_id - _igny8_content_id - _igny8_primary_keyword - _igny8_secondary_keywords - _igny8_cluster_id -o Uses categories and tags produced via plugin and app -4. Cluster aware -o Treats certain categories as cluster hubs -o Builds predictable layout for hub vs supporting posts -5. Minimal logic, maximum compatibility -o Theme must not break when content is not IGNY8 generated -o Works fine for manual posts, pages, and WooCommerce if activated -________________________________________ -3. Theme Folder Structure -Repository: /igny8-wp-theme/ -/igny8-wp-theme/ - style.css - functions.php - theme.json - - /templates/ - index.html - front-page.html - home.html - single.html - single-post.html - page.html - archive.html - category.html - category-cluster.html (custom template, selected by category) - tag.html - search.html - 404.html - - /parts/ - header.html - footer.html - hero.html - post-meta.html - sidebar.html - related-posts.html - cluster-nav.html - breadcrumbs.html - - /patterns/ - hero-featured.php - longform-article.php - cluster-hub-layout.php - faq-section.php - comparison-table.php - product-feature-list.php - call-to-action.php - - /assets/ - /css/ - /js/ - /images/ -________________________________________ -4. Data Contract With IGNY8 WP Plugin -The theme assumes the plugin has already: -1. Created the post with: -o Title -o Full HTML content -o Correct categories and tags -o Featured image -o Optional excerpt -2. Stored IGNY8 specific meta: -Meta key Meaning -_igny8_task_id Link back to Writer task in IGNY8 -_igny8_content_id Internal IGNY8 content identifier -_igny8_primary_keyword Main keyword used for SEO and layout decisions -_igny8_secondary_keywords Comma separated list or JSON string -_igny8_cluster_id Cluster taxonomy term used as category -3. Assigned cluster category as WordPress category: -o wp_set_post_terms($post_id, [$cluster_term_id], 'category') -4. Injected already block friendly markup: -o Paragraphs, headings, lists, blockquotes, tables -o Gutenberg compatible markup -The theme does not rebuild or parse raw AI output. -It only renders and enhances what is there. -________________________________________ -5. Templates and Their Purpose -5.1 front page and home -• front-page.html -For sites where homepage is a static page: -o Hero section -o Key benefits -o Featured clusters -o Latest blogs -• home.html -For standard blog listing: -o Blog list with excerpt and meta -o Optional cluster filters -5.2 single post -• single.html or single-post.html -Structure: -1. Hero section -o Title -o Meta (date, reading time, category) -o Featured image -2. Content body -o Renders Gutenberg blocks as generated by IGNY8 -o Uses a content wrapper with a class like .igny8-article-content -3. In article elements -o Styles for: - Images and captions - Blockquotes - Tables - Lists - FAQ sections - Comparison elements -4. Cluster navigation -o If _igny8_cluster_id exists: - Show cluster name - Show related posts from same cluster - Optional cluster breadcrumb (Cluster > Post) -5.3 category and cluster hubs -• category.html for generic categories -• category-cluster.html for IGNY8 clusters -category-cluster.html is used when: -• Category has meta key _igny8_is_cluster or -• Category is explicitly configured in theme options as cluster type -Layout: -1. Cluster hero -o Cluster name -o Intro text (manual or IGNY8 generated) -o Primary keyword -2. Supporting posts section -o Grid or list of posts in cluster -o Highlight key roles: - Beginner guide - Comparison post - Use case posts -o Make it easy for IGNY8 to map these conventional roles -3. Optional CTA: -o Contact -o Book consultation -o Download resource -5.4 page template -• page.html -For generic static pages (about, contact, services) where IGNY8 content is occasionally used. -5.5 archive, search, 404 -Standard WordPress structures but visually consistent with IGNY8 overall design system. -________________________________________ -6. Block Patterns and Styles -To match IGNY8 generated content, create patterns that correspond to how the app structures text. -6.1 Core patterns -1. hero-featured.php -o Featured image -o Large title -o Subtitle -o CTA button -2. longform-article.php -o Pre configured layout: - Article header - Table of contents - Main content area - Related posts / CTAs -3. cluster-hub-layout.php -o Cluster summary text block -o Supporting post list blocks -o Internal links to key posts -4. faq-section.php -o Repeated question answer blocks -o FAQ heading -o Schema ready markup friendly structure -5. comparison-table.php -o Table styled to match IGNY8 comparison posts -6. product-feature-list.php -o Short bullet feature list -o Icons or checkmarks -7. call-to-action.php -o Section with heading -o Subheading -o Button -These patterns are used both for: -• Manual content tweaking in Gutenberg -• Consistency with AI generated layout designs -________________________________________ -7. Styling System -Use theme.json as the single source of truth for styles. -Key elements: -• Color palette that can map to IGNY8 brand tokens: -o Primary, secondary, accent, background, surface, success, warning, danger -• Typography: -o Base font family -o Heading font -o Sizes and spacing aligned with IGNY8 App styles -• Spacing: -o Small, normal, large section padding and margins -• Block level styles: -o core/paragraph -o core/heading -o core/list -o core/table -o core/quote -o core/image -Ensure: -• Long form content stays readable -• Headings are visually layered -• Tables and lists are clean and clear -• Quote blocks stand out but remain simple -________________________________________ -8. SEO and Performance -The theme does not override SEO plugins, but must be compatible with: -• Yoast -• Rank Math -• All in One SEO -Requirements: -• Proper use of
,
,