Review agent: sticky comment should link to the execution that updated it

[maruiz93]

What happens

When the review agent re-reviews a PR, it updates its sticky comment in-place with the latest findings. A separate status comment records the workflow run URL and timestamps. These two comments are not linked — a reader must manually cross-reference timestamps and head SHAs between them to determine which run produced the current findings.

What should happen

Each time the sticky comment is updated, it should be possible to trace which execution produced the current content. The provenance could point to the status comment on the PR, to the workflow run directly, or to both — whatever makes the audit trail easiest to follow.

Context

Observed on PR #481 after three consecutive review agent runs. The sticky comment body changed across runs (findings were resolved, new ones appeared) but there was no indication of which run produced the current state. The only way to trace provenance was to match the <!-- **Head SHA:** ... --> HTML comment against the status comments' timestamps.

This is a traceability gap. The sticky comment is the primary artifact readers consult for review findings, but it lacks attribution to the process that produced it. Linking the execution makes the review audit trail self-contained — no cross-referencing needed.

[fullsend-ai-triage]

🤖 Finished Triage · ✅ Success · Started 12:10 PM UTC · Completed 12:15 PM UTC
Commit: 37f148b · View workflow run →

[fullsend-ai-triage]

Triage Summary

Severity: Medium · Category: Enhancement

Problem

The review agent's sticky comment is the primary review artifact on a PR, but it contains no provenance link — no reference to the workflow run or status comment that produced its current content. On PRs with multiple review cycles, readers must manually cross-reference the hidden Head SHA HTML comment against status comment timestamps to trace which run produced the current findings.

Root Cause

scripts/post-review.sh does not inject provenance metadata into the sticky comment body before passing the result to the fullsend post-review CLI. The pr-review skill explicitly forbids the agent from adding footers (step 7: "No footer"), making the post-script the correct and only injection point. The post-script already appends other footers (protected-path notices, label reasons, action hints) using the same jq body-append pattern.

Recommended Fix

In post-review.sh, construct the workflow run URL from GitHub Actions environment variables (GITHUB_SERVER_URL, GITHUB_REPOSITORY, GITHUB_RUN_ID) and append it as a subtle provenance footer (e.g., <sub> element) to the .body field before calling fullsend post-review. This follows the established pattern for other footer injections in the script. Gracefully skip injection if the env vars are unavailable.

Proposed Test

# In post-review-test.sh:
# 1. Set GITHUB_SERVER_URL, GITHUB_REPOSITORY, GITHUB_RUN_ID
# 2. Invoke provenance injection on a sample body
# 3. Assert output contains the expected workflow run URL
# 4. Edge case: unset GITHUB_RUN_ID -> no provenance footer, no error

---

Next steps:

• /fs-code — agent creates a PR to implement this issue
• /fs-code <your instruction> — agent implements with your specific guidance

[fullsend-ai-prioritize]

RICE Priority Score: 0.8

Score breakdown

Dimension	Score	Reasoning
Reach	1	The review agent's sticky comment is visible on every PR it reviews, but the missing provenance link is only a pain point when multiple review cycles occur and someone needs to trace which run produced the current findings. This affects a moderate number of active contributors who review PRs with multiple agent runs.
Impact	0.5	Low — a workaround exists (manually cross-referencing the hidden Head SHA HTML comment against status comment timestamps). The improvement makes the audit trail more convenient but does not block any workflow or cause data loss.
Confidence	0.8	High — the issue is well-described with a concrete example (PR #481), the triage comment identifies the exact root cause and injection point in post-review.sh, and the scope is clearly bounded to a single footer injection following an established pattern.
Effort	0.5	Simple — the fix appends a provenance footer in post-review.sh using the same jq body-append pattern already used for other footers, constructing the URL from existing GitHub Actions environment variables. The triage comment lays out the implementation clearly.

Formula: (1 x 0.5 x 0.8) / 0.5 = 0.8