THE UNIFIED PLATFORM BIBLE — ADDENDUM 07

Triple Verification — Migration Pipeline & Fixes June 2026

Version: 1.0
Date: June 16, 2026
Author: Alain Bessette, CFO/Product Owner, ABI Conglomerate
Domain: GoWeBa.com
Status: Official Strategic Addendum — Binding Specification
Constraints: ZERO data loss · ZERO force-reset · ZERO email disruption

⚠️ CRITICAL NOTICE
This addendum has the SAME authority as Part 1, Part 2, and all preceding Addendums of the Bible.
All fixes described herein are production-deployed and checkpointed.
No breaking schema changes were made.

📋 TABLE OF CONTENTS

1. Context & Objective
2. Phase M — Google Pull Verification
3. Phase C — V10 Classification Verification
4. Phase E — Email Forward/Reply Fix
5. Phase A — ARCHIVED Tab & 15-Card Grid
6. Bounce Address Fix
7. Domain Registry — Initial Seed
8. Database State
9. Final Verdict & Recommendations
10. Modified Files — Complete Inventory
11. Checkpoint Timeline

<a id="context"></a>

SECTION 1: CONTEXT & OBJECTIVE

After several iterations on the Google → GoWeBa migration pipeline, this addendum documents the exhaustive triple verification performed on June 16, 2026, before official launch of user migrations.

The verified phases cover the entire lifecycle:

<a id="phase-m"></a>

SECTION 2: PHASE M — GOOGLE PULL VERIFICATION

2.1 Retrieval Architecture

The module lib/migration/google-pull.ts handles Google data extraction via native APIs (People, Gmail, Calendar, Drive) without dependency on the googleapis package.

2.2 Verified Performance Parameters

2.3 Robustness Mechanisms

• Exponential backoff: 2s → 4s → 8s → 16s + random 1s jitter
• Rate limit detection: isRateLimitError() detects HTTP 429 and Google-specific errors
• Preventive stop: After 20 consecutive errors, import stops cleanly with explicit error message
• Progressive flush: Emails are not held in memory — flushed to DB in batches of 200
• Progress logging: Log emitted every ~500 emails with elapsed time
• Time estimation: System calculates and displays estimated remaining time

2.4 Verdict

<a id="phase-c"></a>

SECTION 3: PHASE C — V10 CLASSIFICATION VERIFICATION

3.1 12-Layer Cascade

The file lib/weba/classification-cascade.ts implements the complete V10 cascade as documented in the WebaBox Classification Guide V10 (Document 2):

3.2 Batch Classification (V10 Migration)

The endpoint POST /api/weba/migration/start handles mass classification:

• Batches of 50 threads (configurable up to 100)
• Automatic self-chaining: Server calls itself via selfChain() to process next batch
• Self-chain retry: 3 attempts (localhost → external URL → fallback)
• Combined action: action: 'both' allows classify + archive in a single operation
• Cumulative counters: _totalProcessed and _totalChanged track global progress

3.3 Feature Flags

All V10 flags are enabled by default (via lib/weba/feature-flags.ts):

3.4 Verdict

<a id="phase-e"></a>

SECTION 4: PHASE E — EMAIL FORWARD/REPLY FIX

4.1 Identified Issues

Two bugs in WebaBox Forward/Reply:

1. Attachments not transferred: When forwarding, original email attachments were not included.
2. Incorrect send account: The "From" selector did not default to the thread's email account.

4.2 Fixes Applied

4.2.1 Forward Attachments

Modified files:

• app/(app)/inbox/compose-modal.tsx — Added initialAttachments prop + loading logic (presigned URL → base64)
• app/(app)/inbox/webabox-client.tsx — Added attachments to replyComposeState
• app/(app)/inbox/ongoing/[threadId]/ongoing-client.tsx — Same propagation for thread mode

4.2.2 Default From Account

Modified file: app/(app)/inbox/compose-modal.tsx

Bug: The useEffect that loaded email accounts systematically overwrote the initial selectedAccountId.

