feat(mint): add e2e agent role for pool testing by ifireball · Pull Request #2407 · fullsend-ai/fullsend

ifireball · 2026-06-18T07:53:55Z

Summary

Add e2e to mintcore canonical role permissions (org-admin-equivalent + actions_variables: read for future cross-org policy reads)
Add e2e to config.ValidRoles() so CLI validation and error messages stay aligned
Sync mintsrc/mintcore/github.go.embed

Prerequisite for #2155: after merge + mint deploy, operators can run fullsend mint add-role e2e to create/register the e2e app without pool org enrollment.

Test plan

go test ./internal/mintcore/...
go test ./internal/cli/... -run TestValidateMintSetupRole
go test ./internal/dispatch/gcf/... -run EmbeddedMintSource

Follow-up

After this merges and mint is redeployed:

fullsend mint add-role e2e --org … (or --slug + --pem)
Rebase #2277 (cross-org e2e auth) on main
Pool org install + admin foreign allow

Made with Cursor

Register e2e in mintcore permissions and config.ValidRoles so mint add-role can bootstrap the e2e app before cross-org CI auth (fullsend-ai#2155). Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

github-actions · 2026-06-18T07:55:36Z

Site preview

Preview: https://f7cab97d-site.fullsend-ai.workers.dev

Commit: 01c65cf93724686407fb31041e30e1c9b46ed77b

fullsend-ai-review · 2026-06-18T07:57:33Z

🤖 Review · ⚠️ Cancelled · Started 7:57 AM UTC · Ended 8:06 AM UTC
Commit: 4e21a60 · View workflow run →

Update TestValidRoles for the eighth role added for pool e2e minting. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

fullsend-ai-review · 2026-06-18T08:10:22Z

🤖 Finished Review · ✅ Success · Started 8:10 AM UTC · Completed 8:22 AM UTC
Commit: 2509f5e · View workflow run →

codecov · 2026-06-18T08:12:25Z

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

fullsend-ai-review · 2026-06-18T08:22:22Z

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, and no code-level constraint restricts the role to known test-pool orgs. The linked issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155 states a constraint to "limit minted e2e credentials to the dedicated test org pool" but this constraint is not enforced in code.
Remediation: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint (e.g., an org allowlist in the mint handler or a dedicated env var) restricting the e2e role to known test-pool orgs.

Medium

[missing-doc] docs/guides/infrastructure/infrastructure-reference.md:80 — The Role Permissions Matrix table documents the GitHub permissions for each role but does not include the newly added e2e role. This is a reference table used by administrators to understand permission boundaries. The table currently lists fullsend, triage, coder, review, fix, retro, prioritize but is missing e2e. Furthermore, the table lacks columns for administration, organization_administration, secrets, and members permissions which the e2e role uniquely requires.
Remediation: Add a row for the e2e role to the permissions matrix table with its specific permissions. Add columns for administration, organization_administration, secrets, and members.

Low

[scope-inconsistency] internal/config/config.go:94 — The e2e role is added to ValidRoles() but intentionally excluded from DefaultAgentRoles() and PerRepoDefaultRoles(). ValidRoles() is used for config validation, but e2e is a pool/CI mint role that should never appear in org config files. The comment in harnesswrappers.go states "The e2e role is a pool/CI mint role and is not installed as an agent app", but ValidRoles() is not documented as including non-agent roles. The new TestValidRoles_RecognizedByMintcore test provides drift detection.
Remediation: Add a comment to ValidRoles() clarifying it includes mint-only roles that are not installed as agent apps.
[test-coverage] internal/layers/harnesswrappers_test.go:329 — TestHarnessesForRole table-driven test does not include a test case for the new e2e role. With the diff applied, harnessesForRole("e2e") returns nil (grouped with "fullsend"). Without a dedicated test entry, this behavior is only implicitly covered and a future refactor could silently regress it.
Remediation: Add {"e2e", nil} to the test table.
[fail-closed-analysis] internal/mintcore/handler.go:83 — The mint handler's role gating remains fail-closed: allowedRoles is derived from ROLE_APP_IDS when ALLOWED_ROLES is unset, and both must explicitly include e2e for the role to be usable. The e2e role is excluded from both DefaultAgentRoles() and PerRepoDefaultRoles(), so it will not be auto-installed. The harnessesForRole change correctly returns nil for e2e. These are meaningful mitigating controls.

Previous run

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, and no code-level constraint restricts the role to known test-pool orgs.
Remediation: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

Medium

[scope-inconsistency] internal/config/config.go:94 — The e2e role is added to ValidRoles() but intentionally excluded from DefaultAgentRoles() and PerRepoDefaultRoles(). ValidRoles() is used for config validation, but e2e is a pool/CI mint role that should never appear in org config files. The comment in harnesswrappers.go states "The e2e role is a pool/CI mint role and is not installed as an agent app", but ValidRoles() is not documented as including non-agent roles. See also: [scope-ambiguity] finding at this location.
Remediation: Add a comment to ValidRoles() clarifying it includes mint-only roles that are not installed as agent apps.

Low

[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() makes it configurable in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES/ROLE_APP_IDS environment-variable controls, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role. See also: [scope-inconsistency] finding at this location.
[test-coverage] internal/layers/harnesswrappers_test.go:329 — TestHarnessesForRole table-driven test does not include a test case for the new e2e role. Adding {"e2e", nil} to the test table would guard against future regressions.
[consumer-completeness] internal/config/config.go:105 — DefaultAgentRoles() does not include e2e, so it will not be installed during standard enrollment. This appears intentional for an opt-in pool testing role.
[fail-closed-analysis] internal/mintcore/handler.go:83 — The mint handler's role gating fails closed correctly: checkAllowedRole returns false for all roles when ALLOWED_ROLES and ROLE_APP_IDS are empty. The e2e role requires explicit provisioning in both. These are meaningful mitigating controls.
[test-coverage] internal/forge/github/types_test.go — TestAgentAppConfig_E2e covers all 10 permission fields and empty events. TestAgentAppConfig_E2eMatchesMintcorePermissions cross-checks manifest vs mintcore. TestValidRoles_RecognizedByMintcore catches future drift. Test coverage across config, CLI, and mintcore is adequate.
[incomplete-authorization] internal/forge/github/types.go:142 — AgentAppConfig has an e2e case but harnesswrappers.go states it is not installed as an agent app. This is consistent — AgentAppConfig defines the GitHub App manifest (needed for mint add-role), while harnessesForRole controls webhook harness generation. These serve different purposes.
[alphabetical-ordering] internal/forge/github/types.go:141 — The new e2e case is appended after existing cases. The existing switch cases are not strictly alphabetically ordered (they appear roughly chronological), so this follows the established pattern.

Labels: PR adds a new privileged role to the token mint system for e2e pool testing

Labels: PR adds a new role to the token mint system for e2e pool testing.

Previous run (2)

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, nor does the code enforce the pool-only constraint from issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
Remediation: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

Medium

[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() makes it configurable in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls per mint instance, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role. Issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155 explicitly constrains: "Limit minted e2e credentials to the dedicated test org pool."
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[consumer-completeness] internal/config/config.go:105 — DefaultAgentRoles() does not include e2e, so it will not be installed during standard enrollment. This appears intentional for an opt-in pool testing role.
[fail-closed-analysis] internal/mintcore/handler.go:83 — The mint handler's role gating fails closed correctly: checkAllowedRole returns false for all roles when ALLOWED_ROLES and ROLE_APP_IDS are empty. The e2e role requires explicit provisioning in both. These are meaningful mitigating controls.
[architectural-trajectory] internal/forge/github/types.go — The e2e role is the most privileged in the system, exceeding even the fullsend orchestrator role. Architecturally appropriate for its stated purpose but reinforces the importance of the org-restriction constraint from E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
[test-coverage] internal/forge/github/types_test.go — TestAgentAppConfig_E2e covers all 10 permission fields and empty events. TestAgentAppConfig_E2eMatchesMintcorePermissions cross-checks manifest vs mintcore. TestValidRoles_RecognizedByMintcore catches future drift. Test coverage across config, CLI, and mintcore is adequate.

Previous run

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, nor does the code enforce the pool-only constraint from issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
Remediation: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

Medium

[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() makes it configurable in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls per mint instance, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role. Issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155 explicitly constrains: "Limit minted e2e credentials to the dedicated test org pool."
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[intent-scope-mismatch] internal/forge/github/types.go — The role name e2e does not clearly signal its elevated, test-infrastructure-only scope. See also: [permission-expansion] and [scope-ambiguity] findings above.
[consumer-completeness] internal/config/config.go:105 — DefaultAgentRoles() does not include e2e, so it will not be installed during standard enrollment. This appears intentional for an opt-in pool testing role.
[fail-closed-analysis] internal/mintcore/handler.go:83 — The mint handler's role gating fails closed correctly: checkAllowedRole returns false for all roles when ALLOWED_ROLES and ROLE_APP_IDS are empty. The e2e role requires explicit provisioning in both. These are meaningful mitigating controls.
[architectural-trajectory] internal/forge/github/types.go — The e2e role is the most privileged in the system, exceeding even the fullsend orchestrator role. Architecturally appropriate for its stated purpose but reinforces the importance of the org-restriction constraint from E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
[test-coverage] internal/forge/github/types_test.go — TestAgentAppConfig_E2e covers all 10 permission fields and empty events. Test coverage across config, CLI, and mintcore is adequate.

Previous run

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the codebase requests administration or organization_administration at the mintcore level. Combined with secrets: write, a compromised e2e token could reconfigure the org, exfiltrate secrets, or add malicious collaborators.
Remediation: Apply least privilege: (1) Remove organization_administration: write unless tests need org-level admin. (2) Remove or downscope administration: write. (3) Remove members: write unless tests manage org membership. (4) Remove secrets: write unless tests must create/rotate secrets. (5) Document justification for each remaining permission.

Medium

[consumer-completeness] internal/forge/github/types.go:64 — AgentAppConfig() has no case for e2e in its switch statement, falling through to the default case which grants only issues: read permission. If someone creates the e2e GitHub App via the manifest flow (mint add-role --org), the app will be created with only issues: read, producing a permissions mismatch with what the mint will request at token-creation time.
Remediation: Add an explicit case "e2e" to AgentAppConfig() that sets AppPermissions matching canonicalRolePermissions for the e2e role.
[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() means it can be configured in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls that restrict which roles can actually mint tokens, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role.
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[consumer-completeness] internal/forge/github/types.go:41 — DefaultAgentRoles() does not include e2e. If a user enrolls with --agents e2e and later unenrolls without specifying agents, the cleanup loop will skip the e2e app. This mirrors the existing gap for the fix role.
[consumer-completeness] internal/forge/github/types.go:6 — The AppPermissions struct lacks fields for secrets and organization_administration. Even if a case for e2e is added to AgentAppConfig(), these two permissions cannot be set without extending the struct.
[formatting-consistency] internal/mintcore/github.go:67 — The e2e role permission map uses multi-line formatting while all other roles use single-line. With 11 entries the multi-line format is arguably more readable, but it breaks visual consistency.
[missing-architectural-documentation] internal/config/config.go:94 — The e2e role is added without updating AGENTS.md or other documentation. Since this is a prerequisite PR, documentation can follow in the integration PR.
[naming-alignment] internal/config/config.go:94 — The role is named e2e, which diverges from the existing responsibility-based naming convention (triage, coder, review, etc.). The name accurately describes its test-infrastructure purpose.

Previous run (3)

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, nor does the code enforce the pool-only constraint from issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
Remediation: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

Medium

[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() makes it configurable in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls per mint instance, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role. Issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155 explicitly constrains: "Limit minted e2e credentials to the dedicated test org pool."
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[consumer-completeness] internal/config/config.go:105 — DefaultAgentRoles() does not include e2e, so it will not be installed during standard enrollment. This appears intentional for an opt-in pool testing role.
[fail-closed-analysis] internal/mintcore/handler.go:83 — The mint handler's role gating fails closed correctly: checkAllowedRole returns false for all roles when ALLOWED_ROLES and ROLE_APP_IDS are empty. The e2e role requires explicit provisioning in both. These are meaningful mitigating controls.
[architectural-trajectory] internal/forge/github/types.go — The e2e role is the most privileged in the system, exceeding even the fullsend orchestrator role. Architecturally appropriate for its stated purpose but reinforces the importance of the org-restriction constraint from E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
[test-coverage] internal/forge/github/types_test.go — TestAgentAppConfig_E2e covers all 10 permission fields and empty events. TestAgentAppConfig_E2eMatchesMintcorePermissions cross-checks manifest vs mintcore. TestValidRoles_RecognizedByMintcore catches future drift. Test coverage across config, CLI, and mintcore is adequate.

Previous run (4)

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, nor does the code enforce the pool-only constraint from issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
Remediation: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

Medium

[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() makes it configurable in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls per mint instance, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role. Issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155 explicitly constrains: "Limit minted e2e credentials to the dedicated test org pool."
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[intent-scope-mismatch] internal/forge/github/types.go — The role name e2e does not clearly signal its elevated, test-infrastructure-only scope. See also: [permission-expansion] and [scope-ambiguity] findings above.
[consumer-completeness] internal/config/config.go:105 — DefaultAgentRoles() does not include e2e, so it will not be installed during standard enrollment. This appears intentional for an opt-in pool testing role.
[fail-closed-analysis] internal/mintcore/handler.go:83 — The mint handler's role gating fails closed correctly: checkAllowedRole returns false for all roles when ALLOWED_ROLES and ROLE_APP_IDS are empty. The e2e role requires explicit provisioning in both. These are meaningful mitigating controls.
[architectural-trajectory] internal/forge/github/types.go — The e2e role is the most privileged in the system, exceeding even the fullsend orchestrator role. Architecturally appropriate for its stated purpose but reinforces the importance of the org-restriction constraint from E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
[test-coverage] internal/forge/github/types_test.go — TestAgentAppConfig_E2e covers all 10 permission fields and empty events. Test coverage across config, CLI, and mintcore is adequate.

Previous run

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the codebase requests administration or organization_administration at the mintcore level. Combined with secrets: write, a compromised e2e token could reconfigure the org, exfiltrate secrets, or add malicious collaborators.
Remediation: Apply least privilege: (1) Remove organization_administration: write unless tests need org-level admin. (2) Remove or downscope administration: write. (3) Remove members: write unless tests manage org membership. (4) Remove secrets: write unless tests must create/rotate secrets. (5) Document justification for each remaining permission.

Medium

[consumer-completeness] internal/forge/github/types.go:64 — AgentAppConfig() has no case for e2e in its switch statement, falling through to the default case which grants only issues: read permission. If someone creates the e2e GitHub App via the manifest flow (mint add-role --org), the app will be created with only issues: read, producing a permissions mismatch with what the mint will request at token-creation time.
Remediation: Add an explicit case "e2e" to AgentAppConfig() that sets AppPermissions matching canonicalRolePermissions for the e2e role.
[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() means it can be configured in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls that restrict which roles can actually mint tokens, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role.
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[consumer-completeness] internal/forge/github/types.go:41 — DefaultAgentRoles() does not include e2e. If a user enrolls with --agents e2e and later unenrolls without specifying agents, the cleanup loop will skip the e2e app. This mirrors the existing gap for the fix role.
[consumer-completeness] internal/forge/github/types.go:6 — The AppPermissions struct lacks fields for secrets and organization_administration. Even if a case for e2e is added to AgentAppConfig(), these two permissions cannot be set without extending the struct.
[formatting-consistency] internal/mintcore/github.go:67 — The e2e role permission map uses multi-line formatting while all other roles use single-line. With 11 entries the multi-line format is arguably more readable, but it breaks visual consistency.
[missing-architectural-documentation] internal/config/config.go:94 — The e2e role is added without updating AGENTS.md or other documentation. Since this is a prerequisite PR, documentation can follow in the integration PR.
[naming-alignment] internal/config/config.go:94 — The role is named e2e, which diverges from the existing responsibility-based naming convention (triage, coder, review, etc.). The name accurately describes its test-infrastructure purpose.

Previous run (5)

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, nor does the code enforce the pool-only constraint from issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
Remediation: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

Medium

[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() makes it configurable in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls per mint instance, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role. Issue E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155 explicitly constrains: "Limit minted e2e credentials to the dedicated test org pool."
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[intent-scope-mismatch] internal/forge/github/types.go — The role name e2e does not clearly signal its elevated, test-infrastructure-only scope. See also: [permission-expansion] and [scope-ambiguity] findings above.
[consumer-completeness] internal/config/config.go:105 — DefaultAgentRoles() does not include e2e, so it will not be installed during standard enrollment. This appears intentional for an opt-in pool testing role.
[fail-closed-analysis] internal/mintcore/handler.go:83 — The mint handler's role gating fails closed correctly: checkAllowedRole returns false for all roles when ALLOWED_ROLES and ROLE_APP_IDS are empty. The e2e role requires explicit provisioning in both. These are meaningful mitigating controls.
[architectural-trajectory] internal/forge/github/types.go — The e2e role is the most privileged in the system, exceeding even the fullsend orchestrator role. Architecturally appropriate for its stated purpose but reinforces the importance of the org-restriction constraint from E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155.
[test-coverage] internal/forge/github/types_test.go — TestAgentAppConfig_E2e covers all 10 permission fields and empty events. Test coverage across config, CLI, and mintcore is adequate.

Previous run (6)

Review

Findings

High

[permission-expansion] internal/mintcore/github.go:67 — The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the codebase requests administration or organization_administration at the mintcore level. Combined with secrets: write, a compromised e2e token could reconfigure the org, exfiltrate secrets, or add malicious collaborators.
Remediation: Apply least privilege: (1) Remove organization_administration: write unless tests need org-level admin. (2) Remove or downscope administration: write. (3) Remove members: write unless tests manage org membership. (4) Remove secrets: write unless tests must create/rotate secrets. (5) Document justification for each remaining permission.

Medium

[consumer-completeness] internal/forge/github/types.go:64 — AgentAppConfig() has no case for e2e in its switch statement, falling through to the default case which grants only issues: read permission. If someone creates the e2e GitHub App via the manifest flow (mint add-role --org), the app will be created with only issues: read, producing a permissions mismatch with what the mint will request at token-creation time.
Remediation: Add an explicit case "e2e" to AgentAppConfig() that sets AppPermissions matching canonicalRolePermissions for the e2e role.
[scope-ambiguity] internal/config/config.go:94 — Adding e2e to ValidRoles() means it can be configured in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls that restrict which roles can actually mint tokens, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role.
Remediation: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

Low / Info

[consumer-completeness] internal/forge/github/types.go:41 — DefaultAgentRoles() does not include e2e. If a user enrolls with --agents e2e and later unenrolls without specifying agents, the cleanup loop will skip the e2e app. This mirrors the existing gap for the fix role.
[consumer-completeness] internal/forge/github/types.go:6 — The AppPermissions struct lacks fields for secrets and organization_administration. Even if a case for e2e is added to AgentAppConfig(), these two permissions cannot be set without extending the struct.
[formatting-consistency] internal/mintcore/github.go:67 — The e2e role permission map uses multi-line formatting while all other roles use single-line. With 11 entries the multi-line format is arguably more readable, but it breaks visual consistency.
[missing-architectural-documentation] internal/config/config.go:94 — The e2e role is added without updating AGENTS.md or other documentation. Since this is a prerequisite PR, documentation can follow in the integration PR.
[naming-alignment] internal/config/config.go:94 — The role is named e2e, which diverges from the existing responsibility-based naming convention (triage, coder, review, etc.). The name accurately describes its test-infrastructure purpose.

fullsend-ai-review

See the review comment for full details.

Add AgentAppConfig case and AppPermissions fields so mint add-role --org creates an e2e GitHub App matching canonicalRolePermissions. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

ifireball · 2026-06-18T08:53:51Z

Follow-up on remaining findings (8ee2f1e):

consumer-completeness (AgentAppConfig / AppPermissions) — Fixed in this push. Added explicit e2e case to AgentAppConfig() and organization_administration + secrets fields on AppPermissions so mint add-role --org creates an app whose manifest permissions match canonicalRolePermissions["e2e"].

consumer-completeness (DefaultAgentRoles) — Intentionally omitted. e2e is mint/bootstrap infrastructure for the pool, not a default production agent role (same pattern as fix, which also has its own app but is excluded from DefaultAgentRoles()). Pool orgs install it explicitly via setup script / operator pass.

formatting-consistency — Keeping multi-line for the 11-key e2e map; can collapse to single-line in a follow-up if reviewers prefer strict parity.

missing-architectural-documentation — Deferred to integration PR #2277 / ADR 0046 follow-up; this PR stays minimal (role registration + manifest alignment only).

Prior thread replies cover permission-expansion, scope-ambiguity, and naming-alignment rationale.

fullsend-ai-review · 2026-06-18T08:57:04Z

🤖 Review · ⚠️ Cancelled · Started 8:57 AM UTC · Ended 8:57 AM UTC
Commit: 4e21a60 · View workflow run →

fullsend-ai-review · 2026-06-18T09:02:02Z

🤖 Finished Review · ✅ Success · Started 9:02 AM UTC · Completed 9:14 AM UTC
Commit: e848738 · View workflow run →

fullsend-ai-review

See the review comment for full details.

waynesun09

Review Squad — 6-agent parallel review (Claude, Gemini, Codex)

2 new medium findings posted inline. 1 additional medium finding on a file outside the diff:

[medium] harnessesForRole("e2e") falls through to default, referencing non-existent harness

File: internal/layers/harnesswrappers.go:62

The default case returns []string{role}, so harnessesForRole("e2e") returns ["e2e"] — which looks for harness/e2e.yaml. No such scaffold file exists (only code, fix, prioritize, retro, review, triage). If e2e is ever added to an agent config that triggers harness wrapper installation, it will reference a missing file.

The PR description says "Pool tests are API/mint driven; no webhook events required" — so e2e should return nil like fullsend.

Suggested fix:

case "fullsend", "e2e":
    return nil

Flagged by 1/6 agents — verified against code

2 high findings (permission-expansion on mintcore/github.go:67, scope-ambiguity on config.go:94) already covered by existing review comments — skipped.

ralphbean

One non-blocking note: harnessesForRole("e2e") in internal/layers/harnesswrappers.go:56 falls through to the default case and returns []string{"e2e"}, which would try to reference a harness/e2e.yaml scaffold that doesn't exist. Since e2e is API/mint-driven with no harness, case "fullsend", "e2e": return nil would keep it safe. @waynesun09 flagged this too.

+1 on Wayne's two inline findings (cross-validation test, permission value assertions).

fullsend-ai-review · 2026-06-18T22:19:38Z

🤖 Finished Review · ✅ Success · Started 10:19 PM UTC · Completed 10:32 PM UTC
Commit: 7c5e655 · View workflow run →

fullsend-ai-review

See the review comment for full details.

fullsend-ai-review · 2026-06-18T22:32:09Z

 	"retro":      {"actions": "read", "contents": "read", "pull_requests": "write", "issues": "write", "metadata": "read"},
 	"prioritize": {"contents": "read", "issues": "write", "organization_projects": "write", "metadata": "read"},
 	"fullsend":   {"actions": "write", "actions_variables": "read", "contents": "write", "pull_requests": "write", "workflows": "write", "metadata": "read"},
+	"e2e": {


[high] permission-expansion

The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, nor does the code enforce the pool-only constraint from issue #2155.

Suggested fix: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

fullsend-ai-review · 2026-06-18T22:32:09Z

 // ValidRoles returns the set of recognized agent roles.
 func ValidRoles() []string {
-	return []string{"fullsend", "triage", "coder", "review", "fix", "retro", "prioritize"}
+	return []string{"fullsend", "triage", "coder", "review", "fix", "retro", "prioritize", "e2e"}


[medium] scope-ambiguity

Adding e2e to ValidRoles() makes it configurable in any org's defaults.roles or per-repo roles list via config YAML. The mint handler has ALLOWED_ROLES and ROLE_APP_IDS environment-variable controls per mint instance, but there is no code-level guard at the config validation layer restricting which orgs may reference the e2e role. Issue #2155 explicitly constrains: 'Limit minted e2e credentials to the dedicated test org pool.'

Suggested fix: Ensure the e2e role's GitHub App and PEM are deployed only to mint instances serving the dedicated test org pool, or add explicit org-allowlist checking for the e2e role.

fullsend-ai-review · 2026-06-21T06:30:09Z

🤖 Finished Review · ✅ Success · Started 6:30 AM UTC · Completed 6:46 AM UTC
Commit: db2cd63 · View workflow run →

Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

Assert canonical e2e permissions, ValidRoles/mintcore alignment, and AgentAppConfig parity with mintcore. Tracks consolidation in fullsend-ai#2449. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

e2e is a pool/CI mint role, not an installed agent app. Treat it like fullsend so harness generation does not look for harness/e2e.yaml. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

fullsend-ai-review

See the review comment for full details.

fullsend-ai-review · 2026-06-21T06:45:56Z

 	"retro":      {"actions": "read", "contents": "read", "pull_requests": "write", "issues": "write", "metadata": "read"},
 	"prioritize": {"contents": "read", "issues": "write", "organization_projects": "write", "metadata": "read"},
 	"fullsend":   {"actions": "write", "actions_variables": "read", "contents": "write", "pull_requests": "write", "workflows": "write", "metadata": "read"},
+	"e2e": {


[high] permission-expansion

The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler's ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, and no code-level constraint restricts the role to known test-pool orgs.

Suggested fix: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

fullsend-ai-review · 2026-06-21T06:45:56Z

 // ValidRoles returns the set of recognized agent roles.
 func ValidRoles() []string {
-	return []string{"fullsend", "triage", "coder", "review", "fix", "retro", "prioritize"}
+	return []string{"fullsend", "triage", "coder", "review", "fix", "retro", "prioritize", "e2e"}


[medium] scope-inconsistency

The e2e role is added to ValidRoles() but intentionally excluded from DefaultAgentRoles() and PerRepoDefaultRoles(). ValidRoles() is used for config validation, but e2e is a pool/CI mint role that should never appear in org config files. The comment in harnesswrappers.go states 'The e2e role is a pool/CI mint role and is not installed as an agent app', but ValidRoles() is not documented as including non-agent roles. See also: [scope-ambiguity] finding at this location.

Suggested fix: Add a comment to ValidRoles() clarifying it includes mint-only roles that are not installed as agent apps.

fullsend-ai-review · 2026-06-21T06:49:18Z

🤖 Finished Review · ✅ Success · Started 6:49 AM UTC · Completed 7:04 AM UTC
Commit: 01c65cf · View workflow run →

fullsend-ai-review

See the review comment for full details.

fullsend-ai-review · 2026-06-21T07:04:03Z

 	"retro":      {"actions": "read", "contents": "read", "pull_requests": "write", "issues": "write", "metadata": "read"},
 	"prioritize": {"contents": "read", "issues": "write", "organization_projects": "write", "metadata": "read"},
 	"fullsend":   {"actions": "write", "actions_variables": "read", "contents": "write", "pull_requests": "write", "workflows": "write", "metadata": "read"},
+	"e2e": {


[high] permission-expansion

The new e2e role grants administration: write, organization_administration: write, secrets: write, and members: write — the most privileged GitHub App permissions available. No other role in the canonical permissions map requests organization_administration or secrets at write level. Combined, a minted e2e token could reconfigure repos, manage org settings, overwrite secrets, and modify org membership. The mint handler ALLOWED_ROLES/ROLE_APP_IDS gating and exclusion from DefaultAgentRoles() are meaningful mitigating controls, but neither the code nor an ADR documents why each elevated permission is necessary, and no code-level constraint restricts the role to known test-pool orgs.

Suggested fix: For each permission beyond what the fullsend role already grants, document the specific e2e test operation that requires it (ideally in an ADR or inline comment). In particular: (1) Justify organization_administration: write — if tests only need repo-level admin, remove it. (2) Justify secrets: write — document whether tests must create/rotate secrets. (3) Justify members: write — if tests do not manage org membership, downscope to read. (4) Consider adding a code-level constraint restricting the e2e role to known test-pool orgs.

fullsend-ai-review · 2026-06-21T07:04:03Z

 // ValidRoles returns the set of recognized agent roles.
 func ValidRoles() []string {
-	return []string{"fullsend", "triage", "coder", "review", "fix", "retro", "prioritize"}
+	return []string{"fullsend", "triage", "coder", "review", "fix", "retro", "prioritize", "e2e"}


[low] scope-inconsistency

The e2e role is added to ValidRoles() but intentionally excluded from DefaultAgentRoles() and PerRepoDefaultRoles(). ValidRoles() is used for config validation, but e2e is a pool/CI mint role. ValidRoles() itself lacks a comment noting it includes mint-only roles. The new TestValidRoles_RecognizedByMintcore test provides drift detection.

Suggested fix: Add a comment to ValidRoles() clarifying it includes mint-only roles that are not installed as agent apps.

fullsend-ai-retro · 2026-06-21T07:11:18Z

🤖 Finished Retro · ✅ Success · Started 7:11 AM UTC · Completed 7:17 AM UTC
Commit: 01c65cf · View workflow run →

fullsend-ai-retro · 2026-06-21T07:17:46Z

Retro: PR #2407 — `feat(mint): add e2e agent role for pool testing`

Timeline: Human-authored PR by ifireball (June 18–21). Added e2e role to mintcore with elevated permissions for full admin install/uninstall e2e testing. 9 files changed, all CI green, 100% patch coverage.

Review friction: The review bot ran 7 times, issuing 5 CHANGES_REQUESTED verdicts. The [high] permission-expansion finding was repeated on every review despite the author posting detailed justifications (elevated permissions are intentional — the role runs the full GitHub App lifecycle). Human reviewers (waynesun09, ralphbean) approved on day 1, but the bot kept blocking for 3 more days until the PR was merged with outstanding bot CHANGES_REQUESTED.

What worked well:

The bot caught genuinely useful issues: missing cross-validation tests, missing AppPermissions fields, and the harnessesForRole default case. The author addressed all of these.
Human reviewers (Review Squad + ralphbean) added valuable, non-overlapping findings.
Codecov confirmed full patch coverage.
The sticky comment mechanism successfully accumulated review history.

What didn't work:

The bot could not learn from the author's reply comments. The prior-review fetch (pre-fetch-prior-review.sh) only retrieves the bot's own sticky comment — author replies to inline findings are not passed to the agent on re-reviews. This meant the permission-expansion finding was re-flagged identically 5 times.
The bot issued CHANGES_REQUESTED even after a human reviewer approved, creating merge friction on a deliberate design decision.

Existing issues that cover related patterns (not re-proposed):

#1500 — Review agent should not re-request changes for unchanged findings
#2115 — Use COMMENT verdict for human-authored PRs with only medium/low findings
#1389 — Stabilize review verdicts across re-runs on unchanged code
#2358 — Cap stacked historical iterations in consolidated review comment

One new proposal filed below for the unaddressed gap: author reply comments are invisible to re-reviews.

Proposals filed

Review agent should fetch author reply comments as context for re-reviews (in fullsend-ai/fullsend)

Bring in upstream e2e role (fullsend-ai#2407) and latest main. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

github-actions Bot deployed to site-preview June 18, 2026 07:55 View deployment

test(config): expect e2e in ValidRoles

2509f5e

Update TestValidRoles for the eighth role added for pool e2e minting. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

github-actions Bot deployed to site-preview June 18, 2026 08:07 View deployment

fullsend-ai-review Bot suggested changes Jun 18, 2026

View reviewed changes

Comment thread internal/mintcore/github.go

Comment thread internal/config/config.go

Comment thread internal/mintcore/github.go

Comment thread internal/config/config.go

Comment thread internal/config/config.go

ifireball requested review from ggallen, ralphbean, rh-hemartin and waynesun09 and removed request for ralphbean June 18, 2026 08:30

github-actions Bot deployed to site-preview June 18, 2026 08:55 View deployment

github-actions Bot deployed to site-preview June 18, 2026 08:59 View deployment

fullsend-ai-review Bot suggested changes Jun 18, 2026

View reviewed changes

Comment thread internal/mintcore/github.go

Comment thread internal/config/config.go

waynesun09 reviewed Jun 18, 2026

View reviewed changes

Comment thread internal/forge/github/types_test.go

Comment thread internal/mintcore/github_test.go

ralphbean approved these changes Jun 18, 2026

View reviewed changes

ifireball mentioned this pull request Jun 18, 2026

Consolidate agent role lists and permission definitions #2449

Open

3 tasks

github-actions Bot deployed to site-preview June 18, 2026 21:53 View deployment

ifireball requested a review from waynesun09 June 18, 2026 22:17

fullsend-ai-review Bot suggested changes Jun 18, 2026

View reviewed changes

fullsend-ai-review Bot added component/mint Token mint and cross-boundary credentials component/e2e End-to-end tests security Security threat model and related concerns labels Jun 18, 2026

github-actions Bot deployed to site-preview June 21, 2026 06:28 View deployment

ifireball added this pull request to the merge queue Jun 21, 2026

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks Jun 21, 2026

ifireball and others added 3 commits June 21, 2026 09:45

chore(forge): gofmt AppPermissions struct alignment

8c2ff27

Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

fix(layers): skip harness wrapper for e2e mint role

01c65cf

e2e is a pool/CI mint role, not an installed agent app. Treat it like fullsend so harness generation does not look for harness/e2e.yaml. Signed-off-by: Barak Korren <bkorren@redhat.com> Co-authored-by: Cursor <cursoragent@cursor.com>

fullsend-ai-review Bot suggested changes Jun 21, 2026

View reviewed changes

ifireball force-pushed the feat/e2e-mint-role branch from db2cd63 to 01c65cf Compare June 21, 2026 06:45

github-actions Bot deployed to site-preview June 21, 2026 06:49 View deployment

ifireball added this pull request to the merge queue Jun 21, 2026

fullsend-ai-review Bot suggested changes Jun 21, 2026

View reviewed changes

Merged via the queue into fullsend-ai:main with commit 1e506cd Jun 21, 2026
14 checks passed

ifireball deleted the feat/e2e-mint-role branch June 21, 2026 07:06

fullsend-ai-retro Bot mentioned this pull request Jun 21, 2026

Review agent should fetch author reply comments as context for re-reviews #2463

Closed

qodo-code-review Bot mentioned this pull request Jun 28, 2026

feat(config): add triage-agent to default allowed_remote_resources #2733

Merged

2 tasks

ifireball mentioned this pull request Jul 26, 2026

E2e: secretless GitHub auth via mint OIDC (replace Playwright session + PAT) #2155

Closed

qodo-code-review Bot mentioned this pull request Aug 10, 2026

refactor(runtime): register opencode as a stub runtime #6035

Merged

5 tasks

qodo-code-review Bot mentioned this pull request Sep 2, 2026

feat(config): make the codex runtime selectable #6927

Merged

Uh oh!

Conversation

ifireball commented Jun 18, 2026

Summary

Test plan

Follow-up

Uh oh!

github-actions Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Site preview

Uh oh!

fullsend-ai-review Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

fullsend-ai-review Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Jun 18, 2026

Codecov Report

Uh oh!

fullsend-ai-review Bot commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review

Findings

High

Medium

Low

Review

Findings

High

Medium

Low

Review

Findings

High

Medium

Low / Info

Review

Findings

High

Medium

Low / Info

Review

Findings

High

Medium

Low / Info

Review

Findings

High

Medium

Low / Info

Review

Findings

High

Medium

Low / Info

Review

Findings

High

Medium

Low / Info

Review

Findings

High

Medium

Low / Info

Review

Findings

High

Medium

Low / Info

Uh oh!

fullsend-ai-review Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

github-actions Bot commented Jun 18, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 18, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 18, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 18, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 18, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 18, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 18, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 21, 2026 •

edited

Loading

fullsend-ai-review Bot commented Jun 21, 2026 •

edited

Loading

fullsend-ai-retro Bot commented Jun 21, 2026 •

edited

Loading

Retro: PR #2407 — `feat(mint): add e2e agent role for pool testing`