From 4f418179d1589d1cb7af085e30540f0c3f7fd371 Mon Sep 17 00:00:00 2001 From: aeroreyna Date: Wed, 17 Jun 2026 23:00:01 -0400 Subject: [PATCH] daily auto-sync 2026-06-17 --- areas/maintenance/220_emerald.md | 7 +- areas/maintenance/household_admin_tasks.md | 4 +- index.md | 2 + journals/2026-06-17.md | 14 +++ projects/para_brain_mcp_server.md | 111 ++++++++++++++++++ .../remarkable_hermes_communication_app.md | 87 ++++++++++++++ 6 files changed, 221 insertions(+), 4 deletions(-) create mode 100644 journals/2026-06-17.md create mode 100644 projects/para_brain_mcp_server.md create mode 100644 projects/remarkable_hermes_communication_app.md diff --git a/areas/maintenance/220_emerald.md b/areas/maintenance/220_emerald.md index cccd171..6a76d3d 100644 --- a/areas/maintenance/220_emerald.md +++ b/areas/maintenance/220_emerald.md @@ -11,12 +11,13 @@ This document tracks maintenance and supplies for the home at 220 Emerald. - **Peroxide & Salt Pellets** - **Last Service:** 2026-06-05 (Added 10 bottles peroxide and 2 bags salt pellets) - **Check Cycle:** Monthly (Avg. refill every 1.5 months) - - **Next Check Due:** 2026-07-05 - - **Current Status:** Replenished on 2026-06-05 - - **Next Action:** Check peroxide and salt pellet levels around 2026-07-05 + - **Next Check Due:** 2026-07-25 + - **Current Status:** Replenished on 2026-06-05; family later noted April 25 as the relevant date for the 90-day follow-up cadence. + - **Next Action:** Check peroxide and salt pellet levels around 2026-07-25 - **Service History:** - 2026-06-05: Added 10 bottles peroxide and 2 bags salt pellets. - 2026-04-26: Added 2 bags salt pellets; peroxide purchase pending. + - 2026-04-25: Family noted this as the relevant date for the 90-day/3-month follow-up reminder. ## 🚰 Drinking Water Filter - **Last Service:** (Pending) diff --git a/areas/maintenance/household_admin_tasks.md b/areas/maintenance/household_admin_tasks.md index b1bd423..8ecf377 100644 --- a/areas/maintenance/household_admin_tasks.md +++ b/areas/maintenance/household_admin_tasks.md @@ -18,7 +18,9 @@ Tags: [areas, maintenance, household, admin, tasks] - [x] Verify and pay AccoladeCare overdue balance ($6.85) if valid. (Captured 2026-05-26 photo scan; paid 2026-05-29) - [x] Attend financial advisor appointment with James Phillips (Tue, Jun 16, 2026, 11:00 AM–1:00 PM ET, RingCentral Meeting ID: 321722788). Went well; follow-up in-person session scheduled. (Captured 2026-05-27, completed/updated 2026-06-16, A Reyna) - [ ] Attend in-person financial planning session with James Phillips on Saturday, July 11, 2026, 11:00 AM–2:00 PM ET (3 hours). Location/details TBD. (Captured 2026-06-16, A Reyna) -- [ ] Fridge warranty/service appointment booked for Wednesday, June 17, 2026, 8:00 AM–4:00 PM. Whirlpool appliance, model WRS325SDHZ13, serial HRE3403608, service job SWPV64ED5019-1. Provider: Wsvc Brandt's Appliance Serv, 4415 77th St, Vero Beach, FL, +1 (772) 562-5759. Email confirmation expected. (Captured 2026-06-15, A Reyna) +- [x] Fridge warranty/service appointment completed Wednesday, June 17, 2026. Whirlpool appliance, model WRS325SDHZ13, serial HRE3403608, service job SWPV64ED5019-1. Provider: Wsvc Brandt's Appliance Serv, 4415 77th St, Vero Beach, FL, +1 (772) 562-5759. Visit covered by warranty. (Captured 2026-06-15; updated 2026-06-17, A Reyna) +- [ ] Follow up on fridge warranty repair part/order from Wsvc Brandt's Appliance Serv. Technician said a part needs to be ordered and added to the warranty coverage/process. (Captured 2026-06-17, A Reyna) +- [ ] Attend confirmed ENT appointment on Thursday, June 18, 2026. Adolfo confirmed the appointment. (Captured 2026-06-17, A Reyna) - [ ] Verify Neptune flood insurance autopay processed for $870.23 and coverage renewed for 220 Emerald after July 22, 2026. Renewal policy TNF4366115; expiring policy TNF4093986; premium notice invoice 1821199; coverage through August 21, 2027. See [[220_emerald_flood_insurance]]. (Captured 2026-06-15, A Reyna) - [x] Automate weekday 8:30 PM reminder: read a book, relax, sleep. (Captured 2026-05-27, A Reyna; Hermes cron created 2026-05-29) diff --git a/index.md b/index.md index 5277ce5..bb1c4ba 100644 --- a/index.md +++ b/index.md @@ -1,6 +1,8 @@ # Brain Index (Map of Content) - **[[Projects]]:** Active things we are working on. + - [[reMarkable Hermes Communication App]]: Tablet/Hermes communication app over reMarkable Paper Pro. + - [[PARA Brain MCP Server]]: Server-side MCP/search layer for the Reyna family brain. - **[[Areas]]:** Ongoing responsibilities and household maintenance. - [[Marriage Course Index]]: Weekly sessions with Cuba. - **[[Resources]]:** Interests, reference material, and research. diff --git a/journals/2026-06-17.md b/journals/2026-06-17.md new file mode 100644 index 0000000..6a930e1 --- /dev/null +++ b/journals/2026-06-17.md @@ -0,0 +1,14 @@ +--- +Date: 2026-06-17 +Author: Adolfo Reyna via Hermes +Tags: [journal, household, maintenance, appointments] +--- + +# 2026-06-17 + +## Household / Appointment Updates +- Confirmed the ENT appointment for tomorrow (2026-06-18). +- Fridge appliance service came today. They need to order a part. Today’s visit is covered by the warranty. The technician/company is expected to add the part/order note to the warranty coverage/process. + +## Links +- [[household_admin_tasks]] diff --git a/projects/para_brain_mcp_server.md b/projects/para_brain_mcp_server.md new file mode 100644 index 0000000..e85c62b --- /dev/null +++ b/projects/para_brain_mcp_server.md @@ -0,0 +1,111 @@ +--- +Date: 2026-06-17 +Author: Hermes +Tags: [project, second-brain, para, mcp, obsidian, gitea, server] +--- + +# PARA Brain MCP Server + +## Purpose +Explore running a lightweight, open-source MCP/server layer over the Reyna family brain so Hermes and other AI tools can safely read, search, and update the existing PARA markdown vault from multiple computers. + +The current brain source of truth is the local markdown vault at `~/brain`, backed by the Gitea remote `https://git.reynafamily.com/adolforeyna/FamReynaBrain.git`. + +## Current Sync Direction +Recommended direction: +- Use Git/Gitea as the canonical sync layer for the brain. +- Clone `~/brain` on each computer from Gitea. +- Use Nextcloud only as optional read-only export/backup, not as the main bidirectional live vault sync. + +Reason: combining live Git edits and bidirectional Nextcloud sync can create conflicts, especially with Obsidian/mobile edits. + +## Candidate: MCPVault +Repository: https://github.com/bitbonsai/mcpvault + +MCPVault looks like the lightest first test. + +Why it fits: +- Node-based MCP server. +- Runs directly with `npx`. +- No Obsidian desktop app required. +- No Obsidian plugin required. +- No database required. +- No vector index required. +- No Docker required. +- Works directly against a local folder/vault. +- Focuses on safe Obsidian-style markdown access and avoiding YAML frontmatter corruption. + +Known dependencies from package metadata: +- `@modelcontextprotocol/sdk` +- `gray-matter` +- `trash` +- `yaml` + +Requirement note: +- README mentions Node 18+, but package metadata says Node `>=20.0.0`; treat Node 20+ as required. + +Example direct run: +```bash +npx @bitbonsai/mcpvault@latest /home/adolforeyna/brain +``` + +Possible Hermes MCP config: +```yaml +mcp_servers: + brain: + command: "npx" + args: + - "-y" + - "@bitbonsai/mcpvault@latest" + - "/home/adolforeyna/brain" +``` + +## Other Open-Source Options +- Obsidian Local REST API with MCP: https://github.com/coddingtonbear/obsidian-local-rest-api + - Mature REST/MCP interface, but requires Obsidian running with plugin enabled. +- obsidian-mcp-server: https://github.com/cyanheads/obsidian-mcp-server + - Featureful Obsidian vault MCP server; may depend on the Local REST API plugin depending on mode. +- engraph: https://github.com/devwhodevs/engraph + - Local knowledge API over markdown/Obsidian vaults with MCP, REST, hybrid semantic/full-text/graph search, temporal scoring. +- NeuroStack: https://github.com/raphasouthall/neurostack + - Reads existing markdown, builds searchable knowledge graph, MCP tools, read-only indexing by default with optional writes. +- brain.md: https://github.com/mi4uu/brain.md + - Local-first second brain app with Obsidian-compatible markdown, semantic search, and streamable HTTP MCP server. +- Open Second Brain: https://github.com/itechmeat/open-second-brain + - Obsidian-native agent memory layer, explicitly mentions Hermes Agent; likely more memory-layer focused than general PARA vault management. +- Zettelkasten MCP: https://github.com/entanglr/zettelkasten-mcp + - Useful for atomic note/graph workflows, less directly aligned with the current PARA vault. + +## Proposed Architecture +Phase 1: Safe shared brain +- Keep `~/brain` as plain markdown. +- Use Gitea for sync between computers. +- Run MCPVault against `/home/adolforeyna/brain` on the server. +- Enforce brain rules: + - preserve YAML frontmatter + - use PARA folders + - append unless explicit rewrite + - journals go to `journals/YYYY-MM-DD.md` + - never write to Nextcloud + +Phase 2: Smarter search +- Add engraph or NeuroStack for semantic/graph search. +- Keep the markdown files and Gitea repo as the source of truth. +- Treat indexes/databases as rebuildable cache, not canonical storage. + +Phase 3: Web/API access +- Optionally run a web UI or HTTP MCP endpoint for other computers/tools. +- Connect Hermes, Gemini CLI, Claude Code, Cursor, and other tools to the same server-side brain interface. + +## Open Questions +- Should MCPVault be run as a long-lived service, or launched on demand by Hermes via stdio MCP? +- Should write access be allowed immediately, or should the first test be read-only/search-only? +- How should Git commits/pushes be automated after MCP writes? +- Should the server auto-pull from Gitea only when the working tree is clean? +- Do we want semantic search now, or keep the first implementation intentionally simple? + +## Next Steps +- Confirm Node 20+ on the server. +- Test MCPVault with `/home/adolforeyna/brain` using the MCP inspector or Hermes MCP config. +- Verify it can list/search/read notes without corrupting frontmatter. +- Decide whether to enable write tools and how to pair them with Git commit/push automation. diff --git a/projects/remarkable_hermes_communication_app.md b/projects/remarkable_hermes_communication_app.md new file mode 100644 index 0000000..4fb47c3 --- /dev/null +++ b/projects/remarkable_hermes_communication_app.md @@ -0,0 +1,87 @@ +--- +Date: 2026-06-17 +Author: Hermes +Tags: [project, remarkable, hermes, ssh, xochitl, app-development] +--- + +# reMarkable Hermes Communication App + +## Purpose +Develop an app/workflow that lets Hermes communicate with Adolfo through the reMarkable Paper Pro: Adolfo writes on the tablet, Hermes reads/transcribes the response, then Hermes adds typed/color-coded responses back into the document or a dedicated app surface. + +## Current Status +Initial SSH-based proof of concept works. + +Hermes can: +- Connect to the reMarkable via SSH alias `remarkable`. +- Locate xochitl documents under `/home/root/.local/share/remarkable/xochitl/`. +- Find the document named `Hermes` via `.metadata` `visibleName`. +- Download the document files locally. +- Read handwritten replies from the generated page thumbnail/image. +- Generate a PDF-backed update containing: + - Adolfo's handwritten response transcribed into typed text. + - Hermes' response in a different font/color. +- Upload the updated document back to the tablet. + +## Important Findings +- reMarkable documents are stored as UUID-based companion files in xochitl: + - `{UUID}.metadata` + - `{UUID}.content` + - `{UUID}.pagedata` + - optional `{UUID}.pdf` / `{UUID}.epub` + - `{UUID}/` directory containing page `.rm` stroke/scene files + - optional `{UUID}.thumbnails/` +- The official xochitl docs say xochitl should not be running when accessing or changing stored documents. +- Replacing a PDF while xochitl is running can update files on disk but not reliably refresh the tablet UI. +- Restarting only `rm-sync` can detect changed files and rebuild `.tree`, but did not force the visible document to refresh. +- Closing/reopening the document can help, but cached annotation/stroke layers may still appear. +- Handwriting remains visible if the page `.rm` overlay files are left in the document UUID directory. +- A reliable PDF-replacement flow was: + 1. Stop xochitl briefly. + 2. Stop rm-sync if needed. + 3. Back up the `{UUID}*` document set. + 4. Remove stale `{UUID}/` page `.rm` overlay files and old thumbnails. + 5. Upload updated `.pdf`, `.content`, `.metadata`, `.pagedata`, and thumbnail. + 6. Start xochitl again. + 7. Verify xochitl and rm-sync are active. +- This works, but stopping xochitl is disruptive. It should not be the final UX. + +## Tested Document +- Visible name: `Hermes` +- UUID: `b109ab4c-f21d-4c0e-9df7-248b20dfb9b0` +- Backups made on tablet during testing: + - `/home/root/hermes-backups/20260617-122145` + - `/home/root/hermes-backups/20260617-122818` + - `/home/root/hermes-backups/20260617-123411` + +## References +- xochitl documentation: https://developer.remarkable.com/documentation/xochitl +- Qt/e-paper application documentation: https://developer.remarkable.com/documentation/qt_epaper +- Official Qt Quick examples: https://github.com/reMarkable/remarkable-developer-examples +- Awesome reMarkable project index: https://github.com/reHackable/awesome-reMarkable +- Toltec community package repository: https://github.com/toltec-dev/toltec +- rmkit application framework: https://github.com/rmkit-dev/rmkit +- Oxide launcher/desktop environment: https://github.com/Eeems-Org/oxide +- libremarkable Rust low-level device framework: https://github.com/canselcik/libremarkable + +## Design Direction +The better long-term approach is likely a dedicated reMarkable app or Qt Quick/e-paper application rather than repeatedly replacing xochitl PDF files. + +Possible directions: +- Build a Qt/e-paper app that shows a Hermes conversation surface directly on the tablet. +- Use SSH or a local bridge process to exchange messages between the tablet and Hermes. +- Keep xochitl as the handwritten input surface only if we can safely read `.rm`/scene data and write generated `.rm`/scene content without restarting xochitl. +- Prefer a non-disruptive workflow where xochitl stays running and the tablet UI refreshes naturally. + +## Open Questions +- Can we generate valid `.rm`/scene stroke data for typed or rendered Hermes replies so xochitl treats it like normal ink? +- Can a custom Qt/e-paper app coexist cleanly with xochitl on Paper Pro? +- What is the best transport: SSH polling, local service, webhook, file drop, or a small tablet-side daemon? +- Can handwriting recognition be done directly from `.rm` files instead of relying on thumbnails/screenshots? +- How should message history be persisted: in xochitl, a tablet app store, or the family brain? + +## Next Steps +- Study the Qt/e-paper docs and sample app path. +- Determine how to build/deploy a minimal Paper Pro Qt app. +- Prototype a simple tablet-side Hermes chat screen. +- Investigate `.rm`/scene format generation only if xochitl integration remains preferable.