Files
igny8/docs/planning/Igny8-phase-2-plan.md
IGNY8 VPS (Salman) 76a363b3d5 Organize planning documents and update README structure
- Created a new `docs/planning/` directory to better organize architecture and implementation planning documents.
- Moved existing planning documents into the new directory for improved accessibility.
- Updated `README.md` to reflect the new document structure and added references to the organized planning documents.
- Enhanced overall documentation management for easier navigation and maintenance.
2025-11-16 17:41:30 +00:00

47 KiB
Raw Permalink Blame History

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 IGNY8s 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

  1. 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

  1. CORE FEATURES
  2. Wizard Interface
  3. AI-Generated Site Structure
  4. Page Templates + Blocks
  5. Preview Renderer
  6. Site Settings Management
  7. Deploy to “IGNY8 Sites”
  8. Regeneration per section or page
  9. Full integration with Planner/Writer/Image modules
  10. Multi-tenant and multi-site support

  1. 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

  1. 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
  2. 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
  3. PageBlueprint Stores individual page definitions. • site_blueprint • slug • type (home, about, blog-index, post, ecommerce, etc.) • blocks_json • status
  4. 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.

  1. 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 modules image prompt extraction. Phase 4: Deploy Uploads: • JSON site definition • assets • images To IGNY8 Sites container.

  1. 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

  1. DEPLOYMENT TO IGNY8 SITES Builder → Backend → Sites container Steps:
  2. Builder sends POST /deploy/
  3. Backend converts blueprints → renderer schema
  4. Backend uploads files to: o /igny8-sites/clients/{site-id}/v{version}/
  5. Sites container builds static output (if needed)
  6. Caddy routes: o clientdomain.com → site folder o mysite.stuys.com → site folder

  1. MULTI-TENANCY All builder blueprints must respect: • Tenant ID • Site ID • Permissions • Credit limits So that each user can generate unlimited sites without conflict.

  1. 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

  1. 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:
  2. Marketing Website (igny8.com)
  3. All Stuys/IGNY8-generated client sites
  4. Any public output via IGNY8 Site Builder It consolidates everything into one frontend container equal to: • Webflows published sites • Wixs live sites • Framers publishing engine • Vercels 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

  1. 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

  1. HIGH-LEVEL PIPELINE Builder → Backend Storage → IGNY8 Sites Renderer → Caddy Routing → Public Site Detailed steps:
  2. User builds site via IGNY8 Site Builder
  3. Backend stores: o SiteBlueprint o PageBlueprints o Images
  4. Backend transforms blueprint JSON → Renderer Schema
  5. Renderer receives versioned site folder:
  6. /clients/{site-id}/v1/
  7. site.json
    
  8. pages/
    
  9. images/
    
  10. assets/
    
  11. Caddy routes: o clientdomain.com → folder o mysite.igny8.com → folder o igny8.com → marketing folder

  1. 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


  1. 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: <Hero {...props} /> Blocks library: • Hero • Features • Services • Product grid • Stats • Testimonials • Blog list • Contact form • Footer

  1. 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.

  1. 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


  1. 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

  1. 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:
