Direct answer
Reflecting the requested, acknowledged, cleaned, and recoverable states around cancellation in a local AI task experience requires staying strictly within what those labels express, without inferring or implying that the underlying process halts at the moment a cancellation control is pressed, since native termination behaviour is not addressed by the stated focus. Acknowledgement may be visible without equating it to immediate process exit.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Cancellation state transitions
- Cleanup evidence
- Next-task recovery
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
The four states identified—requested, acknowledged, cleaned, and recoverable—can be observed as a sequence of cancellation state transitions, each accompanied by cleanup evidence showing what was discarded or reset, followed by next-task recovery indicators that demonstrate the system can accept a new assignment; recording these items and comparing their presence across attempts provides a basis for evaluating the cancellation experience against the recorded evidence.
- Pin the official artifact revision.
- Record expected length and trusted digest.
- Check storage for temporary and update copies.
- Download to a temporary path and resume safely.
- Verify before final placement.
- Keep rollback and repair paths.
Failure patterns to prevent
- Hiding work after button press
- Saving cancelled output as final
Pitfalls in this experience include the interface hiding in-progress work immediately after a cancellation button is pressed and treating any partially produced output as a saved final result, both of which misrepresent the state to the user; release readiness should therefore be expressed only in terms of the recorded evidence listed above rather than inferred from absent confirmation of native termination.
Minimum reproducibility record
| Layer | Record |
|---|---|
| Device | Manufacturer, model, chipset, RAM class, operating-system build |
| Software | Application version and git commit |
| Model | Family, variant, revision, format, file length, hash, quantization |
| Runtime | Name, revision, requested backend, observed backend evidence |
| Workload | Fixture revision, input hash, prompt hash, output policy |
| Outcome | Completed, failed, cancelled, fallback, and privacy-safe diagnostics |
Release checklist
- ☐ The primary query is answered without an unsupported number.
- ☐ Every artifact and runtime is pinned.
- ☐ The representative task and failure policy are explicit.
- ☐ Lifecycle, cancellation, cleanup, and fallback are tested.
- ☐ User-content and network boundaries are documented.
- ☐ Result wording applies only to the recorded configuration.
- ☐ The page links to raw method or evidence when results are added.
Sources and related evidence
Chinese deployment and troubleshooting content is organized in the .奇连 AI 端侧专题.