Build a Searchable Directory from an Approved Listing Specification

Implement the bounded searchable directory defined by the approved listing specification in the authorized repository. Build the approved listing ingestion, search, filters, result and detail views, access controls, and moderation behavior. Do not expand the task into a transactional marketplace, payment system, seller platform, web-scraping project, or generic application build.

## Required inputs

Approved directory specification:
{{approved_directory_specification}}

Repository and stack context:
{{repository_and_stack_context}}

Listing schema and authorized data:
{{listing_schema_and_authorized_data}}

Search, filter, access, and moderation rules:
{{search_filter_access_and_moderation_rules}}

Acceptance criteria and authorized scope:
{{acceptance_criteria_and_authorized_scope}}

## Evidence and assumption rules

1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite files, symbols, schema objects, data samples, commands, query plans, and test artifacts where available.
2. Do not invent listing fields, ownership, publication states, moderation rules, ranking signals, access policy, licenses, locations, prices, contact details, integrations, test results, or approval.
3. Treat the approved listing schema, authorized dataset, and search, access, and moderation rules as the implementation contract. If they conflict with the repository or each other, stop the affected path and request a decision from the product owner, data owner, content or moderation owner, and security reviewer.
4. Confirm the supplied data may be used for the directory. Do not scrape, enrich, geocode, publish, or import personal, confidential, copyrighted, or unlicensed data without explicit authority and a documented lawful and contractual basis.
5. Separate repository changes and commands actually executed from proposals and unverified expectations. Do not infer search quality, accessibility, security, or performance from code inspection alone.
6. Preserve unrelated repository and data changes. Do not replace the search stack, database, rendering framework, or moderation model unless the approved specification and authority require it.

## Authorization boundaries

- Implementation requires an authorized repository, approved directory specification, exact listing schema, an authorized synthetic or sanitized dataset, explicit access and moderation states, acceptance criteria, and allowed files and commands.
- Inspect only the supplied workspace, local or isolated database, fixtures, search adapter, schemas, routes, and test output. Do not imply access to a live CMS, production index, third-party data supplier, geocoding service, analytics platform, or deployment system.
- Do not publish listings, import production data, send messages, activate payments, create seller accounts, change production access, call paid enrichment services, deploy, merge, or push.
- Exclude checkout, orders, subscriptions, commissions, bidding, disputes, identity verification, seller onboarding, and marketplace transactions unless they are handled by a later separately approved Prompt.
- Stop before destructive migrations, irreversible re-indexing, bulk data changes, new external transmissions, or actions whose ownership, privacy, cost, blast radius, or rollback is unclear.

## Repository inspection and implementation checkpoint

1. Inspect the repository structure, listing models and schemas, status and ownership rules, routes and APIs, validation, imports, storage, search/index adapter, query scopes, filters, sorting, pagination, access controls, moderation path, templates or components, metadata, tests, monitoring, and release controls that actually exist.
2. Trace one approved listing from source row through validation, normalization, persistence, moderation state, indexing, result display, detail view, update, unpublication, and removal. Identify unsupported or conflicting rules.
3. Establish an authorized baseline using synthetic or sanitized fixtures. Record current tests, query counts or plans where available, search behavior, rendering states, accessibility checks, and exact commands with actual results.
4. Before editing, present a concise checkpoint with affected files and schemas, import and index effects, state model, search and filter implementation, authorization points, test plan, rollout control, rollback, and blockers. Continue only within {{acceptance_criteria_and_authorized_scope}}.

## Implement the approved directory slice

Apply the smallest coherent change set. Where applicable:

1. Implement the approved listing schema, server-side validation, normalization, stable identifiers, source provenance, ownership, visibility, moderation state, timestamps, and update/removal behavior. Use reversible migrations only when explicitly authorized.
2. Implement an idempotent fixture or authorized import path that reports accepted, rejected, duplicate, conflicted, and unchanged records without silently overwriting protected fields.
3. Implement the approved list and detail routes or interfaces. Keep Draft, rejected, suspended, expired, restricted, and future listings outside public results according to the supplied rules.
4. Implement exact approved filters, deterministic sorting with a stable tie-breaker, bounded pagination, result counts where safe, query preservation, empty states, invalid-filter handling, and canonical URL behavior.
5. Implement search using the existing approved database or search adapter. Normalize only the fields and language rules supplied. Bound query length and result size, escape output, parameterize database queries, and avoid leading-wildcard full-body scans unless explicitly justified by the approved architecture and measured evidence.
6. Enforce server-side listing and field visibility at query and detail boundaries. Do not rely on hidden controls or omitted links. Prevent direct-object access and index, cache, export, or metadata leakage.
7. Implement moderation and ownership transitions exactly as approved, including evidence, reason, owner role, and permitted next state. Do not let AI-generated content or an imported status publish a listing automatically.
8. Implement semantic headings, labelled controls, keyboard operation, visible focus, accessible result updates, responsive layouts, safe images or placeholders, and approved public metadata. Do not claim accessibility or SEO quality without checks.
9. Add bounded observability for import outcomes, search latency and errors, invalid filters, rejected records, index version, and moderation transitions without exposing confidential listing data.

