changed perms

fix(ci): shift GeoLite2 update to Sunday targeting development branch

.docker/docker-entrypoint.sh

@@ -303,6 +303,19 @@ ACQUIS_EOF
     # Also handle case where it might be without trailing slash
     sed -i 's|log_dir: /var/log$|log_dir: /var/log/crowdsec|g' "$CS_CONFIG_DIR/config.yaml"
 
+    # Redirect CrowdSec LAPI database to persistent volume
+    # Default path /var/lib/crowdsec/data/crowdsec.db is ephemeral (not volume-mounted),
+    # so it is destroyed on every container rebuild. The bouncer API key (stored on the
+    # persistent volume at /app/data/crowdsec/) survives rebuilds but the LAPI database
+    # that validates it does not — causing perpetual key rejection.
+    # Redirecting db_path to the volume-mounted CS_DATA_DIR fixes this.
+    sed -i "s|db_path: /var/lib/crowdsec/data/crowdsec.db|db_path: ${CS_DATA_DIR}/crowdsec.db|g" "$CS_CONFIG_DIR/config.yaml"
+    if grep -q "db_path:.*${CS_DATA_DIR}" "$CS_CONFIG_DIR/config.yaml"; then
+        echo "✓ CrowdSec LAPI database redirected to persistent volume: ${CS_DATA_DIR}/crowdsec.db"
+    else
+        echo "⚠️  WARNING: Could not verify LAPI db_path redirect — bouncer keys may not survive rebuilds"
+    fi
+
     # Verify LAPI configuration was applied correctly
     if grep -q "listen_uri:.*:8085" "$CS_CONFIG_DIR/config.yaml"; then
         echo "✓ CrowdSec LAPI configured for port 8085"
@@ -310,10 +323,11 @@ ACQUIS_EOF
         echo "✗ WARNING: LAPI port configuration may be incorrect"
     fi
 
-    # Update hub index to ensure CrowdSec can start
-    if [ ! -f "/etc/crowdsec/hub/.index.json" ]; then
-        echo "Updating CrowdSec hub index..."
-        timeout 60s cscli hub update 2>/dev/null || echo "⚠️ Hub update timed out or failed, continuing..."
+    # Always refresh hub index on startup (stale index causes hash mismatch errors on collection install)
+    echo "Updating CrowdSec hub index..."
+    if ! timeout 60s cscli hub update 2>&1; then
+        echo "⚠️ Hub index update failed (network issue?). Collections may fail to install."
+        echo "   CrowdSec will still start with whatever index is cached."
     fi
 
     # Ensure local machine is registered (auto-heal for volume/config mismatch)
@@ -321,12 +335,11 @@ ACQUIS_EOF
     echo "Registering local machine..."
     cscli machines add -a --force 2>/dev/null || echo "Warning: Machine registration may have failed"
 
-    # Install hub items (parsers, scenarios, collections) if local mode enabled
-    if [ "$SECURITY_CROWDSEC_MODE" = "local" ]; then
-        echo "Installing CrowdSec hub items..."
-        if [ -x /usr/local/bin/install_hub_items.sh ]; then
-            /usr/local/bin/install_hub_items.sh 2>/dev/null || echo "Warning: Some hub items may not have installed"
-        fi
+    # Always ensure required collections are present (idempotent — already-installed items are skipped).
+    # Collections are just config files with zero runtime cost when CrowdSec is disabled.
+    echo "Ensuring CrowdSec hub items are installed..."
+    if [ -x /usr/local/bin/install_hub_items.sh ]; then
+        /usr/local/bin/install_hub_items.sh || echo "⚠️ Some hub items may not have installed. CrowdSec can still start."
     fi
 
     # Fix ownership AFTER cscli commands (they run as root and create root-owned files)

.github/agents/Management.agent.md

@@ -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 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."
+        -   *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 organizes work into logical commits within a single PR — one feature = one PR, with ordered commits (Commit 1, Commit 2, …) each defining scope, files, dependencies, and validation gates. 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,15 +59,13 @@ 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 Commit Slicing Strategy in `docs/plans/current_spec.md`.
-        - **If single PR**:
+        - **Read Commit Slicing Strategy**: Read the Commit Slicing Strategy in `docs/plans/current_spec.md` to understand the ordered commits.
+        - **Single PR, Multiple Commits**: All work ships as one PR. Each commit maps to a phase in the plan.
             - **Backend**: Call `Backend_Dev` with the plan file.
             - **Frontend**: Call `Frontend_Dev` with the plan file.
