Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#498 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
5/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
java, jupyter, kotlin
Área
testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Kotlin
Estrellas
33
Forks
27
Merge medio
3 d 21 h
PR fusionados (30 d)
88

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de UnitTestBot/usvm

Todos los issues de UnitTestBot/usvm

Issues similares

Más issues de Kotlin

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.