changed perms

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

.docker/compose/docker-compose.local.yml

@@ -47,7 +47,7 @@ services:
 #      - <PATH_TO_YOUR_CADDYFILE>:/import/Caddyfile:ro
 #      - <PATH_TO_YOUR_SITES_DIR>:/import/sites:ro # If your Caddyfile imports other files
     healthcheck:
-      test: ["CMD-SHELL", "curl -fsS http://localhost:8080/api/v1/health || exit 1"]
+      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:8080/api/v1/health || exit 1"]
       interval: 30s
       timeout: 10s
       retries: 3

.docker/compose/docker-compose.playwright-ci.yml

@@ -87,7 +87,7 @@ services:
       - playwright_caddy_config:/config
       - /var/run/docker.sock:/var/run/docker.sock:ro # For container discovery in tests
     healthcheck:
-      test: ["CMD", "curl", "-sf", "http://localhost:8080/api/v1/health"]
+      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:8080/api/v1/health || exit 1"]
       interval: 5s
       timeout: 3s
       retries: 12

.docker/compose/docker-compose.playwright-local.yml

@@ -48,11 +48,12 @@ services:
     tmpfs:
       # True tmpfs for E2E test data - fresh on every run, in-memory only
       # mode=1777 allows any user to write (container runs as non-root)
-      - /app/data:size=100M,mode=1777
+      # 256M gives headroom for the backup service's 100MB disk-space check
+      - /app/data:size=256M,mode=1777
     volumes:
       - /var/run/docker.sock:/var/run/docker.sock:ro # For container discovery in tests
     healthcheck:
-      test: ["CMD-SHELL", "curl -fsS http://localhost:8080/api/v1/health || exit 1"]
+      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:8080/api/v1/health || exit 1"]
       interval: 5s
       timeout: 5s
       retries: 10

.docker/compose/docker-compose.yml

@@ -52,7 +52,7 @@ services:
       # - ./my-existing-Caddyfile:/import/Caddyfile:ro
       # - ./sites:/import/sites:ro # If your Caddyfile imports other files
     healthcheck:
-      test: ["CMD-SHELL", "curl -fsS http://localhost:8080/api/v1/health || exit 1"]
+      test: ["CMD-SHELL", "wget -qO /dev/null http://localhost:8080/api/v1/health || exit 1"]
       interval: 30s
       timeout: 10s
       retries: 3

.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)
@@ -365,7 +378,7 @@ echo "Caddy started (PID: $CADDY_PID)"
 echo "Waiting for Caddy admin API..."
 i=1
 while [ "$i" -le 30 ]; do
-    if curl -sf http://127.0.0.1:2019/config/ > /dev/null 2>&1; then
+    if wget -qO /dev/null http://127.0.0.1:2019/config/ 2>/dev/null; then
         echo "Caddy is ready!"
         break
     fi

.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,27 +59,26 @@ 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.
 
 6. **Phase 6: Audit**:
