Skip to content

Let a CI pass on the final head satisfy a required local unverified check #367

Closed

Description

@datacas

Problem

Split from #290 (merged in #366). Under the verification-plan contract, a required check that stays unverified always stops the cycle from finishing as READY_FOR_MANUAL_MERGE. When the sandbox cannot run a required check locally but CI ran the same check on the same head, the cycle still stops, although the evidence exists.

#290 left this out deliberately: the CI gate only knows check names and states, and nothing maps a check to a command, so a CI_PASSED cannot prove that CI ran the required command.

Scope

Decide and implement when a CI_PASSED on the final head may satisfy a required local unverified check, under both strict and parallel. Conditions agreed in #290 for any substitution:

  • same head SHA;
  • same command as the required check;
  • evidence that CI actually ran it and it succeeded;
  • a result from an authorized workflow the agent cannot forge (for example unchanged from the base branch and a required check);
  • a check that specifically requires the local environment is never substituted;
  • otherwise the check stays unverified.

Open design points:

  • how a local check maps to a CI check name and command (configuration key, or only the configured test command);
  • how the substitution is recorded in the per-check results without raising the agent's conclusion;
  • how it interacts with the end-of-cycle gate and the verification-only resume planned in Execute and replan native cycles under mandatory policy gates #329.

Acceptance criteria

  • A required unverified check is satisfied by CI only when every condition above holds, and the result records that CI satisfied it, with the CI check, the command and the head SHA.
  • A failing, missing, late or different-SHA CI result never satisfies a check.
  • Behaviour is covered by tests under strict and parallel.
  • The page in docs/ that owns verification is updated in the same pull request.

Related

#290, #329, #288.

Activity

  1. added
    P2Measurement and conditional work
    on Oct 30, 2026
  2. added a commit that references this issue on Oct 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Measurement and conditional work

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions