bcquality/custom/knowledge/architecture/shared-project-memory-must-be-in-repo.md
Michael Dieringer dd5637b1db Custom-laget bestaar nu begge CI-checks: 72 validator-fejl -> 0
Normalisering af alle 39 custom knowledge-filer til READ-kontraktens
skema (validate_frontmatter.py + Test-KnowledgeIndex.ps1 begge groenne):

- R01/R02: 28 filer manglede frontmatter eller brugte aeldre skemaer
  (title/category/severity/rule-id m.fl.) - alle har nu praecis de 6
  kraevede noegler; keywords haandskrevet pr. fil da de driver
  worklist-selektionen i INDEX/knowledge-index
- R09: manglende Description-sektion - regel-agtige foersteoverskrifter
  (Core Rule/Rule/Regel/Core Principle) omdoebt, eller sektion indsat
  efter titlen hvor intro-tekst fandtes
- R10: fenced code blocks konverteret til 4-space indrykkede blokke
  i alle filer (indhold uaendret)
- R11: 4 filer over 100 linjer fortaettet redaktionelt uden semantisk
  tab (ai-eval-scores 143->100, git-lifecycle 121->97,
  permission-sets 113->99, test-feature-scenario-tags 105->91)
- R05: AL0197->al0197, add_repo->add-repo; keyword-lister trimmet
  til maks 10

Ingen regler er fjernet eller aendret i betydning - kun form.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-01 23:47:31 +02:00

69 lines
2.8 KiB
Markdown

---
bc-version: [all]
domain: architecture
keywords: [projectmemory, shared-memory, repo, team-knowledge]
technologies: [al]
countries: [w1]
application-area: [all]
---
# Shared Project Memory Must Be in the Repository
## Description
When Claude learns something relevant to the project — a business rule, an architectural
decision, a known limitation, a scope boundary — that knowledge must be written to the
repository's `projectmemory/` folder, not to the local user memory store
(`~/.claude/projects/.../memory/`).
Local memory is invisible to other team members and disappears when someone works on
a different machine. Version-controlled memory is shared, attributed, and persistent.
## Anti Pattern
# Stored only on Michael's laptop — Tod and SJG never see this
~/.claude/projects/d--MyProject/memory/project-pricing-vat-scope.md
A rule observed by one developer stays siloed. The next session on another machine —
or by another team member — starts from zero.
## Best Practice
# In the git repository — committed, shared, visible to all
projectmemory/
memoryupdates_mid.md ← Michael's observations
memoryupdates_tod.md ← Tod's observations
memoryupdates_sjg.md ← SJG's observations
Each file is named after the user who triggered the observation. All files are read
by every team member's Claude session at start, via an instruction in `CLAUDE.md`:
## Shared project memory
At session start, read **all files** in `projectmemory/` — they contain shared
project observations from all team members and are version-controlled in git.
When you learn something project-relevant, write it to
`projectmemory/memoryupdates_<username>.md` for the active user.
User-specific preferences (tone, workflow habits) stay in the local
`~/.claude/projects/.../memory/` folder as before.
## What belongs in projectmemory vs local memory
| projectmemory/ (shared, in git) | local memory (personal, not shared) |
|---|---|
| Business rules ("B2B only, no VAT") | User's preferred communication language |
| Architectural decisions and rationale | Workflow habits and preferences |
| Scope boundaries ("IC via ChangeCompany only") | Personal shortcuts or shortcuts |
| Known technical debt and migration status | Role and seniority (already known by the team) |
| Test coverage scope | |
| Company/entity structure | |
## Implementation checklist
- [ ] Create `projectmemory/` folder in repo root
- [ ] Add `projectmemory/**` to `cspell.json` ignorePaths (notes are often in the team's native language)
- [ ] Add the read-at-session-start instruction to `CLAUDE.md`
- [ ] When learning something project-relevant, write to `projectmemory/memoryupdates_<username>.md`
- [ ] Commit and push — knowledge is only shared once it is in git