# Documentation map

The project uses a small hierarchy so overlapping plans do not become competing
sources of truth.

1. [`PROJECT_CONTEXT.md`](PROJECT_CONTEXT.md) is the canonical description of
   the vision, current implementation, target architecture, and active
   constraints.
2. [`LEARNING_ROADMAP.md`](LEARNING_ROADMAP.md) owns milestone order,
   architecture gates, reusable-system exit tests, and intentionally deferred
   work.
3. [`BUILD_IN_PUBLIC_PLAN.md`](BUILD_IN_PUBLIC_PLAN.md) owns the scoped Jajce
   visual slice. It must respect the architecture gates in the learning
   roadmap.
4. [`RESOURCE_NODE_MIGRATION.md`](RESOURCE_NODE_MIGRATION.md) is a focused
   migration plan. Phases 1–6 are complete; follow-up work should expand
   resource discovery without reintroducing abstract resource zones.
5. [`ACTION_SYSTEM_ARCHITECTURE.md`](ACTION_SYSTEM_ARCHITECTURE.md),
   [`ECONOMIC_EVENTS.md`](ECONOMIC_EVENTS.md),
   [`FOOD_STORAGE_ARCHITECTURE.md`](FOOD_STORAGE_ARCHITECTURE.md),
   [`SIMULATION_DEFINITIONS.md`](SIMULATION_DEFINITIONS.md), and
   [`SIMULATION_STATE_SCHEMA.md`](SIMULATION_STATE_SCHEMA.md) document the
   current data contracts.
6. [`decisions/`](decisions/) contains durable architectural decisions,
   including consequences and revisit conditions.

When documents disagree:

- code and tests describe current behavior;
- the newest accepted decision record governs architecture;
- `PROJECT_CONTEXT.md` governs product intent;
- `LEARNING_ROADMAP.md` governs what should be built next;
- focused plans govern only their stated scope.

Update the smallest relevant set of documents after a decision or milestone.
Do not copy full status tables into every plan.