daily auto-sync 2026-06-17
This commit is contained in:
@@ -11,12 +11,13 @@ This document tracks maintenance and supplies for the home at 220 Emerald.
|
|||||||
- **Peroxide & Salt Pellets**
|
- **Peroxide & Salt Pellets**
|
||||||
- **Last Service:** 2026-06-05 (Added 10 bottles peroxide and 2 bags 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)
|
- **Check Cycle:** Monthly (Avg. refill every 1.5 months)
|
||||||
- **Next Check Due:** 2026-07-05
|
- **Next Check Due:** 2026-07-25
|
||||||
- **Current Status:** Replenished on 2026-06-05
|
- **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-05
|
- **Next Action:** Check peroxide and salt pellet levels around 2026-07-25
|
||||||
- **Service History:**
|
- **Service History:**
|
||||||
- 2026-06-05: Added 10 bottles peroxide and 2 bags salt pellets.
|
- 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-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
|
## 🚰 Drinking Water Filter
|
||||||
- **Last Service:** (Pending)
|
- **Last Service:** (Pending)
|
||||||
|
|||||||
@@ -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] 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)
|
- [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)
|
- [ ] 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)
|
- [ ] 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)
|
- [x] Automate weekday 8:30 PM reminder: read a book, relax, sleep. (Captured 2026-05-27, A Reyna; Hermes cron created 2026-05-29)
|
||||||
|
|
||||||
|
|||||||
@@ -1,6 +1,8 @@
|
|||||||
# Brain Index (Map of Content)
|
# Brain Index (Map of Content)
|
||||||
|
|
||||||
- **[[Projects]]:** Active things we are working on.
|
- **[[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.
|
- **[[Areas]]:** Ongoing responsibilities and household maintenance.
|
||||||
- [[Marriage Course Index]]: Weekly sessions with Cuba.
|
- [[Marriage Course Index]]: Weekly sessions with Cuba.
|
||||||
- **[[Resources]]:** Interests, reference material, and research.
|
- **[[Resources]]:** Interests, reference material, and research.
|
||||||
|
|||||||
@@ -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]]
|
||||||
@@ -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.
|
||||||
@@ -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.
|
||||||
Reference in New Issue
Block a user