Skip to content

refactor(#1108): use OpenShell providers for Jira credentials - #1109

Merged
ralphbean merged 7 commits into
mainfrom
agent/1108-jira-provider-credentials
Sep 2, 2026
Merged

refactor(#1108): use OpenShell providers for Jira credentials#1109
ralphbean merged 7 commits into
mainfrom
agent/1108-jira-provider-credentials

Conversation

@fullsend-ai-coder

Copy link
Copy Markdown
Contributor

Summary

  • Converge triage and code Jira overlays on provider-backed credential delivery so the real JIRA_TOKEN never enters either sandbox — only the jira-ro provider's opaque placeholder is available to sandboxed Jira clients.
  • Remove runner-side .issue-context.json prefetch from the code agent; the sandbox now reads Jira work items directly through the provider boundary via curl.
  • Add harness-jira-test.sh verifying provider/profile selection and token absence from sandbox configuration for both agents.

Changes

Harness configuration:

  • harness/triage.yaml — remove JIRA_TOKEN from env.sandbox (provider supplies placeholder)
  • harness/code.yaml — attach providers/jira-ro.yaml and profiles/fullsend-jira-ro.yaml; remove host_files prefetch and credential env vars from env.runner; add JIRA_USER_EMAIL and JIRA_BASE_URL to env.sandbox
  • env/jira/triage.env — remove JIRA_TOKEN export (was expanded into sandbox via expand: true)

Scripts:

  • scripts/pre-code-jira.src.sh — remove credential requirements and issue-fetch logic; retain URL validation and pre-commit tool installation
  • scripts/pre-code-jira.sh — rebuilt via make script-build

Skills and docs:

  • skills/code-implementation/SKILL.md — update Jira issue fetching to use provider-backed API access instead of .issue-context.json
  • docs/code.md — update FULLSEND_TRACKER description and Jira-source overlay documentation
  • docs/triage.md — document provider-backed credential delivery in Jira setup and migration notes

Tests:

  • scripts/harness-jira-test.sh (new) — verifies provider/profile presence, JIRA_TOKEN absence from sandbox config, and related assertions for both triage and code harnesses
  • scripts/pre-code-jira-test.sh — updated for simplified pre-script (removed prefetch/credential tests, added tests confirming credentials are no longer required)

Testing

  • bash scripts/harness-jira-test.sh — 17/17 pass
  • bash scripts/pre-code-jira-test.sh — 8/8 pass (source and bundled modes)
  • make check-bundle — pass
  • hack/lint-agent-docs — pass
  • scan-secrets — pass
  • Pre-existing post-retro-test.sh failures (16) are unrelated

Closes #1108

Post-script verification

  • Branch is not main/master (agent/1108-jira-provider-credentials)
  • Secret scan passed (gitleaks — c4879824d5045bfb8c64527a74e620332e18d95a..HEAD)
  • PR body secret scan passed (gitleaks — no-git)

@fullsend-ai-coder
fullsend-ai-coder Bot requested a review from a team as a code owner August 31, 2026 22:01
@fullsend-ai-coder fullsend-ai-coder Bot added the ready-for-review Triggers review agent dispatch label Aug 31, 2026
@fullsend-ai-review

fullsend-ai-review Bot commented Aug 31, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 10:04 PM UTC · Completed 10:26 PM UTC

Commit: 8812312 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high

@fullsend-ai-review fullsend-ai-review Bot added the risk/moderate PR risk: moderate label Aug 31, 2026
@fullsend-ai-review

fullsend-ai-review Bot commented Aug 31, 2026

Copy link
Copy Markdown

Risk Assessment: elevated (3/5)

Details

Elevated from prior score (2 to 3): LINES_CHANGED crossed the 800 threshold (845), large blast radius, 9 protected paths. High Tier 2 churn with fix/revert density. Tier 3 shows strong issue-PR alignment with 8 clear acceptance criteria. Weighted composite 3.00 rounds to 3.

Previous run

Risk Assessment: moderate (2/5)

Details

Anchored to prior score (2). Tier 1 signals unchanged — same 14 files, 10 protected paths, bot author, no dependency or CI changes. Tier 2 churn and fix/revert density remain high but were already accounted for in prior assessment. Tier 3 shows good issue-PR alignment with clear acceptance criteria. Weighted composite 2.43 rounds to 2.

Previous run (2)

Risk Assessment: moderate (2/5)

Details

Anchored to prior score (2). Tier 1 signals unchanged — same 11 files, 7 protected paths, bot author, no dependency or CI changes. Tier 2 churn and fix/revert density remain high but were already accounted for in prior assessment. Tier 3 shows good issue-PR alignment with most acceptance criteria covered.

Previous run (3)

Risk Assessment: moderate (2/5)

Details

Anchored to prior score (2). Tier 1 signals unchanged from prior assessment — same 11 files, 7 protected paths, bot author, no dependencies. High Tier 2 churn and regression history offset by very recent code age and low revert/sentiment signals. Tier 3 shows good issue-PR alignment. Weighted composite 2.25 rounds to 2.

Previous run (4)

Risk Assessment: moderate (2/5)

Details

Anchored to prior assessment (score 2). Only LOCAL.md documentation changed since last review; Tier 1 signals unchanged — same file count (11), same protected-path count (7), same bot author, same dependency status. No articulable reason to change the score.

Previous run (5)

Risk Assessment: moderate (2/5)

Details

Moderate file count (10) with 7 protected-path changes (harness/, scripts/, skills/), but bot author, same-day triaged issue, clear acceptance criteria coverage, and security-focused credential boundary refactor mitigate risk.

@fullsend-ai-review

fullsend-ai-review Bot commented Aug 31, 2026

Copy link
Copy Markdown

Review

Findings

Medium

  • [protected-path] harness/code.yaml, harness/triage.yaml, scripts/harness-jira-test.sh, scripts/pre-code-jira-test.sh, scripts/pre-code-jira.sh, scripts/pre-code-jira.src.sh, scripts/sandbox-credential-boundary-test.sh, skills/code-implementation/SKILL.md, skills/jira-forge/SKILL.md — 9 files under protected paths (harness/, scripts/, skills/) are modified. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale (converging on provider-backed credential delivery). Human approval is required for protected-path changes regardless of context.

Low

  • [injection] scripts/harness-jira-test.sh:37 — The jira_overlay_field helper uses string interpolation to embed a file path into a Python string literal (with open('${harness_file}')). A single quote in the path would break the Python syntax. Exploitation requires controlling the repo checkout path on the runner, making risk negligible.
    Remediation: Pass the path as a command-line argument and use sys.argv instead of shell interpolation into the Python source string.

  • [test-infrastructure-idiom] scripts/harness-jira-test.sh — The Jira skill Basic-auth placeholder tests (lines 355–378) are duplicated verbatim in scripts/sandbox-credential-boundary-test.sh (lines 156–178). Both scripts iterate the same skill files array and run the same grep for --user.
    Remediation: Remove the skill-level Basic-auth loop from harness-jira-test.sh and let sandbox-credential-boundary-test.sh own that assertion exclusively.


Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR
Previous run

Review

Findings

Medium

  • [protected-path] harness/code.yaml, harness/triage.yaml, scripts/harness-jira-test.sh, scripts/pre-code-jira-test.sh, scripts/pre-code-jira.sh, scripts/pre-code-jira.src.sh, skills/code-implementation/SKILL.md, skills/issue-labels/jira/SKILL.md, skills/jira-components/SKILL.md, skills/jira-forge/SKILL.md — 10 files under protected paths (harness/, scripts/, skills/) are modified. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale (converging on provider-backed credential delivery). Human approval is required for protected-path changes regardless of context.

Low

  • [unused-config] harness/code.yaml:157JIRA_USER_EMAIL is injected into the code sandbox environment but is no longer referenced by any skill file at the PR head. All curl examples have removed their --user flags, making this variable dead weight in the sandbox. Similarly present in harness/triage.yaml sandbox env and env/jira/triage.env. Harmless (non-secret config) but could be cleaned up in a follow-up.

  • [test-infrastructure-idiom] scripts/harness-jira-test.sh — The new test file defines custom assert_pass() / assert_fail() helpers not used by any other test script. All other test scripts centralize pass/fail logic in a run_test() function. The idiom divergence is limited to one file and defensible given the YAML-parsing test structure differs from script-execution tests.

  • [incomplete-credential-removal] harness/triage.yaml:111JIRA_TOKEN remains in the triage overlay's env.runner block. Architecturally justified: runner-side post-scripts need the real credential for Jira API mutations (label writes, transitions, comment posting).

  • [defense-in-depth] scripts/pre-code-jira.src.sh:23 — The pre-script's required-env-var guards for JIRA_ISSUE_CONTEXT_FILE, JIRA_USER_EMAIL, and JIRA_TOKEN are removed. With provider-backed delivery, a missing provider surfaces at runtime as HTTP 401 rather than a clear pre-flight error.

  • [naming-convention] scripts/harness-jira-test.sh — The new test script uses a naming pattern different from the convention where test files are named after the script they test (e.g., pre-code-jira-test.sh tests pre-code-jira.sh). No harness-jira.sh counterpart exists. The name is defensible since it tests harness YAML configuration rather than a specific script.

  • [injection] scripts/harness-jira-test.sh:42 — The jira_overlay_field helper uses string interpolation to embed a file path into a Python string literal (with open('${harness_file}')). A single quote in the path would break the Python syntax. Exploitation requires controlling the repo checkout path on the runner, making risk negligible.

Previous run (2)

Review

Findings

High

  • [consumer-completeness] harness/triage.yaml — The PR removes JIRA_TOKEN from the triage sandbox env, but three unchanged skills loaded by the triage Jira overlay still reference ${JIRA_TOKEN} in their curl examples: skills/jira-forge/SKILL.md (8 occurrences), skills/issue-labels/jira/SKILL.md (2 occurrences), and skills/jira-components/SKILL.md (2 occurrences). The triage agent will attempt to expand JIRA_TOKEN, which is no longer set in env.sandbox. The jira-ro provider's enforcement: enforce profile handles auth at the HTTP layer, but the agent will construct --user flags with an undefined variable — a functional gap in the credential migration.
    Remediation: Either (a) update the three triage skills to remove --user flags and document provider-backed auth, or (b) keep JIRA_TOKEN in the triage sandbox env until those skills are updated in a follow-up PR.

Medium

  • [runtime-mechanism-failure] skills/code-implementation/SKILL.md:222 — The SKILL.md instructs the code agent to run curl --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" inside the sandbox, but JIRA_TOKEN is not present in the code agent's sandbox environment (removed in this PR). The jira-ro provider handles auth at the HTTP layer via enforcement: enforce, so the request will authenticate correctly, but the stale --user flag with an undefined JIRA_TOKEN creates ambiguity between curl-level auth and provider-injected auth. See also: [credential-exposure] finding at this location.
    Remediation: Remove the --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" flag from the curl example since the jira-ro provider handles credential injection transparently at the network layer.

  • [protected-path] harness/code.yaml, harness/triage.yaml, scripts/harness-jira-test.sh, scripts/pre-code-jira-test.sh, scripts/pre-code-jira.sh, scripts/pre-code-jira.src.sh, skills/code-implementation/SKILL.md — 7 files under protected paths (harness/, scripts/, skills/) are modified. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale (converging on provider-backed credential delivery). Human approval is required for protected-path changes regardless of context.

Low

  • [stale-reference] LOCAL.md:165 — The prior finding about the misleading comment in the "Testing code agent with Jira" section has been addressed. The updated comment correctly states that JIRA_TOKEN is read by the jira-ro provider on the host and never enters the code agent's runner or sandbox environment.

  • [incomplete-credential-removal] harness/triage.yaml:111JIRA_TOKEN remains in the triage overlay's runner env block. Architecturally justified: runner-side post-scripts need the real credential for Jira API mutations (label writes, transitions, comment posting). The token never enters the sandbox — the new harness-jira-test.sh validates this boundary.

  • [defense-in-depth] scripts/pre-code-jira.src.sh:23 — The pre-script's required-env-var guards for JIRA_ISSUE_CONTEXT_FILE, JIRA_USER_EMAIL, and JIRA_TOKEN are removed. With provider-backed delivery, a missing or misconfigured provider surfaces at runtime as an HTTP 401 from the Jira API inside the sandbox, rather than failing fast at pre-script time. The provider's credential resolution is the new validation gate.

  • [naming-convention] scripts/harness-jira-test.sh — The new test script uses a naming pattern different from the existing convention where test files are named after the script they test (e.g., pre-code-jira-test.sh tests pre-code-jira.sh). No harness-jira.sh counterpart exists. The name is defensible since it tests harness YAML configuration rather than a specific script.


Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR
Previous run (3)

Review

Findings

Medium

  • [stale-reference] LOCAL.md:167 — The comment says "JIRA_TOKEN stays on the runner for post-script mutations" in the "Testing code agent with Jira" section. However, the code agent's Jira overlay in harness/code.yaml does not map JIRA_TOKEN to env.runner (removed in this PR), and post-code.sh never performs Jira mutations. The claim is accurate for triage but misleading here.
    Remediation: Update the comment to reflect that JIRA_TOKEN is not consumed by the code agent harness.

  • [protected-path] harness/code.yaml, harness/triage.yaml, scripts/harness-jira-test.sh, scripts/pre-code-jira-test.sh, scripts/pre-code-jira.sh, scripts/pre-code-jira.src.sh, skills/code-implementation/SKILL.md — 7 files under protected paths (harness/, scripts/, skills/) are modified. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale (converging on provider-backed credential delivery). Human approval is required for protected-path changes regardless of context.

Low

  • [test-inadequate] scripts/pre-code-jira-test.sh:111 — The tests no-jira-email-still-succeeds and no-jira-token-still-succeeds are redundant with valid-jira-github-succeeds because base_env() never sets JIRA_USER_EMAIL or JIRA_TOKEN, so all three run in identical environments.
    Remediation: Set JIRA_USER_EMAIL and JIRA_TOKEN in base_env() and override them to empty in these specific tests.

  • [incomplete-credential-removal] harness/triage.yaml:118JIRA_TOKEN remains in the triage overlay's runner env block. Architecturally justified: runner-side post-scripts need the real credential for Jira API mutations (label writes, transitions, comment posting). The token never enters the sandbox — the new harness-jira-test.sh validates this boundary.

  • [credential-exposure] skills/code-implementation/SKILL.md:222 — The curl --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" pattern places the provider's opaque token placeholder in process arguments within the sandbox. Under enforcement: enforce in the fullsend-jira-ro profile, the OpenShell proxy intercepts the request and substitutes the real credential at the HTTP layer, so the placeholder is not the actual secret.

  • [defense-in-depth] scripts/pre-code-jira.src.sh:25 — The pre-script's required-env-var guards for JIRA_ISSUE_CONTEXT_FILE, JIRA_USER_EMAIL, and JIRA_TOKEN are removed. With provider-backed delivery, a missing or misconfigured provider surfaces at runtime as an HTTP 401 from the Jira API inside the sandbox, rather than failing fast at pre-script time. The provider's credential resolution is the new validation gate.

  • [naming-convention] scripts/harness-jira-test.sh — The new test script uses a naming pattern different from the existing convention where test files are named after the script they test (e.g., pre-code-jira-test.sh tests pre-code-jira.sh). No harness-jira.sh counterpart exists. The name is defensible since it tests harness YAML configuration rather than a specific script.

  • [code-organization] scripts/harness-jira-test.sh — Five near-identical Python-in-bash helper functions (jira_sandbox_env_keys, jira_runner_env_keys, jira_overlay_providers, jira_overlay_profiles, jira_overlay_host_file_dests) differ only in the YAML key path they extract. A single parameterized helper would reduce ~80 lines of repetition.
    Remediation: Refactor into a single jira_overlay_field() helper that accepts the YAML key path as a parameter.


Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR
Previous run (4)

Review

Findings

Medium

  • [protected-path] harness/code.yaml, harness/triage.yaml, scripts/harness-jira-test.sh, scripts/pre-code-jira-test.sh, scripts/pre-code-jira.sh, scripts/pre-code-jira.src.sh, skills/code-implementation/SKILL.md — 7 files under protected paths (harness/, scripts/, skills/) are modified. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale (converging on provider-backed credential delivery). Human approval is required for protected-path changes regardless of context.

Low

  • [incomplete-credential-removal] harness/triage.yaml:111JIRA_TOKEN remains in the triage overlay's runner env block. The runner-side presence is architecturally justified: pre-triage.sh and post-triage.sh execute on the runner and require the real credential for Jira API mutations (label writes, transitions, comment posting). The code agent fully removed JIRA_TOKEN from its runner env because it has no post-script Jira mutations. This asymmetry is by design per issue refactor(jira): use OpenShell providers for triage and code credentials #1108 acceptance criteria ("Runner-side triage mutations can continue to use the real credential where needed").

  • [credential-exposure] skills/code-implementation/SKILL.md:222 — The curl --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" pattern places the provider's opaque token placeholder in process arguments within the sandbox. Under enforcement: enforce in the fullsend-jira-ro profile, the OpenShell proxy intercepts the request and substitutes the real credential at the HTTP layer, so the placeholder is not the actual secret.

  • [defense-in-depth] scripts/pre-code-jira.src.sh:28 — The pre-script's required-env-var guards for JIRA_ISSUE_CONTEXT_FILE, JIRA_USER_EMAIL, and JIRA_TOKEN are removed. With provider-backed delivery, a missing or misconfigured provider surfaces at runtime as an HTTP 401 from the Jira API inside the sandbox, rather than failing fast at pre-script time. The provider's credential resolution is the new validation gate.

Previous run (5)

Review

Findings

Medium

  • [stale-reference] LOCAL.md:178 — LOCAL.md (lines 176–181) still describes the removed Jira prefetch pattern: "The Jira pre-script fetches the issue via the fullsend CLI and writes the context to /tmp/jira-issue-context.json, which host_files copies into the sandbox as /sandbox/workspace/.issue-context.json." This is no longer accurate — the PR removes issue-context prefetching from pre-code-jira.sh and the host_files entry from code.yaml.
    Remediation: Update lines 176–181 of LOCAL.md to describe the new provider-backed Jira API access pattern.

  • [protected-path] harness/code.yaml, harness/triage.yaml, scripts/harness-jira-test.sh, scripts/pre-code-jira-test.sh, scripts/pre-code-jira.sh, scripts/pre-code-jira.src.sh, skills/code-implementation/SKILL.md — 7 files under protected paths (harness/, scripts/, skills/) are modified. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale (converging on provider-backed credential delivery). Human approval is required for protected-path changes regardless of context.

Low

  • [stale-reference] LOCAL.md:165 — The comment # Jira-source env vars (runner-only — never enter sandbox) is misleading: JIRA_USER_EMAIL and JIRA_BASE_URL now enter the code sandbox via env.sandbox, and JIRA_TOKEN is no longer needed for the code agent runner.
    Remediation: Clarify that JIRA_USER_EMAIL and JIRA_BASE_URL enter the sandbox for code runs, and JIRA_TOKEN is only needed for triage runner post-scripts.

  • [defense-in-depth] scripts/pre-code-jira.src.sh — The pre-script's required-env-var guards for JIRA_ISSUE_CONTEXT_FILE, JIRA_USER_EMAIL, and JIRA_TOKEN are removed. With provider-backed delivery, a missing or misconfigured provider will surface at runtime (HTTP 401) rather than failing fast at pre-script time. The provider's credential resolution is the new validation gate.

  • [credential-exposure] skills/code-implementation/SKILL.md — The curl --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" pattern exposes the provider's opaque placeholder in shell history and process listings. The profile's enforcement: enforce mitigates the risk of real credential exposure.


Next steps:

  • /fs-fix — agent addresses review findings automatically
  • /fs-fix <your instruction> — agent fixes with your specific guidance
  • Push commits directly — review re-runs automatically on push
  • /fs-fix-stop — disable automatic fix runs for this PR

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-coder

fullsend-ai-coder Bot commented Aug 31, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Finished Fix · ✅ Success · Started 10:28 PM UTC · Completed 10:34 PM UTC

Commit: 8812312 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $1.61

@fullsend-ai-coder

Copy link
Copy Markdown
Contributor Author

🔧 Fix agent — iteration 1 (bot-triggered)

Fixed two stale references in LOCAL.md: updated the env var comment (line 165) to clarify which vars enter the sandbox, and replaced the prefetch description (lines 178–181) with the new provider-backed API access pattern. Disagreed with three informational findings: protected-path process note (no code fix needed), defense-in-depth observation (intentional design tradeoff), and credential-exposure note (mitigated by profile enforcement).

Fixed (2):

  1. LOCAL.md:178 still describes the removed Jira prefetch pattern (LOCAL.md): Updated lines 178–181 to describe the new provider-backed Jira API access pattern instead of the removed fullsend CLI / host_files / .issue-context.json prefetch.
  2. LOCAL.md:165 comment says runner-only but JIRA_USER_EMAIL and JIRA_BASE_URL now enter sandbox (LOCAL.md): Updated the comment to clarify that JIRA_TOKEN stays on the runner for post-script mutations while JIRA_USER_EMAIL and JIRA_BASE_URL enter the code sandbox as non-secret config for provider-backed API access.

Disagreed (3):

  1. 7 files under protected paths are modified and require human approval: This is an informational finding about process, not a code defect. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale. Human approval for protected-path changes is a process requirement handled outside the fix agent.
  2. Removed env var guards in pre-code-jira.src.sh mean misconfigured providers surface at runtime: This is an intentional design tradeoff acknowledged by the reviewer: the provider's credential resolution is the new validation gate. The PR's purpose is to remove runner-side credential handling. Re-adding guards would contradict the migration. Additionally, scripts/ is a protected path.
  3. curl --user pattern in SKILL.md exposes provider placeholder in shell history: The reviewer notes the profile's enforcement: enforce mitigates the risk of real credential exposure. The opaque placeholder is by design — it is not the real secret. Additionally, skills/ is a protected path.

Tests: passed

Next steps:

  • /fs-review — request a re-review of the changes
  • /fs-fix <your instruction> — run another fix pass with specific guidance
  • Push commits directly — review re-runs automatically on push
    Updated by fullsend fix agent

fullsend-ai-coder Bot added a commit that referenced this pull request Aug 31, 2026
Update two stale references in LOCAL.md that still described the
removed runner-side Jira prefetch pattern:

- Line 165: Clarify that JIRA_USER_EMAIL and JIRA_BASE_URL now enter
  the code sandbox as non-secret config, while JIRA_TOKEN stays on the
  runner for post-script mutations.
- Lines 178–181: Replace the fullsend CLI / host_files / .issue-context.json
  description with the new provider-backed API access pattern.

Addresses #1109
@fullsend-ai-review

fullsend-ai-review Bot commented Aug 31, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 10:35 PM UTC · Completed 10:54 PM UTC

Commit: 9d9e033 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $5.55

@fullsend-ai-review
fullsend-ai-review Bot dismissed their stale review August 31, 2026 22:54

Superseded by updated review

fullsend-ai-review[bot]

This comment was marked as outdated.

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-review fullsend-ai-review Bot added the requires-manual-review Review requires human judgment label Aug 31, 2026
Converge both triage and code agents on provider-backed Jira API
access so the real JIRA_TOKEN never enters either sandbox. The
jira-ro provider injects an opaque placeholder at the HTTP layer;
sandboxed curl calls authenticate through the provider boundary
instead of using the real secret.

Triage harness: remove JIRA_TOKEN from env.sandbox and
env/jira/triage.env. The provider (already attached) supplies the
placeholder. Runner-side post-scripts retain the real token via
env.runner for trusted mutations.

Code harness: attach providers/jira-ro.yaml and the
fullsend-jira-ro OpenShell profile. Remove the runner-side
.issue-context.json prefetch — the sandbox reads Jira work items
directly via the provider boundary. Remove JIRA_ISSUE_CONTEXT_FILE,
JIRA_USER_EMAIL, and JIRA_TOKEN from env.runner (no longer needed).
Add JIRA_USER_EMAIL and JIRA_BASE_URL to env.sandbox (non-secret
config for API calls).

Pre-script: strip credential requirements and issue-fetch logic
from pre-code-jira.src.sh, keeping URL validation and pre-commit
tool installation.

Skill: update code-implementation to query Jira directly via curl
instead of reading .issue-context.json.

Tests: add harness-jira-test.sh verifying provider/profile
selection and JIRA_TOKEN absence from sandbox config. Update
pre-code-jira-test.sh for the simplified pre-script.

Note: shellcheck could not run (not available in sandbox).
pre-commit hooks could not fetch remote repos (network policy);
ran equivalent checks directly. Pre-existing post-retro-test.sh
failures (16) are unrelated to this change.

Closes #1108
Update two stale references in LOCAL.md that still described the
removed runner-side Jira prefetch pattern:

- Line 165: Clarify that JIRA_USER_EMAIL and JIRA_BASE_URL now enter
  the code sandbox as non-secret config, while JIRA_TOKEN stays on the
  runner for post-script mutations.
- Lines 178–181: Replace the fullsend CLI / host_files / .issue-context.json
  description with the new provider-backed API access pattern.

Addresses #1109
@ralphbean
ralphbean force-pushed the agent/1108-jira-provider-credentials branch from 9d9e033 to 9007670 Compare September 1, 2026 21:03
@fullsend-ai-review

fullsend-ai-review Bot commented Sep 1, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 9:05 PM UTC · Completed 9:25 PM UTC

Commit: 9007670 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $7.72

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-review fullsend-ai-review Bot removed the requires-manual-review Review requires human judgment label Sep 1, 2026
@fullsend-ai-coder

fullsend-ai-coder Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Finished Fix · ✅ Success · Started 9:26 PM UTC · Completed 9:33 PM UTC

Commit: 9007670 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $1.81

- Update LOCAL.md comment to clarify JIRA_TOKEN is read by the jira-ro
  provider on the host, not consumed by the code agent's runner or
  sandbox environment (stale-reference finding)
- Add JIRA_USER_EMAIL and JIRA_TOKEN to base_env() in
  pre-code-jira-test.sh so no-jira-email-still-succeeds and
  no-jira-token-still-succeeds tests are no longer redundant with
  valid-jira-github-succeeds (test-inadequate finding)
- Refactor five near-identical Python-in-bash helpers in
  harness-jira-test.sh into a single parameterized jira_overlay_field()
  helper, reducing ~80 lines of repetition (code-organization finding)

Addresses #1109
@fullsend-ai-coder

Copy link
Copy Markdown
Contributor Author

🔧 Fix agent — iteration 2 (bot-triggered)

Fixed 3 findings: corrected stale LOCAL.md comment about JIRA_TOKEN scope, made redundant pre-code-jira tests meaningful by setting vars in base_env(), and refactored 5 near-identical harness test helpers into a single parameterized function. Recorded reasoned disagreements for 5 informational findings the reviewer acknowledged as acceptable.

Fixed (3):

  1. stale-reference: LOCAL.md comment claims JIRA_TOKEN stays on the runner for post-script mutations (LOCAL.md): Updated comment to clarify JIRA_TOKEN is read by the jira-ro provider on the host and never enters the code agent's runner or sandbox environment
  2. test-inadequate: no-jira-email-still-succeeds and no-jira-token-still-succeeds tests are redundant with valid-jira-github-succeeds (scripts/pre-code-jira-test.sh): Added JIRA_USER_EMAIL and JIRA_TOKEN to base_env() so they are set by default, then override them to empty in the specific tests to make them meaningfully distinct
  3. code-organization: five near-identical Python-in-bash helper functions differ only in the YAML key path (scripts/harness-jira-test.sh): Refactored jira_sandbox_env_keys, jira_runner_env_keys, jira_overlay_providers, jira_overlay_profiles, and jira_overlay_host_file_dests into a single parameterized jira_overlay_field() helper that accepts the YAML key path as a Python expression

Disagreed (5):

  1. protected-path: 7 files under protected paths are modified: This is a process gate requiring human approval, not a code fix. The PR links to issue refactor(jira): use OpenShell providers for triage and code credentials #1108 and explains the rationale. No code change can address this finding.
  2. incomplete-credential-removal: JIRA_TOKEN remains in triage overlay runner env: The reviewer acknowledges this is architecturally justified — runner-side post-scripts need the real credential for Jira API mutations. No change needed.
  3. credential-exposure: curl --user pattern places opaque token placeholder in process arguments: The reviewer acknowledges the placeholder is not the actual secret — the OpenShell proxy intercepts and substitutes the real credential at the HTTP layer under enforcement: enforce. No change needed.
  4. defense-in-depth: pre-script required-env-var guards removed: The reviewer acknowledges provider credential resolution is the new validation gate. A missing or misconfigured provider surfaces as HTTP 401 at runtime. No change needed.
  5. naming-convention: harness-jira-test.sh uses a different naming pattern from existing convention: The reviewer acknowledges the name is defensible since it tests harness YAML configuration rather than a specific script. No harness-jira.sh counterpart is expected.

Tests: passed

Decision points
  • Scope of LOCAL.md comment fix (alternatives: Rewrite the entire Jira section to clarify code vs triage differences, Update only the misleading comment about JIRA_TOKEN; rationale: Minimal fix: only the specific comment the reviewer flagged was inaccurate. The rest of the section correctly describes the setup.)

Next steps:

  • /fs-review — request a re-review of the changes
  • /fs-fix <your instruction> — run another fix pass with specific guidance
  • Push commits directly — review re-runs automatically on push
    Updated by fullsend fix agent

@fullsend-ai-review

fullsend-ai-review Bot commented Sep 1, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 9:35 PM UTC · Completed 9:56 PM UTC

Commit: faaebc6 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $8.65

fullsend-ai-review[bot]

This comment was marked as outdated.

fullsend-ai-review[bot]

This comment was marked as outdated.

@fullsend-ai-coder

fullsend-ai-coder Bot commented Sep 1, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Finished Fix · ✅ Success · Started 9:58 PM UTC · Completed 10:06 PM UTC

Commit: faaebc6 · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $2.12

The jira-ro provider handles authentication at the network layer via
enforcement: enforce, so --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" is
unnecessary. With JIRA_TOKEN removed from sandbox env in this PR, the
undefined variable created a functional gap in four skill files.

Remove --user flags from all curl examples in:
- skills/jira-forge/SKILL.md (8 occurrences)
- skills/issue-labels/jira/SKILL.md (2 occurrences)
- skills/jira-components/SKILL.md (2 occurrences)
- skills/code-implementation/SKILL.md (1 occurrence)

Update jira-forge/SKILL.md introductory text to document provider-backed
auth instead of referencing JIRA_USER_EMAIL/JIRA_TOKEN for Basic auth.

Addresses #1109
Add JIRA_TOKEN (alongside OPENAI_API_KEY) to a sandbox expansion
denylist enforced by a new test that scans all harness YAML files for
two leak paths:

  1. env.sandbox values — catches both direct keys and aliases
     (e.g. LEAK: "${JIRA_TOKEN}") that would expand the real
     credential into the sandbox under a different name.

  2. host_files with expand: true — catches expanded env files
     whose source references a denylisted variable.

Also wires harness-jira-test.sh and the new denylist test into the
Makefile script-test target so CI runs them on every push.

Addresses #1109
@ralphbean

Copy link
Copy Markdown
Member

I tried this end-to-end against production Jira from ralphbean/jira-triage-test.

With the harness pinned at 9007670, the sandbox used curl --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" and successfully read Jira through the provider boundary. The harness config did not place the real token in env.sandbox or the copied env file, so that value was the provider credential placeholder.

I then pinned the same test to current head 8b9fb2a and created FSENDAI-4922. The jira-ro provider became ready, and the sandbox correctly followed the updated skill by calling Jira without --user. Those requests returned the Jira "does not exist or no permission" response, although the trusted runner-side pre/post scripts could still mutate the issue. The target harness job itself completed successfully, but its triage result was insufficient because it could not read the issue: run 33581351747.

It looks like the provider can substitute the opaque token when curl constructs Basic auth, but does not originate the complete Jira Authorization header for a credential-free request. Should we keep --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" with the opaque placeholder, or change the provider so the credential-free curl form works?

@fullsend-ai-coder

Copy link
Copy Markdown
Contributor Author

🔧 Fix agent — iteration 4 (human-triggered)

Added sandbox credential expansion denylist enforcement via a new test script that scans all harness YAML files for JIRA_TOKEN and OPENAI_API_KEY references in two paths: (1) env.sandbox values including aliases, and (2) host_files with expand: true. Both harness-jira-test.sh and the new denylist test are now wired into the Makefile script-test target. All 28 denylist checks pass across 7 harness files.

Fixed (3):

  1. Add JIRA_TOKEN to sandbox expansion denylist with protection against env.sandbox aliases (scripts/sandbox-credential-boundary-test.sh): Created sandbox-credential-boundary-test.sh that scans all 7 harness YAML files for JIRA_TOKEN and OPENAI_API_KEY references in env.sandbox values (both direct keys and aliases like LEAK: "${JIRA_TOKEN}"). Uses Python+PyYAML to parse harness YAML and check all top-level and overlay sandbox env values.
  2. Add JIRA_TOKEN to sandbox expansion denylist with protection against host_files references (scripts/sandbox-credential-boundary-test.sh): The same test also scans all host_files entries with expand: true, reads their source env files, and checks for denylisted variable references. This catches the case where an expanded host file contains ${JIRA_TOKEN} which would be expanded to the real token by the runtime.
  3. Wire new tests into CI (Makefile): Added harness-jira-test.sh (was missing from script-test target) and sandbox-credential-boundary-test.sh to the Makefile script-test target so both run on every CI push.

Tests: passed

Strategy change: Iteration 4 — previous iterations focused on removing JIRA_TOKEN from harness config. This iteration takes a fundamentally different approach: instead of only removing the credential, it adds a proactive enforcement mechanism (static-analysis denylist test) that catches regressions across all harness files, including alias smuggling via env.sandbox values and expansion via host_files.

Decision points
  • Implemented denylist as a static-analysis test rather than a runtime config field (alternatives: Add a runtime config field to harness YAML schema, Create a static-analysis CI test that scans all harness files; rationale: The sandbox expansion denylist in the fullsend runtime is outside this repo's scope. A static-analysis test in CI provides defense-in-depth: any harness regression or child overlay that re-introduces JIRA_TOKEN in env.sandbox or expanded host_files will be caught before merge. The DENYLIST array in the test script is the single source of truth for denylisted credentials in this repo.)

Next steps:

  • /fs-review — request a re-review of the changes
  • /fs-fix <your instruction> — run another fix pass with specific guidance
  • Push commits directly — review re-runs automatically on push
    Updated by fullsend fix agent

@fullsend-ai-review

fullsend-ai-review Bot commented Sep 2, 2026

Copy link
Copy Markdown

🤖 Review · ⚠️ Cancelled · Started 2:14 AM UTC · Ended 2:15 AM UTC

Commit: dfd2d7e · View workflow run →

@ralphbean

Copy link
Copy Markdown
Member

I dug into whether the profile could synthesize the header for us. I do not think auth_style: bearer fits the credential and endpoint we have here.

The Jira credential is an Atlassian API token used against https://<tenant>.atlassian.net, and Atlassian documents that combination as Basic auth over email:api_token. Bearer auth is for OAuth access tokens and uses the api.atlassian.com/ex/jira/<cloudId>/... URL shape, so changing this profile to bearer would change both the credential model and the API endpoint.

OpenShell does support auth_style: basic, but its current Providers v2 docs say the static placement metadata is stored and validated while static injection still depends on environment placeholders. For Basic auth, the documented flow is that the agent constructs Authorization: Basic base64(user:<placeholder>); the proxy decodes it, replaces the placeholder, and re-encodes it. That is exactly what curl --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" produces.

So, I think the practical fix here is to restore --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" in the Jira sandbox calls. JIRA_TOKEN remains the opaque provider placeholder inside the sandbox, and the real token remains at the gateway boundary. Adding Basic-auth metadata to the profile may document the intended placement, but it does not currently remove the need for the request to carry the placeholder.

References: OpenShell Providers v2, OpenShell provider injection locations, and Atlassian Basic auth.

@ralphbean

Copy link
Copy Markdown
Member

/fs-fix

The production experiment shows that a credential-free Jira request is anonymous even when jira-ro is ready. Jira API tokens on the tenant URL require Basic auth over email:api_token, and OpenShell documents the static-provider flow as replacing a placeholder already carried in the Basic Authorization header.

Please restore --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" in every sandbox Jira curl command changed by this PR: skills/jira-forge/SKILL.md, skills/issue-labels/jira/SKILL.md, skills/jira-components/SKILL.md, and skills/code-implementation/SKILL.md. Keep the real token out of env.sandbox; JIRA_TOKEN in these commands should be the opaque value supplied by the attached provider, which curl embeds in the Basic header and OpenShell replaces at the proxy boundary.

Please also update the accompanying documentation and tests so they assert this distinction: the real token is never expanded into sandbox config or files, while sandbox requests still carry the opaque provider placeholder through Basic auth. Do not switch the profile to bearer auth, since that would require an OAuth token and the api.atlassian.com/ex/jira/<cloudId>/... endpoint model.

@fullsend-ai-coder

fullsend-ai-coder Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Finished Fix · ✅ Success · Started 2:17 AM UTC · Completed 2:24 AM UTC

Commit: dfd2d7e · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $2.44

Restore `--user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}"` in every sandbox
Jira curl command across jira-forge, issue-labels/jira,
jira-components, and code-implementation skills. Jira Cloud tenant
URLs require Basic auth (email:api_token); the OpenShell static
provider replaces the opaque JIRA_TOKEN placeholder in the Basic
Authorization header at the proxy boundary. Without the --user flag,
sandbox requests are anonymous even when the jira-ro provider is
attached.

Update docs/code.md and docs/triage.md to document this distinction:
the real token is never expanded into sandbox config or env files,
while sandbox curl commands carry the provider placeholder through
Basic auth.

Add test assertions in harness-jira-test.sh (skill-level --user
presence + no-bearer-auth guard) and sandbox-credential-boundary-test.sh
(positive complement verifying skills carry the placeholder).

Addresses #1109
@fullsend-ai-coder

Copy link
Copy Markdown
Contributor Author

🔧 Fix agent — iteration 5 (human-triggered)

Restored --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" in all sandbox Jira curl commands across 4 skill files. Updated docs to document the distinction: real token never enters sandbox config, while sandbox requests carry the opaque provider placeholder through Basic auth. Added test assertions for --user presence and no-bearer-auth guard.

Fixed (8):

  1. Restore --user Basic auth flag in skills/jira-forge/SKILL.md (skills/jira-forge/SKILL.md): Restored --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" in all 8 curl commands and updated the introductory text to explain that JIRA_TOKEN is the opaque provider placeholder, not the real secret
  2. Restore --user Basic auth flag in skills/issue-labels/jira/SKILL.md (skills/issue-labels/jira/SKILL.md): Restored --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" in the label-suggestion and JQL search curl commands
  3. Restore --user Basic auth flag in skills/jira-components/SKILL.md (skills/jira-components/SKILL.md): Restored --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" in the project components and issue components curl commands
  4. Restore --user Basic auth flag in skills/code-implementation/SKILL.md (skills/code-implementation/SKILL.md): Restored --user "${JIRA_USER_EMAIL}:${JIRA_TOKEN}" in the Jira issue fetch curl command and updated description to explain the opaque placeholder distinction
  5. Update documentation to assert the credential boundary distinction (docs/code.md): Updated Jira-source overlay description to explain that sandbox curl uses Basic auth with the provider placeholder, and OpenShell replaces it at the proxy boundary
  6. Update documentation to assert the credential boundary distinction (docs/triage.md): Updated Jira credentials migration note to document Basic auth with placeholder, proxy boundary replacement, and explicit warning against bearer auth
  7. Add tests asserting Basic auth placeholder presence in skills (scripts/harness-jira-test.sh): Added skill-level tests verifying --user flag presence and no-bearer-auth guard for all 4 Jira skill files
  8. Add positive complement test for credential boundary (scripts/sandbox-credential-boundary-test.sh): Added positive complement assertions verifying Jira skill files carry the opaque placeholder via --user Basic auth, complementing the existing negative denylist checks

Tests: passed

Strategy change: Previous iterations (especially commit 8b9fb2a) removed --user flags assuming the provider handles auth transparently at the network layer. This iteration reverses that: Jira Cloud requires Basic auth in the request, and the OpenShell provider replaces the placeholder inside the Basic Authorization header at the proxy boundary.

Decision points
  • Strategy change at iteration 5: previous iterations removed --user flags; this iteration reverses that direction per human instruction (alternatives: Keep credential-free curl (provider handles auth at network layer), Restore --user with opaque placeholder for Basic auth header; rationale: Jira Cloud tenant URLs require Basic auth (email:api_token). The OpenShell static-provider flow replaces a placeholder already carried in the Basic Authorization header — without --user, the request is anonymous even when the provider is attached.)

Next steps:

  • /fs-review — request a re-review of the changes
  • /fs-fix <your instruction> — run another fix pass with specific guidance
  • Push commits directly — review re-runs automatically on push
    Updated by fullsend fix agent

@fullsend-ai-review

fullsend-ai-review Bot commented Sep 2, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 2:26 AM UTC · Completed 2:46 AM UTC

Commit: 8320a1f · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $9.60

@fullsend-ai-review fullsend-ai-review Bot added risk/elevated PR risk: elevated and removed risk/moderate PR risk: moderate labels Sep 2, 2026

@fullsend-ai-review fullsend-ai-review Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the review comment for full details.

Comment thread scripts/harness-jira-test.sh Outdated
@fullsend-ai-review fullsend-ai-review Bot removed the requires-manual-review Review requires human judgment label Sep 2, 2026
@fullsend-ai-coder

fullsend-ai-coder Bot commented Sep 2, 2026

Copy link
Copy Markdown
Contributor Author

🤖 Finished Fix · ❌ Failure (running pre-script: exit status 1) · Started 2:48 AM UTC · Completed 2:48 AM UTC

Commit: 8320a1f · View workflow run →

Effort: high

Signed-off-by: Ralph Bean <rbean@redhat.com>
@ralphbean
ralphbean enabled auto-merge September 2, 2026 17:04
@fullsend-ai-review

fullsend-ai-review Bot commented Sep 2, 2026

Copy link
Copy Markdown

🤖 Finished Review · ✅ Success · Started 5:04 PM UTC · Completed 5:42 PM UTC

Commit: 823e84b · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $8.94

@ralphbean
ralphbean added this pull request to the merge queue Sep 2, 2026
Merged via the queue into main with commit 995e6c6 Sep 2, 2026
20 checks passed
@ralphbean
ralphbean deleted the agent/1108-jira-provider-credentials branch September 2, 2026 17:21
@fullsend-ai-retro

fullsend-ai-retro Bot commented Sep 2, 2026

Copy link
Copy Markdown

🤖 Finished Retro · ✅ Success · Started 5:22 PM UTC · Completed 5:36 PM UTC

Commit: 823e84b · View workflow run →

Runtime: claude · Model: opus → claude-opus-4-6 · Effort: high · Cost: $5.73

@fullsend-ai-retro

Copy link
Copy Markdown

Retro: PR #1109 — use OpenShell providers for Jira credentials

Timeline

Issue #1108 requested converging triage and code Jira overlays on OpenShell provider-backed credential delivery. The triage agent ran successfully ($1.05, 6 min). The code agent created PR #1109 with a 14-file, 477+/299− implementation ($5.65, 16 min). Six review and six fix iterations followed over ~44 hours before the human maintainer approved and merged.

What went well

  • Triage was fast and accurate, correctly identifying the two channels through which JIRA_TOKEN entered the sandbox.
  • The code agent's initial implementation was structurally sound — it correctly attached the jira-ro provider, removed JIRA_TOKEN from env.sandbox, and updated the pre-script.
  • Review iterations 1–2 caught real issues: stale LOCAL.md references, redundant test assertions, and duplicated Python-in-bash helper functions.
  • The human-directed sandbox credential boundary denylist test (iteration 4) was a valuable hardening addition that the agents would not have proposed on their own.
  • Human production testing against Jira Cloud caught a critical runtime failure that no static analysis could detect.

What went poorly

Review-directed regression (primary issue). In Review Iteration 4 (commit faaebc6), the review agent raised a HIGH [consumer-completeness] finding claiming JIRA_TOKEN was absent from the sandbox and a MEDIUM [runtime-mechanism-failure] finding recommending removal of --user flags because the provider "handles credential injection transparently at the network layer." Both claims were wrong: the jira-ro provider supplies JIRA_TOKEN as an opaque placeholder independently of env.sandbox, and Jira Cloud requires Basic auth — the provider replaces the placeholder inside the Authorization header, not by injecting a header onto a credential-free request. Fix Iteration 3 (commit 8b9fb2a) removed 13 --user flags across 4 skill files based on this guidance. Human production testing revealed the breakage, and Fix Iteration 5 (commit 8320a1f) had to reverse all 13 removals — a full oscillation cycle.

Repeated informational finding. The [incomplete-credential-removal] finding about JIRA_TOKEN remaining in the triage runner env was raised in 4+ consecutive review iterations, each time acknowledged as architecturally justified. This consumed review tokens without adding value.

Test tooling mismatch. The fix agent created test scripts using Python YAML parsing (python3 -c "import yaml; ..."), but the CI environment uses yq. This caused CI failure, and the human maintainer had to push a manual fix (commit 823e84b).

Cost. Estimated total: ~$81+ across all agent runs (6 reviews at $5–10 each, 6 fix iterations, triage, code). The oscillation cycle (remove then restore --user flags) and repeated findings were the primary cost drivers beyond the baseline.

Existing issues with new evidence

Proposals filed

@fullsend-ai-review

Copy link
Copy Markdown

Review skipped — this PR is already merged.

The /fs-review command only reviews open PRs/MRs.

Posted by fullsend post-review check

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready-for-review Triggers review agent dispatch risk/elevated PR risk: elevated

Projects

None yet

Development

Successfully merging this pull request may close these issues.

refactor(jira): use OpenShell providers for triage and code credentials

1 participant