Release v3.6.9

.agents/workflows/generate-release.md

@@ -159,21 +159,29 @@ git push origin release/v2.x.y
 
 ### 9. Open PR to main
 
+### 9. Open PR to main
+
+// turbo
+
 ```bash
-gh pr create \
-  --repo diegosouzapw/OmniRoute \
-  --base main \
-  --head release/v2.x.y \
-  --title "chore(release): v2.x.y — summary" \
-  --body "## 🚀 Release v2.x.y
+VERSION=$(node -p "require('./package.json').version")
 
-### Changes
-...
+# Extract the exact changelog entry for this version from the root CHANGELOG.md
+awk "/^## \\[$VERSION\\]/{flag=1; print; next} /^---/{if(flag) {flag=0; exit}} flag" CHANGELOG.md > /tmp/changelog_body.txt
 
-### Tests
-- X/X tests pass
+# Append test status and next steps
+echo "" >> /tmp/changelog_body.txt
+echo "### Tests" >> /tmp/changelog_body.txt
+echo "- All tests pass" >> /tmp/changelog_body.txt
+echo "" >> /tmp/changelog_body.txt
+echo "### ⚠️ After merging: run Phase 2 steps to tag, publish, and deploy." >> /tmp/changelog_body.txt
 
-### ⚠️ After merging: run Phase 2 steps to tag, publish, and deploy."
+gh pr create \
+  --repo diegosouzapw/OmniRoute \
+  --base main \
+  --head release/v$VERSION \
+  --title "Release v$VERSION" \
+  --body-file /tmp/changelog_body.txt
 ```
 
 ### 10. 🛑 STOP — Notify User & Await PR Confirmation

.agents/workflows/resolve-issues.md

@@ -6,7 +6,7 @@ description: Fetch all open GitHub issues, analyze bugs, resolve what's possible
 
 ## Overview
 
-This workflow fetches all open issues from the project's GitHub repository, classifies them, analyzes bugs, resolves what can be fixed, and triages issues with insufficient information. **All fixes are committed on the current release branch** (`release/vX.Y.Z`). It does NOT merge or release automatically — the release branch is later merged via PR to main.
+This workflow fetches all open issues from the project's GitHub repository, classifies them, analyzes bugs, proposes a resolution plan, waits for user validation, and ONLY THEN implements the fixes, commits, and closes the issues on the current release branch (`release/vX.Y.Z`). It does NOT merge or release automatically — the release branch is later merged via PR to main.
 
 > **BRANCH RULE**: All work MUST happen on the current `release/vX.Y.Z` branch. Never create separate `fix/` branches. If no release branch exists yet, create one first using `/generate-release` Phase 1 steps 1–5.
 
@@ -96,26 +96,25 @@ Verify the issue contains enough to act on:
 
 For each bug, classify into one of 5 actions:
 
-| Disposition                  | When to Apply                                                                               | Action                                              |
-| ---------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------- |
-| **✅ CLOSE — Already Fixed** | Owner responded with fix + no user follow-up, OR community confirmed fix                    | Close with comment citing which version fixed it    |
-| **✅ CLOSE — Duplicate**     | Bot flagged >85% similarity + user provides no new info                                     | Close referencing the original issue                |
-| **✅ CLOSE — Stale**         | We requested logs/info > 7 days ago with no reply                                           | Close thanking the user, invite to reopen if needed |
-| **📝 RESPOND — Needs Info**  | Issue is real but missing critical reproduction details                                     | Comment asking for specifics per `/issue-triage`    |
-| **📝 RESPOND — User Config** | Error is caused by unsupported env (Node version, wrong model path, missing API enablement) | Comment explaining the user-side fix                |
-| **🔧 FIX — Code Change**     | Root cause is confirmed in the codebase                                                     | Research, implement, test, commit on release branch |
+| Disposition                  | When to Apply                                                                               | Action                                                  |
+| ---------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
+| **✅ CLOSE — Already Fixed** | Owner responded with fix + no user follow-up, OR community confirmed fix                    | Close with comment citing which version fixed it        |
+| **✅ CLOSE — Duplicate**     | Bot flagged >85% similarity + user provides no new info                                     | Close referencing the original issue                    |
+| **✅ CLOSE — Stale**         | We requested logs/info > 7 days ago with no reply                                           | Close thanking the user, invite to reopen if needed     |
+| **📝 RESPOND — Needs Info**  | Issue is real but missing critical reproduction details                                     | Comment asking for specifics per `/issue-triage`        |
+| **📝 RESPOND — User Config** | Error is caused by unsupported env (Node version, wrong model path, missing API enablement) | Comment explaining the user-side fix                    |
+| **🔧 FIX — Code Change**     | Root cause is confirmed in the codebase                                                     | Research, propose solution in report, wait for approval |
 
 #### 5d. For "FIX — Code Change" Issues
 
