Ty
0198ab6881
Attach/onboard sandbox from agents/hermes, additive OpenShell policy overlays, and nemohermes skill install for scaffold skills. No doctor/connect and no push.
Hermes agent package
Status: Config fragments and manifest ready for S4–S5.
Structure
| Path | Purpose |
|---|---|
config/inference.yaml |
Inference config fragment (main + aux vision models) |
config/mcp-servers.yaml |
MCP server config fragment (Square, QBO — enabled at S7) |
config/channels.yaml |
Messaging channel config fragment (WhatsApp, Telegram, Email — enabled at S7) |
skills-manifest/manifest.yaml |
Skills manifest listing all Lumina skills for sync |
identity/assistant.yaml |
Identity template (name, role, capabilities, constraints) |
Onboard modes
Attach (default for UAT)
When the sandbox already exists (e.g., hermes on this host), S4 skips
onboard and verifies the sandbox is healthy. Config fragments are used as
reference only — the live config is managed by nemohermes sealed commands.
# Attach mode: verify sandbox exists and is healthy
nemohermes <name> status
Onboard (clean host)
On a fresh host, use nemohermes onboard with this agent package:
# Onboard with agent package (dry-run first)
nemohermes onboard --from-dir agents/hermes --dry-run
# Onboard for real
nemohermes onboard --from-dir agents/hermes
The onboard process:
- Creates the sandbox container
- Applies inference config from
.env - Registers the identity template
- Skills are synced separately in S5
Platform-first
All config mutations use nemohermes sealed commands. Never hand-edit
in-sandbox config as SSOT. The fragments in this directory are the
product's source of truth for what gets configured.
Design reference
- design/DESIGN_PLAN.md §3 — Hermes as NemoClaw-managed infrastructure
- design/DESIGN_PLAN.md §2 — Host automation (no custom control API)