fix(ci): stop Claude AI workflows overwriting each other's PR comment

[sfreudenthaler]

Closes: #36761

Problem

Three Claude workflows run on every pull_request in this repo — ai_claude-orchestrator.yml (code review), ai_claude-rollback-safety.yml, ai_claude-backend-reviewer.yml. They all route to the Anthropic path, and anthropics/claude-code-action@v1 finds the comment to reuse by "authored by the Claude app bot", with no per-workflow marker:

// create-initial.ts
const existingComment = comments.data.find((comment) => {
  const idMatch = comment.user?.id === CLAUDE_APP_BOT_ID;   // 209825114
  const botNameMatch = comment.user?.type === "Bot" && comment.user?.login.toLowerCase().includes("claude");
  ...
});

So the later workflow resets the earlier one's comment to "Claude Code is working…" and writes its own result over it. PR #36759 — one comment, eight edits, two workflows:

time	run	content
20:10:08	Claude AI Orchestrator (30301039985)	creates comment
20:11:23	"	Code Review: PR #36759
20:12:17	Claude AI Rollback Safety (30301040015)	reset to "Claude Code is working…" — review gone
20:13:50	"	Rollback-Safety Analysis

This is deterministic, not a race — ordering decides only who wins, so a concurrency group would not help. Note the rollback check wasn't even supposed to comment there: its verdict was "safe", and STEP 4b says label only. The comment it destroyed the review with was the action's own progress comment.

Change

One owner for the action-managed comment. ai_claude-orchestrator.yml keeps it — an auto-updating review comment is the point there. The other two pass track_progress: false:

• rollback-safety reports through the AI: Safe To Rollback / AI: Not Safe To Rollback label, plus its own gh pr comment when unsafe. On a safe verdict the analysis lives in the job log, which is the accepted trade here.
• backend-reviewer upserts its own <!-- dotcms-backend-review --> marker comment in STEP 5.

Neither needs a progress comment, and neither can hijack the review's now.

Dependency — shipped

track_progress was hardcoded "true" in claude-executor.yml. dotCMS/ai-workflows#64 exposes it (default true, no behaviour change for other consumers); released as v3.4.0 and the floating v3 tag now points at it, so the input this PR passes exists. Declared type: boolean, which is why false here is unquoted (unlike issue_autodoc.yml, which calls the action directly, where with: values are strings).

Verified on this PR: both workflows now resolve track_progress: false and get past the earlier startup_failure.

Not verified here

claude-code-action skips any PR that modifies its own workflow file ("Workflow validation failed… identical content to the version on the repository's default branch"), so on this PR the rollback and backend jobs are skipped and no label is applied. End-to-end no-clobber behaviour is exercised by the first ordinary PR after this merges.

Upstream

The real fix is a namespaced sticky marker in claude-code-action. The Bedrock/Codex executors in ai-workflows already do this via sticky_namespace; the limitation and the one-owner convention are now documented in that repo's README (§6).

This PR fixes: #36761

[claude]

Claude finished @sfreudenthaler's task in 48s —— View job

---

Code Review: PR #36762 — stop Claude AI workflows overwriting each other's PR comment

• Read the diff (ai_claude-backend-reviewer.yml, ai_claude-rollback-safety.yml)
• Verify track_progress input contract and value type
• Check the reporting fallback for each de-stickied workflow
• Review complete

---

New Issues

No issues found.

The change is minimal and correct: both callers now pass track_progress: false to dotCMS/ai-workflows/.github/workflows/claude-orchestrator.yml@v3, ceding the single action-managed sticky comment to ai_claude-orchestrator.yml. The reasoning in the PR body holds up against the code:

• Value type is right. The input is declared type: boolean upstream, so the unquoted false is correct — a quoted "false" reaching a boolean input would be the classic footgun, and this avoids it.
• backend-reviewer still reports. STEP 5 (ai_claude-backend-reviewer.yml:220-275) upserts its own `` marker comment and STEP 6 submits a formal review, so dropping the progress comment loses nothing. The upsert's --paginate ... | tail -n1 guard (lines 264-268) is unchanged and still sound.
• rollback-safety still reports. It posts via gh pr comment + the AI: Not Safe To Rollback label on an unsafe verdict (STEP 4a) and label-only on safe (STEP 4b). No progress comment needed.

One thing worth confirming (not a code defect, an operational dependency):

• 🟡 Medium: correctness hinges on the floating v3 tag actually pointing at a release (v3.4.0+) that exposes track_progress. The PR body says this shipped and was verified, and I can't inspect the external ai-workflows repo from here to confirm the tag. What to verify: the first ordinary PR merged after this lands should show the orchestrator's review comment surviving intact through the rollback + backend runs. If v3 ever gets re-pointed at a pre-3.4.0 commit, these callers would fail with an unknown-input error rather than silently ignoring it — so this is a soft coupling to keep in mind, not a change to make here.

The "not verified on this PR" caveat (workflow-file changes cause claude-code-action to skip the rollback/backend jobs) is accurate and correctly disclosed — end-to-end no-clobber behaviour genuinely can't be exercised until the next non-workflow PR.

[sfreudenthaler]

that high finding is ok. i've already shipped (dotCMS/ai-workflows@1a83e93) it in ai-workflows and moved the floating @v3 tag

[erickgonzalez]

Haha nice got this question from some devs but I didn’t had any time to investigate

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request