Home A - Z
Page Index

An Otter Wiki
Properties 
category: reference
tags: [claude-code, memory, process, backup]
last_updated: 2026-03-20
confidence: high

Claude Code Project Memory Backup

Reorganized 2026-03-20. Memory is now tiered for progressive disclosure:

  • MEMORY.md — always loaded. Behavioral rules inline, operational rule index with scopes.
  • Operational rule files — loaded by scope when task matches. Tracked with last_used frontmatter.
  • archive.md — cold operational rules, consulted on demand.
  • Wiki — all informational/project knowledge. No local copies.

MEMORY.md (Operational Briefing)

Project

  • robot.wtf — multi-tenant wiki platform (app server, auth, MCP, management API).
  • Repos under /Users/sderle/code/otterwiki/. Parent dir is NOT a git repo.

User

  • Concise, no sycophancy, no fake enthusiasm.
  • Bias toward minimal solutions. Don't over-engineer.
  • Uses plan mode for non-trivial changes.

Behavioral rules

  • Opus orchestrates, Sonnet implements. Always.
  • All subagents run in background, no exceptions.
  • Worktrees must target a specific repo (e.g. robot.wtf/), never the parent directory.
  • TDD by default. Discuss before skipping.
  • Rule of Two: dispatch a second agent to independently verify any subagent finding before accepting it.
  • Plan review before implementation. Insert explicit Loop Check tasks in the pipeline where the orchestrator decides whether to revise or proceed.
  • Verify branch state with git log before any merge.
  • Dispatch verification agent before merging subagent work.
  • Fix known issues now. Don't carry debt.
  • Don't ask questions you can answer by reading code, wiki, or docs.
  • Question the premise before optimizing. Ask "should this exist?" before "how to make it faster?"
  • Never ignore pre-existing test failures. Fix or flag.
  • On session start, scan operational rules below. Load any that match the task.
  • Follow Design/Implementation_Workflow in wiki for full pipeline.

Memory management

  • Behavioral rules: inline in MEMORY.md, no separate files.
  • Operational rules: individual files with scope and last_used in frontmatter.
  • Informational/project knowledge: write to dev wiki, not local files.
  • Cold operational rules: move index entry to archive.md.
  • Session end: update last_used on any operational rule that was applied.
  • Review when: last_used > 2 weeks OR MEMORY.md exceeds 150 lines.

Wiki knowledge base (query on demand via dev-wiki MCP)

  • Design/ — feature specs, architecture decisions
  • Dev/ — implementation summaries, benchmarks, retrospectives
  • Tasks/ — task breakdowns (To-Do page is authoritative tracker)
  • Security/ — OWASP audit
  • Dev/Claude_Code_Memory_Backup — canonical memory snapshot
  • Use semantic_search when the page location isn't obvious from the index.

Operational rules (load by scope)

  • repos-and-tools.md — scope: git
  • vps-access.md — scope: deploy
  • feedback_reproducible_vps.md — scope: deploy
  • feedback_otterwiki_config_override.md — scope: db
  • reference_db_locations.md — scope: db
  • mcp-servers.md — scope: mcp
  • mcp-auth.md — scope: mcp
  • feedback_preflight_checklist.md — scope: workflow
  • feedback_explicit_loop_checks.md — scope: workflow

Operational Rule Files (full content)

repos-and-tools.md (scope: git)

All repos live under /Users/sderle/code/otterwiki/. The parent directory is NOT a git repo.

