brfosint

You are Codex. Help me build and deploy a Liivo-based BRF OSINT team that finds, analyzes and monitors apartments in my target area.

Use Liivo/OSC building blocks wherever possible. Before creating custom infrastructure, inspect what Liivo services exist and prefer managed Liivo components for Postgres, OCR, parameter storage, My Apps and My Agent Tasks. Act end-to-end: create the repo/app/services/tasks, deploy, verify, and then run the first agent cycle.

My search profile:

• Area/city: [AREA_OR_CITY]
• Target streets/addresses: [TARGET_STREETS]
• Minimum apartment size: [MIN_LIVING_AREA_SQM] sqm
• Minimum rooms: [MIN_ROOMS]
• Preferred apartment size for fee calculations: [PREFERRED_SIZE_SQM] sqm
• Notification email: [EMAIL]
• Basic auth username: [BASIC_AUTH_USER]
• Risk preference: [LOW_FEE / LOW_DEBT / GARAGE / LAND_OWNERSHIP / VALUE_UPSIDE / OTHER]

Important decision factors:

• Current monthly fee and annual fee per sqm.
• Estimated true fee, including maintenance need and refinancing risk.
• Deviation between listed/current fee and true fee.
• Debt per sqm.
• Average interest and loans maturing within three years.
• Liquidity/debt or similar short-term resilience indicator.
• Land ownership versus leasehold/tomtratt.
• Garage or parking access.
• Elevator, size, rooms and apartment fit.
• Sold prices, current listings, upcoming listings and broker activity.
• Source confidence and data freshness.

Privacy and compliance rules:

• Use only lawful public data, explicit APIs, user-provided exports or manually added source URLs.
• Do not collect private-person profiles, names, phone numbers or resident-level data.
• Focus on apartments, BRFs, addresses, brokers, annual reports, market listings and public association facts.
• Respect robots, rate limits, source terms and Cloudflare/interstitial protections.
• If a site blocks automation, create a manual import path instead of trying to bypass the block.
• Every stored fact must keep source URL, timestamp, confidence and enough evidence to audit the claim.

Set up the Liivo foundation:

1. Connect to Liivo/OSC.
2. Create or select a git repository for the project.
3. Create a Liivo PostgreSQL service for the app database.
4. Create a Liivo parameter/config store for secrets and runtime settings.
5. Store at least:
   • DATABASE_URL or equivalent database binding.
   • TARGET_STREETS.
   • MIN_ROOMS.
   • MIN_LIVING_AREA_SQM.
   • PREFERRED_SIZE_SQM.
   • BASIC_AUTH_USER.
   • BASIC_AUTH_PASSWORD.
   • SMTP settings if email notifications are enabled.
   • API credentials only if explicitly available.
6. Create a Liivo My App using the Node.js runtime unless the implementation clearly requires another runtime.
7. Deploy the app from the repository and verify that the stable Liivo URL responds.

Build the database model with tables for at least:

• brfs
• brf_addresses
• annual_reports
• financial_snapshots
• listings
• broker_sources
• brokers
• manual_sources
• source_facts
• agent_runs
• notifications
• osint_lessons or another durable self-improvement memory table

Use idempotent upserts. Store raw evidence or normalized snippets where useful. Separate source reliability from claim confidence.

Build the app:

• Make the map the primary landing view.
• Make it mobile-first, with the map in focus on phones.
• Show BRF pins.
• Let me show/hide current listings, upcoming listings and sold listings so the map does not become cluttered.
• BRF pin popup should show score first, then confidence, fee for my preferred apartment size, true-fee deviation if available, garage/land hints and link to BRF detail page.
• Listing pin popup should show status, asking price or sold price, sold/listed date, rooms, sqm, fee, broker/source link and linked BRF.
• Add a BRF detail page with the full financial analysis and plain-language explanations of each metric: what is good, what is bad and how much confidence we have.
• Add a BRF analysis table.
• Add an object/listing view with tabs:
  • for sale/upcoming first
  • sold objects second
• Sold objects must use the sale date from the source when available; use discovery date only as fallback.
• Add a broker intelligence page showing brokers/offices active in the area, volume, streets, BRFs, price/sqm and source coverage.
• Add a process page for agent runs, source status, parser failures, unresolved gaps and data freshness.
• Add a sources page for broker/manual sources showing URL, status, last scanned time and which BRFs/streets they target.
• Protect the app with basic auth, while leaving health checks accessible.

Create these agent roles:

1. osint-improvement Mission: research better legal open-source methods, source patterns and parser improvements. Focus on:

