One Place

Build me a scheduled personal property monitoring agent, the honest consolation
build for One Place: it watches the sources I configure, it does not rebuild a
live nationwide real-estate index. Requirements:

- Node + Express + better-sqlite3 on localhost:4920, with a small web UI for saved
  searches, matches, and lead notes.
- Saved searches live in SQLite: name, source URLs, natural-language criteria, hard
  filters, cadence, email recipients, and last-run time.
- A node-cron runner wakes on each cadence, fetches configured source/search pages with
  Playwright, and stores raw HTML snapshots for debugging.
- Send cleaned listing HTML to an LLM API key from .env and extract strict JSON: title,
  price, currency, surface, rooms, location text, description, image URLs, source URL, and
  confidence.
- Match each extracted listing against the saved search criteria with deterministic
  filters first, then an LLM yes/no explanation for fuzzy preferences like renovation
  potential or sea view.
- Store listings and match decisions in SQLite, dedupe by canonical URL first and fuzzy
  title+price+surface+location second; keep price-change history.
- Email new matches via Resend or SMTP creds in .env, including the match reason, key
  fields, source link, and unsubscribe/disable link for that saved search.
- Include an MCP server exposing tools: list_saved_searches, run_search_now,
  get_recent_matches, explain_match, update_search, and add_lead_note, so Claude/Codex can
  operate it from chat.
- No accounts, no telemetry, binds to localhost only. Out of scope: nationwide coverage,
  anti-bot arms races, paid data resale, mobile apps, and collaborative CRM.
- README: crawler ethics, robots/terms warning, required API/email keys, how to run the
  scheduler, and how to connect the MCP server.

# AGENTS.md — Build guide for One Place

## Project scope
Run saved searches on a schedule, crawl configured source pages, use an LLM API key to extract listing fields, dedupe into SQLite, email matching finds, and expose an MCP server for chat/coding agents.

Catalogue verdict: no. You can build a scheduled personal property monitor, but not One Place: the value is the maintained real-estate corpus, crawler fleet, AI extraction, deduplication, image/semantic search, geo enrichment, and constant source upkeep across millions of listings.
Use the implementation prompt below to define the deliverable. Complete each phase's acceptance checks before extending the scope.

## Working agreement
- Inspect the repository and its existing instructions before choosing paths, dependencies or commands. Keep one coherent stack and explain changes to the proposed architecture.
- Plan a vertical slice that accepts a real input and produces the useful output described below. Persist only the state the prompt calls for; respect memory-only and upstream-managed workflows. Use fixtures only when they are clearly labelled.
- After scaffolding, document the actual install, development, check and build commands in README and keep them synchronized with the package or project manifest. Do not report commands as successful unless they ran.
- Work in small steps. At handoff, list implemented flows, checks actually performed, remaining blockers, and any credentials or provider setup the owner must supply.
- Do not publish, spend money, contact customers, delete source data or run irreversible migrations without the project owner's authorization.

## Prerequisites
- cron-style scheduled search runner
- Playwright scraping
- LLM API key for listing extraction
- SMTP or Resend email alerts
- MCP server for agent access

## Stack and architecture
- Node + Express + better-sqlite3 on localhost:4920, with a small web UI for saved searches, matches, and lead notes.
- Store listings and match decisions in SQLite, dedupe by canonical URL first and fuzzy title+price+surface+location second; keep price-change history.
- Interface for this real-estate search + property pipeline workflow: a local web page with input, progress, review, and export views.

## Security and data integrity
- If Playwright scraping is unavailable, keep the source record and show a recoverable error instead of a fabricated result.
- Keep API keys and OAuth secrets in .env; redact them from logs, generated files, and error responses.
- State the practical limit: millions of already-normalized listings.

## Agent implementation rules
- Project rule, data: Store listings and match decisions in SQLite, dedupe by canonical URL first and fuzzy title+price+surface+location second; keep price-change history.
- Project rule, behavior: Saved searches live in SQLite: name, source URLs, natural-language criteria, hard filters, cadence, email recipients, and last-run time.
- Project rule, recovery: If Playwright scraping is unavailable, keep the source record and show a recoverable error instead of a fabricated result.

## Optional agent skills and references
No installable skill is listed for this guide; use the project rules and the stack documentation.

