temproary docs uplaoded

2026-03-23 09:02:49 +00:00
parent cb6eca4483
commit 128b186865
113 changed files with 68897 additions and 0 deletions
--- a/v2/V2-Execution-Docs/00-MASTER-EXECUTION-PLAN.md
+++ b/v2/V2-Execution-Docs/00-MASTER-EXECUTION-PLAN.md
@@ -0,0 +1,195 @@
+# IGNY8 V2 — Master Execution Plan
+
+**Version:** 1.0 | March 23, 2026
+**Status:** Active — Execution Reference
+**Author:** Salman (Alorig Systems) + Claude Opus
+**Execution Tool:** Claude Code (SSH to VPS)
+
+---
+
+## 1. What This Is
+
+This is the single master document governing the complete IGNY8 V2 build — from infrastructure migration through SAG engine, all modules, WordPress ecosystem, business layer, and multi-app deployment. Every sub-phase references a dedicated build doc in this folder that Claude Code can pick up and execute independently.
+
+## 2. Current State (Confirmed March 23, 2026)
+
+**IGNY8 v1.8.4** is healthy and functionally production-ready.
+
+| Area | Status |
+|------|--------|
+| Settings save (content, publishing, profile) | ✅ Working |
+| Password change | ✅ Working |
+| Payments (Stripe/PayPal live, credits) | ✅ Working |
+| Publishing flow (IGNY8 → WordPress) | ✅ Working |
+| Security (Jan 2026 audit items) | ✅ Fixed |
+| API Activity tracking | ⚠️ Placeholder data — only open item |
+| `/system/ping/` & `/system/sites/{id}/status/` | Backend exists, frontend removed — wire when needed |
+| `/writer/tasks/{id}/brief/` | No current use case — v2 scope |
+| Taxonomy sync, Linker/Optimizer, webhooks | Correctly scoped as v2 features, not bugs |
+
+**Conclusion:** Phase 0 is pure migration. No bug-fixing sprint needed. Current environment stays untouched — all new work on new server with zero downtime.
+
+## 3. Architecture Overview
+
+**Current:** Single VPS, dev environment running as production, 14 Docker containers (6 unnecessary), Gitea self-hosted, no staging.
+
+**Target:** New Hostinger KVM 4 (4 vCPU, 16GB RAM, 200GB NVMe), shared Alorig infrastructure, production + staging environments, GitHub for all repos, Cloudflare DNS, self-hosted AI on Vast.ai GPU.
+
+**IGNY8 v2 Transformation:** From keyword-driven content generator → structure-first SAG-powered site architecture engine. Attributes first, not keywords first. Keywords emerge from attribute intersections across 45 industries, 449 sectors.
+
+## 4. Technology Stack
+
+| Layer | Current (v1.8.4) | V2 Addition |
+|-------|-------------------|-------------|
+| Backend | Django 5.1, DRF, PostgreSQL, Redis, Celery | SAG models, new module APIs |
+| Frontend | React 19, TypeScript, Zustand, Tailwind | Blueprint UI, wizard, dashboards |
+| AI (Cloud) | OpenAI GPT/DALL-E, Anthropic Claude, ElevenLabs | — |
+| AI (Self-hosted) | — | Qwen3 (text), FLUX/SD (images), Wan 2.1 (video) via Vast.ai |
+| WordPress | Bridge plugin v1.3.3 | Plugin v2 (14 modules), Companion Theme, Toolkit |
+| Infrastructure | Single VPS, Gitea, no staging | KVM 4 + Vast.ai GPU, GitHub, Cloudflare, prod + staging |
+| DevOps | Manual | Claude Code via SSH |
+
+## 5. Complete Execution Map
+
+### Phase 0 — Infrastructure & Migration
+*Goal: Healthy IGNY8 running on new server with staging, all repos on GitHub, legacy killed.*
+
+| Sub | Doc | What | Depends On |
+|-----|-----|------|------------|
+| 0A | `00A-github-repo-consolidation.md` | All repos → 1 GitHub account, linked to Source-Codes/, remove Gitea | — |
+| 0B | `00B-vps-provisioning.md` | New KVM 4, Cloudflare DNS, shared Docker infra (PG/Redis/Caddy/Portainer) | 0A |
+| 0C | `00C-igny8-production-migration.md` | pg_dump → new server, Docker Compose, DNS cutover, zero downtime | 0B |
+| 0D | `00D-staging-environment.md` | Identical 3-container staging, separate DB + Redis prefix | 0C |
+| 0E | `00E-legacy-cleanup.md` | Kill Gitea + 5 containers (frontend-dev, marketing, pgadmin, filebrowser, setup-helper), ~1.5GB freed | 0C |
+| 0F | `00F-self-hosted-ai-infra.md` | Vast.ai GPU (2×RTX 3090) + SSH tunnel + LiteLLM + Ollama/Qwen3 + ComfyUI | 0B |
+
+### Phase 1 — SAG Core Engine
+*Goal: IGNY8 generates full site architectures from industry/sector selection (Case 2) and reverse-engineers existing sites (Case 1).*
+
+| Sub | Doc | What | Depends On |
+|-----|-----|------|------------|
+| 1A | `01A-sag-data-foundation.md` | SAGBlueprint, SAGAttribute, SAGCluster, SectorAttributeTemplate — models + CRUD APIs | 0D |
+| 1B | `01B-sector-attribute-templates.md` | Template loading, multi-sector merge, AI generation for 45 industries/449 sectors | 1A |
+| 1C | `01C-cluster-formation-keyword-engine.md` | AI attribute intersection → clusters, type classification (7 types), 300-500+ keywords/site | 1B |
+| 1D | `01D-setup-wizard-case2-new-site.md` | Wizard Step 3 (Site Structure), attribute review UI, blueprint preview, quick/detailed mode | 1C |
+| 1E | `01E-blueprint-aware-pipeline.md` | Stage 0 (blueprint check), type-specific prompts, auto taxonomy assignment, priority ordering | 1D |
+| 1F | `01F-existing-site-analysis-case1.md` | Plugin site crawl, AI attribute extraction, gap analysis, user confirmation, auto-tagging | 1E |
+| 1G | `01G-sag-health-monitoring.md` | Health score (0-100), weekly Celery automation, blueprint evolution triggers, dashboard widget | 1F |
+
+### Phase 2 — Module Builds
+*Goal: All IGNY8 modules operational — content types, GSC, linking (internal + external), optimization, schema, social, video.*
+
+| Sub | Doc | What | Depends On |
+|-----|-----|------|------------|
+| 2A | `02A-content-types-extension.md` | Pages, products, services, company, comparison, brand pages — each with own presets + prompts | 1E |
+| 2B | `02B-taxonomy-term-content.md` | Term landing pages as first-class SEO pages, cluster mapping, rich content generation | 2A |
+| 2C | `02C-gsc-integration.md` | OAuth, URL Inspection API (2K/day), auto-indexing, re-inspection schedule, search analytics, plugin sync | 1A *(parallel)* |
+| 2D | `02D-linker-internal.md` | 7 link types, scoring algorithm (5 factors), anchor strategy, density rules, audit + new content mode | 1G |
+| 2E | `02E-linker-external-backlinks.md` | FatGrid API, PRNews.io, Linking News, EIN, campaign gen from blueprints, T1-T5 tiers, tipping point detection | 2D + 2C |
+| 2F | `02F-optimizer.md` | Cluster-aligned rewriting, keyword coverage, heading restructure, schema gaps, before/after scoring, batch | 2B |
+| 2G | `02G-rich-schema-serp.md` | 10 JSON-LD types, on-page elements (TL;DR, TOC, tables, definitions, PAA), retroactive enhancement engine | 2A |
+| 2H | `02H-socializer.md` | Native Django, 5 platforms (LinkedIn/Twitter/FB/IG/TikTok), OAuth, platform-specific adaptation, Stage 8, credits | 1E |
+| 2I | `02I-video-creator.md` | Script gen from articles, TTS (cloud + self-hosted), FFmpeg composition, auto-subtitles, Stage 9 | 2H + 0F |
+
+### Phase 3 — WordPress Ecosystem
+*Goal: Complete WordPress product suite — standalone SEO plugin, connected premium mode, SAG-optimized theme, toolkit.*
+
+| Sub | Doc | What | Depends On |
+|-----|-----|------|------------|
+| 3A | `03A-wp-plugin-standalone.md` | 10 modules: SEO meta, schema, sitemap, redirects, intelligence, linker, socializer, analytics, SMTP, import | 2D + 2G |
+| 3B | `03B-wp-plugin-connected.md` | API client, content sync, blueprint sync, taxonomy creation, cluster manager, structure visualization | 3A + 1G |
+| 3C | `03C-companion-theme.md` | 7 CPTs, 9 taxonomies, term landing pages, cluster hub templates, 15 section types, 50+ block patterns, 5 site-type starters | 3B |
+| 3D | `03D-toolkit-plugin.md` | Performance (cache, critical CSS, image optimization), forms, security (firewall, hardening), SMTP, WooCommerce enhancements | 3C |
+
+### Phase 4 — Business Layer
+*Goal: Monetization infrastructure — managed services, agency tools, pricing aligned to feature releases.*
+
+| Sub | Doc | What | Depends On |
+|-----|-----|------|------------|
+| 4A | `04A-managed-services.md` | Lite ($100/site/mo), Pro ($399/site/mo), backlink packages ($800-$8K/mo), client onboarding automation | 2E + 3B |
+| 4B | `04B-whitelabel-reporting.md` | Agency dashboards, branded reports, white-label via Linking News | 4A |
+| 4C | `04C-pricing-launch.md` | Plan pricing increase, WordPress.org plugin submission, go-to-market | 4B |
+
+### Phase 5 — Multi-App Deployment
+*Goal: Remaining 6 apps deployed on shared infrastructure, one at a time, monitoring RAM after each.*
+
+| Sub | Doc | What | Depends On |
+|-----|-----|------|------------|
+| 5 | `05-other-apps-deployment.md` | Psydge → Snapify → Site Builder → Observer OS → AstroTiming → ASMS | Phase 4 complete |
+
+### Reference Documents (Appendices — not build docs)
+
+| Doc | What | Source |
+|-----|------|--------|
+| `REF-sag-methodology.md` | Pure SAG theory, dimensional framework, clustering rules | SAG-Master-Document.md |
+| `REF-industry-sector-list.md` | 45 industries, 449 sectors, validation criteria | IGNY8-Industry-Sector-Master-List.md |
+| `REF-niche-definition-process.md` | Template generation quality reference, hard constraints | SAG-Niche-Definition-Process.docx |
+| `REF-current-state-v1.8.4.md` | Frozen baseline snapshot of v1.8.4 | IGNY8-Current-State.md + Platform Features docx |
+| `SAGIndustry01HealthcareMedical.xlsx` | Healthcare SAG Excel template (formatting reference) | As-is |
+
+## 6. Doc Structure Standard
+
+Every build doc (00A through 05) follows this structure:
+
+```
+# [Phase.Sub] — Title
+## 1. Current State
+   What exists today relevant to this sub-phase.
+## 2. What to Build
+   Complete scope with acceptance criteria.
+## 3. Data Models & APIs
+   New/modified models, endpoints, serializers.
+## 4. Implementation Steps
+   Ordered steps Claude Code executes.
+## 5. Dependencies & Cross-References
+   Which other docs this reads from or feeds into.
+## 6. Acceptance Criteria
+   How to verify this sub-phase is complete.
+## 7. Claude Code Instructions
+   Specific commands, file paths, test procedures.
+```
+
+Each doc is self-contained. Claude Code picks up one doc, reads it, executes it, verifies it — without needing to read the entire plan.
+
+## 7. Source Doc Consolidation
+
+After all V2-Execution-Docs are built, the following source locations get archived to `Igny8/Archive/`:
+
+| Source Location | What's There | Action |
+|-----------------|-------------|--------|
+| `temp/IGNY8-Project-Files/` | All planning docs (duplicates) | Archive entire folder |
+| `Igny8 V2 New Final Plans/` | SAG docs, plugin/theme plans, schema, linker, AI infra | Archive entire folder |
+| `Live Docs on Server/igny8-app-docs/plans/` | Future module plans, dev guides, GSC, socializer | Archive plans/ subfolder only |
+| `Live Docs on Server/igny8-wp-plugin-docs/` | Fix logs, audits, implementation plans | Keep as historical reference |
+| `IGNY8-Complete-Platform-Features.docx` | Current feature inventory | Absorbed into REF-current-state, archive original |
+| `Old plans November/` | Superseded plans | Already archived, no action |
+
+**Live Docs operational folders stay untouched:** 00-SYSTEM, 10-MODULES, 20-API, 30-FRONTEND, 40-WORKFLOWS, 50-DEPLOYMENT, 60-PLUGINS, 90-REFERENCE, audits.
+
+## 8. Key Principles
+
+1. **Nothing working breaks** — nullable fields, feature flags, staging first
+2. **SAG is attribute-first** — keywords are output, not input
+3. **Same container pattern everywhere** — backend + celery_worker + celery_beat
+4. **Current environment never touched** — all new work on new server
+5. **All development via Claude Code** — SSH to VPS, timelines compressed vs manual dev
+6. **Each doc is self-contained** — Claude Code executes one doc at a time without losing context
+7. **Monitor real usage** — upgrade decisions are data-driven, not speculative
+
+## 9. Timeline Estimate (Claude Code Execution)
+
+| Phase | Scope | Estimated Duration |
+|-------|-------|-------------------|
+| 0 | Infrastructure & Migration | 3-5 days |
+| 1 | SAG Core Engine (7 sub-phases) | 2-3 weeks |
+| 2 | Module Builds (9 modules) | 4-5 weeks |
+| 3 | WordPress Ecosystem (4 products) | 3-4 weeks |
+| 4 | Business Layer | 1 week |
+| 5 | Other Apps | Ongoing, post-IGNY8 |
+| **Total (Phase 0-4)** | **IGNY8 complete** | **~8-12 weeks** |
+
+*Timelines assume focused execution without context-switching to client work.*
+
+---
+
+*This document is the single source of truth for IGNY8 V2 execution. All 34 sub-phase docs in this folder implement the plan defined here.*
--- a/v2/V2-Execution-Docs/00A-github-repo-consolidation.md
+++ b/v2/V2-Execution-Docs/00A-github-repo-consolidation.md
--- a/v2/V2-Execution-Docs/00B-vps-provisioning.md
+++ b/v2/V2-Execution-Docs/00B-vps-provisioning.md
--- a/v2/V2-Execution-Docs/00C-igny8-production-migration.md
+++ b/v2/V2-Execution-Docs/00C-igny8-production-migration.md
@@ -0,0 +1,916 @@
+# IGNY8 Phase 0: Production Migration (00C)
+
+**Document ID:** 00C-igny8-production-migration
+**Phase:** Phase 0: Production Migration
+**Version:** 2.0
+**Date:** 2026-03-23
+**Status:** In Progress
+
+**Related Docs:**
+- 00A: GitHub Repository Consolidation (completed)
+- 00B: New VPS Infrastructure Setup (completed — new VPS provisioned with test subdomains)
+- 00D: Staging Environment Setup (follows this doc)
+- 00E: Old VPS Cleanup & Decommission (follows)
+
+---
+
+## 1. Current State
+
+### 1.1 Running System (Old VPS)
+
+**Version:** IGNY8 v1.8.4
+**Runtime:** Docker Compose with production compose file
+**Project Name:** igny8-app
+**Compose File:** docker-compose.app.yml
+
+#### Active Containers
+| Container | Service | Port (Internal) | Technology |
+|-----------|---------|----------------|------------|
+| igny8_backend | REST API | 8010 | Django 4.2 + Gunicorn (4 workers, 120s timeout) |
+| igny8_frontend | Web UI | 5173 → 8021 | Vite dev server |
+| igny8_celery_worker | Task worker | N/A | Celery |
+| igny8_celery_beat | Task scheduler | N/A | Celery Beat |
+| igny8_postgres | Database | 5432 | PostgreSQL 16 |
+| igny8_redis | Cache/Broker | 6379 | Redis 7 (DB 0) |
+| caddy | Reverse proxy/SSL | 80, 443 | Caddy 2 |
+| marketing | Render service | 8023 | Custom service |
+| sites | Render service | 8024 | Custom service |
+
+#### Database
+- **Database Name:** igny8_db
+- **User:** igny8
+- **Engine:** PostgreSQL 16
+- **Backup Location:** /data/app/igny8/scripts/ops/
+- **Backup Scripts:** backup-db.sh, backup-full.sh
+
+#### Storage & Volumes
+| Volume | Mount Path | Content |
+|--------|-----------|---------|
+| Backend Code | /data/app/igny8/backend | Django app source |
+| Shared Data | /data/app/igny8 | Media, plugins, static files |
+| Logs | /data/app/logs | Container logs |
+| Plugin ZIPs | /plugins/wordpress/source/igny8-wp-bridge/ | Distribution files |
+
+#### Environment Configuration
+**Source:** .env file on old VPS or Docker secrets
+**Key Variables:**
+- DATABASE_URL or (DB_HOST, DB_NAME, DB_USER, DB_PASSWORD)
+- REDIS_HOST, REDIS_PORT, REDIS_DB
+- SECRET_KEY, JWT_SECRET_KEY
+- CORS_ALLOWED_ORIGINS
+- CELERY_BROKER_URL
+- Django DEBUG, ALLOWED_HOSTS
+
+**Important:** AI integration keys stored in database (GlobalIntegrationSettings table), NOT in env vars.
+
+#### Networking
+- **Primary Domain:** app.igny8.com (frontend)
+- **API Domain:** api.igny8.com (backend)
+- **Marketing:** igny8.com
+- **DNS Provider:** Current registrar (NOT yet on Cloudflare)
+- **SSL:** Auto-renewed via Caddy
+
+#### Payments & Integrations
+- **Stripe:** Live mode active
+- **PayPal:** Live mode active
+- **WordPress Sync:** Via igny8-wp-bridge plugin
+- **Backup Automation:** Cron jobs on old VPS (backup-db.sh, backup-full.sh)
+
+#### Health Check
+- **Endpoint:** http://localhost:8010/api/v1/system/status/
+- **Expected Response:** 200 OK with system status JSON
+- **Frequency:** Manual or via monitoring
+
+---
+
+## 2. What to Build
+
+### 2.1 Migration Objectives
+
+Migrate IGNY8 v1.8.4 from old VPS to new VPS with **zero downtime** while maintaining:
+- All production data integrity
+- Continuous payment processing (Stripe/PayPal)
+- WordPress plugin distribution and sync
+- SSL/TLS without service interruption
+- Backup automation
+- Monitoring and logging
+
+### 2.2 Three-Stage Migration Strategy
+
+This migration is **not a direct cutover**. Instead, we run both VPS in parallel, test thoroughly via test subdomains, then flip DNS when fully healthy.
+
+#### **Stage 1: Deploy & Test on New VPS (via test subdomains)**
+
+**Prerequisite:** 00B has provisioned new VPS with infrastructure and created test subdomains.
+
+**What Happens:**
+- New VPS is fully operational with Docker, Caddy, PostgreSQL 18, Redis, etc.
+- Test subdomains (`test-app.igny8.com`, `test-api.igny8.com`) already point to NEW VPS IP at current DNS provider
+- Caddy on new VPS is configured to handle BOTH real domains AND test domains (same routing rules)
+- Clone app code from GitHub, restore database via pg_dump/pg_restore (PG16 → PG18), transfer media files
+- Deploy full Docker Compose stack on new VPS
+- **Test EVERYTHING via test subdomains:** user login, payments (Stripe/PayPal), WordPress sync, content creation, API endpoints, Celery tasks
+- Old VPS continues serving 100% of production traffic — **zero disruption to users**
+
+**Duration:** 1-2 days (or until fully confident all features work)
+
+**Rollback:** Simply disable test subdomains if critical issues found; old VPS unaffected.
+
+#### **Stage 2: DNS Flip to New VPS (at current DNS provider)**
+
+**Prerequisite:** New VPS is healthy and all tests passed via test subdomains.
+
+**What Happens:**
+1. Reduce TTL on real A records (`app.igny8.com`, `api.igny8.com`, `igny8.com`) to 60 seconds at current DNS provider
+2. Wait 2-4 hours for old TTL to expire (original TTL was typically 3600+)
+3. Change A records to point to NEW VPS IP
+4. Production traffic flows to new VPS
+5. Old VPS remains running as instant fallback
+6. Monitor for 24-48 hours for any issues
+7. Verify logs, error rates, payment processing, background jobs
+
+**Duration:** 24-48 hours monitoring after DNS flip
+
+**Rollback:** If anything breaks, flip A records back to old VPS IP instantly (TTL is now 60 seconds, so flip takes seconds to propagate). Old VPS was never shut down.
+
+#### **Stage 3: Cloudflare Onboarding (AFTER 24-48h stable on new VPS)**
+
+**Prerequisite:** Production traffic on new VPS is stable for 24-48 hours, error rates normal, payments flowing, logs clean.
+
+**Important:** This stage happens AFTER we're confident on the new VPS. Cloudflare is a *security enhancement*, not a migration requirement.
+
+**What Happens:**
+1. Transfer domain's nameservers from current registrar to Cloudflare
+2. Set up Cloudflare DNS zone with all A records pointing to new VPS IP
+3. Enable Cloudflare proxy (orange cloud) for DDoS protection and CDN
+4. Update Caddy to use Cloudflare DNS challenge for SSL:
+   - Install caddy-cloudflare module: `caddy download github.com/caddy-dns/cloudflare`
+   - Configure Caddyfile with `tls { dns cloudflare {...} }`
+   - OR keep Let's Encrypt HTTP challenge if Cloudflare is in Full (Strict) SSL mode
+5. Remove test subdomains (no longer needed; production is now on real domains)
+6. Configure Cloudflare settings:
+   - SSL/TLS Mode: Full (Strict)
+   - Always Use HTTPS: ON
+   - Auto Minify: JS, CSS, HTML
+   - Browser Cache TTL: 30 minutes
+   - Page Rules: any custom rules per requirements
+
+**Duration:** A few hours (nameserver propagation up to 24 hours, but functional sooner)
+
+**Rollback:** Nameserver rollback is slow (up to 24 hours propagation), so this stage is only done after confirmed stability.
+
+---
+
+## 3. Data Models & APIs
+
+### 3.1 Database Schema (PostgreSQL 16 → 18)
+
+The database schema itself does not change during migration. We use pg_dump and pg_restore to move the entire database from old VPS (PG 16) to new VPS (PG 18).
+
+**Key Tables (not exhaustive):**
+- `users` — User accounts
+- `projects` — Projects/sites
+- `stripe_subscriptions` — Payment records
+- `integration_settings` — AI integration keys (GlobalIntegrationSettings)
+- `wordpress_sync_logs` — Plugin sync history
+- `celery_*` — Celery task tables
+
+**Important:** Do NOT manually migrate tables. Use pg_dump/pg_restore with custom format.
+
+### 3.2 Health Check API
+
+**Endpoint:** `GET http://localhost:8010/api/v1/system/status/`
+**Expected Response:**
+```json
+{
+  "status": "ok",
+  "version": "1.8.4",
+  "database": "connected",
+  "redis": "connected",
+  "celery": "ok"
+}
+```
+
+Use this endpoint to verify both old and new VPS health before/after migration.
+
+---
+
+## 4. Implementation Steps
+
+### 4.1 Stage 1: Deploy & Test on New VPS (test subdomains)
+
+#### Prerequisites (from 00B)
+- ✅ New VPS provisioned with Docker, Caddy, PostgreSQL 18, Redis
+- ✅ Test subdomains (`test-app.igny8.com`, `test-api.igny8.com`) created at current DNS provider, pointing to new VPS IP
+- ✅ Caddy on new VPS configured to route both real and test domains to containers
+
+#### Step 1.1: Clone App Code from GitHub
+
+On new VPS:
+
+```bash
+ssh root@<new-vps-ip>
+
+cd /data/app/igny8
+
+# Clone the consolidated repo (from 00A)
+git clone https://github.com/yourusername/igny8-consolidated.git backend
+cd backend
+git checkout main  # or appropriate branch
+
+# Copy .env.example to .env and configure
+cp .env.example .env
+
+# Update .env for new VPS:
+# - DB_HOST=igny8_postgres (Docker internal hostname)
+# - DB_NAME=igny8_db
+# - DB_USER=igny8
+# - DB_PASSWORD=<secure password>
+# - REDIS_HOST=igny8_redis
+# - SECRET_KEY=<generate new>
+# - ALLOWED_HOSTS=test-app.igny8.com,test-api.igny8.com,app.igny8.com,api.igny8.com,igny8.com
+
+nano .env
+```
+
+#### Step 1.2: Backup Database on Old VPS & Transfer to New VPS
+
+On old VPS:
+
+```bash
+ssh root@<old-vps-ip>
+
+# Create database dump using custom format (required for major version upgrade)
+pg_dump --format=custom --file=/tmp/igny8_db_backup.dump -U igny8 igny8_db
+
+# Verify dump created
+ls -lh /tmp/igny8_db_backup.dump
+
+# Compress for transfer
+gzip /tmp/igny8_db_backup.dump
+```
+
+Transfer to new VPS:
+
+```bash
+# From your local machine or jump host
+scp root@<old-vps-ip>:/tmp/igny8_db_backup.dump.gz /tmp/
+
+# Transfer to new VPS
+scp /tmp/igny8_db_backup.dump.gz root@<new-vps-ip>:/tmp/
+
+# On new VPS, decompress
+ssh root@<new-vps-ip>
+cd /tmp
+gunzip igny8_db_backup.dump.gz
+```
+
+#### Step 1.3: Restore Database on New VPS (PG 18)
+
+On new VPS:
+
+```bash
+# Wait for PostgreSQL container to be healthy
+docker compose -f docker-compose.app.yml ps
+
+# Restore using pg_restore (PostgreSQL 18 handles version upgrade automatically)
+PGPASSWORD=<db-password> pg_restore --format=custom \
+  --host=localhost \
+  --port=5432 \
+  --username=igny8 \
+  --dbname=igny8_db \
+  /tmp/igny8_db_backup.dump
+
+# Verify restore completed
+PGPASSWORD=<db-password> psql --host=localhost --username=igny8 --dbname=igny8_db -c "SELECT COUNT(*) FROM users;"
+
+# Run ANALYZE on all tables to update statistics
+PGPASSWORD=<db-password> psql --host=localhost --username=igny8 --dbname=igny8_db -c "ANALYZE;"
+```
+
+#### Step 1.4: Transfer Media & Plugin Files
+
+On new VPS:
+
+```bash
+# Create target directories
+mkdir -p /data/app/igny8/media
+mkdir -p /plugins/wordpress/source
+
+# From old VPS, rsync media
+rsync -avz --delete root@<old-vps-ip>:/data/app/igny8/media/ /data/app/igny8/media/
+
+# Sync plugin files
+rsync -avz --delete root@<old-vps-ip>:/plugins/wordpress/source/igny8-wp-bridge/ /plugins/wordpress/source/igny8-wp-bridge/
+
+# Verify
+ls -la /data/app/igny8/media/
+ls -la /plugins/wordpress/source/igny8-wp-bridge/
+```
+
+#### Step 1.5: Deploy Docker Compose Stack on New VPS
+
+On new VPS:
+
+```bash
+cd /data/app/igny8
+
+# Copy docker-compose file (create if needed)
+# Ensure it contains:
+# - igny8_backend (Django)
+# - igny8_frontend (Vite)
+# - igny8_celery_worker
+# - igny8_celery_beat
+# - igny8_postgres (PostgreSQL 18)
+# - igny8_redis
+# - caddy
+# - marketing, sites (if needed)
+
+# Build and start
+docker compose -f docker-compose.app.yml build
+docker compose -f docker-compose.app.yml up -d
+
+# Wait for containers to stabilize (10-15 seconds)
+sleep 15
+
+# Verify all containers running
+docker compose -f docker-compose.app.yml ps
+```
+
+#### Step 1.6: Verify Caddy & SSL for Test Subdomains
+
+On new VPS:
+
+```bash
+# Check Caddy is running
+docker compose -f docker-compose.app.yml logs caddy | tail -50
+
+# Verify test subdomains resolve and serve content
+curl -I https://test-app.igny8.com
+curl -I https://test-api.igny8.com
+
+# Both should return 200 OK with valid SSL certificate
+```
+
+#### Step 1.7: Run Health Checks on Test Subdomains
+
+```bash
+# Health check via test API subdomain
+curl -H "Host: test-api.igny8.com" http://localhost:8010/api/v1/system/status/
+
+# Or if DNS is live
+curl https://test-api.igny8.com/api/v1/system/status/
+```
+
+**Expected Response:**
+```json
+{
+  "status": "ok",
+  "version": "1.8.4",
+  "database": "connected",
+  "redis": "connected",
+  "celery": "ok"
+}
+```
+
+#### Step 1.8: Manual Testing on Test Subdomains
+
+Test via `https://test-app.igny8.com`:
+
+- [ ] User login with test account
+- [ ] Create new project/site
+- [ ] View dashboard and analytics
+- [ ] Test Stripe payment flow (use test card: 4242 4242 4242 4242)
+- [ ] Test PayPal integration (sandbox mode)
+- [ ] Verify WordPress plugin can be downloaded from `test-api.igny8.com`
+- [ ] Verify WordPress sync works (if connected)
+- [ ] Check background job processing (Celery logs)
+- [ ] Verify media files upload and display correctly
+- [ ] Check email notifications send correctly
+- [ ] Verify AI integration keys are loaded from database
+
+#### Step 1.9: Monitor Logs for 24 Hours
+
+```bash
+# Watch backend logs
+docker compose -f docker-compose.app.yml logs -f igny8_backend
+
+# Watch Celery logs
+docker compose -f docker-compose.app.yml logs -f igny8_celery_worker
+
+# Watch Caddy/SSL logs
+docker compose -f docker-compose.app.yml logs -f caddy
+```
+
+**Look for:** Errors, warnings, slow queries, failed payment webhooks, SSL issues.
+
+#### Stage 1 Acceptance Criteria
+
+- ✅ Database restored with all tables and data intact (row counts match old VPS)
+- ✅ Media files present and accessible
+- ✅ Caddy SSL working for test subdomains with valid certificate
+- ✅ Health check returns 200 OK with all systems "connected"
+- ✅ User login works on test subdomains
+- ✅ Payment processing (Stripe/PayPal) functional on test subdomains
+- ✅ WordPress plugin distribution functional
+- ✅ Background jobs (Celery) processing successfully
+- ✅ No errors in application or Caddy logs over 24-hour monitoring period
+- ✅ Old VPS still serving 100% production traffic with zero impact
+
+#### Stage 1 Rollback
+
+If critical issues found on new VPS:
+
+```bash
+# Simply delete/disable test subdomains at DNS provider
+# (old VPS remains untouched)
+
+# Or if needed, bring down new VPS containers
+docker compose -f docker-compose.app.yml down
+
+# Old VPS continues serving production
+```
+
+---
+
+### 4.2 Stage 2: DNS Flip to New VPS (at current DNS provider)
+
+#### Prerequisites
+- ✅ Stage 1 testing complete; new VPS fully healthy
+- ✅ All manual acceptance criteria passed
+- ✅ 24+ hours of monitoring with no errors
+
+#### Step 2.1: Reduce TTL on Real A Records
+
+At current DNS provider (registrar panel or DNS management):
+
+1. Navigate to DNS records for igny8.com
+2. Find A records:
+   - `app.igny8.com` (currently points to old VPS IP)
+   - `api.igny8.com` (currently points to old VPS IP)
+   - `igny8.com` (currently points to old VPS IP)
+3. Set TTL to **60 seconds** (reduce from typical 3600)
+4. **Save changes**
+
+```bash
+# Verify TTL change via DNS lookup (run from local machine)
+# TTL should now be ~60 seconds
+nslookup app.igny8.com
+dig app.igny8.com
+
+# Check TTL value in output (usually shows in Answer section)
+```
+
+#### Step 2.2: Wait for TTL Expiration
+
+- **Set TTL:** time T=0
+- **Wait duration:** 2-4 hours (depending on previous TTL; being conservative)
+- **During this time:** Continue monitoring old and new VPS, ensure no errors
+
+#### Step 2.3: Flip A Records to New VPS IP
+
+At current DNS provider, change A records:
+
+- `app.igny8.com` → NEW VPS IP
+- `api.igny8.com` → NEW VPS IP
+- `igny8.com` → NEW VPS IP
+
+**Save changes immediately.**
+
+Verify DNS propagation:
+
+```bash
+# From local machine, verify new IP
+nslookup app.igny8.com
+# Should show NEW VPS IP within seconds to 2 minutes
+
+# From another machine (ISP DNS may cache differently)
+nslookup app.igny8.com
+```
+
+#### Step 2.4: Monitor Production for 24-48 Hours
+
+On new VPS:
+
+```bash
+# Watch all logs
+docker compose -f docker-compose.app.yml logs -f
+
+# Monitor error rates
+# - Check /data/app/logs/ for errors
+# - Monitor Stripe/PayPal webhook logs
+# - Check Celery task success rates
+# - Monitor database slow query log
+```
+
+**Metrics to watch:**
+- HTTP error rates (500, 502, 503, 504) — should remain <0.01%
+- Payment webhook latency — should be <500ms
+- Database connection pool — should not saturate
+- Redis memory usage — should be stable
+- Celery task failure rate — should remain 0%
+
+#### Step 2.5: Verify Old VPS Can Be Kept Running as Fallback
+
+Do NOT shut down old VPS yet. Keep it running as instant fallback for 48 hours.
+
+If critical issue discovered:
+
+```bash
+# On new VPS, pull logs to diagnose
+docker compose -f docker-compose.app.yml logs igny8_backend > /tmp/new-vps-logs.txt
+
+# At DNS provider, flip A records back to OLD VPS IP
+# (takes 30-60 seconds to propagate with TTL=60)
+
+# Traffic reverts to old VPS instantly
+# Old VPS never stopped, so no data loss
+```
+
+#### Step 2.6: Increase TTL Back to Normal (optional)
+
+After 48 hours of stable operation, increase TTL back to 3600 or higher:
+
+At DNS provider:
+
+```bash
+# Set TTL back to 3600 (1 hour)
+# This reduces DNS query load once migration is stable
+```
+
+#### Stage 2 Acceptance Criteria
+
+- ✅ DNS propagation successful within 5 minutes (verified globally)
+- ✅ No 5xx errors spike after DNS flip
+- ✅ Payment webhooks processing normally
+- ✅ Background jobs running without errors
+- ✅ User-facing errors < 0.01% of requests
+- ✅ Database and Redis performing normally
+- ✅ 24-48 hours of clean logs with no critical issues
+- ✅ Old VPS remains running as hot standby
+
+#### Stage 2 Rollback Procedure
+
+If critical issue found within 48 hours:
+
+1. **Diagnose the issue** using new VPS logs
+2. **At DNS provider:** Change A records back to old VPS IP
+3. **Wait:** 30-60 seconds for DNS to propagate (TTL is now 60 seconds)
+4. **Traffic reverts** to old VPS (which never stopped)
+5. **Fix issue** on new VPS in parallel
+6. **Re-test** via test subdomains before attempting DNS flip again
+
+---
+
+### 4.3 Stage 3: Cloudflare Onboarding (AFTER 24-48h stable)
+
+#### Prerequisites
+- ✅ Stage 2 complete; new VPS has been live for 24-48 hours
+- ✅ All monitoring metrics normal
+- ✅ Error logs clean
+- ✅ Payments flowing normally
+- ✅ Test subdomains can now be decommissioned
+
+#### Step 3.1: Transfer Nameservers to Cloudflare
+
+**In Cloudflare Dashboard:**
+
+1. Log into Cloudflare account
+2. Add new site: `igny8.com`
+3. Choose Free or paid plan
+4. Cloudflare generates two nameservers (e.g., `ns1.cloudflare.com`, `ns2.cloudflare.com`)
+
+**At current domain registrar:**
+
+1. Navigate to nameserver settings for igny8.com
+2. Replace current nameservers with Cloudflare nameservers
+3. **Save changes**
+
+**Verification:**
+
+```bash
+# Wait 5-30 minutes for nameserver propagation
+# Then verify:
+nslookup ns igny8.com
+# Should show Cloudflare nameservers
+
+# Verify DNS is resolving (should still point to new VPS IP)
+nslookup app.igny8.com
+# Should show NEW VPS IP
+```
+
+#### Step 3.2: Create DNS Records in Cloudflare
+
+In Cloudflare Dashboard:
+
+1. Go to **DNS** section
+2. Create A records (all pointing to new VPS IP):
+   - Name: `app` | Type: A | IPv4: `<new-vps-ip>` | Proxied: Yes (orange cloud)
+   - Name: `api` | Type: A | IPv4: `<new-vps-ip>` | Proxied: Yes (orange cloud)
+   - Name: `@` (root) | Type: A | IPv4: `<new-vps-ip>` | Proxied: Yes (orange cloud)
+
+3. Remove test subdomains (no longer needed):
+   - Delete `test-app` record
+   - Delete `test-api` record
+
+**Verify DNS is resolving through Cloudflare:**
+
+```bash
+# Should show Cloudflare nameservers
+dig app.igny8.com ns
+
+# Should resolve to new VPS IP
+nslookup app.igny8.com
+```
+
+#### Step 3.3: Configure Caddy for Cloudflare SSL
+
+On new VPS, update Caddy to use Cloudflare DNS challenge for SSL (or keep Let's Encrypt HTTP if using Full Strict mode).
+
+**Option A: Cloudflare DNS Challenge (recommended if using zone caching)**
+
+1. Download Caddy with cloudflare module:
+
+```bash
+# SSH to new VPS
+ssh root@<new-vps-ip>
+
+# Download caddy with cloudflare module
+# (This assumes you built caddy with xcaddy)
+docker exec igny8_caddy caddy version
+# If cloudflare module not present, rebuild Caddy image with:
+# FROM caddy:builder as builder
+# RUN builder -replace github.com/caddy-dns/cloudflare github.com/caddy-dns/cloudflare@latest
+# FROM caddy:latest
+# COPY --from=builder /usr/bin/caddy /usr/bin/caddy
+```
+
+2. Update Caddyfile to use Cloudflare DNS:
+
+```caddyfile
+# Caddyfile on new VPS
+app.igny8.com api.igny8.com igny8.com {
+  reverse_proxy igny8_backend:8010 {
+    header_up Host {upstream_hostport}
+  }
+
+  tls {
+    dns cloudflare {env.CLOUDFLARE_API_TOKEN}
+  }
+}
+```
+
+3. Set Cloudflare API token in Docker Compose:
+
+```yaml
+# docker-compose.app.yml
+services:
+  caddy:
+    environment:
+      CLOUDFLARE_API_TOKEN: <your-cloudflare-api-token>
+```
+
+4. Restart Caddy:
+
+```bash
+docker compose -f docker-compose.app.yml restart caddy
+```
+
+**Option B: Let's Encrypt HTTP Challenge (if Cloudflare Full Strict SSL)**
+
+If Cloudflare is in Full (Strict) SSL mode, Caddy can use HTTP challenge:
+
+```caddyfile
+app.igny8.com api.igny8.com igny8.com {
+  reverse_proxy igny8_backend:8010 {
+    header_up Host {upstream_hostport}
+  }
+
+  tls {
+    # Let's Encrypt will be used by default (HTTP challenge)
+  }
+}
+```
+
+This works because Cloudflare's Full (Strict) mode trusts Caddy's self-signed certificate on the origin.
+
+#### Step 3.4: Configure Cloudflare Settings
+
+In Cloudflare Dashboard:
+
+**SSL/TLS:**
+- Mode: **Full (Strict)** — encrypts traffic between Cloudflare and origin (new VPS)
+- Minimum TLS Version: **1.2**
+- Automatic HTTPS Rewrites: **ON**
+
+**Caching:**
+- Default Cache TTL (Browser): **30 minutes**
+- Cache on Browser Side: **ON**
+
+**Speed:**
+- Auto Minify: Enable **JavaScript, CSS, HTML**
+- Brotli compression: **ON**
+- Automatic platform optimization: **ON**
+
+**Security:**
+- Always Use HTTPS: **ON**
+- HSTS: **max-age=31536000; includeSubDomains; preload**
+- Opportunistic Encryption: **ON**
+
+**Rules (if needed):**
+- Add Page Rules for specific paths if required (e.g., exclude /api/webhooks from caching)
+
+#### Step 3.5: Remove Test Subdomains
+
+On new VPS, update Caddy to remove test subdomain routing (if they're still configured):
+
+```caddyfile
+# OLD (remove test subdomains)
+# test-app.igny8.com test-api.igny8.com {
+#   ...
+# }
+
+# Keep only real domains
+app.igny8.com api.igny8.com igny8.com {
+  reverse_proxy igny8_backend:8010
+  tls {
+    dns cloudflare {env.CLOUDFLARE_API_TOKEN}
+  }
+}
+```
+
+Restart Caddy:
+
+```bash
+docker compose -f docker-compose.app.yml restart caddy
+```
+
+#### Step 3.6: Verify Cloudflare SSL & Performance
+
+```bash
+# Verify SSL is through Cloudflare (should see Cloudflare cert)
+openssl s_client -connect app.igny8.com:443
+
+# Verify HSTS header is present
+curl -I https://app.igny8.com
+# Should show: Strict-Transport-Security: max-age=31536000...
+
+# Test API endpoint through Cloudflare
+curl https://api.igny8.com/api/v1/system/status/
+# Should return 200 OK
+```
+
+#### Stage 3 Acceptance Criteria
+
+- ✅ Nameservers successfully pointing to Cloudflare
+- ✅ DNS records created in Cloudflare (A records for app, api, root)
+- ✅ SSL certificate valid and served through Cloudflare
+- ✅ HTTPS enforced (HTTP redirects to HTTPS)
+- ✅ Cloudflare caching enabled and working (check cache headers)
+- ✅ No application errors after Cloudflare activation
+- ✅ Payment processing still working through Cloudflare proxy
+- ✅ API endpoints responding normally through Cloudflare
+- ✅ Test subdomains removed and no longer needed
+
+#### Stage 3 Rollback Procedure
+
+If issues arise with Cloudflare:
+
+1. **At Cloudflare Dashboard:** Disable proxy (gray cloud) for A records to DNS-only mode
+2. **At registrar:** Revert nameservers back to previous provider
+3. **Traffic reverts** to previous DNS setup (still on new VPS)
+4. **Diagnose** Cloudflare issue
+5. **Re-enable** Cloudflare after fixes are tested
+
+---
+
+## 5. Acceptance Criteria (Per Stage)
+
+### Stage 1: Deploy & Test (Test Subdomains)
+
+- Database row counts match old VPS (verify with SELECT COUNT queries)
+- All media files present and accessible
+- SSL certificates valid for test subdomains
+- Health check endpoint returns 200 OK
+- User authentication works via test subdomains
+- Stripe test payments process successfully
+- PayPal sandbox payments process successfully
+- WordPress plugin downloadable and checksums match
+- Celery background jobs process without errors (check logs)
+- No critical errors in application logs over 24 hours
+- Old VPS still serving production with zero disruption
+
+### Stage 2: DNS Flip (Production Traffic)
+
+- DNS propagation complete within 5 minutes globally
+- No spike in 5xx errors after DNS flip
+- Payment webhook latency remains <500ms
+- Background job success rate remains >99%
+- Database and Redis performance stable
+- All manual testing passes on production domains
+- 48 hours of monitoring with zero critical issues
+- Old VPS remains running as hot fallback
+
+### Stage 3: Cloudflare Onboarding
+
+- Cloudflare nameservers active and resolving
+- SSL certificate valid through Cloudflare
+- HTTP automatically redirects to HTTPS
+- Caching headers present and cache working
+- Payment processing unaffected
+- API endpoints respond normally through Cloudflare proxy
+- HSTS header present
+- No application errors related to Cloudflare
+
+---
+
+## 6. Claude Code Instructions
+
+### For Stage 1 Deployment
+
+```
+Task: Deploy IGNY8 to new VPS and test via test subdomains
+
+1. SSH to new VPS and verify Docker/PostgreSQL/Redis running
+2. Clone GitHub repo to /data/app/igny8/backend
+3. Create .env file with new VPS database credentials
+4. On old VPS: pg_dump --format=custom to backup PostgreSQL 16
+5. Transfer dump to new VPS and pg_restore to PostgreSQL 18
+6. Run ANALYZE on all tables
+7. rsync media and plugin files from old VPS
+8. Docker compose build and up on new VPS
+9. Verify Caddy SSL for test subdomains
+10. Test health check: curl https://test-app.igny8.com/api/v1/system/status/
+11. Manual testing: login, payments, WordPress plugin, background jobs
+12. Monitor logs for 24 hours; report any errors
+```
+
+### For Stage 2 DNS Flip
+
+```
+Task: Flip DNS to new VPS after Stage 1 success
+
+1. At DNS provider: Reduce TTL on A records to 60 seconds
+2. Wait 2-4 hours for old TTL to expire
+3. Change A records to new VPS IP:
+   - app.igny8.com
+   - api.igny8.com
+   - igny8.com
+4. Verify DNS propagation globally (nslookup)
+5. Monitor logs and error rates for 24-48 hours
+6. Keep old VPS running as fallback
+7. Document any issues; have rollback plan ready (flip A records back)
+```
+
+### For Stage 3 Cloudflare Onboarding
+
+```
+Task: Set up Cloudflare DNS and proxy (ONLY after 48h stable)
+
+1. In Cloudflare: Add igny8.com, receive nameservers
+2. At registrar: Replace nameservers with Cloudflare
+3. In Cloudflare: Create A records (app, api, @) pointing to new VPS IP
+4. In Cloudflare: Enable orange cloud (proxy) for all A records
+5. On new VPS: Update Caddyfile with Cloudflare DNS challenge or HTTP challenge
+6. Restart Caddy container
+7. In Cloudflare: Configure SSL (Full Strict), HSTS, Auto Minify, caching
+8. Verify SSL, HTTPS enforcement, cache headers
+9. Test payment processing and API endpoints through Cloudflare
+10. Remove test subdomains from DNS
+```
+
+---
+
+## 7. Rollback Procedures Summary
+
+| Stage | Issue Discovered | Rollback Action | Downtime |
+|-------|-----------------|-----------------|----------|
+| 1 | New VPS has critical errors | Disable test subdomains; old VPS unaffected | 0 minutes |
+| 2 | Production errors after DNS flip | Flip A records back to old VPS IP | <2 minutes (TTL=60s) |
+| 3 | Cloudflare causes issues | Disable Cloudflare proxy (gray cloud) or revert nameservers | <5-30 minutes |
+
+---
+
+## 8. Timeline & Dependencies
+
+```
+Day 0-1:   Stage 1 — Deploy, test via test subdomains
+Day 1-2:   Monitor new VPS; ensure fully healthy
+Day 2:     Stage 2 — Reduce TTL, wait for expiration
+Day 2:     Stage 2 — Flip DNS to new VPS
+Day 2-4:   Monitor production; old VPS as fallback
+Day 4+:    Stage 3 — Transfer to Cloudflare (after 48h stable)
+```
+
+---
+
+## 9. Related Documents
+
+- **00A**: GitHub Repository Consolidation — app code merged into single repo
+- **00B**: New VPS Infrastructure Setup — new VPS provisioned, test subdomains created
+- **00D**: Staging Environment Setup — follows this migration doc
+- **00E**: Old VPS Cleanup & Decommission — decommission after migration stable
+
+---
+
+**End of Document 00C**
--- a/v2/V2-Execution-Docs/00D-staging-environment.md
+++ b/v2/V2-Execution-Docs/00D-staging-environment.md
--- a/v2/V2-Execution-Docs/00E-legacy-cleanup.md
+++ b/v2/V2-Execution-Docs/00E-legacy-cleanup.md
--- a/v2/V2-Execution-Docs/00F-self-hosted-ai-infra.md
+++ b/v2/V2-Execution-Docs/00F-self-hosted-ai-infra.md
--- a/v2/V2-Execution-Docs/01A-sag-data-foundation.md
+++ b/v2/V2-Execution-Docs/01A-sag-data-foundation.md
--- a/v2/V2-Execution-Docs/01B-sector-attribute-templates.md
+++ b/v2/V2-Execution-Docs/01B-sector-attribute-templates.md
--- a/v2/V2-Execution-Docs/01C-cluster-formation-keyword-engine.md
+++ b/v2/V2-Execution-Docs/01C-cluster-formation-keyword-engine.md
--- a/v2/V2-Execution-Docs/01D-setup-wizard-case2-new-site.md
+++ b/v2/V2-Execution-Docs/01D-setup-wizard-case2-new-site.md
--- a/v2/V2-Execution-Docs/01E-blueprint-aware-pipeline.md
+++ b/v2/V2-Execution-Docs/01E-blueprint-aware-pipeline.md
--- a/v2/V2-Execution-Docs/01F-existing-site-analysis-case1.md
+++ b/v2/V2-Execution-Docs/01F-existing-site-analysis-case1.md
--- a/v2/V2-Execution-Docs/01G-sag-health-monitoring.md
+++ b/v2/V2-Execution-Docs/01G-sag-health-monitoring.md
--- a/v2/V2-Execution-Docs/SOURCE-FILES-INDEX.md
+++ b/v2/V2-Execution-Docs/SOURCE-FILES-INDEX.md
@@ -0,0 +1,57 @@
+# V2 Execution Docs — Source Files Index
+
+All unique source files being consolidated into V2-Execution-Docs.
+
+---
+
+## Live Docs on Server/igny8-app-docs/plans/ (14 files — all listed)
+
+- GO-LIVE-CHECKLIST.md
+- SOCIALIZER-AND-VIDEO-CREATOR-MODULES.md
+- gsc_integratin.md
+- Future_Moduels_Features/Content_Types_Writing_Plan.md
+- Future_Moduels_Features/GSC_plnning_to_be_updated_consistent_with_supported_API_and_Igny8_app.md
+- Future_Moduels_Features/Linker_Module_Plan.md
+- Future_Moduels_Features/Optimizer_Module_Plan.md
+- Future_Moduels_Features/Socializer_Video_Modules_Plan.md
+- Future_Moduels_Features/Taxonomy_Term_Content_Plan.md
+- Future_Moduels_Features/FB_LinkedIn_Auth_flow_Steps.md
+- final-dev-guides-of-futute-implementation/DocA-SAG-Architecture-Dev-Guide.md
+- final-dev-guides-of-futute-implementation/DocB-Platform-Modules-Dev-Guide.md
+- final-dev-guides-of-futute-implementation/DocC-WordPress-Ecosystem-Dev-Guide.md
+- final-dev-guides-of-futute-implementation/DocD-Business-Services-Dev-Guide.md
+
+## temp/IGNY8-Project-Files/ — unique only (8 files, not in Live Docs plans/)
+
+- IGNY8-Current-State.md
+- SAG-Master-Document.md
+- SAG-IGNY8-Implementation.md
+- IGNY8-Consolidated-Module-Plans.md
+- SAG-Doc3-Interlinking-Specification-PLAN.md
+- SAG-Doc4-External-Backlink-Campaign-PLAN.md
+- IGNY8-Plugin-Build-Plan.md
+- Theme-Build-Plan.md
+
+## temp/IGNY8-Project-Files/ — non-md files (4 files)
+
+- IGNY8-Industry-Sector-Master-List.md
+- SAG-Niche-Definition-Process.docx
+- SAGIndustry01HealthcareMedical.xlsx
+- IGNY8-Rich-Schema-SERP-Enhancement-Module.docx
+
+## Igny8 V2 New Final Plans/ — unique only (5 files, not in temp/ or Live Docs)
+
+- IGNY8 Self-Hosted AI Infrastructure/Potential-SaaS-Projects-Alorig-Systems.docx
+- IGNY8 Self-Hosted AI Infrastructure/architecture (1).jsx
+- Linker Internal & External/IGNY8_Linker_FatGrid_PR_Analysis.md.pdf
+- Linker Internal & External/IGNY8-Linker-Module-Visualization.html
+- SAG-Niche-Definition-Process.pdf
+
+## Top-level — unique (2 files)
+
+- Igny8/IGNY8-Complete-Platform-Features.docx
+- APPS/Alorig-Master-Plan-v1.docx
+
+---
+
+**Total: 33 unique files (14 in Live Docs plans + 12 in temp + 5 in V2 New Final Plans + 2 top-level)**