# PhpStorm Agent Prompt Pack: Company Admin UI Stabilization
Run these prompts in order, one per agent task. They are based on the live,
authenticated production UI audit dated 2026-08-27.
## Shared instruction block
Prepend this block to every prompt:
> Work only on the non-Filament company-admin panel and the directly supporting
> Laravel configuration, controllers, views, routes, models and tests. Preserve
> unrelated working-tree changes. Inspect the current implementation before
> changing it. Do not submit demo data, delete records, or weaken authorization to
> make a screen render. Add focused tests for every fix and run the narrowest
> relevant test/lint command under the project-required PHP version. At the end,
> report: root cause, files changed, tests run, migration/deployment steps, and
> remaining risk.
---
## 1. Stop Laravel debug output in production
> Fix production error handling for Zapazime. The authenticated company-admin UI
> currently displays Laravel's full exception/debug page on 500 responses,
> including stack traces and request/session diagnostics. Ensure production always
> has `APP_DEBUG=false`, uses a safe generic 4xx/5xx response, logs errors
> server-side, and does not expose debug toolbar/exception content. Keep local
> developer ergonomics intact. Add a deployment-safe configuration checklist and a
> feature test or configuration test proving an exception response does not contain
> debug details in production mode.
Acceptance criteria:
- Production 500 responses are generic and contain no stack trace, query details,
environment values, cookies or debug toolbar.
- Errors remain recorded in the configured log/monitoring mechanism.
- Local development can still opt into debug mode explicitly.
- Document exact cache/config commands required during deployment.
## 2. Fix the housekeeping dashboard 500
> Repair `/company-admin/housekeeping`. It currently throws a
> `RouteNotFoundException` because the dashboard view refers to
> `company-admin.housekeeping.widgets.update`, which is not declared. Determine
> whether widget preferences should reuse the existing generic company-admin widget
> endpoint or have a housekeeping-specific endpoint. Implement the intended route,
> controller behavior, validation and authorization. Ensure the widget modal is
> functional or remove it if there is no supported persistence model.
Acceptance criteria:
- An authenticated company manager receives 200 for the housekeeping dashboard.
- Widget preference form uses a declared named route and cannot update another
user's/company's preferences.
- A feature test covers the dashboard render and widget update path.
## 3. Fix the housekeeping tasks 500 and define venue selection
> Repair `/company-admin/housekeeping/tasks`. It currently calls
> `HousekeepingScheduleOptimizer::getScheduleStatistics(int $venueId, ...)` with
> `null`. Decide the correct product behavior: require a selected venue, default to
> the user's/property's selected venue, or support a company-wide aggregate view.
> Implement that behavior consistently in the controller, optimizer and UI filter.
> Do not satisfy the type error by casting null to zero.
Acceptance criteria:
- Tasks screen returns 200 for a company with one venue, multiple venues and no
venues.
- The selected venue is visible in the UI and statistics match the displayed task
scope.
- Tests cover missing/invalid venue input and tenant isolation.
## 4. Fix staff-attendance manager eager loading
> Repair `/company-admin/attendance/manager`. It currently fails with
> `Collection::addEagerConstraints does not exist` when loading `activeEmployees`.
> Inspect the `EmployeeAttendance`, venue-object and employee relationship methods.
> Correct the relation so `with('activeEmployees')` receives an Eloquent relation,
> or replace it with an explicitly correct query/resource. Preserve company and
> workspace scoping.
Acceptance criteria:
- Attendance manager returns 200 with zero, one and multiple active employees.
- Displayed staff are limited to the current company/workspace.
- Tests cover the relation/query and empty state.
## 5. Restore the front-desk operations screen
> Repair `/company-admin/front-desk/operations`. The controller returns
> `company-admin.front-desk.operations`, but that Blade view does not exist.
> Build the missing operations list view (or deliberately use the correct existing
> view) with filters for venue, operation type and date range, pagination, an
> empty state and links to operation detail where a record exists. Keep this view
> read-only unless an existing authorized action is already supported.
Acceptance criteria:
- Operations screen returns 200 and reflects the controller's filters.
- It has an accessible empty state and no dead detail links.
- Tests cover render, filtering and cross-tenant protection.
## 6. Make invalid deep links safe and deliberate
> Audit company-admin deep links that take a model ID, starting with checkout folio
> review, stay modification, room assignment, booking/stay/invoice detail and
> guest document routes. Missing, malformed or unauthorized IDs must yield a
> deliberate 404 or 403—not a 500 page. Use explicit route constraints, correct
> model binding and company/workspace authorization. Do not expose whether another
> tenant owns a resource.
Acceptance criteria:
- Invalid IDs never render a 500 page.
- Cross-tenant IDs cannot be read or mutated.
- Feature tests cover missing, malformed and unauthorized resources for each
reception-critical deep-link family.
## 7. Create a first-class Reception workboard
> Create a dedicated company-admin Reception workboard and promote it to the top
> of the sidebar's Reception group. It must present today's/overdue arrivals,
> departures, in-house stays, room-ready/dirty/out-of-order/blocked counts,
> outstanding balances and operational exceptions. Each row/card must link to an
> existing authorized workflow: booking/stay, room assignment/change, folio review,
> check-in or checkout. Start read-only for data aggregation; do not duplicate
> status logic in the Blade view.
Acceptance criteria:
- A receptionist can identify the next action from one screen.
- Counts and lists are scoped to the selected company/workspace and property.
- Every visible action has a working route and permission check.
- Tests cover empty, normal and exception states.
## 8. Improve reception navigation and deep-workflow discovery
> Refactor the company-admin sidebar and related dashboard quick actions for a
> reception-first flow. The Reception menu currently exposes Stays, Night Audits
> and Room Blocks, while the front-desk dashboard, operations, room assignment,
> folio review and stay modifications are hard to discover. Add concise links for
> Reception Workboard, Operations, Arrivals, Departures and In-house views (or
> scoped views of the workboard), while keeping advanced configuration in deeper
> sections. Avoid making the already long menu harder to scan.
Acceptance criteria:
- Reception users can reach every daily desk workflow in at most two clicks.
- No menu link points to a 404/500 or an unauthorized screen.
- Mobile/sidebar-collapsed layout remains usable.
- Add a route/link smoke test for all sidebar reception links.
## 9. Improve empty, zero-data and unavailable-data states
> Standardize the company-admin UI states. The current panel mixes clear empty
> states (maintenance, inspections, shifts) with reporting cards that show zeroes
> and placeholder chart copy, making “no data,” “loading,” “not configured” and
> “calculation failed” indistinguishable. Create a small shared view/component
> pattern with an icon, plain-language explanation and safe next action. Apply it
> to reception, housekeeping, reports, fiscal receipts, settlements and role
> permissions first.
Acceptance criteria:
- Each selected screen clearly distinguishes empty data from error/unavailable
data and from unconfigured property data.
- Zero is shown only when it is a calculated zero.
- Empty states include an appropriate action only when the user has permission.
- UI tests/snapshots cover the states.
## 10. Complete Bulgarian/English localization in company admin
> Run a localization completeness pass for the non-Filament company-admin panel.
> The rendered Bulgarian UI mixes Bulgarian text with English labels and raw keys,
> including `Dashboard`, `Night Audits`, `Pre-Check-In Management`,
> `No Bookings Available`, `manage_dashboard_widgets`, `Printed` and `No fiscal
> receipts found`. Replace hard-coded strings and untranslated keys with canonical
> translation keys; add Bulgarian and English translations; remove duplicate or
> conflicting keys. Do not bulk-reformat unrelated language files.
Acceptance criteria:
- Targeted screens render no raw translation key-like labels in either BG or EN.
- The same concept has one canonical key rather than ad-hoc duplicates.
- Add a simple localization smoke test or static check for known raw-key patterns.
## 11. Add hotel-readiness onboarding warnings
> Add a non-blocking but prominent company-admin setup/readiness panel for hotel
> properties. The live settings screen shows the business type as “Not set,” while
> ESTI, tax, check-in/out times, rooms and rates are hotel-operational settings.
> Detect missing required hotel configuration and link users to the exact setup
> page/section. Do not assume every company is a hotel; show this only for hotel
> category/properties or an explicitly selected hotel mode.
Acceptance criteria:
- A hotel manager sees actionable warnings for missing business type, rooms, rate
plan, tax/fiscal configuration, check-in/out times and ESTI setup when relevant.
- A non-hotel company is not incorrectly blocked or warned as a hotel.
- No warning claims an integration is live without verified configuration.
- Tests cover complete/incomplete and hotel/non-hotel cases.
## 12. Implement the missing reception UI modules
> Based on the Reception Readiness Audit, design and implement the next visible
> receptionist modules in this order: key/key-card custody; cashier shifts and
> cash reconciliation; no-show/walk-in/group arrival actions; wake-up calls and
> guest request/parcel tracking. For each module, start with a narrowly scoped
> model/state machine, role permissions, audit log and a simple list/detail/action
> UI. Integrate it into the Reception workboard rather than adding disconnected
> sidebar sprawl. Present a phased design first, then implement only the agreed
> first module in this task.
Acceptance criteria:
- The design identifies data model, lifecycle states, permission boundary, audit
events and UI entry points for all four modules.
- Only one module is implemented per task after the design is accepted.
- The implemented module has complete tenant isolation and feature tests.
## 13. Add authenticated UI smoke coverage and a release gate
> Add an automated company-admin UI/route smoke suite that visits every sidebar
> destination as an authenticated company manager and asserts a non-5xx response,
> correct authorization behavior and no Laravel debug output. Include the
> reception-critical create/list/detail pages, but do not create production data in
> the test environment. Add the suite to CI on PHP 8.3+, and create a release-gate
> checklist that requires it before deployment.
Acceptance criteria:
- Every visible sidebar route is covered by an authenticated smoke test.
- Broken view names, route names, relations and translations are caught before
release.
- Production error pages are asserted to omit debug content.
- CI documents its PHP version and exact test command.