# PhpStorm Agent Prompt Pack: Public Website Stabilization
Run one prompt at a time, in this order. These tasks come from the public-site
audit dated 2026-08-27. Do not start a later prompt until the acceptance criteria
of the current prompt pass.
## Shared instruction block
Prepend this block to every prompt:
> Work only on public/visitor-facing Zapazime pages and their directly supporting
> Laravel routes, controllers, services, models, Blade/Livewire views,
> translations, configuration and tests. Preserve unrelated working-tree changes.
> Inspect the existing implementation before changing it. Do not bypass
> authorization, disable CSRF, expose unpublished inventory, or invent booking,
> rating, availability, price, or destination data to make a page look populated.
> Treat guest-facing routes as anonymous unless the task explicitly says
> otherwise. Add focused tests and run the narrowest relevant test/lint command
> under the project-required PHP version. At the end report: root cause, files
> changed, tests run, deployment/cache steps, and remaining risk.
---
## 1. Stop debug/error disclosure to public visitors
> Fix public production error handling for Zapazime. Public pages that fail must
> never expose framework debug output, stack traces, query details, environment
> values, request/session data, or the debug toolbar. Ensure production uses
> `APP_DEBUG=false`, has safe branded/generic 404 and 500 responses, and records
> full diagnostics server-side. Keep explicit local-development debugging intact.
> Add an anonymous feature test that forces an exception in production mode and
> proves the response contains no sensitive debug content.
Acceptance criteria:
- Public 404/500 responses are safe, localized where appropriate, and provide a
recovery link.
- Debug details remain available only to authorized developers through logs or
monitoring.
- Deployment notes include the exact config/cache commands and environment checks.
## 2. Diagnose and repair the public venue-detail failure
> Repair the public venue detail route starting with `/venue/1`. It is linked
> from the homepage and hot-deals page but currently returns an HTTP response
> failure in production. Reproduce it in a safe local/staging data set, inspect
> the actual exception and its data assumptions, then fix the root cause in the
> route binding/controller/service/view. Do not mask the failure by catching all
> exceptions or by returning partially authorized/unpublished venue data.
Acceptance criteria:
- An anonymous request for a published venue returns 200 with its public detail
view.
- Missing, unpublished, disabled, or foreign/private venues return a deliberate
404 without leaking their existence.
- The venue page renders safely when optional images, location fields, reviews,
pricing, or availability are absent.
- Feature tests cover each case above.
## 3. Restore public listing-to-booking conversion
> After the venue detail page works, trace the complete public flow from homepage
> featured card and deal card to venue detail, date/guest selection, availability,
> rate/unit selection, and the booking entry point. Repair broken route names,
> parameter propagation, and empty/error states. Keep this task read-only through
> the point where a booking would be created or payment initiated; do not submit a
> real booking or charge.
Acceptance criteria:
- Every eligible homepage/deal venue card links to a working public detail page.
- Search dates and guest counts persist into the next step and are validated.
- A visitor receives a clear unavailable/no-results state, not a blank page or
500, when inventory does not match.
- Published/non-published visibility and tenant/property isolation are tested.
## 4. Repair or deliberately withdraw Gift Cards
> Repair the public `/gift-cards` route, which currently returns an HTTP response
> failure. First determine whether gift cards are an active product with complete
> issuance, payment, delivery, redemption, expiry, balance, fraud and accounting
> rules. If the product is incomplete, remove its public navigation/CTA rather
> than exposing a broken page. If it is supported, fix the route and build only
> the safe public browse/start flow; use sandboxed tests rather than a real charge.
Acceptance criteria:
- The route either returns a working, truthful public page or is absent from all
public navigation.
- No payment, amount, expiry, or redemption claim is displayed unless supported
by actual implementation and tests.
- Anonymous route and navigation-link tests prevent regression.
## 5. Repair or deliberately withdraw Blog
> Repair the public `/blog` route, which currently returns an HTTP response
> failure. Inspect the published-post query, pagination, category/tag relations,
> localized fields, images and view assumptions. Implement an accessible empty
> state if there are no published posts. Do not expose drafts, scheduled posts or
> private author data. If Blog is not a supported product area, remove it from
> public navigation instead.
Acceptance criteria:
- Anonymous blog index returns 200 with published posts or an intentional empty
state.
- Pagination and post links have no 5xx responses.
- Draft/unpublished/scheduled content is not public.
- Tests cover populated, empty and unpublished-content cases.
## 6. Make public inventory counts and filters truthful
> Audit the data pipeline behind homepage category counts, destination counts,
> deal cards and `/locations?type=rentals&category=hotel`. The public menu showed
> many zero counts—including Hotels—while the homepage/deals showed venues; the
> hotel filter produced no venue links. Define one canonical public-publication
> scope and reuse it for all counts and listing queries. Correct category taxonomy
> mapping, property/venue status filtering and aggregation; do not hard-code
> numbers or broaden visibility to make results appear.
Acceptance criteria:
- Menu/category/destination counts reconcile with the visible public catalogue.
- The hotel filter returns eligible hotel inventory when it exists and a precise
empty state when it does not.
- Counts exclude drafts, disabled listings, private inventory and other tenants'
data.
- Tests use contrasting published/unpublished and multiple-property fixtures.
## 7. Remove fabricated metrics and incomplete public labels
> Fix homepage/listing data presentation. Destination cards showed zero objects
> alongside repeated-looking `4.8` ratings, and several labels lacked a venue or
> place name. Trace each display value to its source. Render only calculated,
> supported metrics; hide rating/count blocks when unavailable; require or safely
> fall back from missing public display fields. Do not create fake ratings, names,
> cities, prices or availability.
Acceptance criteria:
- Every public rating/count has a documented data source and correct denominator.
- Missing optional data has a polished fallback with no dangling punctuation or
blank labels.
- Values are locale/currency-safe where applicable.
- Component/feature tests cover complete and incomplete data.
## 8. Complete the hotel property-detail experience
> Make the repaired public property page adequate for a hotel guest evaluating a
> stay. For hotel listings, show only real configured data: property and room/unit
> types, gallery, location/address, amenities, check-in/out times, house rules,
> cancellation/payment terms, guest/date availability, and reviews only when
> genuine. Build a clean distinction between a hotel, rental and service listing;
> do not force hotel terminology onto other categories. Start by documenting the
> current data model and proposing the smallest implementation slice, then
> implement that agreed slice.
Acceptance criteria:
- A hotel guest can understand what they are booking and what the applicable
policies are before entering booking/payment.
- Missing configuration uses clear, non-misleading fallbacks.
- Non-hotel listing pages do not show irrelevant hotel fields.
- Feature/view tests protect public publication and policy visibility rules.
## 9. Fix localization, navigation, and public contact consistency
> Run a focused public-site quality pass. The Bulgarian site currently includes
> English strings such as `All locations` and `Terms & Conditions`; the visible
> `office@zapazime.bg` contact label links to `info@zapazime.bg`; the Legal parent,
> App Store, and Google Play entries link to `#`; and `Събитиенни пространства`
> appears misspelled. Replace hard-coded/missing translations with canonical
> Bulgarian and English keys, select one canonical support email, and either
> configure valid legal/store destinations or hide incomplete CTAs.
Acceptance criteria:
- Bulgarian and English public pages contain no mixed-language remnants or raw
translation keys on the audited surfaces.
- Displayed email and `mailto:` target match the approved public address.
- No visible public CTA uses `#` as its destination.
- Navigation/link smoke tests cover header, footer, legal and store links.
## 10. Add an anonymous public-route release gate
> Create a maintainable anonymous public-site smoke suite. Derive its route list
> from the public header, footer, homepage cards, deals, legal links, blog and
> gift-card product flags—avoid a hand-maintained list that silently drifts. For
> each enabled route, assert a non-5xx response, absence of debug output, correct
> published-content visibility and safe empty states. Add it to CI and document a
> release checklist including responsive, accessibility, and sandbox booking/
> payment verification.
Acceptance criteria:
- Every enabled visitor-facing navigation link is tested as anonymous.
- Broken views, bindings, relations, publication scopes and debug exposure fail
CI before deployment.
- Disabled/incomplete products are excluded from navigation and covered by tests.
- CI command, PHP version, fixtures and release checklist are documented.