You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CheckError with 2 codes (RESOLUTION_FAILED, EXTRACTION_FAILED), override readonly cause: unknown per noImplicitOverride.
SDK integration: doPlan/doExecute resolve proposed checks into operations, extract findings from SARIF output artifacts after execution. Re-exports added to @sverka/sdk.
Adds @sverka/checks to turn discovered checks into IR operations and extract SARIF findings. Integrates with @sverka/sdk so auto‑discovery plan() returns check ops and execute() loads findings.
New Features
@sverka/checks: CheckResolver.resolve() → ResolvedCheck (IR OperationSpec + CheckOutput[]); createBuiltinResolver() maps typecheck, lint, test, clippy, vet, fmt-check across Node (bun/npm/yarn/pnpm), Python (ruff/pytest), Rust (cargo), and Go (go).
SDK: plan() resolves proposed checks into ops; execute() extracts findings from the artifact dir; throws CONFIG_NOT_FOUND when no resolvable checks; re‑exports createBuiltinResolver, extractFindings, CheckError, and types from @sverka/checks.
Refactors
Spec 11 simplified: removed provider registry and YAML plugins; single table‑driven resolver; error codes reduced to RESOLUTION_FAILED and EXTRACTION_FAILED.
Packaging: @sverka/checks ships ESM (.mjs/.d.mts); added deps @sverka/core, @sverka/planner, @sverka/findings; @sverka/sdk now depends on @sverka/checks.
Written for commit 7e38213. Summary will update on new commits.
CodeAnt-AI Description
Resolve discovered checks into executable operations and extract SARIF findings
What Changed
Auto-discovered checks now become runnable operations during planning and execution across Node, Python, Rust, and Go projects
Added built-in mappings for typecheck, lint, test, clippy, vet, and format checks, using the detected package manager or tool
Execution now collects findings from declared SARIF output files and reports clear extraction errors for invalid files
Missing output files and unsupported formats are skipped without failing the run
Exposed custom check resolvers, findings extraction, and check errors through the checks package and SDK
Added coverage for resolver mappings, SARIF handling, error behavior, public exports, and plan-mode auto-discovery
Impact
✅ Runnable checks in auto-discovered plans ✅ SARIF findings available after check execution ✅ Clearer errors for invalid check results
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
@codeant-ai ask: Your question here
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
@codeant-ai ask: Can you suggest a safer alternative to storing this secret?
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
@codeant-ai: Your feedback here
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
@codeant-ai: Do not flag unused imports.
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
@codeant-ai: review
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.
Auto reviews are disabled on base/target branches other than the default branch.
Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 8781639d-67d8-4d07-ab86-920159e0b32b
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
🔍 Trigger review
Comment @coderabbitai help to get the list of available commands.
The shipped extractFindings path joins untrusted CheckOutput.path values without constraining them to artifactDir, leaving a concrete path-traversal file-read vulnerability despite the resolved discussion. CI also did not run for this non-trivial SDK/execution change.
The reason will be displayed to describe this comment to others. Learn more.
Summary
This PR introduces the @sverka/checks package with check resolution and findings extraction. The implementation is well-structured with comprehensive test coverage (32 passing tests). However, there are critical security issues that must be addressed before merge.
Critical Issues
Path Traversal Vulnerability (extract.ts): The file path handling in extractFindings allows arbitrary file access outside the artifact directory through path traversal attacks. This enables reading sensitive files anywhere on the filesystem.
Missing Imports (extract.ts): The path traversal fix requires additional imports (resolve, sep) from "node:path" that are currently missing.
Test Coverage
The PR demonstrates solid test coverage including edge cases (missing files, invalid SARIF, multiple package managers). All 32 tests pass and the implementation correctly handles the documented 6 check types across 4 languages.
You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.
• Introduce @sverka/checks to resolve ProposedCheck into executable OperationSpec.
• Add SARIF artifact findings extraction via @sverka/findings.normalizeSarif.
• Wire auto-discovery in SDK plan/execute and re-export checks API from @sverka/sdk.
➖ Adds API surface/complexity beyond the immediate wave scope
➖ May be premature until real custom resolver needs emerge
Recommendation: The PR’s approach (a deterministic built-in (checkId, packageManager) table + a narrow CheckResolver interface) is a good Wave-11 baseline: small surface area, easy to test, and aligns with the planner/findings separation. Consider a follow-up to clarify/adjust precedence semantics (table vs detected order) once multi-ecosystem repos become common, and keep built-in outputs empty until there is a stable cross-tool SARIF convention.
Files changed (20) +1312 / -356
Enhancement (6) +223 / -9
errors.tsIntroduce CheckError with two error codes and override cause+15/-0
Introduce CheckError with two error codes and override cause
• Adds CheckError and CheckErrorCode (RESOLUTION_FAILED, EXTRACTION_FAILED) with 'override readonly cause: unknown' for noImplicitOverride compliance.
extract.tsAdd SARIF-based findings extraction via @sverka/findings+61/-0
Add SARIF-based findings extraction via @sverka/findings
• Implements extractFindings to read declared SARIF outputs from an artifact directory, parse JSON, normalize via normalizeSarif, and wrap failures as CheckError(EXTRACTION_FAILED).
resolver.tsAdd CheckResolver interface and built-in (checkId, PM) table+105/-0
Add CheckResolver interface and built-in (checkId, PM) table
• Defines CheckResolver/ResolvedCheck/CheckOutput and implements createBuiltinResolver using an ordered lookup table mapping checkId and detected package managers to command/args, returning null for unknown mappings.
sverka.tsResolve ProposedChecks into operations and extract SARIF findings+28/-9
Resolve ProposedChecks into operations and extract SARIF findings
• Updates doPlan to resolve proposed checks into OperationSpec[] in auto-discovery mode. Updates doExecute to resolve checks into executable operations when no config exists, and extracts findings from resolved check outputs post-execution.
fixtures.tsAdd temp repo fixture that triggers Node check proposals+24/-0
Add temp repo fixture that triggers Node check proposals
• Adds makeTempGitRepoWithPackageJson to create a minimal bun-managed repo so the planner detects bun and proposes Node checks for auto-discovery tests.
plan-mode.test.tsTest plan-mode auto-discovery now yields check operations+20/-1
Test plan-mode auto-discovery now yields check operations
• Extends plan mode tests to assert that detected package managers lead to ProposedChecks being resolved into non-empty OperationSpec[] with kind=check.
wave-11-checks-plan.mdAdd Wave 11 checks implementation plan and sequencing+419/-0
Add Wave 11 checks implementation plan and sequencing
• Adds an architecture/implementation plan detailing spec amendments, file layout, TDD steps, and SDK integration guidance for checks resolution and findings extraction.
spec.mdRewrite Spec 11 around resolver + SARIF extraction (trimmed scope)+194/-339
Rewrite Spec 11 around resolver + SARIF extraction (trimmed scope)
• Replaces provider/plugin-based design with a minimal CheckResolver + extractFindings contract, reduces error codes, documents the built-in resolution table and updated test plan.
Auto-discovered operations omit image and imageDigest regardless of the selected executor, so
execute({ executor: "docker" }) deterministically fails IR validation before running any check.
The supported Docker option is therefore unusable with the new auto-discovery path.
The resolver creates operations without image metadata, while SDK conversion assigns the globally
selected Docker executor. IR validation explicitly rejects Docker operations without a SHA-256 image
digest, and the SDK converts that validation result into EXECUTION_FAILED.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Make auto-discovered checks valid when the SDK Docker executor is selected.
## Issue Context
Docker IR operations require a pinned SHA-256 image digest, but built-in resolutions are host commands with no image metadata. Either reject/override Docker for host-only auto-checks or add immutable image mappings to resolution.
## Fix Focus Areas
- packages/checks/src/resolver.ts[85-100]
- packages/sdk/src/sverka.ts[94-134]
- packages/sdk/src/convert.ts[59-73]
- packages/ir/src/validate.ts[188-200]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Both SDK paths hard-code createBuiltinResolver(), and SverkaOptions exposes no resolver field,
so consumers cannot use the exported CheckResolver extension point in plan() or execute().
Because built-ins always declare empty outputs, real SDK executions cannot exercise output-bearing
custom checks or SARIF extraction.
+ const resolver = createBuiltinResolver();+ const operations = proposal.checks+ .map((check) => resolver.resolve(check, context))+ .filter((r): r is ResolvedCheck => r !== null)
Evidence
The SDK creates the built-in resolver directly in both planning and execution, while its public
options contain no injection point. The only output-bearing custom resolver is exercised in an
isolated checks-package unit test, and every built-in resolution returns outputs: [].
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Allow callers to provide a `CheckResolver` to both SDK planning and execution, defaulting to the built-in resolver.
## Issue Context
The package publicly exports `CheckResolver`, but the SDK always instantiates its own built-in resolver. Add an optional resolver to SDK options and apply it consistently in both paths, including `createSverka` defaults and per-call overrides.
## Fix Focus Areas
- packages/sdk/src/types.ts[20-34]
- packages/sdk/src/sverka.ts[65-87]
- packages/sdk/src/sverka.ts[94-127]
- packages/sdk/src/__tests__/plan-mode.test.ts[59-71]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
3. Outputs never reach artifacts 🐞 Bug≡ Correctness
Description
The SDK drops ResolvedCheck.outputs when building operations and never maps them to
OperationSpec.artifacts, so executors do not copy declared SARIF files into artifactDir.
extractFindings() then silently skips those missing files, producing false-negative empty
findings.
+ resolvedChecks = proposal.checks+ .map((check) => resolver.resolve(check, context))+ .filter((r): r is ResolvedCheck => r !== null);+ operations = resolvedChecks.map((r) => r.operation);
Evidence
Plan conversion derives runtime artifacts only from OperationSpec.artifacts, and both executors
copy only those declarations. The new custom-resolver example declares out.sarif only in
ResolvedCheck.outputs; extraction subsequently looks for that path under artifactDir and
silently skips it when absent.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Ensure every declared check output is collected into the artifact directory before findings extraction.
## Issue Context
Runtime executors collect only `operation.artifacts`, but `CheckOutput` is currently stored separately and discarded when operations are formed. Merge outputs into artifact declarations with matching destination names, and add an execution-level SARIF integration test.
## Fix Focus Areas
- packages/sdk/src/sverka.ts[114-120]
- packages/sdk/src/sverka.ts[175-184]
- packages/sdk/src/convert.ts[86-88]
- packages/checks/src/__tests__/resolver.test.ts[162-179]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The built-in resolver treats package-manager detection as proof that generic Node scripts exist, so
auto-execution runs typecheck, lint, and test even when package.json declares none. Ordinary
detected projects therefore fail with missing-script errors instead of skipping unsupported checks.
The planner proposes all three Node checks solely from language and package-manager matches, while
package-manager discovery can come from package.json#packageManager without inspecting scripts.
The new SDK fixture demonstrates this exact state: it declares Bun and TypeScript files but no
scripts, yet the resolver maps every proposal to bun run <checkId>.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Prevent built-in checks from resolving commands that the detected project does not actually provide.
## Issue Context
Planner proposals are based only on language and package-manager presence; package-manager detection does not verify `package.json` scripts. Resolution must inspect applicable manifests/tool configuration or return `null` when availability is unconfirmed.
## Fix Focus Areas
- packages/checks/src/resolver.ts[51-77]
- packages/planner/src/planner.ts[268-303]
- packages/planner/src/detect.ts[153-210]
- packages/sdk/src/__tests__/helpers/fixtures.ts[117-135]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
extractFindings() is declared async but uses synchronous existsSync/readFileSync from node:fs
instead of the async fs/promises API, blocking the Node.js event loop while checking and reading
each SARIF file. It is also invoked sequentially in a for-loop over resolvedChecks in doExecute,
compounding the blocking effect when multiple checks declare outputs.
+ if (output.format !== "sarif") continue;+ const filePath = join(artifactDir, output.path);+ if (!existsSync(filePath)) continue;+ const raw = readFileSync(filePath, "utf8");
Evidence
extract.ts imports existsSync/readFileSync from node:fs (synchronous API) and calls them inside an
async function; sverka.ts then awaits extractFindings sequentially per resolved check in a for-loop,
so any blocking read serializes and stalls the event loop during execution. Impact is currently
limited since the built-in resolver always returns outputs: [], but it will affect custom resolvers
and future built-in checks that declare SARIF outputs.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
extractFindings() is marked `async` but performs synchronous, blocking filesystem I/O (`existsSync`, `readFileSync`) internally, which blocks the Node.js event loop during what is otherwise an async execution pipeline.
## Issue Context
The built-in resolver currently always returns `outputs: []`, so this code path is not exercised by default checks today, but it will be exercised by any custom `CheckResolver` that declares SARIF outputs, and by future built-in checks. The function is called in a sequential loop in the SDK's `doExecute`.
## Fix Focus Areas
- packages/checks/src/extract.ts[1-2]
- packages/checks/src/extract.ts[30-33]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Context used
Review mode: 🧠 Deep: This introduces a new checks package plus SDK execution/planning integration across 20 files, with 27 independent edit sites and multiple resolver, artifact-extraction, and execution paths where subtle defects could be missed in one pass.
Tip of the day
💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full
Skipping CodeAnt AI review — this PR changes more than 100 files, which usually means a migration, codemod, or vendored drop. Line-level review on diffs this large produces duplicate findings on the same rewrite pattern and drowns out anything that actually matters.
If you still want a review, comment @codeant-ai : review. For better signal, consider splitting the PR into smaller chunks.
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
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.
codeant-ai
Bot
added
the
size:XXL
![amazon-q-developer[bot]](https://avatars.githubusercontent.com/in/1220912?s=60&v=4){kind=small}
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
User description
Summary
@sverka/checkspackage:CheckResolver.resolve()mapsProposedCheck+ProjectContext→ResolvedCheck(OperationSpec + CheckOutput[]).createBuiltinResolver()covers 6 checkIds (typecheck, lint, test, clippy, vet, fmt-check) across Node/Python/Rust/Go.extractFindings()reads SARIF artifacts via@sverka/findings.normalizeSarif.CheckErrorwith 2 codes (RESOLUTION_FAILED, EXTRACTION_FAILED),override readonly cause: unknownpernoImplicitOverride.doPlan/doExecuteresolve proposed checks into operations, extract findings from SARIF output artifacts after execution. Re-exports added to@sverka/sdk.Test plan
anytypes (impl or tests)Generated with Devin
Summary by cubic
Adds
@sverka/checksto turn discovered checks into IR operations and extract SARIF findings. Integrates with@sverka/sdkso auto‑discoveryplan()returns check ops andexecute()loads findings.New Features
@sverka/checks:CheckResolver.resolve()→ResolvedCheck(IROperationSpec+CheckOutput[]);createBuiltinResolver()mapstypecheck,lint,test,clippy,vet,fmt-checkacross Node (bun/npm/yarn/pnpm), Python (ruff/pytest), Rust (cargo), and Go (go).extractFindings()reads SARIF via@sverka/findings.normalizeSarif; skips missing files; invalid SARIF throwsCheckError("EXTRACTION_FAILED").plan()resolves proposed checks into ops;execute()extracts findings from the artifact dir; throwsCONFIG_NOT_FOUNDwhen no resolvable checks; re‑exportscreateBuiltinResolver,extractFindings,CheckError, and types from@sverka/checks.Refactors
RESOLUTION_FAILEDandEXTRACTION_FAILED.@sverka/checksships ESM (.mjs/.d.mts); added deps@sverka/core,@sverka/planner,@sverka/findings;@sverka/sdknow depends on@sverka/checks.Written for commit 7e38213. Summary will update on new commits.
CodeAnt-AI Description
Resolve discovered checks into executable operations and extract SARIF findings
What Changed
Impact
✅ Runnable checks in auto-discovered plans✅ SARIF findings available after check execution✅ Clearer errors for invalid check results🔄 Retrigger CodeAnt AI Review
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.