Differentiate Identity Seed Data per Context #8

New issue

Closed

opened 2026-03-10 12:18:37 +00:00 by mik-tf · 0 comments

mik-tf commented

2026-03-10 12:18:37 +00:00

Owner

Standalone tracker for differentiating identity seed data (contacts, groups, locations) across the 4 OSIS contexts.

Related: Issue #7 — UI Component Library & Form Quality (completed, closed)

Task

The identity contacts in hero_osis/data/seed/{context}/identity/ are currently identical across all 4 contexts — same Alice, Bob, Carol, Elena, Marcus, Yuki, Kristof etc. in geomind, threefold, incubaid, and root.

What needs to change

Context	Theme	Example contacts
geomind	AI researchers, ML engineers, data scientists	sarah_ml, james_nlp
threefold	Grid operators, farmers, infrastructure engineers	alex_farmer, nina_devops
incubaid	Investors, portfolio founders, deal partners	marc_vc, lisa_founder
root	System admins, security team	kim_sysadmin, raj_security

Files to differentiate

contact_*.toml — must be unique per context (currently 11 identical files each)
group_*.toml — theme per context (e.g. geomind: "ML Team", threefold: "Grid Ops")
location_*.toml — different office locations per context
profile_*.toml / session_*.toml — may stay shared

Impact

Seed data change only — no code changes needed
Only hero_osis repo affected
Same pattern as the business seed data differentiation already done in Issue #7
Requires Docker rebuild (~5-10 min with cargo cache)

Branching Strategy

All work happens on development_mik3, branched from latest development.

Repo	Branch	Purpose
`hero_osis`	`development_mik3`	Seed data changes

Deployment

Tier	Image Tag	Gateway	Port	Status
dev	`:dev`	`herodev.gent02.grid.tf`	8805	Live
demo	`:demo`	`herodemo.gent02.grid.tf`	8806	Live
prod	`:prod`	TBD	TBD	Not deployed

Registry: forge.ourworld.tf/lhumina_code/hero_zero
VM: TFGrid Node 8, Mycelium 495:72fa:8ec3:9264:ff0f:c0a8:abad:234c
SSH: ssh -6 root@495:72fa:8ec3:9264:ff0f:c0a8:abad:234c

DevOps Workflow

Step	What	Who	Gate
1	Code — implement changes	Claude	—
2	Local Docker build	Claude	must compile
3	Deploy to herodev	Claude	—
4	Human test on herodev	Human	must confirm
5	Commit & push	Claude	only after step 4
6	Remote Docker build	Claude	must compile
7	Deploy to herodev (again)	Claude	—
8	Human test on herodev	Human	must confirm
9	Tag `:demo`	Claude	only after step 8
10	Human test on herodemo	Human	must confirm
11	Update this issue	Claude	—

Rules:

Never push before human confirms on herodev (step 4 → step 5)
Never tag :demo before human confirms remote build (step 8 → step 9)
Never rebase, always merge
herodev gets changes first, herodemo only after confirmation
No hot-swapping WASM — always do full Docker rebuild + deploy
All pushes go to development_mik3