<script type="application/ld+json">...</script> ________________________________________ 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 IGNY8s 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 IGNY8s 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/


  1. Data Contract With IGNY8 WP Plugin The theme assumes the plugin has already:
  2. Created the post with: o Title o Full HTML content o Correct categories and tags o Featured image o Optional excerpt
  3. 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
  4. Assigned cluster category as WordPress category: o wp_set_post_terms($post_id, [$cluster_term_id], 'category')
  5. 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.

  1. 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:
  2. Hero section o Title o Meta (date, reading time, category) o Featured image
  3. Content body o Renders Gutenberg blocks as generated by IGNY8 o Uses a content wrapper with a class like .igny8-article-content
  4. In article elements o Styles for:  Images and captions  Blockquotes  Tables  Lists  FAQ sections  Comparison elements
  5. 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:
  6. Cluster hero o Cluster name o Intro text (manual or IGNY8 generated) o Primary keyword
  7. 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
  8. 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.

  1. Block Patterns and Styles To match IGNY8 generated content, create patterns that correspond to how the app structures text. 6.1 Core patterns
  2. hero-featured.php o Featured image o Large title o Subtitle o CTA button
  3. longform-article.php o Pre configured layout:  Article header  Table of contents  Main content area  Related posts / CTAs
  4. cluster-hub-layout.php o Cluster summary text block o Supporting post list blocks o Internal links to key posts
  5. faq-section.php o Repeated question answer blocks o FAQ heading o Schema ready markup friendly structure
  6. comparison-table.php o Table styled to match IGNY8 comparison posts
  7. product-feature-list.php o Short bullet feature list o Icons or checkmarks
  8. 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

  1. 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

  1. 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
    , , , • Clean heading hierarchy • No duplicate title tags • No intrusive inline scripts in content • Support for lazy loading images • Valid HTML for schema aware content (FAQ, reviews, products)

  1. Integration Points With IGNY8 App and Plugin
  2. Categories and clusters o Theme surfaces clusters visually o Plugin assigns cluster category values o IGNY8 App knows cluster names and taxonomies
  3. Primary and secondary keyword meta o Theme can optionally show primary keyword in a subtle way o Or use it for internal navigation
  4. Task and content ids o Not shown publicly, but the theme should not interfere with them
  5. Shortcodes or block hooks (future) o Theme can define specific areas where IGNY8 plugin may inject extra components later, such as:  Related articles injected via shortcode  Internal link widgets  CTA blocks

  1. Execution Phases Phase 0: Bootstrapping • Create theme skeleton with: o style.css o functions.php o theme.json o templates/index.html o parts/header.html, parts/footer.html • Verify it appears and works as a basic block theme in a WP instance. Phase 1: Single Post and Page • Implement single.html, page.html • Add content wrapper with good typography • Style core Gutenberg blocks used by IGNY8 content Phase 2: Cluster and Category • Add category.html • Add category-cluster.html and logic to use it • Build cluster hub layout and related posts area Phase 3: Patterns • Implement primary block patterns matching IGNY8 typical structures • Test them with IGNY8 generated content from real Writer tasks Phase 4: Marketing Consistency • Align colors, typography, and sections with: o IGNY8 Sites renderer design o IGNY8 App general brand design This way, WP based sites and IGNY8 Sites hosted sites feel like the same ecosystem. Phase 5: Performance and Edge Cases • Test with: o Very long articles o Manual posts not from IGNY8 o No featured image o Multiple categories and tags Ensure theme degrades gracefully when IGNY8 metadata is absent.

  1. What This Theme Achieves
  2. Creates a consistent, SEO friendly visual layer for IGNY8 generated content inside WordPress.
  3. Understands the structures and metadata produced by IGNY8 App and plugin.
  4. Does not introduce logic beyond display.
  5. Keeps WordPress users free to manually edit and extend content.
  6. Provides a bridge where the same content strategy patterns from IGNY8 App appear in the frontend layout. IGNY8 OPTIMIZER & LINKER Full Implementation Document Module 5 of 5 Container: IGNY8 App Backend + Celery Workers Frontend: IGNY8 App (React, new modules under /modules/optimizer + /modules/linker) Pipeline Position: After Writer → Before Publish → Before Deployment / Sync

  1. PURPOSE & ROLE IN IGNY8 ECOSYSTEM After IGNY8 Writer generates: • Blog posts • Cluster hub pages • Product pages • Service pages • Taxonomy term pages (category, tag, product_cat, product_attribute) the Optimizer and Linker perform the final SEO refinement and internal linking needed for production-grade output. They operate inside IGNY8 App, not WordPress. WordPress is just a destination after optimization. ORDER: Planner → Writer → Linker → Optimizer → Publish (WP or IGNY8 Sites)

  1. LINKER MODULE Purpose: Build a complete, contextual, semantic interlinking system across all content types. 2.1 LINKING TARGETS Linker can interlink: Content Type Link Direction Blog posts same cluster, cross cluster, upstream, downstream, siblings Cluster hub pages link to supporting posts, cross-cluster hubs Product pages related products, buying guides, blog posts Service pages blog posts, hubs, products Taxonomy term pages category pages, tag pages, product categories, product attributes Link sources → Link targets:
  2. Same cluster (default)
  3. Sibling clusters (brother level)
  4. Cross cluster (if option enabled)
  5. Upstream (cluster hub → support posts)
  6. Downstream (support posts → cluster hub)
  7. Equivalent products (mapped in categories/attributes)
  8. Related taxonomy (tags, product categories)