-        - **If multi-PR**:
-            - Execute in PR slices, one slice at a time, in dependency order.
-            - Require each slice to pass review + QA gates before starting the next slice.
-            - Keep every slice deployable and independently testable.
-        - **MANDATORY**: Implementation agents must perform linting and type checks locally before declaring their slice "DONE". This is a critical step that must not be skipped to avoid broken commits and security issues.
+        - Execute commits in dependency order. Each commit must pass its validation gates before the next commit begins.
+        - The PR is merged only when all commits are complete and all DoD gates pass.
+        - **MANDATORY**: Implementation agents must perform linting and type checks locally before declaring their commit "DONE". This is a critical step that must not be skipped to avoid broken commits and security issues.
 
 5. **Phase 5: Review**:
     - **Supervisor**: Call `Supervisor` to review the implementation against the plan. Provide feedback and ensure alignment with best practices.
@@ -80,7 +78,7 @@ You are "lazy" in the smartest way possible. You never do what a subordinate can
     - **Docs**: Call `Docs_Writer`.
     - **Manual Testing**: create a new test plan in `docs/issues/*.md` for tracking manual testing focused on finding potential bugs of the implemented features.
     - **Final Report**: Summarize the successful subagent runs.
-    - **PR Roadmap**: If split mode was used, include a concise roadmap of completed and remaining PR slices.
+    - **Commit Roadmap**: Include a concise summary of completed and remaining commits within the PR.
 
 **Mandatory Commit Message**: When you reach a stopping point, provide a copy and paste code block commit message at the END of the response on format laid out in `.github/instructions/commit-message.instructions.md`
         - **STRICT RULES**:
@@ -167,23 +165,27 @@ The task is not complete until ALL of the following pass with zero issues:
     - **Base URL**: Uses `PLAYWRIGHT_BASE_URL` or default from `playwright.config.js`
     - All E2E tests must pass before proceeding to unit tests
 
-2. **Local Patch Coverage Preflight (MANDATORY - Before Unit/Coverage Tests)**:
-    - Ensure the local patch report is run first via VS Code task `Test: Local Patch Report` or `bash scripts/local-patch-report.sh`.
-    - Verify both artifacts exist: `test-results/local-patch-report.md` and `test-results/local-patch-report.json`.
-    - Use this report to identify changed files needing coverage before running backend/frontend coverage suites.
-
-3. **Coverage Tests (MANDATORY - Verify Explicitly)**:
+2. **Coverage Tests (MANDATORY - Verify Explicitly)**:
     - **Backend**: Ensure `Backend_Dev` ran VS Code task "Test: Backend with Coverage" or `scripts/go-test-coverage.sh`
     - **Frontend**: Ensure `Frontend_Dev` ran VS Code task "Test: Frontend with Coverage" or `scripts/frontend-test-coverage.sh`
     - **Why**: These are in manual stage of pre-commit for performance. Subagents MUST run them via VS Code tasks or scripts.
     - Minimum coverage: 85% for both backend and frontend.
     - All tests must pass with zero failures.
+    - **Outputs**: `backend/coverage.txt` and `frontend/coverage/lcov.info` — these are required inputs for step 3.
+
+3. **Local Patch Coverage Report (MANDATORY - After Coverage Tests)**:
+    - **Purpose**: Identify uncovered lines in files modified by this task so missing tests are written before declaring Done. This is the bridge between "overall coverage is fine" and "the actual lines I changed are tested."
+    - **Prerequisites**: `backend/coverage.txt` and `frontend/coverage/lcov.info` must exist (generated by step 2). If missing, run coverage tests first.
+    - **Run**: VS Code task `Test: Local Patch Report` or `bash scripts/local-patch-report.sh`.
+    - **Verify artifacts**: Both `test-results/local-patch-report.md` and `test-results/local-patch-report.json` must exist with non-empty results.
+    - **Act on findings**: If patch coverage for any changed file is below **90%**, delegate to the responsible agent (`Backend_Dev` or `Frontend_Dev`) to add targeted tests covering the uncovered lines. Re-run coverage (step 2) and this report until the threshold is met.
+    - **Blocking gate**: 90% overall patch coverage. Do not proceed to pre-commit or security scans until resolved or explicitly waived by the user.
 
 4. **Type Safety (Frontend)**:
     - Ensure `Frontend_Dev` ran VS Code task "Lint: TypeScript Check" or `npm run type-check`
     - **Why**: This check is in manual stage of pre-commit for performance. Subagents MUST run it explicitly.
 