F/OSS Repos:

  • otterwiki/ — Fork of redimp/otterwiki (wiki engine). Upstream: github.com:redimp/otterwiki. Our remote: github.com:schuyler/otterwiki (SSH). Deploy branch: wikibot-io. Feature branches: feat/* off wikibot-io.
  • otterwiki-api/ — REST API plugin. Remote: github.com:schuyler/otterwiki-api. Branch: main.
  • otterwiki-semantic-search/ — FAISS + ONNX MiniLM semantic search plugin. Remote: github.com:schuyler/otterwiki-semantic-search. Branch: main.
  • otterwiki-mcp/ — MCP server plugin (12 tools). Remote: github.com:schuyler/otterwiki-mcp. Branch: main.

Private Repos:

  • robot.wtf/ — Platform app server, auth, MCP sidecar, API, Ansible deploy. Remote: github.com:schuyler/robot.wtf.
  • wikibot-io/ — AWS SaaS predecessor (Pulumi IaC, Lambda packaging). Remote: github.com:schuyler/wikibot-io. AWS profile: wikibot (us-east-1).
  • deploy/ — Legacy 3GW deploy config. No git remote.
  • dev-wiki/ — Local dev wiki git repo.

Deploy flow (robot.wtf): ansible-playbook ansible/deploy.yml -i ansible/inventory.yml from robot.wtf repo.

vps-access.md (scope: deploy)

wiki-1 (app server): ssh sderle@192.168.77.107

  • Services: otterwiki (8000), MCP sidecar (8001), API (8002), auth (8003)
  • Data: /srv/data/robot.db, /srv/data/wikis/, /srv/data/robot.env
  • Ansible: /Users/sderle/code/otterwiki/robot.wtf/ansible/

proxy-1 (Caddy): ssh sderle@robot.wtf

  • Read-only only. Managed by separate Ansible repo.

3GW (local network): LXC container at 3gw.lan, zmx session 3gw.

feedback_reproducible_vps.md (scope: deploy)

NEVER run SSH commands that mutate the VPS. Allowed: read-only diagnostics (journalctl, systemctl status, curl, cat, ls, sqlite3 SELECT). NOT allowed: pip install, sed -i, systemctl restart, rm, mkdir, or any state-changing command.

Correct workflow: Edit Ansible role → commit → ansible-playbook deploy.yml → verify via read-only SSH.

Corrected five times. The 45-second deploy cycle is the cost of reproducibility and it is always worth paying. Subagents must also follow this rule.

feedback_otterwiki_config_override.md (scope: db)

Otterwiki's update_app_config() loads preferences from the active DB and overwrites Flask config. Load order: defaults → settings.cfg → env vars → DB (DB wins). The startup default DB creates empty-string rows that overwrite settings.cfg.

Always seed config values in per-wiki preferences table via _init_wiki_db(). Do NOT rely on settings.cfg for user-modifiable config.

reference_db_locations.md (scope: db)

Platform DB (/srv/data/robot.db): Schema in ansible/roles/database/files/schema.sql. Tables: users, wikis, oauth_*, mcp_tokens. Code: app/db.py, app/models/.

Per-wiki DBs (/srv/data/wikis/{slug}/wiki.db): Otterwiki's own SQLAlchemy schema. Tables: preferences, user, drafts. Code: app/resolver.py (_init_wiki_db). Initialized on first access (idempotent).

These are NOT the same schema. Code that writes to one does not affect the other.

mcp-servers.md (scope: mcp)

Three MCP connections. Do NOT confuse them.

  • dev-wiki (mcp__dev-wiki__*) = dev.robot.wtf — platform dev instance
  • thirdgulfwar (mcp__thirdgulfwar__*) = 3gw.robot.wtf — research wiki (LXC/Caddy)
  • claude_ai_Third_Gulf_War_research_wiki — same as thirdgulfwar, via Claude.ai connector

mcp-auth.md (scope: mcp)

MultiAuth composes InMemoryOAuthProvider (OAuth 2.1 for Claude.ai) + StaticTokenVerifier (bearer token for Claude Code). OAuth is the transport layer — Caddy basic auth on /authorize* is the actual gate. Tokens are in-memory; server restart forces re-auth.

Key gotchas: Claude.ai does NOT support bearer tokens. DCR disabled by default. Claude.ai URL must include /mcp path. StaticTokenVerifier (not DebugTokenVerifier) for bearer fallback.

feedback_preflight_checklist.md (scope: workflow)

Before dispatching ANY worktree-isolated agent:

  1. Verify CWD is inside the target git repo
  2. Confirm plan-review loop is complete (no FAIL or CONDITIONS outstanding)
  3. Confirm task list dependencies are wired up

feedback_explicit_loop_checks.md (scope: workflow)

Pipeline template:

- [ ] Plan
- [ ] Plan Review (blocked by Plan)
- [ ] Plan Loop Check (blocked by Plan Review) ← orchestrator evaluates
- [ ] Implement (blocked by Plan Loop Check)
- [ ] Chico review (blocked by Implement)
- [ ] Zeppo review (blocked by Implement)
- [ ] Review Loop Check (blocked by Chico + Zeppo) ← orchestrator evaluates
- [ ] Verify (blocked by Review Loop Check)

No standing "Fix" task. Fix tasks created only if Loop Check determines they're needed. Loop Check tasks completed by the orchestrator, not a subagent.