Step 0: Have I completed Phase 0 (Git Safety)? If not, STOP and do it now.

• Did I check git status --porcelain?
• Did I offer to commit uncommitted changes?
• Did I offer worktree isolation (ALWAYS, even if no uncommitted changes)?

Step 1: What phase am I in? (git safety, scope selection, extraction, triage, verification, reporting, implementation)

Step 2: For verification - what EXACTLY am I checking usage of?

Step 3: What evidence would PROVE this item is used?

Step 4: What evidence would PROVE this item is dead?

Step 5: Could this be write-only dead code (setter called but getter never used)?

Step 6: Could this be transitive dead code (only used by dead code)?

Step 7: Have I checked ALL files for callers, not just nearby files?

Step 8: If claiming test results, have I ACTUALLY run the tests?

Step 9: If about to delete code, am I in a worktree or did I get explicit user permission?

Now proceed with confidence following this checklist to achieve outstanding results.

Finding Dead Code Workflow

Phase 0: Git Safety

ALWAYS check git state before any analysis. Dead code verification involves code deletion - protect user's work.

CRITICAL: This phase is MANDATORY before ANY dead code analysis, especially "remove and test" verification which involves deleting code.

Step 1: Check for uncommitted changes

git status --porcelain

If output is non-empty:

• Present to user: "You have uncommitted changes. Should I commit them first?"
• Options:
  • Yes - Ask for commit message and create commit
  • No, proceed anyway - Continue but warn about risks
  • Abort - Stop the analysis

If Yes selected:

# Show what will be committed
git status

# Ask user for commit message
# Create commit
git add .
git commit -m "[user-provided message]"

Step 2: Worktree decision

ALWAYS ask about worktree, regardless of uncommitted changes status. This protects the user's main branch from experimental deletions.

Present to user: "Should I use a git worktree for dead code hunting? (Recommended)"

Explanation: "A worktree creates an isolated branch where I can safely delete code to test. Your main branch stays completely untouched. At the end, you can review the findings and decide what to apply."

Options:

• Yes, create worktree (Recommended) - Invoke using-git-worktrees skill
• No, work in current directory - Warn about risks for remove-and-test operations

If worktree selected:

1. Create branch: dead-code-hunt-YYYY-MM-DD-HHMM
2. All "remove and test" operations happen in worktree
3. Final report generated with findings
4. User decides what to apply to main branch
5. Worktree can be deleted after review

If worktree declined:

• Warning: "Working directly in your current directory. Any 'remove and test' verification will modify your working files. I will ask for explicit confirmation before each deletion."
• Continue with extra caution
• Require explicit approval before ANY file modifications

Step 3: Proceed to scope selection

Only after git safety is confirmed, proceed to Phase 1.

Phase 1: Scope Selection

ALWAYS ask user to select scope before extracting any code items.

Use AskUserQuestion with these options:

After selection, identify the target files using:

• Branch: git diff $(git merge-base HEAD main)...HEAD --diff-filter=AM --name-only
• Uncommitted: git diff --diff-filter=AM --name-only + git diff --cached --diff-filter=AM --name-only
• Specific: User-provided paths
• Full repo: All code files matching language patterns

ARH Response Processing for Scope Selection

After presenting scope options, process user response:

1. Detect response type using ARH patterns from ~/.local/spellbook/patterns/adaptive-response-handler.md
2. Handle by type:
   • DIRECT_ANSWER (A/B/C/D): Apply scope selection, proceed to extraction
   • RESEARCH_REQUEST ("can you check what changed"): Show git diff summary, re-ask
   • UNKNOWN ("not sure what to analyze"): Show recent git activity, recommend scope
   • CLARIFICATION ("what's the difference between A and B?"): Explain with examples
   • SKIP: Use default scope (Branch changes)

Example:

Question: "What scope should I analyze? A/B/C/D"
User: "Not sure, can you show me what changed recently?"

