Merge pull request #844 from Wikid82/nightly

Weekly: Promote nightly to main (2026-03-16)

Author: Wikid82

.dockerignore

@@ -9,13 +9,12 @@
 .git/
 .gitignore
 .github/
-.pre-commit-config.yaml
 codecov.yml
 .goreleaser.yaml
 .sourcery.yml
 
 # -----------------------------------------------------------------------------
-# Python (pre-commit, tooling)
+# Python (tooling)
 # -----------------------------------------------------------------------------
 __pycache__/
 *.py[cod]

.github/agents/Backend_Dev.agent.md

@@ -45,7 +45,7 @@ Your priority is writing code that is clean, tested, and secure by default.
     - **Step 3 (The Logic)**:
         - Implement the handler in `internal/api/handlers`.
     - **Step 4 (Lint and Format)**:
-        - Run `pre-commit run --all-files` to ensure code quality.
+        - Run `lefthook run pre-commit` to ensure code quality.
     - **Step 5 (The Green Light)**:
         - Run `go test ./...`.
         - **CRITICAL**: If it fails, fix the *Code*, NOT the *Test* (unless the test was wrong about the contract).
@@ -57,8 +57,7 @@ Your priority is writing code that is clean, tested, and secure by default.
         - **Conditional GORM Gate**: If task changes include model/database-related
             files (`backend/internal/models/**`, GORM query logic, migrations), run
             GORM scanner in check mode and treat CRITICAL/HIGH findings as blocking:
-                - Run: `pre-commit run --hook-stage manual gorm-security-scan --all-files`
-                    OR `./scripts/scan-gorm-security.sh --check`
+                - Run: `lefthook run pre-commit` (which includes manual gorm-security-scan) OR `./scripts/scan-gorm-security.sh --check`
                 - Policy: Process-blocking gate even while automation is manual stage
     - **Local Patch Coverage Preflight (MANDATORY)**: Run VS Code task `Test: Local Patch Report` or `bash scripts/local-patch-report.sh` before backend coverage runs.
         - Ensure artifacts exist: `test-results/local-patch-report.md` and `test-results/local-patch-report.json`.
@@ -69,9 +68,9 @@ Your priority is writing code that is clean, tested, and secure by default.
         - **Manual Script**: Execute `/projects/Charon/scripts/go-test-coverage.sh` from the root directory
         - **Minimum**: 85% coverage (configured via `CHARON_MIN_COVERAGE` or `CPM_MIN_COVERAGE`)
         - **Critical**: If coverage drops below threshold, write additional tests immediately. Do not skip this step.
-        - **Why**: Coverage tests are in manual stage of pre-commit for performance. You MUST run them via VS Code tasks or scripts before completing your task.
+        - **Why**: Coverage tests are in manual stage of lefthook for performance. You MUST run them via VS Code tasks or scripts before completing your task.
     - Ensure coverage goals are met as well as all tests pass. Just because Tests pass does not mean you are done. Goal Coverage Needs to be met even if the tests to get us there are outside the scope of your task. At this point, your task is to maintain coverage goal and all tests pass because we cannot commit changes if they fail.
-    - Run `pre-commit run --all-files` as final check (this runs fast hooks only; coverage was verified above).
+    - Run `lefthook run pre-commit` as final check (this runs fast hooks only; coverage was verified above).
 </workflow>
 
 <constraints>

.github/agents/Frontend_Dev.agent.md

@@ -48,7 +48,7 @@ You are a SENIOR REACT/TYPESCRIPT ENGINEER with deep expertise in:
    - Run tests with `npm test` in `frontend/` directory
 
 4. **Quality Checks**:
-   - Run `pre-commit run --all-files` to ensure linting and formatting
+   - Run `lefthook run pre-commit` to ensure linting and formatting
    - Ensure accessibility with proper ARIA attributes
 </workflow>
 

.github/agents/Management.agent.md

@@ -24,12 +24,12 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
 4. **Team Roster**:
     - `Planning`: The Architect. (Delegate research & planning here).
     - `Supervisor`: The Senior Advisor. (Delegate plan review here).
