Problem Solved: Fear of Breaking Things

❌ Without Boundaries

  • ✗ Fear of modifying critical files
  • ✗ Accidental changes to unrelated code
  • ✗ Difficult to track what changed
  • ✗ No safety net for experiments
  • ✗ One mistake can break everything

✓ With Smart Boundaries

  • ✓ Only approved files can be modified
  • ✓ Clear visual scope boundaries
  • ✓ Change tracking within scope
  • ✓ Safe experimentation zone
  • ✓ Preview before applying changes
🎯

Scope Management

Define exactly which files can be modified. Add protected files like .env, config files, or critical systems that should never be touched.

🚀 Try It Yourself

Protect critical files while allowing work on specific components:

/siftcoder:scope add .env /siftcoder:scope add config/

Now run any command. These files will be protected from modification.

Typical Workflow
  1. /siftcoder:scope add .env config/ - Protect critical files
  2. /siftcoder:fix "Update user authentication" - Fix a bug safely
  3. /siftcoder:scope - Verify what's protected
  4. /siftcoder:scope remove config/ - Allow config changes when needed
💥

Blast Radius Validation

Before making changes, see exactly what will be affected. Validate the impact radius to prevent unintended consequences.

🚀 Try It Yourself

Check what a change will affect before running it:

/siftcoder:blast-radius "Fix login bug"

See all files, functions, and dependencies that will be impacted.

Safety Check Workflow
  1. /siftcoder:blast-radius "Add user profile feature" - Check impact
  2. Review the list of affected files and dependencies
  3. /siftcoder:scope add [critical files] - Protect anything sensitive
  4. /siftcoder:add-feature "Add user profile" - Make changes safely
🔄

Checkpoints & Rollback

Save named checkpoints before making changes. Roll back instantly if anything goes wrong. Experiment freely.

🚀 Try It Yourself

Create checkpoints before risky changes:

/siftcoder:checkpoint save "before-refactor" /siftcoder:checkpoint restore "before-refactor"

Safe to experiment - you can always roll back.

Experimental Workflow
  1. /siftcoder:checkpoint save "stable" - Save working state
  2. /siftcoder:fix "Try new approach" - Make experimental changes
  3. Test the changes
  4. /siftcoder:checkpoint restore "stable" - Rollback if needed
👁️

Preview Changes

See exactly what will change before applying it. Review diffs, understand the impact, then approve.

🚀 Try It Yourself

Preview changes before they're applied:

/siftcoder:preview

Shows full diff of what will change. Approve or reject.

Safe Approval Workflow
  1. /siftcoder:fix "Update API endpoint" - Trigger changes
  2. /siftcoder:preview - See what will change
  3. Review the diff carefully
  4. Approve or reject the changes

Frequently Asked Questions

What's the difference between Scope and Blast Radius? ▼

Scope actively protects files from being modified - it's a whitelist/blacklist system. Blast Radius is a diagnostic tool that shows you what WILL be affected by a change before you make it. Use Blast Radius first to understand impact, then use Scope to protect anything you don't want changed.

How many checkpoints can I create? ▼

Unlimited! Each checkpoint stores the full session state, including all context and conversation history. However, checkpoints do consume storage space. A typical checkpoint is 50-200KB depending on your session size.

Can I preview changes before autonomous workflows? ▼

Yes! The /siftcoder:preview command shows you exactly what will change. For autonomous workflows like BUILD or MAINTAIN, you can use /siftcoder:pause at any time to pause the workflow, then use preview to see what's been done, and /siftcoder:continue when ready.

What happens if I try to modify a protected file? ▼

The system will block the modification and notify you that the file is protected. You'll need to explicitly remove it from scope using /siftcoder:scope remove [file] before modifying it. This prevents accidental changes to critical files like .env or configuration files.

Are checkpoints shared across sessions? ▼

Yes! Checkpoints persist across sessions. You can save a checkpoint in one session and restore it in a later session. This is perfect for branching experiments - save a checkpoint, try something, if it doesn't work out, restore and try a different approach.