# PhpStorm Agent Prompt Pack: Public Visual, Content and Mobile Remediation
Run these prompts in order, one task at a time. They convert the 2026-08-28
public-site visual/mobile audit into implementable work. Do not start a later
prompt until the previous one has been reviewed and its focused tests pass.
## Shared instruction block
Prepend this block to every prompt:
> Work only in the Zapazime public-web surface and the directly supporting
> routes, controllers, views, view models, translations, configuration,
> migrations/seeders, and tests. Preserve unrelated working-tree changes.
> Reproduce and identify the root cause before editing. Do not solve defects by
> catching and suppressing exceptions, exposing inactive/unpublished/private
> inventory, fabricating ratings/counts/prices, disabling authorization/CSRF,
> or weakening validation. Do not submit real forms, bookings, messages, or
> payments. Use PHP 8.3+ only. At the end report root cause, changed files,
> migrations/data repair required, exact tests run, deployment/cache commands,
> and remaining risk.
---
## 1. Remove all production debug and diagnostic exposure
> Fix the production-debug regression observed on every rendered public and
> client page. The Laravel debug toolbar is visible on homepage, catalogue,
> Blog, Contact, legal pages and signed-in client pages; Gift Cards and Reviews
> also expose framework diagnostics. Trace configuration, environment values,
> debugbar registration/middleware and error rendering. Make production HTML and
> JSON responses safe while retaining useful server-side logs and a support
> correlation/reference ID. Do not rely on `APP_ENV` alone: explicitly enforce
> a production `APP_DEBUG=false` configuration and prevent debugbar registration
> outside approved local development environments.
Acceptance criteria:
- Anonymous and authenticated production-mode responses contain no debugbar,
stack trace, SQL/query information, cookies/session values or exception class.
- Normal 404 and controlled 500 HTML/JSON responses are friendly and include a
safe reference ID only.
- Local development debugging remains intentionally available.
- Feature tests exercise a real controlled 500, normal 404 and an ordinary 200.
- Deployment steps include environment validation and config/view/cache refresh.
## 2. Restore the canonical public property-detail route
> Repair the primary conversion path. All six homepage featured venue links
> (`/venue/1` through `/venue/6`) currently return 404 because public cards emit
> numeric IDs while the venue detail logic expects a slug. Choose and implement
> one canonical strategy: safely accept constrained numeric identifiers and
> redirect eligible slugged venues to their canonical slug URL, or make every
> public link producer use a stable dedicated ID URL. Audit homepage, deals,
> location results, favourites, similar-venue components, structured data and
> canonical URLs. Use one explicit public-publication scope for every lookup.
Acceptance criteria:
- Every eligible featured/deal card opens its intended detail page.
- Canonical slug URLs work and numeric legacy URLs behave deliberately.
- Missing, unpublished, inactive, deleted or private venues return a safe 404.
- No route ambiguity exists between numeric IDs and slugs.
- Feature tests cover all six featured-link values, slug, missing, private and
unpublished records.
## 3. Repair or deliberately remove Gift Cards
> Diagnose the HTTP 500 on `/gift-cards` and repair its root cause in the
> controller/view/data contract. Inspect the index action, view, route names,
> product query, translations, optional configuration and cart/checkout entry
> points. Do not wrap the page in a generic `try/catch`. If Gift Cards is not a
> complete enabled product, feature-flag it off and remove every public header,
> footer and mobile-navigation CTA rather than showing a broken page.
Acceptance criteria:
- An enabled catalogue gives an anonymous visitor a 200 response.
- Empty/unconfigured state is intentional, localized and safe.
- Visible checkout/cart links resolve without creating a purchase.
- Disabled feature has no discoverable public CTA.
- Tests cover enabled, empty, disabled and error-prevention cases.
## 4. Fix the Reviews query and its legitimate empty state
> Repair `/reviews`, which currently renders a database exception to the public.
> Reproduce the failed query under production-like data, correct relationships,
> columns, joins/scopes or migrations as required, and design the view's empty
> state. Reviews must only show real, approved, publicly eligible reviews; do
> not add fake rating/review content to make the page look populated.
Acceptance criteria:
- `/reviews` returns 200 with legitimate reviews and with an empty database.
- No database exception or diagnostics reaches a visitor.
- Review aggregate/count matches the cards and venue-detail presentation.
- Tests cover approved public, unapproved/private, malformed/legacy data and
no-review states.
## 5. Reconcile hotel taxonomy, counts and discovery results
> Fix the public hotel discovery disagreement. The UI advertises Hotel inventory
> but `/locations?type=rentals&category=hotel` has no venue-detail cards. Trace
> navigation metadata, category slug mapping, legacy category values,
> `WebController` query filters, venue booking type, publication scope and card
> rendering. Define the canonical hotel taxonomy and migrate/map legacy values
> safely. A truly empty market must remain empty with a useful localized state;
> never include unrelated rentals merely to create results.
Acceptance criteria:
- Eligible published hotels appear in the hotel filter.
- Header/menu count, result count and visible cards agree.
- Cards preserve the selected type/category/date/guest context into detail.
- Non-hotel, inactive, unpublished and private records never appear.
- Tests cover populated and legitimate-empty hotel searches.
## 6. Correct public destination and listing data presentation
> Audit and repair data integrity in the visitor UI. Destination cards currently
> contain duplicated or malformed place labels (for example city repeated or
> mixed-script city values), zero-object claims beside content, and suspicious
> repeated ratings. Centralize public display formatting and aggregation rules.
> Require a valid public title/place fallback, hide an unavailable metric, and
> calculate counts/ratings only from eligible published records. Clean existing
> bad source data through a reviewed migration/seeder/admin correction path.
Acceptance criteria:
- No public destination/listing label is blank, duplicated or malformed.
- Counts are based on the same public scope as the cards.
- Ratings are displayed only when backed by genuine published review data.
- Data-repair operation is idempotent, reviewed and does not alter unrelated
records.
- Tests cover missing names, duplicate city/name, no eligible items and ratings.
## 7. Complete public and client localization/content quality
> Complete the Bulgarian/English localization pass across the shared public shell
> and signed-in client pages. The live Bulgarian session still shows English copy
> on Mobile App, Rewards, selected marketing/category labels and Client
> Favorites; prior checks also found hard-coded English navigation/legal copy and
> the typo `Събитиенни пространства`. Inventory every rendered string in these
> templates, replace hard-coded text with canonical translation keys, add
> reviewed BG/EN translations and correct the Bulgarian wording to
> `Събитийни пространства`. Ensure no fallback locale silently masks missing
> translations.
Acceptance criteria:
- BG public and client routes contain intended Bulgarian labels; EN equivalents
are complete and coherent.
- No mixed-language header, footer, empty state, legal CTA or client page remains.
- Translations are cache-safe and documented in the deployment checklist.
- Focused render tests assert representative BG and EN pages.
## 8. Remove dead/misleading public contact and app CTAs
> Audit all public navigation/footer/mobile CTAs for truthfulness and consistency.
> Resolve the visible contact email-label versus `mailto:` target mismatch using
> one approved support address. Replace any remaining `#`, generic App Store or
> Google Play destination with verified Zapazime product URLs stored in
> configuration, or hide each CTA and related marketing copy when the app/link
> is not configured. Validate parent legal/navigation links as well.
Acceptance criteria:
- Every visible public CTA points to a real intended destination.
- Email text and `mailto:` address match exactly.
- App-store CTAs render only for configured, product-specific URLs.
- Tests cover configured and unconfigured/hidden states.
## 9. Repair the shared mobile shell at 390 px and common breakpoints
> Fix the responsive defects reproduced at 390 x 844 on homepage, catalogue,
> Blog and Contact. The utility bar's language/currency/account/logout group is
> wider than the viewport, creating horizontal scrolling and clipping account
> content. The fixed mobile bottom navigation covers content near the bottom of
> the page. Refactor the shared header/footer/mobile shell rather than applying
> page-specific overflow hiding. Ensure the off-canvas menu cannot expand document
> width, support safe-area insets, retain keyboard access and avoid hiding active
> controls.
Acceptance criteria:
- At 320, 375, 390, 768 and desktop widths, document width never exceeds
viewport width on the shared public/client shell.
- Utility controls remain visible, usable and logically ordered at mobile sizes.
- Main content has enough bottom padding for fixed navigation and safe areas.
- Homepage, catalogue, Blog, Contact, legal page and client page pass responsive
browser checks; no interactive control is clipped.
- Add automated viewport assertions and targeted visual-regression snapshots if
the project test tooling supports them.
## 10. Finish the real hotel detail-to-booking experience in staging
> Once the venue route is repaired, validate and complete the visitor hotel flow
> using seeded/staging-safe inventory only. From date/guest hotel search through
> detail page and booking review, ensure the interface presents real room/unit
> types, gallery, amenities, address/map, house rules, check-in/out times,
> cancellation/payment terms, availability, fees/taxes and reviews only where
> data genuinely exists. Preserve search context. Implement friendly no-availability
> states. Do not use production payment credentials or create a charge; use a
> non-chargeable sandbox method for any end-to-end test.
Acceptance criteria:
- Search, result count, property detail and selected room/rate agree.
- Booking review shows price composition, policies and guest data requirements.
- Availability is revalidated server-side before confirmation.
- Missing optional hotel content is hidden or has a truthful state.
- Feature/browser tests cover happy path, no availability, invalid dates/guests,
expired inventory and sandbox payment handoff.
## 11. Add public-route, responsive and release-gate coverage
> Build the final regression gate for the repaired public website. Add anonymous
> route/view tests for every header/footer destination, all three deal pages,
> Gift Cards, Reviews, legal pages, representative category/location pages and
> every featured venue link. Include assertions that ordinary 200 pages and
> 404/500 pages never contain debug tooling or diagnostics. Add responsive checks
> for the shared shell and a production-like smoke command that can run after
> deployment. Configure the suite to use PHP 8.3+ without weakening Composer's
> platform check.
Acceptance criteria:
- The suite fails on a broken featured link, Gift Cards/Reviews error, visible
debugbar, mobile horizontal overflow, missing translation or bad CTA.
- CI uses PHP 8.3+ and runs the focused public suite.
- Deployment checklist verifies `APP_DEBUG=false`, cache refresh, queue/worker
restart where relevant, rollback readiness and anonymous post-deploy smoke.
- The final report lists remaining data-dependent pages that require an editorial
or inventory owner to populate rather than treating them as code failures.