architecture-decisions

Track architectural decisions by maintaining a compact architecture_log.md file that records every technical choice and its rationale. Read the log before making new decisions and append entries after changes to avoid reintroducing already-solved issues across your session.

An architecture log is a running record of architectural decisions capturing what was decided and why. You need it when introducing, removing, or changing technical topics like library choices, data stores, APIs, authentication, tooling, and module boundaries.

Document architectural decisions by appending new entries to architecture_log.md after each technical change. Record the selected framework or data store along with the reasoning behind the choice to maintain a historical context for future sessions.

The best way to manage technical governance is to enforce reading an architecture_log.md file before deciding any technical matter and mandating append-only updates after decisions, ensuring continuous documentation of library, API, and tooling boundaries.

Yes, this architecture documentation approach explicitly covers module boundaries and API design. It requires recording these structural decisions in architecture_log.md to prevent teams from debating or undoing established boundaries.

You should read an architecture log before making technical decisions to avoid reintroducing already-solved issues. Reviewing past decisions on data stores, APIs, and tooling prevents rework and repeated debates across the current development session.