This directory contains Architecture Decision Records (ADRs) for shared/monorepo-level decisions that affect the entire repository.
For package-specific ADRs, see:
- Client ADRs -
katana-openapi-clientpackage decisions - MCP Server ADRs -
katana-mcp-serverpackage decisions
An Architecture Decision Record (ADR) is a document that captures an important architectural decision made along with its context and consequences.
We use the format proposed by Michael Nygard in his article Documenting Architecture Decisions:
- Title: A short noun phrase describing the decision
- Status: Proposed | Accepted | Deprecated | Superseded
- Context: What is the issue that we're seeing that is motivating this decision?
- Decision: What is the change that we're proposing and/or doing?
- Consequences: What becomes easier or more difficult to do because of this change?
- Proposed: The ADR is proposed and under discussion
- Accepted: The ADR has been accepted and is being implemented
- Deprecated: The ADR is no longer recommended but still in use
- Superseded: The ADR has been replaced by another ADR
- ADR-009: Migrate from Poetry to uv Package Manager
- ADR-013: Module-Local Documentation Structure
- ADR-014: GitHub Copilot Custom Agents with Three-Tier Architecture
-
Copy the template:
cp docs/adr/template.md docs/adr/NNNN-short-title.md
-
Update the number (NNNN) to be the next sequential number
-
Fill in the sections:
- Title
- Status (start with "Proposed")
- Context (why is this decision needed?)
- Decision (what are we doing?)
- Consequences (what are the tradeoffs?)
-
Create a PR for discussion
-
After acceptance, update status to "Accepted"
ADRs are numbered sequentially starting from 0001. The number is part of the filename to ensure ordering.
- Client ADRs - Client package ADRs
- MCP Server ADRs - MCP server package ADRs
- Contributing Guide - Contribution guidelines
- README - Project overview and quick start