Console/ Marketing/ Prototype Design Readiness & System Blueprint

Prototype Design Readiness & System Blueprint

Design Management · DB Structure · System Design · Content Operations · Tracking Framework
marketing Live Batch MKT-06 · Document 6 Author: ChatGPT
Claude-added · Metadata
Primary author
ChatGPT (verbatim source)
Publisher
Claude (ingest · format · index · publish)
Category
marketing
Group
marketing
Status
live
List position
Marketing #6
History
originally shipped as Marketing #7 in Batch MKT-07 (2026-04-22) while slots #4 and #6 were reserved · slot #4 filled by MKT-04 (2026-04-22) · this document renumbered to #6 via Batch MKT-AUDIT-02 (2026-04-22) to produce a contiguous 1–6 list
Route
/marketing/prototype-design-readiness-system-blueprint.html
Related docs
Marketing #1 · MICE Platform Strategy · Marketing #2 · MICE Product Matrix · Marketing #3 · Enterprise Canvas Blueprint · Marketing #5 · Together Mode Architecture V2
Claude did
added TOC anchors (21 main sections + sub-sections) · converted 1 markdown table to HTML · added metadata block · added cross-links · added appendix · added glossary
Claude did NOT
rewrite · summarise · shorten · remove words · change wording of the primary source
Batch
MKT-06 (ingested via Batch MKT-07 · renumbered via Batch MKT-AUDIT-02)
Claude-added · Index

สารบัญ · anchor links สำหรับ 21 sections หลักของ ChatGPT primary source · รวม sub-sections ภายในแต่ละหมวด.

Prototype Design Readiness & System Blueprint

เอกสารฉบับนี้ทำหน้าที่เป็นเอกสารแม่สำหรับพา Together Super App V2 จากระดับต้นแบบเชิงภาพและ interaction ไปสู่ระดับที่สามารถอ้างอิงงาน ออกแบบระบบ ออกแบบฐานข้อมูล จัดการ content เชื่อม data และเปิดให้ทีมทดสอบใช้งานจริงได้อย่างเป็นระบบ

หัวใจของเอกสารนี้คือการเปลี่ยนจาก “ต้นแบบที่ดูได้” ไปสู่ “ระบบที่บริหารได้”

กล่าวคือไม่ใช่เพียงมีหน้าจอสวยหรือ flow ดี แต่ต้องสามารถตอบได้ด้วยว่า:

ดังนั้นเอกสารฉบับนี้ต้องถูกใช้เป็นสะพานเชื่อมระหว่าง:

1. ความเห็นต่อ V1 ในฐานะ milestone prototype

V1 เป็น milestone prototype ที่ดีมาก เพราะไปไกลกว่าระดับ wireframe แล้วอย่างชัดเจน และเริ่มมีคุณลักษณะของ behavioral prototype ที่ใช้อธิบายระบบได้จริง ทั้งในแง่:

จากต้นแบบ V1 เห็นได้ชัดว่ามี screen สำคัญจำนวนมากแล้ว เช่น:

กล่าวได้ว่า V1 ไม่ใช่เพียง mockup สวย ๆ แต่เป็น prototype เชิงพฤติกรรมที่ใช้เป็น visual and interaction baseline ได้แล้ว

จุดแข็งของ V1

ข้อจำกัดของ V1

แม้ V1 จะดีมาก แต่ยังเป็น prototype-centric มากกว่า system-centric
กล่าวคือ:

แต่ยังไม่ใช่ระบบอ้างอิงงานที่ใช้ส่งต่อข้ามทีมได้อย่างลื่นไหล

2. ปัญหาหลักของ V1 ถ้าจะเอาไปต่อทันที

2.1 Source of truth ยังไม่เป็นระบบ

ต้นแบบรวม logic และโครงสร้างจำนวนมากไว้ในชุดเดียว ทำให้:

2.2 ยังไม่มี Design Object Registry ที่ชัด

ยังไม่เห็นชั้นข้อมูลกลางที่ตอบได้ว่า:

2.3 ยังไม่มี Design-to-Dev handoff structure ที่ละเอียดพอ

ยังไม่สามารถตอบได้ทันทีว่า:

2.4 ยังไม่ใช่ prototype management board

ยังไม่เห็นระบบที่ช่วยให้มองภาพรวมทันทีว่า:

3. ข้อเสนอหลัก: ต้องทำเป็น Design Management System