-    - `Backend_Dev`: The Engineer. (Delegate Go implementation here).
-    - `Frontend_Dev`: The Designer. (Delegate React implementation here).
-    - `QA_Security`: The Auditor. (Delegate verification and testing here).
-    - `Docs_Writer`: The Scribe. (Delegate docs here).
+    - `Backend Dev`: The Engineer. (Delegate Go implementation here).
+    - `Frontend Dev`: The Designer. (Delegate React implementation here).
+    - `QA Security`: The Auditor. (Delegate verification and testing here).
+    - `Docs Writer`: The Scribe. (Delegate docs here).
     - `DevOps`: The Packager. (Delegate CI/CD and infrastructure here).
-    - `Playwright_Dev`: The E2E Specialist. (Delegate Playwright test creation and maintenance here).
+    - `Playwright Dev`: The E2E Specialist. (Delegate Playwright test creation and maintenance here).
 5. **Parallel Execution**:
     - You may delegate to `runSubagent` multiple times in parallel if tasks are independent. The only exception is `QA_Security`, which must run last as this validates the entire codebase after all changes.
 6. **Implementation Choices**:
@@ -43,7 +43,7 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
     -   **Identify Goal**: Understand the user's request.
     -   **STOP**: Do not look at the code. Do not run `list_dir`. No code is to be changed or implemented until there is a fundamentally sound plan of action that has been approved by the user.
     -   **Action**: Immediately call `Planning` subagent.
-        -   *Prompt*: "Research the necessary files for '{user_request}' and write a comprehensive plan detailing as many specifics as possible to `docs/plans/current_spec.md`. Be an artist with directions and discriptions. Include file names, function names, and component names wherever possible. Break the plan into phases based on the least amount of requests. Include a PR Slicing Strategy section that decides whether to split work into multiple PRs and, when split, defines PR-1/PR-2/PR-3 scope, dependencies, and acceptance criteria. Review and suggest updaetes to `.gitignore`, `codecov.yml`, `.dockerignore`, and `Dockerfile` if necessary. Return only when the plan is complete."
+        -   *Prompt*: "Research the necessary files for '{user_request}' and write a comprehensive plan detailing as many specifics as possible to `docs/plans/current_spec.md`. Be an artist with directions and discriptions. Include file names, function names, and component names wherever possible. Break the plan into phases based on the least amount of requests. Include a Commit Slicing Strategy section that decides whether to split work into multiple PRs and, when split, defines PR-1/PR-2/PR-3 scope, dependencies, and acceptance criteria. Review and suggest updaetes to `.gitignore`, `codecov.yml`, `.dockerignore`, and `Dockerfile` if necessary. Return only when the plan is complete."
     - **Task Specifics**:
         - If the task is to just run tests or audits, there is no need for a plan. Directly call `QA_Security` to perform the tests and write the report. If issues are found, return to `Planning` for a remediation plan and delegate the fixes to the corresponding subagents.
 
@@ -59,7 +59,7 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
     -   **Ask**: "Plan created. Shall I authorize the construction?"
 
 4. **Phase 4: Execution (Waterfall)**:
-        - **Single-PR or Multi-PR Decision**: Read the PR Slicing Strategy in `docs/plans/current_spec.md`.
+        - **Single-PR or Multi-PR Decision**: Read the Commit Slicing Strategy in `docs/plans/current_spec.md`.
         - **If single PR**:
             - **Backend**: Call `Backend_Dev` with the plan file.
             - **Frontend**: Call `Frontend_Dev` with the plan file.
@@ -73,7 +73,7 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
     - **Supervisor**: Call `Supervisor` to review the implementation against the plan. Provide feedback and ensure alignment with best practices.
 
 6. **Phase 6: Audit**:
