Harden

Guard types:

• None/empty checks
• Type constraints
• Value ranges (positive, non-negative, etc.)
• Length constraints

Step 3: Add debug_log() calls at decision points

debug_log(f"process_videos: videos_count={len(videos)}, estimated_total={estimated_total}")

if not videos:
    debug_log(f"process_videos: empty_videos - returning")
    return []

for video in videos:
    debug_log(f"process_videos: processing video_id={video.get('video_id')}")

Log at:

• Function entry (parameters received)
• Before conditional branches
• Loop iterations (key progress points)
• Early returns or breaks
• Error paths

Step 4: Add guard failure logging

Wrap assertions with logging for better debugging:

# Parameter validation with logging
if videos is None:
    debug_log(f"process_videos: guard_failure - videos is None")
    assert False, "videos cannot be None"

if not isinstance(videos, list):
    debug_log(f"process_videos: guard_failure - wrong_type videos={type(videos)}")
    assert False, f"videos must be list, got {type(videos)}"

Step 5: Complexity check (inline)

After hardening, run quick complexity check:

radon cc <file> -a -s

When to use

• Function receives external/untrusted input
• Need to enforce preconditions
• Defensive programming for public APIs
• After bug caused by invalid input
• Investigating issues with unclear control flow

Integration

After hardening, the system will suggest:

• /debug - Full debug workflow if issues persist

Verification

After hardening:

1. Run tests to ensure guards don't break valid inputs
2. Test with invalid inputs to verify guards trigger
3. Check debug_log output shows proper context
4. Verify complexity hasn't increased significantly