feat: scaffold holiday booking project

06-admin-console.md

@@ -0,0 +1,80 @@
+# 06. Admin Console
+
+## Purpose
+
+Define the back office screens and admin actions needed to run the business.
+
+## Scope
+
+- Secure admin login.
+- Property management.
+- Image management.
+- Amenity management.
+- Pricing management.
+- Availability management.
+- Booking management.
+- Payment record view.
+- Enquiry management.
+- Content page management.
+- Testimonial management.
+- Site settings.
+
+## Proposed Admin Structure
+
+### Core Admin Areas
+
+- Dashboard / overview
+- Properties
+- Availability and pricing
+- Bookings
+- Payments
+- Enquiries
+- Content pages
+- Testimonials
+- Site settings
+
+### Admin Actions
+
+- Create, edit, publish, unpublish, and archive properties.
+- Upload, reorder, and remove property images.
+- Add and assign amenities.
+- Set and override pricing rules.
+- Add availability blocks and exceptions.
+- Review bookings and payment records.
+- Read and manage enquiries.
+- Edit static pages and testimonials.
+- Update site-wide settings and defaults.
+
+### Admin Guardrails
+
+- Admin login is required for all back office actions.
+- Sensitive changes should be scoped by role or privilege if roles are added later.
+- The admin cannot silently break the booking/payment truth model.
+
+## What Needs to Be Done
+
+- Define the admin navigation and main screens.
+- Define CRUD operations for each managed entity.
+- Define admin permissions and safe defaults.
+- Define which screens need audit or status history.
+- Define what the admin can override and what they cannot.
+- Define which booking/payment states are editable versus read-only.
+- Define whether audit history is required for important admin changes.
+
+## Acceptance Criteria
+
+- Every admin requirement from the spec is mapped to a screen or action.
+- The admin surface is grouped in a way that matches day-to-day usage.
+- Sensitive changes have clear rules and boundaries.
+- The admin plan supports future implementation without redesigning the workflow.
+- The admin model does not conflict with booking, payment, or availability rules.
+
+## Dependencies
+
+- Content architecture and data model.
+- Booking, availability, and pricing.
+- Payments and notifications.
+
+## Notes
+
+- Any admin override needs a clear rule to avoid conflict with booking or payment state.