คำตอบเชิงโครงสร้างคือ:
ควรทำให้ระบบนี้มีลักษณะคล้าย project management แต่ยกระดับเป็น Design Management + Build Readiness System

เพราะโจทย์ไม่ใช่แค่ “จัดการงาน”
แต่คือ “จัดการความสัมพันธ์ระหว่าง design, content, dev, data, integration และ testing”

ดังนั้นระบบที่เหมาะสมควรต่อเนื่องจาก:

Design Management → Build Readiness → Integration Readiness → Test Readiness

4. หน่วยหลักของ Design Management System

4.1 Screen Registry

เก็บรายการทุกหน้าจอในระบบ
แต่ละ screen ควรมีข้อมูลอย่างน้อย:

ตัวอย่างรหัส:

4.2 Block / Object Registry

แตกแต่ละหน้าจอเป็นกล่องหรือ component ย่อย
แต่ละ block ควรมี:

ตัวอย่าง:

4.3 Journey Registry

เก็บเส้นทางการใช้งานของผู้ใช้
แต่ละ journey ควรมี:

ตัวอย่าง:

4.4 Data / Integration Registry

เก็บว่าแต่ละ screen หรือ block ใช้ข้อมูลอะไร
แต่ละ data item ควรมี:

4.5 Readiness Board

ใช้ดูสถานะจริงของงานแบบข้ามทีม
สถานะที่ควรมี:

5. ทำไมต้องใช้ระบบรหัสอ้างอิง

ถ้าจะให้ mapping งานต่าง ๆ ง่าย ต้องเปลี่ยนจากคำอธิบายลอย ๆ ไปสู่ระบบรหัสอ้างอิงทุกจุด

5.1 Screen ID

ใช้กับทุกหน้าจอ
เช่น:

5.2 Block ID

ใช้กับกล่องหรือ object ทุกตัว
เช่น:

5.3 Journey ID

ใช้กับ flow ของผู้ใช้
เช่น:

5.4 Data ID

ใช้กับ data source หรือ entity สำคัญ
เช่น:

5.5 Test Case ID

ใช้กับกรณีทดสอบ
เช่น:

เมื่อมีระบบรหัสแบบนี้ ทุกทีมจะอ้างอิงตรงกัน

6. Together Mode Architecture ที่ยืนยันใช้

โหมดที่ยืนยันใช้สำหรับ Together Super App V2 คือ 6 โหมด ดังนี้:

ลำดับความสำคัญที่แนะนำคือ:

  1. Trip
  2. MICE
  3. Rewards
  4. Services
  5. Stay
  6. Shopping

การจัดวางในหน้าจอ popup selector แบบ 2 รายการต่อแถว:

เหตุผลของลำดับนี้:

7. หลักคิดของ Together Mode

Together Mode ไม่ควรเป็นแค่ filter ธรรมดา แต่เป็น “ชั้นของเจตนาใช้งาน”

เมื่อผู้ใช้เลือก mode ระบบต้องเปลี่ยนอย่างน้อย:

ดังนั้น mode คือ “ชั้นคัดกรองประสบการณ์”
เป้าหมายคือทำให้ผู้ใช้รู้สึกว่า:
“ระบบเข้าใจว่ากำลังเข้ามาเพื่อทำอะไร”

8. Mode-by-Mode Content Matrix

8.1 Trip Mode

Trip Mode คือโหมดหลักสำหรับนักท่องเที่ยวที่ต้องการวางแผนเที่ยว ค้นหาสถานที่ ใช้ map และจัด itinerary

Trip Mode ควรเน้น:

คำอธิบาย:

Trip Mode ควรเปลี่ยนใน UI:

8.2 MICE Mode

MICE Mode เป็นโหมดสำหรับผู้ร่วมงานประชุม นิทรรศการ อีเวนต์ และ ecosystem เชิงธุรกิจ

MICE Mode ควรเน้น:

คำอธิบาย:

MICE Mode ควรเปลี่ยนใน UI:

8.3 Rewards Mode

Rewards Mode คือ incentive-driven mode ของแพลตฟอร์ม

Rewards Mode ควรเน้น:

คำอธิบาย:

Rewards Mode ควรเปลี่ยนใน UI:

8.4 Services Mode

Services Mode คือ utility และ support mode

Services Mode ควรเน้น:

คำอธิบาย:

Services Mode ควรเปลี่ยนใน UI:

