# G014.1 — Routing Architecture Audit & Dashboard URL Enhancement

You are acting as the Principal Software Architect for INVEETAIRE.

This is NOT a coding task first.

Your primary responsibility is to review the routing architecture before Version 1.0 is released.

Challenge existing decisions if necessary.

Do not assume the current routing structure is correct.

Review the architecture as if this platform will serve thousands of wedding invitations.

Prioritize:

- Maintainability
- Scalability
- Security
- URL consistency
- Developer Experience
- Couple Experience
- Future extensibility

Only after completing the architectural review should you propose implementation changes.

## Objective

Perform a complete routing audit for INVEETAIRE while implementing the new Dashboard Invitation URL Card.

The goal is to ensure that all public-facing URLs are clean, consistent, scalable, and easy for Couples to understand before Version 1.0 is released.

Do not simply add another route.

Review the entire routing architecture.

---

# Part 1 — Dashboard URL Card

Add a new dashboard card:

```
🌐 Your Invitation
```

Display:

## Invitation Slug

Example

```
/david-nathasya
```

---

## Live Preview

Example

```
https://inveetaire.com/david-nathasya/livepreview
```

Buttons

- Open
- Copy

Always available, including Draft Mode.

---

## Public Invitation

Example

```
https://inveetaire.com/david-nathasya
```

If Draft

Show:

```
Available after Publish
```

If Published

Enable:

- Open
- Copy

---

## Invitation Status

Show current status

- Draft
- Published
- Archived

using the existing status field.

---

# Part 2 — Routing Architecture Review

Audit ALL current routes.

Review:

## Public Routes

Example

```
/i/{slug}/{guestToken}
```

Determine whether this is still the best URL structure.

---

## Couple Routes

Current examples

```
/app/couple/dashboard

/app/couple/invitation/edit

/app/couple/invitation/media

/app/couple/invitation/livepreview
```

Review consistency.

---

## Preview Routes

Current

```
Preview

Live Preview
```

Determine whether both should share a common preview shell.

---

## Public Invitation

Review whether a cleaner URL structure is possible.

Examples

```
/{workspace_slug}
```

instead of

```
/i/{workspace_slug}/{guest_token}
```

If guest tokens remain necessary, explain why.

---

## Live Preview

Review whether

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

is the best long-term route.

Remember:

Only authenticated Couples may access it.

Draft Mode must remain supported.

---

## Admin / Internal URLs

Verify internal routes are grouped consistently.

Example

```
/app/couple

/app/admin

/app/api
```

Review naming consistency.

---

# Part 3 — Routing Standards

Verify:

- Naming consistency
- RESTfulness
- Route grouping
- Middleware grouping
- URL readability
- SEO friendliness
- Future scalability

Identify any routes that should be renamed BEFORE v1.0.

---

# Part 4 — Slug Usage

Review how workspace slugs are currently used.

Verify there is only ONE canonical slug.

The slug should become the primary public identifier.

Avoid duplicate slug generation logic.

---

# Part 5 — Future Scalability

Review whether the routing structure can naturally support future features such as:

```
/{slug}

/{slug}/livepreview

/{slug}/share

/{slug}/gallery

/{slug}/guestbook

/{slug}/checkin

/{slug}/qr

/{slug}/story
```

Do NOT implement these.

Only evaluate whether the current routing architecture can accommodate future expansion cleanly.

---

# Deliverables

Please provide:

## 1.

Current routing map

---

## 2.

Recommended routing map

---

## 3.

Architecture review

Strengths

Weaknesses

Potential conflicts

---

## 4.

Dashboard URL Card implementation

---

## 5.

Any routing improvements recommended before Version 1.0.

Maintain backward compatibility wherever possible.

Prefer evolving the routing architecture rather than introducing breaking changes unless there is a strong architectural reason.