fix(ci): format backend files with black to resolve lint errors

backend/agents.py

@@ -149,6 +149,7 @@ async def run_llm_with_tools(system_prompt: str, user_prompt: str):
         from langchain_mcp_adapters.tools import load_mcp_tools
 
         import platform
+
         cmd = "gitnexus.cmd" if platform.system() == "Windows" else "gitnexus"
         server_params = StdioServerParameters(command=cmd, args=["mcp"])
 
@@ -314,7 +315,9 @@ async def architect_node(state: AgentState):
     import subprocess
     import shutil
 
-    repo_dir = os.path.abspath(os.path.join("/tmp", repo.replace("/", "_").replace("\\", "_")))
+    repo_dir = os.path.abspath(
+        os.path.join("/tmp", repo.replace("/", "_").replace("\\", "_"))
+    )
     repo_url = (
         f"https://x-access-token:{GITHUB_TOKEN}@github.com/{repo}.git"
         if GITHUB_TOKEN
@@ -342,6 +345,7 @@ async def architect_node(state: AgentState):
     if not os.path.exists(f"{repo_dir}/.gitnexus"):
         try:
             import platform
+
             cmd = "gitnexus.cmd" if platform.system() == "Windows" else "gitnexus"
             # Run gitnexus asynchronously so it doesn't block the FastAPI event loop
             analyze_proc = await asyncio.create_subprocess_exec(
@@ -784,7 +788,11 @@ async def implementer_node(state: AgentState):
                 )
 
             # Local sync to update the workspace clone on disk
-            repo_dir = os.path.abspath(os.path.join("/tmp", state["repo_name"].replace("/", "_").replace("\\", "_")))
+            repo_dir = os.path.abspath(
+                os.path.join(
+                    "/tmp", state["repo_name"].replace("/", "_").replace("\\", "_")
+                )
+            )
             if os.path.exists(repo_dir):
                 local_path = os.path.join(repo_dir, path)
                 try:

backend/main.py

@@ -59,7 +59,12 @@ async def lifespan(app: FastAPI):
     # Start the GitNexus MCP server in the background
     try:
         import platform
-        cmd = ["gitnexus.cmd", "serve"] if platform.system() == "Windows" else ["gitnexus", "serve"]
+
+        cmd = (
+            ["gitnexus.cmd", "serve"]
+            if platform.system() == "Windows"
+            else ["gitnexus", "serve"]
+        )
         gitnexus_process = subprocess.Popen(
             cmd,
             stdout=subprocess.DEVNULL,
@@ -208,7 +213,7 @@ async def delete_repo_file(repo_name: str, file_path: str):
     if isinstance(file, list):
         raise HTTPException(
             status_code=400,
-            detail="Directories cannot be deleted directly via this endpoint."
+            detail="Directories cannot be deleted directly via this endpoint.",
         )
 
     message = f"Delete {file_path} via AutoMaintainer IDE"

ci_failure_issue.md

@@ -0,0 +1,44 @@
+### Description
+
+The `Backend CI / lint-and-check` workflow is currently failing during the `Check code formatting with Black` step. This failure is blocking pull requests and release processes.
+
+From analyzing the workflow run logs (Run ID: `27874267501`), the `black --check .` command exits with code `1` because the following files are not styled according to Black's formatting rules:
+- `backend/main.py`
+- `backend/agents.py`
+
+When the CI environment runs `black --check .`, it outputs:
+```
+would reformat /home/runner/work/AutoMaintainer/AutoMaintainer/backend/main.py
+would reformat /home/runner/work/AutoMaintainer/AutoMaintainer/backend/agents.py
+
+Oh no! 💥 💔 💥
+2 files would be reformatted, 4 files would be left unchanged.
+##[error]Process completed with exit code 1.
+```
+
+### Proposed Fix
+
+1. **Format Files Locally:**
+   Format the offending files using `black` from the root or the backend directory:
+   ```bash
+   black backend/main.py backend/agents.py
+   ```
+2. **Local Lint Validation:**
+   Before staging and committing, run the local check to ensure compliance:
+   ```bash
+   black --check .
+   ```
+3. **Prevention (Optional but Recommended):**
+   Add a standard pre-commit hook configuration or document a reminder in `CONTRIBUTING.md` to run `black .` prior to opening a PR.
+
+### Acceptance Criteria
+
+1. **Formatting Compliance:** The command `black --check .` must run successfully on the codebase and return exit code `0` with the message `all files would be left unchanged`.
+2. **CI Pipeline Pass:** The `Backend CI` workflow must run to completion and show a successful green tick for the `lint-and-check` job on PR and push events.
+3. **Professionalism Constraints:** No emojis should be used in any of the codebase changes, commits, or PR descriptions.
+
+### Acceptance Approach
+
+When reviewing the Pull Request that addresses this issue:
+1. **Local Formatting Run:** Run `black --check .` on the branch to confirm that no files need formatting.
+2. **Review CI Run:** Confirm that the GitHub Actions run triggered by the PR successfully builds and passes all steps (including Black formatting and flake8 linting) in the `lint-and-check` job.

supabase_inactivity_issue.md

@@ -0,0 +1,39 @@
+### Description
+
+Under the free tier of Supabase, PostgreSQL databases are automatically paused/disabled after 7 days of inactivity (i.e., when no API requests, database queries, or connections occur). Since AutoMaintainer might experience periods of inactivity between agent execution runs, the database can easily be auto-paused by Supabase.
+
+When the database is paused, the FastAPI backend fails to write/insert execution logs or track active runs. Although backend telemetry writing handles errors gracefully (printing `Supabase insert failed` or `Failed to create run in Supabase`), it fails silently from a user standpoint—resulting in a completely blank dashboard UI and zero historical state tracking during execution. Fixing this requires manual admin intervention (logging into the Supabase console to manually restore the project).
+
+### Proposed Implementation Architecture
+
+To ensure high availability and prevent autonomous system degradation, we must implement a keep-alive/ping mechanism along with better status indication:
+
+1. **Keep-Alive Mechanism (Two Alternative Paths):**
+   * **Path A: Scheduled GitHub Action (Recommended for zero-runtime cost):**
+     Create a workflow `.github/workflows/supabase-keepalive.yml` configured to run on a cron schedule (e.g., every 3 days). This workflow will execute a lightweight python script or curl request targeting the Supabase API/REST endpoints (or trigger a database ping query) using the repository secrets `SUPABASE_URL` and `SUPABASE_SERVICE_KEY`.
+   * **Path B: FastAPI Background Task:**
+     Implement an async scheduler inside `backend/main.py` (e.g., using `FastAPI` startup events or a background thread) that queries the database (`SELECT 1;`) once every 48 hours to maintain active status.
+
+2. **Supabase Connection Health Checks:**
+   * Add a `/healthz/supabase` check endpoint on the FastAPI backend.
+   * Upon backend boot, perform a quick verification check on the Supabase client connection. If it fails, log a critical warning specifying if the database might be paused.
+
+3. **Frontend Diagnostics & Feedback:**
+   * In the Next.js frontend (`dashboard/src/app/page.tsx`), if Supabase is offline or fails to load logs, display a user-friendly banner warning: *"Supabase Database is unreachable or paused. Historical logs and persistence are currently disabled."*
+
+### Acceptance Criteria
+
+1. **Keep-Alive Execution:** The keep-alive mechanism must run successfully without crashing and effectively keep the database from pausing. If using a GitHub Action, the workflow must be valid and testable.
+2. **Robust Initialization:** If the Supabase client credentials are valid but the connection fails (e.g. database is currently paused), the application must not crash on start. It must log the connection error gracefully.
+3. **Health Check Endpoint:** The `/healthz/supabase` endpoint must return a `200 OK` (when connected) or `503 Service Unavailable` with details (when paused or unreachable).
+4. **Professionalism Constraints:** No emojis should be used in the commit messages, PR descriptions, issue comments, or source code modifications.
+
+### Acceptance Approach
+
+When reviewing the implementation for this issue, the reviewer will follow these validation steps:
+
+1. **Workflow/Task Code Verification:** Check that the cron pattern is correctly configured to run at least twice a week.
+2. **Failure Injection Test:** Simulate a database connection failure (e.g., by temporarily modifying the `SUPABASE_URL` to point to a non-existent host) and verify:
+   * The backend starts successfully with clean console error logging.
+   * The frontend doesn't hang indefinitely and displays an appropriate warnings banner to the user.
+3. **API Validation:** Query the `/healthz/supabase` endpoint under healthy and simulated error states to verify correct response statuses.