ARH Processing:
→ Detect: RESEARCH_REQUEST
→ Action: Run git status and git log --oneline -10
→ Show summary: "You have 3 uncommitted files and 5 commits on this branch"
→ Regenerate: "Found 3 uncommitted files and 5 commits on branch. Should I analyze:
   A) Both uncommitted + branch commits (comprehensive)
   B) Just uncommitted files (faster)
   C) Just branch commits (exclude work in progress)"

Phase 2: Code Item Extraction

Extract ALL added code items from scoped files.

What to Extract

Language-Specific Patterns

Nim:

# Extract these patterns from added lines
proc|func|method|macro|template|iterator NAME
type NAME = (object|enum|distinct|...)
field: TYPE in object definitions
import|from|include MODULE
const|let|var NAME at top level

Python:

def NAME, class NAME, import/from statements

TypeScript/JavaScript:

function NAME, class NAME, const/let/var at top level
export/import statements

Extraction Strategy

For each added/modified file in scope:

1. Get the diff of added lines: git diff <base> <file> | grep "^+"
2. Parse added lines for code item declarations
3. Record: {type, name, location, signature}
4. Group symmetric pairs (get/set, create/destroy, etc.)
5. For each setter/store call: Record corresponding getter/read pattern to check later
6. For each field assignment: Record field read patterns to check later
7. For each collection store: Record collection access patterns to check later (seq.add → iterator, table[x] = → table[x] read)

Phase 3: Initial Triage

Present ALL extracted items upfront before verification begins. User must see full scope.

Display items grouped by type with counts:

## Code Items Found: 47

### Procedures/Functions (23 items)
1. proc getDeferredExpr(t: PType): PNode - compiler/semtypes.nim:342
2. proc setDeferredExpr(t: PType, n: PNode) - compiler/semtypes.nim:349
3. proc clearDeferredExpr(t: PType) - compiler/semtypes.nim:356
...

### Type Fields (12 items)
24. deferredPragmas: seq[PNode] - compiler/ast.nim:234
25. sizeExpr: PNode - compiler/ast.nim:235
26. alignExpr: PNode - compiler/ast.nim:236
...

### Imports (5 items)
37. import compiler/injectdestructors - compiler/semtypes.nim:23
...

### Symmetric Pairs Detected (4 groups)
Group A: getDeferredExpr / setDeferredExpr / clearDeferredExpr
Group B: sizeExpr / sizeExpr= (getter/setter)
Group C: alignExpr / alignExpr= (getter/setter)
Group D: importcExpr / importcExpr= (getter/setter)

Proceed with verification? (yes/no)

Detection Heuristics

Symmetric Pairs: If you see getFoo / setFoo / clearFoo, or foo / foo=, group them. They often live or die together.

Convenience Wrappers: If a proc just calls another proc with minor changes, mark as potential wrapper.

Phase 4: Verification

For EVERY code item, search the ENTIRE codebase for usages. Start from "dead" assumption.

Verification Protocol

For each extracted item, follow this process:

Step 1: Generate "Dead Code" Claim

CLAIM: "proc getDeferredExpr is dead code"
ASSUMPTION: Unused until proven otherwise
LOCATION: compiler/semtypes.nim:342

Step 2: Search for Usage Evidence

Search Strategy:

1. Direct calls: grep -rn "getDeferredExpr" --include="*.nim" <repo_root>
2. Exclude definition: Filter out the line where it's defined
3. Check callers: Are there calls outside the definition?
4. Check exports: Is it exported and could be used externally?

Evidence Categories:

Step 3: Write-Only Dead Code Detection

Check for code that STORES values but the stored values are NEVER READ:

Patterns:

1. Setter without getter: setFoo() has callers but getFoo() has zero callers
2. Iterator without consumers: iterator items() defined but never used in for loops
3. Field assigned but never read: Field appears on LHS of = but never on RHS
4. Collection stored but never accessed: seq.add(x) called but seq never iterated

Example:

sym.setDeferredExpr(word, expr)  # Called 3 times
# But:
iterator deferredPragmas(): PNode  # ZERO callers
# → Write-only dead code: data is stored but never consumed

