Adolfo Reyna
0f84463a9f
- Inbox -> archives/inbox_processed: ari_followup (Sardius), remarkable_inbox, tic_tac_toe_state - Inbox images -> resources/kids-os (KidsOS UI 2026-07-28) - Archives/travel/2026: Aeromexico HCYDNU confirmation + Hertz BOS L670EDC05D8 - Exports/calendars: all_flights, chiapas TGZ, maine BOS ICS - Areas: chiapas_trip_2026-09 (HCYDNU booked), trump_accounts_and_emi_board_2026 (Trump accounts + EMI FL board), operations audits (hermes migration + Apple Mail local research) - Projects new (enriched stubs from MEMORY.md): xiao_epaper 400x300 (5-pass grayscale), mac_privacy_migrations (Xcode signing), remarkable_pro workflow (132 + watchdog + art), tactility_humation_avatars (320x240 pre-render), voice_dev_infra (network map .102/.110/.150) - Paper-apps: restored detailed README (181 lines porting guide) + enriched paper_apps_golf_galaxy_zero project with full mechanics cross-ref - Maine wedding: Hertz rental 63 L670EDC05D8 + tolls (PlatePass vs SunPass PRO) — intentional addition kept - 220 Emerald: removed duplicate consolidated junk appended at end (142 lines clean) - Removed runtime logs: chrome.err (288 lines), chrome.log tracked -> now ignored per .gitignore - Clean empty inbox
143 lines
7.3 KiB
Markdown
143 lines
7.3 KiB
Markdown
---
|
|
title: Hermes migration audit — Mac mini
|
|
status: in_progress
|
|
date: 2026-08-02
|
|
source: Live audit on Mac-mini-M4.local
|
|
---
|
|
|
|
# Hermes migration audit — Mac mini
|
|
|
|
## Verified working
|
|
|
|
- Hermes Agent `v0.19.1` is installed at `/Users/adolforeyna/.hermes/hermes-agent`.
|
|
- Primary state database passed `PRAGMA quick_check` and contains 1,456 sessions.
|
|
- Brain access is available at `/Users/adolforeyna/brain` with read/write/traverse access.
|
|
- Migrated Hermes assets exist:
|
|
- 32 skills
|
|
- 33 scripts
|
|
- 4 memory files
|
|
- profiles: `emi`, `kids`, `voice`
|
|
- All 10 scheduled cron jobs are present and their referenced local scripts exist.
|
|
- A persistent macOS launchd gateway was installed at:
|
|
`/Users/adolforeyna/Library/LaunchAgents/ai.hermes.gateway.plist`
|
|
- Gateway cron ticker was verified healthy after installation; scheduled jobs will fire automatically.
|
|
- MCP `macmini` connected successfully in 40 ms and exposed 48 tools.
|
|
|
|
## Restored during audit
|
|
|
|
- WhatsApp credentials were absent locally but present on the old Pi (`pi5`, hostname `aeropi5`).
|
|
- Restored the credential into the canonical Mac path:
|
|
`/Users/adolforeyna/.hermes/platforms/whatsapp/session/creds.json`
|
|
- Set credential permissions to `0600`.
|
|
- After the restore, the Mac gateway connected to WhatsApp.
|
|
|
|
## Outstanding migration work
|
|
|
|
### 1. WhatsApp handoff
|
|
|
|
The Mac gateway can connect to WhatsApp, but outgoing messages failed with `Not connected to WhatsApp`.
|
|
|
|
Likely contributing factors:
|
|
- The old Pi gateway may still be operating the same WhatsApp linked-device session.
|
|
- The old Pi is still reachable as SSH alias `pi5` / hostname `aeropi5`.
|
|
|
|
An attempt to stop the old Pi gateway was denied by the user approval system, so no workaround or retry was performed.
|
|
|
|
### 2. Local session-lock ownership
|
|
|
|
`/Users/adolforeyna/.local/state` is owned by `root`. Hermes consequently cannot create:
|
|
`/Users/adolforeyna/.local/state/hermes`
|
|
|
|
Gateway log warning:
|
|
`Could not acquire session lock (non-fatal): [Errno 13] Permission denied`
|
|
|
|
This should be repaired before relying on the WhatsApp bridge long-term.
|
|
|
|
### 3. OpenSCAD iMac MCP
|
|
|
|
The configured `openscad_imac` MCP fails initial connection because SSH host-key verification fails. The `macmini` MCP is healthy.
|
|
|
|
### 4. ESP32 voice routes
|
|
|
|
The `esp32-voice-gateway` plugin detected that its routes are missing after the Hermes update. Its saved patch no longer applies cleanly to the current `gateway/platforms/api_server.py`.
|
|
|
|
The ESP32 voice API must be updated to the current Hermes source and verified before use.
|
|
|
|
### 5. Gateway model credentials
|
|
|
|
Gateway logs show the configured custom Meta model `muse-spark-1.1` receives HTTP `401 Unauthorized`. The model credential must be refreshed or the gateway model/provider changed, then tested with an inbound message.
|
|
|
|
## Optional capability gaps (not migration failures)
|
|
|
|
- Nous Portal authentication is not configured.
|
|
- Web-search provider keys are not configured.
|
|
- Docker is not installed.
|
|
|
|
These do not block the core agent, brain, cron, or healthy Mac mini MCP.
|
|
|
|
## Migration sequence
|
|
|
|
1. Resolve Pi → Mac WhatsApp ownership and verify a real outbound reply.
|
|
2. Repair the Mac local Hermes-state directory ownership and confirm lock acquisition.
|
|
3. Repair and test the OpenSCAD iMac MCP SSH trust relationship.
|
|
4. Restore and test ESP32 voice gateway routes.
|
|
5. Repair/test gateway model credentials.
|
|
6. Complete end-to-end checks: WhatsApp inbound/outbound, cron heartbeat, MCPs, voice endpoints, and model calls.
|
|
|
|
## Progress update — WhatsApp routing and full session-state recovery
|
|
|
|
### Channel routing correction
|
|
|
|
The first post-migration WhatsApp responses were incorrectly sent into the group named `EMI Assistant` (`120363409068274776@g.us`). This group is reserved for EMI conversations and is not the family/home channel.
|
|
|
|
Live bridge inspection identified these WhatsApp groups:
|
|
|
|
- `EMI Assistant` — separate EMI group
|
|
- `FamReynaBot` — family group, with the bot plus Adolfo and his wife
|
|
- `ReynaO` — separate group
|
|
|
|
The default/home route was corrected so scheduled/default WhatsApp delivery uses the original Pi WhatsApp home-channel configuration rather than EMI.
|
|
|
|
### User registration and policy
|
|
|
|
- Family group policy remains `allowlist` with no mention requirement.
|
|
- The original Pi WhatsApp allowlist was restored rather than using temporary Mac-only configuration overrides.
|
|
- The original bot mode, user allowlist, home channel, owner-message forwarding setting, and enabled setting were copied from the Pi runtime `.env` into the Mac `.env`.
|
|
- The Mac bridge now starts in `bot` mode. It had mistakenly started in `self-chat` mode before restoration; that mode ignores ordinary DM traffic and explained the DM non-responses.
|
|
|
|
### Full WhatsApp session recovery
|
|
|
|
Initial recovery copied only `creds.json`. That was insufficient for inbound-message handling: the Pi WhatsApp session directory contains encrypted multi-file authentication/session state.
|
|
|
|
On 2026-08-02:
|
|
|
|
1. Verified the Pi session had 1,592 files: `creds.json` plus 1,591 key/state files.
|
|
2. Stopped the Mac gateway briefly.
|
|
3. Copied the entire Pi session directory to:
|
|
`/Users/adolforeyna/.hermes/platforms/whatsapp/session/`
|
|
4. Applied restrictive permissions (`0700` directories, `0600` files).
|
|
5. Restarted the Mac launchd gateway.
|
|
|
|
After restart:
|
|
|
|
- WhatsApp bridge reported `status=connected`.
|
|
- Cron gateway ticker was healthy.
|
|
- The gateway processed a recovered inbound WhatsApp event and generated a response.
|
|
|
|
### Current verification status
|
|
|
|
A fresh user-authored DM test after the full session-state restore is still required to prove live inbound DM processing end-to-end. An automated recovery-probe DM was attempted but denied by the user approval system, so it was not retried.
|
|
|
|
## Progress update — browser automation restored on Mac mini
|
|
|
|
The iMac is kids-only and must not host Hermes browser automation or private browser state. On 2026-08-03, a dedicated visible Chrome automation profile was created on the Mac mini at:
|
|
`~/Library/Application Support/Google/Chrome-Hermes/`
|
|
|
|
- The source Chrome profile was copied once with caches and lock files excluded, preserving the available same-Mac browser session material without operating on the iMac.
|
|
- Chrome is running as a separate visible instance with CDP bound only to `127.0.0.1:9222`, using the `ReynaFamilyBot` Chrome profile (`reynafamilybot@gmail.com`) by default. Live Gemini verification confirmed that bot account is signed in.
|
|
- `agent-browser` is connected to that instance under session `hermes-visible`; its dashboard is healthy on `127.0.0.1:4848`.
|
|
- A LAN observer proxy is verified on `192.168.68.112:4849`. The dashboard hard-coded `ws://localhost:<port>`, so laptop viewers saw `Disconnected`; the proxy now rewrites that endpoint to a narrow LAN stream bridge (`:4851`) and normalizes its WebSocket Origin before forwarding to the localhost-only stream (`:4850`). A LAN URL load verified `Online` rather than `Disconnected`.
|
|
- Local helpers: `~/bin/hermes-browser` (`start`/`status`) and `~/bin/hermes-browser-dashboard-proxy.py`.
|
|
|
|
The durable launchd plist was written at `~/Library/LaunchAgents/com.reyna.hermes-browser-dashboard-proxy.plist`, but its registration was blocked by Hermes' gateway safety guard. It requires a one-time explicit `launchctl bootstrap` from a separate Mac mini Terminal session before relying on the LAN observer proxy across restarts.
|