## Domain-specific verification

Use synthetic or authorized fixtures. Test at least:

- valid, missing-field, malformed, duplicate, conflicting, stale, future, restricted, rejected, suspended, and removed listings;
- repeat import, partial failure, interrupted import, rollback, and reconciliation between source, database, index, and rendered results;
- exact search, no match, ambiguous terms, punctuation, excessive input, injection strings, and unsafe markup;
- each filter alone, supported filter combinations, invalid values, sorting ties, page boundaries, empty pages, changed records between pages, and deterministic ordering;
- authorized and unauthorized roles, direct identifiers, hidden fields, Draft detail routes, exports, caches, and search-index visibility;
- moderation transitions, invalid transitions, ownership changes, stale moderator actions, and unpublication propagation;
- loading, empty, unavailable-search, invalid-filter, denied, stale-index, error, and recovery states;
- semantic structure, keyboard navigation, focus order, control names, contrast evidence where tooling exists, narrow-screen layout, metadata, canonical behavior, broken links, query count, query plan, and response-time or result-size thresholds.

For every check, record the fixture and visibility state, identity, query or action, expected observation, exact command or procedure, actual observation, artifact, and pass, fail, blocked, or not run status. Do not present fixture coverage as proof that a production data source, search service, or moderation operation is ready.

## Failure, recovery, and stop conditions

- On uncertain import or indexing completion, reconcile stable source and listing identifiers before replay. Do not create duplicates or silently publish partially processed records.
- Preserve a pre-change schema and configuration record plus an authorized data or index snapshot where applicable. Document how to disable new routes or a feature flag, stop imports, restore prior code/configuration, revert only reversible schema changes, rebuild or restore the index, and verify visibility after recovery.
- Stop with a blocked-handoff report if the approved specification, authorized repository, listing schema, rights-cleared data, visibility and moderation model, test environment, required dependency, or authority is missing or contradictory.
- Stop if the implementation would expose unpublished or restricted records, import unlicensed data, broaden permissions, require an unapproved production index, publish listings automatically, or lack deterministic recovery.

## Output contract

Return:

1. **Implementation status**: Applied and tested, Applied with gaps, Proposed only, or Blocked, with repository, environment, data authorization, and evidence limitations.
2. **Specification-to-implementation traceability**: Requirement, listing/search/moderation behavior, file and symbol, status, evidence, conflict, and owner decision.
3. **Listing lifecycle and boundary map**: State, permitted transition, owner role, public/search/API visibility, stored fields, index/cache behavior, and removal rule.
4. **Repository, schema, and configuration change manifest**: File or object, exact change, reason, applied/proposed state, data effect, test evidence, and rollback treatment.
5. **Import and reconciliation record**: Source, authorization, identifier, validation, normalization, accepted/rejected/duplicate outcomes, idempotency, database/index/result reconciliation, and unresolved records.
6. **Search and discovery implementation record**: Query handling, exact filters, sorting, pagination, access enforcement, metadata, performance evidence, and known limitations.
7. **Domain test ledger**: Scenario, fixture, identity, expected result, actual result, command or procedure, artifact, and status.
8. **Finding and residual-risk register**: Failed criteria, data-rights or privacy gaps, search limitations, moderation risks, owner, and smallest safe correction.
9. **Rollback and owner handoff**: Disablement, import stop, data/index restoration, visibility verification, and actions for product, data, moderation, security, accessibility, engineering, and release owners.
10. **Completion statement**: Separate requested, inspected, changed, executed, passed, failed, blocked, and unverified work. Do not claim publication, search quality, accessibility, security, performance, or release readiness without corresponding evidence. End with the smallest safe next action.