sherpa-memory-sync

README

No README.

STATUS

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

# STATUS — sherpa-memory-sync

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

---

## Current state

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 review before merge.

**Phase 3 is feature-complete after this merges.** Six branches shipped: about-ken composition + CLI, sync-log retention, status staleness, status stub detection, diary tag filtering, and the merged predecessors. Only operational work remains (`install-schedule` for the daily Task Scheduler entry; ongoing manual fill-in of stub STATUS files).

STATUS stub detection merged to `main` at `d7f9ba6` — 3 commits, 12 new tests. `_index.md` shows `⚠ stub` for apps whose Current state is still a placeholder. Stub takes priority over staleness; summary footer has three mutually exclusive buckets `N fresh, N stub, N stale (STATUS)`.

STATUS staleness detection merged to `main` at `ad55430` — 5 commits, 25 new tests. `_index.md` shows `⚠ stale Nd` for apps whose `last_updated` is more than 30 days old.

Sync-log retention merged to `main` at `0066565` — 8 commits, 28 new tests. Both `run` and `about-ken` append to `_sync-log.md` and rotate it on every invocation.

Phase 3 `about_ken.py` is on `main` at `b724e52` — 22 commits, 453 tests at merge. CLI subcommand `sherpa-memory-sync about-ken` regenerates `G:\My Drive\k

…(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 for this app.