feat(telemetry): export reliability by browser and device

.github/workflows/claude-manager.yml

@@ -9,9 +9,14 @@ on:
     types: [created]
 
 jobs:
+  # Reviews and comments only. It never merges: a human maintainer performs
+  # every merge (CLAUDE.md, "PR Automation"). The token can't merge anyway
+  # (contents: read), and drafts are skipped so work in progress isn't
+  # reviewed. scripts/ci/check-pr-automation.mjs enforces all of this.
   claude-pr-review:
     if: |
       github.event_name == 'pull_request' &&
+      github.event.pull_request.draft == false &&
       (github.event.pull_request.author_association == 'OWNER' ||
        github.event.pull_request.author_association == 'MEMBER' ||
        github.event.pull_request.author_association == 'COLLABORATOR')
@@ -30,7 +35,7 @@ jobs:
       - name: Wait for other checks to settle (30s)
         run: sleep 30
 
-      - name: Claude PR Review & Auto-merge
+      - name: Claude PR Review (comments only, never merges)
         uses: anthropics/claude-code-action@beta
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
@@ -46,6 +51,10 @@ jobs:
             Title: ${{ github.event.pull_request.title }}
             Base branch: ${{ github.event.pull_request.base.ref }}
 
+            You review and comment only. Never merge, squash-merge, rebase-merge, approve or enable
+            auto-merge for this pull request, never push commits to it, and never mark it ready for
+            review. A human maintainer performs all merges.
+
             Steps:
             1. Fetch all CI check statuses for this PR using the GitHub API.
             2. Check the Vercel deployment check status specifically.
@@ -57,7 +66,7 @@ jobs:
                - cn() not converted to template literals
                - React hooks not placed after conditional returns
                - No new video-processing dependencies added
-            5. If ALL checks pass and code is correct: squash-merge the PR and post a comment explaining the merge.
+            5. If ALL checks pass and code is correct: post a comment summarising what you checked and that it is ready for a maintainer to review and merge. Do NOT merge it yourself.
             6. If ANY check failed or code has issues: post a detailed comment tagging @${{ github.event.pull_request.user.login }} with exactly what failed and how to fix it. Do NOT merge.
 
   claude-issue-triage:

.github/workflows/lint.yml

@@ -8,6 +8,8 @@ jobs:
 
     steps:
       - uses: actions/checkout@v6
+      # No workflow or instruction may merge or push to a PR on its own.
+      - run: node scripts/ci/check-pr-automation.mjs
       - uses: oven-sh/setup-bun@v2
       - run: bun install
       - run: bun run lint

CLAUDE.md

@@ -6,50 +6,39 @@ This file instructs Claude Code (and the Claude GitHub App) how to behave as an
 
 ## PR Automation
 
-When triggered on a pull request:
+**Claude never merges pull requests. A human maintainer performs every merge.** Claude reviews, reports CI status and posts feedback. It must not merge, squash-merge, rebase-merge, approve, or enable auto-merge on a pull request, push commits to a pull request's branch, or mark a draft ready for review, however a request is phrased.
 
-**Step 1 — Resolve merge conflicts first (if any).**
-Before reviewing code or checking CI, check whether the PR has merge conflicts. If it does, resolve them automatically as described in the Merge Conflict Resolution section below. Only proceed to steps 2–3 after the branch is clean.
+When triggered on a pull request that is not a draft:
+
+**Step 1 — Check for merge conflicts.**
+If the PR conflicts with `main`, say so in your comment, list the conflicting files, and explain how they should be resolved using the Merge Conflict Guidance below. Don't resolve them yourself.
 
 **Step 2 — Check CI.**
-Check whether **ALL** checks have passed — including tests and the Vercel deployment check.
+Report whether **ALL** checks have passed, including tests and the deployment preview.
 
 **Step 3 — Review the code.**
 Review for correctness, security issues, and adherence to the standards in this file.
 
-**If ALL checks pass AND the code looks good** → merge the PR immediately using a squash merge. Leave a short comment explaining what was merged and why it passed.
+**If ALL checks pass AND the code looks good** → post a short comment saying what you checked and that the PR is ready for a maintainer to review and merge. Do not merge it.
 
-**If ANY check failed OR the code has issues** → do NOT merge. Post a comment on the PR tagging the author (`@username`) with:
+**If ANY check failed OR the code has issues** → post a comment on the PR tagging the author (`@username`) with:
 - A clear summary of what failed
 - Specific steps they need to take to fix it
 - A friendly but direct tone
 