-    - **QA**: Call `QA_Security` to meticulously test current implementation as well as regression test. Run all linting, security tasks, and manual pre-commit checks. Write a report to `docs/reports/qa_report.md`. Start back at Phase 1 if issues are found.
+    - **QA**: Call `QA_Security` to meticulously test current implementation as well as regression test. Run all linting, security tasks, and manual lefthook checks. Write a report to `docs/reports/qa_report.md`. Start back at Phase 1 if issues are found.
 
 7. **Phase 7: Closure**:
     - **Docs**: Call `Docs_Writer`.

.github/agents/Planning.agent.md

@@ -44,7 +44,7 @@ You are a PRINCIPAL ARCHITECT responsible for technical planning and system desi
    - Include acceptance criteria
    - Break down into implementable tasks using examples, diagrams, and tables
    - Estimate complexity for each component
-    - Add a **PR Slicing Strategy** section with:
+    - Add a **Commit Slicing Strategy** section with:
        - Decision: single PR or multiple PRs
        - Trigger reasons (scope, risk, cross-domain changes, review size)
        - Ordered PR slices (`PR-1`, `PR-2`, ...), each with scope, files, dependencies, and validation gates

.github/instructions/ARCHITECTURE.instructions.md

@@ -130,7 +130,7 @@ graph TB
 | **WebSocket** | gorilla/websocket | Latest | Real-time log streaming |
 | **Crypto** | golang.org/x/crypto | Latest | Password hashing, encryption |
 | **Metrics** | Prometheus Client | Latest | Application metrics |
-| **Notifications** | Shoutrrr | Latest | Multi-platform alerts |
+| **Notifications** | Notify | Latest | Multi-platform alerts |
 | **Docker Client** | Docker SDK | Latest | Container discovery |
 | **Logging** | Logrus + Lumberjack | Latest | Structured logging with rotation |
 
@@ -1263,8 +1263,8 @@ docker exec charon /app/scripts/restore-backup.sh \
    - Future: Dynamic plugin loading for custom providers
 
 2. **Notification Channels:**
-   - Shoutrrr provides 40+ channels (Discord, Slack, Email, etc.)
-   - Custom channels via Shoutrrr service URLs
+   - Notify provides multi-platform channels (Discord, Slack, Gotify, etc.)
+   - Provider-based configuration with per-channel feature flags
 
 3. **Authentication Providers:**
    - Current: Local database authentication

.github/instructions/copilot-instructions.md

@@ -67,7 +67,7 @@ Before proposing ANY code change or fix, you must build a mental map of the feat
 
 - **Run**: `cd backend && go run ./cmd/api`.
 - **Test**: `go test ./...`.
-- **Static Analysis (BLOCKING)**: Fast linters run automatically on every commit via pre-commit hooks.
+- **Static Analysis (BLOCKING)**: Fast linters run automatically on every commit via lefthook pre-commit-phase hooks.
   - **Staticcheck errors MUST be fixed** - commits are BLOCKED until resolved
   - Manual run: `make lint-fast` or VS Code task "Lint: Staticcheck (Fast)"
   - Staticcheck-only: `make lint-staticcheck-only`
@@ -79,7 +79,7 @@ Before proposing ANY code change or fix, you must build a mental map of the feat
 - **Security**: Sanitize all file paths using `filepath.Clean`. Use `fmt.Errorf("context: %w", err)` for error wrapping.
 - **Graceful Shutdown**: Long-running work must respect `server.Run(ctx)`.
 
-### Troubleshooting Pre-Commit Staticcheck Failures
+### Troubleshooting Lefthook Staticcheck Failures
 
 **Common Issues:**
 
@@ -175,7 +175,7 @@ Before marking an implementation task as complete, perform the following in orde
     - **Exclusions**: Skip this gate for docs-only (`**/*.md`) or frontend-only (`frontend/**`) changes
     - **Run One Of**:
         - VS Code task: `Lint: GORM Security Scan`
-        - Pre-commit: `pre-commit run --hook-stage manual gorm-security-scan --all-files`
+        - Lefthook: `lefthook run pre-commit` (includes gorm-security-scan)
         - Direct: `./scripts/scan-gorm-security.sh --check`
         - **Gate Enforcement**: DoD is process-blocking until scanner reports zero
             CRITICAL/HIGH findings, even while automation remains in manual stage
