[Calls] Ship reusable class discovery and re-audit the same frozen 200-class population

未關閉
  • 哪裡不對？
#498 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
5/5
預估耗時
一週以上
新手友好度
5/100
Issue 類型
功能
描述清晰度
需要釐清
活躍度
活躍
技術堆疊
java, jupyter, kotlin
領域
testing-qa

研究方向

This is a design-level integration gate, not a starter task: it asks for reusable class-discovery tooling that reproduces a sealed 200-class ledger and re-runs 48 selected classes with frozen domain policies. The payload points at no specific source file or test to open first, and the referenced local evidence (selection-ledger-v7.json, V7_INFRASTRUCTURE_FRONTIER.md) lives outside the repository. Done would mean all 200 v7 decisions reproduced with stages recorded, which is multi-week work tied to open related issues and PR 479.

由索引模型根據 Issue 內容生成。

描述

Part of https://github.com/UnitTestBot/usvm/issues/483.

Observed boundary

Priority: P0 foundation / final integration gate. all 200 decisions and reproducible expansion of admission.

Preserve sealed v7. Do not assume fixing a first gate admits a class or that all 200 are executable supported programs.

Implementation scope

Promote the current experiment-only source-surface/domain discovery into reusable tested tooling, reusing Calls catalog/prepare/preflight/cell contracts. First ship the current supported subset and its exact diagnostics; capability extensions can then land independently. Re-run the same 48 selected classes and 152 preordered reserves after each relevant milestone, with unchanged source identities/full member surfaces and explicit frozen revised domain policies. Keep first-gate and later failure stages separate.

Acceptance criteria

  • Baseline tooling reproduces all 200 v7 decisions with class identities, ordering, first diagnostics and explicit preparation/native/IR/engine/replay stages.
  • Each subsequent audit records before/after gates, next newly exposed limitations and exact supporting revision/tests; rejected cases remain in the ledger.
  • No HashMap/HashUtils replacement corpus, function/member dropping or result-driven specialization is used to inflate admission.
  • A final supported representative pilot uses class-only native replay coverage, all four profiles and 30/120s with preserved failures and actual search/extraction/replay accounting.
  • The task can ship baseline discovery before the other tasks; the final readiness claim waits for the evidenced supported population and protocol checks.

Existing work to reuse or coordinate

Evidence and delivery rules

Use the frozen v7 200-class ledger and the source-linked reproducer; do not overwrite sealed experiment output. Reuse existing loaders, domain projection, source instrumentation, candidate/replay contracts and bounded observations. Keep original class members and independently frozen domain policies. Run focused source/native checks for the changed contract and leave broad suites to CI; unsupported and newly exposed later gates remain recorded.

Local evidence: iccq2026-paper/experiments/class-coverage-round-robin-20261002/real-class-campaign-20261014/{original/selection-ledger-v7.json,V7_INFRASTRUCTURE_FRONTIER.md} and real-class-machine-diagnostic-20261014/revised-protocol-v8/README.md.

主要語言
Kotlin
星號
33
分支
27
平均合併
2 天 19 小時
30 天內合併 PR
76

環境準備

這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

UnitTestBot/usvm 的其他 Issue

查看 UnitTestBot/usvm 的全部 Issue

相似的 Issue

更多 Kotlin Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。