Module 1: Architecture Fundamentals & Quality Attributes: Mistake Clinic

This clinic turns wrong moves into reusable judgment. Use it after each practice page and again before the quiz or checkpoint.

---

Module-Specific Mistake Radar

Start with these traps. Replace or extend them with real mistakes from your own work.

Mistake to look for	Where it shows up	Symptom	Repair evidence
Finishing Quality Attributes Elicitation Lab with only a final answer	Quality Attributes Elicitation Lab	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Characteristics-from-Requirements Workshop with only a final answer	Characteristics-from-Requirements Workshop	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Tradeoff Analysis Clinic with only a final answer	Tradeoff Analysis Clinic	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Architecture Communication Katas with only a final answer	Architecture Communication Katas	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Treating Architecture Is Structure Plus Decisions That Are Hard to Change as vocabulary instead of a tool	Architecture Is Structure Plus Decisions That Are Hard to Change	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.
Treating The Architect Role: Technical, Strategic, Communicator as vocabulary instead of a tool	The Architect Role: Technical, Strategic, Communicator	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.

---

Practice Mistake Checks

Pull any miss from these checks into your mistake log.

Quality Attributes Elicitation Lab

Source: practice/01-quality-attributes-elicitation-lab.md

Each of these is a real mistake. Identify the flaw and write the repaired version.

1. "The system should support 1 million users." (requirement)
2. "Our availability target is 100%." (SLO)
3. "We need to make the system faster." (proposal)
4. "Add caching everywhere to improve performance." (architectural move)
5. "We already have unit tests, so the system is testable." (claim)
6. "Security is a compliance issue, not an architectural one." (stance)
7. "Latency p50 = 180 ms, so we are fine." (metric report)
8. "Modifiability matters, but we will focus on it after launch." (plan) For each, name the specific failure: missing environment, missing measure, missing characteristic, confused pair, or wrong category.

Characteristics-from-Requirements Workshop

Source: practice/02-characteristics-from-requirements-workshop.md

Identify the flaw and rewrite:

1. A team ships a requirements doc with 14 "critical" characteristics, weighted equally.
2. An architect insists every quality should have a fitness function, including usability and developer experience. Eighteen fitness functions later, nobody runs any of them.
3. "We prioritized security, scalability, and performance." Nothing in the architecture differs between those characteristics.
4. The PRD mentions "ease of integration." The team ships with a custom RPC protocol.
5. The list includes reliability and availability as two of the top three. Nobody can state the difference.
6. A fitness function has been green for 18 months. No one has checked whether it still runs; no one has checked whether it still fails when it should. Name the specific failure: characteristic sprawl, missed implicit, unfalsifiable claim, dead fitness function.

Tradeoff Analysis Clinic

Source: practice/03-tradeoff-analysis-clinic.md

Identify what is missing or wrong:

1. A proposal says "we will adopt event-driven architecture for service-to-service communication." It lists 5 benefits. It lists no costs and no alternatives.
2. An architect claims "the new system is both more consistent and more available under failure." No partition-behavior section follows.
3. A team applies the circuit-breaker pattern to every inter-service call, citing resilience. Half their failures now come from legitimate requests being rejected during healthy windows.
4. A proposal classifies a choice as two-way but notes the commitment involves signing a 3-year vendor contract.
5. "We picked microservices because it scales better." No scale numbers, no concurrency shape, no top-3 characteristic link.
6. "We can always migrate later." No migration plan. No fitness function. No revisit condition. For each, write the specific repair: missing costs, missing alternatives, over-applied pattern, misclassified door, evidence-free claim, magical-thinking-level reversibility.

---

Repair Protocol

For each real mistake:

1. Reproduce the failure on the smallest example, trace, proof, query, command, or design sketch.
2. Name the hidden assumption.
3. Repair the artifact.
4. Save evidence that changed: failing then passing test, corrected proof step, revised diagram, safer command, benchmark, or review note.
5. Add one retrieval card beginning with Check... before... or Do not use... when....

---

Mistake Log

Date	Mistake	Symptom	Root cause	Repair evidence	Retrieval card
Starter	Pick one radar row above	Explain how it would fail in this module	Name the assumption	Add a counterexample or corrected artifact	Write the card before closing the page

---

Completion Standard

• At least five real mistakes are logged.
• At least two mistakes include a counterexample or failing test.
• At least one mistake connects to an older semester skill.
• At least one correction changes code, a proof, a diagram, a command transcript, a query, or a design decision.