E2E Recommendation Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required E2E

• None. No additional E2E is recommended. The changes are CI workflow/composite-action refactoring plus workflow contract test updates, with no runtime/user-flow code touched. Existing CI and the updated workflow contract tests should validate the refactor; running sandbox or scenario E2E would not add meaningful signal for this PR.

Optional E2E

• None.

New E2E recommendations

• None.

E2E Scenario Advisor

Base: origin/main
Head: HEAD
Confidence: high

Required scenario E2E

• None. No scenario E2E jobs are recommended because this PR changes general CI composite actions, main/PR CI workflows, and their workflow contract test only. It does not change test/e2e-scenario runtime, scenario metadata, expected-state contracts, suite definitions/scripts, onboarding helpers, or the e2e-scenarios workflows.

Optional scenario E2E

• None.

Relevant changed files

• None.

🛠️ Needs attention

• PR-required gates moved into PR-modifiable local actions (.github/workflows/pr.yaml:84): The pull_request workflow now delegates required static/build/coverage gates to repository-local composite actions after checkout. In pull_request runs, those local action definitions are resolved from the checked-out PR/merge workspace, so a future PR can modify .github/actions/ci-* to skip checks or run different commands while the base workflow still invokes the same job names. This weakens the trusted-code boundary compared with the previous inline gate commands in the workflow.
  • Recommendation: Keep PR-required gate commands inline in .github/workflows/pr.yaml, execute the composite actions from a trusted base-ref checkout, or add a trusted fail-closed guard that blocks changes to those local actions while independently running equivalent enforcement.
  • Evidence: The PR changes PR jobs such as static-checks to `uses: ./.github/actions/ci-static-checks`; the diff shows the previous inline commands were removed from .github/workflows/pr.yaml and moved into .github/actions/ci-*/action.yaml.

🔎 Worth checking

• Source-of-truth review needed: PR CI gate implementation source of truth: The advisor marked localized patch analysis as needs_followup.
  • Recommendation: Identify the invalid state, source boundary, source-fix constraint, regression test, and removal condition before merging the localized behavior.
  • Evidence: .github/workflows/pr.yaml now calls `uses: ./.github/actions/ci-*` for required gates after checkout.
• Composite action inputs are interpolated into shell commands without validation (.github/actions/ci-cli-coverage-shard/action.yaml:41): The CLI coverage shard and merge actions interpolate `inputs.shard` and `inputs.shard-count` directly into bash command arguments and file paths. Current callers provide controlled matrix/default numeric values, but if these actions are reused with untrusted `with:` values, malformed inputs could affect shell command behavior or paths.
  • Recommendation: Validate shard inputs as positive integers at the start of each composite action, pass them through environment variables, and quote all uses. Add a contract test that non-numeric shard inputs are rejected before running vitest or find.
  • Evidence: `--shard=${{ inputs.shard }}/${{ inputs.shard-count }}` and `.vitest-reports/blob-${{ inputs.shard }}-${{ inputs.shard-count }}.json` are constructed directly from composite action inputs.
• Hadolint installer verifies with a checksum fetched from the same origin (.github/actions/ci-static-checks/action.yaml:18): The hadolint installer downloads the binary and the .sha256 file from the same GitHub release origin. This is fixed-version and pre-existing from the renamed action, but the checksum is not independently pinned in the repository, so a compromised release origin could provide a matching malicious binary and checksum.
  • Recommendation: Prefer pinning the expected SHA-256 value in the workflow/action or using a trusted package/action with pinned digest. If keeping the current pattern, document the accepted trust model.
  • Evidence: `curl -fsSL -o /usr/local/bin/hadolint "$HADOLINT_URL"` is followed by `EXPECTED=$(curl -fsSL "${HADOLINT_URL}.sha256" | awk '{print $1}')`.
• Workflow contract tests do not cover the trusted-code boundary (test/pr-workflow-contract.test.ts:80): The updated contract tests assert that PR and main workflows reuse the new local actions and that the actions contain expected commands. They do not assert that PR-required enforcement remains outside PR-modifiable files, so the tests can pass while the required gate implementation is mutable by the PR under test.
  • Recommendation: Add a policy/contract test or trusted workflow guard that fails when pull_request-required gates depend on local composite actions from the PR checkout, or that blocks PR changes to those action definitions unless equivalent inline trusted checks remain.
  • Evidence: The test explicitly expects PR jobs to contain `./.github/actions/ci-*` action paths, but no negative assertion prevents PR-required gates from depending on PR-modifiable local action YAML.

🌱 Nice ideas

• None.

• **Runtime validation** — PR code-path gates fail or stay trusted when `.github/actions/ci-*` is modified by a pull request. The deterministic YAML contract tests are broadly appropriate for this CI refactor, but security-sensitive workflow enforcement needs negative coverage for trusted-code boundaries and the reusable composite actions should validate shell-interpolated inputs.
• **Runtime validation** — CLI coverage composite actions reject non-numeric shard and shard-count inputs before shell interpolation. The deterministic YAML contract tests are broadly appropriate for this CI refactor, but security-sensitive workflow enforcement needs negative coverage for trusted-code boundaries and the reusable composite actions should validate shell-interpolated inputs.
• **Runtime validation** — PR aggregate checks still fail when a required shared action job is skipped or cancelled. The deterministic YAML contract tests are broadly appropriate for this CI refactor, but security-sensitive workflow enforcement needs negative coverage for trusted-code boundaries and the reusable composite actions should validate shell-interpolated inputs.
• **Workflow contract tests do not cover the trusted-code boundary** — Add a policy/contract test or trusted workflow guard that fails when pull_request-required gates depend on local composite actions from the PR checkout, or that blocks PR changes to those action definitions unless equivalent inline trusted checks remain.
• **Acceptance clause:** Refs ci: safely split slow CLI coverage suites #4892 and follows ci(pr): shard CLI coverage gate #4977. — add test evidence or identify existing coverage. The deterministic context did not include linked issue bodies or comments, so no literal issue clauses from ci: safely split slow CLI coverage suites #4892 or ci(pr): shard CLI coverage gate #4977 were available to verify.
• **Acceptance clause:** Update the PR workflow to call the shared actions while preserving the existing PR job names and aggregate `checks` behavior. — add test evidence or identify existing coverage. The PR workflow keeps the existing job names and aggregate checks job, and the contract test asserts those relationships. However, moving PR gate logic into local composite actions does not preserve the prior trusted-code boundary for PR enforcement.
• **PR CI gate implementation source of truth** — No regression test proves that PR-required gates remain non-bypassable when .github/actions/ci-* is modified by a PR.. .github/workflows/pr.yaml now calls `uses: ./.github/actions/ci-*` for required gates after checkout.