# API practice feedback

The reference solution is `offline/worked-example.py` plus `offline/contract.py`. A completed non-refused result passes the release gate; partial, refused, failed and invalid results do not. Passing this gate authorizes no downstream action and does not verify factual accuracy.

## Expected outcomes

| Fixture | Status | Release | Usage |
| --- | --- | --- | --- |
| complete | complete | true | supplied counts |
| cancelled | partial | false | unknown |
| incomplete | partial | false | supplied counts |
| refusal | refused | false | unknown |
| failed | failed | false | unknown |
| unterminated | partial | false | unknown |
| malformed | invalid | false | unknown |
| unsupported | request rejected before reduction | none | none |

The deliberate starter bug is `bool(result['text'])`. It accepts several bad outcomes. Reference tests should pass; learner tests should fail until the guard changes. Do not mark deliberate failures as a package defect or disguise them as successful execution.


Do this task before opening the feedback. Different wording can meet the same criteria.