-Before coding, perform deep source analysis:
+Before coding, perform deep source analysis to formulate a plan:
 
 1. **Search the codebase** — `grep_search` for error strings, relevant function names, affected files
 2. **Search the web** — for upstream API changes, SDK updates, or breaking changes that explain the bug
 3. **Read the full source file** — don't rely on grep snippets; understand the surrounding logic
 4. **Verify the root cause** — confirm the bug is reproducible based on the code, not just a user misconfiguration
-5. **Implement the fix** — follow existing code patterns and conventions
-6. **Run tests** — `node --import tsx/esm --test tests/unit/*.test.mjs` (must pass 100%)
-7. **Commit** — `fix: <description> (#<issue_number>)`
+5. **Formulate a proposed solution** — detail the exact files and lines you will change and how you will solve it.
+6. **DO NOT modify the codebase yet** — wait for user approval on your report first.
 
 #### 5e. For "RESPOND" Issues
 
@@ -130,33 +129,35 @@ Post a substantive comment that:
 
 ### 6. Generate Report & Wait for Validation
 
-Present a summary report to the user. For any bugs that have been fixed, you MUST explicitly explain to the user the version that the fix was applied to (e.g., `release/vX.Y.Z`) and point out that it will be included in the next release.
+Present a summary report to the user detailing your proposed actions. For any bugs that need fixing, explicitly explain your proposed solution (files to change and logic) and point out that it will be implemented on the release branch (`release/vX.Y.Z`) after approval.
 
-| Issue | Title | Status        | Action / Version                   |
-| ----- | ----- | ------------- | ---------------------------------- |
-| #N    | Title | ✅ Closed     | Already fixed / duplicate          |
-| #N    | Title | 🔧 Fixed      | Code fix applied in release/vX.Y.Z |
-| #N    | Title | 📝 Responded  | Guidance comment posted            |
-| #N    | Title | ❓ Needs Info | Triage comment posted              |
-| #N    | Title | ⏭️ Skipped    | Feature request / not a bug        |
+| Issue | Title | Status        | Proposed Action / Version                 |
+| ----- | ----- | ------------- | ----------------------------------------- |
+| #N    | Title | ✅ Close      | Already fixed / duplicate (explain why)   |
+| #N    | Title | 🔧 Propose    | Explanation of the code fix to be applied |
+| #N    | Title | 📝 Respond    | Guidance comment to be posted             |
+| #N    | Title | ❓ Needs Info | Triage comment to be posted               |
+| #N    | Title | ⏭️ Skip       | Feature request / not a bug               |
 
-> **⚠️ IMPORTANT**: Do NOT commit, push, or close issues at this step.
-> Wait for the user to review the changes and respond with **OK** before proceeding.
+> **⚠️ IMPORTANT**: Do NOT implement code changes, commit, push, or close issues at this step.
+> Wait for the user to review the proposed fixes and respond with **OK** before proceeding.
 
 - If the user says **OK** or approves → Proceed to step 7
-- If the user requests changes → Apply the requested adjustments first, then present the report again
-- If the user rejects → Revert the changes and stop
-
-### 7. Commit, Push & Close Issues (only after user approval)
-
-After the user validates and gives the OK to commit:
-
-1. **Update CHANGELOG.md** with all new bug fix entries.
-2. **Commit** each fix individually on the release branch with message format: `fix: <description> (#<issue_number>)`.
-3. **Push** the release branch: `git push origin release/vX.Y.Z`.
-4. **Close resolved issues immediately**. For each issue that was marked as Fixed, run:
-   `gh issue close <NUMBER> --repo <owner>/<repo> --comment "Fixed in release/vX.Y.Z. The fix will be included in the next release."`
-5. Likewise, close `Duplicate` or `Needs Info` issues as needed with relevant comments.
-6. If the project runs automatic releases or needs a PR, proceed to run `/generate-release` workflow Phase 1 steps 7–10 (tests → commit → push → open PR to main → wait for user).
+- If the user requests changes → Adjust the proposed solution and present the report again
+- If the user rejects → Revert any accidental changes and stop
+
+### 7. Implement Fixes, Run Tests & Commit (only after user approval)
+
+After the user validates and gives the OK:
+
+1. **Implement the fixes** — modify the codebase according to the approved plan.
+2. **Run tests** — `npm run test:all` (or the specific test file) to ensure 100% pass.
+3. **Update CHANGELOG.md** with all new bug fix entries.
+4. **Commit** each fix individually on the release branch with message format: `fix: <description> (#<issue_number>)`.
+5. **Push** the release branch: `git push origin release/vX.Y.Z`.
+6. **Close resolved issues immediately**. For each issue that was marked as Fixed, run:
+   `gh issue close <NUMBER> --repo <owner>/<repo> --comment "Thank you for reporting! This issue has been fixed and will be included in the next release (vX.Y.Z)."`
+7. Likewise, close `Duplicate` issues referencing the original, close `Needs Info` if stale, and post the required comments.
+8. If the project runs automatic releases or needs a PR, proceed to run `/generate-release` workflow Phase 1 steps 7–10 (tests → commit → push → open PR to main → wait for user).
 
 If NO fixes were committed, skip closing and source control steps and just conclude the workflow.