-5. **Pre-commit Hooks**: Ensure `QA_Security` ran `pre-commit run --all-files` (fast hooks only; coverage was verified in step 3)
+5. **Pre-commit Hooks**: Ensure `QA_Security` ran `pre-commit run --all-files` (fast hooks only; coverage was verified in step 2)
 
 6. **Security Scans**: Ensure `QA_Security` ran the following with zero Critical or High severity issues:
    - **Trivy Filesystem Scan**: Fast scan of source code and dependencies

.github/agents/Planning.agent.md

@@ -38,7 +38,7 @@ You are a PRINCIPAL ARCHITECT responsible for technical planning and system desi
    - Specify database schema changes
    - Document component interactions and data flow
    - Identify potential risks and mitigation strategies
-   - Determine PR sizing and whether to split the work into multiple PRs for safer and faster review
+   - Determine commit sizing and how to organize work into logical commits within a single PR for safer and faster review
 
 3. **Documentation**:
    - Write plan to `docs/plans/current_spec.md`
@@ -46,10 +46,10 @@ You are a PRINCIPAL ARCHITECT responsible for technical planning and system desi
    - Break down into implementable tasks using examples, diagrams, and tables
    - Estimate complexity for each component
     - Add a **Commit Slicing Strategy** section with:
-       - Decision: single PR or multiple PRs
+       - Decision: single PR with ordered logical commits (one feature = one PR)
        - Trigger reasons (scope, risk, cross-domain changes, review size)
-       - Ordered PR slices (`PR-1`, `PR-2`, ...), each with scope, files, dependencies, and validation gates
-       - Rollback and contingency notes per slice
+       - Ordered commits (`Commit 1`, `Commit 2`, ...), each with scope, files, dependencies, and validation gates
+       - Rollback and contingency notes for the PR as a whole
 
 4. **Handoff**:
    - Once plan is approved, delegate to `Supervisor` agent for review.

.github/instructions/subagent.instructions.md