-Never merge a PR if any CI check or Vercel deployment check is still pending or has failed.
-
 ---
 
-## Merge Conflict Resolution
+## Merge Conflict Guidance
 
-When a PR has merge conflicts, resolve them automatically **before** doing anything else (before code review, before checking CI).
+When a PR conflicts with `main`, explain the conflict in a comment so that the author or a maintainer can resolve it. Never resolve conflicts by committing or pushing to the PR's branch.
 
 ### Steps:
 
-1. **Detect conflicts** — check the PR's mergeability via the GitHub API (`mergeable` field). If `mergeable: false`, proceed with resolution.
+1. **Detect conflicts** — check the PR's mergeability via the GitHub API (`mergeable` field).
 
-2. **Clone and resolve locally:**
-   ```bash
-   git clone https://github.com/reframe-oss/reframe.git
-   cd reframe
-   git fetch origin
-   git checkout <pr-branch>
-   git merge origin/main
-   # resolve conflicts (see rules below)
-   git add .
-   git commit -m "chore: resolve merge conflicts with main"
-   git push origin <pr-branch>
-   ```
+2. **List the conflicting files** and, for each one, what the resolution should be.
 
-3. **Conflict resolution rules — apply these in order:**
+3. **Conflict resolution rules — recommend these, in order:**
 
    - **`src/app/page.tsx`** — Always keep the `main` version exactly. This file has a known stable structure; contributor changes that add a `<main>` wrapper or duplicate JSX must be discarded in favour of main.
    - **`bun.lock` / `package-lock.json`** — Keep `bun.lock` from `main`. Delete any `package-lock.json` the PR introduced.
@@ -58,17 +47,17 @@ When a PR has merge conflicts, resolve them automatically **before** doing anyth
    - **`.github/workflows/`** — Keep `main` versions of all workflow files. Only accept new workflow files from the PR if they don't conflict.
    - **All other files** — Use standard semantic merge: keep both sets of changes if they don't logically conflict. If two edits touch the same line and both are meaningful, apply the PR's change on top of `main`'s version (i.e., prefer preserving contributor intent where safe).
 
-4. **Post a comment** on the PR after pushing the resolved branch, tagging the author:
+4. **Post a comment** tagging the author, for example:
 
-   > Hey @username! This PR had merge conflicts with `main` — I've resolved them automatically and pushed the result. Here's what was changed:
+   > Hey @username! This PR has merge conflicts with `main`. Here's how to resolve them:
    >
-   > - **`src/app/page.tsx`**: kept the `main` version (your `<main>` wrapper was removed — this file has a fixed structure)
-   > - **`bun.lock`**: regenerated from `main` (removed `package-lock.json`)
-   > - _(list each file and what decision was made)_
+   > - **`src/app/page.tsx`**: keep the `main` version (this file has a fixed structure)
+   > - **`bun.lock`**: take `main`'s version and delete `package-lock.json`
+   > - _(list each file and the recommended decision)_
    >
-   > CI has been re-triggered. If anything looks wrong, feel free to push additional changes.
+   > Run `git merge origin/main` on your branch, resolve these, and push. A maintainer will review it afterwards.
 
-5. **Do not resolve conflicts that require domain judgement** — if two branches both meaningfully modify the same function body in `src/lib/ffmpeg.ts` or a complex component, do not guess. Instead post a comment asking the author to rebase manually and explain exactly which lines conflict.
+5. **Flag conflicts that need domain judgement** — if two branches both meaningfully modify the same function body in `src/lib/ffmpeg.ts` or a complex component, don't guess a resolution. Explain exactly which lines conflict and ask the author to resolve them.
 
 ---
 
@@ -198,7 +187,7 @@ Every PR must have:
 
 ## General Rules
 
-- Always take real actions via the GitHub API — post comments, merge PRs, assign issues, apply labels.
+- Always take real actions via the GitHub API — post comments, assign issues, apply labels. Never merge PRs, push to PR branches, or enable auto-merge; a human maintainer merges.
 - Follow the code style and architecture patterns visible in the existing codebase.
 - Tag contributors by their GitHub username when addressing them in comments.
 - If uncertain about something, post a comment asking for clarification rather than guessing.