Algorithm:

1. For each setter/store found, search for corresponding getter/read
2. If setter has callers but getter has zero → WRITE-ONLY DEAD
3. Mark BOTH setter and getter as dead (entire feature unused)

Step 4: Transitive Dead Code Detection

If an item is only called by other items, check if ALL callers are dead:

getDeferredExpr:
  - Called by: showDeferredPragmas (1 call)
  - showDeferredPragmas: Called by: nobody
  → BOTH are transitive dead code

Algorithm:

1. Build call graph from search results
2. For each "maybe alive" item, check if all callers are dead
3. If yes, mark as transitive dead
4. Repeat until no new transitive dead code found

Step 5: "Remove and Test" Verification (Optional)

For high-confidence dead code, offer experimental verification:

Protocol:

1. Ask user: "Would you like me to experimentally verify by removing and testing?"
2. If yes, create a temporary git worktree or branch
3. Remove the suspected dead code
4. Run the test suite
5. If tests pass → definitive proof code was dead
6. If tests fail → code was used (or tests are incomplete)
7. Restore original state

When to offer:

• User is uncertain about grep-based verdict
• Code looks "important" but has zero callers
• High-value cleanup (large amount of code)

Step 6: Symmetric Pair Analysis

For detected symmetric pairs:

If ANY of {getFoo, setFoo, clearFoo} is ALIVE → all are potentially alive
If ALL are dead → entire group is dead
If SOME are alive, SOME dead → flag asymmetry for user review

Example from context:

• getDeferredExpr: 0 callers → DEAD
• setDeferredExpr: 3 callers → ALIVE
• clearDeferredExpr: 1 caller → ALIVE
• Verdict: getDeferredExpr is dead, rest alive (asymmetric API)

Phase 5: Iterative Re-scanning

After identifying dead code, re-scan for newly orphaned code. Removal may cascade.

Why Re-scan: After marking code as dead, other code may become orphaned:

Round 1: evaluateDeferredFieldPragmas → 0 callers → DEAD
Round 2: sym.deferredPragmas iterator → only called by evaluateDeferredFieldPragmas → NOW DEAD (transitive)
Round 3: sym.setDeferredExpr → only stores to deferredPragmas, which is never read → NOW WRITE-ONLY DEAD

Re-scan Algorithm:

1. Mark initial dead code (zero callers)
2. Re-extract all code items, excluding already-marked-dead code
3. Re-run verification on remaining items
4. Check for newly transitive dead code
5. Check for newly write-only dead code (getter removed → setter now orphaned)
6. Repeat until no new dead code found (fixed point)

Cascade Detection:

• If removal of A makes B dead → note "B depends on A" in report
• Present cascade chains: "Removing X enables removing Y, Z"
• Helps user understand impact

Phase 6: Report Generation

Generate markdown report that serves as both audit and implementation plan.

Report Structure

# Dead Code Report

**Generated:** 2025-12-30T18:00:00Z
**Scope:** Branch feature/generic-deferred-pragmas (2 commits since devel)
**Items Analyzed:** 47
**Dead Code Found:** 8 | **Alive:** 37 | **Transitive Dead:** 2

## Summary

| Category | Dead | Alive | Notes |
|----------|------|-------|-------|
| Procedures | 5 | 18 | 2 transitive dead |
| Type Fields | 3 | 9 | 3-field symmetric group all dead |
| Imports | 0 | 5 | All used |

## Dead Code Findings

### High Confidence (Zero Callers)

#### 1. proc getDeferredExpr - DEAD
- **Location:** compiler/semtypes.nim:342
- **Evidence:** Zero callers in codebase
- **Search:** `grep -rn "getDeferredExpr"` → only definition found
- **Symmetric Pair:** Part of get/set/clear group; set/clear ARE used
- **Verdict:** Asymmetric API, getter never needed
- **Removal Complexity:** Simple - delete proc
- **Remove and Test:** ✓ Offered, tests passed after removal (if applicable)