• pre-market signals
• sold-price sources
• broker source discovery
• local-media housing transaction sources
• annual-report discovery and extraction improvements
• OCR strategy for scanned reports
• lessons learned from recent failures in agent_runs This task should update durable notes/playbooks and, when appropriate, improve code/parsers.

2. brf-discovery Mission: identify BRFs, organization numbers, addresses and property mappings in the target area. Sources:

• BRF websites
• Allabrf-like pages
• Hittabrf-like pages
• broker object pages
• association pages
• public search results and manually added sources Rules:
• Use municipality/address validation to avoid same-street false matches in other towns.
• Preserve uncertainty and confidence.
• Store address aliases and spelling variants.

3. geocode-addresses Mission: geocode BRF and listing addresses after discovery or market updates. Goal: new BRFs and objects should appear on the map without needing an app restart.

4. annual-report-fetcher Mission: find and store annual reports for known BRFs. Sources and patterns:

• BRF websites.
• Broker information pages.
• Association pages.
• Broker object pages where annual reports are linked.
• Common BRF-site paths such as /maklarinformation/, /mäklarinformation/ and /allmant/maklarinformation/. Store URL, year, hash, fetch timestamp and source confidence.

5. financial-extractor Mission: extract financial facts from annual reports. Extract:

• annual fee per sqm
• monthly fee where available
• debt per sqm
• average interest
• loan maturity and loans within three years
• maintenance plan and major works
• maintenance fund/reserves
• liquidity/debt or similar liquidity indicator
• land ownership/tomtratt
• garage/parking signals
• apartment count and premises count If a PDF lacks text, use Liivo OCR if available. If OCR or parsing fails, record a gap and improve the parser where possible.

6. true-fee-analyst Mission: calculate true fee, score and score explanation. Score guidance:

• 100 is best.
• Include debt, fee level, true-fee deviation, refinancing risk, maintenance risk, land ownership, garage access, data quality and market attractiveness.
• If true fee is missing, a low current fee may count mildly positive but must not be weighted heavily because it may be unsustainably low.
• Only recompute when relevant input data changed.

7. market-watcher Mission: find current, upcoming and sold objects matching the search profile. Sources:

• broker pages
• explicit APIs where available
• user-provided exports from blocked/commercial sites
• manually added source URLs Rules:
• Do not bypass Cloudflare or login walls.
• Store source URL, broker, status, rooms, sqm, fee, asking/sold price, listing date and sold date.
• Prefer source-provided sold date over discovery date.

8. listing-brf-reconciler Mission: link listings to BRFs. Use:

• exact address match
• broker association section
• BRF homepage link from broker page
• Allabrf/Hittabrf-style association address lists
• annual reports linked from the object page Be conservative and store evidence/confidence in the listing analysis.

9. broker-intelligence Mission: map brokers and offices active in the target area. Track:

• broker name normalization
• office/company
• sold/current object counts
• streets and BRFs covered
• median price/sqm
• source quality and missing broker gaps

10. notifications Mission: send consolidated email digests. Notify on:

• new relevant object
• status change
• new BRF
• important source failure Do not email for ordinary BRF score changes unless I explicitly ask for it. Consolidate events to reduce spam.

Recommended Liivo My Agent Task schedule:

• osint-improvement: weekly, first in the chain.
• brf-discovery: weekly, after osint-improvement.
• annual-report-fetcher: weekly, after brf-discovery.
• financial-extractor: weekly, after annual-report-fetcher.
• true-fee-analyst: weekly, only if relevant inputs changed.
• geocode-addresses: after discovery and after market updates.
• market-watcher: twice weekly.
• listing-brf-reconciler: after market-watcher.
• broker-intelligence: after market-watcher/reconciler or weekly.
• notifications: after market/reconciler, as a digest.

Make My Agent Task prompts outcome-driven. The agents should not merely run scripts; they should inspect gaps, improve parser/code when needed, update the database, leave an agent_runs summary and make the next run better.

Definition of done:

• Git repository exists and has all code.
• Liivo Postgres/config/app are created and connected.
• App is deployed on a stable Liivo URL.
• Database migrations/init ran successfully.
• My Agent Tasks exist with Codex runtimes if available.
• A first manual run of discovery, annual report fetch, extraction, market watch, reconciliation, scoring and geocoding has been verified.
• The map shows BRFs and listings.
• The process page shows recent agent runs.
• At least one BRF detail page has traceable source evidence.
• All known gaps are recorded in agent_runs or source_facts with next-step notes.

Start now by inspecting available Liivo services, then provision the required services and build the first deployable version.