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
Adds @sverka/sdk as a single entry point to define, plan, and run workflows end-to-end. Includes config discovery, deterministic plan generation, host-first execution (Docker opt-in), baseline filtering, policy evaluation, and a typed SdkError. Findings are stubbed to [] until check providers land.
New Features
High-level API: createSverka(), plan(), execute(), defineWorkflow(), task(); config via findConfig() and loadWorkflow() (safe dynamic import with project-root guard).
Plan mode: side-effect-free plan runtime; convertToPlan() sets metadata (apiVersion, sverkaVersion from package.json, generatedBy, canonical sourceContextHash); deterministic computePlanId; zero-config plan() returns a proposal when no config is found.
Execution + Policy: host executor by default (Docker opt-in); returns status, outcomes, duration, verdict; baseline filtering via loadBaseline/filterOnlyNew; evaluates policy; findings stay empty for now.
Reliability: clamp retries to maxAttempts >= 1; 128-bit cache key; validate configPath is inside the project root; clean temp artifact/cache dirs with top-level try/finally; pass baseline fingerprints when baselinePath is set; derive Docker runAs from current uid/gid; forward PATH to the host executor.
Code health: reduced defaulting complexity (extracted resolveDefaults, explicit field mapping).
Build: ESM outputs (index.mjs, index.d.mts); derive sverkaVersion at runtime from package.json.
Written for commit c47f227. Summary will update on new commits.
CodeAnt-AI Description
Add a single SDK entry point for defining, planning, and running workflows
What Changed
Added @sverka/sdk as a unified import for workflow building, project discovery, planning, execution, findings, and policy evaluation
Added plan() and execute() APIs, plus createSverka() for reusable defaults; planning records workflows without running commands
Added sverka.config.ts and .js discovery, workflow loading, validation, and clear typed errors for missing, invalid, or unloadable configuration
Added host execution by default with optional Docker execution, operation outcomes, execution status, policy verdicts, and baseline filtering support
Added deterministic plan generation with resource, timeout, retry, network, artifact, executor, and dependency defaults
Added workflow helpers, core package re-exports, and coverage for configuration, planning, execution, conversion, defaults, and error handling
Impact
✅ One import for end-to-end workflow use ✅ No command execution during planning ✅ Clear configuration failure errors
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.
Added a TypeScript SDK for discovering workflows, planning operations, and executing them on host or Docker runtimes.
Added public APIs for workflow definition, task naming, configuration loading, plan generation, and execution.
Added structured SDK errors with categorized configuration and execution codes.
Added execution results with status, operation outcomes, findings, policy verdicts, and duration.
Bug Fixes
Source context validation now accepts empty string values.
Documentation
Added comprehensive SDK architecture and implementation planning documentation.
Walkthrough
The PR adds the Wave 09 TypeScript SDK. It supports workflow discovery, plan mode, host or Docker execution, IR plan conversion, policy and baseline processing, structured results, typed errors, public exports, and comprehensive tests.
Changes
SDK facade implementation
Layer / File(s)
Summary
SDK contracts and workspace integration engdocs/architecture/wave-09-sdk-plan.md, specs/09-sdk/spec.md, packages/sdk/package.json, packages/sdk/project.json, packages/ir/src/validate.ts
Defines the plan/execute SDK contract, workspace integration, runtime dependencies, conversion defaults, and relaxed empty source-context hash validation.
Public API and configuration loading packages/sdk/src/types.ts, packages/sdk/src/errors.ts, packages/sdk/src/index.ts, packages/sdk/src/config.ts, packages/sdk/src/__tests__/*
Adds SDK types, SdkError, public re-exports, task, defineWorkflow, configuration discovery, dynamic loading, shape validation, and related tests.
Plan runtime and IR conversion packages/sdk/src/internal/plan-runtime.ts, packages/sdk/src/convert.ts, packages/sdk/src/__tests__/convert.test.ts, packages/sdk/src/__tests__/plan-mode.test.ts
Records operations in plan mode and converts them into validated IR plans with execution defaults, dependencies, hashes, artifacts, caches, and executor metadata.
Execution orchestration and result processing packages/sdk/src/sverka.ts, packages/sdk/src/__tests__/execute-mode.test.ts
Adds configured and top-level planning and execution, executor selection, scheduler integration, temporary resource management, baseline filtering, policy evaluation, verdicts, and structured outcomes.
sequenceDiagram
participant Sverka
participant ConfigLoader
participant PlanRuntime
participant PlanConverter
participant Scheduler
participant PolicyEvaluator
Sverka->>ConfigLoader: discover and load workflow
Sverka->>PlanRuntime: evaluate workflow operations
Sverka->>PlanConverter: convert operations into validated plan
Sverka->>Scheduler: execute plan with selected executor
Scheduler-->>Sverka: return status and outcomes
Sverka->>PolicyEvaluator: evaluate findings and baseline result
PolicyEvaluator-->>Sverka: return policy result and verdict
Loading
Possibly related PRs
sverka-dev/sverka#1: Provides the core workflow, operation, runtime, and planning APIs used by the SDK.
sverka-dev/sverka#2: Provides the IR plan schema, validation, deterministic IDs, and source-context hash behavior.
sverka-dev/sverka#3: Provides the scheduler, executor contracts, and execution results used by SDK execution.
🚥 Pre-merge checks | ✅ 4 | ❌ 1
❌ Failed checks (1 warning)
Check name
Status
Explanation
Resolution
Docstring Coverage
⚠️ Warning
Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.
Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name
Status
Explanation
Linked Issues check
✅ Passed
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
✅ Passed
Check skipped because no linked issues were found for this pull request.
Title check
✅ Passed
The title identifies the Wave 9 SDK change and is concise enough for the main implementation objective.
Description check
✅ Passed
The description directly explains the SDK APIs, configuration, planning, execution, testing, and related implementation changes.
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
Create stacked PR
Commit on current branch
🧪 Generate unit tests (beta)
Create PR with unit tests
Commit unit tests in branch wave-9-sdk
Comment @coderabbitai help to get the list of available commands.
The reason will be displayed to describe this comment to others. Learn more.
This PR implements the SDK layer with comprehensive re-exports, high-level APIs, and config discovery. The implementation is generally well-structured, but several critical issues must be addressed before merge:
Security: Path traversal vulnerability in config loading without path validation
Security: Truncated hash in cache key generation increases collision risk
Logic: Missing cleanup of temporary directories in failure scenarios
Logic: Unsafe type assertion bypasses TypeScript's type safety
Strengths:
Clean API design with createSverka factory pattern
Comprehensive re-exports from core packages
Good separation of plan vs execute modes
Extensive test coverage (60 tests passing)
All findings require fixes as they either create security vulnerabilities or logic errors that could cause incorrect behavior or resource leaks.
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.
This non-trivial public SDK/runtime change has no CI verification. The SDK tests dynamically import @sverka/sdk, whose package exports point to dist/index.mjs, but the test target does not build the package and no dist output is present, so clean test execution is uncertain.
• Introduce @sverka/sdk composition root with re-exports and plan/execute APIs.
• Add sverka.config.{ts,js} discovery/loading and workflow → IR Plan conversion.
• Add vitest suite covering public API, config errors, plan mode, and execution mode.
The following are alternative approaches to this PR:
1. Make executor injection first-class
➕ Allows custom executors and easier unit testing without running commands
➕ Avoids hard-coding allowlist and Docker defaults in the SDK
➖ Bigger surface area for v1; more docs and validation needed
➖ Still need sensible defaults for typical users
2. Strict Workflow-only config (no bare Operation)
➕ Simplifies config validation and normalization logic
➕ Avoids ambiguity in config authoring
➖ Less ergonomic for simple pipelines
➖ Breaks the goal of allowing minimal configs (pipeline(...) directly)
3. Plan/execute return the IR Plan (or persist it)
➕ Improves debuggability and allows external tooling to reuse the plan
➕ Enables caching/replay/resume workflows later
➖ Exposes more internal IR details to end users
➖ Adds complexity to result types and backwards-compat constraints
Recommendation: The PR’s approach is appropriate for an initial SDK: keep the API small, make the SDK the single composition root, and wire execution end-to-end even with stubbed findings. Consider adding optional executor injection later (non-breaking) once real check providers land and testing needs expand.
Files changed (23) +2230 / -328
Enhancement (7) +743 / -0
config.tsImplement config discovery and dynamic workflow loading+99/-0
Implement config discovery and dynamic workflow loading
• Implements findConfig() searching for sverka.config.ts/js up to 5 parents and loadWorkflow() using dynamic import with shape validation and SdkError wrapping.
convert.tsImplement OperationSpec[] → IR Plan conversion with defaults+150/-0
Implement OperationSpec[] → IR Plan conversion with defaults
• Adds convertToPlan() to map core OperationSpec into IR Plan/PlanOperation, computing plan id, sourceContextHash, cache keys, and filling required defaults for execution.
plan-runtime.tsAdd plan-mode Runtime that records operations+39/-0
Add plan-mode Runtime that records operations
• Introduces PlanRuntime implementing Runtime to evaluate workflow graphs without side effects by recording OperationSpec entries and returning planned outcomes.
sverka.tsImplement createSverka(), plan(), and execute() orchestration+261/-0
Implement createSverka(), plan(), and execute() orchestration
• Wires planner discovery, config resolution, workflow evaluation, plan conversion, optional plan validation, and runtime execution via Scheduler with HostExecutor/DockerExecutor; stubs findings and applies baseline+policy evaluation.
• Validates execute() returns status/verdict/outcomes, stubs findings as empty, and that createSverka().execute matches the top-level execute() behavior.
wave-09-sdk-plan.mdAdd Wave 09 SDK implementation plan document+312/-0
Add Wave 09 SDK implementation plan document
• Introduces a detailed architecture/TDD plan describing the SDK as the composition root, config discovery/loading, workflow evaluation, plan conversion, execute pipeline, and error handling expectations.
spec.mdUpdate Wave 09 spec to match implemented SDK API and behavior+277/-322
Update Wave 09 spec to match implemented SDK API and behavior
• Refines goals/non-goals (drops compile mode for now), documents execute/plan flows, config discovery rules, conversion defaults, result types, and error semantics aligned with the implementation.
package.jsonFinalize SDK package entrypoints and workspace deps+15/-5
Finalize SDK package entrypoints and workspace deps
• Switches dist outputs to ESM-friendly .mjs and .d.mts and declares workspace dependencies on the Sverka internal packages required by the SDK composition root.
1. False conditions still execute 🐞 Bug≡ Correctness
Description
evaluateWorkflow() forwards core's full ordered operation list, including condition-skipped
operations, into a scheduler that never evaluates condition. Commands wrapped in when(...) can
therefore execute even when their condition is false.
+ const runtime = new PlanRuntime();+ const result = await wf.plan(runtime);+ return result.operations;
Evidence
The SDK returns result.operations; core explicitly skips runtime.evaluate() for false conditions
but then returns the complete ordered list, while the scheduler initializes and schedules every
plan operation without reading condition.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The SDK sends condition-skipped operations to the scheduler, so `when(...)` does not prevent execution.
## Issue Context
Core's planning result replaces the runtime's recorded operations with the complete ordered graph. Preserve the planning-time skip decision in a form the scheduler honors; ensure dependencies of skipped operations continue with the scheduler's existing `skipped` semantics.
## Fix Focus Areas
- packages/sdk/src/sverka.ts[219-225]
- packages/sdk/src/internal/plan-runtime.ts[14-37]
- packages/runtime/src/scheduler.ts[115-169]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The SDK’s default HostExecutor is created with an empty envAllowlist and no config.env, so
buildEnv() constructs a child environment that omits PATH from process.env. Because Node’s spawn()
uses options.env when provided and Unix PATH lookup falls back only to /usr/bin:/bin when PATH is
missing, user-local commands (e.g., bun, npm-installed binaries, project-local node_modules/.bin
tools) can fail to spawn with ENOENT.
In packages/sdk/src/sverka.ts, createExecutor() constructs a HostExecutor with envAllowlist: [], and
in packages/runtime-host/src/host-executor.ts, buildEnv() starts from an empty environment and only
copies host variables whose keys appear in config.envAllowlist, so PATH is dropped by default. This
is corroborated by the project’s own fixtures/tests that explicitly include PATH, and by Node’s
documented spawn() semantics: when an explicit options.env is passed without PATH, Unix command
resolution uses only a minimal fallback (/usr/bin:/bin) rather than the user’s actual PATH, which
would prevent resolving tools referenced by the SDK’s own configuration examples.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The SDK’s default `HostExecutor` is constructed with `envAllowlist: []`, so `HostExecutor.buildEnv()` never forwards `PATH` from `process.env` into the environment passed to `child_process.spawn()`. When `spawn()` is invoked with an explicit `options.env` that lacks `PATH`, Unix command resolution falls back only to `/usr/bin:/bin`, causing commands that rely on user/project PATH entries (e.g., `bun`, version-manager-installed tools, npm-installed binaries, `node_modules/.bin`) to fail with `ENOENT`.
## Issue Context
`createExecutor()` in `packages/sdk/src/sverka.ts` builds the default `HostExecutor` config used by `execute()`/`sverka.execute()`. `HostExecutor.buildEnv()` in `packages/runtime-host/src/host-executor.ts` constructs a fresh child environment and only copies keys explicitly listed in `config.envAllowlist`, so an empty allowlist drops all host variables including `PATH`. Environment filtering should remain, but the default host execution path should forward at least the minimum variables required for normal command execution (at least `PATH`), and consider whether platform-specific essentials such as `HOME`, `SystemRoot`, or `PATHEXT` are also needed.
## Fix Focus Areas
- packages/sdk/src/sverka.ts[245-261]
- packages/runtime-host/src/host-executor.ts[165-189]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The newly selected DockerExecutor constructs docker run --timeout, but docker run has no
--timeout option. Every Docker-mode operation that reaches execution is rejected before its
container starts.
+ if (type === "docker") {+ return new DockerExecutor({+ runAs: "1000:1000",+ cacheDir,+ });
Evidence
The SDK activates DockerExecutor; that executor always inserts --timeout in the docker run
arguments. Docker's run reference lists --stop-timeout, not --timeout, and the repository's
real-Docker tests are skipped by default.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
SDK Docker execution activates an executor that passes unsupported `--timeout` arguments to `docker run`.
## Issue Context
The executor already enforces wall-clock timeout by terminating the Docker CLI process. Remove the invalid run argument (or use a supported option only for its documented stop-timeout semantics) and add a real-Docker execution test.
## Fix Focus Areas
- packages/sdk/src/sverka.ts[245-254]
- packages/runtime-docker/src/docker-executor.ts[42-58]
- packages/runtime-docker/src/__tests__/integration.test.ts[5-24]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
4. Temp artifact/cache dirs never cleaned up✓ Resolved🐞 Bug☼ Reliability
Description
doExecute() creates two unique temporary directories (sverka-artifacts-* and sverka-cache-*) via
mkdtempSync on every execute() call, but cleanup only disposes the scheduler/executors and never
removes these directories. As a result, both successful and failed SDK runs leak artifact output and
cache data on disk, accumulating indefinitely across repeated CI/local runs.
In packages/sdk/src/sverka.ts, artifactDir and cacheDir are created using mkdtempSync and passed
into the Scheduler, but the surrounding cleanup logic only calls scheduler.dispose() in a finally
block. The Scheduler’s dispose implementation in packages/runtime/src/scheduler.ts only forwards
disposal to Executor.dispose() implementations, and the referenced host/Docker executors do not
delete the provided filesystem paths, while sverka.ts contains no rm/rmSync (or equivalent) calls
for artifactDir or cacheDir, demonstrating that the temporary directories are never removed.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`doExecute()` allocates two per-execution `mkdtempSync` directories (artifacts and cache) but never deletes them; current cleanup only calls `scheduler.dispose()`, which disposes executors but does not remove the directories, so each SDK `execute()` leaks temp data on disk.
## Issue Context
The SDK creates unique artifact and cache directories for each run and passes them into the scheduler/executors; however, filesystem cleanup for these temp dirs is missing, so both successful and failed runs accumulate temporary command output and cache data indefinitely. Add explicit cleanup in a `finally` block that also covers failures during scheduler/executor construction and execution, and consider/define an artifact retention policy so returned artifact paths remain usable when needed while transient cache data and non-retained artifacts are removed.
## Fix Focus Areas
- packages/sdk/src/sverka.ts[137-163]
- packages/sdk/src/sverka.ts[188-195]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
5. generatedBy hardcoded to manual 🐞 Bug≡ Correctness
Description
convertToPlan() always sets metadata.generatedBy to "manual" regardless of whether a user config was
loaded or the plan came from auto-discovery, but the spec requires generatedBy to be "planner" when
no config exists. This mislabels the provenance of plans built without a user config, which is
meaningful data since PlanMetadata.generatedBy explicitly distinguishes "planner" | "manual" |
"compiler".
convert.ts hardcodes generatedBy: "manual" with no parameterization by convert options. The spec
(specs/09-sdk/spec.md) explicitly documents metadata.generatedBy as config ? "manual" : "planner",
and packages/ir/src/plan.ts's PlanMetadata type allows a distinct "planner" value, confirming the
field is meant to distinguish the two cases.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`convertToPlan()` always sets `metadata.generatedBy` to `"manual"`, but the spec requires `"planner"` when the plan was produced without a user config (auto-discovery path). This is a metadata correctness bug that mislabels plan provenance.
## Issue Context
`ConvertOptions` in `packages/sdk/src/convert.ts` has no field indicating whether a user config was resolved; `doExecute()` in `packages/sdk/src/sverka.ts` knows this (via `configPath !== null`) but doesn't pass it through.
## Fix Focus Areas
- packages/sdk/src/convert.ts[20-27]
- packages/sdk/src/convert.ts[40-43]
- packages/sdk/src/sverka.ts[96-124]
Add a `generatedBy` (or `hasConfig`) field to `ConvertOptions`, thread it from `doExecute()` based on whether `configPath` resolved, and use it instead of the hardcoded literal.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
packages/sdk/package.json's new dependencies block omits @sverka/planner even though sverka.ts and
types.ts import createPlanner and ProjectContext/PlanProposal from @sverka/planner at runtime;
bun.lock's sdk entry correctly lists @sverka/planner, so the package.json and lockfile are
inconsistent, which risks install/publish failures or accidental undeclared-dependency resolution
outside the monorepo workspace.
The new dependencies object in packages/sdk/package.json lists core, ir, runtime, runtime-host,
runtime-docker, findings, policy, but omits planner, while packages/sdk/src/sverka.ts imports
createPlanner and types from @sverka/planner, and bun.lock's packages/sdk entry (lines 173-182)
does include @sverka/planner: workspace:*. This mismatch means the declared package manifest
under-declares a real runtime dependency.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`packages/sdk/package.json`'s dependencies list is missing `@sverka/planner`, even though the SDK imports `createPlanner` and planner types at runtime, and `bun.lock` already reflects `@sverka/planner` as a dependency for the sdk workspace package.
## Issue Context
This inconsistency between the manifest and the lockfile/actual usage can cause resolution issues if the lockfile is regenerated or if the package is published/installed outside the current workspace state.
## Fix Focus Areas
- packages/sdk/package.json[21-30]
Add `"@sverka/planner": "workspace:*"` to the `dependencies` object, matching bun.lock and the actual `@sverka/planner` imports in `src/sverka.ts` and `src/types.ts`.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Review mode: 🧠 Deep: This is a new SDK composition root with substantial execution, config-loading, plan-conversion, and public API logic across many independent edit sites, making multiple subtle defects plausible.
Tip of the day
💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full
The reason will be displayed to describe this comment to others. Learn more.
All reported issues were addressed across 23 files
Tip: instead of fixing issues one by one fix them all with cubic Tip: cubic can generate docs of your entire codebase and keep them up to date. Try it here.
Use a dedicated valueOrDefault helper so resolveDefaults no longer contains multiple ?? operators.
Co-Authored-By: Petr Plenkov <petr.plenkov@gmail.com>
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}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
User description
Summary
Test plan
Stacked on #10
Generated with Devin
Summary by cubic
Adds
@sverka/sdkas a single entry point to define, plan, and run workflows end-to-end. Includes config discovery, deterministic plan generation, host-first execution (Docker opt-in), baseline filtering, policy evaluation, and a typedSdkError. Findings are stubbed to[]until check providers land.New Features
createSverka(),plan(),execute(),defineWorkflow(),task(); config viafindConfig()andloadWorkflow()(safe dynamic import with project-root guard).convertToPlan()sets metadata (apiVersion,sverkaVersionfrom package.json,generatedBy, canonicalsourceContextHash); deterministiccomputePlanId; zero-configplan()returns a proposal when no config is found.loadBaseline/filterOnlyNew; evaluates policy; findings stay empty for now.validatePlan,computePlanId), planner, runtime (Scheduler,@sverka/runtime-host,@sverka/runtime-docker), findings, policy.Bug Fixes and Refactors
sourceContextHash; canonical stringify with sorted paths (explicit comparator).maxAttempts >= 1; 128-bit cache key; validateconfigPathis inside the project root; clean temp artifact/cache dirs with top-leveltry/finally; pass baseline fingerprints whenbaselinePathis set; derive DockerrunAsfrom current uid/gid; forwardPATHto the host executor.resolveDefaults, explicit field mapping).index.mjs,index.d.mts); derivesverkaVersionat runtime from package.json.Written for commit c47f227. Summary will update on new commits.
CodeAnt-AI Description
Add a single SDK entry point for defining, planning, and running workflows
What Changed
@sverka/sdkas a unified import for workflow building, project discovery, planning, execution, findings, and policy evaluationplan()andexecute()APIs, pluscreateSverka()for reusable defaults; planning records workflows without running commandssverka.config.tsand.jsdiscovery, workflow loading, validation, and clear typed errors for missing, invalid, or unloadable configurationImpact
✅ One import for end-to-end workflow use✅ No command execution during planning✅ Clear configuration failure errors🔄 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.