Completed foundation and current continuation
The delivered clean baseline remains completed. Continue the full property-aware roadmap in #345, including #395 and #396. Reuse current usvm-ts-pbt/usvm-ts-fast-check module boundaries; no legacy custom concrete interpreter is reinstated.
The original delivered scope below is historical context; new acceptance criteria are owned by the linked open issues.
Original delivered scope (historical)
Goal
Establish a clean and reproducible baseline for the new fast-check integration on the current USVM codebase and the native JacoDB TypeScript frontend.
Why
The existing TS PBT branch contains the historical custom generator, concrete interpreter, and hybrid prototype. The new implementation should start from the current upstream code and port only the infrastructure required by the new property-based architecture.
Scope
- Use the current USVM upstream branch as the implementation base.
- Integrate with the current JacoDB
neo TypeScript frontend.
- Configure the native
ts-frontend without ArkAnalyzer.
- Restore only the minimal
usvm-ts-pbt module and build wiring required for subsequent issues.
- Add a smoke test that loads TypeScript into EtsIR and verifies source origins.
- Document the required JDK, Node, Gradle, and frontend configuration.
- Keep the historical TS PBT branch unchanged.
Do not port InputGenerator, the existing PbtPhase, the custom Shrinker, or EtsConcreteInterpreter as the foundation of the new pipeline.
Definition of Done
- The new module builds against the current USVM and JacoDB
neo code.
- The native TypeScript frontend is used without an ArkAnalyzer dependency.
- A smoke test verifies that a TypeScript method and its
EtsSourceSpan are available in EtsIR.
- Focused module checks pass from a clean checkout.
- Reproducible build and test commands are documented.
- No legacy custom PBT execution code is introduced.
- The implementation is delivered in a dedicated PR linked to this issue.
Completed foundation and current continuation
The delivered clean baseline remains completed. Continue the full property-aware roadmap in #345, including #395 and #396. Reuse current usvm-ts-pbt/usvm-ts-fast-check module boundaries; no legacy custom concrete interpreter is reinstated.
The original delivered scope below is historical context; new acceptance criteria are owned by the linked open issues.
Original delivered scope (historical)
Goal
Establish a clean and reproducible baseline for the new fast-check integration on the current USVM codebase and the native JacoDB TypeScript frontend.
Why
The existing TS PBT branch contains the historical custom generator, concrete interpreter, and hybrid prototype. The new implementation should start from the current upstream code and port only the infrastructure required by the new property-based architecture.
Scope
neoTypeScript frontend.ts-frontendwithout ArkAnalyzer.usvm-ts-pbtmodule and build wiring required for subsequent issues.Do not port
InputGenerator, the existingPbtPhase, the customShrinker, orEtsConcreteInterpreteras the foundation of the new pipeline.Definition of Done
neocode.EtsSourceSpanare available in EtsIR.