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
Switched core operation IDs to SHA‑256 content‑addressed IDs (op-<64hex>) per ADR‑006, and unified ID/serialization primitives across @sverka/core and @sverka/ir for consistent planning, execution, and compilation.
New Features
@sverka/core: Deterministic IDs from computeOperationId(kind, name, context) using canonical JSON (sorted keys, compact; objects omit undefined; arrays emit null for undefined; rejects NaN/Infinity/BigInt). Context includes matrix dims, userId (from spec.id), command, and args. True duplicates (same kind/name/context) fail. Legacy derived IDs and matrix suffix logic were removed. Public API exports computeOperationId and canonicalStringify.
Planning: Resolves dependsOn strings that reference either op IDs or spec.id aliases; duplicate or unknown aliases fail. Cycle detection runs on resolved op IDs.
@sverka/ir: Re‑exports canonicalStringify and computeOperationId from @sverka/core; added a cross‑package test to ensure identical op IDs.
Migration
IDs are now op-<64hex>; update any consumers expecting readable IDs or previous formatting.
dependsOn may reference op IDs or spec.id aliases; aliases must be unique and resolvable.
Use computeOperationId from @sverka/core to recompute IDs; @sverka/core and @sverka/ir now produce identical results.
Written for commit fe92e6b. Summary will update on new commits.
CodeAnt-AI Description
Use stable content-based operation IDs across planning, execution, and compilation
What Changed
Operations now receive deterministic op- IDs generated from their content instead of readable command-based IDs or user IDs.
Matrix operations get distinct IDs for each combination, while identical operations are rejected as duplicates.
dependsOn can reference either generated operation IDs or user-provided aliases; cycles and unresolved references are validated against the resolved IDs.
Core exposes the shared ID and canonical serialization helpers so core and IR produce matching results.
Canonical serialization now consistently handles key ordering, arrays, special numbers, bigints, and lone surrogate characters.
Impact
✅ Stable operation IDs across planning and execution ✅ Reliable matrix and dependency tracking ✅ Consistent IDs between core and IR
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.
@ThePlenkov, you've reached your PR review limit, so we couldn't start this review.
Next review available in:39 minutes
Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.
For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.
Running ultrareview automatically — This rewrites core ID assignment and dependency resolution to content-addressed op- IDs, changing public ID semantics and duplicate-operation behavior across every planned workflow — high blast radius if a hashing, canonicalization, or edge-resolution bug slips through.. I'll post findings when complete.
Fix core operation ID assignment with ADR-006 SHA-256 content-addressed IDs
🐞 Bug fix🧪 Tests✨ Enhancement🕐 40+ Minutes
AI Description
• Replace planner-derived human-readable ids with ADR-006 SHA-256 content-addressed op- ids.
• Add canonical JSON serialization and fold user spec.id into hash context as userId.
• Export computeOperationId and add/update tests, including core↔ir consistency coverage.
The following are alternative approaches to this PR:
1. Create shared canonical/id package
➕ Eliminates duplicated canonicalStringify logic between core and ir
➕ Single place to evolve ADR-006 behavior with shared tests
➖ Introduces a new shared package/dependency edge
➖ Requires careful versioning to avoid tightening core’s dependency surface
2. Use a deterministic stringify library
➕ Less bespoke canonicalization code to maintain
➕ Likely broader edge-case handling
➖ Adds a dependency to core (size/supply-chain/compatibility risk)
➖ Harder to guarantee byte-identical output required by ADR-006 long term
3. Keep spec.id as alias-only (not in hash context)
➕ op- ids remain stable even if user alias changes
➕ Clearer separation of identity vs. aliasing
➖ Would diverge from the chosen ADR-006 interpretation in this PR
➖ Increases risk of collisions for otherwise-identical operations without extra discriminators
Recommendation: The PR’s approach is appropriate for ADR-006: core stays dependency-light (node:crypto only), ids are fully content-addressed, and the new core↔ir consistency test is the right long-term guardrail against drift. Consider a shared package only if maintaining two canonicalizers becomes a recurring cost.
Files changed (12) +462 / -124
Enhancement (2) +136 / -0
index.tsExport computeOperationId from core public API+1/-0
Export computeOperationId from core public API
• Adds computeOperationId to the @sverka/core public barrel to support consumers recomputing ids from content.
canonical.tsIntroduce canonical JSON serializer used for stable hashing (ADR-006)+135/-0
Introduce canonical JSON serializer used for stable hashing (ADR-006)
• Adds a manual canonical JSON emitter with sorted object keys, omission of undefined fields, and strict handling of non-JSON numbers. Documented as an independent copy of IR’s canonicalization, with drift guarded by tests.
ids.tsImplement computeOperationId via canonical JSON + SHA-256; remove legacy id derivation+22/-52
Implement computeOperationId via canonical JSON + SHA-256; remove legacy id derivation
• Deletes the prior derived-id and matrix-child suffix logic and replaces it with computeOperationId(kind,name,context) using node:crypto sha256. Retains isKnownKind validation helper.
plan.tsRework ID assignment and dependsOn resolution for content-addressed ids+104/-29
Rework ID assignment and dependsOn resolution for content-addressed ids
• Assigns op ids via computeOperationId using nameFor() and contextFor() (matrix dims, userId alias, command, args) and rejects true duplicates by construction. Adds aliasMap and resolves dependsOn strings as either op ids or spec.id aliases, erroring on dangling references.
workflow.test.tsUpdate workflow planning assertions to op-<64hex> ids+9/-7
Update workflow planning assertions to op-<64hex> ids
• Stops asserting old human-readable ids and instead validates op-<64hex> format for planned operations. Updates dependsOn expectations to reference the computed op ids.
dag.test.tsAlign DAG tests with alias resolution and content-addressed collisions+37/-16
Align DAG tests with alias resolution and content-addressed collisions
• Updates wording and expectations to treat spec.id as a dependsOn alias resolved to op ids. Adds a new test that identical operations collide (same op id) and surface an op id in CompositionError context.
ids.test.tsAdd computeOperationId unit tests+67/-0
Add computeOperationId unit tests
• Introduces coverage for id format, determinism, key-order independence, and variation across kind/name/context. Verifies output matches a manual sha256 over canonical JSON input.
laziness.test.tsAvoid true-duplicate ops in laziness test under content-addressed ids+5/-1
Avoid true-duplicate ops in laziness test under content-addressed ids
• Changes the workflow roots to use distinct operations so planning doesn't reject duplicates. Keeps the focus on ensuring no filesystem/process/network I/O occurs.
matrix.test.tsUpdate matrix tests to expect content-addressed op ids+21/-10
Update matrix tests to expect content-addressed op ids
• Replaces suffix-based id assertions with op-id regex and uniqueness checks. Adds expectations that ids match computeOperationId over the expected context fields.
runtime-modes.test.tsUpdate runtime mode expectations to use planned op ids+15/-8
Update runtime mode expectations to use planned op ids
• Makes execute/compile/condition tests compare evaluated ids to plan ids rather than hard-coded strings. Ensures artifacts and evaluated ids follow op-<64hex> format.
• Adds parameterized tests ensuring core and ir implementations produce byte-identical op ids for representative inputs, preventing canonicalization/hashing drift.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
The PR implementation of SHA-256 content-addressed IDs is currently not up to standards, primarily due to a logic flaw in the ID context generation and failure of cross-package consistency checks.
Critical Blocking Issues
ID Collision Risk: The 'contextFor' function in 'plan.ts' omits critical fields like 'env', 'image', and 'workingDir'. This causes different operations to hash to the same ID, which will trigger composition errors or incorrect cache behavior.
Test Resolution Failure: The consistency test in the IR package cannot resolve the core module, meaning the cross-package verification required by ADR-006 is not actually executing in CI.
Complexity & Coverage: 'packages/core/src/internal/canonical.ts' has been identified as a complex file with significant uncovered logic, posing a maintenance risk for such a critical component of the hashing system.
Platform Compatibility: The use of 'node:crypto' and ES2017 features (like 'padStart') may break the package's requirements for isomorphic or legacy environment support.
About this PR
The implementation of 'canonicalStringify' is manually duplicated between the core and ir packages. While this avoids circular dependencies, any future changes to the canonical format (ADR-006) must be manually synced in both locations to prevent ID mismatches.
Test suggestions
Verify computeOperationId produces the same hash for identical inputs regardless of key insertion order in context
Verify matrix expansion produces distinct, deterministic IDs for each combination
Verify planning fails when duplicate user-provided spec.id aliases are defined
Verify planning fails when two operations have identical kind, name, and context (true duplicates)
Verify dependsOn strings correctly resolve user-provided spec.id aliases to the resulting op- IDs
Verify cross-package consistency: core and ir implementations of computeOperationId produce identical outputs
Verify canonicalStringify correctly escapes control characters and quotes per JSON spec
Address code coverage gaps in 'packages/core/src/internal/canonical.ts'
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Address code coverage gaps in 'packages/core/src/internal/canonical.ts'
Spec 01-core §ID assignment requires the hash context to include a positional discovery index,
and the operation identity should distinguish execution-affecting configuration, but the new
contextFor() in plan.ts omits the index and only includes matrix combo, userId, command, and
args. This makes repeated or semantically different operations hash to the same op-<hash> and,
because assignIds() rejects any collision, causes planWorkflow to throw
CompositionError('duplicate operation id ...') for workflows that previously planned successfully
(old behavior disambiguated with a counter suffix).
+function contextFor(node: OperationNode): Record<string, unknown> {+ const s = node.spec;+ const ctx: Record<string, unknown> = {};+ const combo = (node as unknown as Record<string, unknown>).__matrixCombo as+ | readonly [string, unknown][]+ | undefined;+ if (combo !== undefined) {+ for (const [k, v] of combo) ctx[k] = v;+ }+ if (s.id !== undefined) ctx["userId"] = s.id;+ if (s.command !== undefined) ctx["command"] = s.command;+ if (s.args !== undefined) ctx["args"] = [...s.args];+ return ctx;
}
Evidence
The spec text in specs/01-core/spec.md (lines 384–392) explicitly calls out a positional index
within the discovery walk as part of the context used for ID assignment, indicating IDs should be
distinct “by construction” even when operations share kind/name and overlap in other fields;
however, the shipped contextFor() implementation only carries matrix dimensions, user ID, command,
and args, omitting any index and other execution-affecting fields present in the operation model
(e.g., env, image, workingDir, credentials, timeout). With assignIds() rejecting every hash
collision, two operations that are repeated in a workflow or differ only in those omitted
configuration fields can legitimately exist yet still collide and fail planning, and the new test in
packages/core/src/__tests__/dag.test.ts (“rejects true duplicate operations (identical
kind/name/context)”) codifies collision rejection as expected behavior, which diverges from the
spec’s stated discriminator and from the prior counter-suffix behavior that allowed repeated steps
to coexist.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`contextFor()` in `packages/core/src/internal/plan.ts` computes the hash context used by `computeOperationId`, but it omits discriminators required/expected by the ID assignment contract: the spec mandates including a positional discovery `index`, and there are additional execution-affecting operation fields (e.g., `env`, `image`, `workingDir`, credentials, timeout) that are not represented in the current context. Because `assignIds()` rejects any ID collision, this overly narrow context causes repeated operations or semantically different operations to hash to the same `op-<sha256>` ID and fail planning with `CompositionError('duplicate operation id ...')`, even for workflows that previously planned successfully.
## Issue Context
- `specs/01-core/spec.md` (§ID assignment) states the context must include a positional `index` within the discovery walk, specifically to ensure distinct IDs by construction.
- The current `contextFor()` includes only matrix combo, `userId`, `command`, and `args`, so structurally identical operations used twice in a workflow (e.g., two unnamed `run({ command: "test" })` nodes reused for repeated/retry steps) collide.
- The operation model contains many fields that affect execution; if positional identity is not intended, the identity contract may need to include those fields in canonical form to avoid collisions between semantically different operations.
- A new test in `packages/core/src/__tests__/dag.test.ts` (“rejects true duplicate operations (identical kind/name/context)”) treats these collisions as expected; the spec, implementation, and tests need to be reconciled so they agree on whether IDs are positional (include index) and/or configuration-sensitive (include execution-affecting fields).
## Fix Focus Areas
- packages/core/src/internal/plan.ts[245-275]
- packages/core/src/internal/plan.ts[289-308]
- packages/core/src/internal/plan.ts[258-260]
- packages/core/src/internal/plan.ts[295-307]
- specs/01-core/spec.md[384-392]
- packages/core/src/__tests__/dag.test.ts[47-60]
- packages/core/src/operation.ts[18-42]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
2. Matrix user IDs collide 🐞 Bug≡ Correctness
Description
Every expanded matrix child inherits the template's spec.id, but the new alias map rejects the
second occurrence. Consequently, any multi-value matrix(..., run({ id: ... })) fails planning even
though matrix dimensions give its children distinct content-addressed IDs.
+ if (node.spec.id !== undefined) {+ if (aliasMap.has(node.spec.id)) {+ throw new CompositionError(
Evidence
Expansion copies the full spec into each child, including spec.id; matrix dimensions make child
hashes distinct, but alias uniqueness independently rejects the repeated template alias. The core
specification allows user IDs to influence hashes and defines matrix expansion without prohibiting
that combination.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
Matrix expansion copies one user ID to every child, and global alias uniqueness makes the resulting valid matrix unplannable.
## Issue Context
Define template-alias semantics for expanded children, such as resolving the template alias to all child IDs or deriving unambiguous child aliases. Do not reject repeated aliases that originate from one matrix template, and add a two-value matrix regression test with an explicit `spec.id`.
## Fix Focus Areas
- packages/core/src/internal/plan.ts[141-149]
- packages/core/src/internal/plan.ts[264-272]
- packages/core/src/internal/plan.ts[295-306]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
3. Resolved name not emitted 🐞 Bug≡ Correctness
Description
The planner hashes the command fallback from nameFor(node), but emits name: "" when spec.name
is absent. A consumer recomputing the ID from the fully resolved operation therefore gets a
different ID for common inputs such as run({ command: "build" }).
+ const id = computeOperationId(node.kind, nameFor(node), contextFor(node));
Evidence
The hash uses nameFor, whose fallback is spec.command, while buildSpec emits an empty name.
ADR-006 requires operation IDs to be reproducible by tools reading the plan.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
The operation ID is computed with `nameFor(node)`, but the emitted operation may contain a different `name`, preventing ID reproduction from plan content.
## Issue Context
For operations without `spec.name`, `nameFor` uses `spec.command` while `buildSpec` currently emits an empty string. Use one resolved name for both hashing and emission, and add a regression test that recomputes the emitted operation's ID.
## Fix Focus Areas
- packages/core/src/internal/plan.ts[258-258]
- packages/core/src/internal/plan.ts[282-286]
- packages/core/src/internal/plan.ts[368-374]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
4. Alias shadows generated ID 🐞 Bug≡ Correctness
Description
resolveDep gives generated IDs precedence over unrestricted user aliases. If operation A's
spec.id equals operation B's generated ID, a dependency intended for A silently targets B and
produces the wrong DAG.
+ if (knownOpIds.has(dep)) return dep;+ const aliased = aliasMap.get(dep);+ if (aliased !== undefined) return aliased;
Evidence
Aliases are accepted without comparison to generated IDs, while dependency resolution checks
generated IDs first. Since computeOperationId is public, the overlapping value can be constructed
deterministically.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
A dependency string can match both a generated operation ID and a user alias, and the current precedence silently resolves it to the wrong node.
## Issue Context
After collecting all generated IDs and aliases, reject any alias that overlaps the generated-ID namespace. Add a regression test where one operation's alias equals another operation's public `computeOperationId` result.
## Fix Focus Areas
- packages/core/src/internal/plan.ts[264-272]
- packages/core/src/internal/plan.ts[349-356]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
resolveDep() treats any user dependsOn string that isn't already a known op- id as an alias
lookup in aliasMap, and raises an error only if no operation happens to declare that spec.id;
this means a typo'd or stale dependsOn value that accidentally matches another unrelated
operation's spec.id silently creates a wrong dependency edge instead of failing loudly, and there
is no way to reference a truly external/foreign id since any non-matching string throws.
resolveDep (packages/core/src/internal/plan.ts lines 349-360) has only two success paths — exact
op- id match or alias-map match — with no additional validation that the alias was intended for
this specific dependsOn reference, so any coincidental id collision across unrelated operations in a
large workflow resolves silently to the wrong edge.
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
## Issue description
`resolveDep()` resolves a `dependsOn` string against `aliasMap` (user-provided `spec.id` values) whenever it isn't already a known `op-` id, with no additional disambiguation. In large workflows composed from multiple modules, this creates a risk that an unrelated operation's `spec.id` accidentally satisfies a `dependsOn` reference intended for a different (perhaps typo'd or removed) operation, producing a silently wrong dependency edge rather than an error.
## Issue Context
This is a low-probability, hard-to-detect issue since `spec.id` collisions are already rejected earlier in `assignIds()`, but cross-file/cross-module composition could still lead to accidental reuse of common alias names (e.g. "build", "test").
## Fix Focus Areas
- packages/core/src/internal/plan.ts[343-360]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Context
Review mode: 🧠 Deep: This is a high-density behavioral change spanning core ID generation, canonical serialization, planning, dependency alias resolution, public API, IR consistency, and many independent test paths; subtle cross-package or edge-resolution 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
The shipped planner rejects any multi-value matrix operation carrying a user-provided spec.id because every expanded child reuses the alias. This contradicts the PR’s claimed support for distinct matrix IDs and prevents valid workflows from being planned.
The reason will be displayed to describe this comment to others. Learn more.
Ultrareview completed in 9m 37s
5 issues found across 12 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/core/src/internal/ids.ts">
<violation number="1" location="packages/core/src/internal/ids.ts:25">
P2: Operation IDs collide when a name or string context value contains an unpaired surrogate: the canonical serializer writes it raw, and the UTF-8 hash conversion replaces it with U+FFFD. As a result, for example, `"\uD800"` and `"\uFFFD"` hash to the same operation ID despite being distinct inputs. Escaping unpaired surrogates in `canonicalStringify` (as `JSON.stringify` does), or rejecting them before hashing, would preserve content addressing.</violation>
</file>
<file name="packages/core/src/internal/plan.ts">
<violation number="1" location="packages/core/src/internal/plan.ts:265">
P1: A matrix operation with a user-provided `id` can no longer be planned: every expanded child inherits that ID, and the second child is treated as a duplicate alias even though its matrix context gives it a distinct `op-` ID. The alias representation needs to account for a matrix alias resolving to multiple child IDs (and expand a dependency on it accordingly), or matrix-child aliases need to be handled separately so an otherwise valid matrix does not fail during ID assignment.</violation>
<violation number="2" location="packages/core/src/internal/plan.ts:306">
P1: Two otherwise identical operations that use different environments are now rejected as duplicate operations, even though their emitted specs execute with different `env` values. `contextFor()` only hashes `command` and `args` beyond the name, so it needs to include the other execution-discriminating fields (such as `env`, image, working directory, and runtime policy) or retain another documented uniqueness discriminator before duplicate detection.</violation>
<violation number="3" location="packages/core/src/internal/plan.ts:354">
P2: A user alias that happens to equal an existing `op-` ID is silently resolved as the generated ID, so a `dependsOn` edge can point at the wrong operation. Since `spec.id` accepts arbitrary strings and aliases are now supported, detect this namespace collision and reject it (or introduce an unambiguous alias syntax) instead of giving generated IDs implicit precedence.</violation>
</file>
<file name="packages/ir/src/__tests__/core-consistency.test.ts">
<violation number="1" location="packages/ir/src/__tests__/core-consistency.test.ts:21">
P3: The cross-consistency test only asserts `core === ir`, so it guards against one copy drifting but cannot detect a correlative drift where both copies change identically (e.g., a shared change to the `op-` prefix or the hashing/canonicalization). Since ids.test.ts already validates the `op-` + 64-hex format for the ir copy, consider anchoring at least one Consistency test case to a golden expected hash (computed from ADR-006) — or asserting the format directly here — so a simultaneous regression in both packages is caught, not just divergence between them.</violation>
</file>
Core's assignId/assignIds used human-readable string derivation
(kind:name-or-command-or-index with collision counter) and passed
user spec.id through as-is, violating ADR-006. Now uses SHA-256
content-addressed ids: op-<64 hex> via node:crypto.createHash over
canonical JSON of {kind, name, context}, with spec.id folded into
hash context as userId.
- Created packages/core/src/internal/canonical.ts (computeOperationId)
- Rewrote packages/core/src/internal/ids.ts + plan.ts for SHA-256
- Exported computeOperationId from core public index.ts
- Fixed all tests to assert op-<64hex> format (90 core tests pass)
- Added cross-consistency test: core === ir computeOperationId (87 ir tests)
- Full monorepo: 16 projects test+typecheck+build green
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:L
![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}
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
User description
Summary
packages/core/src/internal/canonical.tswithcomputeOperationId(SHA-256 via node:crypto.createHash)ids.ts+plan.ts: op-<64 hex> format, spec.id folded into hash context as userId (not used as-is)computeOperationIdfrom core public APIcomputeOperationId=== ircomputeOperationIdfor identical inputsTest plan
Stacked on #5
Generated with Devin
Summary by cubic
Switched core operation IDs to SHA‑256 content‑addressed IDs (
op-<64hex>) per ADR‑006, and unified ID/serialization primitives across@sverka/coreand@sverka/irfor consistent planning, execution, and compilation.New Features
@sverka/core: Deterministic IDs fromcomputeOperationId(kind, name, context)using canonical JSON (sorted keys, compact; objects omit undefined; arrays emit null for undefined; rejects NaN/Infinity/BigInt). Context includes matrix dims,userId(fromspec.id),command, andargs. True duplicates (same kind/name/context) fail. Legacy derived IDs and matrix suffix logic were removed. Public API exportscomputeOperationIdandcanonicalStringify.dependsOnstrings that reference either op IDs orspec.idaliases; duplicate or unknown aliases fail. Cycle detection runs on resolved op IDs.@sverka/ir: Re‑exportscanonicalStringifyandcomputeOperationIdfrom@sverka/core; added a cross‑package test to ensure identical op IDs.Migration
op-<64hex>; update any consumers expecting readable IDs or previous formatting.dependsOnmay reference op IDs orspec.idaliases; aliases must be unique and resolvable.computeOperationIdfrom@sverka/coreto recompute IDs;@sverka/coreand@sverka/irnow produce identical results.Written for commit fe92e6b. Summary will update on new commits.
CodeAnt-AI Description
Use stable content-based operation IDs across planning, execution, and compilation
What Changed
op-IDs generated from their content instead of readable command-based IDs or user IDs.dependsOncan reference either generated operation IDs or user-provided aliases; cycles and unresolved references are validated against the resolved IDs.Impact
✅ Stable operation IDs across planning and execution✅ Reliable matrix and dependency tracking✅ Consistent IDs between core and IR🔄 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.