Changelog — v1

v1.0.8 — 2026-10-14

• Published Roadmap in the site header and Project Management. Delivery plan is not a /next draft. v1 playbook winners unchanged.

Who implements

Team	Action
All	Use the header Roadmap for dates. Keep implementing v1 winners until a next row is promoted

v1.0.7 — 2026-10-11

• Greenfield rebuild drafts on next: email template matrix (no TSX dump), booking IDs, MelonQ hosts, subdomain engine, ARI SSOT. v1 winners unchanged.
• Amenities stay the local slug catalog. Content APIs store ticks; they do not serve the picker list.

Who implements

Team	Action
All	Review /next before promoting. Do not treat MelonQ / inventory SSOT as published winners
Frontend	Keep local slugs. Do not fetch an amenity catalog API
Middleware Backend	Emails folder is live on explorer (POST .../emails/send) — promote via next changelog
Core Backend	No change this pass

v1.0.6 — 2026-10-08

• Search indexes: category / tags / metadata vs Middleware. City via search_by=meta_key.city; one amenity via tags=amenity_{slug} (tags=a,b is OR). Example Core GETs + after-filter for Middleware.
• Frontend hard-codes a local amenity tick list (slugs). Extranet and Marketplace must stop sending labels / wifi / pool.
• Specs: Core fetchAll tags / categories / search_by; Middleware list amenities slugs.
• Live Middleware explorer remount (/api/v1/bookdirect/properties) recorded under limitations — not rewritten this pass.

Who implements

Team	Action
Frontend	Copy lib/amenity-catalog.ts from the tick list. Picker + search id = slug. GET .../properties?amenities=swimming_pool,free_parking. Map legacy labels once on edit
Middleware Backend	On property write: city meta, amenity_* meta + tags, optional location_city_* / policy_* mirrors, min_rate_ngn. List: Core narrow (example on properties); AND extra slugs; price/dates/rooms/guests in process
Core Backend	Stay generic fetchAll. Do not add an amenities table. Optional later: tag AND, status=active, numeric min_rate_ngn

v1.0.5 — 2026-09-18

• Project Management (PM) playbook: overview, activation matrix, ENV / Metadata Catalog index. PM means turning a feature on (status, winner URL, ENV names, Core metadata) — not a product-manager story.

Who implements

Team	Action
Project Management	Use the activation matrix to turn a screen or function on; set names from the catalogs — never paste secrets
Frontend	Switch remaining Core smart-meta-manager property/booking writes to the Middleware winners in the matrix
Middleware Backend	Keep live folders as winners; refunds / emails / google-rates stay off until they are in routes.json
Core Backend	Stay generic; path-settings IDOR only — do not assign IDOR to the Next.js app

v1.0.4 — 2026-09-18

• Frontend is Next.js (Marketplace + Extranet), not Vue/Convex. Screens / Pages and Logic / Functions under each app. ENV / Metadata Catalog on every playbook.
• Middleware Backend live folders (explorer): properties, rates-packages, bookings, availability, payments (incl. wallet), reservations, file-manager. Those are winners. Core smart-meta-manager create property/booking is “called by Middleware.”
• Who implements: Frontend switch remaining Core SMART_META calls to Middleware; Middleware keep refunds/emails/google-rates off until folders exist; Core stay generic + path-settings IDOR.

v1.0.3 — 2026-09-12

• Display names: Core Backend and Middleware Backend (paths unchanged: /v1/core/, /v1/middleware/).
• GitHub Pages workflow runs only on the deploy-github-pages branch.

v1.0.2 — 2026-09-12

• Playbooks are how to build each layer.
• IDOR only on Core Backend API-key path settings and Middleware Backend. Frontend browse x-api-key is public. Do not assign IDOR to Vue; if a control is missing, recommend it on Core Backend/Middleware Backend.

v1.0.1 — 2026-09-12

Framing pass (no winner-URL moves).

• Product: PMS — hotels, shortlets, and apartments are all property (property_category).
• Three equal playbooks: Frontend (screens), Middleware Backend (processors, webhooks, workers), Core Backend (recommended Nellalink usage / do-not-add).
• Home and v1 overview lead with all three; not frontend-only.

Who implements

Team	Action
Product	Read playbooks as guest/owner flows
Frontend	Screens against winner URLs
Middleware Backend	Folders + workers from the Middleware Backend playbook
Core Backend	Stay generic; follow recommended usage

v1.0.0 — 2026-09-12

First published lodging docs.

• Architecture: frontend → Core Backend for auth/CRUD; frontend → Middleware Backend for processors; Middleware Backend → Core Backend to persist.
• Frontend playbooks: sign up/login, owner property setup, guest search, checkout/pay, manage booking — each step has one winner URL.
• Core Backend conventions: property, room, rate_plan, booking, payment + metadata catalog.
• Middleware Backend contracts (to implement except file-manager): availability, payments, refunds, emails, google-rates.
• Hosting: /v1 stable, /next drafts. Iteration prompt + IDOR checklist.

Who implements

Team	Action
Frontend	Build screens against winner URLs (stop new Convex-only features)
Middleware Backend	Implement route folders from specs/middleware/v1
Core Backend	Stay generic; consider object-level ACL on GET/PUT entity by uuid (IDOR)