@@ -189,15 +189,15 @@ Before marking an implementation task as complete, perform the following in orde
     - **Expected Behavior**: Report may warn (non-blocking rollout), but artifact generation is mandatory.
 
 3. **Security Scans** (MANDATORY - Zero Tolerance):
-    - **CodeQL Go Scan**: Run VS Code task "Security: CodeQL Go Scan (CI-Aligned)" OR `pre-commit run codeql-go-scan --all-files`
+    - **CodeQL Go Scan**: Run VS Code task "Security: CodeQL Go Scan (CI-Aligned)" OR `lefthook run pre-commit`
         - Must use `security-and-quality` suite (CI-aligned)
         - **Zero high/critical (error-level) findings allowed**
         - Medium/low findings should be documented and triaged
-    - **CodeQL JS Scan**: Run VS Code task "Security: CodeQL JS Scan (CI-Aligned)" OR `pre-commit run codeql-js-scan --all-files`
+    - **CodeQL JS Scan**: Run VS Code task "Security: CodeQL JS Scan (CI-Aligned)" OR `lefthook run pre-commit`
         - Must use `security-and-quality` suite (CI-aligned)
         - **Zero high/critical (error-level) findings allowed**
         - Medium/low findings should be documented and triaged
-    - **Validate Findings**: Run `pre-commit run codeql-check-findings --all-files` to check for HIGH/CRITICAL issues
+    - **Validate Findings**: Run `lefthook run pre-commit` to check for HIGH/CRITICAL issues
     - **Trivy Container Scan**: Run VS Code task "Security: Trivy Scan" for container/dependency vulnerabilities
     - **Results Viewing**:
         - Primary: VS Code SARIF Viewer extension (`MS-SarifVSCode.sarif-viewer`)
@@ -210,7 +210,7 @@ Before marking an implementation task as complete, perform the following in orde
         - Database creation: `--threads=0 --overwrite`
         - Analysis: `--sarif-add-baseline-file-info`
 
-4. **Pre-Commit Triage**: Run `pre-commit run --all-files`.
+4. **Lefthook Triage**: Run `lefthook run pre-commit`.
     - If errors occur, **fix them immediately**.
     - If logic errors occur, analyze and propose a fix.
     - Do not output code that violates pre-commit standards.

.github/instructions/go.instructions.md

@@ -353,7 +353,7 @@ Follow idiomatic Go practices and community standards when writing Go code. Thes
 ### Development Practices
 
 - Run tests before committing
-- Use pre-commit hooks for formatting and linting
+- Use lefthook pre-commit-phase hooks for formatting and linting
 - Keep commits focused and atomic
 - Write meaningful commit messages
 - Review diffs before committing

.github/instructions/structure.instructions.md

@@ -9,7 +9,7 @@ description: 'Repository structure guidelines to maintain organized file placeme
 
 The repository root should contain ONLY:
 
-- Essential config files (`.gitignore`, `.pre-commit-config.yaml`, `Makefile`, etc.)
+- Essential config files (`.gitignore`, `Makefile`, etc.)
 - Standard project files (`README.md`, `CONTRIBUTING.md`, `LICENSE`, `CHANGELOG.md`)
 - Go workspace files (`go.work`, `go.work.sum`)
 - VS Code workspace (`Chiron.code-workspace`)

.github/instructions/subagent.instructions.md

@@ -28,7 +28,7 @@ runSubagent({
 - Parallel: run `QA and Security`, `DevOps` and `Doc Writer` in parallel for CI / QA checks and documentation.
 - Return: a JSON summary with `subagent_results`, `overall_status`, and aggregated artifacts.
 
-2.1) Multi-PR Slicing Protocol
+2.1) Multi-Commit Slicing Protocol
 
 - If a task is large or high-risk, split into PR slices and execute in order.
 - Each slice must have: