CI Log Triage — sample deliverable

Scenario
A GitHub Actions job succeeds locally but fails on pull requests with:
  HTTP 403: Resource not accessible by integration

Finding
Category: Permission or authentication failure
Confidence: High for the failure class; repository-specific confirmation is still required.

Likely cause
The workflow attempts a write operation while running with a read-only event token. This commonly occurs on pull_request events, forked pull requests, or jobs without explicit permissions.

Evidence to confirm
1. Identify the first command returning HTTP 403.
2. Record the triggering event and whether the pull request comes from a fork.
3. Inspect the workflow-level and job-level permissions blocks.
4. Confirm whether the failing command needs contents:write, pull-requests:write, packages:write, or no write access at all.

Minimal repair plan
1. Keep untrusted pull-request code on a read-only token.
2. Move the write operation to a separate trusted workflow or remove it from fork-triggered runs.
3. Grant only the specific permission needed at job scope.
4. Add an explicit condition so the write step cannot run for forked pull requests.
5. Re-run the named failing check on the same revision.

Security note
Do not replace pull_request with pull_request_target while checking out and executing untrusted pull-request code. That can expose privileged tokens or secrets.

Acceptance criteria
- The named CI check passes on an internal pull request.
- A forked pull request still runs without access to write credentials.
- No unrelated workflow permissions are broadened.
- Existing tests and required checks remain enabled.

What the paid repair adds
- Repository-specific root-cause confirmation
- A minimal patch or exact diff
- Validation on the agreed revision
- A short handoff explaining the change and residual risks

This is an illustrative sample, not evidence of a completed customer order.