Common regression connections

한국어 · English

regressions.json is the finite registry for five current Jaekit invariants. Each route names its product consumers, public contract, general property, original example, related input families, supported boundary, selected regression, and public follow-up when unresolved. It is reviewed source, not an inference from private goal records. Changes that introduce another consumer of I1–I5 must add that route and its protection or explicit gap.

protected means that the named property has the listed regression connected to the common verification group. It does not claim that every possible input or every property of that source file is covered. gap is an unresolved property and is never counted as protection. Existing protection must not be demoted merely to avoid a failing regression. The integrated registry connects the producer, observation and scanner fixes to their actual regression selectors. Stable route IDs retain their original names (including a historical -gap suffix); the status field is authoritative. Issue links preserve the source of each correction and do not by themselves establish protection. protected still describes the listed property and selection, not a recorded pass of the combined tree.

The commands below run from a Git source checkout of this repository. The release archive ships this contract and regressions.json but not the tools/ they name; use a source checkout of the same version to run them.

Run python3 tools/regression_map.py --format json to validate the registry. The result says assurance: selection-only. It checks public source paths, explicit test definitions and the supported unconditional discovery statements in tools/verify.py. Sources, bases and checks must be files tracked by Git in that checkout; repository metadata under .git/, root docs/ goal documents and untracked files are refused, and history is not read, so a full and a shallow clone give the same result. A commented name, absent test, unselected file, or unsupported selection control flow does not establish selection. A build-only with body that could end or skip the rest of its group, such as by return, raise, a branch or an exit call, is unsupported control flow. A Python selector must name a class or method that the common unittest loader collects from the selected file; a plain class, a mixin alone, a test case without tests or a module that fails to import is not selection. Collection imports the module but does not run its tests; unittest execution is checked separately. Group-body parsing does not prove the main dispatcher or CI wiring: the existing tools/workflow-checks/test_verify.py and test_repository.py cover those connections. The parser is intentionally narrow: when the verification implementation changes beyond its supported statements, update and verify the selector parser or report that it cannot establish the connection.

This command does not execute a test or attest remote CI. The shared documentation group loads the registry regression through tools/workflow-checks/test_regressions.py; the existing Go group executes the protected Go and shell suites. Run python3 tools/verify.py on the actual integrated tree to execute both groups, including the real product regressions. A synthetic invocation fixture proves selection and failure forwarding only. A test file's existence, a selection-only report, a product test result, and a remote CI result are distinct evidence.

For the shared full Go test command, verification reads the selected Go tool's effective GOFLAGS, including persistent configuration. It reports and removes test restrictions (run, skip, list, fuzz, enabled short, and a nonpositive count, including their test. forms) from that child process only. Other flags keep their values and Go quoting; shell settings and persistent configuration are never rewritten. Uninterpretable flags and compile-only or substituted-execution modes cannot establish full execution and stop verification. Explicit selection restrictions in the shared command are refused by the static registry reader. Intentional per-selector regression commands keep their existing selection behavior, and documentation-only validation does not require Go.

Go selection accepts supported package-level test declarations after distinguishing comments, strings, identifiers and declaration boundaries. A test needs an ASCII Test name whose following character is not lowercase, a non-generic signature with one pointer to the imported testing.T type, no result values and a body. This is a finite lexical reader, not a Go compiler or proof that the package builds. The go_selection report describes its platform-independent scope: files without platform filename suffixes or build directives. Known GOOS/GOARCH filename conditions and //go:build or legacy // +build headers are explicitly unsupported; the reader does not guess host settings, configured tags or toolchain conditions. For the checkout-root ./... package walk, hidden and underscore-prefixed directories, testdata, descendants of vendor, nested modules and descendant directory symlinks are excluded. The vendor directory itself and a checkout reached through a host directory alias remain supported. Conditional or otherwise unsupported selection returns a reason instead of protection. The separate Go-group execution regression compares these boundaries with real Go discovery; the static reader and documentation group do not launch Go.

Python collection uses the common command's actual discovery start directory, file pattern, optional top-level directory and repeated -k filters. Start and top-level directories must remain inside the checkout. Positional and standard short/long discovery options are supported; unknown options are refused. -k uses unittest's case-sensitive name matching, with substring matching when there is no * and alternatives for repeated filters. The actual pattern reaches load_tests, and each collected class or method is bound to its defining source file so a same-named selector in another module cannot substitute for it. Empty, excluded or unavailable collection does not establish protection. Collection may import modules and call discovery hooks but never executes test bodies; normal intentional per-selector execution remains separate.

For an explicit prior public registry snapshot, python3 tools/regression_map.py --previous <public-snapshot.json> --format json reports removed or demoted protection, scope edits, and narrower or replaced check sets. changed_invariants lists invariants whose property or basis changed, or that were added or removed, and affected_routes lists every route under them. It does not fetch Git history or infer a prior private goal. Record why a replacement preserves the property and link the replacement regression in the source change. The comparison marks changes for review; it does not judge semantic equivalence automatically. Changing a goal or branch name is not a reason to remove a route.

When integrating a fix, preserve the stable route ID, update its sources and selectors, and distinguish the original case from its generalized input family. For every protected route, execute its normal and relevant violation/error/unsupported fixtures. I2 needs the producer-to-Core current and baseline boundary; I3 needs uncertainty and identity at the final consumer; I4 needs actual selected launch paths; I5 needs both normal scanner sources and forbidden inputs. Capture the tested commit/tree and result in the change's verification record. Results from individual branches do not describe a combined tree until that tree has been tested.

The registry adds no installed tool, network, model, history download, or private-record requirement. Documentation-only verification retains its existing dependencies. Public synthetic fixture treatment is local to the relevant scanner; it is not a repository-wide instruction to split strings or exempt filenames. Longer-term defect recurrence and execution cost remain follow-up observations, not claims made by this registry.

The integrated additions remain within I1–I5: explicit retention inputs protect I1; result adapters, saved findings and evidence-reporting contracts protect I2; bounded archive inputs and explicit Spec observation boundaries protect I3. Their rows state which checks use actual local processes and which validate synthetic document/protocol fixtures. These additions do not broaden the registry into every behavior of those features. Existing protected route IDs, scopes and regression selectors are retained. Run the combined tree through the shared entrypoint before describing the integration as verified.

The Windows release additions also stay within I1–I5. windows-archive-consumer-contract (I3) protects the structural Windows ZIP check before publication and the publication gate's acceptance link in the release notes; the installer's own package check runs only in the release workflow's Windows job, as its boundary states. release-checker-import-boundary (I3) protects code that imports the release acceptance checker directly from running caller modules, through one direct-import process with synthetic archives.