# Life Knowledge Base — Operating Guide

This guide defines how the life_manager agent (and Cameron) should maintain this knowledge base.

## Core Principles

1. **Append, don't overwrite.** Add timestamped entries. History is valuable.
2. **Summary at the top.** Every file starts with a `## Summary` section (5-10 lines) that captures the current state. Update this when the details below change meaningfully.
3. **Split at ~300 lines.** If a file gets long, move resolved/old content to `archive/` and keep the main file focused on current state.
4. **Frontmatter is metadata.** Every file has YAML frontmatter with at least `last-updated`. Projects also get `status` and `priority`.
5. **Subfolders are cheap.** When a topic grows complex, make a subfolder. E.g., `areas/phd/` with `courses.md`, `research.md`, `advisor-notes.md` instead of one giant `phd.md`.

## File Lifecycle

### Creating a new file
```yaml
---
status: active          # active, paused, completed, archived
priority: medium        # low, medium, high, urgent
last-updated: 2026-04-06
---

# Title

## Summary
<!-- 5-10 lines: what is this, current state, what's next -->

## Details
<!-- Full content below -->
```

### When to create subfolders
- A file exceeds ~300 lines
- A topic has 3+ distinct sub-topics (e.g., PhD → courses, research, milestones)
- You want to store related files together (e.g., `resources/paper-notes/`)

When you create a subfolder, add an `index.md` inside it with a summary of what's there.

### Journal entries
- One file per day: `journal/YYYY-MM-DD.md`
- Append timestamped entries throughout the day:
  ```
  ### 14:30 — Meeting with advisor
  Discussed X, decided Y, next step is Z.
  ```
- At the end of each month, create `journal/YYYY-MM-rollup.md` extracting key decisions, changes, and open threads
- Daily files stay in `journal/`, rollups are the "working memory"

### Archiving
- When a project is completed or paused indefinitely, move it from `projects/` to `archive/`
- Add a note at the top: `Archived on YYYY-MM-DD. Reason: completed / paused / superseded by X`
- The `archive/` folder is append-only — don't delete archived files

### Updating index.md
- After significant changes to any file, update the corresponding line in `index.md`
- `index.md` should be readable in under 1 minute and give a complete picture of what's in the knowledge base

## Structure Reference

```
life/
├── CLAUDE.md              ← instructions for Claude Code (auto-read)
├── GUIDE.md               ← you are here: how to maintain this KB
├── index.md               ← one-paragraph summary of every file
├── me.md                  ← identity, goals, values, preferences
├── projects/              ← active projects (have a deadline or end state)
│   ├── para.md
│   ├── 567-course-project.md
│   └── [new-project].md
├── areas/                 ← ongoing responsibilities (no end date)
│   ├── phd.md             ← or phd/ subfolder if it grows
│   ├── finances.md
│   ├── health.md
│   └── [new-area].md
├── resources/             ← reference material
│   ├── people.md
│   └── paper-notes/
├── journal/               ← daily entries + monthly rollups
│   ├── YYYY-MM-DD.md
│   └── YYYY-MM-rollup.md
└── archive/               ← completed/paused projects
```

## What Goes Where

| Type | Location | Example |
|------|----------|---------|
| Something with a deadline | `projects/` | Paper submission, course project, internship application |
| Ongoing responsibility | `areas/` | PhD, health, finances, relationships |
| Reference you look up | `resources/` | Paper notes, people contacts, how-to guides |
| Daily log / reflection | `journal/` | What happened today, decisions made, ideas |
| Done or abandoned | `archive/` | Completed projects, old course notes |

## Privacy & Scope

- **This knowledge base is personal.** It should NOT be read by PARA experiment agents or other project-specific agents.
- **Only the `life_manager` agent and the `manager` (orchestrator) should access these files.**
- **Project files** (e.g., `projects/para.md`) can reference external project directories but should contain personal context, timelines, and decisions — not technical details that belong in the project itself.