← All apps
🔁

sherpa-memory-sync

Mirror memory-style files from local projects to a Google Drive hub for Claude cross-session context.

README

No README.

STATUS

---
type: project-status
project: sherpa-memory-sync
last_updated: 2026-06-11
---

# STATUS — sherpa-memory-sync

*The freshest file. Answers "where am I on this project?" Updated at the end of every substantive session.*

---

## Current state

**ABOUT-KEN.md staleness fixed (2026-06-11, from the second computer).** The
nightly `SherpaMemorySync` task was running fine (daily 05:30 sync-log entries)
but only ever ran `run` — `about-ken` was never scheduled, so the brief sat
frozen at its 4/28 manual run. Fixed in `af9081b` (pushed): `ScheduledTaskSpec`
gained `extra_actions`, and `install-schedule` now registers `about-ken` as a
second Task Scheduler action after `run`. 550 tests passing (4 new).
ABOUT-KEN.md was regenerated manually same day (985 words) and the stray
`meta\Copy of ABOUT-KEN.md` (stale 4/28 duplicate) deleted from the hub.

- [ ] **Ken / next main-machine session: re-register the task** so the fix takes
      effect — `poetry run sherpa-memory-sync install-schedule` in
      `D:\dev\sherpa-memory-sync`. Until then ABOUT-KEN.md only updates manually.
- [ ] Pre-existing test failure (unrelated): `test_index.py::TestGenerateIndex::
      test_shows_check_for_present_cross_for_missing` — fixture hardcodes a
      `last_updated` date that has drifted >30 days stale. Fixture needs
      `date.today()` or a frozen clock.

---

Previous state (2026-04-27):

Diary tag filtering shipped on `phase-3/diary-tag-filtering` — **547 tests passing**. Diary entries older than 90 days are skipped during sync unless their frontmatter `tags` field includes one of the configured `always_include_tags` (default `["project-memory"]`). Non-dated diary files (e.g., README.md) always pass through. Filtered files are recorded in `SyncReport.filtered` and surfaced in `_sync-log.md` under a `Filtered (N):` block alongside the existing Denied/Too-large/Binary sections. Smoke-tested against the real hub: 0 filtered (all current diary entries within 90 days). Branch awaiting Ken's r

…(truncated for upload size)

DECISIONS

---
type: project-decisions
project: sherpa-memory-sync
last_updated: 2026-04-27
---

# DECISIONS — sherpa-memory-sync

*Architectural and scope choices. Append-only log. Each entry is a decision that shouldn't be re-litigated without new information.*

---

## How to use this file

Each decision gets a dated entry with: what was decided, why, what was considered instead, and what would change our mind. Never delete entries — if a decision is reversed, add a new one that supersedes it. Newest at the top.

---

## 2026-04-28 — Diary tag filtering: date-then-tag rule, non-dated-files-always-included, double-read accepted

**Decision:** During `_sync_diary_source`, each `.md` file is run through a filter before reaching `sync_file`. The filter applies in this order: (1) if the filename has no parseable `YYYY-MM-DD` prefix, the file is included unconditionally; (2) if the parsed date is within `today - retention_days` (default 90), the entry is included; (3) if older, the file's frontmatter `tags` are checked against `diary.always_include_tags` (default `["project-memory"]`) — any case-insensitive match keeps the entry; (4) otherwise the entry is excluded and recorded in `SyncReport.filtered` with a human-readable reason. The `Filtered (N):` block renders in `_sync-log.md` alongside the existing `Denied`/`Too large`/`Binary` sections.

**Context:** DESIGN.md's diary retention rule — "Last 90 days of diary entries, plus any entry with `project-memory` in its frontmatter `tags`" — was the last unimplemented feature in Phase 1's spec. The config fields (`diary_retention_days`, `diary_always_include_tags`) had been parsed since Phase 1 but unused.

**Why non-dated files (README.md) always pass:** README.md and any other non-entry files in the diary directory aren't entries — they're metadata about the diary itself. Filtering them by retention rules would silently drop them from the hub mirror. Best to treat them as "outside the retention rule" rather than create a special-c

…(truncated for upload size)

MEMORY