#### 2. sizeExpr field + accessors - DEAD (Write-Only)
- **Location:** compiler/ast.nim:235, semtypes.nim:380-387
- **Evidence:** Field and both accessors have zero callers
- **Search:** `grep -rn "sizeExpr"` → only definitions found
- **Symmetric Group:** sizeExpr / sizeExpr= both dead
- **Write-Only Check:** Setter never called, getter never called → entire feature unused
- **Verdict:** Entire feature unused
- **Removal Complexity:** Medium - delete field + 2 procs

### Transitive Dead Code

#### 3. proc showDeferredPragmas - TRANSITIVE DEAD
- **Location:** compiler/debug.nim:123
- **Evidence:** Only called by `dumpTypeInfo`, which is itself dead
- **Call Chain:** showDeferredPragmas ← dumpTypeInfo ← nobody
- **Cascade:** Removing dumpTypeInfo orphaned this proc (found in Round 2 re-scan)
- **Verdict:** Dead because caller is dead
- **Removal Complexity:** Simple - delete both procs

### Write-Only Dead Code

#### 4. iterator deferredPragmas - WRITE-ONLY DEAD
- **Location:** compiler/ast.nim:456
- **Evidence:** setDeferredExpr called 3 times, but iterator has ZERO callers
- **Write-Only Pattern:** Data is stored but never read
- **Cascade:** Removing evaluateDeferredFieldPragmas made this detectable (Round 2 re-scan)
- **Verdict:** Entire deferred pragma storage feature is dead
- **Removal Complexity:** High - delete iterator + setter + field + all call sites to setter

## Alive Code (Verified Necessary)

### Definitely Used

#### 1. proc setDeferredExpr - ALIVE
- **Location:** compiler/semtypes.nim:349
- **Evidence:** 3 callers found
- **Callers:**
  - compiler/semtypes.nim:567 (in semGenericType)
  - compiler/semtypes.nim:789 (in semTypeNode)
  - compiler/pragmas.nim:234 (in processPragmas)
- **Verdict:** Necessary

#### 2. iterator deferredPragmas - ALIVE
- **Location:** compiler/ast.nim:456
- **Evidence:** 2 call sites
- **Callers:**
  - compiler/semtypes.nim:678
  - compiler/codegen.nim:123
- **Verdict:** Core feature

## Implementation Plan

This report doubles as an implementation plan. Work through items in order.

### Phase 1: Simple Deletions (Low Risk)
1. [ ] Delete `getDeferredExpr` proc (line 342)
2. [ ] Delete `importcExpr` field (line 237)
3. [ ] Delete `importcExpr=` setter (line 395)
4. [ ] Delete `importcExpr` getter (line 388)

### Phase 2: Symmetric Group Deletions
5. [ ] Delete `alignExpr` field (line 236)
6. [ ] Delete `alignExpr=` setter (line 387)
7. [ ] Delete `alignExpr` getter (line 380)
8. [ ] Delete `sizeExpr` field (line 235)
9. [ ] Delete `sizeExpr=` setter (line 393)
10. [ ] Delete `sizeExpr` getter (line 386)

### Phase 3: Transitive Deletions
11. [ ] Delete `showDeferredPragmas` proc (line 123)
12. [ ] Delete `dumpTypeInfo` proc (line 98)

### Verification Commands

