2meet-data-optimizer/docs/INTEGRATION_PATTERN_DECISION.md

Integration Pattern Decision — 2026-04-25

v1.0.0 後記（2026-07-31）：本文結論已被架構拆分取代。 當時的兩個選項是「集中在核心」vs「各外掛自帶 bridge」。v1.0.0 走的是第三條路： 每個夥伴外掛對應一個獨立 AddOn 外掛（2meet-data-optimizer-<partner>-addon，共 11 個）， 核心完全不認識夥伴外掛。下文的 class-tmdo-<partner>.php 一律已搬進對應 AddOn。 本文保留是為了記錄「為什麼不選 per-plugin bridge 檔」這段推理 —— 該理由對 AddOn 邊界同樣適用。

Trigger: Step BB audit revealed two parallel patterns for partner plugin integration; need to commit to one.

---

What I found

Plugin	Centralized in 2meet-data-optimizer?	Own bridge file?
2meet-infocards	✅ class-tmdo-infocards.php	❌
2meet-bookings	✅ class-tmdo-bookings.php	❌
2meet-quotation	✅ class-tmdo-quotation.php	❌
2meet-events	✅ class-tmdo-events.php	✅ class-tmevents-wpdo-bridge.php (duplicate!)
2meet-collab	✅ class-tmdo-collab.php	❌
2meet-mobile-bridge	✅ class-tmdo-mobile-bridge.php	❌
2meet-playlist	✅ class-tmdo-playlist.php	❌
2meet-courses	❌	✅ class-2meetic-courses-wpdo.php (NEW today, P step)
2meet-inquiries	❌	✅ class-tmqi-wpdo-integration.php (NEW from scratch)

Inconsistency:

• 7 plugins are integrated centrally (legacy Wave 2 demo pattern)
• 2 new plugins (today) are integrated decentrally (cookbook Tier 4 pattern)
• 2meet-events has both (silent dedup by registry — works but smelly)

---

Decision: Decentralized (own bridge) is the canonical pattern

Rationale

1. Cookbook Tier 4 documents it as the standard for new plugins (already published)
2. Each plugin owns its own data contract — no cross-plugin coupling in 2meet-data-optimizer
3. Easier to ship — partner plugin can update its registration without bumping 2meet-data-optimizer
4. Simpler mental model — "where do tables get registered? In the plugin that owns them"

Why we're NOT migrating today

1. Freeze: Per FREEZE_2026-04-25.md, no risky refactors during freeze
2. Working: All 7 centralized integrations work; registry dedup handles the events double-pattern
3. No vendor demand: Nobody has reported confusion or bugs from the dual pattern
4. Risk > reward: Moving 7 classes touches 8 plugins, requires coordinated version bumps, breaks atomic rollback

---

Migration plan (when we DO migrate)

Trigger conditions (any one):

• A new partner plugin can't ship cleanly because of the centralized pattern
• A bug in the centralized integrations affects multiple plugins simultaneously
• We hit 10+ partner plugins (currently 9) and the 2meet-data-optimizer integrations dir is too crowded

Steps (per plugin, ~0.5 day each)

1. Copy /2meet-data-optimizer/includes/integrations/class-tmdo-{slug}.php
   to /{plugin-slug}/includes/integrations/class-{prefix}-wpdo.php

2. Rename class:
   - TMDO_Bookings → TMB_WPDO
   - TMDO_Quotation → TMQUO_WPDO  (etc.)
   - Keep registration logic identical

3. Wire in {plugin-slug} bootstrap (after main classes load):
   require_once $dir . 'includes/integrations/class-{prefix}-wpdo.php';
   {prefix}_WPDO::register();

4. In 2meet-data-optimizer:
   - Remove require_once line
   - Remove class name from the partner array (line ~208 of main file)
   - Bump WPDO version (patch)

5. Verify:
   wp eval 'echo count(TMDO_Custom_Table_Registry::instance()->for_provider("{slug}"));'
   → should still match the original count

6. Bump partner plugin version (minor, since it now has new dependency)
   Update Requires Plugins header to mention 2meet-data-optimizer ≥ X.Y.Z

Special case: 2meet-events double-pattern

Already has both. Migration = remove the centralized class-tmdo-events.php (the bridge in 2meet-events stays). This is the simplest first migration because the partner plugin's own bridge is already proven.

---

What this means for tomorrow's reader

If you're writing a NEW 2meet-* plugin: follow Tier 4 pattern, put your integration class in your own plugin's includes/integrations/ directory.

If you're maintaining an EXISTING centralized integration in 2meet-data-optimizer: leave it alone unless one of the migration triggers fires.

If you see the dual pattern in 2meet-events and are confused: it's intentional, registry dedups, will be cleaned up later.

---

Anti-decisions (things explicitly NOT done)

• ❌ NOT moving 7 integrations today — too risky, freeze active
• ❌ NOT fixing the events double-pattern today — works fine, low priority
• ❌ NOT writing a "consolidation script" — premature optimization for a one-time migration
• ❌ NOT updating cookbook to mention the centralized pattern — would be confusing

---

When to revisit this decision

Same as freeze conditions (FREEZE_2026-04-25.md):

• vendor reports confusion / bug
• 30 days passed with no action needed
• New plugin (#10+) onboarded
• Production critical event involves the pattern