architecture-workflowlisted

# Architecture Workflow A design decision is good when the person who inherits it can tell what you were optimizing for. Most bad architecture isn't wrong — it's undocumented and un-reversible, made against constraints nobody wrote down. This skill is a sequence for getting to a decision that holds up: **frame → constrain → generate → decide → slice → record.** Skip steps deliberately, not by accident. ## 1. Frame the actual problem The stated problem is usually a proposed solution in disguise. "We need a message queue" is an answer; the question underneath it is something like "writes are timing out during traffic spikes." Work backwards to it: - What breaks today, and for whom? Concretely — which users, which flow, how often. - What happens if we do nothing for six months? - What does "solved" look like in numbers? (Latency, cost, error rate, time-to-ship.) - Is this a problem we have, or one we expect? Both are valid, but they justify very different investment. **Stop here and ask if the answers aren't available.** Designing against a misunderstood problem is the most expensive mistake in this workflow, and it's invisible until implementation is half done. ## 2. Surface the constraints — especially the human ones Constraints determine the answer more than requirements do. Get them explicit: - **Team**: how many people, what do they actually know, who maintains this at 3am? - **Time**: is there a real date, and what's tied to it? - **Money**: infrastructure budget