Bug report details: six recorded examples
The downloads contain six original inputs, their expected labels and one recorded API observation per input revision. Disagreements stay visible.
Jev bug reproduction completeness
Check a bug report for missing reproduction details
Paste a report to check whether it describes the steps and what happened. Compare complete reports, missing details and contradictions before following up with the reporter.
bug reproduction completenessLive API
The decision
What the decision checks
A report can sound serious and still omit the information needed to investigate it. This check distinguishes missing actions from a missing result so a follow-up can ask for the useful detail.
The source-linked Jevidence project reviews bug-report evidence. Our text exercise labels the completeness of a description. A Reproducible description label does not mean someone ran the steps, confirmed the defect or identified its cause.
This is an independently authored text demonstration inspired by the linked X discussion. Its rules and synthetic inputs are ours. It does not reproduce the author’s application, verify reported outcomes, or perform an external action.
Try the example in four steps
Use the sample to understand the rule, then test your own input for bug report details.
Add the information to check
Paste a report to check whether it describes the steps and what happened.
Confirm the question and labels
Open the decision rules and keep the intended distinction between Reproducible description, Missing steps, Missing result, Not a bug report, Review. Edit the choices only when testing your own rule.
Run the decision
Use a sample first, then try your own input. Compare the selected label with the other returned probabilities.
Review the next step
Review Missing steps, Missing result, Review before using a result. The label is a decision about the supplied information, not an executed action.
Our API test
Recorded API observations
| Original input | Observed label | Leading probability |
|---|---|---|
| Clear export failure | Reproducible description | 100% |
| Failure alone | Missing steps | 100% |
| No outcome | Missing result | 99.0% |
| Feature idea | Not a bug report | 100% |
| Contradictory account | Review | 99.0% |
| Required start included | Reproducible description | 100% |
These are six original synthetic inputs, tested once per request revision. The percentage is the leading option probability, not measured accuracy. Authored expectations and any disagreements remain in the downloadable evidence. 6 of 6 results matched the authored fixture expectations.Verified
Understand the results
Using the result in your application
The single-request SDK runner uses your private TYPESAFE_API_KEY. The offline consumer reads saved observations, checks request hashes and prints a pending output. It does not call the model or change any external system.
Replay options
Inspect saved outputs or request a new decision
View the code example
# Offline: inspect the downloaded saved observations. No API key is needed.
python preview_choice_workflow.py samples.json saved-api-results.json
# Optional live request: install the SDK and set TYPESAFE_API_KEY privately.
npm install @typesafe-ai/sdk@0.6.0
node run-choice-sample.mjs samples.json case-1
# The live response prints to the terminal; it does not update saved-api-results.json.Where this decision fits
Useful scope
- Preparing a targeted follow-up to a bug reporter
- Separating feature ideas from behavior reports
- Checking that starting conditions and actual results are recorded
Outside this demonstration
- Running the reported steps
- Confirming that a defect exists
- Assigning severity, blame or a root cause
Using this example
The input contract and these limits define what the result means.
Does Reproducible description mean the bug is confirmed?
No. It means the report describes concrete steps and an observed result. A tester still needs to run those steps in the relevant environment.
Is an expected result mandatory for this label?
This particular contract checks actions and actual result. An expected result is often useful, but it is not silently added as a requirement for the saved label.
Does the leading probability measure accuracy?
It describes the distribution over the supplied choices for this request. These six synthetic examples are functional tests with authored expectations, not a production accuracy benchmark.
Will a result change an external system?
No. The demo displays a label and distribution. The downloadable consumer produces a pending preview packet. Application code and a separate authorization policy would control any real action.
Test a different input
Edit the example above to see how a changed fact affects the decision, or open the Playground for another task.