[Epic][TS Calls] Introduce explicit fallback policies and partial semantic models
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- kotlin, typescript
- Ambito
- compilers
Direzione di ricerca
Begin with blocking issue #383 and the simplification in PRs #377/#380, then trace the TsInterpreterObserver and EtsIR interpreter contracts. Review the dependent work in #365, #366, #367, #368, and #385; completion requires the documented boundary, justified model set, focused behavior tests, and replay-based evaluation described in the definition of done.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Goal
Make unknown-call behavior explicit and evaluate its effect on symbolic exploration and concrete reproducibility.
Scope
- Use the current USVM and native JacoDB TypeScript frontend.
- Reuse one typed unknown-call dispatch boundary.
- Select an immutable set of semantic models independently from STOP_PATH or FRESH_SYMBOLIC_RETURN fallback.
- Support guarded normal/exceptional successors, state changes and aliases, with an explicit residual domain routed to fallback.
- Execute source models through the normal EtsIR interpreter; use intrinsics for engine primitives unavailable or inefficient in ordinary TypeScript.
- Observe decisions through TsInterpreterObserver. Persistent path history and stopped-state snapshots are not production requirements.
- Select a small justified model set using a real-project census and existing-model audit, then compare policy/model configurations with real TypeScript replay.
First-priority gate
#383 is P0 and blocks completion of #365/#366 and further integration using their old contract. Reuse the simplification already in PR #377/#380; do not create a duplicate implementation.
A model needs an ID, a declarative target and execution. Do not reintroduce separate backend/registration/descriptor layers, redundant implementation-kind/precision values, manually maintained model versions, or a generic plugin framework.
Work
- Completed foundation: #361, #362, #363, #364.
- Priority simplification gate: #383.
- Model integration: #365, #366.
- Independent census and audit: #367, #368. Their preparatory work may continue while the gate is resolved.
- Final policy/model experiment: #385. Add bounded family implementation prerequisites only when the census justifies them.
- Optional research-only frontier capture: #373, only when a concrete consumer needs more than existing decision events.
Definition of Done
- All relevant unknown calls use one documented boundary or have an explicit exclusion.
- Fallback semantics are consistent; opaque returns do not claim to model arbitrary side effects or exceptions.
- Built-in model applicability depends on sufficient target/receiver evidence, not a method name or one possible type.
- Unsupported domains retain their configured fallback; trusted models have focused guard, alias and exception tests.
- One useful intrinsic and one ordinary TypeScript model demonstrate the two implementation mechanisms.
- Decision observation does not change exploration or require generic core-state changes.
- A frozen model set and development/held-out evaluation in #385 measure real replay-confirmed targets on comparable budgets.
- Mandatory language semantics and correctness fixes remain identical between experimental profiles.
- Negative results and unsupported cases are reported.
PBT generation, hybrid scheduling, LLM/MCP, a complete standard library and speculative research-state APIs are outside this epic.
- Lingua principale
- Kotlin
- Stelle
- 33
- Fork
- 27
- Merge medio
- 4g 3h
- PR unite (30g)
- 15
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di UnitTestBot/usvm
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 45/100
UnitTestBot/usvm#388 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
UnitTestBot/usvm#384 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
UnitTestBot/usvm#382 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
UnitTestBot/usvm#379 ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
UnitTestBot/usvm#373 ·
Tutte le issue di UnitTestBot/usvm
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
bitcoindevkit/bdk-ffi#1125 ·
-
Issue: Bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 91/100
OpenAPITools/openapi-generator#24978 ·
-
helsemelding-json-schema json-schema-core
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
contributor: external needs review
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100