Import of trace-adapter from Sui repository with preserved history#638
Open
Import of trace-adapter from Sui repository with preserved history#638
Conversation
…n (#19106) ## Description Move VM tracing is currently in development (MystenLabs/sui#18730) and this PR contains the first version of both the Move VM trace viewing VSCode extension and the IDE-independent [Debug Adapter Protocol ](https://microsoft.github.io/debug-adapter-protocol/)(DAP) implementation that is is responsible for actual trace analysis and visualization. Reviewing advice - I would suggest focusing on TypeScript files as the rest is largely configuration and boilerplate to get a TypeScript project (and, by extension, a VSCode project) going. ## Test plan Tested manually by both packaging/installing extension and making sure that the extension itself can be debugged correctly.
## Description This PR adds the ability to step back through the trace. The main limitation is that stepping back into or over (previously executed) function calls is not supported. We will add this support after support for viewing variables is added as it will requires snapshotting variable state (which we do not have at the moment). ## Test plan Tested manually that: - viewer correctly steps back within the function and from inside the callee to the caller - viewer correctly stops stepping back at the beginning of the trace - viewer correctly stops stepping back upon encountering previously executed function call
…306)
## Description
In Move, there isn't necessarily 1:1 correspondence between source code
and bytecode due to compiler optimizations. In the following code
example (admittedly somewhat artificial for presentation purposes),
there will be no entry for `constant` variable in the bytecode as it
will be optimized away via constant propagation:
```
fun hello(param: u64): vector<u64> {
let mut res = param;
let constant = 42; // optimized away
if (constant >= 42) { // optimized away and turned into straight line code
res = 42;
};
vector::singleton(res)
}
```
This PR implements a heuristic that will mark source code lines
optimized away by the compiler as having grey background. We do this by
analyzing source maps for a given file and marking lines that are
present in the source map but not in the source file (with some
exceptions, notably empty lines, lines starting with `const`, and lines
that only contain right brace `}`).
At this point, the "optimized away" lines include comments (we can
finesse it in the future if need be, but it does in some sense reflect
the spirit of this visualization)
## Test plan
Tested manually to see if grey lines appear and changes throughout
debugging session when going to different files, and that they are reset
once debug session is finished.
## Description
This PR adds support for "continue" debugger action. It also makes
implementation of "next" ("step over") and "step out" actions faithful
to their intended semantics (i.e., executing all instruction in a
function stepped over or stepped out of). These changes do not actually
change the current behavior of the viewer - they are done in preparation
for implementing variable value tracking and displaying.
This PR also includes a refinement of the "step out" action
implementation. As also explained in the code comment, previously in the
following line of code, after entering `foo` and stepping out of it, we
would immediately step into `bar`, which could be quite confusing for
the user:
```
assert(foo() == bar());
```
Finally, this PR also includes some formatting changes for lines that
were a bit too long
## Test plan
Tested manually
…#19394) ## Description This PR is the first in the series of PRs aiming to implement support for inspecting variables when viewing the trace (splitting this into multiple PRs to make the reviewing easier). The current focus is on primitive values (no structs/enums or references), but even with this limited focus it leaves the following work to subsequent PR: - support for shadowed variables (a variable declared in an inner scope/block that has the same name as the one declared in the outer scope/block) - support for moving backwards in trace ## Test plan Tested manually to make sure that thing work correctly
## Description This PR adds handling of shadowed variables to the trace viewer: - shadowed variables appear in separate scopes - shadowed scope appears when a variable with the same name as an already existing one is declared - shadowed scope disappears when all variables it includes stop being live Additionally, this PR (temporarily) suppresses on-hover information that VSCode shows during debug session. The reason for it is that the default VSCode behavior in this department breaks in presence of shadowed variables ## Test plan Tested manually
## Description This PR adds support for tracking variable values for structs and enums. It also does some code cleanup (mostly via renamings) ## Test plan Tested manually
## Description This PR implements a more principled way to handle skipping instructions located on the same source code line for a smoother user experience. The main issue is handling call instructions, particularly if more than one of them is located on the same source code line. If not handled properly, the following effects could take place - if a call instruction was preceded by another instruction on the same source code line, when executing `step` action, the user would have to click `step` button twice on the same line to actually step into the call making an impression that the debugger is somehow stuck (or at least stuttering) - if more than one call instruction was on the same line, two things could happen: - executing the `next` action would not skip over all calls but only over a single one instead (the user would have to click `next` button multiple times to get to the next line) - executing the `step` would cause control flow to immediately enter the subsequent call on the same line instead of waiting for another `step` command from the user This PR also removes code related to stepping backwards in the trace as it's not being used nor maintained making a false impression that it's simply disabled and ready to roll ## Test plan Tested manually that the scenarios described above are handled correctly
## Description This PR adds support for tracking reference values and displaying reference type when hovering over the variable name. The idea is really simple - for references, simply remember where they are pointing at and when asked to display their value, display the value of the original variable ## Test plan Tested manually
## Description I was trying to reduce memory footprint of files pushed to the repo for testing the trace viewer but missed one Move stdlib dependency that still needs to be there. This PR fixes this. ## Test plan All tests must pass (tested on a fresh checkout of the repo that they do)
## Description Added support for line breakpoints. ## Test plan Old and new tests must pass
…(#20080) ## Description Adds support for native functions where the `CloseFrame` event happens right after `OpenFrame` event and both need to be skipped to skip over the native function. Also added support for handling global locations - they should be parsed properly but largely ignored in the trace as they cannot directly affect values of local variables ## Test plan All old and new tests must pass
## Description This PR adds handling of aborts in traces. At the point when the code aborts an exception is thrown and the state of the program at this point can still be inspected:  ## Test plan All new and old tests must pass
## Description This PR finesses support for tracing macros, but due to how macros are (or rather are not) represented in the bytecode and source maps, this support has some limitations. In particular: 1. Currently we don't keep track of variable values inside macros 2. Macros and lambdas are not real function calls so when tracing execution of the macro, control flow may move somewhat unpredictably between the caller and callee 3. We track macro invocations using virtual frames but these are not necessarily pushed/popped symmetrically due to lack of precise information on when macro code starts and ends. As a result we keep limited number of virtual frames on the stack (max 2) - more detailed explanation can be found in code comments ## Test plan All new and old tests must pass
## Description This PR updates the extension's README file and finesses some checks and error messages issues when traces cannot be found or are empty. ## Test plan Tested manually
## Description This PR fixes trace ingestion for the case when global location is used in a write to address a problem reported in MystenLabs/sui#20727 ## Test plan Added a new test (all new and old tests must pass)
remove repetitive words --------- Signed-off-by: RiceChuan <lc582041246@gmail.com> Co-authored-by: stefan-mysten <135084671+stefan-mysten@users.noreply.github.com>
## Description
When displaying references to structs/enums, we need to store the index
path to a specific portion of the struct/enum so that we can display
only the "innermost" portion of the whole referenced values. Consider
the following code:
```move
public struct SomeStruct has drop {
struct_field: VecStruct,
}
public struct VecStruct has drop, copy {
vec_field: vector<u64>,
}
fun bar(vec_ref: &mut vector<u64>): u64 {
let e = vector::borrow_mut(vec_ref, 0);
*e = 42;
vec_ref[0]
}
fun foo(some_struct_ref: &mut SomeStruct): u64 {
let res = bar(&mut some_struct_ref.struct_field.vec_field);
res + some_struct_ref.struct_field.vec_field[0]
}
fun some_struct(): SomeStruct {
SomeStruct {
struct_field: VecStruct { vec_field: vector::singleton(0) }
}
}
#[test]
fun test() {
let mut some_struct = some_struct();
some_struct.struct_field.vec_field.push_back(7);
foo(&mut some_struct);
}
```
In `bar`, we want to display just the vector and its values even though
this vector is part of a larger nested struct. Previously, without index
paths being available, we would see the entire struct:
After changes in this PR, we will correctly only show the content of the
vector:
## Test plan
All tests (including the updated ones) must pass
## Description As it appears, we actually need full support for global values. At least one (and immediate) reason for it is that we need to support reading a value from global location where it has been deposited as a result of a native function returning a value. A particular example of this is related to dynamic fields where `dynamic_fields::borrow_child_object` returns a reference to a value that in some cases is NOT stored in a local variable before it is being picked up by a write to a different local. ## Test plan A new test has been added and all other existing tests must pass
## Description This PR adds support for viewing disassembly of Move source code when available. It does not use DAP's 'disassemblyRequest` feature as it does not seem mature enough to be used in our production setting. The particular problems discovered when trying to use it were: - difficulty to properly refresh the disassembly view when moving between disassembly located in different files - difficulty in controlling disassembly<->source transitions - difficulty in controlling how disassembly input looks like (in particular if trying to add "invalid" instructions surrounding the disassembly to satisfy number of instructions to be returned as per VSCode-specified requirements passed in `disassemblyRequest`) The gist of this solution is to maintain two views of the trace state, one reflecting "source" execution and one (optional), reflecting "bytecode" execution". The two main differences between these views are: - local variable display: "source" view uses source-level variable names and hides "artificial" variables (generated by the compiler to support enums/macros), whereas "bytecode" displays all variables and uses their bytecode-level names - a line of source/bytecode being executed at stop points Breakpoints are also handles separately for different views (i.e., source/bytecode-level breakpoints only work in frames that show source/bytecode, respectively). ## Test plan A new test for disassembly-level stepping, breakpoints and variable display has been added. All remaining tests must pass
## Description This PR adds the ability to start trace debugging a unit test with an assembly file (rather than a source file) in active editor ## Test plan Tested manually that one can start debugging with a disassembly file opened
## Description This PR adds support for missing source files - if a disassembled file for a given module exists, it will be used instead. ## Test plan Added a new test and all existing tests must pass
## Description This PR adds the ability to trace-debug traced obtained from the replay tool. The PR also includes a fix to bytecode map generation - location of function definition and and function name in the generated map was reversed for native functions. ## Test plan Added new tests mimicking the directory structure of replay tool's output. Also augmented a test checking correctness of bytecode map generation. All remaining tests should pass.
## Description This PR fixes a problem related to handling disassembly view. With the recent addition of an option to have only disassembled bytecode files (or a mix of source and bytecode files), mode switching was no longer 100% correct as it relied on the assumption that we have either source and disassembled bytecode or only source. Instead of one flag controling both mode switches (to/from source/bytecode) and debugger behavior in disassembly mode, we need two of them: - one to select internal data to be used when the mode switches - one to control the debugger behavior (as in only-bytecode situation there will be no actual mode switch) ## Test plan Test output was previously incorrect but has now been corrected and all tests must pass
## Description This PR adds support for trace debugger understanding how to read and use debug info (renamed source maps) introduced in MystenLabs/sui#21454 ## Test plan Added new test with debug info replacing source maps. All tests must pass --------- Co-authored-by: Mark Logan <103447440+mystenmark@users.noreply.github.com>
…ebugger experience (#21495) ## Description This PR adds source file information to debug info for the file that this info was generated for/from. Previously, dependency source files used by the trace debugger are those in the `build` directory, as they are easy to find and readily available. This however had two unfortunate consequences for the trace debugger user: - if during debugging, the user enters a function in a dependent source file, they will not have access to Move IDE's code inspection capabilities for this file (the reason for it is that source files in the `build` directory are not "buildable" by the compiler due to lack of the manifest file so the symbols required for on-hover, go-to-def etc. cannot be produced) - if the user uses go-to-def to go to a dependent source file to set a breakpoint there, the breakpoint would not trigger (the reason for it is that the dependent file reached this way is not the one in the `build` directory that is known to the trace debugger but rather the actual original dependent source file) Having the original dependent file path in debug info allows us to remedy these two shortcomings. Of course it is possible that this original dependent file path no longer exists, in which case trace debugger will default to using a file from the `build` directory. ## Test plan A new test for debug info v2 was added. All tests must pass. I also tested manually that both deficiencies were remedies when using trace debugger.
## Description
Adds compression to Move traces to make them smaller. It compresses
traces using the `zstd` compression, as in benchmarking/testing this
compression provided the best compression and speed for the generated
traces.
This also updates the trace file format to be streamed. Before the trace
format was a single json object something like
```
{
version: 1,
events: [
event1,
event2,
...,
event_n,
]
}
```
The new trace format is now a sequence of json objects
```
{ "version": 2 }
{ event1 }
{ event2 }
...
{ event3 }
```
This also updates the representation of Move values in the generated
traces to be typed.
The base commit is the core Rust changes
The second commit are the changes to the debugger to support the new
traces format (I'm a Typescript n00b so feel free to throw things at me
here @awelc).
The third commit is just updating snapshot files.
These commits can't really be broken up as they should really be landed
all together since they are both dependent on the trace format and
output.
And before you ask: yes, yes, delta encoding will be coming soon™️
## Test plan
Existing tests + added a couple smaller ones.
---
## Release notes
Check each box that your changes affect. If none of the boxes relate to
your changes, release notes aren't required.
For each box you select, include information after the relevant heading
that describes the impact of your changes that a user might notice and
any actions they must take to implement updates.
- [ ] Protocol:
- [ ] Nodes (Validators and Full nodes):
- [ ] gRPC:
- [ ] JSON-RPC:
- [ ] GraphQL:
- [X] CLI: Change in generated Move trace representation to be
compressed. Existing Move test traces will need to be regenerated in
order to me used.
- [ ] Rust SDK:
## Description This PR removes the ability to start debugging when bytecode file is open. The main reason for this is that the existing implementation needs to inspect all available trace files to find out which functions are available for debugging. This is: - quite costly as it needs to decompress ALL trace files - not super consistent with starting to debug when a source file is open (which selects test functions within the source file) Additionally, this was only possible when debugging unit tests and would not work for traced produced by replay tool, which could be potentially quite misleading to the user. We can always bring it back in the future if need be. Additional cleanups are marked as comments in the PR. ## Test plan Tested manually that everything works
## Description This PR fixes one problem introduced in a recent [PR](MystenLabs/sui#21908). Details in the code comments. ## Test plan Tested manually
…22048) ## Description This PR fixes a problem with setting breakpoints in disassembly files that do not have a corresponding source file. The problem was related to the fact that a no-source disassembly file is treated as a source file by the runtime if no actual source file exists. This was reflected everywhere but not in the code responsible for checking validity of breakpoints... ## Test plan A test verifying that no-source disassembly file is debugged correctly was modified. This test was previously incorrect actually (note that the stack never showed disassembly file frame) so in addition to adding breakpoint test, stepping through source/disassembly combination has also been fixed.
## Description What the title says. Here is how types are displayed now:  ## Test plan A test has been updated to include type args and its output reflects the new display strategy
…ndependent one (#22076) ## Description As it appears, mongodb's zstd library does not have bindings on some platforms (e.g. [this](MystenLabs/sui#22033) bug report) ## Test plan Tested that it works on Linux (when it previously did not)
## Description remove duplicate word in comment ## Test plan How did you test the new or updated feature? --- ## Release notes Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required. For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] gRPC: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: Signed-off-by: wangcundashang <wangcundashang@qq.com>
## Description This PR adds support for trace-debugging PTB commands. Currently it only supports debugging PTBs containing Move calls only. ## Test plan Removed old "replay tool tests" because: - they were created to only test directory structure created by the replay tool - were not actually generated by the replay tool but rather "mocked" from other existing tests to mimic the correct directory structure - these "mock" tests were becoming too annoying to update manually Added a new test actually generated from the replay tool. All tests must pass
…2372) ## Description As it appears with the recent change in how the external events test is called we exceeded Windows file path length limit. Hopefully this brings it back under
## Description This PR adds support for the remaining PTB tracing in the execution layer. I also modifies the debugger-side test to be more comprehensive and include (almost) all command (upgrade command is not include but it's the same as publish command). The reason for modifying the test rather than creating a new one is that these external tests take a fair amount of space due to all dependencies from replayed transactions that they require ## Test plan A test has been modified to reflect additional PTB commands. All tests must pass
## Description Breakpoints in the trace debugger previously only worked when continuing execution and not when stepping over functions that have breakpoints in them. This PR fixes this ## Test plan Modified breakpoints test to also check for breakpoints being engaged when stepping over functions. All tests must pass
## Description This PR fixes a problem related to re-using runtime-level functions to implement certain actions. For example, `stepOut` function was implemented by repeatedly calling `next` function. The problem was that these these re-used functions were also called from the adapter and where expected to send and even to the client informing it of the need to suspend execution in the debugger. Clearly this event should only be send once per completed action but because the functions implementing actions were re-used (in loops) an excessive number of such events would be send, slowing down the debugger or even stalling it permanently in extreme cases. The solution is to refactor action implementation to private internal functions that do not send events to the client, re-use these internal functions in the implementation, and create top-level public event-sending functions to be used by the adapter. This PR also includes a very small improvement to stack request handling that's unrelated to the main goal of this PR, and was included to avoid fragmenting the review process too much as the content of this PR remains rather small even with the two fixes included ## Test plan All existing tests must pass. Also tested manually to make sure that there is not excessive communication of events to the client
## Description This PR fixes a problem with replay and trace-debugging transactions that include calls into upgraded packages. The problem was related to modules being represented as belonging to the original package rather than the defining (upgraded) package. This was manifested in two places: - `OpenFrame` event in the trace - debug info The result of the former was that a function that did not exist in the original package could not be found during trace debugging as the debugger, seeing module name and original package ID, would look for this function in debug info representing a module from the original package, where this function indeed does not exist. The result of the latter was that debug info (key-ed in the debugger on the module name and package ID) for different versions of the module could not be distinguished in the debugger as all these debug info-s would contain original package ID ## Test plan Tested that upgraded packages are handled correctly, In particular, mainnet transaction with the following digest can now be trace-debugged correctly: `8jfAyyiQZG895NtjBjnb3eEjiwQtSwXi3FYHMGuJJZr6
## Description
This PR fixes a problem related to handling `Global` trace values in the
trace debugger. A bit of context first, the way the debugger handles
references is that it creates a chain of local variables (containing
references) that ultimately points to the location where the actual
values is stored. When reading/writing the value off a given local, this
chain is traversed and the original value is read/written (and it's the
only place where the things are updated - locals containing references
are not).
There are two types of reference chains:
- one that ends in a "regular" value (e.g., a struct)
- one that ends in a `Global` value
Global values are references that appear in Move code execution "out of
thin air" (e.g., a mutable reference is passed as an argument to the
top-level function). If not handled correctly, this may create a problem
when assigning values to globals.
In the debugger's runtime, global values are stored in in a map
(initially populated by `DataLoad` effect which initializes it from the
global's value snapshot). However, subsequently, there may be a
situation when a reference is assigned to a global in the trace. For
example:
```
{"Effect":{"Write":{"location":{"Indexed":[{"Indexed":[{"Global":16},0]},0]},"root_value_after_write":{"MutRef":{"location":{"Global":16},"snapshot": ...
```
What's important here in this trace snippet is that we are assigning a
reference to `Global16` (which was just modified) to a variable
containing a reference path to the same `Global16`. Prior to this PR, we
would process this trace effect directly and assign reference to
`Global16` to be the value of `Global16`, creating a global that
effectively points to itself (more precisely, to its location in the
map). When subsequently trying to read a variable pointing to this
global, we would end up in infinite recursion trying to access the end
of the reference chain.
This PR fixes this problem by always assigning a value to globals from
(already updated) snapshots), much like it happens when they are
initialized.
When working on this PR, a problem with the trace generation was
discovered, which was subsequently fixed in
MystenLabs/sui#22777. Variable values present in
the output of the new test added to this PR reflect the updated
(correct) global value tracking in the fixed trace generation problem.
While not strictly necessary it is thus probably best to land this PR
after the one containing the fix lands
## Test plan
Additional test was added that would fail to correctly display variable
value after assignment of a global to a an indexed global. All tests
must pass
## Description The long directory paths in the test files were causing Windows build to fail in some settings (prefix path to directory containing sui repository could take the whole path beyond its limit on Windows). This PR cuts these directory names (representing either txn digest or package IDs) to its last 5 characters ## Test plan All tests must pass
…984) ## Description This PR fixes two problems reported by early adopters: - toml parser used in the previous version was incorrectly parsing some Move manifest files (we now use a more modern and compliant instead) - reading a large trace into a string was previously violation JavaScript's max string size (we now read it directly into a string array) I also tagged along another fix here. Previously, when reading strings from the source file based on the location in debug info, we were doing this on per-character basis (having converted file content into a string), whereas locations in debug info are actually byte-based. Great thanks for @tzakian to actually find what's going on with this one! ## Test plan Manually tested that these fixes work. In particular a large trace generated by replaying the following transaction can now be trace-debugged correctly: CNiT7vcohmcLhCLKTTwLfiNDLsKLJCk2deCXph835fsf Modified a test to check that byte-based string reading fixes a problem with char-based reading if there are non-ascii characters in a source file
## Description This PR implements improvement to source-level debugging for replayed transactions. The limitation of the previous approach was that there was no way to source-debug upgraded packages. The reason for it was that we were relying on the build process to populate debug info with the correct package ID and there was no way to make this package ID represent upgraded `version_id` (we could only a package version to represent `original_id` of the non-upgraded package). In this PR we re-organize structure of the directory created by the replay tool to contain trace-debugging meta-data to make `source` directory a sub-directory of a package directory (named after package ID). We can then override package ID in the debug info based on the package ID taken from the directory name rather than relying on the build system to do it for us. ## Test plan Manually tested that source-level debugging works in the new setup
## Description Refactor coin registry implementation on top of #21400. This refactors the initial PR to reverse the internal dependency (all new currencies are initialized from `coin_registry` now). It also introduces Dynamic coin creation! Some of the PRs motivators: - Guaranteed metadata Discoverability & on-chain access - Decoupling of TreasuryCap <> Metadata management - Native supply modes (fixed currency, deflationary currency) - Dynamic coin creation (create a currency without requiring OTW). (e.g. LP<A,B>) -- - Usage examples are here: #23413 ## Progress - [x] initial layout - [x] internal verifier rule for `new_currency` #23377 - will be merged post review - [x] system object `0xC` - [x] adapter tests - [x] Move tests (almost everything covered) - [x] update examples + usage in system packages #23413 - will be merged post review ## Test plan How did you test the new or updated feature? --- ## Release notes Check each box that your changes affect. If none of the boxes relate to your changes, release notes aren't required. For each box you select, include information after the relevant heading that describes the impact of your changes that a user might notice and any actions they must take to implement updates. - [ ] Protocol: - [ ] Nodes (Validators and Full nodes): - [ ] gRPC: - [ ] JSON-RPC: - [ ] GraphQL: - [ ] CLI: - [ ] Rust SDK: --------- Co-authored-by: Bridgerz <bridgerzoske@gmail.com> Co-authored-by: Damir Shamanaev <damirka.ru@gmail.com>
## Description This PR fixes a problem with effects being generated outside of Move calls which resulted in a silent error being generated instead of an actual exception. This PR also adds more meaningful error messages rather then just reporting a generic exception ## Test plan Added a new test for silent error and adjusted existing tests to match output with more verbose exception information
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
awelc
had a problem deploying
to
sui-typescript-aws-kms-test-env
GitHub Actions
Failure
awelc
had a problem deploying
to
sui-typescript-aws-kms-test-env
GitHub Actions
Failure
Contributor
|
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Description
This PR migrates
trace-adapterTS package from the Sui repository so that it can be release in NPM (the original package is still in the Sui repository until we finish integration with the VSCode extension that is located in the same repository).The AI involvement in this PR is a bit complicated. The PR itself was mostly prepared by AI (other than removal of hard-coded paths from tests) but the only code that was really written by it was CI test integration in the ts-sdks repo. All other code for this package was written with very light AI-assistance (Cursor)
Test plan
CI tests should be enabled and passing
AI Assistance Notice