2.2 LINKER BACKEND LOGIC A. Data source: Unified Content Index Stored in new Django model: LinkableContent

  • id
  • type (post, hub, product, taxonomy)
  • title
  • slug
  • url
  • cluster_id
  • keywords []
  • tags []
  • taxonomy_ids [] This index is built from: • IGNY8 App generated content • WordPress full site sync (via plugin) • IGNY8 Sites renderer site definitions B. Linking Rules Engine Linker uses multiple matching rules:
  1. Cluster-based: content.cluster_id == target.cluster_id
  2. Tag-based: Overlapping tags between source and target.
  3. Keyword-based: Primary keyword or secondary keywords overlap.
  4. Taxonomy-based: Product category, product attribute, blog tag.
  5. Semantic match: Optional AI-based anchor and sentence suggestion.
  6. Cross cluster: Allowed only if: o both clusters belong to same sector OR o target is a “parent” or “sibling” cluster C. Types of Links Injected Linker injects link types: • Inline contextual anchor links • “Read next” block • “Related articles” block • “Products related to this article” blocks • “More from this cluster” • “Explore more categories” (taxonomy-based) D. Injection Specification All links must generate Gutenberg friendly HTML:

... keyword phrase ...

or block format:

Related Articles

________________________________________ 2.3 LINKER WORKFLOW IN IGNY8 APP Step 1: Pick content • Blog • Hub • Product • Page • Taxonomy Step 2: Linker loads candidates via: GET /api/v1/linker/candidates/?content_id=xxx Step 3: AI determines: • Which links to insert • Anchor text • Link positions • Cross cluster logic Step 4: Link Injection AI returns: • Injected HTML • Link list • Anchor map • Link graph Stored in DB: internal_links: - source_id - target_id - anchor - position Step 5: Pass to Optimizer (next module) ________________________________________ 3. OPTIMIZER MODULE Purpose: Improve SEO, clarity, length, structure, and ranking potential of the content. It includes: • Rewrite • Length expansion • Keyword targeting • Editing for tone • Grammar + clarity • Meta optimization • Structure optimization (headings, flow) Optimizer works on: Type Examples Blog posts supporting and cluster hubs Product pages descriptions, benefits, FAQ Service pages local SEO pages Static pages about/contact Taxonomy term pages category descriptions, product categories ________________________________________ 3.1 OPTIMIZER TASK TYPES A. Keyword-focused optimization • Aligns content with chosen primary keyword • Adjusts headings and paragraph relevance B. Cluster alignment • Ensures cluster hub structure follows IGNY8 style • Updates intro, TOC, internal link placement C. Length optimization • Expand to required word count • Add missing sections • Improve detail in weak areas D. Tone/style correction • Make content more authoritative • Less robotic • Smooth transitions • Improve flow between headings E. Metadata correction • Optimize title • Improve meta description • Add missing alt text • Fix broken headings • Validate structure ________________________________________ 3.2 OPTIMIZER BACKEND LOGIC Tracks all optimization tasks: OptimizationTask - content_id - type (keyword, structure, rewrite, length) - target_keyword - cluster_id - request_payload - ai_output - html_before - html_after - diff - score_before - score_after A. Analyzer Phase Before rewriting, optimizer runs: 1. Readability score 2. Structure score 3. SEO score 4. Keyword density 5. Header hierarchy 6. Link structure 7. Semantic coverage B. Rewrite Phase AI performs: • Rewrite paragraphs • Upgrade headings • Add missing semantic depth • Insert inline enhancements • Add FAQs or missing blocks C. Post-Processing Phase • Convert AI text into clean HTML • Validate Gutenberg blocks • Ensure no invalid markup • Remove duplicates • Clean anchor links (no broken URLs) ________________________________________ 3.3 OPTIMIZER WORKFLOW IN IGNY8 APP Step 1: Select task • Rewriting • Keyword optimization • Cluster alignment • Length extension • Meta optimization Step 2: Analyzer runs Returns: • Before/After score • Suggestions list • Weaknesses Step 3: AI rewrite Injects: • Optimized HTML • Updated metadata • Optimized headings • Improved readability • More logical flow Step 4: Store and compare Frontend shows: • diff • score improvement • SEO checklist Step 5: Approve & publish Push to: • WP (via plugin) • IGNY8 Sites container ________________________________________ 4. FRONTEND UI MODULE (IN IGNY8 APP) New folders: /frontend/src/modules/linker/ /frontend/src/modules/optimizer/ Linker UI • List of suggested links • Toggle link inclusion • Preview injected HTML • Graph view (optional) Optimizer UI • Analyzer report (scores, flags) • Optimization type selection • Side-by-side before/after compare • Diff viewer • Metadata editor • Publish button ________________________________________ 5. INTEGRATION WITH WRITER MODULE Linker & Optimizer appear after Writer: Writer → Linker → Optimizer → Publish Writer sends: • content_id • cluster_id • keywords • HTML content Linker updates: • html_with_links • internal_links[] Optimizer updates: • html_optimized • metadata_optimized Both update the igny8_content record. Finally: Publish system reads optimized output Publishes to: • WordPress (via plugin) • IGNY8 Sites (renderer) ________________________________________ 6. API ENDPOINTS (Backend) Base routes: /api/v1/linker/ /api/v1/optimizer/ Linker POST /linker/run/ GET /linker/candidates/ GET /linker/history/{id}/ Optimizer POST /optimizer/analyze/ POST /optimizer/optimize/ GET /optimizer/task/{id}/ ________________________________________ 7. DATA FLOW SUMMARY Writer Output ↓ Linker - Interlink content using cluster/tags/keywords/taxonomy - Inject Gutenberg HTML ↓ Optimizer - Rewrite or enhance content - Improve metadata - Extend length if needed ↓ Publish - WordPress - IGNY8 Sites renderer ________________________________________ 8. EXECUTION PHASES Phase 1 • Django models for Linker + Optimizer • API endpoints • Basic UI scaffolding Phase 2 • Analyzer engine • Link candidate engine • Block-safe HTML injector Phase 3 • Full AI rewrite integration • Diff engine • Scoring system Phase 4 • Publish integration • WordPress metadata sync • IGNY8 Sites renderer integration ________________________________________ 9. What Linker & Optimizer Achieve Linker: • Creates semantic internal link networks • Improves SEO structure automatically • Works across blogs, hubs, products, taxonomies • Understands clusters and cross-cluster relations Optimizer: • Produces editorial-quality rewritten content • Ensures SEO + readability + metadata are correct • Works on all content types including taxonomy pages • Maintains perfect block-structure compatibility Together they complete IGNY8s end-to-end AI SEO OS pipeline. NEW MODULE: IGNY8 Universal Content Types Layer This expands the core content pipeline beyond blog posts and pages. 1. WHATS MISSING TODAY Your current architecture handles: Type Status Blog posts ✔ Supported Cluster hub (page) ✔ Supported Static pages ✔ Supported But missing: Type Status Needs Product pages Missing AI generation, SEO optimizer, link insertion Product categories Missing Cluster-style hub logic Product tags Missing Similar to category/tag archives Product attributes Missing Archive/landing page logic Company service pages Missing Content + SEO + audit Taxonomy term pages Missing Blog category, tag, custom taxonomy pages Without this, IGNY8 cannot fully power e-commerce stores or company websites. Now we build a unified content model that supports EVERYTHING. ________________________________________ 2. NEW "CONTENT TYPE FRAMEWORK" INSIDE IGNY8 APP We introduce a new model: ContentEntity ContentEntity - id - type (post, page, product, product_cat, product_tag, product_attr, service_page, taxonomy_term) - source (igny8, wordpress, builder) - title - slug - html - json_blocks - keywords - cluster_id - taxonomy_id - seo_meta {} - images [] - external_post_id (for WP sync) - parent_id (for hierarchy) - sector_id - created_at - updated_at This becomes the backbone for: • Writer • Linker • Optimizer • Publisher • WP sync • IGNY8 Sites deployer ________________________________________ 3. HOW EACH TYPE IS HANDLED ✔ 3.1 PRODUCT PAGE What is needed: • Title generation • Feature list • Product benefits • Comparison block • FAQs • SEO meta • Longform editorial section • Image prompts (35 images) • Pricing logic (optional) AI Flow: Writer generates: • Product description • Technical spec explanation • Benefits • Cross-linkable sections • Images (DALL·E/Hidream) Linker: • Related products • Buying guides • Product categories • Blog posts Optimizer: • Improve SEO • Match keywords • Rewrite or expand as needed ________________________________________ ✔ 3.2 PRODUCT CATEGORY Treat product category like a cluster hub. AI Flow: • Category overview • Key benefits • Product list explanation • Filters (attributes) • SEO meta • Internal links to: o Products o Related categories o Buying guides (blog posts) ________________________________________ ✔ 3.3 PRODUCT TAG PAGE (Tags like “Memory Foam”, “Kids Mattress”, “Eco-Friendly”) AI Flow: • Tag meaning • Use cases • Tag → product mapping • Related tags • Related clusters ________________________________________ ✔ 3.4 PRODUCT ATTRIBUTE PAGE (E.g., “Color: Blue”, “Firmness: Medium”, “Material: Latex”) AI Flow: • Attribute explanation • Benefits • Attribute-specific buying advice • Best products list • Internal linking ________________________________________ ✔ 3.5 COMPANY SERVICE PAGE (Service: “Window Installation”, “SEO Services”, etc.) AI Flow: • Service overview • Process • Benefits • Why choose you • Testimonials (optional) • FAQs • SEO meta • City/area-specific variants (Phase 2) ________________________________________ ✔ 3.6 TAXONOMY TERM PAGE (Blog Category, Tag) AI Flow: • Category/Tag introduction • Topic summary • Importance • Internal links to blog posts • Related terms • SEO optimization sections ________________________________________ 4. PIPELINE INTEGRATION All new content types must be included in: Planner Planner creates: • Keywords & clusters for products • Keywords for service pages • Keywords for product categories Writer Writer receives: • content_type in task: o product o product_category o product_tag o product_attribute o service_page o taxonomy_term Writer selects the correct prompt automatically. Linker Linker receives: • source_type • Finds targets using: o attributes o tags o categories o cluster o cross-cluster o siblings o parent/child Optimizer Optimizer rewrites based on: • Keyword • Cluster • Length • SEO • Content type rules Publisher Publisher knows: • Where to push: o WordPress → correct CPT or taxonomy description o IGNY8 Sites → correct page type ________________________________________ 5. DATABASE EXTENSION Three new tables: 1. igny8_content_entities Stores ALL content items ever created. 2. igny8_taxonomies Maps: • WordPress taxonomies • Product attributes • Product categories • Builder taxonomies 3. igny8_entity_relations Supports: • Interlink graph • Related products • Related posts • Parent/child mapping ________________________________________ 6. API ENDPOINTS (IGNY8 APP) POST /writer/content/entity/create/ Creates task for any content type. POST /writer/content/entity/generate/ Generates page/product/service/taxonomy content. POST /linker/entity/ Interlinks the new entity type. POST /optimizer/entity/ Optimizes the entity type. GET /content/entities/ Unified list for all content types. ________________________________________ 7. WP PLUGIN INTEGRATION The plugin must support creation/sync of: • Posts → post • Pages → page • Woo products → product • Product categories → product_cat • Product tags → product_tag • Product attributes → pa_* taxonomies • Blog categories → category • Blog tags → post_tag • Custom taxonomies → dynamic sync Plugin sends taxonomy structure to IGNY8 App. Publisher pushes correct updates back: • For product pages → WP product update • For taxonomy pages → update term description ________________________________________ 8. WHY THIS MATTERS This converts IGNY8 from a blog-only generator into a universal content engine used for: • SEO agencies • E-commerce stores • Local service businesses • Multi-niche affiliate sites • Direct-to-consumer brands • Builders (Stuys) • Full websites under IGNY8 Sites container This aligns with your vision of: IGNY8 = Full AI SEO Operating System ________________________________________ 9. EXECUTION PHASE ORDER This is how to build it step-by-step. Phase 1 Foundation • Add ContentEntity model • Add taxonomies model • Extend Planner to support non-post types • Extend Writer task schema Phase 2 Writer Upgrade • Product content prompts • Service page prompts • taxonomy prompts (category/tag/product taxonomy) • Map to existing AI pipeline Phase 3 Linker Upgrade • Rewrite Linker rules to support all content types • Add taxonomy-based linking • Add product attribute linking • Add cross-type linking logic Phase 4 Optimizer Upgrade • Rewrite rules per content type • Add SEO scoring for product, category, service pages Phase 5 Publisher Upgrade • Extend WP publishing logic • Extend IGNY8 Sites renderer mapping • Support term description updates Phase 6 UI/UX • Add unified content list • Add entity type filters • Add per-entity optimization • Add per-entity linking panel ________________________________________ 10. FINAL RESULT IGNY8 will be able to automatically: • Generate product pages • Generate product category/tag/attribute pages • Generate service pages • Generate taxonomy term pages • Optimize them • Interlink them • Publish them to WordPress or IGNY8 Sites • Maintain internal link graph • Maintain SEO structure • Handle content for any type of website This completes the missing 40 percent of functionality required for a true platform-level AI SEO engine.