+    - Review Security: Read `security.md.instrutctions.md` and `SECURITY.md` to understand the security requirements and best practices for Charon. Ensure that any open concerns or issues are addressed in the QA Audit and `SECURITY.md` is updated accordingly.
     - **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`.
     - **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**:
@@ -166,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/instructions/security.md.instructions.md

@@ -0,0 +1,204 @@
+---
+applyTo: SECURITY.md
+---
+
+# Instructions: Maintaining `SECURITY.md`
+
+`SECURITY.md` is the project's living security record. It serves two audiences simultaneously: users who need to know what risks exist right now, and the broader community who need confidence that vulnerabilities are being tracked and remediated with discipline. Treat it like a changelog, but for security events — every known issue gets an entry, every resolved issue keeps its entry.
+
+---
+
+## File Structure
+
+`SECURITY.md` must always contain the following top-level sections, in this order:
+
+1. A brief project security policy preamble (responsible disclosure contact, response SLA)
+2. **`## Known Vulnerabilities`** — active, unpatched issues
+3. **`## Patched Vulnerabilities`** — resolved issues, retained permanently for audit trail
+
+No other top-level sections are required. Do not collapse or remove sections even when they are empty — use the explicit empty-state placeholder defined below.
+
+---
+
+## Section 1: Known Vulnerabilities
+
+This section lists every vulnerability that is currently unpatched or only partially mitigated. Entries must be sorted with the highest severity first, then by discovery date descending within the same severity tier.
+
+### Entry Format
+
+Each entry is an H3 heading followed by a structured block:
+
+```markdown
+### [SEVERITY] CVE-XXXX-XXXXX · Short Title
+
+| Field        | Value |
+|--------------|-------|
+| **ID**       | CVE-XXXX-XXXXX (or `CHARON-YYYY-NNN` if no CVE assigned yet) |
+| **Severity** | Critical / High / Medium / Low · CVSS v3.1 score if known (e.g. `8.1 · High`) |
+| **Status**   | Investigating / Fix In Progress / Awaiting Upstream / Mitigated (partial) |
+
+**What**
+One to three sentences describing the vulnerability class and its impact.
+Be specific: name the weakness type (e.g. SQL injection, path traversal, SSRF).
+
+**Who**
+- Discovered by: [Reporter name or handle, or "Internal audit", or "Automated scan (tool name)"]
+- Reported: YYYY-MM-DD
+- Affects: [User roles, API consumers, unauthenticated users, etc.]
+
+**Where**
+- Component: [Module or service name]
+- File(s): `path/to/affected/file.go`, `path/to/other/file.ts`
+- Versions affected: `>= X.Y.Z` (or "all versions" / "prior to X.Y.Z")
+
+**When**
+- Discovered: YYYY-MM-DD
+- Disclosed (if public): YYYY-MM-DD (or "Not yet publicly disclosed")
+- Target fix: YYYY-MM-DD (or sprint/milestone reference)
+
+**How**
+A concise technical description of the attack vector, prerequisites, and exploitation
+method. Omit proof-of-concept code. Reference CVE advisories or upstream issue
+trackers where appropriate.
+
+**Planned Remediation**
+Describe the fix strategy: library upgrade, logic refactor, config change, etc.
+If a workaround is available in the meantime, document it here.
+Link to the tracking issue: [#NNN](https://github.com/owner/repo/issues/NNN)
+```
+
+### Empty State
+
+When there are no known vulnerabilities:
+
+```markdown
+## Known Vulnerabilities
+
+No known unpatched vulnerabilities at this time.
+Last reviewed: YYYY-MM-DD
+```
+
+---
+
+## Section 2: Patched Vulnerabilities
+
+This section is a permanent, append-only ledger. Entries are never deleted. Sort newest-patched first. This section builds community trust by demonstrating that issues are resolved promptly and transparently.
+
+### Entry Format
+
+```markdown
+### ✅ [SEVERITY] CVE-XXXX-XXXXX · Short Title
+
+| Field        | Value |
+|--------------|-------|
+| **ID**       | CVE-XXXX-XXXXX (or internal ID) |
+| **Severity** | Critical / High / Medium / Low · CVSS v3.1 score |
+| **Patched**  | YYYY-MM-DD in `vX.Y.Z` |
+
+**What**
+Same description carried over from the Known Vulnerabilities entry.
+
+**Who**
+- Discovered by: [Reporter or method]
+- Reported: YYYY-MM-DD
+
+**Where**
+- Component: [Module or service name]
+- File(s): `path/to/affected/file.go`
+- Versions affected: `< X.Y.Z`
+
+**When**
+- Discovered: YYYY-MM-DD
+- Patched: YYYY-MM-DD
+- Time to patch: N days
+
+**How**
+Same technical description as the original entry.
+
+**Resolution**
+Describe exactly what was changed to fix the issue.
+- Commit: [`abc1234`](https://github.com/owner/repo/commit/abc1234)
+- PR: [#NNN](https://github.com/owner/repo/pull/NNN)
+- Release: [`vX.Y.Z`](https://github.com/owner/repo/releases/tag/vX.Y.Z)
+
+**Credit**
+[Optional] Thank the reporter if they consented to attribution.
+```
+
+### Empty State
+
+```markdown
+## Patched Vulnerabilities
+
+No patched vulnerabilities on record yet.
+```
+
+---
+
+## Lifecycle: Moving an Entry from Known → Patched
+
+When a fix ships:
+
+1. Remove the entry from `## Known Vulnerabilities` entirely.
+2. Add a new entry to the **top** of `## Patched Vulnerabilities` using the patched format above.
+3. Carry forward all original fields verbatim — do not rewrite the history of the issue.
+4. Add the `**Resolution**` and `**Credit**` blocks with patch details.
+5. Update the `Last reviewed` date on the Known Vulnerabilities section if it is now empty.
+
+Do not edit or backfill existing Patched entries once they are committed.
+
+---
+
+## Severity Classification
+
+Use the following definitions consistently:
+
+| Severity | CVSS Range | Meaning |
+|----------|------------|---------|
+| **Critical** | 9.0–10.0 | Remote code execution, auth bypass, full data exposure |
+| **High**     | 7.0–8.9  | Significant data exposure, privilege escalation, DoS |
+| **Medium**   | 4.0–6.9  | Limited data exposure, requires user interaction or auth |
+| **Low**      | 0.1–3.9  | Minimal impact, difficult to exploit, defense-in-depth |
+
+When a CVE CVSS score is not yet available, assign a preliminary severity based on these definitions and note it as `(preliminary)` until confirmed.
+
+---
+
+## Internal IDs
+
+If a vulnerability has no CVE assigned, use the format `CHARON-YYYY-NNN` where `YYYY` is the year and `NNN` is a zero-padded sequence number starting at `001` for each year. Example: `CHARON-2025-003`. Assign a CVE ID in the entry retroactively if one is issued later, and add the internal ID as an alias in parentheses.
+
+---
+
+## Responsible Disclosure Preamble
+
+The preamble at the top of `SECURITY.md` (before the vulnerability sections) must include:
+
+- The preferred contact method for reporting vulnerabilities (e.g. a GitHub private advisory link, a security email address, or both)
+- An acknowledgment-first response commitment: confirm receipt within 48 hours, even if the full investigation takes longer
+- A statement that reporters will not be penalized or publicly named without consent
+- A link to the full disclosure policy if one exists
+
+Example:
+
+```markdown
+## Reporting a Vulnerability
+
+To report a security issue, please use
+[GitHub Private Security Advisories](https://github.com/owner/repo/security/advisories/new)
+or email `security@example.com`.
+
+We will acknowledge your report within **48 hours** and provide a remediation
+timeline within **7 days**. Reporters are credited with their consent.
+We do not pursue legal action against good-faith security researchers.
+```
+
+---
+
+## Maintenance Rules
+
+- **Review cadence**: Update the `Last reviewed` date in the Known Vulnerabilities section at least once per release cycle, even if no entries changed.
+- **No silent patches**: Every security fix — no matter how minor — must produce an entry in `## Patched Vulnerabilities` before or alongside the release.
+- **No redaction**: Do not redact or soften historical entries. Accuracy builds trust; minimizing past issues destroys it.
+- **Dependency vulnerabilities**: Transitive dependency CVEs that affect Charon's exposed attack surface must be tracked here the same as first-party vulnerabilities. Pure dev-dependency CVEs with no runtime impact may be omitted at maintainer discretion, but must still be noted in the relevant dependency update PR.
+- **Partial mitigations**: If a workaround is deployed but the root cause is not fixed, the entry stays in `## Known Vulnerabilities` with `Status: Mitigated (partial)` and the workaround documented in `**Planned Remediation**`.

