State Lifecycle Architecture Lens
Cognitive Mode: Perspective (Quality Overlay)
Primary Question: "How is state corruption prevented?"
Focus: Field Contracts, Validation Gates, Resume Safety, State Mutation Control
When to Use
- Need to understand state management architecture
- Documenting field lifecycle contracts
- Analyzing resume and checkpoint safety
- User invokes
/arch-lens-state-lifecycle or /make-arch-diag state
Critical Constraints
NEVER:
- Modify any source code files
- Show business logic details
- Focus on data content (focus on mutation rules)
ALWAYS:
- Focus on STATE MUTATION RULES
- Show field lifecycle categories
- Document validation gates
- Include resume detection strategy
- BEFORE creating any diagram, LOAD the
/mermaid skill using the Skill tool - this is MANDATORY
Analysis Workflow
Step 1: Launch Parallel Exploration Subagents
Spawn Explore subagents to investigate:
State Schema
- Find state/context definitions
- Identify typed state fields
- Look for: State classes, Context objects, state schemas, typed dictionaries
Field Categories
- Find field mutation patterns
- Identify immutable vs mutable fields
- Look for: immutable fields, readonly, lifecycle annotations, const fields
Validation Gates
- Find state validation code
- Identify gate patterns
- Look for: validate_*, gate, check_*, guard, assert, state validators
Resume Detection
- Find resume/checkpoint code
- Identify resume detection strategy
- Look for: resume, checkpoint, restore, detect state, load checkpoint
State Updates
- Find state mutation code
- Identify update patterns
- Look for: update methods, setState, mutation functions, state setters
Contract Enforcement
- Find contract validation
- Identify violation detection
- Look for: contract checking, violation detection, enforcement mechanisms
Step 2: Categorize Fields
| Category |
Description |
Fields |
| INIT_ONLY |
Set once, never modify |
{fields} |
| INIT_PRESERVE |
Keep on resume |
{fields} |
| MUTABLE |
Can change freely |
{fields} |
| APPEND_ONLY |
Can only grow |
{fields} |
| DERIVED |
Computed, not stored |
{fields} |
CRITICAL - Analyze Read/Write Direction:
For EVERY state field and storage location:
- Read patterns: Who READS this field? When?
- Write patterns: Who WRITES this field? When?
- Read-after-write: Is the written value ever READ back by the system?
Distinguish clearly:
- State fields (read/write): System both writes AND reads back for decisions
- Checkpoint storage (read/write): Written during execution, read on resume
- Audit logs (write-only): System writes but never reads back for logic
- Debug artifacts (write-only): Written for humans, not read by system
Step 3: Map Validation Flow
Document:
- Gate order (which runs first)
- Failure modes
- Resume vs fresh start differences
Step 4: Create the Diagram
Use flowchart with:
Direction: TB for contract enforcement flow
Subgraphs:
- Lifecycles (field categories)
- Validation Gates
- State Wrapper (mutation mechanism)
- Resume Detection
- Phase Jump Routing
Node Styling:
detector class: INIT_ONLY fields (red - critical)
gap class: INIT_PRESERVE fields (yellow - warning)
phase class: MUTABLE fields (purple)
handler class: APPEND_ONLY fields (orange)
stateNode class: Validation gates
output class: State wrapper/accessor
cli class: Resume detection tiers
Step 5: Write Output
Write the diagram to: temp/arch-lens-state-lifecycle/arch_diag_state_lifecycle_{YYYY-MM-DD_HHMMSS}.md
Output Template
# State Lifecycle Diagram: {System Name}
**Lens:** State Lifecycle (Contract Overlay)
**Question:** How is state corruption prevented?
**Date:** {YYYY-MM-DD}
**Scope:** {What was analyzed}
## Field Lifecycle Categories
| Category | Description | Example Fields |
|----------|-------------|----------------|
| INIT_ONLY | Never modify after init | {fields} |
| INIT_PRESERVE | Keep on resume | {fields} |
| MUTABLE | Free to change | {fields} |
| APPEND_ONLY | Can only grow | {fields} |
## State Lifecycle Diagram
```mermaid
%%{init: {'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60, 'curve': 'basis'}}}%%
flowchart TB
%% CLASS DEFINITIONS %%
classDef cli 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 Lifecycles ["FIELD LIFECYCLE CATEGORIES"]
direction TB
INIT_ONLY["INIT_ONLY<br/>━━━━━━━━━━<br/>id, request_id<br/>NEVER modify"]
INIT_PRESERVE["INIT_PRESERVE<br/>━━━━━━━━━━<br/>is_resuming<br/>Keep on resume"]
MUTABLE["MUTABLE<br/>━━━━━━━━━━<br/>current_state<br/>Freely change"]
APPEND_ONLY["APPEND_ONLY<br/>━━━━━━━━━━<br/>errors, history<br/>Only grow"]
end
subgraph Gates ["VALIDATION GATES"]
direction TB
GATE1["validate_required<br/>━━━━━━━━━━<br/>FAIL-FAST"]
GATE2["validate_lifecycle<br/>━━━━━━━━━━<br/>Contract check"]
GATE3["resume_safety<br/>━━━━━━━━━━<br/>Preserve check"]
end
subgraph Wrapper ["STATE WRAPPER"]
direction TB
ACCESSOR["StateAccessor<br/>━━━━━━━━━━<br/>Tracks mutations"]
MERGE["Merge Updates<br/>━━━━━━━━━━<br/>Auto-include"]
end
subgraph Resume ["RESUME DETECTION"]
direction TB
TIER1["Tier 1: Explicit<br/>━━━━━━━━━━<br/>flag=true"]
TIER2["Tier 2: Heuristic<br/>━━━━━━━━━━<br/>State exists"]
TIER3["Tier 3: Fresh<br/>━━━━━━━━━━<br/>No indicators"]
end
%% FLOW %%
INIT_ONLY --> GATE1
INIT_PRESERVE --> GATE2
MUTABLE --> GATE2
APPEND_ONLY --> GATE2
GATE1 --> GATE2
GATE2 --> GATE3
GATE3 --> ACCESSOR
ACCESSOR --> MERGE
MERGE --> TIER1
TIER1 --> TIER2
TIER2 --> TIER3
%% CLASS ASSIGNMENTS %%
class INIT_ONLY detector;
class INIT_PRESERVE gap;
class MUTABLE phase;
class APPEND_ONLY handler;
class GATE1,GATE2,GATE3 stateNode;
class ACCESSOR,MERGE output;
class TIER1,TIER2,TIER3 cli;
Color Legend:
| Color |
Category |
Description |
| Red |
INIT_ONLY |
Never modify (critical) |
| Yellow |
INIT_PRESERVE |
Preserved on resume |
| Purple |
MUTABLE |
Freely modifiable |
| Orange |
APPEND_ONLY |
Can only grow |
| Teal |
Gates |
Validation gates |
| Dark Teal |
Wrapper |
State mutation mechanism |
| Dark Blue |
Detection |
Resume detection tiers |
State Lifecycle Contract Rules
| Lifecycle |
Fresh Start |
Resume |
Violation Detection |
| INIT_ONLY |
Cannot modify |
Cannot modify |
{detection} |
| INIT_PRESERVE |
Can modify |
Cannot modify |
{detection} |
| MUTABLE |
Can modify |
Can modify |
Never fails |
| APPEND_ONLY |
Can append |
Can append |
{detection} |
Resume Detection Strategy
| Tier |
Check |
Result |
| 1 |
Explicit flag |
{what happens} |
| 2 |
Heuristic |
{what happens} |
| 3 |
Fresh start |
{what happens} |
---
## Pre-Diagram Checklist
Before creating the diagram, verify:
- [ ] LOADED `/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
- `/make-arch-diag` - Parent skill for lens selection
- `/mermaid` - MUST BE LOADED before creating diagram
- `/arch-lens-process-flow` - For state machine view
- `/arch-lens-error-resilience` - For validation failure handling
1---2name: arch-lens-state-lifecycle3description: Create State Lifecycle architecture diagram showing field contracts, validation gates, and resume safety. Contract overlay lens answering "How is state corruption prevented?"4---56# State Lifecycle Architecture Lens78**Cognitive Mode:** Perspective (Quality Overlay)9**Primary Question:** "How is state corruption prevented?"10**Focus:** Field Contracts, Validation Gates, Resume Safety, State Mutation Control1112## When to Use1314- Need to understand state management architecture15- Documenting field lifecycle contracts16- Analyzing resume and checkpoint safety17- User invokes `/arch-lens-state-lifecycle` or `/make-arch-diag state`1819## Critical Constraints2021**NEVER:**22- Modify any source code files23- Show business logic details24- Focus on data content (focus on mutation rules)2526**ALWAYS:**27- Focus on STATE MUTATION RULES28- Show field lifecycle categories29- Document validation gates30- Include resume detection strategy31- BEFORE creating any diagram, LOAD the `/mermaid` skill using the Skill tool - this is MANDATORY3233---3435## Analysis Workflow3637### Step 1: Launch Parallel Exploration Subagents3839Spawn Explore subagents to investigate:4041**State Schema**42- Find state/context definitions43- Identify typed state fields44- Look for: State classes, Context objects, state schemas, typed dictionaries4546**Field Categories**47- Find field mutation patterns48- Identify immutable vs mutable fields49- Look for: immutable fields, readonly, lifecycle annotations, const fields5051**Validation Gates**52- Find state validation code53- Identify gate patterns54- Look for: validate_*, gate, check_*, guard, assert, state validators5556**Resume Detection**57- Find resume/checkpoint code58- Identify resume detection strategy59- Look for: resume, checkpoint, restore, detect state, load checkpoint6061**State Updates**62- Find state mutation code63- Identify update patterns64- Look for: update methods, setState, mutation functions, state setters6566**Contract Enforcement**67- Find contract validation68- Identify violation detection69- Look for: contract checking, violation detection, enforcement mechanisms7071### Step 2: Categorize Fields7273| Category | Description | Fields |74|----------|-------------|--------|75| INIT_ONLY | Set once, never modify | {fields} |76| INIT_PRESERVE | Keep on resume | {fields} |77| MUTABLE | Can change freely | {fields} |78| APPEND_ONLY | Can only grow | {fields} |79| DERIVED | Computed, not stored | {fields} |8081**CRITICAL - Analyze Read/Write Direction:**82For EVERY state field and storage location:83- **Read patterns**: Who READS this field? When?84- **Write patterns**: Who WRITES this field? When?85- **Read-after-write**: Is the written value ever READ back by the system?8687Distinguish clearly:88- **State fields (read/write)**: System both writes AND reads back for decisions89- **Checkpoint storage (read/write)**: Written during execution, read on resume90- **Audit logs (write-only)**: System writes but never reads back for logic91- **Debug artifacts (write-only)**: Written for humans, not read by system9293### Step 3: Map Validation Flow9495Document:96- Gate order (which runs first)97- Failure modes98- Resume vs fresh start differences99100### Step 4: Create the Diagram101102Use flowchart with:103104**Direction:** `TB` for contract enforcement flow105106**Subgraphs:**107- Lifecycles (field categories)108- Validation Gates109- State Wrapper (mutation mechanism)110- Resume Detection111- Phase Jump Routing112113**Node Styling:**114- `detector` class: INIT_ONLY fields (red - critical)115- `gap` class: INIT_PRESERVE fields (yellow - warning)116- `phase` class: MUTABLE fields (purple)117- `handler` class: APPEND_ONLY fields (orange)118- `stateNode` class: Validation gates119- `output` class: State wrapper/accessor120- `cli` class: Resume detection tiers121122### Step 5: Write Output123124Write the diagram to: `temp/arch-lens-state-lifecycle/arch_diag_state_lifecycle_{YYYY-MM-DD_HHMMSS}.md`125126---127128## Output Template129130```markdown131# State Lifecycle Diagram: {System Name}132133**Lens:** State Lifecycle (Contract Overlay)134**Question:** How is state corruption prevented?135**Date:** {YYYY-MM-DD}136**Scope:** {What was analyzed}137138## Field Lifecycle Categories139140| Category | Description | Example Fields |141|----------|-------------|----------------|142| INIT_ONLY | Never modify after init | {fields} |143| INIT_PRESERVE | Keep on resume | {fields} |144| MUTABLE | Free to change | {fields} |145| APPEND_ONLY | Can only grow | {fields} |146147## State Lifecycle Diagram148149```mermaid150%%{init: {'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60, 'curve': 'basis'}}}%%151flowchart TB152 %% CLASS DEFINITIONS %%153 classDef cli fill:#1a237e,stroke:#7986cb,stroke-width:2px,color:#fff;154 classDef stateNode fill:#004d40,stroke:#4db6ac,stroke-width:2px,color:#fff;155 classDef handler fill:#e65100,stroke:#ffb74d,stroke-width:2px,color:#fff;156 classDef phase fill:#6a1b9a,stroke:#ba68c8,stroke-width:2px,color:#fff;157 classDef detector fill:#b71c1c,stroke:#ef5350,stroke-width:2px,color:#fff;158 classDef output fill:#00695c,stroke:#4db6ac,stroke-width:2px,color:#fff;159 classDef gap fill:#ff6f00,stroke:#ffa726,stroke-width:2px,color:#000;160161 subgraph Lifecycles ["FIELD LIFECYCLE CATEGORIES"]162 direction TB163 INIT_ONLY["INIT_ONLY<br/>━━━━━━━━━━<br/>id, request_id<br/>NEVER modify"]164 INIT_PRESERVE["INIT_PRESERVE<br/>━━━━━━━━━━<br/>is_resuming<br/>Keep on resume"]165 MUTABLE["MUTABLE<br/>━━━━━━━━━━<br/>current_state<br/>Freely change"]166 APPEND_ONLY["APPEND_ONLY<br/>━━━━━━━━━━<br/>errors, history<br/>Only grow"]167 end168169 subgraph Gates ["VALIDATION GATES"]170 direction TB171 GATE1["validate_required<br/>━━━━━━━━━━<br/>FAIL-FAST"]172 GATE2["validate_lifecycle<br/>━━━━━━━━━━<br/>Contract check"]173 GATE3["resume_safety<br/>━━━━━━━━━━<br/>Preserve check"]174 end175176 subgraph Wrapper ["STATE WRAPPER"]177 direction TB178 ACCESSOR["StateAccessor<br/>━━━━━━━━━━<br/>Tracks mutations"]179 MERGE["Merge Updates<br/>━━━━━━━━━━<br/>Auto-include"]180 end181182 subgraph Resume ["RESUME DETECTION"]183 direction TB184 TIER1["Tier 1: Explicit<br/>━━━━━━━━━━<br/>flag=true"]185 TIER2["Tier 2: Heuristic<br/>━━━━━━━━━━<br/>State exists"]186 TIER3["Tier 3: Fresh<br/>━━━━━━━━━━<br/>No indicators"]187 end188189 %% FLOW %%190 INIT_ONLY --> GATE1191 INIT_PRESERVE --> GATE2192 MUTABLE --> GATE2193 APPEND_ONLY --> GATE2194195 GATE1 --> GATE2196 GATE2 --> GATE3197 GATE3 --> ACCESSOR198 ACCESSOR --> MERGE199200 MERGE --> TIER1201 TIER1 --> TIER2202 TIER2 --> TIER3203204 %% CLASS ASSIGNMENTS %%205 class INIT_ONLY detector;206 class INIT_PRESERVE gap;207 class MUTABLE phase;208 class APPEND_ONLY handler;209 class GATE1,GATE2,GATE3 stateNode;210 class ACCESSOR,MERGE output;211 class TIER1,TIER2,TIER3 cli;212```213214**Color Legend:**215| Color | Category | Description |216|-------|----------|-------------|217| Red | INIT_ONLY | Never modify (critical) |218| Yellow | INIT_PRESERVE | Preserved on resume |219| Purple | MUTABLE | Freely modifiable |220| Orange | APPEND_ONLY | Can only grow |221| Teal | Gates | Validation gates |222| Dark Teal | Wrapper | State mutation mechanism |223| Dark Blue | Detection | Resume detection tiers |224225## State Lifecycle Contract Rules226227| Lifecycle | Fresh Start | Resume | Violation Detection |228|-----------|-------------|--------|---------------------|229| INIT_ONLY | Cannot modify | Cannot modify | {detection} |230| INIT_PRESERVE | Can modify | Cannot modify | {detection} |231| MUTABLE | Can modify | Can modify | Never fails |232| APPEND_ONLY | Can append | Can append | {detection} |233234## Resume Detection Strategy235236| Tier | Check | Result |237|------|-------|--------|238| 1 | Explicit flag | {what happens} |239| 2 | Heuristic | {what happens} |240| 3 | Fresh start | {what happens} |241```242243---244245## Pre-Diagram Checklist246247Before creating the diagram, verify:248249- [ ] LOADED `/mermaid` skill using the Skill tool250- [ ] Using ONLY classDef styles from the mermaid skill (no invented colors)251- [ ] Diagram will include a color legend table252253---254255## Related Skills256257- `/make-arch-diag` - Parent skill for lens selection258- `/mermaid` - MUST BE LOADED before creating diagram259- `/arch-lens-process-flow` - For state machine view260- `/arch-lens-error-resilience` - For validation failure handling