Boligmester

boligmester is an open-source, terminal-first property buying assistant for the Danish housing market.

It is being built around Google ADK, deterministic finance logic, and evidence-aware property analysis.

Status

This is still an early build focused on the first usable apartment analysis workflow.

Current implementation includes:

• delivery planning in plan.md
• mission, vision, and goals in plan.md
• a typed application service layer under src/
• deterministic finance calculations
• calibrated Danish finance screening assumptions
• listing ingestion with fixture, live-fetch, browser-fallback, and imported-capture paths
• manifest-backed listing regression fixtures
• apartment search workflow with fixture/live-fetch parsing and local persistence
• saved-apartment workflow for revisiting candidate listings from the TUI
• apartment comparison workflow with deterministic finance outputs and missing evidence
• watchlist workflow with persisted snapshots and field-level change detection
• a validation harness for real-world URL sets
• an explicit top-level analysis workflow graph with deterministic nodes and an ADK agent boundary
• a terminal UI for URL analysis, apartment search, saved apartments, comparisons, watchlists, and buyer profiles
• local workspace persistence for buyer profiles, search runs, saved apartments, comparisons, watchlists, and analysis run metadata

Still in progress:

• web productization and hosted workflows
• graph views and scheduled watchlist notifications

Read Next

• Development setup
• Contribution guide
• Vision, mission, and goals
• ADK analysis graph
• Browser fetch contract
• Finance boundary
• Finance policy calibration
• MVP validation notes
• Local workspace
• Apartment search workflow
• Saved apartments
• Apartment comparison workflow
• Watchlist workflow

Repository Layout

src/apartment_agents/
  agents/
  city_adapters/
  finance/
  reports/
  storage/
  tools/
  tui/
tests/
examples/
docs/

Principles

The project should stay honest about confidence, source quality, and missing data. It should not present shallow or weakly evidenced outputs as strong recommendations.

Active work tracking belongs in GitHub Issues, not local markdown backlog files.