.agents/workflows/review-prs.md

@@ -163,9 +163,9 @@ Perform a **global impact assessment** to verify whether the PR changes are comp
 
 ### 7. Pre-Merge Fixes & CI Green-Lighting (if approved)
 
-> **⚠️ Fixes should be pushed back to the PR branch before merging.** We want the PR itself to be green and fully valid before it integrates.
+> **⚠️ Fixes and Conflict Resolutions MUST be pushed back to the PR branch before merging.** We want the PR itself to be green and fully valid before it integrates.
 
-- **Sync latest fixes:** Merge the current `release` branch into the PR branch so the PR inherits any latest CI or integration test fixes (preventing false-positive failures).
+- **Sync latest fixes & Resolve Conflicts:** Merge the current `release` branch into the PR branch. If there are merge conflicts, you MUST resolve them inside the author's PR branch. NEVER resolve conflicts by closing their PR and doing the work in a separate branch, as this steals credit from the original author.
 - **Implement improvements:** Apply the required fixes identified in the analysis directly on the PR branch (e.g., adding missing API routes, fixing SSRF, applying comments from other agents).
 - **Pushing changes to PR branches:**
 
@@ -193,34 +193,30 @@ Perform a **global impact assessment** to verify whether the PR changes are comp
 
 ### 8. Merge into Release Branch
 
-### 8. Merge into Release Branch (NEVER SILENTLY CLOSE!)
+### 8. Merge into Release Branch (NEVER CLOSE!)
 
-> **⚠️ CRITICAL**: NEVER use `gh pr close` for a PR whose idea or code was accepted, even if you had to rewrite it manually. Closing a PR in a contributor's face after taking their idea is unacceptable.
-> ALWAYS ensure the contributor gets proper credit.
+> **⚠️ CRITICAL**: NEVER use `gh pr close` for a PR whose idea or code was accepted. Closing a PR in a contributor's face after taking their idea—or closing it just because it had conflicts—is unacceptable.
+> You MUST ALWAYS resolve conflicts and apply fixes on the author's PR branch, and then merge the PR using GitHub so the contributor gets the official "Merged" badge and proper credit on their profile.
 
-If the PR is green and can be merged directly:
+Even if the PR had severe conflicts or required significant architectural adjustments, you MUST:
 
-- Merge the PR into the release branch using the GitHub CLI.
-  ```bash
-  # Merge the PR (base is already set to release/vX.Y.Z from step 3.5)
-  gh pr merge <NUMBER> --repo <owner>/<repo> --squash --body "Integrated into release/vX.Y.Z"
-  ```
-
-If the PR had severe conflicts or you had to implement the feature manually on our branch instead:
+1. Resolve any conflicts and apply the fixes directly to their PR branch (as detailed in step 7).
+2. Once the PR branch is green, conflict-free, and correct, merge it into the release branch using the GitHub CLI.
 
-- You MUST still post a comment giving them full credit before closing it.
-- Explain that their idea was great, that it was integrated in a specific commit (mention the commit hash), and that due to merge conflicts or architectural adjustments, it was integrated manually.
-- Add their name as a Co-authored-by in the manual commit if possible.
+```bash
+# Merge the PR (base is already set to release/vX.Y.Z from step 3.5)
+gh pr merge <NUMBER> --repo <owner>/<repo> --squash --body "Integrated into release/vX.Y.Z"
+```
 
-In ALL accepted cases (merged directly or implemented manually):
+In ALL cases:
 
-- Post a **thank-you comment** on the PR via the GitHub API.
+- Post a **thank-you comment** on the PR via the GitHub API before or immediately after merging.
 - The message should:
   - Thank the author by name/username for their contribution.
-  - Explain what was adjusted or improved (if anything).
+  - Explain what was adjusted or improved (if we pushed fixes to their branch).
   - Note it will be included in the upcoming release.
   - Be friendly, professional, and encouraging.
-- Example: _"Thanks @author for this great contribution! 🎉 The [feature/fix] has been integrated into the release/vX.Y.Z branch and will be part of the next release. We appreciate your effort!"_
+- Example: _"Thanks @author for this great contribution! 🎉 We've added a few small adjustments to your branch to align with our latest architecture, and it's now officially merged into the release/vX.Y.Z branch. It will be part of the next release. We appreciate your effort!"_
 
 ### 9. Sync Local Release Branch
 

