Architecture Decision: Open Paws Platform Sync — API Gateway vs Sync vs Divergence

[LarytheLord]

Problem

The Open Paws Platform (Astro + Supabase) has reimplemented AG's guild functionality independently:

• guild_quests table (separate from our quests)
• guild_quest_assignments table (separate from our quest_assignments)
• Own service layer at src/lib/services/guild/guild-quest-service.ts
• Different status names ('applied' vs our 'assigned')
• Different field names (quest_id snake_case vs our Prisma questId)

Our AG platform (Next.js + Neon/Prisma) is the authoritative system — Phase 0-2 is complete with QuestTrack, Party system, QA mediation, BootcampLink, and now Guild Card.

The two systems have diverged. Quest data is duplicated, not synced.

Options

Option A: API Gateway (Recommended)

OP Platform calls AG's API instead of maintaining its own DB tables.

How:

• OP Platform's guild-quest-service.ts calls https://adventurersguild.space/api/... endpoints instead of Supabase
• Auth bridging: OP Platform passes a service token, AG validates it (similar to the bootcamp onboard webhook secret)
• OP Platform becomes a read-through client of AG

Pros: Single source of truth. No sync lag. All new features (parties, QA mediation, Guild Card) available instantly.
Cons: Requires OP Platform code changes. AG becomes a dependency for OP Platform uptime. Need to add service-to-service auth.
Effort: ~2 days AG side (add service auth), ~3 days OP side (rewrite service layer)

Option B: One-Way Sync (Pragmatic)

AG is authoritative. Nightly/hourly sync pushes quest + assignment data to OP Platform's Supabase.

How:

• Cron job or webhook: when quest status changes in AG, push to OP Supabase
• OP Platform reads from its own Supabase (fast, no cross-service dependency)
• Writes only happen on AG side

Pros: OP Platform stays independent. No runtime dependency on AG.
Cons: Sync lag (up to 1 hour). Need to maintain the sync job. Schema mapping headaches as AG evolves.
Effort: ~3 days (build sync service + field mapping)

Option C: Shared Schema Definition

Both platforms read from the same Prisma schema definition, apply to their own DBs independently.

Pros: Consistent field names.
Cons: Still duplicated data. Doesn't solve runtime sync. Two DBs to maintain.
Effort: ~1 day setup, ongoing maintenance burden

Option D: Accept Divergence (Simplest for Now)

OP Platform is a separate read-only view. We manually keep important quests in sync. Focus on AG as the primary platform.

Pros: Zero engineering effort. Ship faster.
Cons: Data drifts. Users might see different quest states on different platforms.
Effort: 0 days

Recommendation

Option A (API Gateway) for May launch. Reasons:

1. We already have the bootcamp onboard webhook pattern — service-to-service auth is proven
2. AG has 40 audited API routes covering everything OP needs
3. One source of truth avoids the "which platform shows the right status" problem
4. Phase 2 features (parties, QA mediation, Guild Card) are only on AG — syncing them would be a massive effort vs just calling the API

Fallback: If OP Platform team can't rewrite their service layer before May, use Option D (accept divergence) and plan API Gateway for June.

Decision Needed

@LarytheLord and Sam need to align on:

1. Which option to go with
2. Who rewrites the OP Platform service layer (if Option A)
3. Timeline — does this block intern onboarding in May?