Keysat
2afed210cb
Structural fix for the duplicate-people class of bug: instead of matching a grid contact "pill" to a contacts row heuristically by name/email (which drifted and caused the 1406 double-count), link them by id. Backend: - Migration 0004: fundraising_contacts.contact_id (additive, nullable, logical FK to contacts(id)) + index. Paired down migration. - sync_fundraising_relational now stores the id that _upsert_contact_from_fundraising already returns, so every grid contact carries its contacts-table id. - _backfill_grid_contact_ids: one-time, idempotent backfill on startup (re-runs the grid sync once if any row lacks contact_id), so existing data links immediately. - entity_resolution: grid pass prefers the explicit contact_id link (match_kind 'grid_link') over heuristic email / name+investor, guarded by a PRAGMA check so older DBs without the column still work. Frontend: - Fundraising grid "+ Row" -> "+ Investor" (clear, single investor entry point). - Contacts page: the "+ Add Contact" trigger is replaced by a pointer to the grid; the page is now a read/search/edit view (ContactDetailPanel still edits all fields). New people are added from the grid. No contact data is removed. Tests: backend/ingest/test_entity_resolution.py extended (explicit-link case, 11/11) and a new backend/test_grid_contact_link.py integration test (init_db applies 0004, sync populates contact_id to the right contact, re-sync is idempotent). py_compile + frontend html.parser clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ten31 Database — StartOS 0.4 wrapper (x86_64)
This directory is the self-contained StartOS 0.4 service package for
Ten31 Database. It is the x86_64 successor to the 0.3.5 (aarch64)
wrapper in ../0.3.5/. Both packages share the same package id
(ten-database) and the same /data volume layout so data can be
preserved across the migration.
Start here
Read DEPLOY_040.md first. It covers:
- How the image-seed data-preservation mechanism works.
- How to refresh the seed with live production data from the 0.3.5 host
(via
./refresh_seed.shor manual scp). - How to install the build prerequisites (Node, Docker,
start-cli). - How to build the x86_64
.s9pk. - How to sideload onto the StartOS 0.4 beta node.
- A rollback plan and a post-install verification checklist.
Quick cheat sheet
# From this directory:
./refresh_seed.sh embassy@embassy.local # pull live prod data into seed/
make clean
make x86
make install # uses ~/.startos/config.yaml
Data layout (unchanged from 0.3.5)
Inside the container:
/data/crm.db— SQLite database/data/backups/— app-level JSON exports/data/.crm-secret— JWT signing key (created on first boot if absent)
The entrypoint seeds an empty volume from the image's baked-in snapshot on first boot, and is a no-op for every later boot. Existing volumes are never overwritten.
Status
- Source scaffold: complete and
tsc --noEmitclean against@start9labs/start-sdk0.4.0. - Dockerfile: self-contained under
start9/0.4/with no cross-folder references tostart9/0.3.5/. - Seed snapshot: present at
seed/data/(repo dev DB — replace with live prod data before building). - Not yet built into a
.s9pkhere; build on a machine with Docker +start-cliperDEPLOY_040.md.