cebf8c167a
Folds three previously-separate pieces into one preliminary-example repo for the HAHACS thesis: - thesis/ (submodule) → gitea Thesis.git — the PhD proposal - fret-pipeline/ — FRET requirements to AIGER controller (was ~/Documents/fret_processing/; prior single-commit history abandoned per user decision) - plant-model/ — 10-state PKE + lumped T/H PWR model (was ~/Documents/PKE_Playground/; never version-controlled before) - presentations/2026DICE/ (submodule) → gitea 2026DICE.git - reachability/, hardware/ — empty placeholders for Thrust 3 and HIL - docs/architecture.md — how the discrete and continuous layers compose - claude_memory/ — session notes and scratch knowledge pattern Plant model refactored to thesis naming (x, plant, u, ref); pke_th_rhs now takes u as an explicit arg instead of reading rho_ext from the params struct. First two controllers built to the contract u = ctrl_<mode>(t, x, plant, ref): ctrl_null (baseline) and ctrl_operation (stabilizing, proportional on T_avg). Validated under a 100% -> 80% Q_sg step: ctrl_operation reduces steady-state T_avg drift ~47% vs. the unforced plant. Root CLAUDE.md emphasizes that CLAUDE.md files are living documents and that any knowledge not captured before a session ends is lost forever; claude_memory/ holds the session-level notes that haven't stabilized enough to graduate into a CLAUDE.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
40 lines
1.6 KiB
Markdown
40 lines
1.6 KiB
Markdown
# claude_memory/
|
|
|
|
Session notes and scratch knowledge that hasn't (yet) earned a place in a
|
|
`CLAUDE.md`. **Anything that leaves a context window uncaptured is lost
|
|
forever** — this folder exists so session-level insight doesn't evaporate.
|
|
|
|
## Purpose
|
|
|
|
A Claude context window is finite. Anything an agent figures out in a session
|
|
that isn't written down is gone when the session ends. The curated
|
|
`CLAUDE.md` files hold stable, authoritative knowledge; this folder holds
|
|
everything else that's still worth remembering.
|
|
|
|
## Pattern
|
|
|
|
- One file per session with non-trivial insight.
|
|
- Filename: `YYYY-MM-DD-short-topic.md`. Date first so `ls` is chronological.
|
|
- Freeform. Rough edges encouraged. Don't polish — capture.
|
|
- At minimum, answer: *what did we do, what did we decide, what surprised
|
|
us, what's still open.*
|
|
- Cross-reference files you edited, alternatives you considered, dead-ends
|
|
you hit.
|
|
|
|
## What graduates vs. what stays
|
|
|
|
Three futures for a note in here:
|
|
|
|
1. **Graduates up** into a `CLAUDE.md` (or `docs/architecture.md`, or a
|
|
code comment) when the knowledge stabilizes and becomes authoritative.
|
|
After graduating, consider deleting the note or leaving it as historical
|
|
context.
|
|
2. **Stays here** as historical context — useful for "why did we do X last
|
|
month?" or "what have we already tried?"
|
|
3. **Gets deleted** when it's no longer relevant (a fixed bug, an abandoned
|
|
approach, a stale investigation).
|
|
|
|
The graduation step is a discipline, not automation. When you're finishing a
|
|
session and think "a future agent needs this to avoid re-discovering it,"
|
|
ask: is this stable enough for a `CLAUDE.md`, or is it still forming?
|