Foundations - Senior Full-Stack Dev(PHP / CodeIgniter)

Scope is attached. Fixed quote only. We do not do calls. Please review the scope and ask questions. We are happy to answers. Please provide estimated timeline and be transparent about quotes. I can negotiate with the right candidate This scope has been narrowed down to unblock some other work. So please review in full if interested Foundations – Build Unlock Layer v1.1 (FINAL) ________________________________________ 1. Scope Identity Scope Name: Foundations – Build Unlock Layer Version: v1.1 (Final) Purpose: Deliver the minimum correct structural foundation required to unblock Agenda Phase 3 while preserving long-term architectural integrity and preventing future schema rework. ________________________________________ 2. Objective This scope establishes the core system structure required to support: • multi-organization readiness • multi-hotel assignment • hotel-based context resolution • hotel-level data isolation • foundational role / position / department structure • compatibility with future Agenda and permission systems This scope is intentionally designed to: • enable forward development immediately • avoid enterprise-level overbuild • defer enforcement and hardening layers to a later phase ________________________________________ 3. Core Principle (Non-Negotiable) Simplify enforcement, NOT structure. All structural elements must be implemented correctly. Enforcement, refactoring, and enterprise hardening are intentionally deferred. ________________________________________ 4. Mandatory Structural Deliverables ________________________________________ 4.1 Multi-Organization Base Model • Create Organization entity • Each Hotel must belong to an Organization • Remove reliance on hard-coded firm_id in new architecture • Organization structure must be usable and extensible ________________________________________ 4.2 User ↔ Hotel Many-to-Many Assignment • Implement user_hotel join table • Support: o multiple hotels per user o multiple users per hotel • Include: o active / inactive assignment flag o unique constraints (no duplicate assignments) o indexed join columns ❗ Single-hotel foreign key on users is NOT allowed ________________________________________ 4.3 Roles (Lightweight – Structure Only) • Create Role entity • Allow role assignment capability • Roles must be structurally independent ✔ Must support future permission mapping ❌ Full RBAC enforcement NOT required in this phase ________________________________________ 4.4 Positions (Hotel-Level) • Create Position entity • Positions belong to a hotel • Implement user ↔ position assignment • Support: o multiple positions per user o active / inactive assignments ❗ Positions may NOT be collapsed into roles ________________________________________ 4.5 Departments (Hotel-Level) • Create Department entity • Departments belong to a hotel • Positions must link to departments ❗ Departments may NOT be free-text fields ________________________________________ 4.6 Session Context System System must support: • active organization context • active hotel context • ability to switch active hotel • session persistence of active hotel • context resolution per request This must be reliable enough for multi-hotel operation. ________________________________________ 4.7 Cross-Hotel Data Isolation (Critical) • All data must respect active hotel context • No cross-hotel data leakage permitted • Queries must resolve against active hotel ❗ This is a hard requirement ________________________________________ 4.8 Hotel Time Zone Standard • Each hotel must store IANA time zone (e.g., America/New_York) • Active hotel context must return time zone • No system-default fallback allowed ________________________________________ 4.9 Object Identification Standard The following entities must include: • UUID (primary immutable identifier) • Human-readable reference ID Applies to: • Users • Organizations • Hotels • Roles • Departments • Positions ID generation must be consistent and centralized. ________________________________________ 4.10 Minimal Admin Configuration Surfaces Provide basic UI for: • organization ↔ hotel linkage • user ↔ hotel assignment • role setup (basic) • department CRUD • position CRUD Requirements: • fully functional on Desktop • must not break on Tablet or Mobile • minimal UI is acceptable (no polish required) ________________________________________ 4.11 Bootstrap / Safe Defaults System must seed: • Admin role • Default Department: Operations • Default Position: General Manager System must not allow unusable empty state. ________________________________________ 5. Critical Structural Guardrails (Non-Negotiable) The following are strictly prohibited: • single-hotel shortcut in place of join table • collapsing positions into roles • collapsing departments into text fields • bypassing hotel context in data queries • ad-hoc identifier generation • hardcoding architecture instead of relational modeling ________________________________________ 6. Explicit Exclusions (IMPORTANT) The following are NOT included in this phase: ❌ Permission Hardening • full RBAC system • full permission mapping engine • default-deny enforcement ❌ Middleware & Global Enforcement • system-wide permission middleware • global authorization refactor ❌ Legacy Refactor • rewriting all controllers • removing all hard-coded logic across system ❌ Audit Logging • append-only audit system • before/after tracking • audit enforcement ❌ Enterprise Guarantees • zero-hardcoded system certification • full architecture compliance guarantees • Phase 3 liability enforcement ________________________________________ 7. Regression Boundaries The implementation may NOT: • break login • break session persistence • break authentication flow • introduce cross-hotel leakage • make existing system unusable ________________________________________ 8. Deliverable Artifacts (Required) Developer must provide: • migration files • list of affected tables • list of affected models • list of affected controllers/services • updated ERD or schema diagram • brief before/after summary ________________________________________ 9. Demonstration Requirements Before approval, developer must demonstrate: • organization → hotel relationship working • user assigned to multiple hotels • active hotel context switching • correct hotel-based data separation • position assignment functioning • department structure functioning • hotel time zone stored and retrievable • UUID/reference IDs present This is to validate structure, not full enforcement. ________________________________________ 10. Completion Definition This scope is complete ONLY when: • data model is correctly implemented • multi-hotel assignment works • context switching works • hotel isolation works • positions and departments function • identifiers and time zones exist • admin setup is usable • system is ready to support Agenda ________________________________________ 11. Non-Acceptance Conditions The following will result in rejection: • single-hotel user model • missing join tables • free-text positions or departments • broken or unreliable context switching • missing time zone support • missing UUID/reference ID system • non-functional admin setup • placeholder or unused implementations ________________________________________ 12. Agenda Compatibility Protection (CRITICAL) This scope MUST preserve all structural dependencies required for Agenda. This phase may defer: • enforcement • governance • audit But it may NOT defer: • structure • relationships • context • isolation