# PhpStorm Agent Prompt Pack: Remaining Company-Admin Work
This is the post-retest recap from 2026-08-28. Run one prompt at a time, in the
listed order. Prompts for the verified fixes—housekeeping dashboard and
front-desk operations—are intentionally omitted.
## Shared instruction block
Prepend this block to every prompt:
> Work only on the non-Filament company-admin panel and directly supporting
> Laravel configuration, routes, controllers, services, models, views,
> translations and tests. Preserve unrelated working-tree changes. Inspect the
> current implementation before editing. Never weaken tenant isolation,
> authorization, CSRF protection, or route binding merely to make a screen
> render. Do not create/delete demo or production records. Add focused tests and
> run them under PHP 8.3+ only. At the end report: root cause, files changed,
> tests run, deployment/cache steps, and remaining risk.
---
## 1. Prove production errors are safe with a real forced-500 test
> Strengthen production error handling in the company-admin/public application.
> Existing code attempts to render a safe production 500 page, but the current
> test only requests a missing route (404) and does not prove that the 500
> renderer is safe. Add an isolated test-only mechanism that throws a controlled
> exception. Assert that production-mode HTML and JSON responses contain a generic
> message and correlation/reference ID but no exception class/message, stack trace,
> SQL/query detail, environment value, session/cookie data, or debug toolbar. Make
> production `APP_DEBUG=false` a deployment-enforced condition rather than an
> assumption based solely on `APP_ENV`.
Acceptance criteria:
- Tests exercise an actual 500 response and pass on PHP 8.3+.
- Working and failing company-admin routes never reveal framework diagnostics in
production.
- Errors retain a server-side, support-usable reference ID and log record.
- Deployment checklist includes exact config/view/route cache refresh commands.
## 2. Repair housekeeping tasks and make venue scope explicit
> Repair `/company-admin/housekeeping/tasks`, which still fails live. The
> controller now tries to default `selectedVenueId`, but the production result is
> still an HTTP error. Reproduce the actual exception with zero, one and multiple
> venues. Define the product behaviour: selected venue, default company venue, or
> company aggregate. Implement it consistently in the controller, optimizer,
> statistics query, filter UI and empty state. Do not coerce a null venue ID to
> zero or use another company’s venue as a fallback.
Acceptance criteria:
- The route returns 200 for companies with zero, one and multiple venues.
- Selected venue is visible; task list and statistics always use the same scope.
- Invalid/cross-company venue IDs are rejected safely.
- Tests cover all three venue-count states and tenant isolation.
## 3. Repair attendance manager and close attendance tenant gaps
> Repair `/company-admin/attendance/manager`, which still fails live. Verify that
> `activeEmployees` is handled as a collection/value rather than passed to
> Eloquent eager-loading APIs, and remove any remaining invalid relation usage.
> Review clock-in QR lookup and venue-object attendance detail endpoints at the
> same time: both must scope venue objects to the authenticated company/workspace
> before returning or modifying data.
Acceptance criteria:
- Attendance manager returns 200 for no active employees, one employee and many
employees.
- Displayed attendance and venue objects are limited to current company/workspace.
- QR and attendance-detail endpoints cannot access another tenant’s venue object.
- Tests cover render, empty state and cross-tenant rejection.
## 4. Harden all reception deep links, starting with folio review
> Complete reception deep-link hardening. `check-out-folio-review/{stay}` still
> relies on implicit binding without an explicit company/workspace scope, and the
> route has no numeric constraint. Audit it plus stay show/edit/update, room
> assignment, stay modification, booking/stay/invoice details and front-desk
> operation details. Use constrained parameters and company/workspace-scoped
> lookups/policies. Missing, malformed and foreign IDs must give a deliberate 404
> or 403—not a 500—and must not reveal whether a foreign record exists.
Acceptance criteria:
- Checkout folio review cannot show/approve/finalize a foreign stay.
- Every audited deep-link family rejects malformed, missing and cross-tenant IDs
safely.
- No controller flashes raw exception messages back to users.
- Feature tests cover read and mutating endpoints separately.
## 5. Build the first-class Reception workboard
> Create a company-admin Reception workboard, separate from the Guest Service
> workboard. It must aggregate today’s/overdue arrivals, departures, in-house
> stays, room-ready/dirty/out-of-order/blocked counts, outstanding balances, and
> operational exceptions. Each card/row must lead to an existing authorized
> workflow: stay/booking, check-in, checkout, room assignment/change, folio
> review, or exception handling. Keep the initial screen read-only and centralize
> aggregation/state logic outside Blade templates.
Acceptance criteria:
- Receptionist can identify today’s next action from one screen.
- Results are scoped by company/workspace/property and selected venue.
- Empty, unavailable and exception states are distinct.
- Every displayed CTA has a valid authorized route.
- Tests cover normal, empty and exception states.
## 6. Refactor reception navigation around daily desk work
> Refactor the company-admin sidebar and dashboard quick actions to make
> reception workflows discoverable. The current Front Desk group still mainly
> shows Stays, Night Audits and Room Blocks. Add concise links for Reception
> Workboard, Operations, Arrivals, Departures and In-house views (or their
> workboard filters), plus direct access to folio review/room assignment where
> justified. Keep configuration and advanced tools deeper in the hierarchy; do
> not turn the sidebar into a long ungrouped list.
Acceptance criteria:
- Daily reception actions are reachable in at most two clicks.
- Sidebar links do not lead to a 404, 500, inaccessible screen or unimplemented
route.
- Mobile and collapsed-sidebar layouts remain usable.
- Add an authenticated sidebar route/link smoke test.
## 7. Standardize empty, unavailable and error states
> Implement a small shared company-admin UI component/pattern for no-data, not-
> configured, calculation-unavailable and recoverable-error states. Apply it first
> to reception, housekeeping, reports, fiscal receipts, settlements and role/
> permission screens. Do not label an unavailable calculation as numeric zero,
> and only present a next-action CTA when the user has that permission.
Acceptance criteria:
- Selected screens clearly distinguish calculated zero, empty data, missing
configuration and failed/unavailable data.
- Shared component avoids copy/paste markup and supports BG/EN translations.
- View/feature tests cover each state.
## 8. Complete company-admin BG/EN localization
> Complete the non-Filament company-admin localization pass. The live UI still
> mixes Bulgarian and English, including `Dashboard`; previous audit examples also
> included Night Audits, Pre-Check-In Management, No Bookings Available, Printed,
> No fiscal receipts found and raw translation-key-like labels. Replace hard-coded
> strings with canonical translation keys, supply coherent BG and EN values, and
> remove duplicate/conflicting keys. Do not bulk-reformat unrelated language files.
Acceptance criteria:
- Audited company-admin screens show no English remnants or raw keys in BG, and
no Bulgarian remnants in EN.
- One canonical key exists per concept.
- Include a static/render smoke check for known untranslated strings.
- Document translation/cache deployment steps.
## 9. Add hotel-readiness onboarding warnings
> Add a non-blocking hotel-readiness panel to company-admin for hotel-mode
> properties only. Current settings expose business type and ESTI configuration,
> but do not tell an operator what remains incomplete. Detect missing hotel
> business type, rooms/units, rate plan, tax/fiscal configuration, check-in/out
> times and ESTI setup. Link each warning to the exact configuration area; never
> claim an integration is active unless verified. Do not show hotel warnings to
> unrelated business types.
Acceptance criteria:
- Hotel managers see specific, actionable configuration gaps.
- Complete hotel setup has no false warnings.
- Non-hotel companies are not blocked or shown irrelevant warnings.
- Tests cover complete/incomplete hotel and non-hotel states.
## 10. Surface the remaining reception modules coherently
> Reception-domain models/services/tests already exist for keys/key-cards,
> cashier shifts, no-shows, walk-ins, group arrivals, wake-up calls, guest
> requests and packages. Audit their controller routes, permissions, audit logs
> and actual views, then integrate the approved modules into Reception workboard
> and navigation without duplicating disconnected screens. First provide a concise
> design mapping each module’s states, data ownership, permission boundary, audit
> events and entry point. Implement only the agreed first visible module in this
> task.
Acceptance criteria:
- Design distinguishes existing backend capability from missing operator UI.
- Every surfaced action has tenant isolation, authorization and audit logging.
- The first agreed module has a complete list/detail/action UI and focused tests.
- No unapproved extra module is implemented in the same task.
## 11. Add authenticated UI smoke coverage and a release gate
> Build an authenticated company-admin route/UI smoke suite. Derive its route list
> from visible sidebar/dashboard links and reception-critical pages, then visit
> each route as a company manager with suitable fixtures. Assert non-5xx response,
> correct authorization behaviour, no Laravel debug output, and a valid empty or
> normal state. Add it to CI under PHP 8.3+ and update the deployment checklist
> with a release gate and rollback/post-deploy checks.
Acceptance criteria:
- Every visible sidebar destination is covered by an authenticated smoke test.
- Reception-critical lists, detail pages and invalid deep links are covered.
- The suite fails on missing views/routes, bad relations, error disclosure and
broken navigation.
- CI PHP version, command, fixtures and release criteria are documented.