David F GliddenandClaude Opus 4.7
119285cf43
The ~/.claude/ directory was previously local-only — a machine wipe
would have lost the accumulated memory, custom skills, and settings.
This commit moves the durable parts into dotfiles with the same
symlink-to-home pattern used for CLAUDE.md, PENDING.md, REVIEWED.md,
and L2-BOOTSTRAP.md.
Preserved (symlinked from ~/.claude/* into here):
skills/audit/ — thinking-folder drift scanner
skills/symmetria/ — practice-of-return discipline
skills/vault-update-people/ — Obsidian People-file maintainer
skills/wake-up/ — session restoration
skills/wrap-up/ — session state capture
memory/ — 55+ memory files (MEMORY.md, sessions,
ledgers, project state, feedback, etc.)
settings/settings.json — user preferences (hooks, flags, no secrets)
Deliberately NOT backed up:
settings.local.json — contains operational secrets (HF_TOKEN,
SSH password in expect scripts); by naming
convention, *.local.* is not synced.
Needs separate review and probable rotation.
sessions/, history.jsonl, caches, telemetry — ephemeral
plugins/, marketplace skills and agents — reinstallable
The working copies at ~/.claude/skills/* and
~/.claude/projects/-Users-davidglidden/memory are symlinks into this
directory, so every write flows here automatically. install.sh
recreates the symlinks on a fresh machine.
FOLLOW-ON (flagged, not in this commit):
settings.local.json contains a HuggingFace token and an SSH password
as plaintext strings inside allowed Bash command patterns. These
should be rotated and moved to secure storage (keychain / pass /
env file outside the settings file).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4.4 KiB
name, description, type
| name | description | type |
|---|---|---|
| Design Brief — Session Start/End Agents | Design problem for session lifecycle agents that replace manual memory maintenance with source-of-truth reconciliation | project |
Design Brief: Session Lifecycle Agents
Date: 2026-04-02 Status: Design problem — next session Why: Memory files went stale 3+ times in a single productive session. Manual sync is unsustainable and error-prone. The session handoff hook is static text that never updates itself.
Problem Statement
State about the collaboration lives in too many places, updated at different times, by different actors (steward, executor, jurist, hooks). No mechanism reconciles them. When memory files drift from reality, the executor either works from stale context or burns time syncing — both are waste.
Constraint: What Memory Should Store
Only things that cannot be derived from artifacts:
- Steward preferences and feedback
- Decisions and their rationale (the why, not the what)
- Personal context (schedule, collaborators, relationships)
- Reference pointers (where to look, not what's there)
- Cross-project context that no single repo captures
Everything else should be queried at session start from authoritative sources.
Authoritative Sources (query, don't store)
| Information | Source of truth | How to query |
|---|---|---|
| What code changed | git log across repos |
Git CLI |
| Finding/task status | FINDINGS.md, PENDING.md, REVIEWED.md | Read file, parse status fields |
| BMF health | curl localhost:3011/health |
HTTP |
| What's in the registry | Registry files on disk | Read files |
| Ollama models | ollama list |
CLI |
| Repo structure | File system | Glob/Read |
Candidate Approaches
A — Startup query agent + session-end diff agent
Startup: Agent reads authoritative sources, compares against last known state (stored in a lightweight session-state.json), reports what changed. No manual memory to maintain for derived state.
Session end: Agent diffs current state against session start, captures: decisions made, tasks completed, things left incomplete, blockers discovered. Writes a structured handoff (not prose — structured data the startup agent can consume).
Pro: Clean separation. Memory files shrink to non-derivable context only. Con: Two agents to maintain. Startup agent needs to know all sources.
B — Single reconciliation agent on a loop
Agent runs periodically (every N minutes or on significant events) and keeps a single state file current. Session start reads it; session end is just the last reconciliation.
Pro: Always current, no end-of-session rush. Con: Background cost. May be noisy. Harder to distinguish "what changed this session" from "what changed since last check."
C — Hook-driven incremental updates
Post-commit hooks, post-tool-use hooks update specific state fields. No agent — just targeted updates wired to events.
Pro: Minimal overhead. Updates happen at the moment of change. Con: Hooks are fragile. Can't capture decisions that don't produce commits. Doesn't handle cross-repo state.
D — Hybrid: hooks for fast updates + agent for reconciliation
Hooks handle the obvious updates (commit → task done, health check → BMF status). Agent runs at session start and end to catch what hooks missed and reconcile drift.
Pro: Best of both. Hooks keep things warm; agent catches drift. Con: Most complex to build and maintain.
Design Questions for Next Session
- Which approach fits the actual workflow? (David works in bursts, sometimes rapid-fire decisions, sometimes long gaps between sessions)
- What format should the handoff take? (Structured data the agent consumes? Prose the human reads? Both?)
- Should the three-party model's decisions (steward authorizations, jurist reviews) have their own tracking mechanism separate from task status?
- How much startup time is acceptable? (If the agent reads 5 repos + health endpoint + 3 status files, that's 10-15 seconds)
- Should this integrate with the existing hooks system or replace the session handoff hook?
What NOT to Build
- A dashboard or monitoring UI — this is a CLI collaboration
- A database — files and git are the persistence layer
- Anything that requires BMF to be running — it's currently down and shouldn't be a dependency
- Anything that duplicates what
git logalready does