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
Reuses existing discovery + plan synthesis logic unchanged
Fixed cross-cutting bug: PipelineDefinition.inputs changed from Input[] to Record<string, Input> to preserve input names through synthesis. Updated core, IR validation, and test fixtures.
Produces a deterministic RunPlan from a selected entry in @sverka/planner, with fast-fail graph validation and secrets-safe plan IDs. Old: no binder. New: bindRunPlan computes reachable steps, binds inputs, and omits secret values from the plan and its ID.
Validates runtime graph shape up front, then runs @sverka/corevalidateGraph on the selected pipeline; malformed graphs, cycles, and unknown dependencies[].producer raise PlannerError("INVALID_GRAPH").
Finds the entry across all pipelines; unknown entry/root raise ENTRY_NOT_FOUND/ROOT_NOT_FOUND.
Reachability follows only dependencies[].producer backward from roots and excludes unrelated steps.
Inputs are Record<string, Input>; defaults merge with user overrides with strict type checks. Type mismatches raise INVALID_INPUT; missing required values raise MISSING_INPUT. Secret inputs are omitted from RunPlan.inputs and excluded from @sverka/ircomputeRunPlanId.
Public API: Planner.bindRunPlan(...); @sverka/planner exports bindRunPlan, computeReachableSteps, and PlannerError (adds INVALID_INPUT). RunPlan includes graphId, a content-addressed id, and createdAt. @sverka/planner now depends on @sverka/core and @sverka/ir.
@sverka/core re-exports graph types. @sverka/ir validator enforces inputs object shape and validates type, required, secret, description, and default type consistency.
Migration
Replace PipelineDefinition.inputs: Input[] with Record<string, Input> and update array iterations to Object.entries/Object.keys.
Written for commit c06b5e0. Summary will update on new commits.
CodeAnt-AI Description
Bind definition graphs into executable run plans
What Changed
Added Run Plan creation from a selected pipeline entry, including reachable steps, bound inputs, source graph identity, deterministic plan identity, and creation time
Includes connected dependencies and dependents while excluding unrelated steps
Applies default inputs, allows user values to override them, and reports missing required inputs with clear planner error codes
Exposes Run Plan binding and reachability utilities through the planner API, while preserving existing discovery and planning
Pipeline inputs are now named records, preserving input names through graph synthesis and validation
Impact
✅ Executable plans from selected pipeline entries ✅ Unrelated steps excluded from runs ✅ Clear errors for invalid entries and missing inputs
💡 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:
@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.
Running ultrareview automatically — This PR adds a new Run Plan binding feature and changes the public PipelineDefinition.inputs type from array to record, a cross-cutting contract change affecting core, IR, and all consumers — a subtle bug in reachability or input binding could break pipeline execution across the system.. I'll post findings when complete.
Added Run Plan binding for selected pipeline entries, including dependency resolution, input defaults, overrides, and generated plan metadata.
Added reachability utilities and planner APIs for creating executable plans.
Added structured planner errors with codes for missing entries, roots, inputs, and invalid graphs.
Expanded public planner and graph type exports.
Validation
Pipeline inputs now use name-keyed objects with validation for supported types, required fields, secrets, descriptions, and defaults.
Documentation
Added comprehensive planner specification covering behavior, APIs, errors, and testing.
Walkthrough
The change converts pipeline inputs to keyed records and adds planner RunPlan binding. The planner resolves reachable steps, binds defaults and overrides, validates inputs, creates identifiers, exposes typed errors, and publishes the new API.
Pipeline inputs now use keyed Input records. Core re-exports graph types. IR validation checks supported types, metadata, flags, and matching defaults. Fixtures and assertions use keyed inputs.
Planner API and RunPlan binding
Layer / File(s)
Summary
Planner contracts and public API specs/13-planner/spec.md, packages/planner/src/errors.ts, packages/planner/src/planner.ts, packages/planner/src/index.ts, packages/planner/package.json, packages/planner/src/__tests__/public-api.test.ts
The planner specification defines RunPlan binding and reachability. The public API exports binding functions, options, and planner errors. Planner delegates binding to the implementation.
RunPlan binding and validation packages/planner/src/bind.ts, packages/planner/src/__tests__/bind.test.ts
bindRunPlan validates entries and dependencies, resolves reachable steps, binds inputs, excludes secrets, computes identifiers, and returns a timestamped RunPlan. Tests cover binding, reachability, errors, identifiers, and timestamps.
The planner can still produce invalid run plans or crash while handling malformed inputs, and cyclic graphs may reach execution without a schedulable plan. Several documented API and validation contracts also remain inconsistent, while a configured complexity check is failing; these issues should be resolved before merge.
Sequence Diagram(s)
sequenceDiagram
participant Planner
participant bindRunPlan
participant DefinitionGraph
participant RunPlan
Planner->>bindRunPlan: bindRunPlan(options)
bindRunPlan->>DefinitionGraph: locate entry and resolve reachable steps
bindRunPlan->>DefinitionGraph: resolve and validate inputs
bindRunPlan->>RunPlan: construct identifiers and timestamped plan
RunPlan-->>Planner: return bound RunPlan
Loading
Possibly related PRs
sverka-dev/sverka#2: Defines the IR graph and identifier infrastructure used by RunPlan binding.
sverka-dev/sverka#8: Extends the same @sverka/planner package and planner API.
sverka-dev/sverka#38: Establishes the Definition Graph and synthesis model extended by the keyed input changes.
🚥 Pre-merge checks | ✅ 4 | ❌ 1
❌ Failed checks (1 warning)
Check name
Status
Explanation
Resolution
Docstring Coverage
⚠️ Warning
Docstring coverage is 0.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 clearly and concisely identifies the planner Run Plan binding change.
Description check
✅ Passed
The description directly explains Run Plan binding, reachability, input handling, errors, API changes, and test results.
✨ Finishing Touches 💡 2📝 Generate docstrings 💡
Create stacked PR
Commit on current branch
🛠️ Fix failing CI checks 💡
Create stacked PR
Commit on current branch
🧪 Generate unit tests (beta)
Create PR with unit tests
Commit unit tests in branch v0-g-planner
Comment @coderabbitai help to get the list of available commands.
I can't run this ultrareview because you've reached your trial's review limit. Trial plans have lower review limits than paid plans. Upgrade now to resume reviews.
To help optimise your usage, you can tune cubic to get the most out of your usage limits:
The reason will be displayed to describe this comment to others. Learn more.
Review Summary
This PR introduces Run Plan binding functionality for the planner package, which binds Definition Graphs with entry points and inputs into concrete RunPlans for execution. The implementation includes transitive closure computation for reachable steps, input binding with validation, and comprehensive error handling.
Critical Issue Found
Performance Regression: The computeReachableSteps function contains a critical performance issue that must be fixed before merge. The array spread operators in lines 102-103 create unnecessary copies on every iteration, resulting in O(n²) complexity for the adjacency list construction.
Changes Reviewed
✅ New bindRunPlan implementation with proper validation
✅ Error handling with appropriate PlannerError codes
✅ Cross-cutting fix: PipelineDefinition.inputs changed from array to object (maintains input names)
✅ Updated IR validation to match new schema
✅ Comprehensive test coverage (58 passing tests)
The implementation is well-structured with clear separation of concerns. Once the performance issue is resolved, this will be ready to merge.
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 is a substantial planner/API and secret-handling change, but ci_ran=false; the required green CI verification is absent. Human review is needed before merging.
• Add bindRunPlan to bind a DefinitionGraph entry + inputs into an executable RunPlan.
• Compute reachable steps via dependency transitive closure and validate missing entry/roots/inputs.
• Preserve pipeline input names by changing PipelineDefinition.inputs to a keyed object across
core/IR/tests.
Diagram
graph TD
U["Caller"] --> G[("DefinitionGraph")] --> P["bindRunPlan"] --> C["computeReachableSteps"] --> I["computeGraphId + computeRunPlanId"] --> O["RunPlan"]
P --> BI["bindInputs"] --> I
Loading
High-Level Assessment
The following are alternative approaches to this PR:
1. Keep `inputs: Input[]` and add `name` field to Input
➕ Avoids a breaking structural change from array → map in PipelineDefinition
➕ Maintains stable iteration ordering without additional sorting
➖ Duplicates the key in each element and increases risk of name/value divergence
➖ Still requires extra validation for uniqueness and non-empty names
2. Use `inputs: Array` (tuple list) instead of `Record`
➕ Preserves names through synthesis while keeping deterministic ordering
➖ IR/schema validation and JSON shape are less conventional than an object
3. Reachability only follows producers (backward) from roots
➕ Smaller reachable set and simpler traversal logic
➕ Matches 'dependencies[].producer' direction more strictly
➖ Would exclude downstream dependents if roots are not true entry leaves
➖ More brittle if entries/root semantics evolve (e.g., roots as mid-graph anchors)
Recommendation: The chosen approach is sound for v0: bindRunPlan is a clean boundary that produces an engine-ready RunPlan with deterministic IDs, and switching pipeline inputs to Record directly fixes the name-loss issue during synthesis. If ordering becomes important for ID determinism or UX, consider defining an explicit canonical key sort during ID computation rather than reverting the data model.
Files changed (15) +593 / -29
Enhancement (6) +226 / -2
graph.tsChange PipelineDefinition.inputs to Record and re-export constructs types+5/-1
Change PipelineDefinition.inputs to Record and re-export constructs types
• Updates 'PipelineDefinition.inputs' from 'Input[]' to 'Readonly<Record<string, Input>>' to preserve input names. Re-exports constructs types via '@sverka/core' to reduce downstream direct dependencies on '@sverka/constructs'.
bind.tsImplement RunPlan binding (bindRunPlan) and reachability traversal+182/-0
Implement RunPlan binding (bindRunPlan) and reachability traversal
• Adds 'bindRunPlan' to validate graph/entry/roots, select reachable steps, bind pipeline inputs, compute 'graphId'/plan 'id', and set 'createdAt'. Adds 'computeReachableSteps' BFS over dependency edges in both directions and input binding logic with required/default enforcement.
index.tsExport RunPlan binding APIs from planner entrypoint+6/-1
Export RunPlan binding APIs from planner entrypoint
• Updates the planner public API surface to export 'bindRunPlan', 'computeReachableSteps', 'BindRunPlanOptions', and 'PlannerError' alongside existing discovery/plan APIs.
synthesize.tsPreserve input names during pipeline synthesis+4/-1
Preserve input names during pipeline synthesis
• Changes synthesis to emit pipeline inputs as a 'Record<string, Input>' by iterating pipeline input entries, preventing name loss during graph generation.
spec.mdActivate Spec 13 with RunPlan binding behavior and error model+125/-11
Activate Spec 13 with RunPlan binding behavior and error model
• Replaces the stub with an active specification describing 'bindRunPlan', reachability, input binding, ID computation, error codes, exports, and a concrete test plan aligned to the implementation.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
The current implementation introduces a significant discrepancy with Spec 13 regarding reachability logic; the planner currently traverses both producers and dependents, whereas the specification mandates following only producer edges (backward traversal). Additionally, the reachability calculation lacks validation for referenced producers, which could lead to runtime failures if the graph contains broken references.
Codacy analysis indicates the PR is not up to standards, primarily due to high cyclomatic complexity in packages/planner/src/bind.ts. The computeReachableSteps function alone has a complexity of 18. Refactoring this logic into modular helpers is required to improve maintainability and ensure the core BFS logic is verifiable.
About this PR
Discrepancy in reachability logic: The implementation and PR description specify a 'both directions' (forward and backward) transitive closure, whereas the updated Spec 13 (§ Data models) specifies following only 'dependencies[].producer' edges (backward).
1 comment outside of the diffpackages/ir/src/validate.ts
line 118 ⚪ LOW RISK
Suggestion: This validation function is reaching the complexity threshold. While currently readable, consider using a loop for checking required array properties to reduce the branching factor.
function validatePipelineStructure(value: unknown): void {
if (typeof value !== "object" || value === null) {
throw new ValidationError("invalid pipeline: expected object");
}
const p = value as Record<string, unknown>;
if (typeof p.id !== "string") throw new ValidationError("invalid pipeline: missing 'id'");
if (typeof p.inputs !== "object" || p.inputs === null || Array.isArray(p.inputs)) {
throw new ValidationError("invalid pipeline: missing 'inputs' object");
}
for (const key of ["entries", "steps", "outputs"]) {
if (!Array.isArray(p[key])) throw new ValidationError(`invalid pipeline: missing '${key}' array`);
}
for (const step of p.steps as any[]) {
validateStepStructure(step);
}
}
Test suggestions
bindRunPlan produces a RunPlan for a single-step graph
bindRunPlan includes all reachable steps and excludes unrelated steps
bindRunPlan resolves inputs correctly using defaults and user overrides
bindRunPlan throws MISSING_INPUT for required inputs without a value
bindRunPlan throws ENTRY_NOT_FOUND or ROOT_NOT_FOUND for invalid references
bindRunPlan generates a deterministic ID excluding volatile fields
computeReachableSteps handles transitive closure and diamond dependencies without duplicates
computeReachableSteps returns empty list for empty roots
Reachability queues nonexistent producer IDs and later filters them out, leaving dependent steps in
the RunPlan instead of rejecting the graph. The engine then ignores the missing edge during sorting
but cannot mark the dependent ready, and can report success without executing it.
PR/spec explicitly promises validation of producer IDs; missing-producer should be rejected as
INVALID_GRAPH.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
The planner specification requires valid producers. The traversal accepts arbitrary producer IDs and
removes them only from the output; the scheduler ignores absent producers for indegree calculation
while readiness requires every producer to have succeeded, and the engine's no-work path retains
hasFailure === false.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`bindRunPlan` can emit a RunPlan containing a step whose declared producer is absent.
## Issue Context
Validate producer existence for every reachable step and throw `PlannerError` with `INVALID_GRAPH` before computing or returning the plan.
## Fix Focus Areas
- packages/planner/src/bind.ts[39-46]
- packages/planner/src/bind.ts[90-125]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
The revised schema check accepts any non-array object as pipeline.inputs, including {env: null},
and asserts it is a valid graph. Binding such a deserialized graph dereferences input.default and
throws a raw TypeError rather than rejecting invalid input schema.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
Each input must have a valid Input shape, but deserialization returns immediately after validators
that never inspect the record values; the new binder then directly dereferences every value.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Graph deserialization validates only the `inputs` container, not its values, allowing malformed input declarations into typed code.
## Issue Context
Validate every record value as an `Input`, including `type`, optional field primitive types, and default/type compatibility, before asserting `DefinitionGraph`.
## Fix Focus Areas
- packages/ir/src/validate.ts[118-141]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
computeReachableSteps walks dependency edges in both directions from entry roots (producers AND
dependents), so once an ancestor of a root is added, all of that ancestor's other dependents
(unrelated sibling branches) are pulled into the RunPlan too. This contradicts the spec's stated
'transitive closure over dependencies[].producer edges' and can cause the native engine to receive
and execute steps that are not actually needed by the triggered entry.
+ // Add dependents (forward).+ for (const dep of dependents.get(id) ?? []) {+ if (!reachable.has(dep)) queue.push(dep);+ }+ // Add producers (backward).+ for (const prod of producers.get(id) ?? []) {+ if (!reachable.has(prod)) queue.push(prod);+ }
Relevance
●●● Strong
Spec says reachability follows dependencies[].producer only; current bidirectional walk includes
unrelated siblings, likely seen as a bug.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
The spec (specs/13-planner/spec.md lines 84-87 in diff) states reachability is 'transitive closure
from Entry roots over dependencies[].producer edges' — i.e. producer-only (backward) traversal. The
implementation in bind.ts instead builds both a dependents map and a producers map and enqueues
both directions from every visited node (lines 114-121), so given steps B (root, depends on A) and C
(also depends on A, but not related to B), once A is reached via B's producer edge, C gets added as
a 'dependent' of A even though C is not needed to run B. The PR's own test 'includes all reachable
steps with dependencies' only exercises a linear chain so it doesn't catch this, but a
diamond/sibling-branch graph would incorrectly include C in the RunPlan for an entry rooted at B.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
computeReachableSteps in packages/planner/src/bind.ts traverses dependency edges in both directions (producer edges AND dependent edges) starting from the entry's roots. This means that once an ancestor of a root is reached, all of that ancestor's other descendants (unrelated sibling steps not needed to execute the root) are also pulled into the RunPlan.
## Issue Context
The spec (specs/13-planner/spec.md) defines reachability as the transitive closure from Entry roots over `dependencies[].producer` edges only (i.e., an entry needs its roots and all of their transitive producers/ancestors — not unrelated dependents/descendants of those producers). The current implementation instead does a bidirectional BFS which over-includes steps.
## Fix Focus Areas
- packages/planner/src/bind.ts[90-126]
- packages/planner/src/bind.ts[97-105]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
bindRunPlan hardcodes graph.project.pipelines[0] as the pipeline to bind against, so in graphs
with multiple pipelines a valid entryId that exists only in a later pipeline incorrectly throws
ENTRY_NOT_FOUND rather than being found or explicitly rejected. Although a comment acknowledges
this limitation, there is no validation to guard against multi-pipeline graphs and no mechanism to
select or search other pipelines, leaving multi-pipeline DefinitionGraphs only partially bindable.
+ // For v0, we operate on the first (and typically only) pipeline.+ const pipeline = graph.project.pipelines[0]!;++ // Find the entry.+ const entry = findEntry(pipeline, entryId);
Relevance
●● Moderate
Multi-pipeline support is explicitly deferred (“v0…first pipeline”); change is architectural and may
be postponed.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
In packages/planner/src/bind.ts, bindRunPlan always selects graph.project.pipelines[0]!
(around line 34) and passes it into findEntry, and findEntry only searches within that
pipeline’s entries (around line 129). Meanwhile, the graph model represents pipelines as
DefinitionGraph.project.pipelines: readonly PipelineDefinition[] (packages/core/src/graph.ts)
with no restriction to a single element, meaning multi-pipeline graphs are a valid representable
state; synthesis emits every pipeline and uses pipeline-qualified entry IDs, but the binder still
only checks the first pipeline. As a result, entries that exist in later pipelines are never
considered during binding and incorrectly surface as ENTRY_NOT_FOUND, which is misleading rather
than an explicit “unsupported multi-pipeline graph” or a correct match.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`bindRunPlan` unconditionally binds against `graph.project.pipelines[0]`, silently ignoring additional pipelines. This causes valid `entryId`s that belong to later pipelines to fail with a misleading `ENTRY_NOT_FOUND` instead of being found (e.g., by searching all pipelines) or being rejected with a clear error (e.g., invalid/unsupported multi-pipeline graph).
## Issue Context
`DefinitionGraph.project.pipelines` is an array (and not constrained to length 1 by the type system or validation), so multi-pipeline graphs are a legitimate state. Each pipeline owns its own entries, and synthesis emits every pipeline and uses pipeline-qualified entry IDs, but binding currently searches only the first pipeline; if you expand binding to search across pipelines, handle ambiguity explicitly if necessary.
## Fix Focus Areas
- packages/planner/src/bind.ts[29-37]
- packages/planner/src/bind.ts[33-37]
- packages/planner/src/bind.ts[128-137]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
5. Input types not enforced✓ Resolved🐞 Bug≡ Correctness
Description
bindInputs copies overrides and defaults without comparing their primitive type to Input.type,
so a declared string input can be bound to a number. The resulting concrete RunPlan violates its
input declaration and can deliver incorrect values to consumers.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Input overrides and defaults are accepted regardless of the corresponding declaration's `type`.
## Issue Context
Require string, number, or boolean values to match `Input.type`. Validate graph defaults and return a structured planner error for invalid user overrides.
## Fix Focus Areas
- packages/planner/src/bind.ts[151-178]
- packages/ir/src/validate.ts[118-141]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
6. Special input names mishandled✓ Resolved🐞 Bug≡ Correctness
Description
Synthesis writes arbitrary input names into a normal {} object, so assigning __proto__ invokes
its legacy setter rather than reliably creating an own property. Such a permitted input can be lost
or alter the record prototype, and binding repeats the same unsafe accumulation pattern.
ⓘ Recommendations generated based on similar findings in past PRs
Evidence
The constructs API accepts arbitrary record keys and preserves them in a Map, but synthesis and
binding copy those keys via indexed assignment into ordinary objects.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Arbitrary input names are copied into prototype-bearing objects, which mishandles names such as `__proto__`.
## Issue Context
Use `Object.create(null)`, `Object.fromEntries`, or safely defined own properties consistently for synthesized and bound input records.
## Fix Focus Areas
- packages/core/src/synthesize.ts[70-73]
- packages/planner/src/bind.ts[151-181]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Review mode: 🧠 Deep: This is a substantial behavioral planner/API change spanning multiple packages, with new graph traversal, input binding, validation, identity computation, and a cross-cutting schema change that creates several independent opportunities for subtle defects.
Tip of the day
💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR
Rebuilt @sverka/planner with bindRunPlan: binds a Definition Graph's
Entry + user inputs into a concrete RunPlan for the native engine.
- bindRunPlan: selects reachable steps, binds inputs, computes IDs
- computeReachableSteps: transitive closure from entry roots (both directions)
- PlannerError: ENTRY_NOT_FOUND, ROOT_NOT_FOUND, MISSING_INPUT, INVALID_GRAPH
- Reuses existing discovery + plan synthesis logic unchanged
Changed PipelineDefinition.inputs from Input[] to Record<string, Input>
to preserve input names through synthesis. Updated core, IR validation,
and test fixtures accordingly.
58 planner tests pass (17 new bind tests + 41 existing). All 7 affected
packages green: 229 tests total. No any types.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
- Search all pipelines in findEntry (not just the first one).
- Validate dependency producers before building the RunPlan.
- Follow only producer/prerequisite edges backward in computeReachableSteps.
- Validate pipeline input descriptor fields (type, required, secret, description, default).
- Omit secret input values from RunPlan.inputs and from the content-addressed plan ID.
- Update graph and bind tests for record-based inputs and sink roots.
Co-Authored-By: Petr Plenkov <petr.plenkov@gmail.com>
- Validate runtime graph shape in bindRunPlan before dereferencing fields.
- Run core validateGraph on the selected pipeline to detect cycles and semantic errors.
- Use an index-based queue in computeReachableSteps and mark nodes reachable on enqueue.
- Validate input descriptor type for secret and optional inputs.
- Add INVALID_INPUT PlannerErrorCode and use it for type-mismatched user/default values.
- Update Spec 13 to document options-object contract, inputs record, INVALID_INPUT, and structural validation.
Co-Authored-By: Petr Plenkov <petr.plenkov@gmail.com>
Split validatePipelineInput (complexity 13→3) into per-field validators
and validatePipelineShape (complexity 12→3) into field/child helpers.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.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:XL
![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}
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
baz-reviewer
Bot
added
baz: ready to merge
baz: needs review
and removed
baz: needs review
baz: ready to merge
labels
User description
Summary
@sverka/plannerwithbindRunPlan: binds a Definition Graph's Entry + user inputs into a concrete RunPlan for the native enginecomputeReachableSteps: transitive closure from entry roots (both directions)PlannerError: ENTRY_NOT_FOUND, ROOT_NOT_FOUND, MISSING_INPUT, INVALID_GRAPHPipelineDefinition.inputschanged fromInput[]toRecord<string, Input>to preserve input names through synthesis. Updated core, IR validation, and test fixtures.Test plan
anytypesGenerated with Devin
Summary by cubic
Produces a deterministic RunPlan from a selected entry in
@sverka/planner, with fast-fail graph validation and secrets-safe plan IDs. Old: no binder. New:bindRunPlancomputes reachable steps, binds inputs, and omits secret values from the plan and its ID.@sverka/corevalidateGraphon the selected pipeline; malformed graphs, cycles, and unknowndependencies[].producerraisePlannerError("INVALID_GRAPH").ENTRY_NOT_FOUND/ROOT_NOT_FOUND.dependencies[].producerbackward from roots and excludes unrelated steps.Record<string, Input>; defaults merge with user overrides with strict type checks. Type mismatches raiseINVALID_INPUT; missing required values raiseMISSING_INPUT. Secret inputs are omitted fromRunPlan.inputsand excluded from@sverka/ircomputeRunPlanId.Planner.bindRunPlan(...);@sverka/plannerexportsbindRunPlan,computeReachableSteps, andPlannerError(addsINVALID_INPUT).RunPlanincludesgraphId, a content-addressedid, andcreatedAt.@sverka/plannernow depends on@sverka/coreand@sverka/ir.@sverka/corere-exports graph types.@sverka/irvalidator enforces inputs object shape and validatestype,required,secret,description, and default type consistency.Migration
PipelineDefinition.inputs: Input[]withRecord<string, Input>and update array iterations toObject.entries/Object.keys.Written for commit c06b5e0. Summary will update on new commits.
CodeAnt-AI Description
Bind definition graphs into executable run plans
What Changed
Impact
✅ Executable plans from selected pipeline entries✅ Unrelated steps excluded from runs✅ Clear errors for invalid entries and missing inputs💡 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.