---
id: OV-C6-POS-001
title: "Failure reason classified by fixability and stored as latest only"
product: mobile
module: offline-visitation
type: integration
priority: P1
risk: high
status: draft
automationStatus: planned
sourceRefs:
  tsd: PK144
  tsdSection: C6
  tsdScenario: C6.1
  prd: PK144
  jira: null
automationRef: null
lifecycleStatus: active
lifecycleReason: "AI-generated draft from PK144 TSD C6.1; pending QA review."
lastReviewedAt: null
reviewedBy: null
supersededBy: null
duplicateOf: null
blockedBy: null
preconditionRefs:
  - PRE-OV-gagal-kirim-has-items
tags:
  - mobile
  - offline-visitation
  - perlu-dikirim
  - sync
  - pk144
  - staging
---
## Objective
Verify failed submissions are classified by fixability and that only the latest failure reason is stored.

## Preconditions
- See [[PRE-OV-gagal-kirim-has-items]]
- And an item has failed to sync

## Steps
1. Trigger each failure condition and inspect the stored classification

## Expected Result
- Then fixability is classified per the contract: retryable-not-editable (no internet, unstable timeout); fixable (missing mandatory value, invalid format, missing required photo); not-fixable (duplicate submission, PJP target achieved, same visitation completed on other device); not-fixable-by-employee (server 5xx, expired/invalidated reference data)
- And the system stores the LATEST failure reason, replacing (not appending) the previous one on a subsequent failure
- And the original captured submission data is preserved unchanged

## Source Traceability
- TSD: PK144
- Section: C6 - Failed Sync Detail, Modification & Resync
- Scenario: C6.1 - Failure reason classification & storage
- Acceptance Criteria: M.28 AC1–AC4

## Evidence Required
- Stored failure-reason field per condition; original payload diff = none.

## Notes / Gaps
- Testing Concern #23 (Critical): the "Fixable" flag backend contract per failure reason must be defined to assert classification deterministically.