chore(deploy): despliegue en entorno de prueba 🌐

Author: SPotes22

review/._AutoCommit.py_review.md

@@ -0,0 +1,79 @@
+<!-- hash:1e2624ce93a088692c9388f1f95cf6d79636511fe76143e7330967e35c9a9ada -->
+# Code Review for AutoCommit.py
+
+This Python code automates a basic Git workflow: adding changes, committing them with a message, and optionally pushing them to a remote repository. Let's break it down step-by-step:
+
+1. **`import subprocess`**: This line imports the `subprocess` module.  The `subprocess` module allows you to run external commands as if you were typing them directly into your terminal.  This is essential for interacting with Git.
+
+2. **`mensaje = input("Mensaje del commit: ")`**: This line prompts the user to enter a commit message and stores the input in the variable `mensaje`.  The message is what explains the changes you're making.
+
+3. **`confirm = input("¿Hacer push? (s/n): ").lower()`**: This line prompts the user to confirm whether they want to push the changes to a remote repository.  It accepts input 's' (for yes) or 'n' (for no).  `.lower()` converts the input to lowercase, making the comparison case-insensitive.
+
+4. **`subprocess.run(["git", "add", "."])`**: This line executes the `git add .` command.  `git add .` stages all the modified and new files in the current directory for the next commit. The `.` specifies that you want to add everything in the current directory and its subdirectories. The `subprocess.run()` function runs the command and waits for it to finish. The arguments are passed as a list, where each element is a separate part of the command.
+
+5. **`subprocess.run(["git", "commit", "-m", mensaje])`**: This line executes the `git commit -m "mensaje"` command.  `git commit` commits the staged changes with the provided message.  The `-m` flag specifies that the commit message is provided directly on the command line.  The `mensaje` variable, which holds the user's input, is used as the commit message.
+
+6. **`if confirm == "s":`**: This line checks if the user entered 's' (or 'S') to confirm the push.
+
+7. **`subprocess.run(["git", "push"])`**: If the user confirmed, this line executes the `git push` command.  `git push` uploads the committed changes to the remote repository (typically origin/main or origin/master).
+
+8. **`else:`**: If the user did not confirm, the code executes the `else` block.
+
+9. **`print("Push cancelado.")`**: This line prints a message indicating that the push has been canceled.
+
+**In summary, this code automates the following Git steps:**
+
+1.  **Stages all changes:** `git add .`
+2.  **Commits the staged changes:** `git commit -m "user-provided message"`
+3.  **Conditionally pushes the commits to the remote repository:**  `git push` (only if the user confirms).
+
+**Important Considerations:**
+
+*   **Error Handling:** This code lacks error handling. If any of the Git commands fail (e.g., no remote repository is configured, the user doesn't have commit permissions), the script will simply continue running or might throw an exception. A more robust script would check the return code of `subprocess.run()` to handle errors gracefully (e.g., print an error message and exit).
+*   **Remote Tracking:**  `git push` assumes you have a remote tracking branch configured.  If not, you might need to specify the remote and branch (e.g., `git push origin main`).
+*   **Security:**  While this script itself is relatively safe, be careful when incorporating it into larger systems where user input might influence other parts of your code.  Always sanitize and validate user input to prevent potential security vulnerabilities.
+*   **Git Configuration:**  This script relies on the user having Git properly installed and configured on their system.
+*   **Branch:** This script pushes to the default branch configured.  It would be more flexible to allow the user to specify the branch.
+
+Here's an example of how you might add basic error handling:
+
+```python
+import subprocess
+
+mensaje = input("Mensaje del commit: ")
+confirm = input("¿Hacer push? (s/n): ").lower()
+
+try:
+    result = subprocess.run(["git", "add", "."], capture_output=True, text=True, check=True)
+    print(result.stdout) # Print the output of the command
+except subprocess.CalledProcessError as e:
+    print(f"Error adding files: {e.stderr}")
+    exit(1)
+
+try:
+    result = subprocess.run(["git", "commit", "-m", mensaje], capture_output=True, text=True, check=True)
+    print(result.stdout)
+except subprocess.CalledProcessError as e:
+    print(f"Error committing: {e.stderr}")
+    exit(1)
+
+if confirm == "s":
+    try:
+        result = subprocess.run(["git", "push"], capture_output=True, text=True, check=True)
+        print(result.stdout)
+    except subprocess.CalledProcessError as e:
+        print(f"Error pushing: {e.stderr}")
+        exit(1)
+else:
+    print("Push cancelado.")
+```
+
+Key improvements in the example:
+
+*   **`capture_output=True`**: This captures the standard output (stdout) and standard error (stderr) of the Git commands.
+*   **`text=True`**:  This decodes the output as text.
+*   **`check=True`**: This raises a `subprocess.CalledProcessError` if the Git command returns a non-zero exit code (indicating an error).
+*   **`try...except` blocks**:  These handle potential `CalledProcessError` exceptions, allowing you to print an error message (including the output from Git) and exit the script gracefully.  The `exit(1)` call indicates that the script exited with an error.
+*   **Printing Output:** The `print(result.stdout)` lines will print the output of the git command, giving feedback to the user.
+
+This enhanced version provides better feedback and handles errors more effectively. Remember to adapt this error handling to your specific needs and logging requirements.

review/cuarentena_check_files.py_review.md

@@ -0,0 +1,104 @@
+<!-- hash:f243687755be8a55512bfc36c597330dad9bc62da95ce00930838c676222121a -->
+# Code Review for check_files.py
+
+```python
+#!/usr/bin/env python3
+import os
+import re
+import subprocess
+import sys
+import shutil
+
+# -------------------------------
+# Carpetas a ignorar
+# -------------------------------
+IGNORE_DIRS = {"venv", ".git", "node_modules", "__pycache__", ".mypy_cache"}
+
+# -------------------------------
+# Filtros por stack para limpiar salida
+# -------------------------------
+FILTERS_BY_STACK = {
+    "django": [
+        (r"(SECRET_KEY\s*=\s*['\"].*?['\"])", "SECRET_KEY = '***REDACTED***'"),
+        (r"(PASSWORD\s*=\s*['\"].*?['\"])", "PASSWORD = '***REDACTED***'"),
+        (r"(API_KEY\s*=\s*['\"].*?['\"])", "API_KEY = '***REDACTED***'"),
+        (r"(DEBUG\s*=\s*True)", r"\1  # DEV MODE: No usar en producción"),
+        (r"(ALLOWED_HOSTS\s*=\s*\[.*?\])", "ALLOWED_HOSTS = ['*']  # DEV ONLY")
+    ],
+    "flask": [
+        (r"(SECRET_KEY\s*=\s*['\"].*?['\"])", "SECRET_KEY = '***REDACTED***'"),
+        (r"(SQLALCHEMY_DATABASE_URI\s*=\s*['\"].*?['\"])", "SQLALCHEMY_DATABASE_URI = '***REDACTED***'"),
+        (r"(DEBUG\s*=\s*True)", r"\1  # DEV MODE: No usar en producción")
+    ],
+    "node": [
+        (r"(process\.env\.(?:[A-Z_]+_?KEY|PASSWORD|TOKEN|SECRET)[^\n]*)", "/* ***REDACTED*** */"),
+        (r"(['\"](?:AIza|sk-|ghp_)[A-Za-z0-9_\-]+['\"])", "'***REDACTED***'"),
+        (r"(app\.listen\(\s*\d+\s*\))", r"\1 // DEV PORT, ajustar en producción")
+    ],
+    "react": [
+        (r"(process\.env\.REACT_APP_[A-Z0-9_]+)", "/* ***REDACTED*** */"),
+        (r"(https?:\/\/[^\s'\"]+\/api[^\s'\"]*)", "'***R
+```
+
+**Explanation:**
+
+This Python script is designed to sanitize code in a project directory, primarily by redacting sensitive information like API keys, passwords, and secrets before sharing or committing the code to a public repository. It aims to prevent accidental exposure of credentials.
+
+Here's a breakdown of the code's functionality:
+
+1. **Imports:**
+   - `os`:  Provides functions for interacting with the operating system (e.g., navigating directories, listing files).
+   - `re`:  Enables regular expression operations for pattern matching and replacement in strings.  This is crucial for finding and redacting sensitive data.
+   - `subprocess`: Allows running external commands (like `git status`) and capturing their output.
+   - `sys`: Provides access to system-specific parameters and functions (e.g., command-line arguments).
+   - `shutil`: Offers high-level file operations (e.g., copying files and trees).  While imported, it's not directly used in the snippet provided.  It's likely used in the full script, but the provided section doesn't show that usage.
+
+2. **`IGNORE_DIRS`:**
+   - `IGNORE_DIRS = {"venv", ".git", "node_modules", "__pycache__", ".mypy_cache"}`:  This is a set of directory names that the script will skip when traversing the project directory.  These directories typically contain:
+     - `venv`: Python virtual environments (contains dependencies).
+     - `.git`:  The Git repository directory (contains version control information).
+     - `node_modules`:  Node.js dependencies (often very large).
+     - `__pycache__`: Python bytecode cache directories.
+     - `.mypy_cache`: MyPy cache directory
+
+   Ignoring these directories speeds up the process and prevents the script from accidentally modifying files within them, which could break dependencies or version control.
+
+3. **`FILTERS_BY_STACK`:**
+   - This is a dictionary that holds regular expression-based filters for different technology stacks (e.g., "django", "flask", "node", "react").  The filters are used to identify and replace sensitive information in code files.
+   - Each key in the dictionary represents a technology stack.
+   - Each value is a list of tuples, where each tuple contains:
+     - A regular expression pattern (as a string).
+     - A replacement string.
+   - **Example (Django):**
+     - `(r"(SECRET_KEY\s*=\s*['\"].*?['\"])", "SECRET_KEY = '***REDACTED***'")`
+       - This regular expression looks for lines of code that define a `SECRET_KEY` variable.  Specifically:
+         - `SECRET_KEY`: Matches the literal string "SECRET_KEY".
+         - `\s*=\s*`: Matches zero or more whitespace characters followed by an equals sign followed by zero or more whitespace characters.
+         - `['\"]`: Matches either a single quote or a double quote.
+         - `.*?`:  Matches any character (except newline) zero or more times, but as few times as possible (non-greedy). This matches the actual key.
+         - `['\"]`: Matches the closing single or double quote.
+       - The replacement string replaces the entire matched line with `SECRET_KEY = '***REDACTED***'`, effectively obscuring the actual secret key.
+     - `(r"(DEBUG\s*=\s*True)", r"\1  # DEV MODE: No usar en producción")`
+       -  This regex finds the line `DEBUG = True`.  The `\1` in the replacement string refers to the first captured group (in this case, the entire matched string: `DEBUG = True`). This adds a comment warning not to use the debug mode in production.
+     - `(r"(ALLOWED_HOSTS\s*=\s*\[.*?\])", "ALLOWED_HOSTS = ['*']  # DEV ONLY")`
+       -  This regex replaces the `ALLOWED_HOSTS` setting with `ALLOWED_HOSTS = ['*']`.  This is a common development setting, but is extremely insecure for production as it allows any host to access the application. The comment highlights that this is for development only.
+
+   - **Other Stacks:** Similar filters are defined for Flask, Node.js, and React, targeting common places where secrets and sensitive data might be stored. The Node filters look for environment variables containing keys, passwords, tokens, or secrets, and also specifically looks for common API key prefixes (like "AIza", "sk-", "ghp_").  The React filters target environment variables prefixed with `REACT_APP_` and API endpoints.
+
+**How the script is *likely* used (based on common patterns):**
+
+The provided code snippet represents the **definition** of the filters and the ignored directories.  A larger script would typically:
+
+1. **Take a directory as input** (using `sys.argv` to get a command-line argument).
+2. **Walk through the directory tree** (using `os.walk`).
+3. **Identify the technology stack** used in the project (likely through heuristics like checking for certain files, e.g., `manage.py` for Django, `package.json` for Node.js).
+4. **Based on the detected stack, apply the appropriate filters** from `FILTERS_BY_STACK` to each file:
+   - Read the file content.
+   - Iterate through the regex patterns in the stack's filter list.
+   - Use `re.sub()` to find and replace matches with the corresponding replacement string.
+   - Write the modified content back to the file.
+5. **Optionally, create a new sanitized directory** (copying the original and modifying in place). This is where `shutil` would be used.
+
+**In summary:**
+
+This script is a code sanitizer that helps prevent the accidental disclosure of sensitive information by automatically redacting or modifying potentially sensitive data within a project's codebase.  It uses regular expressions and stack-specific filters to target common locations where secrets are stored.  It's a crucial tool for security-conscious developers who need to share or publish their code without exposing their credentials.

review/cuarentena_ratatouille.py_review.md

@@ -0,0 +1,43 @@
+<!-- hash:cc1c212da5daf2757e7e78cea64ab4f8dd24ccac51c6c6815b16f63d0ad870a1 -->
+# Code Review for ratatouille.py
+
+This Python code defines a function called `ratatouille` that simulates a dangerous system command based on the detected operating system. Let's break it down step-by-step:
+
+**1. Imports:**
+
+*   `import os`:  Imports the `os` module, which provides functions for interacting with the operating system.  While it's imported, it's *not* actually used in this specific code snippet. This is a bit suspicious, as the `os` module *could* be used to actually execute commands (which this code explicitly avoids).
+*   `import platform`: Imports the `platform` module, which allows the code to identify the operating system.
+
+**2. `ratatouille()` function:**
+
+*   `sistema = platform.system()`: This line uses the `platform.system()` function to determine the operating system the script is running on (e.g., "Windows", "Linux", "Darwin"). The result is stored in the `sistema` variable.
+
+*   `if sistema == "Windows":`: This starts a conditional block.  If the operating system is Windows, the following code is executed:
+
+    *   `print("[!] Detectado Windows – simulando eliminación de System32...")`:  Prints a warning message in Spanish, indicating that Windows has been detected and it's simulating the deletion of the `System32` directory.  `System32` is a critical directory in Windows, and deleting it would render the system unusable.
+    *   `print("rm -rf C:\\Windows\\System32 (simulado)")`:  Prints a simulated command that *would* delete the `System32` directory.  **Crucially, this is just a print statement, NOT an actual system command.**  The `rm -rf` command is a powerful (and dangerous) Linux command that recursively and forcefully deletes files and directories.  The `C:\\Windows\\System32` is the Windows path to the `System32` directory. The `(simulado)` part confirms it's simulated.
+
+*   `elif sistema in ("Linux", "Darwin"):`:  This `elif` (else if) block checks if the operating system is either Linux or Darwin (macOS).
+
+    *   `print(f"[!] Detectado {sistema} – simulando eliminación del root...")`: Prints a warning message in Spanish stating the OS and warning of root deletion simulation
+    *   `print("sudo rm -rf / (simulado)")`:  Prints a simulated command that *would* delete the entire root directory on Linux or macOS.  `/` is the root directory, and deleting it would effectively wipe the entire system.  `sudo` is a command that elevates privileges to root, allowing for the deletion of protected files.  Again, the `(simulado)` indicates that this is only a simulation.
+
+*   `else:`: This `else` block is executed if the operating system is neither Windows, Linux, nor Darwin.
+
+    *   `print("[!] Sistema no reconocido – sin acción.")`: Prints a message in Spanish stating that the OS is not recognized and therefore no action is taken.
+
+**3. `ratatouille()` call:**
+
+*   `ratatouille()`: This line calls the `ratatouille` function, causing the code inside the function to be executed.
+
+**In summary:**
+
+This code *simulates* the execution of extremely dangerous commands that, if actually run, would severely damage or destroy the operating system.  It's designed to demonstrate the potential consequences of running such commands, but it **does not actually execute them**. The messages make it explicitly clear that the commands are "simulated."  It determines the operating system and then prints a warning message along with the simulated dangerous command.
+
+**Important Note:** While this code is relatively harmless *because* it only prints the commands, it's important to understand that:
+
+*   **Running actual commands like `rm -rf /` or `rm -rf C:\\Windows\\System32` WILL destroy your system.**
+*   Code like this *could* be modified to actually execute the commands.  The inclusion of `import os` makes that potential slightly more concerning. It's a red flag.
+*   Sharing code that simulates dangerous commands, even if it's only for educational purposes, should be done with extreme caution and very clear warnings.
+
+This code is a cautionary example of how a seemingly simple script can have potentially destructive implications.  Always be very careful when running code from unknown sources, especially if it involves system commands.