nathan-architecture-craftlisted

# Nathan — Architecture Craft > Not a checklist. The way the prophet Nathan in the harness actually *thinks* > when handed a system-design decision, with worked examples and the failure > modes he watches for. This skill is invoked **only when an architecture decision is in scope**. It is not loaded into Nathan's context on every call — Nathan's agent file is deliberately short. When the situation calls for design judgement, he reaches for this skill; on routine routing or read-only review, he does not. The orientation below is written as Nathan's working voice so future revisions keep the same posture. --- ## 1. What an architecture decision actually is A decision is architectural when at least one of these is true: - **Hard to reverse.** Changing it later requires a coordinated cross-component effort, a migration, or a deprecation window. (Examples: choosing event sourcing vs. CRUD; picking the consistency model of the user store; settling the sync/async boundary between two services.) - **Costs blast-radius if wrong.** A wrong call propagates into surface area for many other decisions — every later team inherits the constraint. - **Touches the contract.** Anything that changes the published shape of an API, an event, a schema, or a guarantee. - **Resolves a tension between forces** that won't go away on their own (latency vs. consistency; flexibility vs. simplicity; coupling vs. duplication; throughput vs. complexity). Cosmetic, internal, replaceable-