@W-21461342 Adding Configurable safety levels

[charithaT07]

Summary

Brief description of what this PR does.

Summary

Adds configurable safety levels to protect against accidental destructive operations. Safety levels provide HTTP-layer protection via the SFCC_SAFETY_LEVEL environment variable that cannot be bypassed by CLI
flags or config files.

Safety Levels

NONE (default)

• No restrictions
• Blocks: Nothing

NO_DELETE

• Prevent deletions only
• Blocks: DELETE operations

NO_UPDATE

• Prevent destructive changes
• Blocks: DELETE + destructive POST (reset/stop/restart)

READ_ONLY

• Investigation/audit mode
• Blocks: All write operations (POST/PUT/PATCH/DELETE)

Usage

Block accidental deletions

export SFCC_SAFETY_LEVEL=NO_DELETE
b2c ods sandbox delete prod-sandbox # ❌ Blocked

Read-only mode for investigation

export SFCC_SAFETY_LEVEL=READ_ONLY
b2c ods sandbox list # ✅ Allowed
b2c mrt push # ❌ Blocked

Why Environment Variables?

Uses process.env exclusively for security:

• ✅ Cannot be bypassed by CLI flags
• ✅ Cannot be bypassed by config files
• ✅ LLMs cannot modify parent shell environment
• ✅ Immutable at runtime

Changes

• New safety module with 4 protection levels
• HTTP middleware that intercepts all API requests
• 137 unit tests with 99.34% coverage
• 25 CLI commands updated with safety warnings
• Documentation with CI/CD examples

Works across all HTTP clients (ODS, MRT, OCAPI, SCAPI, eCDN, SLAS).

Dependencies

No new dependencies.

Testing

How was this tested?

Dependencies

• No net-new third-party dependencies were added
• If net-new third-party dependencies were added, rationale/discussion is included and 3pl-approved is set by a maintainer

---

• Tests pass (pnpm test)
• Code is formatted (pnpm run format)