After each deletion, verify no references remain:
```bash
# Example for getDeferredExpr
grep -rn "getDeferredExpr" compiler/ tests/
# Should return: no results

# Run tests to ensure nothing broke
nim c -r tests/all.nim
# CRITICAL: Actually run this command and paste output
# DO NOT claim "tests pass" without running them

Re-scan After Deletions

After Phase 1 deletions, re-run dead code detection:

# May reveal newly orphaned code
# Example: Removing getter may orphan setter

Risk Assessment

Next Steps

Would you like me to: A. Implement all deletions automatically (using writing-plans pattern) B. Implement deletions one-by-one with approval C. Generate a git branch with deletions for you to review D. Just keep this report for manual implementation

---

## Phase 7: Implementation Prompt

After presenting the report, ask:

Found 8 dead code items in this branch. They account for N lines.

Would you like me to: A. Remove all dead code automatically (I'll create commits) B. Remove items one-by-one with your approval C. Create a cleanup branch you can review D. Just keep the report, you'll handle it

Choose A/B/C/D:

### ARH Response Processing for Implementation Decision

**After presenting implementation options, process user response:**

1. **Detect response type** using ARH patterns from `~/.local/spellbook/patterns/adaptive-response-handler.md`
2. **Handle by type:**
   - **DIRECT_ANSWER (A/B/C/D):** Execute chosen implementation strategy
   - **RESEARCH_REQUEST ("can you verify X is really unused?"):** Re-run usage search for specific item
   - **UNKNOWN ("not sure if safe to delete"):** Show test coverage, offer remove-and-test
   - **CLARIFICATION ("what's difference between A and B?"):** Explain strategies with examples
   - **SKIP:** Save report only (option D)

**Example:**

Question: "Remove all dead code automatically (A) or one-by-one (B)?" User: "Not sure if it's safe to delete getDeferredExpr, can you double check?"

ARH Processing: → Detect: UNKNOWN + RESEARCH_REQUEST → Action: Re-run comprehensive search for getDeferredExpr grep -rn "getDeferredExpr" . --include=".nim" --include=".nimble" grep -rn "deferred.expr" . -i --include=".nim" # Check variations → Return: "Confirmed: 0 references found in code, tests, or configs" → Regenerate: "Verified getDeferredExpr has no references (checked variations). Safe to delete. Should I: A) Remove all items including this (automated) B) Show each item before deletion (manual approval) C) Create branch for your review first"

### Implementation Strategy (if user chooses A or B)

Follow the writing-plans skill pattern:

1. **Create implementation plan** (already in report)
2. **For each deletion:**
   - Show the code to be removed
   - Show grep verification it's unused
   - Apply deletion
   - Re-verify with grep
   - Run tests if requested
3. **Create commit** after each logical group
4. **Final verification:** Run full test suite

---

## Detection Patterns (What Would Have Caught Our Example)

### Pattern 1: Asymmetric Symmetric API

IF getFoo exists AND setFoo exists AND clearFoo exists: Check usage of each independently IF any has zero callers → flag as dead EVEN IF others in group are used

### Pattern 2: Convenience Wrapper

IF proc foo() only calls bar() with minor transform: Check if foo has callers IF zero callers → dead wrapper EVEN IF bar() is heavily used

### Pattern 3: Transitive Dead Code

WHILE changes detected: FOR each item with callers: IF ALL callers are marked dead: Mark item as transitive dead

### Pattern 4: Field + Accessors

IF field X detected: Search for getter getX or X Search for setter setX or X= IF all three have zero usage → dead feature

### Pattern 5: Test-Only Usage

IF all callers are in test files: ASK user if test-only code should be kept Don't auto-mark as dead

### Pattern 6: Write-Only Dead Code

FOR each setter/store S with corresponding getter/read G: IF S has callers AND G has zero callers: Mark BOTH S and G as write-only dead Mark data is "stored but never read" Example: setFoo() called, but getFoo() never called

### Pattern 7: Iterator Without Consumers

IF iterator I defined: Search for "for .* in I" or "items(I)" patterns IF zero consumers found: Mark iterator as dead Check if iterator's backing storage is also write-only dead

---

<FORBIDDEN pattern="1">
### Marking Code as "Used" Without Evidence
- Assuming code is used because it "looks important"
- Marking as alive because "it might be called dynamically"
- Skipping verification because "it's probably needed"

**Reality**: Every item needs grep proof of callers or it's dead.
</FORBIDDEN>

<FORBIDDEN pattern="2">
### Incomplete Search
- Only searching nearby files
- Only searching same directory
- Not checking test directories
- Not checking if it's exported

**Reality**: Search the ENTIRE codebase, including tests.
</FORBIDDEN>

<FORBIDDEN pattern="3">
### Ignoring Transitive Dead Code
- Marking code as "used" because something calls it
- Not checking if the caller is itself dead
- Stopping after first-level verification

**Reality**: Build the call graph, check transitivity.
</FORBIDDEN>

<FORBIDDEN pattern="4">
### Deleting Without User Approval
- Auto-removing code without showing the plan
- Batch-deleting without per-item verification
- Not offering user choice in implementation

**Reality**: Present report, get approval, then implement.
</FORBIDDEN>

<FORBIDDEN pattern="5">
### Claiming Test Results Without Running Tests
- Stating "tests fail" without actually running the test command
- Claiming code "doesn't work" without execution evidence
- Making assertions about runtime behavior from static analysis alone
- Saying "tests pass" after removal without running them

**Reality**: Run the actual command. Paste the actual output. Evidence over confidence.
</FORBIDDEN>

<FORBIDDEN pattern="6">
### Missing Write-Only Dead Code
- Only checking if code is called, not if stored data is read
- Not verifying that iterator/getter counterparts exist for setter/store operations
- Assuming "something calls it" means "code is used"

**Reality**: Check the full data flow. Code that stores without reading is dead.
</FORBIDDEN>

<FORBIDDEN pattern="7">
### Single-Pass Verification
- Marking code as "alive" or "dead" in one pass
- Not re-scanning after identifying dead code
- Missing cascade effects where removal orphans other code

**Reality**: Re-scan iteratively until no new dead code found (fixed point).
</FORBIDDEN>

<FORBIDDEN pattern="8">
### Deleting Code Without Git Safety
- Running "remove and test" verification without checking git status first
- Deleting code in user's working directory without worktree isolation
- Not offering to commit uncommitted changes before destructive operations
- Skipping worktree recommendation for experimental deletions

**Reality**: ALWAYS check git status in Phase 0. ALWAYS offer worktree isolation for remove-and-test. NEVER delete code without explicit git safety protocol.
</FORBIDDEN>

---

<EXAMPLE type="complete">
## Complete Dead Code Detection Example

**User**: "Find dead code in my current branch"

**Step 0 - Git Safety**:
```bash
# Check git status
git status --porcelain

