# Knowledge Store

## Purpose
The KnowledgeStore holds project experiences — lessons learned from real work, not abstract
facts. An experience captures a situation that occurred, what was done, and what the
consequence was. Use it to avoid repeating mistakes and to apply proven patterns.

## Experience vs. Fact

The KnowledgeStore stores **experiences**, not general knowledge:

- **Fact** (not useful here): "Fact tables should not contain descriptive attributes."
- **Experience** (what belongs here): "In project X, a descriptive attribute was placed
  in a Fact table. The BI tool aggregated it incorrectly. This caused incorrect reports
  for three months. Lesson: validate Fact table column types at design review, not
  after implementation."

An experience has a situation, an action, a consequence, and a lesson.
A fact is just a rule that could appear in a manual.

## Reading — Always Before Designing or Implementing

Search the KnowledgeStore before making any significant design or implementation decision:
1. Use `search_knowledge` with 2–3 keyword variations of your topic.
2. Apply found experiences to your current work.
3. If a relevant experience exists, follow its lesson — do not repeat documented mistakes.

## Experience Entry Format

A good knowledge entry has:
- **Situation**: When and in what context does this apply?
- **Action**: What was done?
- **Consequence**: What happened as a result?
- **Recommendation**: What to do or avoid in the future?

## Entry Types
- **Rule**: A general principle derived from repeated experience.
- **Decision**: A specific architectural or design choice with its rationale and context.
- **Anti-Pattern**: A mistake pattern with its observed consequence.
- **Postmortem**: A retrospective on what went wrong and what was learned.

## Write Access

Only the `knowledge-architect` agent writes to the KnowledgeStore.
All other agents read only.
