housekeeping 2026-08-05: organize PARA, clean inbox, archive travel, restore paper-apps
- 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
This commit is contained in:
Adolfo Reyna
@@ -0,0 +1,67 @@
|
||||
---
|
||||
title: Apple Mail local-store reader — research only
|
||||
date: 2026-08-03
|
||||
status: deferred
|
||||
scope: potential workflow improvement; no implementation authorized
|
||||
sources:
|
||||
- https://github.com/hexrw/mailgrep
|
||||
- https://github.com/imdinu/apple-mail-mcp
|
||||
- https://developer.apple.com/library/archive/documentation/AppleScript/Conceptual/AppleScriptLangGuide/reference/ASLR_cmds.html
|
||||
---
|
||||
|
||||
# Apple Mail local-store reader — research only
|
||||
|
||||
## Decision
|
||||
|
||||
Potential improvement to the MacMiniMCP/Hermes email workflow. **Do not implement, install, grant permissions, or alter the current Mail/MCP setup without renewed user approval.**
|
||||
|
||||
The desired end state includes all accounts configured in macOS Mail, including personal, EMI, and the assistant's own Mail account, subject to what is locally cached and the account protocol permits.
|
||||
|
||||
## Why it was explored
|
||||
|
||||
Apple Mail automation/JXA can enumerate accounts and work for a selected Exchange inbox item, but it performs poorly against the large combined inbox (about 25k messages observed), timing out during account-scoped traversal. It is not a dependable full-history search backend.
|
||||
|
||||
## Candidate approach: direct local Mail store, read-only
|
||||
|
||||
`mailgrep` is the preferred design reference:
|
||||
|
||||
- MIT-licensed, read-only by construction; no code path to send, move, delete, or flag messages.
|
||||
- Reads Apple Mail's local `Envelope Index` SQLite database for metadata and `.emlx` files for locally materialized bodies/attachments.
|
||||
- Uses a snapshot copy of the SQLite database plus `-wal` and `-shm` sidecars, then opens the copy read-only. Reading the primary database alone may omit recent data in WAL mode.
|
||||
- Performs metadata filtering in SQLite and parses local messages for bodies/attachments.
|
||||
- Has a `doctor`/coverage concept: explicitly report messages that are indexed without a body file, body files not indexed, unreadable items, and potential staleness instead of silently pretending coverage is complete.
|
||||
- Mail database schemas are undocumented and can vary by macOS release, so runtime schema discovery/validation is required. Message database row IDs are not durable identifiers; an RFC `Message-ID` is safer for persistent references.
|
||||
|
||||
The `apple-mail-mcp` project independently confirms the operational model: direct Envelope-Index reads and an FTS5 index avoid AppleScript timeouts on large mailboxes. It is GPL-3.0, so it is research-only/reference-only for our codebase; do not copy its implementation.
|
||||
|
||||
## Account/protocol implications
|
||||
|
||||
- **Personal Gmail / IMAP / iCloud / On My Mac:** likely good candidates for a local-store reader when Mail has downloaded the messages. Direct local reads can support fast read-only list/search/read flows.
|
||||
- **EMI Exchange / EWS:** local body coverage may be incomplete or absent because messages can remain server-resident and be fetched on demand. Direct local storage should not be treated as a complete EMI historical-email solution.
|
||||
- **Assistant Mail account:** include it in account discovery and the same read-only eligibility/coverage report. Do not special-case its credentials or access another credential store.
|
||||
- **Attachments:** local readers must distinguish inline, locally externalized, and never-downloaded attachments; never report an empty file as a successful extraction.
|
||||
|
||||
## Permission and safety model
|
||||
|
||||
macOS protects the Mail store with TCC. A future local reader needs Full Disk Access granted to the application/process that launches it (for example, the MacMiniMCP service context), not just its executable. This is a broad system privacy permission, so it must be explicitly approved first.
|
||||
|
||||
A read-only local-store implementation should deliberately avoid AppleScript synchronization. Synchronizing Mail via Apple Events would additionally require Automation access and creates a broader control surface than this workflow needs.
|
||||
|
||||
## Recommended future shape (only if approved)
|
||||
|
||||
1. Add a small read-only adapter to MacMiniMCP using the public MIT-compatible design principles above.
|
||||
2. First run a non-mutating `doctor`/coverage probe after explicit Full Disk Access approval.
|
||||
3. Expose account discovery, mailbox discovery, bounded metadata list/search, selected-message read, and attachment-state reporting.
|
||||
4. Retain Apple Mail automation only as an explicitly labeled fallback for Exchange/current-message access.
|
||||
5. Evaluate Microsoft Graph delegated OAuth separately if reliable full EMI/Exchange historical search becomes necessary.
|
||||
6. Test with synthetic Mail-store fixtures plus opt-in live read-only checks; do not persist Apple database row IDs across sessions.
|
||||
|
||||
## Original evidence / sources
|
||||
|
||||
- `mailgrep` README and source inspection: https://github.com/hexrw/mailgrep
|
||||
- `apple-mail-mcp` README and source inspection: https://github.com/imdinu/apple-mail-mcp
|
||||
- AppleScript reference (relevant only to the automation fallback): https://developer.apple.com/library/archive/documentation/AppleScript/Conceptual/AppleScriptLangGuide/reference/ASLR_cmds.html
|
||||
|
||||
## Local observation, 2026-08-03
|
||||
|
||||
An ordinary file scan did not reveal candidate Mail database/message files. This is not evidence that the store is absent: it is consistent with protected-directory visibility under macOS privacy controls. No Full Disk Access was requested or changed.
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user