[ops] Formalize the nu-shell OSIS seed step — canonical hero_zero_seed binary + schema-aligned TOMLs #162
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
Today hero_zero's legacy seed data (
hero_zero/dist/var/seed/<context>/<domain>/*.toml, 572 files across 5 contexts) is the only thing that turns a freshly-installed OSIS into a demo-ready state with Business/Calendar/Projects/Media populated. In the nu-shell deploy path, nothing automates this — it took a manual scp + 2 rounds of running the binary + a custom Python uploader on heronu.Issues encountered running the legacy binary against the current OSIS:
.setwrite reportsFailed to parse response: error decoding response body, but writes actually succeed. The binary expects an older OSIS response format.status ∈ {todo, in_progress, done}but seed TOMLs usestatus = "active"/"not_started". Had to patch via a Python transformer.<domain>.setrejectsotomlparam name, needsobjparam withO:\nprefix. Binary doesn't know this.http://localhost:3377/api(hero_proxy era); nu-shell deploy uses hero_routerhttp://10.1.2.2:9988/hero_osis/ui.Net result: the legacy binary works for about 70% of the seed corpus; the rest requires hand-written shims per domain.
Proposed architecture
Rewrite as
hero_zero_seed(orhero_osis_seed— either way, maintained in-tree):Design points:
hero_zero/dist/var/seed/— a build artifact path. They should be versioned source, e.g.lhumina_code/demo_seed/<context>/<domain>/*.toml.cargo test -p hero_zero_seedwhich attempts to load every seed TOML against the current OSIS types. Any drift fails CI immediately. No more surprise runtime failures.hero_zero_seed --context geomind --domain projectsshould idempotently (re-)seed ONLY those records, leaving everything else untouched.O:\nprefix,.setvs.create,objvsdataparam selection based on OpenRPC spec.hero_zero_seed --verifyqueries OSIS, compares to expected TOML set, prints diff. Used by CI and by the disaster-recovery restore flow (see #XYZ) to confirm the replay worked.HERO_SOCKET_DIRexists, use Unix sockets per-domain; else use the configured HTTP URL.Concrete migration tasks
hero_zero/dist/var/seed/*→ newdemo_seed/repo (or subdir ofhero_zero).hero_osis_seedbinary against current hero_osis_sdk types.cargo test -p hero_zero_seed -- --fixtures=demo_seed/— fails on schema drift.hero_skills install-all: afterhero_proc startcompletes, runhero_zero_seed --context default --all-domainsfor a first-boot baseline.What's in scope vs not
In scope: OSIS per-domain data (business, calendar, projects, identity, communication, media, base, ai, files).
Out of scope for this issue: hero_books library content (that's driven by
libraries.txtalready), hero_foundry webdav media (already seeded from/home/driver/hero/var/seed_media), hero_office's own document store (separate issue).Related
Signed-off-by: mik-tf
Resolved by
lhumina_code/hero_skills@7c823d1(PR lhumina_code/hero_skills#126).Part of Phase 2 tracker #185.
Reopening — closed in error earlier today. The hero_demo runbook §13 had this issue listed as the tracker for an unrelated deploy step (ONNX install for #162 / HERO_ROOTDIR override for #164), and I trusted the reference without checking the actual issue body. Apologies for the noise. The actual scope of this issue is unchanged from when it was filed.
The correct trackers for the work that just landed: ONNX install + HERO_ROOTDIR are covered directly by
lhumina_code/hero_skills@7c823d1and tracked under #185 (no separate sub-issues filed).Moved to hero_demo#30 — see lhumina_code/hero_demo#30