Phase 0 foundation: canonical schema, ingest pipeline, CRM MCP server
Workstream A–C substrate for the Ten31 agentic system: - A1: docs/crm-overview.md; CLAUDE.md conventions + guardrail #9 - A2: additive/reversible core migration (canonical_entities, entity_links, interaction_log, relationship_edges, soft-delete) + ledgered runner - B1/B3: chunking + deterministic entity resolution (backend/ingest) - B2: dense (bge-m3) + BM25 sparse ingest to Qdrant crm_chunks - C: CRM MCP server (reads, retrieval modes, logged writes) — no outbound tools - docs: redaction/re-hydration, Gmail enablement runbook - synthetic test data; .env.example; housekeeping (.gitignore, untrack crm.db, drop legacy files + start9/0.3.5) Verified end-to-end on synthetic data + live Sparks (hybrid > dense on entity queries). Real backfill runs on Ten31 infra; index holds synthetic data only. Branch snapshot also captures pre-existing working-tree changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
+50
-7
@@ -1,9 +1,52 @@
|
||||
# Start9 Wrapper (0.4 placeholder)
|
||||
# Ten31 Database — StartOS 0.4 wrapper (x86_64)
|
||||
|
||||
This directory is reserved for the StartOS 0.4 package wrapper.
|
||||
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.
|
||||
|
||||
Migration plan from 0.3.5:
|
||||
1. Keep package id stable (`ten-database`) if StartOS migration path allows.
|
||||
2. Keep mounted data directory contract unchanged (`/data/crm.db`, `/data/backups`).
|
||||
3. Rebuild wrapper files against 0.4 packaging spec and verify with current start-sdk.
|
||||
4. Test upgrade on a staging node using production backup restore before live cutover.
|
||||
## Start here
|
||||
|
||||
**Read `DEPLOY_040.md` first.** It covers:
|
||||
|
||||
1. How the image-seed data-preservation mechanism works.
|
||||
2. How to refresh the seed with live production data from the 0.3.5 host
|
||||
(via `./refresh_seed.sh` or manual scp).
|
||||
3. How to install the build prerequisites (Node, Docker, `start-cli`).
|
||||
4. How to build the x86_64 `.s9pk`.
|
||||
5. How to sideload onto the StartOS 0.4 beta node.
|
||||
6. A rollback plan and a post-install verification checklist.
|
||||
|
||||
## Quick cheat sheet
|
||||
|
||||
```sh
|
||||
# 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 --noEmit` clean against
|
||||
`@start9labs/start-sdk` 0.4.0.
|
||||
- Dockerfile: self-contained under `start9/0.4/` with no cross-folder
|
||||
references to `start9/0.3.5/`.
|
||||
- Seed snapshot: present at `seed/data/` (repo dev DB — replace with live
|
||||
prod data before building).
|
||||
- Not yet built into a `.s9pk` here; build on a machine with Docker +
|
||||
`start-cli` per `DEPLOY_040.md`.
|
||||
|
||||
Reference in New Issue
Block a user