.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,
@@ -130,6 +130,32 @@
       "datasourceTemplate": "go",
       "versioningTemplate": "semver"
     },
+    {
+      "customType": "regex",
+      "description": "Track gotestsum version in codecov workflow",
+      "managerFilePatterns": [
+        "/^\\.github/workflows/codecov-upload\\.yml$/"
+      ],
+      "matchStrings": [
+        "gotestsum@v(?<currentValue>[^\\s]+)"
+      ],
+      "depNameTemplate": "gotest.tools/gotestsum",
+      "datasourceTemplate": "go",
+      "versioningTemplate": "semver"
+    },
+    {
+      "customType": "regex",
+      "description": "Track gotestsum version in quality checks workflow",
+      "managerFilePatterns": [
+        "/^\\.github/workflows/quality-checks\\.yml$/"
+      ],
+      "matchStrings": [
+        "gotestsum@v(?<currentValue>[^\\s]+)"
+      ],
+      "depNameTemplate": "gotest.tools/gotestsum",
+      "datasourceTemplate": "go",
+      "versioningTemplate": "semver"
+    },
     {
       "customType": "regex",
       "description": "Track govulncheck version in scripts",
@@ -205,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",
@@ -250,11 +295,41 @@
       "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"],
       "automerge": false,
       "labels": ["manual-review"]
+    },
+    {
+      "description": "Fix Renovate lookup for geoip2-golang v2 module path",
+      "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"
     }
   ]
 }