Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#498 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
5/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
java, jupyter, kotlin
Ambito
testing-qa

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Kotlin
Stelle
33
Fork
27
Merge medio
3g 21h
PR unite (30g)
88

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di UnitTestBot/usvm

Tutte le issue di UnitTestBot/usvm

Issue simili

Altre issue su Kotlin

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.