# 010 Chat history policy

## Context
- v1 keeps chat history in filesystem, not in central DB
- chat metadata must not depend on parsing history content
- each chat already maps to an isolated working directory

## Decision
- each chat owns one `history.md` inside its chat directory
- `history.md` is created with chat layout initialization
- chat metadata stores identity and lifecycle fields separately from history content
- history read and write stay behind storage ports in outer layers

## Consequences
- history survives sandbox restart with chat storage
- metadata and content evolve independently
- later migration to another history backend can keep the same chat identity model