# Sprint G008 — QR Attendance Engine

## Objective

The following modules have already been completed:

- G004 — Media Engine
- G005 — Image Processing Engine
- G006 — Guest & Invitation Engine
- G007 — Music Engine

Do NOT redesign any existing architecture.

Your responsibility is to review the current implementation first, then extend it into a production-ready QR Attendance Engine.

This sprint must integrate naturally with the existing Guest Engine.

---

# Phase 1 — Architecture Review (Mandatory)

Before writing any code, review the current implementation.

Analyze:

- Guest Engine
- Public Invitation
- Media Engine
- Music Engine
- Invitation Builder
- Existing routing
- Existing controllers
- Existing models
- Existing services

Determine whether the current architecture is suitable.

If it already is:

- Extend it.
- Do NOT redesign it.
- Only introduce changes when there is a clear architectural benefit.

---

# Objective

Each Guest Invitation should support QR Attendance.

Each Guest owns exactly one QR Code.

The QR identifies the invitation.

The QR will later be scanned during event check-in.

---

# QR Generation

Each Guest should have one QR Code.

Review the existing Guest architecture first.

Determine whether QR should be generated:

- Automatically
- Lazily
- Cached
- Generated on demand

Choose the approach that best fits the current architecture.

Avoid unnecessary storage duplication.

---

# QR Content

Do NOT expose internal database IDs.

Reuse the existing Guest Token whenever appropriate.

The QR should uniquely identify a guest invitation while remaining compatible with future Public Identity improvements.

---

# QR Download

Inside Guest Management add:

- Download QR

The QR should:

- High resolution
- Square
- Printable
- Suitable for stickers or cards

Support PNG.

Design the implementation so PDF export can be added later without refactoring.

---

# Public Validation Endpoint

Implement a lightweight endpoint capable of validating QR payloads.

Do NOT implement attendance recording yet.

This endpoint should only resolve:

Guest

↓

Invitation

↓

Workspace

↓

Validation Result

The endpoint must not expose unnecessary data.

---

# Dashboard Integration

Extend Guest List naturally.

Each Guest should support:

- Preview
- Copy Link
- Download QR

Maintain the existing UI.

---

# QR Rendering

The QR should include:

- Quiet zone
- Error correction suitable for printed media
- High readability

Avoid embedding logos inside the QR in this sprint.

---

# Performance

Avoid regenerating QR repeatedly.

Reuse generated assets whenever possible.

If regeneration is required, only regenerate when the payload changes.

---

# Security

Review:

- Guest Token validation
- Public endpoint
- Unauthorized access
- Rate limiting considerations
- QR forgery prevention

Improve only where necessary.

---

# Future Compatibility

Design the architecture so future sprints can easily add:

- QR Scanner
- Attendance Recording
- Check-in Time
- Operator Dashboard
- Multiple Entry Gates
- Offline Validation
- Event Analytics

without requiring architectural refactoring.

---

# Deliverables

Produce:

- Updated Guest module
- QR generation service
- Download endpoint
- Validation endpoint
- Updated Guest List UI
- Technical documentation

Only create database migrations if absolutely necessary.

---

# Validation

Before completing the sprint:

- Verify every modified file.
- Ensure no syntax errors.
- Verify QR generation.
- Verify QR download.
- Verify public validation endpoint.
- Verify Guest compatibility.
- Verify Public Invitation compatibility.
- Verify Media Engine compatibility.
- Verify Music Engine compatibility.
- Verify backward compatibility.

---

# Important

This sprint extends the existing architecture.

Do NOT redesign the application.

Prioritise:

- Maintainability
- Scalability
- Security
- Backward Compatibility
- Minimal Breaking Changes

Always review the current implementation before introducing modifications.