memory-dual

# memory-dual The single durable-knowledge surface for vibekit. Two file-backed regions under `.vibekit/`: - **Entries** — keyed knowledge, one file per key. Spans atomic facts ("test runner is vitest") and compound documents ("the entire auth flow architecture, edge cases, and rejected alternatives") under one storage convention. The shape of an entry is signaled by its `type:` frontmatter, not by which directory it lives in. - **Notepad** — three short-lived sections (Priority / Working / Manual) for context that should survive conversation compaction within a session. A single append-only `log.md` chronicles all writes. An auto-maintained `INDEX.md` catalogs every entry. All five CLIs (Claude Code, Codex, Gemini, opencode, Pi) read and write the same files identically. No database, no daemon, no runtime API. ## When to invoke - The user asks to remember, recall, save, note, pin, query, or audit project knowledge. - A vibe run produces a finding that should outlive the run (a project convention, a deadline, a stakeholder ask, a non-obvious gotcha, an architecture decision, a session-log). - A skill needs project context the current conversation does not carry (`brainstorm-lean` step 1, `brief-compiler` CONTEXT enrichment). - The user asks to lint, prune, or clean memory. Do NOT invoke for: - Information already in code, git history, or the spec/plan files. Those are authoritative. - Per-feature design docs — those are `docs/specs/` artifacts produced by `brainstorm-l...