# Listing Syndication Audit

Verify that a property listing renders correctly — price, photos, and description — across the public real estate portals it was syndicated to.

## When to use

- After a new listing is published or an existing listing's price, photos, or description is updated.
- When a client or agent reports a listing looks wrong on a specific portal.
- On a recurring cadence to catch silent portal-side sync failures.
- Before a scheduled open house, to confirm the listing is presentable everywhere buyers might see it.

## Tools

- `browser-navigate`
- `browser-extract`
- `create-task`

## Playbook

1. Confirm the source-of-truth listing details before checking anything external: price, photo count and order, and the current description text. Treat these as the baseline you will compare every portal against.
2. Use `browser-navigate` to open the listing's page on the first target portal (e.g. `https://www.zillow.com/homedetails/<listing-id>`).
3. Use `browser-extract` to pull the rendered price, photo count, and description text from that page.
4. Compare the extracted values against the baseline. Flag any mismatch: wrong price, missing or reordered photos, truncated or stale description text.
5. Repeat steps 2-4 for each additional portal in scope (e.g. `https://www.realtor.com/realestateandhomes-detail/<listing-id>`, `https://www.redfin.com/home/<listing-id>`, or an MLS (Multiple Listing Service — the regional database brokers use to share listings) public-facing search result).
6. If a portal shows a listing as expired, unpublished, or missing entirely when it should be live, record that as a hard failure, not just a rendering mismatch.
7. Compile findings into a per-portal pass/fail summary noting the specific field that failed (price, photos, or description) and the observed vs. expected value.
8. For any failure, use `create-task` to open a follow-up task assigned to a human, since fixing portal sync settings, re-triggering a feed export, or contacting portal support requires account access and judgment calls this audit does not have.
9. If every portal checked matches the baseline, close out the audit with a clean summary and no follow-up task needed.

## Failure modes

- A portal caches old listing data, so a fresh page load still shows a stale price or description even though the source system was updated correctly — note the cache lag rather than assuming the source data is wrong.
- Photos load out of order or are missing on mobile-rendered portal pages but correct on desktop; check both if the portal serves different markup.
- A portal's page structure changes without notice, causing `browser-extract` to pull the wrong element (e.g. a promotional banner price instead of the listing price) — sanity-check any wildly implausible extracted value before flagging it as a mismatch.
- Listing was intentionally pulled or put under contract, so it correctly disappears from public portals — confirm listing status before treating "not found" as a failure.

## Done when

- Every portal in scope has been checked against the current source-of-truth listing details for price, photos, and description.
- A pass/fail summary exists for each portal, with specific mismatches noted.
- A human-facing task has been created via `create-task` for every confirmed failure, or the audit is closed clean with none needed.