Train
Minimal slug limit
Boundary behavior, public-call compatibility, and production-scope discipline.
Reference corpus · 21 calibrated cases
Cases designed to expose weak evidence.
Every case carries observable requirements, an objective verifier, explicit resource bounds, and known-good, known-bad, and adversarial variants. The corpus demonstrates the contract; it does not define Skivolve’s domain ceiling.
Composition
Ten train cases. Eleven validation cases. Two disciplines.
The split is fixed in the suite manifest. Engineering contributes five train and nine validation cases; testing contributes five train and two validation cases.
14engineering cases
7testing cases
10train cases
11validation cases
Engineering track
Implementation evidence across real failure modes.
Train
Symbol verification
Local API contracts, cached token behavior, and dependency restraint.
Train
Secure archive restore
Path containment, resource bounds, hostile member types, and atomic publication.
Train
Representative performance
Correctness-guarded workload measurement and evidence against decorative optimization.
Train
Public API compatibility
Observable signature, error, and consumer behavior across a public change.
Validation
Concurrent store
Shared-state ownership and schedule-sensitive correctness.
Validation
Transactional event intent
Atomic state and delivery intent under partial failure.
Validation
Behavioral subtyping
Substitution contracts rather than inheritance-shaped code reuse.
Validation
Knowledge boundary
Authority, locality, and duplication decisions under change pressure.
Validation
Domain simplicity
Direct design and earned complexity for domain behavior.
Validation
Compatibility decision
Public-contract conflicts, migration ownership, and safe ask-before-change restraint.
Validation
Root-cause diagnosis
Concrete causal evidence, reproducible checks, and honest remaining gaps.
Validation
Surgical plan
Proportional implementation scope, precise boundaries, and native verification.
Validation
Evidence gap
Source-bounded decisions, material counter-evidence, and resolving next checks.
Testing track
Tests treated as falsifiable engineering evidence.
Train
Oracle sensitivity
Whether the test rejects the targeted defect instead of merely executing code.
Train
Parser boundaries
Valid and invalid partitions, limits, and adversarial input handling.
Train
State-machine sequences
Transitions and invariants across ordered behavior.
Train
Real boundary fidelity
Production-compatible integration instead of a configured double proving itself.
Train
Concurrency flake control
Deterministic coordination, useful failure artifacts, and visible instability.
Validation
Legacy characterization
Observed behavior separated from contractual, harmful, and unknown behavior.
Validation
Event idempotency
Duplicate delivery and retry behavior under a durable effect contract.
Case acceptance
An oracle must prove it can fail.
Known-good
Demonstrates that the verifier accepts an implementation satisfying the case contract.
Known-bad
Demonstrates that the verifier rejects the named defect the case intends to detect.
Adversarial
Challenges identity leakage, evaluator branching, environmental shortcuts, and shallow assertions.