# 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.

```bash
# 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:

```bash
# 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:
1. Creates the sandbox container
2. Applies inference config from `.env`
3. Registers the identity template
4. 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](../../design/DESIGN_PLAN.md) — Hermes as NemoClaw-managed infrastructure
- [design/DESIGN_PLAN.md §2](../../design/DESIGN_PLAN.md) — Host automation (no custom control API)