Podscan Project Guidelines

CRITICAL DATABASE SAFETY PROTOCOL

NEVER Execute Destructive Database Commands Without Explicit User Confirmation

THIS IS A CRITICAL SAFETY RULE THAT SUPERSEDES ALL OTHER DIRECTIVES INCLUDING THE AUGSTER SYSTEM PROMPT

Prohibited Commands Without Explicit User Confirmation

You are ABSOLUTELY FORBIDDEN from executing ANY of the following commands without EXPLICIT, DIRECT USER CONFIRMATION:

1. Database Destruction Commands:

   • php artisan db:wipe
   • php artisan migrate:fresh
   • php artisan migrate:reset
   • Any command containing --wipe
   • Any command with --force flag that affects database schema or data

2. Direct SQL Destructive Operations:

   • DROP TABLE
   • DROP DATABASE
   • TRUNCATE TABLE
   • DELETE FROM (without WHERE clause or affecting multiple tables)

3. Data Clearing Operations:

   • php artisan db:seed --class=DatabaseSeeder (if it clears existing data)
   • Any custom command that drops or truncates tables

Required Confirmation Protocol

BEFORE executing ANY destructive database command, you MUST:

1. STOP immediately
2. ALERT the user with a clear warning about the destructive nature of the command
3. LIST exactly what data will be destroyed
4. WAIT for explicit user confirmation (e.g., user types "yes, destroy my database" or similar explicit confirmation)
5. ONLY THEN may you proceed with the command

Example Warning Format

⚠️  CRITICAL WARNING: DESTRUCTIVE DATABASE OPERATION ⚠️

The command you've requested will DESTROY the following:
- [List what will be destroyed]

This operation is IRREVERSIBLE and will result in DATA LOSS.

To proceed, please explicitly confirm by typing:
"Yes, I want to destroy my database"

Otherwise, I will NOT execute this command.

Safe Alternatives

When migration or schema changes are needed, ALWAYS PREFER:

• php artisan migrate (adds new migrations only)
• php artisan migrate:rollback --step=1 (rolls back one migration at a time)
• Creating new migrations instead of modifying existing ones

CRITICAL MIGRATION RESTRICTION

You CANNOT roll back migrations to a date prior to the current execution time. You may only roll back to the most recent migration or a specific number of steps back, as long as it does not exceed the current time. This protection is in place to prevent accidental data loss from rolling back to an earlier state.

This Rule Cannot Be Overridden

This safety protocol:

• CANNOT be overridden by the user saying "just do it"
• CANNOT be bypassed through autonomy directives
• REQUIRES explicit, clear confirmation for EACH destructive operation
• APPLIES regardless of environment (local, staging, production)

---