Repository navigation
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
gateReview(outcome, { failOn })measures aReviewOutcomefromwaitForReviewagainst aWARNINGorSERIOUSthreshold with the rules ofproofline ci review --fail-on. It returnsREACHED,NOT_REACHED,NOT_COMPLETEorUNAVAILABLE, which correspond to the CLI's exit codes 3, 0, 2 and 4.Who this helps
Node pipelines, deploy scripts and coding agents that already call
waitForReviewand want to stop on findings. Today they have to rebuild the rule from the CLI's Rust source, or spawn the CLI separately and read its exit code. Each part of the rule is easy to get subtly wrong: completeness decides first, missing counts must not read as a pass, an unknown severity reaches every threshold, and CODE findings count only from a complete record of the review's own commits.Decisions
ci_verdict,code_reaches,code_assessmentandSeverity::reached_byin prooflinedev/cli, so a Node job and a CLI job agree on the same review. Measure a review against a severity threshold like ci review --fail-on sdk-python#39 proposes the same helper for Python; the names and the four results match it.open_items.open_findings/serious_findingsalready exclude dismissed findings and unexpired risk acceptances, so nothing is recounted fromassessments[].findings.UNAVAILABLE, because the generated types don't validate them at runtime. An invalidfailOnthrowsTypeError.codeAssessmentintorecordedCode;codeAssessmentkeeps its rule that a CODE result never stands in for an environment result and callsrecordedCode.waitForReviewbehaves exactly as before.merge_gate. The threshold is the caller's, as with--fail-on; the README says so.src/index.ts,tests/gate.test.mjs, README. No generated code, contract or workflow changes.Verification
tests/gate.test.mjsreads each case throughwaitForReviewagainst a local HTTP fixture, so it gates realReviewOutcomes. It ports the CLI'sci_verdicttest table (counts × threshold, incomplete/failed/stopped, a gap deciding before missing counts) and adds: timed-out wait, malformed counts (string, negative, fractional, boolean, missing), CODE findings by severity and lifecycle (code-only and beside environments, unknown severities), partial or foreign-commit CODE records, and invalid thresholds.pnpm generate && git diff --exit-code,pnpm lint,pnpm typecheck,node check-claims.mjs,pnpm build,pnpm test(63 tests, 0 failures), andnpm pack.