.github/workflows/ci.yml

@@ -6,6 +6,7 @@ on:
   pull_request:
     branches: [main]
     types: [opened, synchronize, reopened, ready_for_review]
+  workflow_dispatch:
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
@@ -111,7 +112,7 @@ jobs:
         uses: trufflesecurity/trufflehog@main
         with:
           path: ./
-          base: ${{ github.event.repository.default_branch }}
+          base: ${{ github.event.before || github.event.repository.default_branch }}
           head: HEAD
           extra_args: --only-verified
 
@@ -168,10 +169,14 @@ jobs:
       - run: npm run check:pack-artifact
 
   test-unit:
-    name: Unit Tests
+    name: Unit Tests (${{ matrix.shard }}/2)
     runs-on: ubuntu-latest
     timeout-minutes: 15
     needs: build
+    strategy:
+      fail-fast: false
+      matrix:
+        shard: [1, 2]
     env:
       JWT_SECRET: ci-test-secret-with-sufficient-length-for-validation
       API_KEY_SECRET: ci-test-api-key-secret-long
@@ -184,13 +189,17 @@ jobs:
           cache: npm
       - run: npm ci
       - run: npm run check:node-runtime
-      - run: npm run test:unit
+      - run: node --import tsx/esm --test --test-concurrency=1 --test-shard=${{ matrix.shard }}/2 tests/unit/*.test.ts
 
   node-24-compat:
-    name: Node 24 Compatibility
+    name: Node 24 Compatibility (${{ matrix.shard }}/2)
     runs-on: ubuntu-latest
     timeout-minutes: 15
     needs: build
+    strategy:
+      fail-fast: false
+      matrix:
+        shard: [1, 2]
     env:
       JWT_SECRET: ci-test-secret-with-sufficient-length-for-validation
       API_KEY_SECRET: ci-test-api-key-secret-long
@@ -204,12 +213,12 @@ jobs:
       - run: npm ci
       - run: npm run check:node-runtime
       - run: npm run build
-      - run: npm run test:unit
+      - run: node --import tsx/esm --test --test-concurrency=1 --test-shard=${{ matrix.shard }}/2 tests/unit/*.test.ts
 
   test-coverage:
     name: Coverage
     runs-on: ubuntu-latest
-    timeout-minutes: 15
+    timeout-minutes: 30
     needs: build
     env:
       JWT_SECRET: ci-test-secret-with-sufficient-length-for-validation
@@ -359,14 +368,14 @@ jobs:
             }
 
   test-e2e:
-    name: E2E Tests (${{ matrix.shard }}/4)
+    name: E2E Tests (${{ matrix.shard }}/6)
     runs-on: ubuntu-latest
-    timeout-minutes: 15
+    timeout-minutes: 20
     needs: build
     strategy:
       fail-fast: false
       matrix:
-        shard: [1, 2, 3, 4]
+        shard: [1, 2, 3, 4, 5, 6]
     env:
       JWT_SECRET: ci-test-secret-with-sufficient-length-for-validation
       API_KEY_SECRET: ci-test-api-key-secret-long
@@ -381,18 +390,22 @@ jobs:
       - run: npm run check:node-runtime
       - run: npx playwright install --with-deps chromium
       - run: npm run build
-      - run: npx playwright test tests/e2e/*.spec.ts --shard=${{ matrix.shard }}/4
+      - run: npx playwright test tests/e2e/*.spec.ts --shard=${{ matrix.shard }}/6
 
   test-integration:
-    name: Integration Tests
+    name: Integration Tests (${{ matrix.shard }}/2)
     runs-on: ubuntu-latest
-    timeout-minutes: 10
+    timeout-minutes: 15
     needs: build
+    strategy:
+      fail-fast: false
+      matrix:
+        shard: [1, 2]
     env:
       JWT_SECRET: ci-test-secret-with-sufficient-length-for-validation
       API_KEY_SECRET: ci-test-api-key-secret-long
       INITIAL_PASSWORD: ci-test-password-for-integration
-      DATA_DIR: /tmp/omniroute-ci
+      DATA_DIR: /tmp/omniroute-ci-${{ matrix.shard }}
       DISABLE_SQLITE_AUTO_BACKUP: "true"
     steps:
       - uses: actions/checkout@v6
@@ -402,7 +415,7 @@ jobs:
           cache: npm
       - run: npm ci
       - run: npm run check:node-runtime
-      - run: npm run test:integration
+      - run: node --import tsx/esm --test --test-shard=${{ matrix.shard }}/2 tests/integration/*.test.ts
 
   test-security:
     name: Security Tests