Keysat
6d6f4bcc7e
Addresses Grant's feedback that the Workshop was confusing and underbuilt (no delete,
no approve, redundant generate-vs-feedback panels, and a stray "0" on segment lines).
Backend (architect_tools.py + server.py routes/handlers):
- retire_node: soft-delete a node + its subtree (reversible). DELETE /api/thesis/nodes/{id}.
- choose_variant: 'Use this' — keep this option, soft-delete the others in its group,
mark it approved. POST /api/thesis/nodes/{id}/choose.
- upsert_thesis_node gains actor_type so a manual human edit is recorded as 'human'.
PUT /api/thesis/nodes/{id} edits a part's text directly.
- handle_approve_line: one-click 'approve as current' — records this admin's approval on
the line's in-review version (creating + submitting one from the live tree if none),
promoting to canonical at the required distinct-approval count. POST /api/thesis/lines/{key}/approve.
Frontend (ThesisWorkshop redesign):
- Merged the redundant "Generate options" + "Give feedback" panels into one "Ask the
Architect for options" box (revise was just generate-with-guidance).
- Per option: Use this / Edit (inline) / Delete. Per part: edit + delete via the same.
- "Approve as current" bar with dual-sign-off state + a "Current ✓" badge, and a one-line
"how it works" hint. Refreshes the tree after every action.
- Fixed the stray "0": `{line.is_core && <badge>}` rendered 0 for non-core lines (SQLite
integer 0); now `{!!line.is_core && ...}`.
Verified: backend test_thesis_actions.py (choose/edit/retire-subtree/dual-approval->canonical),
and a live in-browser smoke test (JSX compiles, Workshop renders, options show Use/Edit/Delete,
approve returns 1-of-2, no runtime errors).
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.