Operational Lessons (from Issue #7)

These are hard-won lessons from the previous session — follow them to avoid wasting time:

Docker cache can go stale — sometimes --no-cache is needed when cargo dependencies change or layers are cached from a different branch. Don'''t assume cache is always safe.
Container name conflicts — always docker stop + rm the old container before docker run. We hit issues with leftover containers (e.g. heroos was already running and conflicting).
Registry workflow is the right path — build locally → docker push to registry → docker pull on VM → docker run. Don'''t build on the VM.
Never break herodemo — herodev is the playground. Only tag :demo and redeploy herodemo after human confirms herodev works. Non-negotiable.
Port mapping — container exposes 6666 internally, mapped to 8805 (herodev) and 8806 (herodemo). Don'''t mix these up.
Cargo cache layer — the Dockerfile has a cargo cache layer that speeds rebuilds from ~30min to ~5-10min, but only when dependencies haven'''t changed drastically.

Standalone tracker for differentiating identity seed data (contacts, groups, locations) across the 4 OSIS contexts. **Related:** Issue #7 — UI Component Library & Form Quality (completed, closed) ### Task The identity contacts in `hero_osis/data/seed/{context}/identity/` are currently **identical across all 4 contexts** — same Alice, Bob, Carol, Elena, Marcus, Yuki, Kristof etc. in geomind, threefold, incubaid, and root. #### What needs to change | Context | Theme | Example contacts | |---------|-------|-----------------| | **geomind** | AI researchers, ML engineers, data scientists | sarah_ml, james_nlp | | **threefold** | Grid operators, farmers, infrastructure engineers | alex_farmer, nina_devops | | **incubaid** | Investors, portfolio founders, deal partners | marc_vc, lisa_founder | | **root** | System admins, security team | kim_sysadmin, raj_security | #### Files to differentiate - **`contact_*.toml`** — must be unique per context (currently 11 identical files each) - **`group_*.toml`** — theme per context (e.g. geomind: "ML Team", threefold: "Grid Ops") - **`location_*.toml`** — different office locations per context - **`profile_*.toml` / `session_*.toml`** — may stay shared #### Impact - Seed data change only — no code changes needed - Only `hero_osis` repo affected - Same pattern as the business seed data differentiation already done in Issue #7 - Requires Docker rebuild (~5-10 min with cargo cache) ### Branching Strategy All work happens on `development_mik3`, branched from latest `development`. | Repo | Branch | Purpose | |------|--------|---------| | `hero_osis` | `development_mik3` | Seed data changes | ### Deployment | Tier | Image Tag | Gateway | Port | Status | |------|-----------|---------|------|--------| | **dev** | `:dev` | `herodev.gent02.grid.tf` | 8805 | Live | | **demo** | `:demo` | `herodemo.gent02.grid.tf` | 8806 | Live | | **prod** | `:prod` | TBD | TBD | Not deployed | **Registry:** `forge.ourworld.tf/lhumina_code/hero_zero` **VM:** TFGrid Node 8, Mycelium `495:72fa:8ec3:9264:ff0f:c0a8:abad:234c` **SSH:** `ssh -6 root@495:72fa:8ec3:9264:ff0f:c0a8:abad:234c` ### DevOps Workflow | Step | What | Who | Gate | |------|------|-----|------| | 1 | **Code** — implement changes | Claude | — | | 2 | **Local Docker build** | Claude | must compile | | 3 | **Deploy to herodev** | Claude | — | | 4 | **Human test on herodev** | Human | must confirm | | 5 | **Commit & push** | Claude | only after step 4 | | 6 | **Remote Docker build** | Claude | must compile | | 7 | **Deploy to herodev (again)** | Claude | — | | 8 | **Human test on herodev** | Human | must confirm | | 9 | **Tag `:demo`** | Claude | only after step 8 | | 10 | **Human test on herodemo** | Human | must confirm | | 11 | **Update this issue** | Claude | — | **Rules:** - Never push before human confirms on herodev (step 4 → step 5) - Never tag `:demo` before human confirms remote build (step 8 → step 9) - Never rebase, always merge - herodev gets changes first, herodemo only after confirmation - No hot-swapping WASM — always do full Docker rebuild + deploy - All pushes go to `development_mik3` ### Operational Lessons (from Issue #7) These are hard-won lessons from the previous session — follow them to avoid wasting time: 1. **Docker cache can go stale** — sometimes `--no-cache` is needed when cargo dependencies change or layers are cached from a different branch. Don'''t assume cache is always safe. 2. **Container name conflicts** — always `docker stop + rm` the old container before `docker run`. We hit issues with leftover containers (e.g. `heroos` was already running and conflicting). 3. **Registry workflow is the right path** — build locally → `docker push` to registry → `docker pull` on VM → `docker run`. Don'''t build on the VM. 4. **Never break herodemo** — herodev is the playground. Only tag `:demo` and redeploy herodemo after human confirms herodev works. Non-negotiable. 5. **Port mapping** — container exposes 6666 internally, mapped to 8805 (herodev) and 8806 (herodemo). Don'''t mix these up. 6. **Cargo cache layer** — the Dockerfile has a cargo cache layer that speeds rebuilds from ~30min to ~5-10min, but only when dependencies haven'''t changed drastically.