Release candidate: E2E sanity, dependency audit and go/no-go

A release candidate needs a second look from several angles at once, and someone has to write down the call. Release Readiness gives each angle to a different agent and ends with an explicit go or no-go.

Which agents run

The steps run one after another, despite the workflow's parallel label. The E2E Tester writes end-to-end scenarios for the user-visible flows and names the gaps; it doesn't drive a browser. The Dependency Auditor reads your direct dependencies from the manifest, not lockfiles, and flags vulnerable, risky-license or abandoned packages. The Architect reads all four and makes the call.

What runs and what blocks

The code pass writes the release note the task asks for. Your project's test command then runs in an offline sandbox, which is the only code that executes. The findings review reads the diff with all five steps as context, so dependency and security problems become findings with a severity.

• Open high or critical findings block the pull request until triaged.
• Failing tests block, and only a result for the current version counts.
• A person other than the session's starter approves.

Require it from CI

On the release pull request, ask the gate to confirm the change came from a completed Release Readiness session and to block on medium findings too:

curl -sf -X POST "https://console.aicodeops.dev/api/release/check" \
  -H "Authorization: Bearer $WORKSPACE_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"pullRequestURL\":\"$PR_URL\",\"requiredWorkflows\":[\"release-readiness\"],\"blockingSeverity\":\"medium\"}" \
  | jq -e '.allowed == true'

A required workflow with no completed run, or with a failed one, denies the release. See quality gates for how the per-run checks and the CI check fit together.

Pair this with the coverage floor template if the candidate also needs a minimum coverage. Problems that turn up between releases are cheaper to catch with a weekly codebase inspection.