Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#498 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
5/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Active
Stack technique
java, jupyter, kotlin
Domaine
testing-qa

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Kotlin
Étoiles
33
Forks
27
Merge moyen
3 j 21 h
PR mergées (30 j)
88

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de UnitTestBot/usvm

Toutes les issues de UnitTestBot/usvm

Issues similaires

Plus d'issues Kotlin

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.