---
type: project-memory
project: sherpa-memory-sync
last_updated: 2026-04-24
---

# MEMORY — sherpa-memory-sync

*Standing facts, preferences, and accumulated context. Long-lived — not "what I did yesterday" (that's STATUS.md). Update when you learn something worth keeping.*

---

## Purpose and scope

Mirrors memory-style files (CLAUDE.md, MEMORY.md, STATUS.md, DECISIONS.md, README.md, diary) from Ken's local projects to `G:\My Drive\kens-personal-life\`, generates an index showing gaps, and produces a compact identity brief (ABOUT-KEN.md) Ken can paste into any new Claude session. Solves the "Claude doesn't know my name after 5 months of daily use" problem.

## Domain knowledge

- **Ken's bucket taxonomy on D: drive** — `dev\` (sherpa-family work apps), `Personal\` (Ken's non-work utilities), `Games\`, `tools\` (third-party binaries and reference data), `Archive\` (retired projects). Sync reads from dev, Personal, Games — skips tools and Archive.
- **Four-file schema** — every project in dev/Personal should have CLAUDE, MEMORY, STATUS, DECISIONS at the root. This schema is what the sync assumes when scanning.
- **Source-of-truth rule** — local project folders are authoritative. Hub is read-only mirror. Editing memory happens in source projects only.
- **Dropbox vault** — Ken's Obsidian vault lives at `C:\Users\Ken2\Tax Shelter Dropbox\Ken Lill\KenVault\`. Diary is under `Claude Diary\`. Dropbox client must be running for fresh reads.
- **Three cloud services** — Dropbox (diary input), Google Drive (hub output), GitHub (code backup). If any is offline, parts of the system degrade.
- **Ken is a CPA** — confidentiality is professional, not just personal. Leaking client data or credentials has real consequences. Denylist is the most important code in this project.

## User preferences discovered

- **One-way sync only.** Never propose write-back or bidirectional sync.
- **Phase discipline.** Ken wants Phase 1 fully shipped before Phase 2 starts. No bundling.
- **Test

…(truncated for upload size)

CLAUDE.md

# CLAUDE.md — sherpa-memory-sync

*Last updated: 2026-04-24*

---

## What this is

Python utility that mirrors memory-style files from Ken's local projects to `G:\My Drive\kens-personal-life\`, generates an inventory index, and produces a compact identity brief (`ABOUT-KEN.md`) Ken can paste into new Claude sessions. Non-goals: not a backup system, not bidirectional, not a document store, not a CPA practice system.

See `DESIGN.md` for the full specification. **Read DESIGN.md before making any structural decisions.**

## Tech stack

- **Python 3.12+** (not 3.13 — this project must work on any sherpa-family machine)
- **Poetry** for dependency management
- **stdlib-first** — pathlib, shutil, re, json, datetime, hashlib, argparse
- **Limited external deps:** `tomli`, `python-frontmatter`, `rich` (optional)
- **No database.** State via mtime and the sync log.
- **No API calls in Phase 1.** Phase 3 may add Anthropic API for LLM-composed ABOUT-KEN.md.

## Session startup

- Read `DESIGN.md` first. It's the authoritative specification.
- Read `STATUS.md` to see where we stopped.
- Do not begin Phase 2 work while Phase 1 has open tests or known bugs.

## Conventions

- Follow sherpa-family conventions from `~/.claude/CLAUDE.md`.
- This project is the first exemplar of the four-file schema. It must practice what it preaches — all four of CLAUDE.md, MEMORY.md, STATUS.md, DECISIONS.md must exist at the project root and stay current.
- Commits in small, reviewable units. No 500-line PRs.
- Tests before features. Especially for the denylist — that's the one thing that cannot fail.

## Do not redesign without asking

- **Direction of sync is one-way** (local → Drive). Never add write-back. Ken edits memory in source projects, sync propagates to hub, full stop.
- **Credentials denylist is non-negotiable.** Both filename patterns and content scanning. Do not remove or weaken to reduce false positives — better to skip a legitimate file with a warning than leak one secret.
- **Hub 

…(truncated for upload size)

Diary mentions

No recent diary mentions.