Three workstreams: host-testable firmware logic (closing the gap that let
the RD03E frame bug ship), crossing over as a five-layer rite with
trait-driven twists, and a /doctrine page whose every arcane claim maps to
a real mechanism in the source.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Five parallel workstreams: profile model+rank+API, profile UI, hunter
messages, surfacing the Codex encounter record (the summoner and every
hunter who has met a spirit — the data already exists in
Entity.discovered_by and entity_sightings, it just was never shown), and a
verification pass over the audit findings that were never machine-confirmed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
app/haunts.py merges two free, keyless, properly-licensed APIs rather than
scraping: Wikipedia geosearch+extracts (CC BY-SA) and OSM Overpass (ODbL).
Every haunt carries its source and a link back.
The Wikipedia-article requirement doubles as a notability gate: no article,
no pin. That keeps the map to documented history rather than rumour and
makes every entry independently checkable.
Deliberately excluded — recent crimes at residential addresses. People live
in those houses now and get harassed; the families are usually still alive.
So crime-framed entries must clear HISTORICAL_CUTOFF_YEAR, anything
residential is blurred to ~250m (street, never a door number), and an entry
that reads as a crime with no legible date is excluded rather than assumed
old. Battlefields, plague pits, gaols, executions and famous historical
cases are unaffected.
Privacy: the seeker's exact coordinate never leaves the process. Queries
snap to a ~1km grid before going upstream — far finer than the search
radius, coarse enough that Wikipedia and OSM never learn where anyone is,
and it makes the cache shared across a neighbourhood.
Two bugs found and fixed by testing against the live services rather than
assuming:
- Overpass answered 504. The naive query built 28 separate `around:`
searches (14 kinds x 2 element types); regrouping to one regex-alternated
clause per tag key with `nwr` cuts it to four.
- The flat keyword filter put "Fenchurch Street railway station" on the map
because its article mentions a fire. Hints are now split into strong
(qualify alone) and weak (need two), verified against live results.
Known limitation, honestly: all three public Overpass mirrors currently
time out or return empty from this host, so the map is Wikipedia-only in
practice right now. fetch_overpass already returns [] on any failure, so
this degrades quietly and self-heals if a mirror recovers.
Also adds the hunter-profiles contract spec.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Third sub-project: physical hardware (ESP32-P4, presence + BME280 env
sensors, experimental RTL-SDR USB-host module) pairs with a user's account
and streams telemetry that feeds the SAME anomaly/summon pipeline the
browser-based modes already use — not a passive dashboard, the actual
business model (selling devices that summon spirits). Defines device
pairing/auth (reusing the existing session-token hash convention),
a generic/extensible sensor-reading shape, and the live-broadcast +
anomaly-detection contract split across 5 workstreams (G/K backend,
H frontend, I/J firmware).
Renaming: "Armory" read too militaristic for a séance app. Landed on "The
Reliquary" (not "The Threshold" — that name was already taken by the
landing-page back-link).
Spec addendum: added a visible essence currency (earned per summon, spent
on unlocks — distinct from the hidden favor score) and a fourth judgment
verdict, cross_over, for compassionately helping a genuinely benevolent
"stuck" spirit move on rather than just trusting or banishing it. Updates
workstreams B/C/E/F accordingly before any of them are dispatched.
First sub-project of the "make contact feel real" arc (candle rituals,
quantum RNG, tuning, progression, escalation to follow as separate specs).
Defines the stability-score contract shared between the backend audio
degradation and frontend text-glitch halves so they can build in parallel.
Reordered to put a real browsable site first (React frontend served
by FastAPI, Tasks 1-2) ahead of backend-only plumbing (Ollama queue,
Piper TTS, WebSocket session channel, Tasks 3-5) that Plans 3-6 will
build spirit-mode logic on top of.
Task 1 now scaffolds a Python venv and a systemd unit template
instead of a Dockerfile/Compose stack. Task 3 installs Postgres
directly via apt and creates dev/test databases on the same
instance. All test-run commands switched from `docker compose run`
to plain `pytest` with exported env vars.
User's Proxmox LXC CTs run apps as plain venv + systemd services,
not containers. Updated spec sections 2, 6, and 9 to reflect a
bare-metal deployment: Postgres via apt, FastAPI app via uvicorn
under a systemd unit.
Captures the v1 architecture for the self-hosted spirit-communication
web app: FastAPI + React stack, four launch modes (Spirit Radio, EVP,
Wire Ghost, Ouija/Planchette), hybrid entity/Codex system backed by a
remote CPU-only Ollama instance, and deployment via Docker Compose
behind a Cloudflare Tunnel. ESP32-P4/C6 hardware is scoped out for a
future spec.