8.5 Stay Mode

Stay Mode คือ hospitality mode สำหรับเรื่องที่พัก

Stay Mode ควรเน้น:

คำอธิบาย:

Stay Mode ควรเปลี่ยนใน UI:

8.6 Shopping Mode

Shopping Mode คือ commerce mode ของระบบ

Shopping Mode ควรเน้น:

คำอธิบาย:

Shopping Mode ควรเปลี่ยนใน UI:

9. Together Mode First Entry Screen Design Spec

หน้าจอแรกของระบบควรเป็นหน้าจอเลือก Together Mode

องค์ประกอบที่ควรมี:

ลำดับบน popup:

10. รายละเอียดของ Together Mode Cards

Trip

MICE

Rewards

Services

Stay

Shopping

11. Matrix ระดับภาพรวมของแต่ละ Mode

Mode Overview Matrix · 6 modes × 6 dimensions (User Intent · Hero · Quick Actions · Content Priority · Search Priority · Recommendation Priority)
Mode User Intent หลัก Hero หลัก Quick Actions หลัก Content Priority Search Priority Recommendation Priority
Trip วางแผนเที่ยว/หาที่ไป destinations / route / nearby plan trip, map, nearby, itinerary attractions, routes, local experiences places, districts, attractions nearby + itinerary + themed routes
MICE เข้าร่วมงาน/ดูงาน/จัดงาน live event / agenda / check-in register, check-in, agenda, venue sessions, speakers, exhibitors, sponsors event, agenda, booth, speaker session + role + event status
Rewards รับสิทธิ์/สะสม/แลก points / mission / campaign redeem, earn, mission, voucher points, perks, campaigns, nearby rewards reward, voucher, mission redeemables + campaigns + location
Services ขอความช่วยเหลือ/ใช้ utility support / essentials / assistance helpdesk, eSIM, transport, emergency utilities, support, assistance, insurance help, support, transport, assistance context-sensitive services
Stay ค้นหาที่พัก/จัดการเข้าพัก hotels / offers / bundles find stay, offers, nearby hotels hotel, offers, packages, check-in info hotel, room, area, package nearby stay + budget + area
Shopping ซื้อสินค้า/ดูร้าน/ข้อเสนอ featured products / stores / deals shop now, offers, stores, cart products, merchants, campaigns, offers product, merchant, category offers + merchants + browsing history

12. Matrix รายละเอียดของแต่ละ Mode

Trip Mode

MICE Mode

Rewards Mode

Services Mode

Stay Mode

Shopping Mode

13. สิ่งที่ Mode ต้องเปลี่ยนในระดับระบบ

Together Mode ต้องเปลี่ยนอย่างน้อย 8 จุด:

  1. Hero Layer
  2. Navigation Layer
  3. Recommendation Layer
  4. Search Layer
  5. Notification Layer
  6. Quick Action Layer
  7. Card Ranking Layer
  8. Analytics Layer

รายละเอียด:

13.1 Hero Layer

hero ต้องเปลี่ยนตาม mode
เช่น:

13.2 Navigation Layer

navigation หลักและเมนูย่อยต้องเปลี่ยนตาม mode
ไม่ควรใช้เมนูเดียวกันทั้งหมด

13.3 Recommendation Layer

recommendation ต้องเปลี่ยนตาม intent
เช่น:

13.4 Search Layer

search suggestion, chips, ranking และ defaults ต้องเปลี่ยนตาม mode

13.5 Notification Layer

notification ต้อง contextualize ตาม mode
เช่น:

13.6 Analytics Layer

analytics ต้อง track mode switching และ behavior แยกตาม mode

14. ตัวอย่างผลลัพธ์เชิง UX ที่ควรเห็นจริง

เมื่อเข้า Trip Mode

ควรเห็น:

เมื่อเข้า MICE Mode

ควรเห็น:

เมื่อเข้า Rewards Mode

ควรเห็น:

เมื่อเข้า Shopping Mode

ควรเห็น:

เมื่อเข้า Services Mode

ควรเห็น:

เมื่อเข้า Stay Mode

ควรเห็น:

15. Prompt สำหรับสั่ง Claude Code ออกแบบ Together Mode First Screen

ออกแบบหน้า popup selector สำหรับ “Together Mode” ของ super app โดยใช้ 6 modes ตามนี้:

  1. Trip
  2. MICE
  3. Rewards
  4. Services
  5. Stay
  6. Shopping

