PhpStorm Agent Prompt Pack: Company Admin Reception Readiness

📄 General
← Back to Documentation
# PhpStorm Agent Prompt Pack: Company Admin Reception Readiness Run these prompts in order. Use a fresh agent task for each numbered prompt. Do not combine steps: the acceptance criteria of one step are the safety baseline for the next. ## Shared instruction block Prepend this block to every prompt below: > Work only in the non-Filament `company-admin` web panel and its directly used > models/services/tests. Preserve unrelated working-tree changes. Before editing, > inspect the relevant routes, controllers, models, migrations and existing tests. > Do not bypass tenant/global scopes as a substitute for authorization. Use explicit > authorization and return 403/404 deliberately. Add focused feature/unit tests for > every behavioral fix. Run the narrowest applicable test suite and static checks. > If the local runtime cannot execute tests, state the exact blocker and still > provide the commands to run under PHP 8.3+. Finish with: files changed, behavior > changed, tests run, and remaining risks. --- ## 1. Establish a safe baseline and map authorization > Audit tenant authorization in the non-Filament company-admin panel before making > broad changes. Identify every use of `withoutGlobalScopes()` and every commented > or missing company/workspace ownership check in `CompanyAdminController` and the > dedicated company-admin controllers. Define a consistent authorization approach: > selected company/workspace, explicit resource ownership, and super-admin bypass > only where intended. Do not silently change behavior yet except to add tests or > a small reusable authorization helper if it makes the next task safer. Produce a > concise map of affected actions and propose the minimal implementation plan. Acceptance criteria: - A complete list of affected resource actions and their tenant columns/relations. - Tests demonstrate the existing cross-tenant behavior where safely possible. - A reusable approach is selected; no global-scope bypass remains undocumented. ## 2. Restore tenant isolation for bookings, stays and rooms > Implement the authorization approach from the previous task for company-admin > booking, stay, venue and venue-object actions. Replace unsafe > `withoutGlobalScopes()->find(...)` plus commented 403 checks with scoped lookup > and/or explicit authorization. A regular company user must not view, edit, > check in/out, cancel, add guests to, or change rooms for another company’s data. > Preserve legitimate super-admin access intentionally and test it separately. Acceptance criteria: - Cross-company access returns 403 or 404 consistently for all listed actions. - Same-company actions continue to work. - Super-admin behavior is explicit and covered by tests. - No controller action changes the selected company based solely on an untrusted > resource ID. ## 3. Restore tenant isolation for finance, guests and catalog data > Extend the same authorization policy to company-admin invoices, payments, fiscal > receipts, clients, guests, services, packages, products, facilities, documents, > room blocks and B2B invoices. Verify nested resource IDs are also owned by the > selected company/workspace. Do not use `exists:table,id` validation without a > company-scoped ownership check for foreign IDs. Acceptance criteria: - Cross-tenant read and write attempts fail safely. - Foreign-key inputs such as venue, room, client and booking cannot reference a > different tenant. - Tests cover at least one read and one mutation in every resource family. ## 4. Repair broken company-admin routes and route-model binding > Repair known route defects in the non-Filament company-admin panel. Move static > routes before wildcard routes, particularly > `/company-admin/stays/available-venue-objects`. Correct the add-guest-to-stay > route/model-binding mismatch (`{stayId}` vs `Stay $stay`). Inventory all routes > whose controller signatures use implicit binding and ensure route parameter names > match. Add route constraints for numeric IDs where they prevent static-route > collisions without breaking UUID/slug resources. Acceptance criteria: - `GET /company-admin/stays/available-venue-objects` reaches its JSON controller. - Adding a guest resolves the requested stay and never a blank model. - A route test suite protects static-before-wildcard ordering and binding behavior. ## 5. Repair the B2B invoice UI-to-route contract > Make the existing non-Filament B2B invoice screens fully routable. The controller > already has create, store, edit, update, send, mark-paid and cancel actions, but > the route group exposes only index and show. Add the missing routes with correct > HTTP verbs, authorization and draft/status guards. Verify every named route used > by `resources/views/company-admin/b2b-invoices` is declared and every declared > action is reachable from an appropriate screen. Acceptance criteria: - No `route('company-admin.b2b-invoices.*')` reference is undefined. - Draft invoices can be created/edited; sent/paid/cancelled states follow valid > transitions. - Company isolation and tests cover each mutation route. ## 6. Consolidate availability into one transactional service > Build or complete a single availability service used by booking creation/editing, > stay creation/extension, room assignment/change and room blocks. Its availability > result must account for confirmed/active bookings, active stays, room-block dates, > housekeeping state and maintenance/out-of-order state. Define precise inclusive/ > exclusive date semantics so a checkout and another arrival on the same day is > allowed when appropriate. Lock or otherwise protect the room/inventory during the > final reservation/check-in decision to prevent double booking. Acceptance criteria: - One documented overlap predicate is used across all entry points. - Null actual checkout for an active stay blocks the room. - Back-to-back stays behave correctly. - Tests cover bookings, active stays, cancelled/no-show records, blocks, dirty and > out-of-order rooms, and concurrent/conflicting reservation attempts. ## 7. Make check-in a controlled reception workflow > Improve the company-admin check-in workflow into an explicit receptionist flow. > Add a front-desk arrivals queue showing today/overdue arrivals, room readiness, > balance/deposit state, guest-registration completeness and exceptions. Ensure > check-in validates room readiness, required guest data, payment/deposit policy > and availability inside a transaction. Support documented early-arrival handling > rather than silently bypassing checks. Acceptance criteria: - One screen lets a receptionist process arrivals and see why a booking is blocked. - Check-in creates/updates the stay and room assignment atomically. - Every override requires a reason and is written to the audit log. - Feature tests cover normal, early, dirty-room, missing-registration and unpaid > scenarios. ## 8. Complete guest registration and document handling > Complete the non-Filament guest registration workflow. Define mandatory guest > fields by property/country configuration, capture guest documents securely, and > add a registration-card/consent/signature record where required. Treat existing > browser-side scanner/OCR interfaces as unverified until a server-validated upload > and extraction process is implemented. Add role-based access and retention rules > for highly sensitive identity documents. Acceptance criteria: - The check-in workflow can enforce configured mandatory registration fields. - Uploaded identity documents have authorization, audit trail and safe storage. - No UI claims a camera/OCR/QR scan succeeded unless the server received and > verified the result. - Tests cover permission denial and required-field enforcement. ## 9. Add a receptionist departure workboard and checkout controls > Build a departure queue for today/overdue departures in company-admin. For each > stay show room, guest, balance, open folio charges, payment status, room/key > return status and housekeeping handoff. Make checkout use the folio review flow > and prevent final checkout with unresolved balances or required exceptions unless > an authorized override with reason is recorded. Trigger a post-departure room > status/task exactly once. Acceptance criteria: - Checkout is safe against duplicate submissions. - Checkout blocks or audibly flags unresolved balance/folio exceptions. - The room moves to the correct post-departure housekeeping state. - Tests cover paid, unpaid override, duplicate checkout and cleaning handoff. ## 10. Add key-card/key custody management > Design and implement a company-admin key-management module tied to a stay and > room assignment. Support issue, duplicate/reissue, expiry, return, lost key and > deactivation. Record staff member, timestamps, reason and optional charge. Keep > this provider-neutral initially, but define an adapter boundary for future door- > lock integrations. Surface key state in arrivals, in-house stays and departures. Acceptance criteria: - Issued keys are auditable and scoped to the active stay/room assignment. - A returned/expired/checked-out key cannot remain active in the workflow. - Duplicate and lost-key events are distinguishable and reportable. - Tests cover lifecycle transitions and tenant isolation. ## 11. Add cashier shifts and cash reconciliation > Implement front-office cashier-shift controls for the non-Filament panel. A > cashier must open a shift with an opening float, record cash paid-in/paid-out > movements and payment allocations, count the drawer at close, record variances > with reasons, and hand over to the next cashier. Link payment/refund operations > and fiscal receipts to the active cashier shift when paid at reception. Do not > rewrite historic financial records when a shift closes. Acceptance criteria: - Only one open shift per cashier/device/property as configured. - Closing produces an immutable reconciliation summary and variance audit record. - Refunds and voids require controlled permissions/reasons. - Tests cover opening, cash movements, close, variance and handover. ## 12. Harden folios, split billing and payment guarantees > Extend the folio/payment model for hotel billing controls: multiple folios per > stay, charge routing (guest/company/room), split payments, transfer of charges, > direct billing accounts, deposits/pre-authorizations/guarantees, adjustments and > controlled void/refund flows. Reuse existing Folio/FolioCharge/FolioPayment where > possible and preserve a complete immutable audit trail. Keep fiscal receipt rules > compatible with the existing Tremol/MyPOS flows. Acceptance criteria: - A receptionist can split or route legitimate charges without changing history. - Payment guarantees and deposits visibly affect check-in/checkout decisions. - Transfers, adjustments, voids and refunds record who/when/why. - Tests verify totals and prevent cross-tenant or double allocation errors. ## 13. Replace night audit with a controlled business-date close > Upgrade the existing night-audit module into a controlled daily-close process. > Introduce a property business date, pre-audit validation checklist, cashier-shift > closure prerequisite, arrival/departure/no-show exception list, room-status > exceptions, posting/rollover step, approval and immutable output package. Support > authorized reversal/rerun with a clear audit trail rather than editing a completed > audit. Keep the current audit records compatible through a migration plan. Acceptance criteria: - A hotel cannot silently close the same business date twice. - Exceptions are visible and either resolved or approved with a reason. - Close output includes key operational and financial totals. - Tests cover success, blocked close, approval and authorized rerun/reversal. ## 14. Add no-show, walk-in, early/late and group workflows > Add dedicated reception workflows for walk-ins, no-shows, early arrivals, late > checkout and groups. A no-show must apply its configured policy, release future > inventory, preserve charges/audit evidence and notify the correct users. A walk-in > must use the same transactional availability and registration controls as a normal > booking. For groups, add a master reservation, rooming list, allocation/status and > optionally grouped/direct billing. Do not use generic booking notes as the data > model for these processes. Acceptance criteria: - Each workflow has a visible action, state transition, permission and audit log. - Inventory and financial consequences are deterministic and tested. - Group arrivals/departures can be processed by room or in bulk with safeguards. ## 15. Add guest-service desk operations > Add the missing in-house guest-service workflows: wake-up-call scheduling and > completion log, guest request/concierge ticket queue with owner/SLA/status, > package/parcel logging and handover notes. Integrate guest messages where useful, > but keep operational requests distinct from chat. Surface open requests on the > receptionist workboard and ensure they close or transfer cleanly at shift handover. Acceptance criteria: - A receptionist can create, assign, track and close each request type. - Wake-up calls are scheduled in the property timezone and completion is logged. - Open requests and handover notes are visible at the next shift. - Tests cover lifecycle, permissions and timezone behavior. ## 16. Add channel/OTA operational management > Design the first production-safe channel-management boundary for the company-admin > panel. Do not pretend an external integration exists until it does. Create a > provider-neutral mapping for property/room/rate-plan, availability and reservation > sync events, with an operational queue, retries, error status, manual retry and > reconciliation view. Start with one selected channel/provider and preserve an > adapter interface for others. Coordinate all outbound updates with the unified > availability service. Acceptance criteria: - The panel shows what was sent, what failed and how to recover it. - Incoming reservations are idempotent and map to a tenant/property safely. - Sync failures never silently change local inventory. - Tests cover duplicate webhook/event handling and failed retry behavior. ## 17. Reception acceptance suite and go-live checklist > Create a non-Filament company-admin reception acceptance test suite and a concise > go-live checklist. Cover tenant separation, availability/concurrency, booking, > check-in, room assignment/change, guest registration, payment/deposit, folio, > checkout, housekeeping handoff, key custody, cashier close, night audit, no-show > and B2B invoice routing. Run it under the PHP version required by Composer (8.3+) > in CI and document the exact command. Mark each capability as pass, blocked or > intentionally deferred; do not describe unimplemented features as complete. Acceptance criteria: - Tests are organized by receptionist workflow and run in CI. - The checklist has named operational owners and evidence fields. - The final report distinguishes code-complete from production-validated.