Error/Resilience Architecture Lens
Cognitive Mode: Diagnostic
Primary Question: "How are failures handled?"
Focus: Error Propagation, Recovery Mechanisms, Circuit Breakers, Validation Gates
When to Use
- Need to understand error handling architecture
- Documenting recovery and retry mechanisms
- Analyzing validation gates and circuit breakers
- User invokes
/autoskillit:arch-lens-error-resilience or /autoskillit:make-arch-diag error
Critical Constraints
NEVER:
- Modify any source code files
- Show happy path details (that's process flow lens)
- Ignore validation and fail-fast patterns
ALWAYS:
- Focus on FAILURE paths and recovery
- Show validation gates and their failure modes
- Document retry limits and circuit breakers
- Include exception hierarchy if present
- BEFORE creating any diagram, LOAD the
/autoskillit:mermaid skill using the Skill tool - this is MANDATORY
Analysis Workflow
Step 1: Launch Parallel Exploration Subagents
Spawn Explore subagents to investigate:
Exception Hierarchy
- Find custom exception classes
- Map inheritance relationships
- Look for: Exception, Error, raise, error classes, custom exceptions
Validation Gates
- Find validation/guard functions
- Identify fail-fast patterns
- Look for: validate_*, check_*, assert, guard, gate, precondition checks
Error Detection
- Find error detection points
- Identify how failures are recognized
- Look for: try/except, catch, on_error, handle_error, error handling
Recovery Mechanisms
- Find retry logic
- Identify fallback strategies
- Look for: retry, backoff, attempt, max_retries, retry policies
Circuit Breakers
- Find patterns that prevent infinite retries
- Identify failure thresholds
- Look for: circuit, breaker, max_failures, trip, failure thresholds
Error Routing
- Find how errors are propagated
- Identify error terminal states
- Look for: raise, return Error, error node, ERROR state
Step 2: Map Error Paths
For each major operation, document:
- Success Path: Normal completion
- Retry Path: Transient failure recovery
- Failure Path: Permanent failure handling
- Circuit Break Path: Threshold exceeded
CRITICAL - Analyze Read/Write Direction:
For EVERY error handling component:
- Error context capture: What data is READ to build error context?
- Error logging: Where are errors WRITTEN (logs, database, files)?
- State updates: What state is WRITTEN on failure?
- Recovery reads: What data is READ during recovery?
Distinguish:
- Error logs (write-only, never read back for logic)
- Failure context in database (may be read for retry/debugging)
- Debug artifacts (write-only diagnostics)
Step 3: Document Recovery Mechanisms
| Mechanism |
Trigger |
Action |
Limit |
| Retry |
Transient error |
Repeat operation |
max N |
| Fallback |
Specific error |
Alternative action |
- |
| Circuit Breaker |
Too many failures |
Stop retrying |
threshold |
Step 4: Create the Diagram
Use flowchart with:
Direction: TB for error flow hierarchy
Subgraphs:
- Execution (normal operation)
- Validation Gates (fail-fast checks)
- Error Handling (detection and routing)
- Recovery (retry, fallback)
- Terminals (success, failure states)
Node Styling:
handler class: Execution nodes
detector class: Validation gates, error detection
gap class: Failed/error state (yellow warning)
stateNode class: Decision points, circuit breaker
output class: Recovery actions
terminal class: Final states (success, error)
Connection Types:
- Solid: Normal flow
- Edge labels: Conditions, error types
- Show loops for retry mechanisms
Step 5: Write Output
Write the diagram to: temp/arch-lens-error-resilience/arch_diag_error_resilience_{YYYY-MM-DD_HHMMSS}.md (relative to the current working directory)
After writing the diagram file, emit a structured output line:
diagram_path = {absolute_path_to_diagram_file}
Output Template
# Error/Resilience Diagram: {System Name}
**Lens:** Error/Resilience (Diagnostic)
**Question:** How are failures handled?
**Date:** {YYYY-MM-DD}
**Scope:** {What was analyzed}
## Exception Hierarchy
BaseError
├── ValidationError
├── ProcessingError
│ └── RetryableError
└── FatalError
## Resilience Diagram
```mermaid
%%{init: {'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50, 'curve': 'basis'}}}%%
flowchart TB
%% CLASS DEFINITIONS %%
classDef terminal fill:#1a237e,stroke:#7986cb,stroke-width:2px,color:#fff;
classDef stateNode fill:#004d40,stroke:#4db6ac,stroke-width:2px,color:#fff;
classDef handler fill:#e65100,stroke:#ffb74d,stroke-width:2px,color:#fff;
classDef phase fill:#6a1b9a,stroke:#ba68c8,stroke-width:2px,color:#fff;
classDef detector fill:#b71c1c,stroke:#ef5350,stroke-width:2px,color:#fff;
classDef output fill:#00695c,stroke:#4db6ac,stroke-width:2px,color:#fff;
classDef gap fill:#ff6f00,stroke:#ffa726,stroke-width:2px,color:#000;
subgraph Execution ["EXECUTION"]
EXEC["Execute<br/>━━━━━━━━━━<br/>Main operation"]
SUCCESS["SUCCESS<br/>━━━━━━━━━━<br/>Completed"]
RETRY["RETRY<br/>━━━━━━━━━━<br/>Transient failure"]
FAILED["FAILED<br/>━━━━━━━━━━<br/>Needs handling"]
end
subgraph Gates ["VALIDATION GATES (Fail-Fast)"]
GATE1["Validate Input<br/>━━━━━━━━━━<br/>Check required fields"]
GATE2["Validate State<br/>━━━━━━━━━━<br/>Check preconditions"]
end
subgraph Recovery ["RECOVERY MECHANISMS"]
direction TB
R_RETRY["Retry with Backoff<br/>━━━━━━━━━━<br/>Max N attempts"]
R_FALLBACK["Fallback Action<br/>━━━━━━━━━━<br/>Alternative path"]
R_CIRCUIT{"Circuit<br/>Breaker<br/>triggered?"}
end
subgraph Terminals ["TERMINAL STATES"]
T_COMPLETE([COMPLETE])
T_ERROR([ERROR])
T_CIRCUIT([CIRCUIT_BROKEN])
end
%% EXECUTION FLOW %%
EXEC --> SUCCESS
EXEC --> RETRY
EXEC --> FAILED
SUCCESS --> T_COMPLETE
RETRY -->|"back to queue"| EXEC
%% VALIDATION GATES %%
GATE1 -->|"missing"| T_ERROR
GATE1 -->|"valid"| GATE2
GATE2 -->|"invalid"| T_ERROR
GATE2 -->|"valid"| EXEC
%% RECOVERY %%
FAILED --> R_CIRCUIT
R_CIRCUIT -->|"not triggered"| R_RETRY
R_CIRCUIT -->|"triggered"| T_CIRCUIT
R_RETRY --> EXEC
R_RETRY -->|"exhausted"| R_FALLBACK
R_FALLBACK --> T_ERROR
%% CLASS ASSIGNMENTS %%
class EXEC,SUCCESS handler;
class RETRY,FAILED gap;
class GATE1,GATE2 detector;
class R_RETRY,R_FALLBACK output;
class R_CIRCUIT stateNode;
class T_COMPLETE,T_ERROR,T_CIRCUIT terminal;
Color Legend:
| Color |
Category |
Description |
| Orange |
Execution |
Normal operation and success |
| Yellow |
Failed |
Failure states requiring handling |
| Red |
Gates |
Validation gates (fail-fast) |
| Dark Teal |
Recovery |
Retry and fallback mechanisms |
| Teal |
Circuit |
Circuit breaker decisions |
| Dark Blue |
Terminal |
Final states |
Recovery Mechanisms
| Mechanism |
Trigger |
Action |
Max Attempts |
| {name} |
{condition} |
{what happens} |
{limit} |
Validation Gates
| Gate |
Checks |
Failure Mode |
| {name} |
{what validated} |
{error raised} |
---
## Pre-Diagram Checklist
Before creating the diagram, verify:
- [ ] LOADED `/autoskillit:mermaid` skill using the Skill tool
- [ ] Using ONLY classDef styles from the mermaid skill (no invented colors)
- [ ] Diagram will include a color legend table
---
## Related Skills
- `/autoskillit:make-arch-diag` - Parent skill for lens selection
- `/autoskillit:mermaid` - MUST BE LOADED before creating diagram
- `/autoskillit:arch-lens-process-flow` - For normal flow view
- `/autoskillit:arch-lens-concurrency` - For parallel failure handling
1---2name: arch-lens-error-resilience3description: Create Error/Resilience architecture diagram showing failure handling, recovery mechanisms, and circuit breakers. Diagnostic lens answering "How are failures handled?"4---5
6# Error/Resilience Architecture Lens
7
8**Cognitive Mode:** Diagnostic
9**Primary Question:** "How are failures handled?"
10**Focus:** Error Propagation, Recovery Mechanisms, Circuit Breakers, Validation Gates
11
12## When to Use
13
14- Need to understand error handling architecture
15- Documenting recovery and retry mechanisms
16- Analyzing validation gates and circuit breakers
17- User invokes `/autoskillit:arch-lens-error-resilience` or `/autoskillit:make-arch-diag error`
18
19## Critical Constraints
20
21**NEVER:**
22- Modify any source code files
23- Show happy path details (that's process flow lens)
24- Ignore validation and fail-fast patterns
25
26**ALWAYS:**
27- Focus on FAILURE paths and recovery
28- Show validation gates and their failure modes
29- Document retry limits and circuit breakers
30- Include exception hierarchy if present
31- BEFORE creating any diagram, LOAD the `/autoskillit:mermaid` skill using the Skill tool - this is MANDATORY
32
33---
34
35## Analysis Workflow
36
37### Step 1: Launch Parallel Exploration Subagents
38
39Spawn Explore subagents to investigate:
40
41**Exception Hierarchy**
42- Find custom exception classes
43- Map inheritance relationships
44- Look for: Exception, Error, raise, error classes, custom exceptions
45
46**Validation Gates**
47- Find validation/guard functions
48- Identify fail-fast patterns
49- Look for: validate_*, check_*, assert, guard, gate, precondition checks
50
51**Error Detection**
52- Find error detection points
53- Identify how failures are recognized
54- Look for: try/except, catch, on_error, handle_error, error handling
55
56**Recovery Mechanisms**
57- Find retry logic
58- Identify fallback strategies
59- Look for: retry, backoff, attempt, max_retries, retry policies
60
61**Circuit Breakers**
62- Find patterns that prevent infinite retries
63- Identify failure thresholds
64- Look for: circuit, breaker, max_failures, trip, failure thresholds
65
66**Error Routing**
67- Find how errors are propagated
68- Identify error terminal states
69- Look for: raise, return Error, error node, ERROR state
70
71### Step 2: Map Error Paths
72
73For each major operation, document:
74- **Success Path**: Normal completion
75- **Retry Path**: Transient failure recovery
76- **Failure Path**: Permanent failure handling
77- **Circuit Break Path**: Threshold exceeded
78
79**CRITICAL - Analyze Read/Write Direction:**
80For EVERY error handling component:
81- **Error context capture**: What data is READ to build error context?
82- **Error logging**: Where are errors WRITTEN (logs, database, files)?
83- **State updates**: What state is WRITTEN on failure?
84- **Recovery reads**: What data is READ during recovery?
85
86Distinguish:
87- Error logs (write-only, never read back for logic)
88- Failure context in database (may be read for retry/debugging)
89- Debug artifacts (write-only diagnostics)
90
91### Step 3: Document Recovery Mechanisms
92
93| Mechanism | Trigger | Action | Limit |
94|-----------|---------|--------|-------|
95| Retry | Transient error | Repeat operation | max N |
96| Fallback | Specific error | Alternative action | - |
97| Circuit Breaker | Too many failures | Stop retrying | threshold |
98
99### Step 4: Create the Diagram
100
101Use flowchart with:
102
103**Direction:** `TB` for error flow hierarchy
104
105**Subgraphs:**
106- Execution (normal operation)
107- Validation Gates (fail-fast checks)
108- Error Handling (detection and routing)
109- Recovery (retry, fallback)
110- Terminals (success, failure states)
111
112**Node Styling:**
113- `handler` class: Execution nodes
114- `detector` class: Validation gates, error detection
115- `gap` class: Failed/error state (yellow warning)
116- `stateNode` class: Decision points, circuit breaker
117- `output` class: Recovery actions
118- `terminal` class: Final states (success, error)
119
120**Connection Types:**
121- Solid: Normal flow
122- Edge labels: Conditions, error types
123- Show loops for retry mechanisms
124
125### Step 5: Write Output
126
127Write the diagram to: `temp/arch-lens-error-resilience/arch_diag_error_resilience_{YYYY-MM-DD_HHMMSS}.md` (relative to the current working directory)
128
129After writing the diagram file, emit a structured output line:
130
131```
132diagram_path = {absolute_path_to_diagram_file}
133```
134
135---
136
137## Output Template
138
139```markdown
140# Error/Resilience Diagram: {System Name}
141
142**Lens:** Error/Resilience (Diagnostic)
143**Question:** How are failures handled?
144**Date:** {YYYY-MM-DD}
145**Scope:** {What was analyzed}
146
147## Exception Hierarchy
148
149```
150BaseError
151├── ValidationError
152├── ProcessingError
153│ └── RetryableError
154└── FatalError
155```
156
157## Resilience Diagram
158
159```mermaid
160%%{init: {'flowchart': {'nodeSpacing': 40, 'rankSpacing': 50, 'curve': 'basis'}}}%%
161flowchart TB
162 %% CLASS DEFINITIONS %%
163 classDef terminal fill:#1a237e,stroke:#7986cb,stroke-width:2px,color:#fff;
164 classDef stateNode fill:#004d40,stroke:#4db6ac,stroke-width:2px,color:#fff;
165 classDef handler fill:#e65100,stroke:#ffb74d,stroke-width:2px,color:#fff;
166 classDef phase fill:#6a1b9a,stroke:#ba68c8,stroke-width:2px,color:#fff;
167 classDef detector fill:#b71c1c,stroke:#ef5350,stroke-width:2px,color:#fff;
168 classDef output fill:#00695c,stroke:#4db6ac,stroke-width:2px,color:#fff;
169 classDef gap fill:#ff6f00,stroke:#ffa726,stroke-width:2px,color:#000;
170
171 subgraph Execution ["EXECUTION"]
172 EXEC["Execute<br/>━━━━━━━━━━<br/>Main operation"]
173 SUCCESS["SUCCESS<br/>━━━━━━━━━━<br/>Completed"]
174 RETRY["RETRY<br/>━━━━━━━━━━<br/>Transient failure"]
175 FAILED["FAILED<br/>━━━━━━━━━━<br/>Needs handling"]
176 end
177
178 subgraph Gates ["VALIDATION GATES (Fail-Fast)"]
179 GATE1["Validate Input<br/>━━━━━━━━━━<br/>Check required fields"]
180 GATE2["Validate State<br/>━━━━━━━━━━<br/>Check preconditions"]
181 end
182
183 subgraph Recovery ["RECOVERY MECHANISMS"]
184 direction TB
185 R_RETRY["Retry with Backoff<br/>━━━━━━━━━━<br/>Max N attempts"]
186 R_FALLBACK["Fallback Action<br/>━━━━━━━━━━<br/>Alternative path"]
187 R_CIRCUIT{"Circuit<br/>Breaker<br/>triggered?"}
188 end
189
190 subgraph Terminals ["TERMINAL STATES"]
191 T_COMPLETE([COMPLETE])
192 T_ERROR([ERROR])
193 T_CIRCUIT([CIRCUIT_BROKEN])
194 end
195
196 %% EXECUTION FLOW %%
197 EXEC --> SUCCESS
198 EXEC --> RETRY
199 EXEC --> FAILED
200
201 SUCCESS --> T_COMPLETE
202 RETRY -->|"back to queue"| EXEC
203
204 %% VALIDATION GATES %%
205 GATE1 -->|"missing"| T_ERROR
206 GATE1 -->|"valid"| GATE2
207 GATE2 -->|"invalid"| T_ERROR
208 GATE2 -->|"valid"| EXEC
209
210 %% RECOVERY %%
211 FAILED --> R_CIRCUIT
212 R_CIRCUIT -->|"not triggered"| R_RETRY
213 R_CIRCUIT -->|"triggered"| T_CIRCUIT
214 R_RETRY --> EXEC
215 R_RETRY -->|"exhausted"| R_FALLBACK
216 R_FALLBACK --> T_ERROR
217
218 %% CLASS ASSIGNMENTS %%
219 class EXEC,SUCCESS handler;
220 class RETRY,FAILED gap;
221 class GATE1,GATE2 detector;
222 class R_RETRY,R_FALLBACK output;
223 class R_CIRCUIT stateNode;
224 class T_COMPLETE,T_ERROR,T_CIRCUIT terminal;
225```
226
227**Color Legend:**
228| Color | Category | Description |
229|-------|----------|-------------|
230| Orange | Execution | Normal operation and success |
231| Yellow | Failed | Failure states requiring handling |
232| Red | Gates | Validation gates (fail-fast) |
233| Dark Teal | Recovery | Retry and fallback mechanisms |
234| Teal | Circuit | Circuit breaker decisions |
235| Dark Blue | Terminal | Final states |
236
237## Recovery Mechanisms
238
239| Mechanism | Trigger | Action | Max Attempts |
240|-----------|---------|--------|--------------|
241| {name} | {condition} | {what happens} | {limit} |
242
243## Validation Gates
244
245| Gate | Checks | Failure Mode |
246|------|--------|--------------|
247| {name} | {what validated} | {error raised} |
248```
249
250---
251
252## Pre-Diagram Checklist
253
254Before creating the diagram, verify:
255
256- [ ] LOADED `/autoskillit:mermaid` skill using the Skill tool
257- [ ] Using ONLY classDef styles from the mermaid skill (no invented colors)
258- [ ] Diagram will include a color legend table
259
260---
261
262## Related Skills
263
264- `/autoskillit:make-arch-diag` - Parent skill for lens selection
265- `/autoskillit:mermaid` - MUST BE LOADED before creating diagram
266- `/autoskillit:arch-lens-process-flow` - For normal flow view
267- `/autoskillit:arch-lens-concurrency` - For parallel failure handling