# G014.1 — Live Preview UX & Production Parity

You are acting as the Lead Product Engineer for INVEETAIRE.

The Live Preview engine has already been implemented.

Your task is NOT to redesign it.

Your task is to ensure that Live Preview behaves exactly according to the original product vision before Version 1.0.

This sprint focuses on user experience, production parity, and read-only behavior.

Do not redesign the routing architecture.

Do not redesign the renderer.

Do not redesign the Preview feature.

---

# Objective

Ensure that Live Preview is a true production preview of the invitation.

The Couple should experience exactly what their guests will see after publication, while preventing any write operations.

Live Preview must become the canonical "preview before publish" experience.

---

# Live Preview Concept

Live Preview is NOT another Preview.

Preview and Live Preview intentionally serve different purposes.

## Preview

Purpose:

Editing experience.

Characteristics:

- Device simulator
- Preview Shell
- Toolbar
- Zoom controls
- Device switching

This remains part of the Builder.

---

## Live Preview

Purpose:

Experience the invitation exactly as guests will.

Characteristics:

- Standalone page
- Production renderer
- Same layout as production
- Same sections
- Same theme
- Same assets
- Same responsive behavior

No device simulator.

No Preview Shell.

No Builder UI.

No editing controls.

The URL must be:

```
/{workspace_slug}/livepreview
```

---

# Production Parity

Live Preview must reuse the exact production renderer.

It must not have its own template.

It must not duplicate rendering logic.

The rendered output should be visually identical to the future guest invitation.

---

# Read-Only Mode

Live Preview is production rendering running in Preview Mode.

All read operations are allowed.

All write operations must be disabled.

Specifically:

## Disable

- RSVP submission
- Guest Book submission
- QR attendance
- Analytics tracking
- Visitor tracking
- Any database write

---

## Allow

- Theme rendering
- Gallery
- Countdown
- Maps
- Story
- Timeline
- Music
- Event schedule
- Wishes display
- Couple profile
- All invitation sections

Everything visible to guests should also be visible in Live Preview.

---

# Multiple Events

If the invitation contains:

- Holy Matrimony
- Tea Pai
- Reception

Live Preview should render all configured events exactly as production would.

Do not hide sections based on publication state.

---

# Guest Book

Display existing wishes.

Example:

```
Congratulations!

Happy Wedding!

Best Wishes!
```

The submission form must not create new wishes.

Preferred behavior:

- Disable inputs

or

- Hide submission controls

Explain which approach provides the better user experience.

---

# RSVP

Display the RSVP section.

Prevent confirmation submission.

No attendance records should be created.

---

# Live Preview Badge

Review whether a minimal informational badge should appear.

Example:

```
👁 Live Preview

Read-only

No analytics

No submissions
```

The badge should be subtle.

It must not change the overall invitation layout.

If a better solution exists, explain why.

---

# Verification

Verify:

- Production renderer reused
- No duplicated templates
- No duplicated business logic
- No write operations
- Read-only behavior
- Responsive layout identical to production

---

# Deliverables

Please provide:

## 1.

Architecture review

Does Live Preview fully reuse the production renderer?

---

## 2.

Production parity review

Identify any visual or behavioral differences from the public invitation.

---

## 3.

Read-only review

List every interaction that must be disabled.

---

## 4.

UX recommendations

Recommend any improvements before Version 1.0 while preserving production parity.

---

## 5.

Implementation summary

Describe any code changes required.

Prefer minimal, maintainable improvements.

Do not redesign the routing architecture.

Do not redesign Preview.

Do not introduce unnecessary abstractions.