Fix: Added if (!initialAccountId && ...) condition to prevent overwriting an already-selected account.

4.3 Verdict

<a id="phase-a"></a>

SECTION 5: PHASE A — ARCHIVED TAB & 15-CARD GRID

5.1 UI Changes

5.2 Grid Layout

5.3 Verdict

<a id="bounce-fix"></a>

SECTION 6: BOUNCE ADDRESS FIX

6.1 Identified Issue

Inbound emails displayed sender addresses like:

bounce+982d51.e8c12e-admin=goweba.com@m.relayfi.com

instead of the real sender address, making Reply and Forward unusable.

6.2 Root Cause

File: app/api/webhooks/sendgrid-inbound/route.ts
Function: handleRawMode()

The code correctly extracted the real address from the MIME From: header via parsed.from.address, but then overwrote it with envelope.from — the technical bounce/return-path address.

// ❌ BEFORE — Bug
const envelopeFrom = parsed.from.address; // ← Correct initially
if (envelope.from) envelopeFrom = envelope.from; // ← OVERWRITES with bounce

// ✅ AFTER — Fix
const mimeFrom = parsed.from.address; // ← Real sender (MIME From:)
let envelopeFrom = mimeFrom; // ← Copy for spam checks
if (envelope.from) envelopeFrom = envelope.from; // ← Envelope for SPF/DKIM only
// mimeFrom → stored in DB and used for contacts
// envelopeFrom → used only for checkSpamAndSpoofing()

6.3 Impact

6.4 Known Limitation

30 existing messages still have bounce addresses as fromEmail. Only new inbound emails are fixed. A retroactive migration script can be run on request.

6.5 Verdict

<a id="domain-registry"></a>

SECTION 7: DOMAIN REGISTRY — INITIAL SEED

7.1 Discovery

During the triple verification, it was found that the DomainRegistry table was empty (0 entries). Layer 4 of the V10 cascade (Domain Registry) could not function.

7.2 Corrective Action

Seed executed from lib/weba/domain-registry-seed-data.ts:

• 334 domains defined in source file
• 333 domains created in database (1 duplicate resolved by update)
• 5 categories covered: SOCIAL, TRAVEL, PROMOTIONS, JOURNAL, OFFICE

7.3 Impact on Classification

With 333 domains in the database, layer 4 (confidence 0.90) can now classify most emails from known services without calling the LLM (layer 10), improving speed, accuracy, and cost.

7.4 Verdict

<a id="db-state"></a>

SECTION 8: DATABASE STATE

8.1 Snapshot — June 16, 2026

8.2 Category Distribution

Note: 781 threads (88.3%) are categorized NONE because V10 classification has not yet been run on existing threads. After batch classification, this distribution should approach the target documented in the V10 Guide.

8.3 Old Migration Cleanup

Both test migrations (alainbessette55@gmail.com and alainbessette.com/iwant@) were fully deleted:

• 0 residual data found in migration projects
• 0 orphaned data linked to these accounts

<a id="verdict"></a>

SECTION 9: FINAL VERDICT & RECOMMENDATIONS

9.1 Verification Summary

9.2 Post-Deployment Recommendations

1. Run V10 classification on 781 existing threads categorized NONE via admin /admin/weba/migration
2. Run auto-archive to archive threads >90 days in eligible categories
3. Verify first inbound emails after bounce fix to confirm addresses are correct
4. Consider a retroactive correction script for the 30 messages with bounce addresses
5. Consider adding a replyTo field to the EmailMessage model (future improvement)

9.3 Conclusion

🟢 THE MIGRATION PIPELINE IS READY. All verifications passed. Critical fixes applied. Domain registry populated. The system is ready to process new migrations with confidence.

<a id="files"></a>

SECTION 10: MODIFIED FILES — COMPLETE INVENTORY

<a id="checkpoints"></a>

SECTION 11: CHECKPOINT TIMELINE

End of Addendum 07 — Triple Verification Migration