One brain per project.
One library per platform.
Every project stays sealed — it never learns other projects exist. Technical lessons still travel between them, but only anonymized, only through gates, and only applied with your approval.
What this is: a memory architecture for a multi-project studio running on Claude Code. Each project — call it project-x — is a sealed room — the agent inside it cannot see, name, or infer any other project. Each platform (WordPress, Shopify) keeps one anonymous library of hard-won technical lessons, plus a stricter root library for cross-platform lessons every project can use. Between the rooms and the libraries stand two gates: a mechanical scrub gate that blocks any identifying detail from being written, and your approval, required before any lesson is applied or saved. Knowledge flows; identity never does.
00The contract — your rules
Dictated by the owner. Everything below in this page exists to enforce these six clauses.
While working in one project, no other project exists. The agent never lists, reads, references, or infers sibling directories, project names, or their work.
The platform knowledge/ folder is the sole bridge between projects. No side channels — not memory, not chat summaries, not filenames.
No names, domains, paths, dates, or stack fingerprints that could identify where a lesson came from. Untraceable by design — even when asked directly.
The agent may read any lesson while diagnosing. Before applying one to a project: explicit owner approval, per pattern, every session.
Every write to knowledge/ requires the owner to approve the exact final text — and must pass the scrub gate mechanically.
A lesson from one project may be wrong for another. Every lesson carries where it was tested, where it failed, and its own verification probes.
01The map
Nothing inside the projects changes. The system lives in parent folders and one toolbox outside the tree.
L1 loads for every project: work on ONE project, never list/read/infer siblings, never attribute knowledge. L2 adds platform rules: how to read lessons, when to ask approval.
One anonymous lesson per file, grep-found, not in git. Platform folders hold platform-semantics lessons; the root pool holds cross-platform ones (CI, DNS, hosting, tooling) — routed by what a lesson applies to, never by where it was found. Root is stricter: 3 admission gates, required “why not obvious” field, hard cap of 30.
The blocklist holds every project identifier — inside the tree it would itself be a leak. Only the scrub script reads it; the agent just sees pass/fail.
02Three defense layers
Each layer catches what the previous one misses.
CLAUDE.md contracts
Bind the agent: no sibling awareness, no attribution, no auto-apply, no preemptive knowledge scanning. Loaded automatically in every session.
Write-guard hook + scrubber
Any file write into knowledge/ is piped through scrub.sh first. URLs, emails, IPs, paths, dates, phone numbers, blocklist terms → write denied. Works even against prompt injection.
You approve everything
Every lesson’s final text before it lands. Every application before it touches a project. The machine proposes; you decide.
03Flow A — daily work: read & apply
Happens inside any project session, whenever a real problem matches a lesson. Never at session start, never preemptively.
Example: live site throws 502 errors, but only sometimes.
grep -l "502" WordPress/knowledge/ → finds wp-cdn-cache-hit-502. Checks applies_when / avoid_when against the current project.
“Lesson wp-cdn-cache-hit-502 matches. tested_context: shared-litespeed / wp 6.x. known_failures: none. Your note: verified once, untested on VPS. Apply? [y/n/show]” — context differences are highlighted, never hidden.
Runs the lesson’s own check that it actually applies here (e.g. confirm 502 only on cache HIT). Probe fails → stop, report, nothing touched.
Applies the pattern adapted to this project, then runs the lesson’s post-checks: homepage, checkout, admin, mobile.
Optionally propose a confidence_note update (“also verified on VPS”) → you approve → written through the scrub gate.
Run the lesson’s Rollback. Propose a known_failures append — tag vocabulary only, no free text → you approve → written through the scrub gate.
May cite the lesson id (ids are anonymous). Never writes project details in the other direction.
04Flow B — /promote
Manual only. Run at milestones — end of engagement, notable fix.
Filter generalizable technical lessons. Skip project state, per-project rules, one-offs.
Routed by applicability: platform semantics → platform folder; generic infra → root pool (3 gates + cap 30). Rigid schema: versions → major.x, no dates, no domains. Novelty check flags anything an LLM already knows.
scrub.sh --registeradds this project’s identifiers to the blocklist, then scans every draft. Hits must be fixed.
You see the exact final text AND destination folder. Approve / edit / reject / change target.
The write-guard hook re-scrubs at write time. Double gate.
05Flow C — /knowledge-review
Quarterly. Run from the platform folder — a session with no project context loaded.
List lessons with age, status, version ranges.
Stale version ranges, lessons with repeated failures that should split into two narrower lessons, duplicates.
Keep / edit / split / retire. Retired lessons keep their file, status flips — history stays greppable.
50 hard-won lessons beat 200 “maybe useful” notes.
06Anatomy of a lesson
A lesson is a conditional hypothesis with its own tests — never a universal fact. Two statuses only: active / retired. No counters, no “proven”.
Where it actually worked — coarse enough to never fingerprint a project. Shown verbatim in every approval prompt so you can compare against the current project yourself.
The agent must match these before even proposing the lesson. A mismatch is surfaced with the difference highlighted — you decide, not an algorithm.
Tag vocabulary only — free text is where project details leak. A lesson failing twice for the same reason should be split, not annotated forever.
The load-bearing safety. A probe like apachectl -M | grep rewrite catches misapplication regardless of history — more reliable than any track record.
One line, written by you at promote time. Honest scope beats implied statistics.
07Try the scrub gate
Same rules as scrub.sh. Paste lesson text — or load a sample — and run the gate. (Samples use fictional identifiers.)
08Scenarios covered
09Cost of running it
L1 + L2 contracts per session. Lessons load only on a grep match.
inside existing projects. Only parent-level files are added.
/promote, /knowledge-review, and the knowledge write-guard.
for knowledge/ — commit timestamps correlate lessons to project work.
10Watch it run
Two live simulations — auto-playing sessions with pause, speed and scene controls.
Inside one sealed project
A session in project-x hits a live bug, greps the library, passes the gates, applies with probes — then promotes the lesson out through the scrub gate.
How projects share knowledge
The full sequence between two sealed projects: X learns and promotes; weeks later Y discovers the lesson, gets it approved, applies it — and never learns where it came from.