fix: MCP-first Jira auth and diagnose Ambient env var accessibility

workflows/cve-fixer/.claude/commands/cve.find.md

@@ -54,13 +54,45 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
 
 2. **Verify Jira Access**
 
-   Secrets may be injected by the Ambient session, a secrets manager, or an MCP server — do NOT rely solely on bash env var checks. Instead, attempt a lightweight test API call and let the response determine whether credentials are available.
+   **ALWAYS check for a Jira MCP server first** before attempting any curl/env var approach.
+
+   **2.1: Check for Jira MCP server (do this first, every time)**
+
+   Look at the available tools in the current session. If any tool matching `mcp__jira*`,
+   `mcp__atlassian*`, or any Jira-related MCP tool is present:
+   - Use the MCP tool directly for all Jira queries in Step 3
+   - Skip the curl/auth setup entirely
+   - Print: "✅ Using Jira MCP server — no credentials required"
+
+   **Do NOT assume MCP is unavailable just because the user has not mentioned it.**
+   Always proactively check the available tool list before falling back to curl.
+
+   **2.2: Fallback — curl with credentials (only if no MCP found)**
+
+   If no Jira MCP server is available, first check whether the credentials are accessible
+   to the bash shell — Ambient custom env vars are sometimes available to Claude but not
+   automatically exported to bash subprocesses:
+
+   ```bash
+   # Diagnose accessibility before attempting auth
+   TOKEN_SET=$([ -n "${JIRA_API_TOKEN}" ] && echo "yes" || echo "no")
+   EMAIL_SET=$([ -n "${JIRA_EMAIL}" ] && echo "yes" || echo "no")
+   echo "JIRA_API_TOKEN accessible to bash: $TOKEN_SET"
+   echo "JIRA_EMAIL accessible to bash: $EMAIL_SET"
+   ```
+
+   - If either is **"no"** → the Ambient custom env vars are not being passed to bash
+     subprocesses. Ask the user to export them explicitly in the session:
+     ```bash
+     export JIRA_API_TOKEN="your-token-here"
+     export JIRA_EMAIL="your-email@redhat.com"
+     ```
+   - If both are **"yes"** → proceed with the auth test call:
 
    ```bash
    JIRA_BASE_URL="https://redhat.atlassian.net"
    AUTH=$(echo -n "${JIRA_EMAIL}:${JIRA_API_TOKEN}" | base64)
 
-   # Retry once on network failure (curl exit code 000 = timeout/no response)
    for ATTEMPT in 1 2; do
      TEST_RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" -X GET \
        --connect-timeout 10 --max-time 15 \
@@ -74,29 +106,22 @@ Report: artifacts/cve-fixer/find/cve-issues-20260226-145018.md
    ```
 
    - **HTTP 200** → credentials valid, proceed
-   - **HTTP 401** → credentials missing or invalid. Note: `/rest/api/3/myself` returns 401 for all authentication failures — there is no separate 403 for this endpoint. Only now inform the user:
-     - Check if `JIRA_API_TOKEN` and `JIRA_EMAIL` are configured as Ambient session secrets
-     - If not, generate a token at https://id.atlassian.com/manage-profile/security/api-tokens and export:
-
-       ```bash
-       export JIRA_API_TOKEN="your-token-here"
-       export JIRA_EMAIL="your-email@redhat.com"
-       ```
-   - **HTTP 000 after retry** → persistent network issue — inform user and stop
-
-   **Do NOT pre-check env vars with `[ -z "$JIRA_API_TOKEN" ]` and stop.** The variables may be available to the API call even if not visible to the shell check (e.g. Ambient secrets injection).
+   - **HTTP 401** → token is invalid or expired. Generate a new token at
+     https://id.atlassian.com/manage-profile/security/api-tokens and export it
+   - **HTTP 000 after retry** → network issue — inform user and stop
 
 3. **Query Jira for CVE Issues**
 
-   a. Set up variables (AUTH already set from Step 2):
+   a. Set up variables:
 
    ```bash
    COMPONENT_NAME="[from step 1]"
    JIRA_BASE_URL="https://redhat.atlassian.net"
-   # AUTH already constructed in Step 2 — reuse it
+   # If using MCP (Step 2.1): pass JQL directly to MCP tool — no AUTH needed
+   # If using curl (Step 2.2): AUTH already constructed in Step 2 — reuse it
    ```
 
-   b. Construct JQL query and execute API call:
+   b. Construct JQL query and execute via MCP or curl:
 
    ```bash
    # Normalize component name with case-insensitive lookup against mapping file

workflows/cve-fixer/.claude/commands/cve.fix.md

@@ -33,6 +33,11 @@ Summary:
 
 1. **Load CVEs from Find Output or User-Specified Jira Issue**
 
+   **Supported flags:**
+   - `--automerge` — After creating each PR, enable GitHub's automerge so the PR merges automatically once all required checks pass. Off by default — the user must explicitly opt in.
+
+   Parse this flag before processing Jira issues. Store as `AUTOMERGE=true/false`.
+
    **Option A: User specifies one or more Jira issues**
    - If user provides one or more Jira issue IDs (e.g., `/cve.fix RHOAIENG-4973` or `/cve.fix RHOAIENG-4973 RHOAIENG-5821`):
      - Process each issue independently -- extract CVE ID and component from each
@@ -1074,10 +1079,16 @@ This PR fixes **CVE-YYYY-XXXXX** by upgrading <package> from X.X.X to Y.Y.Y.
 EOF
 )
 
-       gh pr create \
+       PR_URL=$(gh pr create \
          --base <target-branch> \
          --title "Security: Fix CVE-YYYY-XXXXX (<package-name>)" \
-         --body "$PR_BODY"
+         --body "$PR_BODY")
+
+       # Enable automerge if --automerge flag was passed
+       if [ "$AUTOMERGE" = "true" ]; then
+         gh pr merge --auto --squash "$PR_URL"
+         echo "✅ Automerge enabled on $PR_URL — will merge when checks pass"
+       fi
        ```
      - Capture the PR URL from the command output
      - Save PR URL to fix implementation report
@@ -1222,6 +1233,12 @@ Fix multiple specific Jira issues:
 /cve.fix RHOAIENG-4973 RHOAIENG-5821
 ```
 
+Fix and enable automerge on all created PRs (merges automatically when checks pass):
+```
+/cve.fix --automerge
+/cve.fix RHOAIENG-4973 --automerge
+```
+
 Fix with custom message:
 ```
 /cve.fix Fix open CVEs found in latest scan