# INVEETAIRE ## DESIGN REVISION PACK Version : 1.0 Status : Pending Review Document Type : Design Revision Proposal Created After : - Product Discovery - Product Vision - PRD v1.1 - SAD v1.1 - DDD Conceptual v1.0 - DDD Logical v1.1 - Development Blueprint (DBP v1.0) - Physical Database Design (PDD v1.0) - Architecture Decision Records (ADR v1.0) - Master Implementation Backlog (MIB v1.0) - Technical Coding Standards (TCS v1.0) --- # Purpose This document records architectural improvements and design refinements discovered after the initial architecture freeze. These improvements were identified during the implementation planning phase (Master Implementation Backlog) and have **NOT** yet been merged into the official architecture documents. This document acts as a temporary review buffer. No official documentation shall be modified until every revision listed in this document has been reviewed and approved. After approval, the changes will be incorporated into: - PRD - SAD - DDD - PDD - ADR This document will then become obsolete. --- # Revision Status Current Status Pending Review Architecture Freeze Maintained Implementation Not Started Breaking Changes None Database Impact Minor Module Impact Medium --- # Revision 001 ## Promote Wedding Event as First-Class Entity ### Background Originally, Guests were modeled as the primary operational entity. During implementation planning, it became clear that almost every operational module revolves around individual wedding events rather than the workspace itself. Examples include: - Holy Matrimony - Reception - Engagement - Sangjit - Tea Ceremony - After Party ### Proposal Workspace contains one or more Wedding Events. Wedding Events become the second aggregate root after Workspace. Every operational module references Wedding Events instead of directly referencing Workspace whenever appropriate. ### Benefits - Unlimited event support - Future-proof architecture - Cleaner dashboard aggregation - Better reporting - Better operational separation ### Impact PRD SAD DDD PDD --- # Revision 002 ## Guest Event Assignment ### Background Guests should not be limited by hardcoded invitation types. ### Proposal Guests are assigned to one or more Wedding Events. Examples Guest A ✓ Holy Matrimony ✓ Reception Guest B ✗ Holy Matrimony ✓ Reception Guest C ✓ Engagement ### Benefits No hardcoded event logic. Unlimited event flexibility. Cleaner database. ### Impact DDD PDD Guest Module RSVP Check-in Communication Reports --- # Revision 003 ## Dynamic Invitation Rendering ### Background Invitation pages should not be built around invitation types. Instead, they should dynamically render invited events. ### Proposal Invitation Engine renders: Guest × Assigned Wedding Events The invitation automatically displays all events assigned to the guest. ### Benefits Single rendering engine. Unlimited events. Simpler themes. Future-proof. ### Impact PRD SAD Invitation Module Theme Engine --- # Revision 004 ## Unified Guest Experience ### Background Guests should never experience multiple invitations for one wedding. ### Proposal Every guest receives - One Invitation URL - One Guest Code - One QR Code - One Invitation Journey Invitation content changes dynamically according to assigned events. ### Benefits Simple user experience. Less confusion. Better communication. ### Impact Invitation Communication QR Guest Journey --- # Revision 005 ## Event-Specific Operational Data ### Background Although guests experience one invitation, operational data should remain separated. ### Proposal The following become Event-specific: - RSVP - Attendance - Check-in - Dashboard - Statistics - Reports ### Benefits Accurate reporting. Operational clarity. Real-time monitoring. ### Impact Dashboard Reports Wedding Day RSVP --- # Revision 006 ## Unified Reminder Communication ### Background For weddings occurring on the same day, guests should not receive multiple reminder messages. ### Proposal One guest receives one reminder. The reminder dynamically summarizes every invited event. Example Holy Matrimony 09:00 Reception 18:00 ### Benefits Cleaner communication. Less spam. Better guest experience. ### Impact Communication Reminder Invitation --- # Revision 007 ## Event Dashboard Separation ### Background Couples need statistics for every event independently. ### Proposal Dashboard provides: Overall Workspace ↓ Individual Event Cards Example Holy Matrimony Invited RSVP Present Reception Invited RSVP Present ### Benefits Better operational awareness. Better reporting. ### Impact Dashboard Reports Analytics --- # Revision 008 ## Event Context for Crew ### Background Reception crews normally work only for one event. ### Proposal Crew logs into a specific Wedding Event. Example Holy Crew Reception Crew Check-in automatically validates guests against the active event. ### Benefits Faster workflow. Less operator mistakes. Cleaner dashboard. ### Impact Crew Authentication Wedding Day QR --- # Revision 009 ## Vendor Event Assignment (Optional) ### Background Some vendors serve only one event. Others serve all events. ### Proposal Vendor may optionally be assigned to one or more Wedding Events. Examples Pastor Holy Matrimony Band Reception EO All Events ### Status Optional Future Review Required ### Impact Vendor Module Timeline Budget --- # Summary of Affected Documents | Document | Revision Required | |------------|------------------| | PRD | Yes | | SAD | Yes | | DDD | Yes | | PDD | Yes | | ADR | Yes (ADR-026) | | MIB | Minor Review | | TCS | No | --- # Approval Workflow Design Review ↓ Approval ↓ PRD v1.2 ↓ SAD v1.2 ↓ DDD v1.2 ↓ PDD v1.1 ↓ ADR-026 ↓ Final Architecture Freeze ↓ Sprint 0 Development --- # Final Statement This Design Revision Pack documents architectural improvements identified after the initial design freeze. No revision contained within this document becomes official until formally reviewed and approved. Once approved, all accepted revisions shall be merged into the official project documentation. After integration, this document serves as historical reference only and should not be modified further.