Rename DOTCMS_API_TOKEN secrets in autodoc workflow

[jdcmsd]

Summary

• Renames DOTCMS_API_TOKEN → DOTCMS_API_TOKEN_AISEARCH and DOTCMS_API_TOKEN_LOCAL → DOTCMS_API_TOKEN_AUTODOCDRAFT in issue_autodoc.yml to match the updated secret names now set in repo settings.

Test plan

• Merge this PR
• Trigger the autodoc workflow by labeling a test Epic with Doc : Needs Doc

[github-actions]

❌ Issue Linking Required

This PR could not be linked to an issue. All PRs must be linked to an issue for tracking purposes.

How to fix this:

Option 1: Add keyword to PR body (Recommended - auto-removes this comment)
Edit this PR description and add one of these lines:

• This PR fixes #123 or Fixes: #123

• This PR closes #123 or Closes: #123

• This PR resolves #123 or Resolves: #123

• Other supported keywords: fix, fixed, close, closed, resolve, resolved
  Option 2: Link via GitHub UI (Note: won't clear the failed check)

1. Go to the PR → Development section (right sidebar)

2. Click "Link issue" and select an existing issue

3. Push a new commit or re-run the workflow to clear the failed check
   Option 3: Use branch naming
   Create a new branch with one of these patterns:

• 123-feature-description (number at start)

• issue-123-feature-description (issue-number at start)

• feature-issue-123 (issue-number anywhere)

Why is this required?

Issue linking ensures proper tracking, documentation, and helps maintain project history. It connects your code changes to the problem they solve.---

This comment was automatically generated by the issue linking workflow

[claude]

Claude finished @jdcmsd's task in 1m 17s —— View job

---

PR Review: autodoc workflow

• Read the diff and full workflow file
• Analyze logic, triggers, and secret handling

The secret rename itself is mechanically fine, but this PR's diff contains far more than its title/description claim, and a couple of those changes carry real risk.

---

🔴 Most likely to break things: env var names changed, not just secret references

-      DOTCMS_API_TOKEN:       ${{ secrets.DOTCMS_API_TOKEN }}
-      DOTCMS_API_TOKEN_LOCAL: ${{ secrets.DOTCMS_API_TOKEN_LOCAL }}
+      DOTCMS_API_TOKEN_AISEARCH:     ${{ secrets.DOTCMS_API_TOKEN_AISEARCH }}
+      DOTCMS_API_TOKEN_AUTODOCDRAFT: ${{ secrets.DOTCMS_API_TOKEN_AUTODOCDRAFT }}

You renamed both the secret and the environment variable exposed to the scripts. The consuming code lives in another repo (secrets.AUTODOC_REPO → run_eval.py / finalize.py), so I can't verify it here. If those scripts read os.environ["DOTCMS_API_TOKEN"] / DOTCMS_API_TOKEN_LOCAL, they will now get nothing and fail (or silently auth as anonymous). Please confirm the autodoc scripts were updated to read the new variable names, or keep the env var names stable and only change the right-hand secrets.* reference.

🟠 Description / test plan no longer match the workflow

• PR title/body say "rename secrets" only, but the diff also changes the trigger from labeled → closed and adds an entire preflight job. These were the prior commits on the branch, but the PR description should reflect the actual scope.
• The test plan says "Trigger by labeling a test Epic with Doc : Needs Doc" — that no longer triggers anything. The workflow now fires only on issues: [closed]. The test plan is stale and would lead a reviewer to "verify" via a path that can't fire.

🟠 EPIC_NUMBER may not be an Epic anymore

The preflight now allows a closed issue to proceed when it has a doc label and is not an Epic sub-task — i.e. a standalone non-Epic issue runs the audit too. But the job still does:

EPIC_NUMBER: ${{ github.event.issue.number }}
...
uv run python scripts/run_eval.py --epic "$EPIC_NUMBER" ...

A non-Epic issue number is passed as --epic. Confirm run_eval.py handles a non-Epic issue gracefully, otherwise this is a semantic mismatch introduced by broadening the trigger.

🟡 GraphQL parent field — verify availability

issue(number: $number) { parent { labels(first: 20) { nodes { name } } } }

Issue.parent is part of GitHub's sub-issues feature. Depending on rollout it may require the GraphQL-Features: sub_issues preview header. If the field isn't recognized for this token/endpoint the query errors → see next point.

🟡 Preflight fails open on API error

There's no set -e and the gh api graphql exit code isn't checked. If the call fails (network, schema/preview, permissions), PARENT_LABELS is empty, grep -qx "Epic" doesn't match, and you fall into the else → should_run=true. So any API hiccup causes the full audit (with API spend) to run. Consider checking the exit status explicitly and deciding whether fail-open or fail-closed is intended.

🟡 No concurrency guard

Close/reopen/close churn on an issue can launch overlapping audit runs that post duplicate/competing comments. A concurrency group keyed on the issue number would prevent this.

---

Note: I can review but cannot modify files under .github/workflows/ (GitHub App permission restriction), so these are flagged for you to address.

The single-line verdict you asked for: the rename is correct in isolation, but verify the downstream scripts read the new env var names — that's the one change here that can silently break the workflow.