# 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