Agent: "I see you have uncommitted changes in 2 files:

• compiler/ast.nim (modified)
• tests/test_pragmas.nim (new file)

Should I commit these changes first? This ensures we have a clean state before analyzing dead code.

Options: A. Yes, commit them (I'll ask for a commit message) B. No, proceed anyway (risky if we do remove-and-test verification) C. Abort the analysis"

User: A

Agent: "What commit message should I use?"

User: "WIP: deferred pragma implementation"

git add .
git commit -m "WIP: deferred pragma implementation"

Agent: "Committed! Now, should I use a git worktree for dead code hunting?

This is recommended because:

• Creates an isolated branch (dead-code-hunt-2025-12-30-1430)
• All 'remove and test' operations happen there
• Your current branch stays completely untouched
• You review findings and decide what to apply

Options: A. Yes, create worktree (Recommended) B. No, work in current directory (I'll ask before each deletion)

Choose A or B:"

User: A

Agent: "Creating worktree..."

# Worktree creation via using-git-worktrees skill

"Worktree created at ../nim-dead-code-hunt. All analysis and testing will happen there."

Step 1 - Scope Selection:

I'll help you find dead code. First, let me confirm the scope:

What should I analyze?
A. Branch changes (all code added since merge-base with devel) [Recommended]
B. Uncommitted changes only (staged + unstaged)
C. Specific files (you provide paths)
D. Full repository (use carefully)

User selects: A

Step 2 - Extraction:

Analyzing branch feature/generic-deferred-pragmas (2 commits since devel)...

Extracting code items from 3 modified files:
- compiler/ast.nim
- compiler/semtypes.nim
- compiler/pragmas.nim

Step 3 - Triage:

## Code Items Found: 12

### Procedures (7 items)
1. proc getDeferredExpr(t: PType): PNode - semtypes.nim:342
2. proc setDeferredExpr(t: PType, n: PNode) - semtypes.nim:349
3. proc clearDeferredExpr(t: PType) - semtypes.nim:356
4. proc `sizeExpr=`(t: PType, n: PNode) - semtypes.nim:380
5. proc sizeExpr(t: PType): PNode - semtypes.nim:386
6. proc `alignExpr=`(t: PType, n: PNode) - semtypes.nim:387
7. proc alignExpr(t: PType): PNode - semtypes.nim:393

### Type Fields (4 items)
8. deferredPragmas: seq[PNode] - ast.nim:234
9. sizeExpr: PNode - ast.nim:235
10. alignExpr: PNode - ast.nim:236
11. importcExpr: PNode - ast.nim:237

### Iterators (1 item)
12. iterator deferredPragmas(t: PType): PNode - ast.nim:456

### Symmetric Pairs Detected
- Group A: getDeferredExpr / setDeferredExpr / clearDeferredExpr
- Group B: sizeExpr / sizeExpr=
- Group C: alignExpr / alignExpr=

Proceed with verification? (yes)

Step 4 - Verification (showing two items with different patterns):

Item 1: proc getDeferredExpr

• Claim: "getDeferredExpr is dead code"
• Search: grep -rn "getDeferredExpr" compiler/ tests/
• Results:

  compiler/semtypes.nim:342:proc getDeferredExpr(t: PType): PNode =
  

  (only the definition)
• Callers: ZERO
• Symmetric Pair Check: setDeferredExpr has 3 callers, clearDeferredExpr has 1 caller
• Verdict: DEAD - Getter never needed, only set/clear used

Item 8: iterator deferredPragmas

• Claim: "deferredPragmas iterator is dead code"
• Search: grep -rn "deferredPragmas" compiler/ tests/
• Results:

  compiler/ast.nim:456:iterator deferredPragmas(t: PType): PNode =
  compiler/ast.nim:234:  deferredPragmas: seq[PNode]
  compiler/semtypes.nim:567:  sym.setDeferredExpr(word, expr)  # stores to deferredPragmas field
  

• Write-Only Check: setDeferredExpr stores data to deferredPragmas field, but iterator has ZERO callers
• Callers: ZERO for iterator
• Data Flow: Data is STORED but NEVER READ
• Verdict: WRITE-ONLY DEAD - Entire feature is unused

Step 5 - Iterative Re-scan (after Round 1):

After marking getDeferredExpr as dead, re-scan remaining code:

Round 2 discoveries:

• iterator deferredPragmas → NOW detectable as write-only (setter called, iterator unused)
• proc evaluateDeferredFieldPragmas → Transitive dead (only called by removed code)

Round 3 discoveries:

• setDeferredExpr → NOW detectable as write-only dead (stores to iterator that's dead)

No new dead code found → Fixed point reached

Step 6 - Remove and Test Verification (optional):

User: "I'm not sure about deferredPragmas, it looks important"

Agent: "I understand. Let me experimentally verify by removing it and running tests:

# Create temporary branch
git checkout -b verify-dead-code-temp

# Remove deferredPragmas iterator and related code
# ... (edits made) ...

# Run tests
nim c -r tests/all.nim

Test output:

[TEST] Running 1247 tests...
[PASS] All tests passed in 23.4s

Tests passed! This confirms deferredPragmas was dead code. The iterator was never consumed. Restoring original state..."

Step 7 - Implementation Prompt:

Found 4 dead code items accounting for approximately 35 lines:
- 1 unused getter (getDeferredExpr)
- 1 write-only iterator (deferredPragmas)
- 2 transitive dead items (found in re-scan)

Would you like me to:
A. Remove all dead code automatically
B. Remove items one-by-one with approval
C. Create a cleanup branch for review
D. Just keep the report

Choose A/B/C/D: