[seed] Reproducible OSIS data seeding — contexts + business + projects + calendar + messages + runbook §7.4 #49

New issue

Open

opened 2026-04-30 16:30:50 +00:00 by mik-tf · 0 comments

mik-tf commented 2026-04-30 16:30:50 +00:00

Owner

Copy link

Goal

Make the demo's OSIS-backed data — contexts, business records, project boards, calendar events, messages — reproducible from this repo. Today the herodemo's per-domain hero_osis_* services have data populated somehow (visible in earlier screenshots: Persons, Companies, Deals, Projects with sprints/kanban, Calendar events, Messages), but the seed mechanism is not in this repo. A fresh deploy following docs/ops/DEPLOYMENT.md produces an empty Business / empty Projects / empty Calendar / empty Messages.

This is the largest of the seed gaps and probably needs design work before implementation.

Current state

The hero_demo runs 17 per-domain hero_osis_<X> services (identity, business, calendar, code, communication, embedder, files, finance, flow, job, ledger, media, network, projects, settings, base, ai). Each domain has its own state and own typed schema. The visible UI archipelagos read from these services through the central hero_osis_ui proxy.

data/seed/seed_install.sh does not currently touch any of them.

What needs to be seeded (visible in past demo screenshots)

UI archipelago	Records	Domain service
(foundation)	Contexts: default, geomind, threefold, incubaid, …	hero_osis_base (registry) + hero_osis_identity (membership)
Business — CRM	Persons, Companies, Contacts, Opportunities, Deals	hero_osis_business
Business — Finance	Instruments, Contracts, Transactions	hero_osis_finance
Projects	Projects, Milestones, Tasks, Stories, Sprints, Kanban boards	hero_osis_projects
Calendar	Events, recurring meetings, attendees	hero_osis_calendar
Communication	Messages, Conversations, Conferences, Calls, Contacts	hero_osis_communication
Library	Photo / Song / Video metadata (if not pure-foundry)	hero_osis_media
Library — Files	File metadata	hero_osis_files

For a "complete demo" experience every archipelago should show some realistic content in at least the canonical demo contexts.

Design questions (resolve before implementing)

1. What's the supported insert path into a per-domain OSIS server?
   • Direct JSON-RPC over the domain's rpc.sock? (Would require building per-record JSON payloads.)
   • Via hero_lib_rhai Rhai bindings against the OSIS SDK? (Would let us write seed scripts as .rhai files.)
   • Via a new osis seed-from-toml import command on the per-domain server?
   • Via direct OServer DB writes against the on-disk state? (Probably too intimate; couples seed to internal storage.)
2. Idempotence: how do we re-run a seed without duplicating records? Per-record stable IDs (UUID or deterministic hash from input)? An "update or insert" semantic in OSIS?
3. Per-context seeding: do all contexts share schema, or does each context have its own data namespace? (The 4-context split visible on herodemo suggests namespaced data.)
4. Volume: what's "enough" data per archipelago to show the UI is alive without overwhelming the snapshot? Suggested: ~5-20 records per kind per context.

Acceptance criteria

• Design doc in docs/dev/seed_osis.md (or similar) answering the four design questions above. Half a day of writing/exploration.
• Seed manifests under data/seed/<domain>/:
  • data/seed/contexts/contexts.toml — declares the contexts to register
  • data/seed/business/persons.toml (or .rhai)
  • data/seed/business/companies.toml
  • data/seed/business/deals.toml (with cross-refs to persons + companies)
  • data/seed/projects/projects.toml
  • data/seed/projects/sprints.toml
  • data/seed/projects/tasks.toml (with cross-refs to projects + persons)
  • data/seed/calendar/events.toml
  • data/seed/communication/messages.toml
  • data/seed/finance/instruments.toml, contracts.toml, transactions.toml
• Extend data/seed/seed_install.sh with a seed_osis sub-routine that loops over the manifests and invokes the chosen import path against the running per-domain services. Idempotent.
• §7.4 OSIS seeding in runbook: what gets seeded, how to add more, how to seed for new contexts.
• Verified on a fresh deploy: service_complete --update --release + seed_install.sh produces a demo where every archipelago shows realistic content matching the past screenshots.

Suggested implementation order

1. Design doc (1/2 day)
2. Pick simplest OSIS domain (e.g. hero_osis_business with just Persons), prove the import path works end-to-end
3. Add the rest of the domains
4. Wire into seed_install.sh
5. Runbook update
6. Test on a fresh VM (or on a snapshot rollback of herodemo)

Out of scope

• Photo / Song / Video file blobs — see the media-seed issue
• Update flow runbook section — see the update-runbook issue
• Building new contexts at runtime via the UI — that's a feature, not a seed

References

• 17 per-domain hero_osis_* services declared in services/hero_osis_*.toml
• Past herodemo screenshots show the target visual state (Apr 24 working demo)
• This issue is large; budget at least 1-2 dev-days post design

Signed-off-by: mik-tf

## Goal Make the demo's OSIS-backed data — contexts, business records, project boards, calendar events, messages — reproducible from this repo. Today the herodemo's per-domain `hero_osis_*` services have data populated somehow (visible in earlier screenshots: Persons, Companies, Deals, Projects with sprints/kanban, Calendar events, Messages), but the seed mechanism is not in this repo. A fresh deploy following `docs/ops/DEPLOYMENT.md` produces an empty Business / empty Projects / empty Calendar / empty Messages. This is the largest of the seed gaps and probably needs design work before implementation. ## Current state The hero_demo runs **17 per-domain `hero_osis_<X>` services** (identity, business, calendar, code, communication, embedder, files, finance, flow, job, ledger, media, network, projects, settings, base, ai). Each domain has its own state and own typed schema. The visible UI archipelagos read from these services through the central `hero_osis_ui` proxy. `data/seed/seed_install.sh` does not currently touch any of them. ## What needs to be seeded (visible in past demo screenshots) | UI archipelago | Records | Domain service | |---|---|---| | (foundation) | Contexts: `default`, `geomind`, `threefold`, `incubaid`, … | `hero_osis_base` (registry) + `hero_osis_identity` (membership) | | Business — CRM | Persons, Companies, Contacts, Opportunities, Deals | `hero_osis_business` | | Business — Finance | Instruments, Contracts, Transactions | `hero_osis_finance` | | Projects | Projects, Milestones, Tasks, Stories, Sprints, Kanban boards | `hero_osis_projects` | | Calendar | Events, recurring meetings, attendees | `hero_osis_calendar` | | Communication | Messages, Conversations, Conferences, Calls, Contacts | `hero_osis_communication` | | Library | Photo / Song / Video metadata (if not pure-foundry) | `hero_osis_media` | | Library — Files | File metadata | `hero_osis_files` | For a "complete demo" experience every archipelago should show some realistic content in at least the canonical demo contexts. ## Design questions (resolve before implementing) 1. **What's the supported insert path into a per-domain OSIS server?** - Direct JSON-RPC over the domain's `rpc.sock`? (Would require building per-record JSON payloads.) - Via `hero_lib_rhai` Rhai bindings against the OSIS SDK? (Would let us write seed scripts as `.rhai` files.) - Via a new `osis seed-from-toml` import command on the per-domain server? - Via direct OServer DB writes against the on-disk state? (Probably too intimate; couples seed to internal storage.) 2. **Idempotence**: how do we re-run a seed without duplicating records? Per-record stable IDs (UUID or deterministic hash from input)? An "update or insert" semantic in OSIS? 3. **Per-context seeding**: do all contexts share schema, or does each context have its own data namespace? (The 4-context split visible on herodemo suggests namespaced data.) 4. **Volume**: what's "enough" data per archipelago to show the UI is alive without overwhelming the snapshot? Suggested: ~5-20 records per kind per context. ## Acceptance criteria - [ ] **Design doc** in `docs/dev/seed_osis.md` (or similar) answering the four design questions above. Half a day of writing/exploration. - [ ] **Seed manifests** under `data/seed/<domain>/`: - `data/seed/contexts/contexts.toml` — declares the contexts to register - `data/seed/business/persons.toml` (or `.rhai`) - `data/seed/business/companies.toml` - `data/seed/business/deals.toml` (with cross-refs to persons + companies) - `data/seed/projects/projects.toml` - `data/seed/projects/sprints.toml` - `data/seed/projects/tasks.toml` (with cross-refs to projects + persons) - `data/seed/calendar/events.toml` - `data/seed/communication/messages.toml` - `data/seed/finance/instruments.toml`, `contracts.toml`, `transactions.toml` - [ ] **Extend `data/seed/seed_install.sh`** with a `seed_osis` sub-routine that loops over the manifests and invokes the chosen import path against the running per-domain services. Idempotent. - [ ] **`§7.4 OSIS seeding` in runbook**: what gets seeded, how to add more, how to seed for new contexts. - [ ] **Verified on a fresh deploy**: `service_complete --update --release` + `seed_install.sh` produces a demo where every archipelago shows realistic content matching the past screenshots. ## Suggested implementation order 1. Design doc (1/2 day) 2. Pick simplest OSIS domain (e.g. `hero_osis_business` with just Persons), prove the import path works end-to-end 3. Add the rest of the domains 4. Wire into `seed_install.sh` 5. Runbook update 6. Test on a fresh VM (or on a snapshot rollback of herodemo) ## Out of scope - Photo / Song / Video file blobs — see the media-seed issue - Update flow runbook section — see the update-runbook issue - Building new contexts at runtime via the UI — that's a feature, not a seed ## References - 17 per-domain `hero_osis_*` services declared in `services/hero_osis_*.toml` - Past herodemo screenshots show the target visual state (Apr 24 working demo) - This issue is large; budget at least 1-2 dev-days post design Signed-off-by: mik-tf

mik-tf referenced this issue 2026-04-30 17:52:26 +00:00

[spec] Hero OS bootstrap MUST work on any Ubuntu 24.04+ — root or unprivileged user #50

mik-tf referenced this issue 2026-05-10 17:52:56 +00:00

[vision] Hero OS as an ambient AI desktop — sovereign, voice-native, multi-context #52

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

v0.9.3-dev

v0.9.0-dev

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_demo#49

No description provided.