Architecture Decision Records - Katana OpenAPI Client¶
This directory contains Architecture Decision Records (ADRs) specific to the katana-openapi-client package.
What is an ADR?¶
An Architecture Decision Record (ADR) is a document that captures an important architectural decision made along with its context and consequences.
Format¶
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?
ADR Lifecycle¶
- 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
Index¶
Accepted Architecture Decisions¶
- ADR-001: Use Transport-Layer Resilience Pattern
- ADR-002: Generate Client from OpenAPI Specification
- ADR-003: Transparent Automatic Pagination
- ADR-004: Defer Observability to httpx
- ADR-005: Provide Both Sync and Async APIs
- ADR-006: Use Utility Functions for Response Unwrapping
- ADR-007: Generate Domain Helper Classes
- ADR-011: Pydantic Domain Models for Business Entities
- ADR-012: Validation Tiers for Agent Workflows
Proposed Architecture Decisions¶
- ADR-008: Avoid Traditional Builder Pattern - PROPOSED
Creating a New ADR¶
- Copy the template from the shared ADR directory
- Update the number (NNNN) to be the next sequential number
- Fill in the sections
- Create a PR for discussion
- After acceptance, update status to "Accepted"
Related Documentation¶
- Testing Guide - Test coverage analysis and testing strategy
- Client Guide - User guide for the client
- Contributing Guide - Contribution guidelines
- Monorepo ADRs - Shared/monorepo-level ADRs