You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+47-11Lines changed: 47 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,7 @@
2
2
3
3
Seek and Score is a planning-first, explainable property-intelligence platform for discovering, underwriting, and ranking real-estate investment opportunities. Central Texas is the launch market; the architecture is intentionally designed to add county-by-county data adapters and Opportunity Zone cohorts across the United States without forking the core product.
4
4
5
-
> Status: architecture and delivery planning. No production application or live investment recommendations exist yet.
5
+
> Status: Milestone 1 foundation. A synthetic-only operator console, API, workers, database migrations, local infrastructure, CI, and Railway deployment templates are runnable. Live data ingestion, automated outreach, and production investment recommendations remain disabled.
6
6
7
7
## North-star outcome
8
8
@@ -59,6 +59,41 @@ Parcel location is also not a legal conclusion that an investment qualifies for
59
59
60
60
See [Opportunity Zone and national data design](docs/OPPORTUNITY_ZONES_AND_DATA.md).
61
61
62
+
## What runs today
63
+
64
+
The foundation slice is intentionally useful without implying that the product is ready for live acquisitions:
65
+
66
+
- a responsive Next.js operator console with a synthetic Top 25 queue, evidence, risks, filters, and candidate drill-down;
67
+
- a FastAPI read API with health, version, capabilities, synthetic candidate list, and candidate-detail endpoints;
68
+
- modular backend boundaries for platform, registry, identity, and engagement;
69
+
- policy-gated outreach states where every outbound channel and send action fails closed;
70
+
- Alembic foundations for the registry, identity, engagement, and platform schemas;
71
+
- worker and scheduler entrypoints with inert defaults;
72
+
- PostGIS, Redis, and private MinIO services for local development;
73
+
- non-root production containers, continuous integration, configuration validation, and credential scanning.
74
+
75
+
The web application prefers the API when `API_BASE_URL` is set and healthy. It falls back to an explicitly labeled synthetic fixture when the API is unavailable, so a preview never silently turns into a live-data product.
76
+
77
+
## Quick start
78
+
79
+
Prerequisites are Python 3.12+, [uv](https://docs.astral.sh/uv/), Node.js 22+, pnpm 10+, and Docker for the infrastructure profile.
80
+
81
+
```bash
82
+
make install
83
+
make check
84
+
```
85
+
86
+
Run the API and web application in separate terminals:
87
+
88
+
```bash
89
+
uv run python -m seekandscore.api
90
+
pnpm dev
91
+
```
92
+
93
+
Then open `http://localhost:3000`. The API exposes `http://localhost:8000/readyz`, `/version`, `/v1/capabilities`, and `/v1/candidates`.
94
+
95
+
For local persistence services, use `make infra-up`. To build and run the complete container stack with the same safe defaults, use `make app-up`.
96
+
62
97
## Repository guide
63
98
64
99
-[Implementation plan](docs/IMPLEMENTATION_PLAN.md) — phases, deliverables, acceptance criteria, dependencies, and risks
@@ -85,7 +120,7 @@ See [Opportunity Zone and national data design](docs/OPPORTUNITY_ZONES_AND_DATA.
85
120
10. Acquisition outreach is party-verified, policy-gated, human-approved, suppressible, and auditable.
86
121
11. A second, dissimilar market must prove the abstraction before national expansion.
engagement/ policy-gated contact and scheduling boundary
106
139
infra/
140
+
docker/ production container definitions
107
141
railway/ service configuration and runbooks
108
142
docs/
109
143
adr/ architecture decision records
144
+
tests/
145
+
backend/ API, settings, read-model, and runtime tests
110
146
```
111
147
112
-
This structure is the target scaffold for Milestone 1; the current repository intentionally begins with decisions and execution criteria before code.
148
+
Source adapters, regional packs, scoring configurations, and live provider integrations will be added behind these boundaries in later milestones.
113
149
114
150
## Railway strategy
115
151
116
-
Railway will host stateless web/API/worker processes and the initial Redis/PostGIS services. The MVP can use a single Railway PostGIS node with tested backups. Railway's native PostgreSQL high-availability conversion does not support the community PostGIS image, so production scale has an explicit decision gate: accept the documented single-node risk or move PostGIS to a managed HA provider while leaving the applications on Railway.
152
+
Railway hosts the stateless web/API/worker processes and can host the initial Redis/PostGIS services. The MVP can use a single Railway PostGIS node with tested backups. Railway's native PostgreSQL high-availability conversion does not support the community PostGIS image, so production scale has an explicit decision gate: accept the documented single-node risk or move PostGIS to a managed HA provider while leaving the applications on Railway.
117
153
118
-
No Railway project is created in this planning commit. Deployment starts after the foundation service has health endpoints, migrations, a synthetic fixture dataset, and a restore-tested database.
154
+
The initial staging release deploys only synthetic application behavior with ingestion and outreach disabled. Database-backed ingestion is activated only after the PostGIS backup/restore path and source rights are verified; provider outreach remains a separate production activation decision.
0 commit comments