ci(search): automate domain-credibility list refresh

.github/workflows/credibility-list-refresh.yml

@@ -0,0 +1,104 @@
+name: Credibility List Refresh
+
+# Scheduled maintenance for the keyless search engine's domain-credibility list
+# (src-tauri/src/websearch/credibility.rs). Regenerates the autogenerated
+# regions of credibility_domains.txt from upstream license-clean sources and
+# opens a reviewable PR when the diff is non-empty. Mirrors the existing
+# Renovate engine-bump pattern (#238): automation proposes, a human reviews and
+# merges, updates ship with releases. The app itself never fetches these lists
+# at runtime; this is dev/CI tooling only.
+#
+# Note: this PR is opened with the default GITHUB_TOKEN, so per
+# https://github.com/peter-evans/create-pull-request/blob/main/docs/concepts-guidelines.md#triggering-further-workflow-runs
+# it will not trigger this repo's other pull_request-triggered CI workflows.
+# A reviewer must push an empty commit, or close and reopen the PR, to get CI
+# to run on it before merging.
+
+on:
+  schedule:
+    # Weekly, 06:17 UTC on Mondays. Off-the-hour minute to avoid the
+    # scheduled-workflow thundering herd at :00.
+    - cron: '17 6 * * 1'
+  workflow_dispatch:
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  refresh:
+    name: Refresh credibility list
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          fetch-depth: 1
+
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6 # v2.2.0
+        with:
+          bun-version: 1.3.11
+
+      - name: Install dependencies
+        run: bun install --frozen-lockfile
+
+      - name: Run credibility list refresh
+        id: refresh
+        run: bun scripts/refresh-credibility-list.ts --summary refresh-summary.md
+
+      - name: Append summary to job summary
+        if: always()
+        run: |
+          if [ -f refresh-summary.md ]; then
+            cat refresh-summary.md >> "$GITHUB_STEP_SUMMARY"
+          fi
+
+      - name: Check for changes
+        id: diff
+        run: |
+          if git diff --quiet -- src-tauri/src/websearch/credibility_domains.txt; then
+            echo "changed=false" >> "$GITHUB_OUTPUT"
+          else
+            echo "changed=true" >> "$GITHUB_OUTPUT"
+          fi
+
+      - name: Open pull request
+        if: steps.diff.outputs.changed == 'true'
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: |
+          set -euo pipefail
+          branch=chore/credibility-list-refresh
+          git config user.name 'github-actions[bot]'
+          git config user.email '41898282+github-actions[bot]@users.noreply.github.com'
+          git checkout -B "$branch"
+          git add src-tauri/src/websearch/credibility_domains.txt
+          git commit -s -m 'chore(search): refresh domain-credibility list'
+          git push --force origin "$branch"
+
+          {
+            echo "Automated refresh of the autogenerated regions in"
+            echo "\`src-tauri/src/websearch/credibility_domains.txt\`"
+            echo "from upstream license-clean sources. See the summary below for"
+            echo "per-region counts and the added/removed domains."
+            echo ""
+            echo "This PR was opened with the default \`GITHUB_TOKEN\`, so it will"
+            echo "not trigger this repo's other pull_request-triggered CI"
+            echo "workflows. Push an empty commit, or close and reopen this PR,"
+            echo "to run CI before merging."
+            echo ""
+            cat refresh-summary.md
+          } > pr-body.md
+
+          existing=$(gh pr list --head "$branch" --state open --json number --jq '.[0].number // empty')
+          if [ -n "$existing" ]; then
+            gh pr edit "$existing" --body-file pr-body.md
+          else
+            gh pr create \
+              --base main \
+              --head "$branch" \
+              --title 'chore(search): refresh domain-credibility list' \
+              --body-file pr-body.md
+          fi

docs/built-in-web-search.md

@@ -559,6 +559,8 @@ Code: `judge.rs`, `orchestrator.rs`.
 **Example.**  
 Query `openai ceo` → DuckDuckGo ranks A,B,C; Mojeek ranks B,D → B’s RRF score wins → fetch B first.
 
+**Maintenance.** The bulk-imported penalize clusters in `credibility_domains.txt` are refreshed by a scheduled GitHub Action that pulls the latest upstream license-clean spam/copycat lists and opens a reviewable PR when the diff is non-empty; a human still reviews and merges every change. The app itself never fetches these lists at runtime, so the no-phone-home privacy stance is unchanged; updates only ship inside a release.
+
 Code: `engine.rs`, `credibility.rs`.
 
 ---

docs/search-eval.md

@@ -118,6 +118,10 @@ Deterministic-first, never pairwise, never a rubric score:
 
 Before trusting the gate, hand-label a sample of 30-40 rows spanning all three graded sources and volatility buckets with your own CORRECT/INCORRECT/NOT_ATTEMPTED judgment against the same predicted answers the harness generated, then run the live judge (majority-of-3) over that identical sample and compute agreement: the fraction of rows where the judge's majority verdict matches your hand label. This is the only way to know whether the local judge model is reliable enough for `CONFIDENTLY_WRONG_GATE` to mean anything, and is a prerequisite for tightening it. It needs a live model and a human rater (Logan), so it is a documented manual procedure, not code in this repository.
 
+## Related automation
+
+These harnesses are dev-machine tools, run by hand as documented above; no CI workflow executes them. The domain-credibility list has its own scheduled refresh workflow (`.github/workflows/credibility-list-refresh.yml`); see [built-in-web-search.md](./built-in-web-search.md) for that automation.
+
 ## Judging: pairwise superseded by absolute SimpleQA grading
 
 An earlier revision of this doc sketched pairwise, position-swapped LLM-as-judge scoring, following [Brave's published search-eval methodology](https://brave.com/blog/), as the intended next step once two capture runs existed to compare: an LLM judge shown both runs' answers in one order, then the swapped order, with a majority vote across both orderings deciding the winner or a tie.