`bubbesblock/review.md`

29 lines
## Snapshot
- Community surface for a home-history ecosystem: block posts, marketplace, neighbor profiles, events, address-tagged Q&A.
- Stack: unclear; no application source, package files, runtime config, or datastore files observed.
- How it's run: unclear; no pm2/systemd/launchd/cron/docker/package scripts observed.
- Status: stale/scaffold-only; no runnable app present.

## Top Risks (P0 — fix this week)
- `.env:2`, `.env:3`, `.env:5`: real API keys live in the project root; accidental sync/commit leaks Google/DPLA access. Rotate keys if shared, keep `.env` out of VCS/backups, and enforce domain/IP/API restrictions.
- `README.md:9`: claimed-address posting gate is only documented, with no enforceable auth code present. If this repo is deployed as-is or rebuilt later, posting can ship without verification; implement server-side verification against `claimmyaddress.com`.

## Notable Issues (P1 — fix this month)
- `README.md:5`: core plan is a sibling-relative file, so this repo is not self-contained. Copy the operational contract/API expectations into this repo or add a checked-in spec.
- `README.md:7-9`: the project depends on cross-domain identity/history flows, but no API boundary, failure handling, or trust model is present. Define request/response contracts and what happens when sister domains are unavailable.
- Project root: no source, tests, package/deploy config, or datastore schema observed. This prevents review of auth, input validation, dependency CVEs, jobs, SQL injection, or data loss paths.

## Polish (P2 — when convenient)
- `.env.example:1-2`: good start, but add all required keys, including `DPLA_API_KEY`, so setup drift is visible.
- `README.md`: add a minimal “run/deploy/status” section once code exists.
- Project root: add `.gitignore` before initializing Git; it should explicitly exclude `.env`.

## Strengths
- `README.md:7-13`: domain responsibility and sister-domain boundaries are clearly stated.
- `README.md:9`: address-claim verification is identified as a core product constraint, which is the right place to anchor abuse prevention.
- `.env.example:1-2`: separates browser and server Google keys and calls out referrer/IP restrictions.

## Open questions for the owner
- Is the actual source code in another directory or private repo?
- Are the `.env` keys production keys, and have they ever been shared or committed?
- Is `claimmyaddress.com` intended to be the sole identity/authorization source?