2e9d83f749
First full run of the Eval C discrimination harness (3-level ambiguity ladder, 6-scenario run-set, 3 reps/cell, both sonnet+haiku): 36 headless reps, 12/12 cells PASS at ≥2/3 majority. Haiku 18/18 reps, sonnet 17/18 (P1-L1 rep 1: final message citing only 0005, not governing 0002 — a boundary artifact, not a behavioral miss). Zero over-trigger ADR creation on any negative at any level; all positive passes via governing-ADR citation (16 reps) or judge fallback (1). Two harness defects fixed before running the grid: (1) bin/run pipefail bug that aborted remaining reps after first FAIL (changed checker invocation to || true); (2) positive axis-b previously required ADR creation only, contradicting the README's design statement that "consulting and/or recording is correct" — run-set positives sit in already-decided territory, so find→cite→comply is the correct behavior. Implemented three-branch axis-b check: created (new ADR file), cited-governing (final message cites the governing Accepted ADR), or judge fallback. Added two self-test guards to verify the compliance path. Scenario metadata updated to document the corrected axis-b checker behavior (cited-governing as a valid pass branch). TSV reasons column now records the pass path via `B-via:` field for positives. Verdict: Eval B wording generalizes to a new fixture, new language, new domain, and decreasing cue explicitness. Grid ceiling not found; next signal is production (rollout + IRL session audits). Run-set baseline locked; wording tuning moves measurement to reserve-set. |
||
|---|---|---|
| bin | ||
| docs | ||
| openspec | ||
| plugins | ||
| .gitignore | ||
| CLAUDE.md | ||
| README.md | ||
| graphify-interview | ||
| memory-systems-compared060326 | ||
README.md
cc-os — Cross-Project Memory for Claude Code
A personal memory system for Claude Code, designed for a multi-client freelancer. The system captures knowledge across projects and surfaces it automatically at the start of each Claude Code session.
Status
The memory plugin is live and working. Design documentation lives in docs/.
Both episodic memory (memsearch) and semantic/knowledge memory (Graphify + Obsidian vault)
are active.
What it does for you
- Injects vault context at session start — Claude sees your SecondBrain graph summary, your conventions, and today's journal path before you type the first message.
- Surfaces project structure on demand — run one command to build a graph of any project; Claude can then query it for patterns, architecture, and conventions.
- Remembers conventions automatically —
memory-writestores evergreen knowledge (coding patterns, client rules, recurring decisions) in the correct vault location with proper tags. - Stays fresh without a daemon — the vault graph rebuilds in the background when stale; vault writes immediately invalidate the timestamp so the next session picks up changes.
- Keeps project repos clean — all indexes are build artifacts (
graphify-out/); nothing is committed to project repos.
User guide
See docs/USER-GUIDE.md for setup, onboarding new projects, using the skills, and known limitations.
Directory layout
| Path | Contents |
|---|---|
docs/memory-system/ |
Architecture, ADRs, build plan, Graphify evaluation |
docs/graphify/ |
Verified Graphify command handbook |
docs/USER-GUIDE.md |
Practical usage guide |
openspec/ |
Spec-driven change management (changes, specs) |
graphify-interview, memory-systems-compared060326 |
Raw source transcripts (do not cite as fact) |