UnitTestBot / UnitTestBot/usvm
[TS Calls][Research] Capture stopped-path frontiers for article experiments
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 33
- Forks
- 27
- Avg merge
- 4d 3h
- Merged PRs (30d)
- 15
Description
Follow-up to #364. Part of #360. Optional research support for #385.
Goal
Capture stopped-state information only if an identified experiment requires data unavailable from existing unknown-call decision events.
Start condition
First name the consumer, the research question and the fields it cannot obtain by aggregating #364 events. Basic call counts, model decisions and stop-site frequencies do not justify a new snapshot API. If no concrete consumer needs a snapshot, leave this work deferred.
#364 provides decision callbacks only. It deliberately provides neither persistent path history nor stopped-frontier snapshots.
Scope
- Add opt-in capture orthogonal to the fallback setting only for the demonstrated consumer.
- Capture detached data rather than retaining live TsState/TsContext objects or allocation counters.
- Include the minimum stopping event, relevant signatures/statements and constraint status needed by that consumer.
- Add history or textual constraints only when explicitly required; do not serialize the entire engine state.
- Prefer experiment-owned aggregation/storage over changes to generic usvm-core primitives.
- Keep captured stopped states separate from completed execution states and generated tests.
- Define bounded retention and ownership with the consumer.
Definition of Done
- The consumer and required information are documented before implementation.
- Capture does not alter exploration decisions; observer failure isolation and detached ownership have focused tests.
- A stopped snapshot is never counted as a completed/replay-confirmed result.
- Deliver only the scoped research support in a separate PR when needed.
This issue does not block #365/#366, the census, or baseline evaluation in #385. It becomes a prerequisite only if the chosen measurement demonstrably requires it.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files or tests are named. First identify a concrete consumer, research question, and fields unavailable from #364 decision events; if none exists, leave the work deferred. For an approved scope, define detached stopped-state ownership and bounded retention, then add focused tests for observer failure isolation, decision preservation, and separation from completed or replay-confirmed results.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kotlin
- Domain
- devtools, testing-qa
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100