จัด layout แบบ 2 cards ต่อแถว รวม 3 แถว โดยเรียงดังนี้:

  • Trip | MICE
  • Rewards | Services
  • Stay | Shopping

เป้าหมายของหน้าจอ:

  • เป็น first screen ที่นักท่องเที่ยวเห็นแล้วเข้าใจทันทีว่าระบบช่วยอะไรได้
  • ลดความรกของ content โดยให้ผู้ใช้เลือก intent ก่อน
  • เมื่อเลือกแล้ว ระบบจะ filter content, main menu, hero, quick actions, recommendation, search suggestions และ notification context ตาม mode ที่เลือก

Look & Feel:

  • premium
  • modern
  • inviting
  • mobile-first
  • ใช้งานง่าย
  • ไม่แข็งแบบ dashboard องค์กร
  • ไม่รกแบบ marketplace หนักเกินไป

องค์ประกอบของหน้า:

  1. logo area
  2. headline
  3. subheadline
  4. mode grid
  5. footer actions
  6. remember my mode toggle

Headline:
“วันนี้ต้องการใช้ Together แบบไหน”

Subheadline:
“เลือกโหมดที่ตรงกับสิ่งที่ต้องการ แล้วระบบจะจัดเมนู คอนเทนต์ และบริการให้เหมาะกับการใช้งานมากที่สุด”

Helper text:
“สามารถเปลี่ยนโหมดได้ทุกเมื่อภายหลัง”

สำหรับแต่ละ mode card ให้มี:

  • icon ใหญ่
  • title
  • short tagline
  • 3 chips
  • CTA button
  • selected state
  • hover/tap animation แบบเบา ๆ

รายละเอียดแต่ละ mode:

Trip

  • tagline: “เที่ยว วางแผน และค้นพบสถานที่น่าสนใจได้ง่ายขึ้น”
  • chips: Attractions / Day Plans / Nearby Places
  • CTA: Start Exploring
  • icon direction: compass / map-route
  • color direction: sky / turquoise

MICE

  • tagline: “เข้างาน ดูกำหนดการ เชื่อมต่อผู้ร่วมงาน และใช้งานหน้างานได้สะดวก”
  • chips: Agenda / Check-in / Exhibitors
  • CTA: Enter Event Mode
  • icon direction: calendar-badge / stage
  • color direction: indigo / electric blue

Rewards

  • tagline: “สะสมแต้ม รับสิทธิพิเศษ และเข้าถึงรางวัลที่ออกแบบมาเพื่อการเดินทาง”
  • chips: Points / Missions / Redeem Now
  • CTA: View Rewards
  • icon direction: gift / coin-star
  • color direction: gold / coral / pink-gold

Services

  • tagline: “เข้าถึงบริการจำเป็น ความช่วยเหลือ และการสนับสนุนได้รวดเร็ว”
  • chips: eSIM / Helpdesk / Travel Support
  • CTA: Open Services
  • icon direction: concierge / headset-shield
  • color direction: teal / emerald

Stay

  • tagline: “ค้นหาที่พัก ดูข้อเสนอ และจัดการการเข้าพักได้อย่างมั่นใจ”
  • chips: Hotels / Room Offers / Stay Bundles
  • CTA: Find a Stay
  • icon direction: hotel / bed-key
  • color direction: navy / violet-night

Shopping

  • tagline: “เลือกดูสินค้า ข้อเสนอพิเศษ ของฝาก และร้านเด่นได้ในที่เดียว”
  • chips: Local Products / Featured Stores / Special Offers
  • CTA: Shop Now
  • icon direction: bag / storefront
  • color direction: orange / magenta

Footer actions:

  • Continue with default mode
  • Explore all content
  • Close

Behavior requirements:

  • selected state ต้องชัด
  • remember my mode toggle
  • สามารถเปลี่ยน mode ภายหลังได้
  • ต้องมี hook สำหรับ logic ต่อไปนี้:
    • hero switching
    • quick action switching
    • navigation filtering
    • recommendation context
    • search chip switching
    • notification context
  • เตรียม data structure หรือ config object รองรับ mode ทั้ง 6
  • ทำให้พร้อมต่อยอดกับระบบจริงได้ ไม่ใช่แค่ static popup

ขอ output เป็นงานออกแบบที่ดูเหมือนใช้งานได้จริงใน Together Super App V2

