property-permit-leads

name	property-permit-leads
description	Scans all configured Romanian city permit sources for new company-led multi-unit residential and mixed-use projects, enriches each company with a reviewed CUI, ANAF status, annual financial signals, and a website when found, then writes an HTML lead report with evidence and reviewable email drafts. Use when Stock.estate needs new property developer leads from construction permits.

Property permit leads

Input

Use the source registry at demo/input/sources.json. Use the reviewed company identity file at demo/input/company-identities.json. The user does not supply a city, URL, company, or CUI. Each run checks every enabled permit source.

Steps

1. From the repository root, run a discovery scan without writing scan state:

   node .agents/skills/property-permit-leads/scripts/scan.mjs --sources demo/input/sources.json --identities demo/input/company-identities.json --output demo/output/leads.html --no-state

2. Read demo/output/leads.json. Find each matching company whose screening.reason says that reviewed CUI evidence is missing.

3. If one or more companies need CUI research, dispatch one research subagent. Give it the exact permit company names and cities. Tell it to use web search and return only:

   • the exact permit company name;
   • the CUI;
   • the legal company name shown by the source;
   • the public source URL for the CUI;
   • the official company website and its evidence URL, or not found;
   • a public role email from the official company website, or not found;
   • the research date.

4. Tell the research subagent not to return owners, representatives, private persons, phone numbers, home addresses, or personal email addresses. A company directory can support CUI discovery. Only the company website can support a website or role email claim.

5. Review the subagent result. Add an item to demo/input/company-identities.json only when the source shows the company name and CUI. Add website_url only when the evidence identifies it as the company website. Add contact_email only for a role address such as office@ or contact@ on that website. Do not add a guessed value.

6. Run the same command again without --no-state. This final run checks the CUI through the official ANAF service. It uses the synchronous v9 service first and the asynchronous v8 service as a fallback. It also gets the latest available annual financial statement from the ANAF balance-sheet service.

7. Read the command summary. Treat a permit or ANAF error as a visible limitation. Do not replace failed retrieval with guessed data.

8. Run open demo/output/leads.html to open the report in the macOS default browser. Confirm that each card has the permit evidence, company enrichment, financial risk flag, filter result, source links, retrieval time, and correct email action.

9. Report the output path, counts for ready, needs review, and excluded companies, source failures, and excluded permit rows.

The scanner writes .permit-leads-state.json after each successful source scan. Later runs use it to report new permit IDs. A fresh clone uses the initial date for each source in demo/input/sources.json.

Selection rules

• Include a permit holder only when its name contains a Romanian legal-entity marker such as SRL or SA.
• Include new construction for multi-unit residential or mixed-use buildings. Accept direct evidence such as collective housing, apartment blocks, apartments, a housing complex, or two or more homes or buildings.
• Keep the municipality text as evidence. Do not infer project size or use when the text does not state it.
• Mark direct city permit data as high confidence for the permit claim only.

Company enrichment and filter

• Require a reviewed CUI source and an exact normalized legal-name match from ANAF before a lead can enter Ready for outreach review.
• Enrich a matched company with its CUI, registration state, registration date, main CAEN code, VAT state, latest net turnover, net result, current assets, total debt, average employees, and official website when evidence is available.
• Show a financial risk flag from the current-assets-to-total-debt coverage proxy. Use the guide's 1.0 and 1.5 levels for review priority. State that the ANAF report does not separate current liabilities, so this is not the general liquidity ratio or a credit rating.
• Put a company in Needs company review when the CUI is missing, ANAF is unavailable, or the legal names do not match.
• Put a company in Excluded by company status only when ANAF reports fiscal inactivity or a removal date.
• Use the ANAF result only for the fields that it supplies. Do not treat this basic status filter as an insolvency, court, ownership, sanctions, or reputation check.
• Cite the CUI discovery source, ANAF service documentation, and municipal permit source in the report.

Boundaries

• Exclude every natural-person applicant and every applicant whose legal-entity status is not clear.
• Keep outreach as a reviewable mailto: draft. Use a verified public role email when available. Otherwise leave the recipient blank and state that the recipient is not verified. Never send email.
• Withhold the email action for companies that need review or are excluded.
• Never label a company as safe, unsafe, reputable, or shady. State only the result and limit of the evidence-based filter.
• Keep the financial flag separate from the ANAF company-status filter. Missing or weak financial data does not exclude a company.
• Use public permit and company data only. Do not add personal contact details.

Done when

demo/output/leads.html exists, all enabled permit sources were checked or show a retrieval error, each matching company has a review state and a financial signal or visible data limit, only companies that pass the ANAF check have email actions, each claim links to evidence, and no natural-person applicant appears in the output.