Keysat
fffc90c7a4
Swap the dead "scarcity as the connecting idea" / bitcoin-as-settlement spine for the v2.0 reserve-asset spine (bitcoin = apex non-debasable reserve asset; debasement = forcing function; AI = abundance engine; throughline is an asset-value/capital-flow claim, not settlement; three seams Energy<->Compute, Debasement<->Bitcoin, AI<->Data-Ownership) everywhere it was still encoded in live code, the seed, and the docs. - architect_agent.py / outreach_agent.py: both system prompts carried "scarcity as the connecting idea" and shipped settlement framing into every generated draft; rewritten to the reserve-asset spine. - thesis_seed.py: THROUGHLINE, PILLAR_1, the AI/energy-operator segment angle, and THESIS_V2 corrected and voice-cleaned (no em dash / "X, not Y" / "bet"). PILLAR_2/3 (real revenue, founder access) kept. - ensure_thesis_v2_promoted / revert_thesis_v2_promotion: make the v2.0 spine the working APPROVED spine and re-ground/clean the core nodes, deployment-state-invariant (structural targeting, not body text) and fully reversible (captures prior body/title/status/deleted_at). NODE level only: never sets a thesis_version canonical (guardrail #4); no hard deletes (guardrail #3). Wired into init_db after the v2 candidate stage. - docs/thesis-handoff.md replaced wholesale with the complete v2.0 doc; Ten31_Agentic_Build_Plan.md + PHASE_1.md throughline glosses updated. The v2.0 spine remains an unratified draft from the signal-engine workstream: canonical freeze stays the partners' dual sign-off, and Appendix-A conviction/exposure figures stay Grant's working read. 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.