- Python 100%
|
|
||
|---|---|---|
| .forgejo/ISSUE_TEMPLATE | ||
| docs | ||
| meetings | ||
| .gitignore | ||
| hero_ci_report.py | ||
| main_integration_ci.md | ||
| README.md | ||
| repos.md | ||
| repos_focus_migration.md | ||
| repos_focus_production.md | ||
| team.md | ||
Hero — Home
Central issue tracker and coordination hub for the Hero Platform across lhumina_code.
What Hero is
The Hero Platform is a sovereign, AI-native personal operating system: it runs in the browser, owns its data, and is operated by an always-on AI assistant. Its shape is simple:
- A Hero Platform is one admin instance plus one or many member instances, managed as a unit.
- A named instantiation of it for a real group (a company, a team, a class) is an organization (for example organization Acme, or our own testing organization). One organization is one Hero Platform.
- An admin instance is the control plane: it runs the deployer and the shared engines and provisions the member instances.
- A member instance is one person's machine, running their own Hero stack (their services and apps) behind their own login.
Two more terms for what runs on a member instance: the Hero stack is the full set of services that make it up, and Hero OS (hero_os) is one service in that stack, the shell (dock and islands) that presents the apps as one view. The full vocabulary, the component breakdown, and diagrams live in docs/hero_platform/README.md — read that first.
How it is built
A member instance runs a Hero stack: a suite of small Rust services, each supervised by hero_proc and reached through a single hero_router entry point.
- On every instance:
hero_proc(process supervisor and secret store) andhero_router(single entry point with discovery and per-context routing). - On the admin instance: the deployer (
hero_tfgrid_deployer, provisioning plus the operator console) and the shared engines (the stateless embedder and voice models served once for the whole organization). - On each member instance:
hero_proxy(the login gate),hero_cockpit(the member console),hero_os(the shell that shows your apps as one view), and the apps chosen for that member (the library, the CRM, the AI assistant, voice, files, memory, and more).
Engines live on the admin instance; each member's data stays on their member instance.
Issue conventions
Every issue is labelled platform (the integrated stack: deployer, onboarding, gateway, admin instance, build tooling) or service (work inside one app, for example hero_books or hero_voice). The title prefix names the area or service ([deployer], [hero_books], [lab]), and the assignee owns it. This repo is the big-picture board for platform and service work.
Branching
The default branch is development. Feature branches squash-merge into development (one branch, one squashed commit, with the commit message linking the issue). main is brought up to speed from development when we choose to; the sandbox proving channel for the service repos is integration.
Links
| Resource | URL |
|---|---|
| Issues | lhumina_code/home/issues |
| Platform vocabulary and architecture | docs/hero_platform/README.md |
| The deployer as a product | docs/hero_platform/composable-deployer.md |
| Organizations | home#285 |
| Project board | projects/13 |
Meetings
Recording a meeting? Pick a template — the report is AI-drafted and the issue is closed for you automatically, nothing else to do:
- Transcript — paste the raw text, AI writes the report → new meeting-transcript issue
- Notes — you already wrote the summary → new meeting-notes issue
- Sensitive transcript — count only, no AI/shared archive → new sensitive transcript issue
- Sensitive notes — count only, no AI/shared archive → new sensitive notes issue