exp(stick-editlast)

[mmiermans]

Sticky-review strategy test. Do not merge.

[github-actions]

🤖 Claude has reviewed this PR — expand after forming your own opinion

Summary

This PR rewrites the Claude PR review workflow (switching from /review + track_progress to an inline sticky-comment prompt) and adds a small JS helper file under webclient/resources/js/.

Findings — .github/workflows/claude-review.yml

• Dropped prompt-injection mitigation. The previous config used include_comments_by_actor: "mmiermans" and excluded gh pr view specifically to avoid pulling untrusted PR comments into context. The new config removes that guard. The replacement mitigates the risk a different way — it only runs gh pr diff and no longer fetches comments — but the diff itself is still attacker-controlled on PRs and the comment is posted with pull-requests: write. Worth a deliberate note that this is an accepted tradeoff.
• issues: write looks redundant. PR comments are issue comments, but pull-requests: write (already granted) is sufficient to create/edit them via gh pr comment. Adding issues: write broadens token scope without an apparent need — consider dropping it.
• id-token: write removed — fine given auth no longer uses OIDC (anthropic_api_key + github_token); just confirm no GitHub App OIDC path relies on it.
• Stripping the explanatory comments (concurrency, fork-PR guard, tool rationale) is a minor readability loss; the fork guard if: and cancel-in-progress are retained, which is good.

Findings — webclient/resources/js/exp-stick-editlast.js

• Appears to be experimental scratch / dead code. The file name (exp-stick-editlast) and comment (helper for sticky-review experiment) suggest a scratch artifact, and pct is not referenced anywhere in the repo. If it is not intended to ship, it probably should not be committed.
• Unguarded division by zero. pct(part, 0) returns Infinity (or NaN when part is 0) rather than erroring — the inline comment even flags this. If the function is kept, guard total === 0.

Tests / Docs

No tests or documentation accompany the change. Given the JS helper is unreferenced, that is consistent — but reinforces the question of whether it belongs in this PR.

Overall the workflow change is reasonable; the main asks are to confirm the injection-mitigation tradeoff is intentional, trim the issues: write scope, and clarify the intent of the new JS file.