feat(#6334): add openshell provider and profile for Jira

[fullsend-ai-coder]

Summary

Add openshell credential provider and profile for Jira Cloud, enabling agents running inside the sandbox to reach the Jira REST API via credential delivery tier 2 (ADR 0025).

Related Issue

Closes #6334

Changes

• Add providers/jira.yaml — declares the jira provider with fullsend-jira profile type and the _NOOP_JIRA credential placeholder (OpenShell Review agent should withhold approval when dependency bot PR violates project's own dependency config #1978 workaround), following the existing provider pattern
• Add profiles/fullsend-jira.yaml — scopes egress to *.atlassian.net:443 with read-write access and enforcement, allows curl and node binaries, categorized as data

Design decisions

• Wildcard host (*.atlassian.net): Jira Cloud instances are per-customer, so the profile uses a wildcard. Self-hosted instances would need a custom profile via ADR 0075 local-path support.
• Category: data — Jira is an external data source, matching the pattern of gitleaks and package-registries.
• Binaries: curl and node — agents may use either to make HTTP requests to the Jira API from within the sandbox.
• Open questions: The issue raises composite credential injection (Basic auth requires base64-encoding email:token). The provider uses the standard single-placeholder pattern; composite transformation would need upstream OpenShell support. Users can provide a pre-encoded token as a workaround.

Testing

• go test ./internal/scaffold/... passes (includes TestAllScaffoldYAMLDocumentStartMarker which validates the --- document start marker)
• go vet ./internal/scaffold/... passes
• Secret scan passes
• YAML files follow existing provider/profile patterns exactly

---

Closes #6334

Post-script verification

• Branch is not main/master (agent/6334-add-jira-provider-profile)
• Secret scan passed (gitleaks — 9ecbd9b395b0e00a10f2a959b7e83503ff718bd1..HEAD)
• PR body secret scan passed (gitleaks — no-git)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 6:18 PM UTC · Completed 6:31 PM UTC

Commit: 41bcc3f · View workflow run →

[fullsend-ai-review]

Review

Findings

Medium

• [naming-inconsistency-with-triage] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:2 — The provider and profile use atlassian-cloud naming, diverging from the triage agent’s explicit guidance in issue Add openshell credential provider and profile for JIRA #6334. The triage comment proposed filenames providers/jira.yaml and profiles/fullsend-jira.yaml. Rather than adopting the triage-specified names, the PR uses atlassian-cloud naming throughout. Every existing provider/profile pair in the scaffold uses a service-specific name (github, vertex-ai, gitleaks), not a parent-platform name. The issue title itself is “Add openshell credential provider and profile for JIRA.”
  Remediation: Rename both files to match the triage guidance and existing scaffold naming convention: profiles/fullsend-jira.yaml (profile id: fullsend-jira) and providers/jira.yaml (provider name: jira, type: fullsend-jira). The *.atlassian.net wildcard endpoint can remain — that is a network-policy detail, not a service identifier.

Low

• [documentation accuracy] docs/guides/user/jira-integration.md:62 — The documentation instructs the user to generate a base64-encoded token (printf 'you@example.com:your-api-token' | base64) but does not explain where that token should be configured or injected. The actual provider YAML contains only a no-op credential _NOOP_ATLASSIAN_CLOUD: "" as a workaround for OpenShell issue Review agent should withhold approval when dependency bot PR violates project's own dependency config #1978 — it does not declare any credential key where the user would supply the pre-encoded token.
  Remediation: Clarify in the documentation how/where the pre-encoded token is actually injected at runtime (e.g., via a separate environment variable or the reusable workflow’s secrets configuration).

• [permission-expansion] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:11 — Wildcard host *.atlassian.net permits egress to any Atlassian Cloud tenant. Accepted risk documented inline (lines 7–10) and in issue Add openshell credential provider and profile for JIRA #6334. Follows established codebase pattern (*.googleapis.com in fullsend-vertex-ai, *.blob.core.windows.net in fullsend-github-artifacts).

• [permission-expansion] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:17 — The **/curl binary allowlist entry is unique among scaffold profiles — no other profile permits curl. While curl is scoped by endpoint enforcement rules, it supports features (e.g., --upload-file, SSRF via redirect following, protocol downgrades) that make it a more flexible egress vector than node with fetch.
  Remediation: Consider removing **/curl from the binaries list if node with fetch is sufficient for HTTP requests.

• [scope-drift] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:1 — The profile is named and described as generic “Atlassian Cloud” infrastructure, but the authorized scope from issue Add openshell credential provider and profile for JIRA #6334 is Jira-specific. See also: [naming-inconsistency-with-triage] finding at this location.
  Remediation: Update the description to “Jira Cloud API access for fullsend agents” to match the authorized scope.

• [consistency-with-established-patterns] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:4 — The profile description uses generic service naming (“Atlassian Cloud”) rather than the specific service the integration targets (Jira). Every existing profile description names the concrete service. See also: [naming-inconsistency-with-triage] finding at this location.

Previous run

Review

Findings

Medium

• [technical documentation accuracy] docs/guides/user/jira-integration.md:60 — The documentation states "When the scaffold is applied to your repo, these files are installed automatically" but this is incorrect. The profiles/ and providers/ directories are in the layeredDirs list in internal/scaffold/scaffold.go, meaning WalkFullsendRepo skips them during scaffold installation. TestLayeredDirsNotInstalled verifies they are never written to the .fullsend repo. These files are provided at runtime via WalkLayeredContent. The claim that they are "installed automatically" will mislead users into expecting these files in their .fullsend directory.
  Remediation: Reword to reflect the actual delivery mechanism, e.g.: "These are layered content — they are provided at runtime by reusable workflows, not written to the .fullsend directory."

• [naming-convention] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:2 — Profile ID fullsend-atlassian-cloud breaks the naming convention. Every existing provider-profile pair uses consistent naming where the provider name matches the profile suffix after fullsend-: github→fullsend-github, vertex-ai→fullsend-vertex-ai, gitleaks→fullsend-gitleaks, etc. The new provider is named jira but references profile type fullsend-atlassian-cloud, breaking the 1:1 naming symmetry.
  Remediation: Rename the profile ID to fullsend-jira and update the provider's type field to match.

Low

• [permission-expansion] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:11 — Wildcard host *.atlassian.net permits egress to any Atlassian Cloud tenant. Accepted risk documented inline (lines 7-10) and in issue Add openshell credential provider and profile for JIRA #6334. Follows established codebase pattern (*.googleapis.com in fullsend-vertex-ai, *.blob.core.windows.net in fullsend-github-artifacts).
  Remediation: When OpenShell gains profile templating, revisit to scope the host to the specific tenant.

• [permission-expansion] internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml:17 — The **/curl binary allowlist entry is unique among scaffold profiles — no other profile permits curl. While curl is scoped by endpoint enforcement rules, it supports features (e.g., --upload-file, SSRF via redirect following, protocol downgrades) that make it a more flexible egress vector. The node binary is already permitted and could serve the same HTTP needs.
  Remediation: Consider whether curl is strictly necessary or if node-based HTTP clients are sufficient.

• [comment-format] internal/scaffold/fullsend-repo/providers/jira.yaml:4 — Comment block style differs from existing providers, which use single-line issue references. The jira provider has a multi-line block with both a GitHub issue reference and credential format documentation. The additional context is useful given the non-obvious _NOOP_JIRA workaround, but the format diverges from conventions.
  Remediation: Consider separating the workaround reference from the credential format documentation to better match the established pattern.

Previous run (2)

Review

Findings

Medium

• [permission-expansion] internal/scaffold/fullsend-repo/profiles/fullsend-jira.yaml:7 — Wildcard host *.atlassian.net permits egress to any Atlassian Cloud tenant, not just the org's own instance. An agent with this profile could read or write data in any reachable Jira Cloud tenant if credentials happen to be valid cross-tenant. The issue (Add openshell credential provider and profile for JIRA #6334) and triage agent acknowledge this trade-off and note that per-tenant scoping requires profile templating not yet supported by OpenShell, making this an accepted risk for now.
  Remediation: Document the accepted risk in an ADR or inline comment in the profile. When OpenShell gains profile templating, revisit to scope the host to the specific tenant.

Low

• [scope-vs-intent] internal/scaffold/fullsend-repo/providers/jira.yaml:5 — Issue Add openshell credential provider and profile for JIRA #6334 raised an open question about composite credential injection (email:token base64-encoded for Jira Basic auth). The triage agent resolved this as 'use single pre-encoded token'. However, neither the profile nor the provider documents this design decision or the expected credential format.
  Remediation: Add a comment in providers/jira.yaml explaining the expected credential format.

• [permission-expansion] internal/scaffold/fullsend-repo/profiles/fullsend-jira.yaml:13 — The **/curl binary allowlist entry is new — no existing profile permits curl. While curl is scoped by the endpoint enforcement rules, curl supports features (e.g., --upload-file, --data @/path, SSRF via redirect following, protocol downgrades via --proto) that make it a more flexible egress vector than purpose-built CLIs like gh.
  Remediation: Consider whether curl is strictly necessary or if node-based HTTP clients (already permitted) are sufficient.

• [missing-documentation] docs/guides/user/jira-integration.md:48 — The Jira integration guide's 'Credential setup' section describes only host-side credential configuration. This PR adds a scaffold-level OpenShell credential provider and network profile. The guide does not mention this sandbox-side credential/network plumbing.
  Remediation: Add a subsection explaining that the scaffold now ships a fullsend-jira profile and jira provider, which grant sandboxed agents network access to *.atlassian.net.

---

Labels: PR adds sandbox-level OpenShell provider and egress profile for Jira Cloud

[ralphbean]

/fs-fix address unresolved findings

[fullsend-ai-coder]

🤖 Finished Fix · ✅ Success · Started 8:33 PM UTC · Completed 8:40 PM UTC

Commit: 41bcc3f · View workflow run →

[fullsend-ai-coder]

🔧 Fix agent — iteration 1 (human-triggered)

Addressed 4 of 4 review findings. Renamed profile to fullsend-atlassian-cloud per maintainer instruction, documented accepted wildcard risk, added credential format documentation, and added sandbox plumbing docs to the Jira integration guide. Curl binary inclusion accepted as-is per maintainer.

Fixed (4):

1. *Wildcard host .atlassian.net permits egress to any Atlassian Cloud tenant (internal/scaffold/fullsend-repo/profiles/fullsend-atlassian-cloud.yaml): Renamed profile from fullsend-jira to fullsend-atlassian-cloud (file, id, display_name, description) to make the broader scope clear, and added inline comment documenting the accepted risk per maintainer instruction
2. Neither the profile nor the provider documents the expected credential format (internal/scaffold/fullsend-repo/providers/jira.yaml): Added comment explaining that Jira Cloud Basic auth requires a pre-encoded base64 email:api-token string, with generation command
3. Provider type reference must match renamed profile (internal/scaffold/fullsend-repo/providers/jira.yaml): Updated provider type from fullsend-jira to fullsend-atlassian-cloud to match the renamed profile
4. Jira integration guide does not mention sandbox-side credential/network plumbing (docs/guides/user/jira-integration.md): Added 'Sandbox credentials and network access' subsection under Credential setup explaining the scaffold's fullsend-atlassian-cloud profile and jira provider

Disagreed (1):

1. curl binary allowlist is a more flexible egress vector than purpose-built CLIs: Maintainer explicitly accepted curl as fine for now (inline comment: 'Yes, this is fine for now'). No code change needed.

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-review]

🤖 Review · ❌ Terminated · Started 8:42 PM UTC · Ended 8:59 PM UTC

Commit: 0bb84fd · View workflow run →

[github-actions]

Site preview

Preview: https://2b4fa46b-site.fullsend-ai.workers.dev

Commit: 15d9c392aa7104ccc7edbef15bff1e07d2ff6dcd

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:42 PM UTC · Completed 8:59 PM UTC

Commit: 0bb84fd · View workflow run →

[ralphbean]

/fs-fix address remaining open findings

[fullsend-ai-coder]

🤖 Finished Fix · ✅ Success · Started 7:40 PM UTC · Completed 7:47 PM UTC

Commit: 0bb84fd · View workflow run →

[fullsend-ai-coder]

🔧 Fix agent — iteration 2 (human-triggered)

Addressed 3 open review findings: fixed documentation accuracy (layered content, not installed), renamed provider to atlassian-cloud to match profile naming convention per human instruction, and normalized comment format. Disagreed with 2 duplicate findings already resolved in iteration 1.

Fixed (3):

1. technical documentation accuracy — docs say files are installed automatically (docs/guides/user/jira-integration.md): Reworded to reflect actual delivery mechanism: these are layered content provided at runtime by reusable workflows, not written to the .fullsend directory
2. naming-convention — provider name jira does not match profile suffix atlassian-cloud (internal/scaffold/fullsend-repo/providers/atlassian-cloud.yaml): Renamed provider file from jira.yaml to atlassian-cloud.yaml, updated name field from jira to atlassian-cloud, and updated credential placeholder from _NOOP_JIRA to _NOOP_ATLASSIAN_CLOUD to follow the 1:1 naming convention (provider name = profile suffix after fullsend-)
3. comment-format — multi-line comment block diverges from single-line convention (internal/scaffold/fullsend-repo/providers/atlassian-cloud.yaml): Normalized comment to the single-line workaround reference used by all other providers. Moved credential format documentation to the user guide (docs/guides/user/jira-integration.md) where it is more discoverable

Disagreed (2):

1. *permission-expansion — wildcard host .atlassian.net: Duplicate of previous review cycle finding. Already addressed in iteration 1 with inline risk comment. Human confirmed as duplicate.
2. permission-expansion — curl binary allowlist: Duplicate of previous review cycle finding. Human confirmed curl is fine for now in iteration 1. Human confirmed as duplicate.

Tests: passed

Decision points

• Chose to rename provider to match profile rather than renaming profile to match provider (alternatives: Rename profile to fullsend-jira (reviewer suggestion), Rename provider to atlassian-cloud (human instruction); rationale: Human explicitly instructed to rename the file to match the profile id (atlassian-cloud). The broader atlassian-cloud name reflects the fact the profile permits egress to all Atlassian Cloud services, not just Jira.)
• Moved credential format documentation from provider comment to user guide (alternatives: Keep multi-line comment in provider file, Add separate documentation file; rationale: Satisfies both the comment-format finding (normalize to single-line convention) and keeps the credential format info accessible in the user-facing guide where users actually look for setup instructions)

---

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]

🤖 Finished Review · ✅ Success · Started 7:49 PM UTC · Completed 8:05 PM UTC

Commit: 15d9c39 · View workflow run →

[fullsend-ai-retro]

🤖 Finished Retro · ❌ Failure · Started 8:28 PM UTC · Completed 8:28 PM UTC

Commit: 15d9c39 · View workflow run →