Read the linked SKILL.md and its dependencies before adding a skill. Select only the skills matching this project's runtime and task; their documentation does not supply API access, credentials or approval to perform external actions. Pin the reviewed revision where the tool supports it. Follow the chosen agent's documented project-level installation mechanism.

## Distribution ideas
These are optional planning notes. Obtain the owner's approval before publishing or contacting anyone.
- Demonstrate this real-estate search + property pipeline operation with sample or user-owned data: Saved searches live in SQLite: name, source URLs, natural-language criteria, hard filters, cadence, email recipients, and last-run time.
- Show a concrete result or export: Include an MCP server exposing tools: list_saved_searches, run_search_now, get_recent_matches, explain_match, update_search, and add_lead_note, so Claude/Codex can operate it from chat.
- State the practical limit: millions of already-normalized listings.

## Engineering roadmap
1. Phase 1, architecture and data: Node + Express + better-sqlite3 on localhost:4920, with a small web UI for saved searches, matches, and lead notes. Store listings and match decisions in SQLite, dedupe by canonical URL first and fuzzy title+price+surface+location second; keep price-change history.
2. Phase 2, implement: Saved searches live in SQLite: name, source URLs, natural-language criteria, hard filters, cadence, email recipients, and last-run time.
3. Phase 3, implement: Send cleaned listing HTML to an LLM API key from .env and extract strict JSON: title, price, currency, surface, rooms, location text, description, image URLs, source URL, and confidence.
4. Phase 4, review and output: Include an MCP server exposing tools: list_saved_searches, run_search_now, get_recent_matches, explain_match, update_search, and add_lead_note, so Claude/Codex can operate it from chat.
5. Phase 5, recovery and acceptance: If Playwright scraping is unavailable, keep the source record and show a recoverable error instead of a fabricated result. Verify this invariant with a saved fixture: An invalid input or interrupted operation must retain the source and show a recoverable state; exported records must reload with the same IDs. State the practical limit: millions of already-normalized listings.

## Paid-product capabilities outside this build
- millions of already-normalized listings
- maintained crawlers across real-estate portals
- AI extraction, deduplication, and image/semantic search at scale
- geo/POI enrichment and currency/unit normalization
- hosted boards, lead pipeline, sharing, and agentic search

## Implementation prompt
Build me a scheduled personal property monitoring agent, the honest consolation
build for One Place: it watches the sources I configure, it does not rebuild a
live nationwide real-estate index. Requirements:

- Node + Express + better-sqlite3 on localhost:4920, with a small web UI for saved
  searches, matches, and lead notes.
- Saved searches live in SQLite: name, source URLs, natural-language criteria, hard
  filters, cadence, email recipients, and last-run time.
- A node-cron runner wakes on each cadence, fetches configured source/search pages with
  Playwright, and stores raw HTML snapshots for debugging.
- Send cleaned listing HTML to an LLM API key from .env and extract strict JSON: title,
  price, currency, surface, rooms, location text, description, image URLs, source URL, and
  confidence.
- Match each extracted listing against the saved search criteria with deterministic
  filters first, then an LLM yes/no explanation for fuzzy preferences like renovation
  potential or sea view.
- Store listings and match decisions in SQLite, dedupe by canonical URL first and fuzzy
  title+price+surface+location second; keep price-change history.
- Email new matches via Resend or SMTP creds in .env, including the match reason, key
  fields, source link, and unsubscribe/disable link for that saved search.
- Include an MCP server exposing tools: list_saved_searches, run_search_now,
  get_recent_matches, explain_match, update_search, and add_lead_note, so Claude/Codex can
  operate it from chat.
- No accounts, no telemetry, binds to localhost only. Out of scope: nationwide coverage,
  anti-bot arms races, paid data resale, mobile apps, and collaborative CRM.
- README: crawler ethics, robots/terms warning, required API/email keys, how to run the
  scheduler, and how to connect the MCP server.

## Completion evidence
Demonstrate the prompt's acceptance scenarios against the scoped workflow. Include setup from a clean checkout and failure recovery. Check persistence across restart and export/restore only for the state the prompt says to store; for memory-only tools, confirm that temporary content is discarded as specified. Record actual results and remaining limitations. A detailed plan alone does not establish a working replacement.