Pattern
Breakdown and Repair
When tools fail, distinguish between fixing and repairing. Fixes restore function; repairs restructure understanding. Both are necessary—but only repair prevents recurrence.
"The breakdown triggers a shift from ready-to-hand to present-at-hand, making visible the normally-hidden assumptions embedded in our practice."
— Stahl, interpreting Heidegger
Definition
Breakdown is Heidegger's term for the moment when a tool stops working and suddenly becomes visible. The carpenter's hammer, normally transparent in use (Zuhandenheit), becomes an object of attention (Vorhandenheit) when its head comes loose.
Gerry Stahl, in his analysis of Heideggerian concepts for software design, identifies a critical distinction: fixing versus repairing.
Fixing
Mechanical correction. Reattach the hammer head. Restart the service. Rollback the deployment. The symptom is addressed; the tool works again.
Repairing
Restructuring understanding. Document why the head came loose. Update deployment patterns. Change the conceptual framework so this class of failure becomes impossible.
Fixing restores function. Repairing prevents recurrence. A system that only fixes accumulates the same breakdowns. A system that repairs evolves its understanding.
"True repair requires restructuring one's conceptual framework and language—not just mechanical correction."
The Two Responses
1. Immediate Fix (Necessary)
When infrastructure fails, restore service first. Users need the system working. This is triage—essential but insufficient.
• Rollback the broken deployment
• Clear the corrupted cache
• Restart the crashed service
2. Structural Repair (Essential)
After the immediate crisis, ask: what assumption was invisible until it broke? Document the failure. Update patterns. Make the implicit explicit.
• Document why the route pattern needed /*
• Add to deployment checklist
• Update conceptual model in rules files
The Hermeneutic Loop
Stahl emphasizes that understanding moves cyclically: preunderstanding → breakdown → reinterpretation → revised understanding. Each breakdown is an opportunity to enter this loop and emerge with better conceptual tools.
Application
In CREATE SOMETHING practice, this pattern appears in .claude/rules/ files. When deployment fails, we don't just fix—we repair by updating the rules
that govern future deployments.
| Breakdown | Fix | Repair |
|---|---|---|
| Route pattern missing /* | Add /* to wrangler.toml | Document in template-deployment-patterns.md |
| Fallback overwrites index | Rename to 200.html | Add to deployment checklist |
| DNS conflicts with worker | Remove wildcard record | Explain why in Canon Reflection section |
The Canon Reflection section at the end of pattern documents is where repair happens: we articulate
the implicit assumption that failed, making it explicit so future work can avoid it.
When to Apply
Always Repair When
- • Same failure has occurred before
- • Failure reveals unstated assumption
- • Others could hit the same issue
- • Pattern documentation exists
- • The fix was non-obvious
Fix-Only Acceptable When
- • Truly one-off environmental issue
- • External dependency failure
- • Repair would be premature (still learning)
- • Cost of repair exceeds likelihood of recurrence
Source
This pattern draws from Gerry Stahl's interpretation of Heideggerian concepts for software design, particularly the distinction between mechanical fixing and conceptual repairing.
Stahl, G. "A Heideggerian Interpretation of Computer Support" →Part of the CREATE SOMETHING Pattern Library