@@ -23,21 +23,21 @@ runSubagent({
 
 - Validate: `plan_file` exists and contains a `Handoff Contract` JSON.
 - Kickoff: call `Planning` to create the plan if not present.
-- Decide: check if work should be split into multiple PRs (size, risk, cross-domain impact).
+- Decide: check how to organize work into logical commits within a single PR (size, risk, cross-domain impact).
 - Run: execute `Backend Dev` then `Frontend Dev` sequentially.
 - 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-Commit Slicing Protocol
 
-- If a task is large or high-risk, split into PR slices and execute in order.
-- Each slice must have:
+- All work for a single feature ships as one PR with ordered logical commits.
+- Each commit must have:
   - Scope boundary (what is included/excluded)
-  - Dependency on previous slices
-  - Validation gates (tests/scans required for that slice)
-  - Explicit rollback notes
-- Do not start the next slice until the current slice is complete and verified.
-- Keep each slice independently reviewable and deployable.
+  - Dependency on previous commits
+  - Validation gates (tests/scans required for that commit)
+  - Explicit rollback notes for the PR as a whole
+- Do not start the next commit until the current commit is complete and verified.
+- Keep each commit independently reviewable within the PR.
 
 3) Return Contract that all subagents must return
 
@@ -55,7 +55,7 @@ runSubagent({
 
 - On a subagent failure, the Management agent must capture `tests.output` and decide to retry (1 retry maximum), or request a revert/rollback.
 - Clearly mark the `status` as `failed`, and include `errors` and `failing_tests` in the `summary`.
-- For multi-PR execution, mark failed slice as blocked and stop downstream slices until resolved.
+- For multi-commit execution, mark failed commit as blocked and stop downstream commits until resolved.
 
 5) Example: Run a full Feature Implementation
 

.github/instructions/testing.instructions.md

@@ -12,9 +12,19 @@ instruction files take precedence over agent files and operator documentation.
 
 **MANDATORY**: Before running unit tests, verify the application UI/UX functions correctly end-to-end.
 
-## 0.5 Local Patch Coverage Preflight (Before Unit Tests)
+## 0.5 Local Patch Coverage Report (After Coverage Tests)
 
-**MANDATORY**: After E2E and before backend/frontend unit coverage runs, generate a local patch report so uncovered changed lines are visible early.
+**MANDATORY**: After running backend and frontend coverage tests (which generate
+`backend/coverage.txt` and `frontend/coverage/lcov.info`), run the local patch
+report to identify uncovered lines in changed files.
+
+**Purpose**: Overall coverage can be healthy while the specific lines you changed
+are untested. This step catches that gap. If uncovered lines are found in
+feature code, add targeted tests before completing the task.
+
+**Prerequisites**: Coverage artifacts must exist before running the report:
+- `backend/coverage.txt` — generated by `scripts/go-test-coverage.sh`
+- `frontend/coverage/lcov.info` — generated by `scripts/frontend-test-coverage.sh`
 
 Run one of the following from `/projects/Charon`:
 
@@ -26,11 +36,14 @@ Test: Local Patch Report
 bash scripts/local-patch-report.sh
 ```
 
-Required artifacts:
+Required output artifacts:
 - `test-results/local-patch-report.md`
 - `test-results/local-patch-report.json`
 
-This preflight is advisory for thresholds during rollout, but artifact generation is required in DoD.
+**Action on results**: If patch coverage for any changed file is below 90%, add
+tests targeting the uncovered changed lines. Re-run coverage and this report to
+verify improvement. Artifact generation is required for DoD regardless of
+threshold results.
 
 ### PREREQUISITE: Start E2E Environment
 

.github/renovate.json

@@ -6,11 +6,11 @@
     ":separateMultipleMajorReleases",
     "helpers:pinGitHubActionDigests"
   ],
-  "baseBranches": [
+  "baseBranchPatterns": [
     "feature/beta-release",
     "development"
-
   ],
+  "postUpdateOptions": ["npmDedupe"],
   "timezone": "America/New_York",
   "dependencyDashboard": true,
   "dependencyDashboardApproval": true,
@@ -231,20 +231,39 @@
       "datasourceTemplate": "github-releases",
       "versioningTemplate": "semver",
       "extractVersionTemplate": "^v(?<version>.*)$"
+    },
+    {
+      "customType": "regex",
+      "description": "Track go-version in skill example workflows",
+      "managerFilePatterns": ["/^\\.github/skills/examples/.*\\.yml$/"],
+      "matchStrings": [
+        "go-version: [\"']?(?<currentValue>[\\d\\.]+)[\"']?"
+      ],
+      "depNameTemplate": "golang/go",
+      "datasourceTemplate": "golang-version",
+      "versioningTemplate": "semver"
     }
   ],
 
+  "github-actions": {
+    "managerFilePatterns": [
+      "/^\\.github/skills/examples/.*\\.ya?ml$/"
+    ]
+  },
+
   "packageRules": [
     {
       "description": "THE MEGAZORD: Group ALL non-major updates (NPM, Docker, Go, Actions) into one PR",
-      "matchPackagePatterns": ["*"],
       "matchUpdateTypes": [
         "minor",
         "patch",
         "pin",
         "digest"
       ],
-      "groupName": "non-major-updates"
+      "groupName": "non-major-updates",
+      "matchPackageNames": [
+        "*"
+      ]
     },
         {
       "description": "Feature branches: Auto-merge non-major updates after proven stable",
@@ -276,6 +295,24 @@
       "matchPackageNames": ["caddy"],
       "allowedVersions": "<3.0.0"
     },
+    {
+      "description": "Go: keep pgx within v4 (CrowdSec requires pgx/v4 module path)",
+      "matchDatasources": ["go"],
+      "matchPackageNames": ["github.com/jackc/pgx/v4"],
+      "allowedVersions": "<5.0.0"
+    },
+    {
+      "description": "Go: keep go-jose/v3 within v3 (v4 is a different Go module path)",
+      "matchDatasources": ["go"],
+      "matchPackageNames": ["github.com/go-jose/go-jose/v3"],
+      "allowedVersions": "<4.0.0"
+    },
+    {
+      "description": "Go: keep go-jose/v4 within v4 (v5 would be a different Go module path)",
+      "matchDatasources": ["go"],
+      "matchPackageNames": ["github.com/go-jose/go-jose/v4"],
+      "allowedVersions": "<5.0.0"
+    },
     {
       "description": "Safety: Keep MAJOR updates separate and require manual review",
       "matchUpdateTypes": ["major"],
@@ -287,6 +324,12 @@
       "matchDatasources": ["go"],
       "matchPackageNames": ["github.com/oschwald/geoip2-golang/v2"],
       "sourceUrl": "https://github.com/oschwald/geoip2-golang"
+    },
+    {
+      "description": "Fix Renovate lookup for google/uuid",
+      "matchDatasources": ["go"],
+      "matchPackageNames": ["github.com/google/uuid"],
+      "sourceUrl": "https://github.com/google/uuid"
     }
   ]
 }