16. คำตอบเชิงโครงสร้างว่า “หลังจากนี้จะช่วยออกแบบระบบใช่ไหม”

ใช่ หลังจากจัด Design Management / Prototype Readiness ให้เป็นระบบแล้ว งานถัดไปควรต่อเป็น 4 ชั้นหลัก:

16.1 DB Structure

ออกแบบโครงข้อมูลกลาง เช่น:

เป้าหมายคือให้ทุกหน้าจอใน V2 อ้างอิงข้อมูลจากโครงเดียวกัน ไม่ใช่ผูกตายกับหน้า

16.2 System Design

ออกแบบสถาปัตยกรรมระบบ เช่น:

16.3 Add Content

ออกแบบวิธีเติม content ให้เป็นระบบ เช่น:

16.4 Tracking

วาง tracking ตั้งแต่ต้น เช่น:

เป้าหมายคือให้วัดได้ว่า:

17. 4-Layer Blueprint สำหรับ Together Super App V2

Layer A — Design Management Foundation

ชั้นนี้ทำให้ทุกอย่างอ้างอิงได้

A1. Screen Registry

ฟิลด์หลัก:

A2. Block Registry

ฟิลด์หลัก:

A3. Journey Registry

ฟิลด์หลัก:

A4. Readiness Board

สถานะ:

Layer B — Data & System Foundation

ชั้นนี้ทำให้สิ่งที่ออกแบบไว้เชื่อมกับระบบจริงได้

B1. Core Domain Model

B2. DB Structure ระดับแม่

กลุ่ม Platform Structure:

กลุ่ม Content:

กลุ่ม MICE:

กลุ่ม Trip / Stay / Shopping:

กลุ่ม Rewards:

กลุ่ม Support / Services:

กลุ่ม Identity / Governance:

กลุ่ม Tracking:

Layer C — Content Operating Model

ชั้นนี้ทำให้ระบบไม่ตันเพราะ content

C1. Content Types

C2. Content Status

C3. Content Mapping

ต้องตอบได้ว่า content ไหนไปอยู่:

C4. Content Source

C5. Content Governance

Layer D — Tracking & Optimization

ชั้นนี้ทำให้รู้ว่าระบบทำงานจริงไหม

D1. Event Taxonomy

D2. KPI Mapping

Trip:

MICE:

Rewards:

Services:

Stay:

Shopping:

18. สถาปัตยกรรมระบบที่แนะนำ

Frontend Layer

Application Layer

Data Layer

19. ลำดับเฟสที่ควรทำ

Phase 1 — Foundation

Phase 2 — Operational Prototype

Phase 3 — Integrated V2

Phase 4 — Live Readiness

20. สิ่งที่ควรทำเป็นเอกสารชุดถัดไป

  1. Prototype Design Readiness & Playbook
  2. DB Structure & Data Model Blueprint
  3. System Design & Integration Architecture
  4. Content Operations & Publishing Model
  5. Tracking Framework & KPI Matrix

21. สรุปเชิงกลยุทธ์

V1 ไม่ควรถูกรื้อทิ้ง เพราะ:

แต่ V1 ต้องถูก “ครอบ” ด้วยระบบอ้างอิงงานและ readiness framework ทันที

ข้อเสนอหลักของเอกสารนี้คือ:

ดังนั้น เอกสารฉบับนี้ควรถูกใช้เป็นฐานสำหรับ:

ท้ายที่สุด หากทำตามเอกสารนี้อย่างครบถ้วน Together Super App V2 จะไม่เป็นเพียง demo ที่ดูดี แต่จะมีโครงที่พร้อมต่อยอดเป็นระบบใช้งานจริงได้ในระดับที่ทีมงานหลายฝ่ายสามารถทำงานร่วมกันบน source of truth ชุดเดียวกันได้

Claude-added · Cross-links + Appendix

ส่วนนี้ ไม่ใช่ ข้อความของ ChatGPT · Claude เพิ่มเพื่อเชื่อมเอกสารเข้าระบบ marketing library · สามารถลบได้โดยไม่กระทบเนื้อหาหลัก.

ตำแหน่งของเอกสารนี้ใน Marketing track:

เอกสารนี้เชื่อมกับ Marketing #1–#5 อย่างไร:

เชื่อมกับงานถัดไปที่ Doc นี้บอกไว้ (§20):

