Direct answer
A safe language-pack update is a transactional replacement workflow, not “download over the existing file.” First establish what the product calls a pack and what identity fields are actually available: language direction, revision, source, format, expected size if configured, and digest only if a trusted digest exists. `COVE-DOWNLOAD-01` describes a downloader that stages bytes in a temporary file, can request range resumption, may verify SHA-256 when configured, and renames after completion. `COVE-MODEL-02` warns that the current Cove Gemma E2B digest field is empty, so a verified hash cannot be claimed for that configured artifact. These facts guide testing; they do not prove a particular app distributes language packs or that every pack has a manifest or checksum. Keep the currently usable asset intact while a candidate downloads. Record which revision the active task uses, where the candidate is stored, and how the app avoids opening half-written bytes. A completed HTTP transfer is not the same as a format-valid pack, a loadable model, or a successful translation task. The application should expose distinct states such as not present, downloading, staged, validation failed, ready to activate, active, and rollback pending only if those states exist in its implementation. Do not invent version labels or integrity indicators for assets that do not expose them. Validation must match the available trust evidence. If a trusted digest is part of the manifest, verify exact bytes against it before activation. If no digest is configured, say only what was actually checked—such as transfer completion, byte count, or successful runtime open—and label the remaining identity limitation. A matching filename is not identity evidence. A language code in a screen does not establish the pack’s exact model revision, supported direction, or offline behavior. Use a harmless fixed text fixture after activation, with connectivity disabled only after setup, to test the declared path. Design interruption points deliberately: low storage, process death during transfer, network change, HTTP error, failed digest, invalid format, activation crash, and user cancellation. A candidate failure should not corrupt the active pack or delete user transcripts, photos, notes, or settings. Use a staged path and an atomic activation marker appropriate to the storage design; make cleanup idempotent. If background work is used, follow its actual lifecycle contract and do not claim guaranteed completion. On restart, reconcile database state with files instead of assuming a prior in-memory state survived. Rollback is not simply renaming any old file back. Retain the previous known-good asset only according to product storage policy, track which one is active, and test the task after switching back. Do not mix a tokenizer/configuration from one revision with bytes from another. If the app cannot restore the previous asset, tell the user what action is available and whether a network is needed. Preserve user-created language preferences separately from asset bytes. Use a test matrix that distinguishes transfer, integrity, runtime load, and user task. Record app build, source/build variant, asset identity fields, storage path class, network condition, interruption point, validation result, activation, rollback, and sample output properties. No benchmark result is required for this guide: it explains method, not update speed, reliability percentage, pack coverage, or broad device support. This separation lets a maintainer say exactly which transition was verified and keeps a language-pack refresh from silently destroying a working offline path.
A candidate language asset arrives while a traveler still needs the active pack
The app has an active asset and a proposed replacement. A transfer is interrupted once, and the team must decide whether to resume, reject, or activate the candidate without losing user history.
Decision
Download to a separate staging location, validate only with evidence the manifest/configuration provides, preserve the active asset through the switch, and verify a task before claiming readiness.
Expected outcome
The test record distinguishes bytes received, validation, activation, and task behavior; failure leaves the prior path and user-created data unchanged.
Evidence to collect
The claim becomes reviewable only when the following evidence is attached to the same artifact and test run:
- Old and new pack manifests
- Verification and switch record
- Rollback test
A completed byte stream is not enough. Final placement, integrity, runtime load, and recovery must also pass.
Implementation workflow
- Record pack identity and active revision. Capture every available identity field and note which asset revision is active. Mark missing revision, digest, or direction metadata as unknown rather than inventing a manifest.
- Stage the candidate separately. Write temporary bytes away from the active artifact, handle partial transfer and process restart, and ensure the UI does not call a candidate ready before the configured checks finish.
- Validate bytes and loadability. Verify a trusted configured digest when available. If none exists, report the checks that were performed without calling the file cryptographically verified. Open through the actual runtime before activation where design permits.
- Switch with recoverable state. Use an explicit active-revision marker and a documented commit boundary. Preserve the last usable asset within storage policy and keep history, settings, and exports separate.
- Inject failures and exercise rollback. Interrupt transfer, validation, rename/activation, and first task. Restart, reconcile on-disk state, restore the previous asset when supported, and run a fixed harmless fixture again.
Keep each transition observable. A failure should identify the stage, artifact, runtime, and recovery action without logging private user content.
Acceptance criteria
- Transfer completion, identity/integrity checks, runtime load, activation, and translation-task result are distinct observations.
- A failed or interrupted candidate cannot overwrite the active asset or delete unrelated user-created content; restart recovery is tested.
- The report states which identity evidence exists and does not claim pack distribution, hash verification, language coverage, or universal readiness without proof.
Decision table
| Dimension | Choice or evidence | How to interpret it |
|---|---|---|
| Overwrite active file in place | Single-path replacement | A failed write can destroy the usable asset and makes recovery difficult. |
| Separate staging then commit | Candidate/active transaction | Preserves a clear boundary for validation and rollback if implemented and tested. |
| Download then label ready | Transfer-only state | Does not establish artifact identity, format validity, runtime load, or completed task. |
Failure patterns to prevent
- Overwriting the active pack
- Mixing pack revisions
Also prevent silent fallback, unpinned artifacts, missing cancellation, and conclusions that combine unlike configurations. Store unsuccessful runs alongside successful ones.
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 端侧专题.
Frequently asked questions
Does a completed download prove the new pack is valid?
No. It shows bytes were transferred according to the observed path. Identity, configured integrity evidence, file format, runtime opening, and a representative task are separate checks.
Can I claim the pack was verified when no digest is configured?
Not cryptographically. Report the exact checks performed, such as transfer completion or runtime open, and state that an expected trusted digest was unavailable.
Should an update remove the old asset immediately?
Only if the product policy permits it and recovery behavior is understood. Test a candidate failure and rollback first, while keeping user-created records separate from shared model assets.