# 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.