ID Scheme snapshot (§5):

Readiness Board ladder (§4.5):

Concept → Designed → Reviewed → Content-ready → Dev-ready → In build → Integrated → Test-ready → UAT → Done

Publisher note: Claude มีบทบาทเป็น ingester + formatter + indexer เท่านั้น · ไม่แก้ wording ของ ChatGPT primary source · ทำเฉพาะ: HTML conversion (markdown → HTML list + heading + table), anchor IDs (21 main sections + sub-sections), TOC, metadata block, cross-links/appendix นี้, และ glossary ด้านล่าง · ตาราง §11 เป็นการแปลง markdown table → HTML table · symbol และ wording ในตารางยกมาจากต้นฉบับตรง ๆ · ข้อความต้นฉบับ §1–§21 ทุกตัวอักษรอยู่ครบไม่มีการลบหรือสรุป.

Claude-added · Glossary (optional)

คำศัพท์ที่ปรากฏบ่อยในเอกสารนี้ · สรุปให้ผู้อ่านไม่ใช่ technical stakeholder · ไม่ใช่ ข้อความต้นฉบับของ ChatGPT.

Screen Registry
ทะเบียนกลางของทุกหน้าจอในระบบ · เก็บ screen_id · screen_name · mode · platform · purpose · owner · status · related_modules · related_APIs · related_content_blocks · notes — §4.1, §5.1, §17-A1.
Block Registry
ทะเบียน component/กล่องย่อยในทุกหน้าจอ · เก็บ block_id · screen_id · block_name · block_type · display_priority · content_type · data_source · states · reusable · owner · readiness — §4.2, §5.2, §17-A2.
Journey Registry
ทะเบียน user flow · เก็บ journey_id · journey_name · entry_point · user_type · mode · step_sequence · exit_condition · success_metric — §4.3, §5.3, §17-A3.
Data / Integration Registry
ทะเบียน data source ที่แต่ละ screen/block เรียกใช้ · เก็บ data_id · source · owner · mock/static/live · api_dependency · update_frequency · related_screens · related_blocks — §4.4.
Readiness Board
กระดาน status รายงานความพร้อมข้ามทีม · 10 สถานะ (Concept → Designed → Reviewed → Content-ready → Dev-ready → In build → Integrated → Test-ready → UAT → Done) — §4.5, §17-A4.
Content Mapping
การผูก content เข้ากับ mode/screen/block พร้อม priority + target audience · ตอบได้ว่า content ชิ้นหนึ่งไปอยู่ที่ไหน · §17-C3.
Event Taxonomy
ชุด event ที่ระบบ track · เช่น mode_selected · screen_viewed · block_clicked · search_submitted · itinerary_saved · registration_completed · reward_redeemed · เป็น source of truth ของ tracking — §17-D1.
KPI Mapping
การ map KPI ต่อ mode — Trip (itinerary saves, map opens, …), MICE (registrations, check-ins, …), Rewards (mission starts, voucher redemptions, …), Services (helpdesk starts, eSIM clicks, …), Stay (hotel views, booking intent, …), Shopping (product views, add to cart, …) — §17-D2.
4-Layer Blueprint
ชั้นงานหลัก 4 ชั้นของ Super App V2 · Layer A Design Management · Layer B Data & System · Layer C Content Operating · Layer D Tracking & Optimization — §17.
6-Mode Set (confirmed)
ชุด mode ที่ยืนยันใช้สำหรับ V2 ตาม §6 · Trip · MICE · Rewards · Shopping · Services · Stay · popup layout 2×3: Trip|MICE / Rewards|Services / Stay|Shopping.
8 Layers ที่ Mode ต้องเปลี่ยน
Hero · Navigation · Recommendation · Search · Notification · Quick Action · Card Ranking · Analytics — §13 (เพิ่มจาก 6 layers ของ Doc #5 ด้วย Quick Action + Card Ranking).
4-Phase Rollout
Phase 1 Foundation (Registries + Mode Definition + Core DB + Content type) · Phase 2 Operational Prototype (Mode selector + mode-based home + mock binding + base tracking) · Phase 3 Integrated V2 (API + RBAC + content workflow + commerce connections + support) · Phase 4 Live Readiness (QA/UAT + dashboard + content ops + analytics review + pilot) — §19.
← Marketing library · Marketing #1 · Marketing #2 · Marketing #3 · Marketing #5 · Main Console