✅ 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
,
,