Offline Visitation — Testcase Report

103

testcases

C-sections

critical risk

high risk

103

planned auto

preconditions

Sections — what each C-group tests

Each C-section is a capability area from the TSD. Product shows whether it runs on web (CP), mobile, or API.

Section	Capability	Product	Testcases
C1	Download Preparation, Download Center, Storage Tiering & Bundle Lifecycle	mobile	27
C2	Visitation Flow: Fully Online & Fully Offline	mobile	12
C3	Offline Submission & Gagal Kirim Queue	mobile	8
C4	Sync Strategy: Auto & Manual	mobile	11
C5	Expiration & Manual Deletion	mobile	6
C6	Failed Sync Detail, Modification & Resync	mobile	9
C7	Network Quality Detection & State-Driven Drawer Mechanics	mobile	8
C8	Mode Luring State Management	mobile	8
C9	Multi-device Race Conditions, Persona & Target Rules	mobile	7
C10	Cross-cutting Edge Cases & Failure Recovery	mobile	7

Coverage by C-section

C10

Distribution

Priority P0 / P1 / P2 / P3: 25 / 61 / 15 / 2
Risk critical / high / med / low: 25 / 58 / 17 / 3
Coverage POS / NEG / EDGE: 76 / 15 / 12
Automation planned: 103
Flows · Suites: 3 · 2

Precondition composition

Foundational data fragments (left) flow into state fragments (right), which testcases reference. Counts are direct testcase usage. The data world — channel, form template, visitation — is seeded before any login or navigation.

PRE-OV-channel-exists

0 testcases

→

PRE-OV-form-template-assigned

0 testcases · needs 1

→

PRE-OV-visitation-assigned

0 testcases · needs 1

→

PRE-OV-visitation-data-seeded

0 testcases · needs 1

→

PRE-OV-download-center-open

20 testcases · needs 1

PRE-OV-gagal-kirim-has-items

34 testcases · needs 1

PRE-OV-logged-in-online

33 testcases · needs 1

PRE-OV-mode-luring-active

16 testcases · needs 1

Precondition	Composes	Used by	Source
PRE-OV-channel-exists A channel exists and is in the employee's authorized scope	—	0	md
PRE-OV-download-center-open Employee has Download Center open from the channel list	PRE-OV-visitation-data-seeded	20	md
PRE-OV-form-template-assigned A task form template is assigned to the channel	PRE-OV-channel-exists	0	md
PRE-OV-gagal-kirim-has-items Employee has one or more items in the Gagal Kirim queue	PRE-OV-visitation-data-seeded	34	md
PRE-OV-logged-in-online Employee logged in with GOOD connection and Mode Luring OFF	PRE-OV-visitation-data-seeded	33	md
PRE-OV-mode-luring-active Employee operating in Mode Luring with downloaded bundles	PRE-OV-visitation-data-seeded	16	md
PRE-OV-visitation-assigned A visitation is assigned to the employee for the test day	PRE-OV-form-template-assigned	0	md
PRE-OV-visitation-data-seeded Channel, form template, and visitation data are seeded for the employee	PRE-OV-visitation-assigned	0	md

Flows — journeys

FLOW-OV-C1-download-lifecycle

Download Center bundle lifecycle journey (prepare to purge)

active

PRE-OV-download-center-open

1. OV-C1-POS-003 2. OV-C1-POS-005 3. OV-C1-POS-008 4. OV-C1-POS-009 5. OV-C1-POS-014 6. OV-C1-POS-015 7. OV-C1-POS-016 8. OV-C1-POS-019 9. OV-C1-POS-022 10. OV-C1-POS-024 11. OV-C1-POS-020

FLOW-OV-C4-sync-strategy

Auto and manual sync strategy journey

active

PRE-OV-gagal-kirim-has-items

1. OV-C4-POS-001 2. OV-C4-POS-002 3. OV-C4-POS-003 4. OV-C4-NEG-004 5. OV-C4-POS-005 6. OV-C4-POS-007 7. OV-C4-POS-008 8. OV-C4-EDGE-010

FLOW-OV-C6-failed-resync

Failed submission modify-and-resync journey

active

PRE-OV-gagal-kirim-has-items

1. OV-C6-POS-002 2. OV-C6-POS-003 3. OV-C6-POS-005 4. OV-C6-NEG-006 5. OV-C6-POS-007 6. OV-C6-POS-008

Suites — run sets

pk144-regression-staging

PK144 Offline Mode full regression (staging)

active

103 testcases · env staging

OV-C1-EDGE-002 OV-C1-EDGE-010 OV-C1-EDGE-021 OV-C1-EDGE-026 OV-C1-EDGE-027 OV-C1-NEG-011 OV-C1-NEG-013 OV-C1-NEG-018 OV-C1-NEG-023 OV-C1-POS-001 OV-C1-POS-003 OV-C1-POS-004

pk144-smoke-staging

PK144 Offline Mode smoke (P0 critical paths, staging)

active

23 testcases · env staging

OV-C1-POS-009 OV-C1-NEG-011 OV-C1-POS-015 OV-C1-NEG-018 OV-C1-NEG-023 OV-C2-POS-002 OV-C2-POS-008 OV-C2-POS-009 OV-C3-POS-001 OV-C3-POS-007 OV-C3-NEG-008 OV-C4-POS-003

Testcases

103 / 103 shown

ID	Scn	Product	Title	Pri	Risk	Status	Auto	Preconditions	Src
▸C1 Download Preparation, Download Center, Storage Tiering & Bundle Lifecycle mobile
▸OV-C1-EDGE-002	C1.1	mobile	Download Center entry behaves correctly under NO CONNECTION and Mode Luring ON Verify the Download Center entry point reacts correctly to connectivity and Mode Luring state when tapped.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the Download Center entry point reacts correctly to connectivity and Mode Luring state when tapped. Preconditions See PRE-OV-logged-in-online (then vary connectivity/Mode Luring per case below) Steps With NO CONNECTION and Mode Luring OFF, tap the Download Center entry point With Mode Luring ON, open the Download Center Expected Result Then tapping under NO CONNECTION (Mode Luring OFF) shows the "Tidak ada Koneksi" drawer And with Mode Luring ON, bulk-download is disabled (state S3) Source Traceability TSD: PK144 Section: C1 - Download Preparation, Download Center, Storage Tiering & Bundle Lifecycle Scenario: C1.1 - Open Download Center from channel list (entry point visibility) Acceptance Criteria: M.1 AC1, AC2, AC3 Evidence Required Screen recording showing the "Tidak ada Koneksi" drawer and disabled bulk-download under Mode Luring. Notes / Gaps Drawer routing detail is owned by section C7; this case asserts only the entry-point trigger.
▸OV-C1-POS-001	C1.1	mobile	Download Center entry point is visible and accessible from channel list Verify the Download Center entry point is always discoverable from the channel list, independent of the current download/storage state.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the Download Center entry point is always discoverable from the channel list, independent of the current download/storage state. Preconditions See PRE-OV-logged-in-online And the employee is on the channel list page Steps When the channel list page renders Open the overflow menu Expected Result Then the Download Center entry point is visible regardless of download state And the entry point is enabled and accessible via overflow menu → "Unduh Data" And the entry point remains accessible in S1, S2, and S3 Source Traceability TSD: PK144 Section: C1 - Download Preparation, Download Center, Storage Tiering & Bundle Lifecycle Scenario: C1.1 - Open Download Center from channel list (entry point visibility) Acceptance Criteria: M.1 AC1, AC2, AC3 Evidence Required Screen recording from Staffinc Work showing the entry point under S1/S2/S3. Notes / Gaps No gap. Connectivity-gated behavior of the entry point is covered separately in OV-C1-EDGE-002.
▸OV-C1-POS-003	C1.2	mobile	Download Center default state with downloaded items shows summary and list Verify the Download Center summary and list state when downloaded bundles exist.	P2	medium	draft	planned	PRE-OV-download-center-open	md
Objective Verify the Download Center summary and list state when downloaded bundles exist. Preconditions See PRE-OV-download-center-open And at least one bundle has already been downloaded Steps When the employee opens the Download Center with downloaded items Expected Result Then the summary shows "Total Data: <size>" with cumulative size And the "Hapus Semua" CTA is visible and enabled And the downloaded items list renders with a cloud-icon timestamp per row Source Traceability TSD: PK144 Section: C1 - Download Center Scenario: C1.2 - Default page state distinguishes downloaded vs empty Acceptance Criteria: M.2 AC1, AC2 Evidence Required Screenshot of the populated Download Center summary and list. Notes / Gaps Empty-state counterpart is OV-C1-POS-004.
▸OV-C1-POS-004	C1.2	mobile	Download Center empty state when no bundles are downloaded Verify the Download Center empty state when no bundles have been downloaded.	P2	medium	draft	planned	PRE-OV-download-center-open	md
Objective Verify the Download Center empty state when no bundles have been downloaded. Preconditions See PRE-OV-download-center-open And no bundle has been downloaded Steps When the employee opens the Download Center with no downloaded items Expected Result Then the summary section is empty OR shows "Total Data: 0 kB" And the "Hapus Semua" CTA is disabled And the downloaded items list is hidden Source Traceability TSD: PK144 Section: C1 - Download Center Scenario: C1.2 - Default page state distinguishes downloaded vs empty Acceptance Criteria: M.2 AC1, AC2 Evidence Required Screenshot of the empty Download Center state. Notes / Gaps Testing Concern #1 (Critical: no — Low): empty-state design (hide vs "0 kB") is not finalized. Assert whichever the build implements and flag mismatch.
▸OV-C1-POS-005	C1.3	mobile	Item selection mechanics drive the Unduh Data CTA state Verify the "Unduh Data" CTA enable/disable state and counter track item selection.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify the "Unduh Data" CTA enable/disable state and counter track item selection. Preconditions See PRE-OV-download-center-open And downloadable items exist with no item selected Steps Observe the CTA with no item selected When the employee selects 1 or more items When the employee taps "Reset" Expected Result Then with no selection the "Unduh Data" CTA is disabled and shows count "0" And after selecting 1+ items the CTA is enabled and shows "Unduh (N)" And after "Reset" all selections clear, the count returns to 0, and the CTA is disabled Source Traceability TSD: PK144 Section: C1 - Download Center Scenario: C1.3 - Selection mechanics drive CTA state Acceptance Criteria: M.2 AC3, AC5–AC7 Evidence Required Screen recording of CTA state transitions. Notes / Gaps Testing Concern #2 (Medium): "Pilih Semua" behavior is TBD — intentionally NOT covered here; create a testcase once PM defines it. Testing Concern #3 (Medium): max selection limit is unspecified — no boundary assertion until clarified.
▸OV-C1-POS-006	C1.4	mobile	PJP persona: downloadable-item dropdown shows assigned PJP channels Verify persona-based filtering of the downloadable-item dropdown for a PJP employee.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify persona-based filtering of the downloadable-item dropdown for a PJP employee. Preconditions See PRE-OV-download-center-open And the employee has PJP assignments for today Steps When the employee opens the downloadable-item dropdown Expected Result Then the list shows channels from the assigned PJP across the appointed dates And those entries are downloadable per visitation Source Traceability TSD: PK144 Section: C1 - Download Center Scenario: C1.4 - Persona-based filtering in item dropdown Acceptance Criteria: M.2 AC8, M.7 AC1–AC3 Evidence Required Screenshot of the PJP-filtered dropdown. Notes / Gaps Testing Concern #4 (Critical): hybrid persona (PJP + non-PJP same day) is unresolved — this case assumes pure PJP. Hybrid behavior is a gap, not covered.
▸OV-C1-POS-007	C1.4	mobile	Non-PJP persona: downloadable-item dropdown shows all authorized channels Verify persona-based filtering of the downloadable-item dropdown for a Non-PJP employee.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify persona-based filtering of the downloadable-item dropdown for a Non-PJP employee. Preconditions See PRE-OV-download-center-open And the employee has no PJP assignment Steps When the employee opens the downloadable-item dropdown Expected Result Then the list shows all authorized channels And those entries are downloadable per channel (Non-PJP, reusable) Source Traceability TSD: PK144 Section: C1 - Download Center Scenario: C1.4 - Persona-based filtering in item dropdown Acceptance Criteria: M.2 AC8, M.7 AC1–AC3 Evidence Required Screenshot of the Non-PJP dropdown listing authorized channels. Notes / Gaps Pairs with OV-C1-POS-006 (PJP). Hybrid persona remains a gap (Testing Concern #4, Critical).
▸OV-C1-POS-008	C1.5	mobile	Search filtering preserves selections in downloadable items list Verify real-time search filtering and that selections persist across filtering and clearing.	P2	medium	draft	planned	PRE-OV-download-center-open	md
Objective Verify real-time search filtering and that selections persist across filtering and clearing. Preconditions See PRE-OV-download-center-open And the downloadable items list is rendered Steps When the employee types into the search field Select one or more filtered items When the employee clears the search Expected Result Then the list filters by channel name OR ID OR external ID in real-time And previously-selected items remain selected And clearing the search restores the full list with selections preserved Source Traceability TSD: PK144 Section: C1 - Download Center Scenario: C1.5 - Search filtering with selection persistence Acceptance Criteria: M.2 AC4, AC6, AC7 Evidence Required Screen recording showing filter + selection persistence. Notes / Gaps No gap.
▸OV-C1-EDGE-010	C1.6	mobile	Storage tier routing: LIMITED_REFERENCE_ONLY shows consent drawer Verify the storage-tier router presents the Limited-Reference Consent drawer when storage only supports limited reference data.	P0	critical	draft	planned	PRE-OV-download-center-open	md
Objective Verify the storage-tier router presents the Limited-Reference Consent drawer when storage only supports limited reference data. Preconditions See PRE-OV-download-center-open And device storage is in the LIMITED_REFERENCE_ONLY state Steps When the employee taps "Unduh Data" with a selection And the system evaluates available device storage Expected Result Then the system routes to LIMITED_REFERENCE_ONLY and shows the Limited-Reference Consent drawer Source Traceability TSD: PK144 Section: C1 - Storage Tiering Scenario: C1.6 - Storage tier routing (the 3-branch flow) Acceptance Criteria: M.4 AC1, AC2, AC6 Evidence Required Screenshot of the Limited-Reference Consent drawer with the storage state captured. Notes / Gaps Consent path outcomes are covered by OV-C1-POS-012 / OV-C1-NEG-013. Testing Concern #5 (Critical) and #6 (High: Limited vs Complete reference data contract) apply.
▸OV-C1-NEG-011	C1.6	mobile	Storage tier routing: TEMPLATE_NOT_SUPPORTED blocks with Gagal Mengunduh Verify the storage-tier router blocks the download and surfaces "Gagal Mengunduh" when the device cannot support the template.	P0	critical	draft	planned	PRE-OV-download-center-open	md
Objective Verify the storage-tier router blocks the download and surfaces "Gagal Mengunduh" when the device cannot support the template. Preconditions See PRE-OV-download-center-open And device storage is in the TEMPLATE_NOT_SUPPORTED state Steps When the employee taps "Unduh Data" with a selection And the system evaluates available device storage Expected Result Then the system routes to TEMPLATE_NOT_SUPPORTED and shows the "Gagal Mengunduh" drawer And the download is blocked (no bundle stored) Source Traceability TSD: PK144 Section: C1 - Storage Tiering Scenario: C1.6 - Storage tier routing (the 3-branch flow) Acceptance Criteria: M.4 AC1, AC2, AC6 Evidence Required Screenshot of the "Gagal Mengunduh" drawer; confirm no bundle was stored. Notes / Gaps Testing Concern #5 (Critical): threshold values undefined — branch is hard to trigger deterministically until specified.
▸OV-C1-POS-009	C1.6	mobile	Storage tier routing: FULL_BUNDLE_SUPPORTED proceeds with full download Verify the storage-tier router proceeds with a full download when device storage supports the full bundle.	P0	critical	draft	planned	PRE-OV-download-center-open	md
Objective Verify the storage-tier router proceeds with a full download when device storage supports the full bundle. Preconditions See PRE-OV-download-center-open And device storage is in the FULL_BUNDLE_SUPPORTED state Steps When the employee taps "Unduh Data" with a selection And the system completes bundle preparation and evaluates available device storage Expected Result Then the system routes to FULL_BUNDLE_SUPPORTED and proceeds with the full download Source Traceability TSD: PK144 Section: C1 - Storage Tiering Scenario: C1.6 - Storage tier routing (the 3-branch flow) Acceptance Criteria: M.4 AC1, AC2, AC6 Evidence Required Screen recording of the full-download path; device storage state captured. Notes / Gaps Testing Concern #5 (Critical): storage tier routing threshold values are undefined. Reproducing each branch deterministically is blocked until Engineering specifies thresholds.
▸OV-C1-NEG-013	C1.7	mobile	Limited-Reference consent: Batal cancels download with no bundle stored Verify declining the Limited-Reference Consent cancels the download and stores no bundle.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify declining the Limited-Reference Consent cancels the download and stores no bundle. Preconditions See PRE-OV-download-center-open And the Limited-Reference Consent drawer is shown (see OV-C1-EDGE-010) Steps When the employee taps "Batal" Expected Result Then the download is cancelled and no bundle is stored And the "Gagal Mengunduh" drawer is shown Source Traceability TSD: PK144 Section: C1 - Storage Tiering Scenario: C1.7 - Limited-Reference consent path Acceptance Criteria: M.4 AC3–AC5 Evidence Required Screenshot of the "Gagal Mengunduh" drawer; confirm no bundle stored. Notes / Gaps No gap.
▸OV-C1-POS-012	C1.7	mobile	Limited-Reference consent: Lanjutkan starts limited download with fallback Verify accepting the Limited-Reference Consent starts a limited download flagged accordingly.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify accepting the Limited-Reference Consent starts a limited download flagged accordingly. Preconditions See PRE-OV-download-center-open And the Limited-Reference Consent drawer is shown (see OV-C1-EDGE-010) Steps When the employee taps "Lanjutkan" Expected Result Then the limited-reference download starts And the bundle is stored with IsLimitedReference flag = true And the form-fill UI later offers a manual input fallback Source Traceability TSD: PK144 Section: C1 - Storage Tiering Scenario: C1.7 - Limited-Reference consent path Acceptance Criteria: M.4 AC3–AC5 Evidence Required Screen recording of consent → limited download; backend/local flag IsLimitedReference captured. Notes / Gaps Manual-input fallback verification depends on form-fill (section C8) and the reference-data contract (Concern #6, High).
▸OV-C1-POS-014	C1.8	mobile	Download progress modal blocks UI and resolves to success drawer Verify the blocking download progress modal and its transition to the success drawer.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify the blocking download progress modal and its transition to the success drawer. Preconditions See PRE-OV-download-center-open And a download has been started (FULL_BUNDLE_SUPPORTED) Steps When byte transfer begins When the download completes Expected Result Then a center modal renders with a spinner and "Mengunduh..." label And the byte counter shows "<downloaded> kB dari <total> kB" And the background page is dimmed and non-interactive And on completion the progress modal is replaced by a success drawer titled "Data Anda berhasil terunduh", body "Anda dapat melanjutkan pekerjaan Anda.", CTA "Ya, Saya mengerti" Source Traceability TSD: PK144 Section: C1 - Download Center Scenario: C1.8 - Download progress modal (blocking, byte counter) Acceptance Criteria: M.5 AC1, AC5, M.3 AC4–AC6 Evidence Required Screen recording of the progress modal and success drawer. Notes / Gaps Testing Concern #7 (Low): percentage progress bar is TBD — byte counter is asserted, percentage is not.
▸OV-C1-POS-015	C1.9	mobile	Downloaded bundle is atomic and contains all required components Verify a successful full download produces a complete, atomic bundle.	P0	critical	draft	planned	PRE-OV-download-center-open	md
Objective Verify a successful full download produces a complete, atomic bundle. Preconditions See PRE-OV-download-center-open And a full download has succeeded Steps Inspect the downloaded bundle contents and state Expected Result Then the bundle includes: channel detail info (name, address, contact, photos); visitation policy (selfie/geofence y/n); assigned task list (form assignments); form template (structure + mandatory + logic jumps + nested compound); form availability & target; limited option sets (e.g., 1,000 of 5,700 SKUs) And the bundle is atomic — Terunduh OR Belum Diunduh, with no intermediate state Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.9 - Bundle contents are atomic & complete Acceptance Criteria: M.6 AC1–AC3 Evidence Required Bundle inspection evidence (local storage dump or instrumented assertion) covering all six components. Notes / Gaps "Limited option sets" count depends on the reference-data contract (Concern #6, High).
▸OV-C1-POS-016	C1.10	mobile	Cloud-icon timestamp shows bundle presence and updates on re-download Verify the cloud-icon timestamp represents bundle presence and refreshes after re-download.	P2	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the cloud-icon timestamp represents bundle presence and refreshes after re-download. Preconditions See PRE-OV-logged-in-online And a downloaded bundle exists Steps When the employee views a card (homepage, channel list, Download Center, Detail Kunjungan) When a re-download succeeds Expected Result Then the card shows "☁ <absolute_timestamp>" (e.g., "☁ 7 Mar 2026 07:15 WIB") And after re-download the timestamp updates to the new download time without a page refresh Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.10 - Cloud-icon timestamp as visual presence indicator Acceptance Criteria: M.8 AC1–AC5, M.10 AC1, AC4 Evidence Required Screen recording across the four card surfaces and the post-re-download update. Notes / Gaps Absence-of-icon counterpart is OV-C1-POS-017.
▸OV-C1-POS-017	C1.10	mobile	No cloud-icon line rendered when no bundle exists Verify the absence of the cloud-icon line is itself the "no bundle" visual signal.	P3	low	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the absence of the cloud-icon line is itself the "no bundle" visual signal. Preconditions See PRE-OV-logged-in-online And no bundle exists for the card Steps When the employee views the card Expected Result Then no cloud-icon line is rendered (absence IS the visual signal) Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.10 - Cloud-icon timestamp as visual presence indicator Acceptance Criteria: M.8 AC1–AC5, M.10 AC1, AC4 Evidence Required Screenshot of a card with no cloud-icon line. Notes / Gaps No gap.
▸OV-C1-NEG-018	C1.11	mobile	Re-download blocked while a dependent visitation is Dalam Proses Verify re-download is blocked while a visitation depending on the bundle is in progress, protecting in-use data.	P0	critical	draft	planned	PRE-OV-logged-in-online	md
Objective Verify re-download is blocked while a visitation depending on the bundle is in progress, protecting in-use data. Preconditions See PRE-OV-logged-in-online And a downloaded bundle exists And at least one visitation using it is "Dalam Proses" Steps When the employee attempts re-download (from Download Center or Detail Kunjungan) Expected Result Then the re-download is BLOCKED And the employee sees an explanation that the data is still used by an ongoing visitation And the existing bundle remains intact Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.11 - Re-download with "Dalam Proses" guard Acceptance Criteria: M.9 AC3, AC4, AC8, AC10 Evidence Required Screen recording of the blocked re-download and explanation; confirm bundle intact. Notes / Gaps Unblock-after-completion counterpart is OV-C1-POS-019.
▸OV-C1-POS-019	C1.11	mobile	Re-download proceeds after dependent visitation completes or cancels Verify re-download is allowed once no dependent visitation is in progress.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify re-download is allowed once no dependent visitation is in progress. Preconditions See PRE-OV-logged-in-online And a downloaded bundle exists whose dependent visitation just completed or was cancelled Steps When the employee attempts re-download Expected Result Then the re-download proceeds normally (overwrites the bundle and updates the timestamp) Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.11 - Re-download with "Dalam Proses" guard Acceptance Criteria: M.9 AC3, AC4, AC8, AC10 Evidence Required Screen recording of the successful re-download and updated timestamp. Notes / Gaps No gap.
▸OV-C1-EDGE-021	C1.12	mobile	Cache clear or uninstall deletes all bundles regardless of retention age Verify that clearing app cache or uninstalling removes all bundles irrespective of retention age.	P2	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify that clearing app cache or uninstalling removes all bundles irrespective of retention age. Preconditions See PRE-OV-logged-in-online And one or more downloaded bundles exist Steps When the app cache is cleared OR the app is uninstalled Expected Result Then all bundles are deleted regardless of retention age Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.12 - Retention & auto-purge (3×24h) Acceptance Criteria: M.10 AC2, AC3, AC4 Evidence Required Storage inspection before/after cache clear or uninstall/reinstall. Notes / Gaps Related cross-cutting recovery is covered in section C10 (cache clear & uninstall, data loss expected).
▸OV-C1-POS-020	C1.12	mobile	Bundle auto-purges after 3×24h with no dependents Verify automatic purge of an unused bundle after the 3×24h retention window.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify automatic purge of an unused bundle after the 3×24h retention window. Preconditions See PRE-OV-logged-in-online And a downloaded bundle exists And no related visitation is "Dalam Proses" And no Perlu Dikirim queue item depends on it Steps When 3×24 hours elapse since check-out (or last activity) Expected Result Then the bundle is auto-purged from local storage And the cloud-icon timestamp disappears without a page refresh And no notification is shown Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.12 - Retention & auto-purge (3×24h) Acceptance Criteria: M.10 AC2, AC3, AC4 Evidence Required Instrumented clock/retention evidence showing purge after the window. Notes / Gaps Testing Concern #9 (Critical): retention timer start (check-out vs no-dependent) is undefined — the exact window start is a gap; assert relative elapse, flag the trigger choice. Cache-clear/uninstall counterpart is OV-C1-EDGE-021.
▸OV-C1-NEG-023	C1.13	mobile	Single delete rejected when bundle is used by Dalam Proses or Gagal Kirim Verify deletion is rejected for a bundle still required by an ongoing or queued submission.	P0	critical	draft	planned	PRE-OV-download-center-open	md
Objective Verify deletion is rejected for a bundle still required by an ongoing or queued submission. Preconditions See PRE-OV-download-center-open And the bundle is still used by a "Dalam Proses" visitation OR a Gagal Kirim item Steps When the employee attempts to delete that bundle Expected Result Then the deletion is rejected with an explanation And the bundle remains intact Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.13 - Single delete from Download Center Acceptance Criteria: M.11 AC1–AC3, AC7, AC8 Evidence Required Screenshot of the rejection explanation; confirm bundle intact. Notes / Gaps No gap.
▸OV-C1-POS-022	C1.13	mobile	Single delete from Download Center removes bundle after confirmation Verify per-row deletion of a bundle from the Download Center, including confirmation and UI updates.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify per-row deletion of a bundle from the Download Center, including confirmation and UI updates. Preconditions See PRE-OV-download-center-open And at least one deletable bundle exists Steps When the employee taps the per-row delete icon When the employee confirms the deletion Expected Result Then a confirmation prompt appears (permanent deletion warning) And after confirming, the bundle is removed from local storage And the cloud-icon disappears from affected cards immediately And the Total Data size updates Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.13 - Single delete from Download Center Acceptance Criteria: M.11 AC1–AC3, AC7, AC8 Evidence Required Screen recording of delete confirmation and post-delete UI. Notes / Gaps Rejected-delete (protected bundle) counterpart is OV-C1-NEG-023.
▸OV-C1-POS-024	C1.14	mobile	Bulk delete via Hapus Semua deletes only eligible bundles Verify "Hapus Semua" deletes eligible bundles while protecting in-use ones and explaining the outcome.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify "Hapus Semua" deletes eligible bundles while protecting in-use ones and explaining the outcome. Preconditions See PRE-OV-download-center-open And a mix of eligible and protected (Dalam Proses dependent) bundles exists Steps When the employee taps "Hapus Semua" When the employee confirms Expected Result Then a confirmation prompt appears (permanent deletion warning) And after confirming, only eligible bundles are deleted And protected bundles (Dalam Proses dependents) remain And a summary explains which bundles could not be deleted Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.14 - Bulk delete via "Hapus Semua" Acceptance Criteria: M.11 AC4–AC6, AC9 Evidence Required Screen recording of bulk delete with mixed eligible/protected bundles. Notes / Gaps Testing Concern #11 (Medium): "Hapus Semua" mixed-outcome UX is not finalized — assert the implemented summary and flag deviations.
▸OV-C1-POS-025	C1.15	mobile	Download from Detail Kunjungan prepares a bundle for the current visitation Verify the pre-check-in download entry point on Detail Kunjungan prepares a bundle scoped to the current visitation.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the pre-check-in download entry point on Detail Kunjungan prepares a bundle scoped to the current visitation. Preconditions See PRE-OV-logged-in-online And the employee is on Detail Kunjungan (before check-in) And the current visitation has no bundle Steps When the page loads When the employee taps "Unduh Data" Expected Result Then the CTA "Unduh Data" is rendered without an upfront size And tapping it prepares a bundle for the current visitation only And it follows the shared storage validation (M.4) and shared progress/result handling (M.5) And persona scope applies: Non-PJP → per channel, reusable; PJP → per visitation (channel + date), single-use Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.15 - Download from Detail Kunjungan (pre-check-in) Acceptance Criteria: M.12 AC1–AC5, AC12 Evidence Required Screen recording of Detail Kunjungan download for both personas. Notes / Gaps Hybrid persona same-day scope remains a gap (Testing Concern #4, Critical).
▸OV-C1-EDGE-026	C1.16	mobile	Mid-download storage exhaustion stops download with no partial bundle Verify graceful handling when device storage runs out during a download.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify graceful handling when device storage runs out during a download. Preconditions See PRE-OV-download-center-open And a download is in progress And device storage becomes exhausted mid-transfer Steps When storage runs out mid-download Expected Result Then the download stops and the "Gagal Mengunduh" drawer is shown And no partial bundle is stored Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.16 - Mid-download failure handling Acceptance Criteria: M.5 AC3–AC5 Evidence Required Screen recording of mid-download storage failure; confirm no partial bundle. Notes / Gaps Network-drop counterpart is OV-C1-EDGE-027.
▸OV-C1-EDGE-027	C1.16	mobile	Mid-download network drop stops download and preserves existing bundle Verify graceful handling when the network drops during a download, preserving any existing bundle.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify graceful handling when the network drops during a download, preserving any existing bundle. Preconditions See PRE-OV-download-center-open And a download is in progress (re-download attempt over an existing bundle) And the network drops mid-transfer Steps When the network drops mid-download Expected Result Then the download stops and the "Tidak ada Koneksi" drawer is shown And the existing bundle (if a re-download attempt) is preserved Source Traceability TSD: PK144 Section: C1 - Bundle Lifecycle Scenario: C1.16 - Mid-download failure handling Acceptance Criteria: M.5 AC3–AC5 Evidence Required Screen recording of mid-download network drop; confirm existing bundle preserved. Notes / Gaps No gap.
▸C2 Visitation Flow: Fully Online & Fully Offline mobile
▸OV-C2-POS-001	C2.1	mobile	Fully Online: channel list visible for both personas without connectivity prompts Verify the homepage renders the correct channel list per persona with no connectivity popups while fully online.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the homepage renders the correct channel list per persona with no connectivity popups while fully online. Preconditions See PRE-OV-logged-in-online (GOOD network throughout) Steps When the employee opens the homepage Expected Result Then for Non-PJP the list shows all authorized channels And for PJP the assigned Journey Plan is shown, each card with a "Dijadwalkan" badge And no connectivity-related popups, banners, or overlays appear Source Traceability TSD: PK144 Section: C2 - Visitation Flow: Fully Online & Fully Offline Scenario: C2.1 - Fully Online: Channel list visible without prompts Acceptance Criteria: M.13 AC1 Evidence Required Screenshots of Non-PJP and PJP homepages with no connectivity prompts. Notes / Gaps No gap.
▸OV-C2-POS-002	C2.2	mobile	Fully Online: complete visitation flow end-to-end with live backend data Verify a fully online visitation completes immediately with no Gagal Kirim entries.	P0	critical	draft	planned	PRE-OV-logged-in-online	md
Objective Verify a fully online visitation completes immediately with no Gagal Kirim entries. Preconditions See PRE-OV-logged-in-online And the employee has selected a channel with GOOD network throughout Steps Complete check-in (selfie + geofence per PK135) Fill all task forms with live backend data (full SKU catalog, 5,700 items) Proceed through Kirim → Ringkasan → Check Out Expected Result Then submission completes immediately And the visit transitions to Selesai And the visit appears in Riwayat right away And no items are added to the Gagal Kirim queue Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.2 - Fully Online: Complete visitation flow end-to-end Acceptance Criteria: M.13 AC2 Evidence Required Screen recording of the end-to-end online visitation; Riwayat entry captured. Notes / Gaps Check-in selfie/geofence detail is owned by PK135 (cross-PRD reference).
▸OV-C2-POS-003	C2.3	mobile	Fully Online: draft mirrored to server and local, flushed on completion Verify online draft saving mirrors to backend and local, and local copies flush on successful completion.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify online draft saving mirrors to backend and local, and local copies flush on successful completion. Preconditions See PRE-OV-logged-in-online And the employee is in an active online visitation Steps When the employee taps "Simpan" to save a draft When the visit successfully completes via Kirim → Ringkasan → Check Out Expected Result Then the draft is sent to backend with status Draf And a local copy of the draft is written to the device (mirror) And on successful completion all local draft copies are automatically flushed from the device Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.3 - Fully Online: Draft mirror (server + local) Acceptance Criteria: M.13 AC3 Evidence Required Backend draft status + local storage inspection before and after completion. Notes / Gaps Testing Concern #13 (Critical): server-local draft conflict resolution is unresolved. Persist-on-abandon counterpart is OV-C2-POS-004.
▸OV-C2-POS-004	C2.3	mobile	Local draft persists when visit not completed and app closed Verify local draft copies remain on device when a visit has not yet completed.	P2	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify local draft copies remain on device when a visit has not yet completed. Preconditions See PRE-OV-logged-in-online And a draft was saved for an in-progress visit Steps When the visit is not yet successfully completed And the employee navigates away or closes the app Expected Result Then the local draft copies remain on the device Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.3 - Fully Online: Draft mirror (server + local) Acceptance Criteria: M.13 AC3 Evidence Required Local storage inspection after navigating away / app close. Notes / Gaps No gap.
▸OV-C2-POS-005	C2.4	mobile	Fully Offline prep: review full plan at office with good connection Verify the employee can review the full day plan at the office before going offline.	P2	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the employee can review the full day plan at the office before going offline. Preconditions See PRE-OV-logged-in-online And the employee is at the office with a GOOD connection and Mode Luring OFF Steps When the employee opens the homepage Expected Result Then the employee sees the full channel list (Non-PJP) or full journey plan (PJP) for the day Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.4 - Fully Offline (Pre-prepared): Review plan at office Acceptance Criteria: M.14 AC1 Evidence Required Screenshot of the full plan at the office. Notes / Gaps No gap.
▸OV-C2-POS-006	C2.5	mobile	Fully Offline prep: bulk pre-download of multiple channels/visitations Verify bulk pre-download of reference data for multiple selected items succeeds with presence indicators.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify bulk pre-download of reference data for multiple selected items succeeds with presence indicators. Preconditions See PRE-OV-download-center-open And the employee is at the office with a stable connection Steps When the employee selects multiple channels/visitations And confirms the download Expected Result Then the system downloads the required reference data per item And on success each item shows a cloud-icon timestamp Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.5 - Fully Offline: Bulk pre-download Acceptance Criteria: M.14 AC2 Evidence Required Screen recording of bulk download with per-item cloud-icon results. Notes / Gaps Shares storage validation with C1.6 (storage tier thresholds, Concern #5, Critical).
▸OV-C2-POS-007	C2.6	mobile	Fully Offline prep: activating Mode Luring filters list to downloaded items Verify activating Mode Luring before leaving shows the banner and filters the channel list.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify activating Mode Luring before leaving shows the banner and filters the channel list. Preconditions See PRE-OV-logged-in-online And required bundles have been downloaded Steps When the employee navigates to Account → Mode Luring and toggles ON Expected Result Then Mode Luring is activated And a persistent "Mode Luring Aktif" banner appears on every screen And the channel list is filtered to ONLY downloaded items Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.6 - Fully Offline: Activate Mode Luring before leaving Acceptance Criteria: M.14 AC3 Evidence Required Screen recording of activation, banner, and filtered list. Notes / Gaps Detailed filtering rules are covered in C8.3.
▸OV-C2-POS-008	C2.7	mobile	Fully Offline: completing each visit saves one atomic Gagal Kirim entry Verify offline completion of each visit produces one atomic queue entry and allows immediate continuation.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify offline completion of each visit produces one atomic queue entry and allows immediate continuation. Preconditions See PRE-OV-mode-luring-active And the employee is in the field with no connection Steps When the employee completes each visit (check-in → forms → Check Out) Expected Result Then each visitation is saved locally as ONE atomic queue entry in Gagal Kirim (Belum Terkirim) And the entry contains visit-level data plus all task report drafts And the employee can continue immediately to the next visit Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.7 - Fully Offline: Complete all visits, atomic queue Acceptance Criteria: M.14 AC4 Evidence Required Local queue inspection confirming one atomic entry per visit. Notes / Gaps Testing Concern #15 (Critical): atomicity guarantee for queue item creation.
▸OV-C2-POS-009	C2.8	mobile	Connection returns with Auto-Sync ON: queue drains automatically Verify the queue drains automatically when the connection returns and Auto-Sync is ON.	P0	critical	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the queue drains automatically when the connection returns and Auto-Sync is ON. Preconditions See PRE-OV-gagal-kirim-has-items And Auto-Sync is ON And the employee returns to a GOOD connection Steps When the connection becomes GOOD and stable for ~5 minutes Expected Result Then the queue drains automatically And successfully synced visits move to Riwayat with Selesai And all local draft copies are flushed Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.8 - Fully Offline: Connection returns, sync drains queue Acceptance Criteria: M.14 AC5 Evidence Required Screen recording of automatic drain; Riwayat entries captured. Notes / Gaps Testing Concern #17 (Medium): the ~5 min stable-connection threshold is tuning-dependent. Auto-Sync OFF counterpart is OV-C2-POS-010.
▸OV-C2-POS-010	C2.8	mobile	Connection returns with Auto-Sync OFF: manual send required Verify the queue does NOT drain automatically when Auto-Sync is OFF.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the queue does NOT drain automatically when Auto-Sync is OFF. Preconditions See PRE-OV-gagal-kirim-has-items And Auto-Sync is OFF And the employee returns to a GOOD connection Steps Observe the queue after the connection returns Expected Result Then the queue does NOT drain automatically And the Auto-Sync OFF banner is shown And the employee must tap "Kirim Semua" or "Kirim Ulang" manually Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.8 - Fully Offline: Connection returns, sync drains queue Acceptance Criteria: M.14 AC5 Evidence Required Screenshot of the Auto-Sync OFF banner with the queue still populated. Notes / Gaps No gap.
▸OV-C2-NEG-011	C2.9	mobile	Cannot disable Mode Luring while a visitation is Dalam Proses Verify Mode Luring cannot be switched off while an in-progress visitation exists (data-loss prevention).	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify Mode Luring cannot be switched off while an in-progress visitation exists (data-loss prevention). Preconditions See PRE-OV-mode-luring-active And at least one visitation is in "Dalam Proses" Steps When the employee attempts to switch Mode Luring OFF Expected Result Then the toggle is DISABLED with an explanation (data loss prevention) Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.9 - Fully Offline: Cannot disable Mode Luring with active drafts Acceptance Criteria: M.14 AC6 Evidence Required Screenshot of the disabled toggle with explanation. Notes / Gaps Cross-ref C8.7 (deliberate exit flow). Testing Concern #14 (High): cancel/abandon visit mechanism in Mode Luring.
▸OV-C2-POS-012	C2.9	mobile	Can disable Mode Luring once all Dalam Proses visits complete or cancel Verify Mode Luring can be disabled once no visitation is in progress.	P1	high	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify Mode Luring can be disabled once no visitation is in progress. Preconditions See PRE-OV-mode-luring-active And all Dalam Proses visits have completed or been cancelled Steps When the employee attempts to switch Mode Luring OFF Expected Result Then the toggle is enabled and the employee can disable Mode Luring Source Traceability TSD: PK144 Section: C2 - Visitation Flow Scenario: C2.9 - Fully Offline: Cannot disable Mode Luring with active drafts Acceptance Criteria: M.14 AC6 Evidence Required Screen recording of the toggle becoming enabled after visits complete. Notes / Gaps No gap.
▸C3 Offline Submission & Gagal Kirim Queue mobile
▸OV-C3-POS-001	C3.1	mobile	Offline submission saves an atomic local queue entry with confirmation Verify completing a visitation offline saves an atomic queue entry and shows the confirmation drawer.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify completing a visitation offline saves an atomic queue entry and shows the confirmation drawer. Preconditions See PRE-OV-mode-luring-active And the employee has completed a visitation and is on the Ringkasan step Steps When the employee taps "Check Out" Expected Result Then the submission is saved locally as an atomic queue entry (Belum Terkirim) containing visit-level data, check-in/check-out data (selfie, coordinates), and all completed task report drafts And a "Data Berhasil Disimpan" drawer appears with 2 CTAs: "Ke Gagal Kirim" and "Ke Beranda" Source Traceability TSD: PK144 Section: C3 - Offline Submission & Gagal Kirim Queue Scenario: C3.1 - Offline submission saves locally with confirmation Acceptance Criteria: M.15 AC1–AC4, AC6 Evidence Required Screen recording of Check Out → confirmation drawer; local queue inspection. Notes / Gaps Local-save-must-precede-success is covered by OV-C3-POS-007 / OV-C3-NEG-008.
▸OV-C3-POS-002	C3.2	mobile	Gagal Kirim homepage indicator shows count and updates on changes Verify the Gagal Kirim homepage entry point and its count behavior.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the Gagal Kirim homepage entry point and its count behavior. Preconditions See PRE-OV-gagal-kirim-has-items Steps View the homepage with ≥1 queue item Tap the "Gagal Kirim (N)" indicator Trigger a new submission, then a sync/delete/expiry Expected Result Then the "Gagal Kirim (N)" indicator is visible on the homepage And tapping it opens the "Gagal Kirim Kunjungan" page And the count increases on a new submission and decreases on sync/delete/expiry Source Traceability TSD: PK144 Section: C3 - Gagal Kirim Queue Scenario: C3.2 - Gagal Kirim entry point on homepage Acceptance Criteria: M.16 AC1–AC5 Evidence Required Screen recording of indicator navigation and count updates. Notes / Gaps Empty-state counterpart is OV-C3-POS-003.
▸OV-C3-POS-003	C3.2	mobile	Gagal Kirim indicator hidden or inactive when queue is empty Verify the Gagal Kirim entry point when the queue is empty.	P3	low	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the Gagal Kirim entry point when the queue is empty. Preconditions See PRE-OV-logged-in-online And the Gagal Kirim queue is empty Steps View the homepage Expected Result Then the indicator is hidden OR shows an inactive empty state Source Traceability TSD: PK144 Section: C3 - Gagal Kirim Queue Scenario: C3.2 - Gagal Kirim entry point on homepage Acceptance Criteria: M.16 AC1–AC5 Evidence Required Screenshot of the homepage with an empty queue. Notes / Gaps No gap.
▸OV-C3-POS-004	C3.3	mobile	Gagal Kirim queue list view renders summary, controls, and item metadata Verify the Gagal Kirim queue page layout and per-item metadata.	P1	medium	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the Gagal Kirim queue page layout and per-item metadata. Preconditions See PRE-OV-gagal-kirim-has-items Steps Open the "Gagal Kirim Kunjungan" page Expected Result Then the page renders "Total Data: <total_size>", a "Hapus Semua" CTA, a search field, a "Kirim Semua" CTA, and a list of queue items (oldest first) And each item displays channel name + address/location, local submission timestamp, current status (Belum Terkirim / Mengirim / Gagal Terkirim), and visitation identity metadata Source Traceability TSD: PK144 Section: C3 - Gagal Kirim Queue Scenario: C3.3 - Gagal Kirim queue list view Acceptance Criteria: M.17 AC1–AC5 Evidence Required Screenshot of the populated queue list. Notes / Gaps No gap.
▸OV-C3-POS-005	C3.4	mobile	Search filtering in Gagal Kirim queue with no-results and restore Verify search filtering, no-results state, and restore in the Gagal Kirim queue.	P2	low	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify search filtering, no-results state, and restore in the Gagal Kirim queue. Preconditions See PRE-OV-gagal-kirim-has-items Steps When the employee types into the search field When the search has no matches When the search is cleared Expected Result Then the queue filters by channel name or metadata And no matches shows a no-results state And clearing restores the full queue Source Traceability TSD: PK144 Section: C3 - Gagal Kirim Queue Scenario: C3.4 - Search filtering in Gagal Kirim queue Acceptance Criteria: M.17 AC6, AC7 Evidence Required Screen recording of filtering, no-results, and restore. Notes / Gaps No gap.
▸OV-C3-POS-006	C3.5	mobile	Queue item status lifecycle is consistent across views Verify the queue item status transitions and that status is consistent between list and detail views.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the queue item status transitions and that status is consistent between list and detail views. Preconditions See PRE-OV-gagal-kirim-has-items Steps Initiate sync on a Belum Terkirim item and observe transitions through success and failure Expected Result Then a NEW item is Belum Terkirim → Mengirim when sync initiated (send disabled) → Removed on success (visit → Riwayat as Selesai) OR Gagal Terkirim on failure And after retry attempts an item may move between Belum Terkirim ↔ Gagal Terkirim And status is consistent between the list view and Detail Kunjungan view Source Traceability TSD: PK144 Section: C3 - Gagal Kirim Queue Scenario: C3.5 - Queue item status lifecycle Acceptance Criteria: M.18 AC1–AC5 Evidence Required Screen recording covering each status transition across both views. Notes / Gaps Cross-surface consistency is also asserted in C10.4.
▸OV-C3-NEG-008	C3.6	mobile	Local save failure shows no success drawer and stores no partial item Verify graceful handling when local persistence fails on offline submission.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify graceful handling when local persistence fails on offline submission. Preconditions See PRE-OV-mode-luring-active And local persistence is forced to fail (e.g., storage error) Steps When local persistence fails Expected Result Then no success drawer is shown And no partial queue item is created And a failure UI is shown Source Traceability TSD: PK144 Section: C3 - Gagal Kirim Queue Scenario: C3.6 - Local save MUST complete before success shown Acceptance Criteria: M.15 AC4, AC5 Evidence Required Screen recording of the failure UI; confirm no partial queue item. Notes / Gaps Testing Concern #15 (Critical): atomicity guarantee for queue item creation.
▸OV-C3-POS-007	C3.6	mobile	Success drawer shown only after local persistence succeeds Verify the success drawer appears only when local persistence has succeeded.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify the success drawer appears only when local persistence has succeeded. Preconditions See PRE-OV-mode-luring-active And the employee submits a completed visitation offline Steps When local persistence succeeds Expected Result Then the success drawer is shown Source Traceability TSD: PK144 Section: C3 - Gagal Kirim Queue Scenario: C3.6 - Local save MUST complete before success shown Acceptance Criteria: M.15 AC4, AC5 Evidence Required Screen recording correlating local-save completion with the success drawer. Notes / Gaps Failure counterpart is OV-C3-NEG-008. Testing Concern #16 (Medium): pre-save storage validation for Gagal Kirim.
▸C4 Sync Strategy: Auto & Manual mobile
▸OV-C4-POS-001	C4.1	mobile	Auto Sync configuration reachable from two entry points, default OFF Verify both entry points reach the same Auto Sync configuration page and the default is OFF.	P2	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify both entry points reach the same Auto Sync configuration page and the default is OFF. Preconditions See PRE-OV-logged-in-online Steps Open Account → Mode Luring settings area Open Gagal Kirim page → "Sinkronisasi Otomatis" status section Expected Result Then both entry points navigate to the same Auto Sync configuration page And the default state is OFF Source Traceability TSD: PK144 Section: C4 - Sync Strategy: Auto & Manual Scenario: C4.1 - Auto Sync preference: dual entry points Acceptance Criteria: M.19 AC1–AC5 Evidence Required Screenshots of both entry points landing on the same config page. Notes / Gaps No gap.
▸OV-C4-POS-002	C4.2	mobile	Auto Sync toggle persists across entry points and app restart Verify the Auto Sync preference persists and does not itself trigger a sync.	P1	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the Auto Sync preference persists and does not itself trigger a sync. Preconditions See PRE-OV-logged-in-online Steps When the employee toggles the Auto Sync state Restart the app Expected Result Then the preference is saved and both entry points reflect the updated state And after app restart the state remains unchanged And toggling does NOT immediately trigger a sync Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.2 - Toggle Auto Sync ON/OFF persists Acceptance Criteria: M.19 AC6–AC9 Evidence Required Screen recording of toggle persistence across restart. Notes / Gaps No gap.
▸OV-C4-POS-003	C4.3	mobile	Auto Sync triggers silently when network stable and queue has items Verify Auto Sync starts and resolves silently when conditions are met.	P0	critical	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify Auto Sync starts and resolves silently when conditions are met. Preconditions See PRE-OV-gagal-kirim-has-items And Auto Sync is ON Steps When the network transitions to GOOD and stays stable for ~5 minutes Expected Result Then automatic synchronization starts and items transition to "Mengirim" (send disabled) And on success the item is removed, the visit appears in Riwayat, and the count decreases And on failure the item remains with status "Gagal Terkirim" and the failure reason is stored And Auto Sync runs silently — no popup, no notification Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.3 - Auto Sync triggers when conditions met Acceptance Criteria: M.20 AC1–AC6 Evidence Required Screen recording of silent auto-sync with success and failure outcomes. Notes / Gaps Testing Concern #17 (Medium): ~5 min stable-connection threshold tuning. #18 (Critical): background auto-sync feasibility when app closed (see C4.8 / C10.1).
▸OV-C4-NEG-004	C4.4	mobile	Auto Sync OFF: no automatic sync even on GOOD network Verify no automatic sync occurs when Auto Sync is OFF.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify no automatic sync occurs when Auto Sync is OFF. Preconditions See PRE-OV-gagal-kirim-has-items And Auto Sync is OFF Steps When the network is GOOD Expected Result Then no automatic sync starts And an Auto-Sync OFF banner is shown with a CTA to Account → Mode Luring And the employee must use Kirim Semua or Kirim Ulang manually Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.4 - Auto Sync OFF: no auto-trigger Acceptance Criteria: M.20 AC2 Evidence Required Screenshot of the Auto-Sync OFF banner with the queue unchanged. Notes / Gaps No gap.
▸OV-C4-NEG-006	C4.5	mobile	Kirim Semua disabled when a Mengirim item exists or under NO CONNECTION Verify the "Kirim Semua" button is disabled in the two blocking conditions.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the "Kirim Semua" button is disabled in the two blocking conditions. Preconditions See PRE-OV-gagal-kirim-has-items Steps With GOOD network and at least one "Mengirim" item present, observe the button With NO CONNECTION and any queue items, observe the button Expected Result Then "Kirim Semua" is disabled when at least one item is "Mengirim" And "Kirim Semua" is disabled under NO CONNECTION regardless of queue contents Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.5 - Kirim Semua: enabled state matrix Acceptance Criteria: M.21 AC1, AC2 Evidence Required Screenshots of the disabled button in both conditions. Notes / Gaps No gap.
▸OV-C4-POS-005	C4.5	mobile	Kirim Semua enabled on GOOD network for sendable queue contents Verify the "Kirim Semua" button is enabled for sendable queue contents on GOOD network.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the "Kirim Semua" button is enabled for sendable queue contents on GOOD network. Preconditions See PRE-OV-gagal-kirim-has-items And the network is GOOD Steps Observe "Kirim Semua" with only Belum Terkirim items Observe with only Gagal Terkirim items Observe with both Belum Terkirim AND Gagal Terkirim items Expected Result Then "Kirim Semua" is enabled in all three GOOD-network cases above Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.5 - Kirim Semua: enabled state matrix Acceptance Criteria: M.21 AC1, AC2 Evidence Required Screenshots of the enabled button for each queue composition. Notes / Gaps Disabled states are covered by OV-C4-NEG-006.
▸OV-C4-POS-007	C4.6	mobile	Kirim Semua bulk sync is atomic per visitation with mixed outcomes Verify bulk sync transitions all eligible items and resolves each visitation atomically.	P0	critical	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify bulk sync transitions all eligible items and resolves each visitation atomically. Preconditions See PRE-OV-gagal-kirim-has-items And the network is GOOD with eligible items present Steps When the employee taps "Kirim Semua" Expected Result Then all eligible items transition to "Mengirim" simultaneously and send actions are disabled while sending And per-item outcome is atomic per visitation: success → removed from queue, visit in Riwayat; failure → the entire visitation stays "Gagal Terkirim" (no partial success) And with mixed outcomes, successful items are removed while failed items remain Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.6 - Kirim Semua: bulk sync execution Acceptance Criteria: M.21 AC3–AC6 Evidence Required Screen recording of bulk sync with at least one success and one failure. Notes / Gaps Atomicity detail asserted in OV-C4-NEG-011 (C4.9).
▸OV-C4-NEG-009	C4.7	mobile	Kirim Ulang disabled or blocked under NO CONNECTION Verify resend is prevented under NO CONNECTION.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify resend is prevented under NO CONNECTION. Preconditions See PRE-OV-gagal-kirim-has-items And the device has NO CONNECTION And an item is open in Detail Kunjungan Steps When the employee attempts "Kirim Ulang" Expected Result Then "Kirim Ulang" is disabled OR blocked with no-connection feedback Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.7 - Kirim Ulang from Detail Kunjungan Acceptance Criteria: M.22 AC1–AC5 Evidence Required Screenshot of the disabled/blocked resend under NO CONNECTION. Notes / Gaps No gap.
▸OV-C4-POS-008	C4.7	mobile	Kirim Ulang from Detail Kunjungan syncs a single item on GOOD network Verify single-item resend from Detail Kunjungan on GOOD network.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify single-item resend from Detail Kunjungan on GOOD network. Preconditions See PRE-OV-gagal-kirim-has-items And the network is GOOD And a Belum Terkirim or Gagal Terkirim item is open in Detail Kunjungan Steps When the employee taps "Kirim Ulang" Expected Result Then sync starts for THAT item only And the detail button becomes "Mengirim" (disabled) And the corresponding list item also shows "Mengirim" Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.7 - Kirim Ulang from Detail Kunjungan Acceptance Criteria: M.22 AC1–AC5 Evidence Required Screen recording of single-item resend reflected in both views. Notes / Gaps NO CONNECTION counterpart is OV-C4-NEG-009.
▸OV-C4-EDGE-010	C4.8	mobile	Sync integrity preserved across app restart and force-close (no duplicates) Verify sync state survives app interruption without producing duplicate backend records.	P0	critical	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify sync state survives app interruption without producing duplicate backend records. Preconditions See PRE-OV-gagal-kirim-has-items Steps Restart the app before sync Force-close the app during a "Mengirim" item Relaunch and observe recovery Expected Result Then after restart-before-sync the item remains in Gagal Kirim with status preserved And after force-close during Mengirim the system re-evaluates item state safely on relaunch, the item is NOT duplicated on backend, and it is either confirmed synced OR returned to a retryable status And sync recovery respects the Auto Sync preference (ON → resumes automatically when eligible; OFF → does not resume) And the backend does NOT create duplicate visitations on retry Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.8 - Sync integrity during app interruption Acceptance Criteria: M.23 AC1–AC4 Evidence Required Backend record count before/after interruption; relaunch behavior recording. Notes / Gaps Testing Concern #18 (Critical): background auto-sync feasibility. #19 (Critical): idempotency key contract for retry safety.
▸OV-C4-NEG-011	C4.9	mobile	Visitation atomicity: any rejected part keeps the whole in Gagal Kirim Verify a queued visitation syncs atomically: partial backend rejection keeps the whole item failed.	P0	critical	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify a queued visitation syncs atomically: partial backend rejection keeps the whole item failed. Preconditions See PRE-OV-gagal-kirim-has-items And a queued visitation contains visit-level data plus multiple task report drafts Steps When sync is attempted And ANY part is rejected by the backend Expected Result Then the ENTIRE visitation remains in Gagal Kirim (Gagal Terkirim) And no partial success is recorded on backend And local draft copies are NOT flushed Source Traceability TSD: PK144 Section: C4 - Sync Strategy Scenario: C4.9 - Visitation atomicity (visit + tasks) Acceptance Criteria: Cross-cutting, ref M.21 AC4 Evidence Required Backend state showing no partial record; local drafts retained. Notes / Gaps No gap.
▸C5 Expiration & Manual Deletion mobile
▸OV-C5-POS-001	C5.1	mobile	Queue items expire after 3-day retention and are not recoverable Verify queue retention expiry removes items permanently without moving them to Riwayat.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify queue retention expiry removes items permanently without moving them to Riwayat. Preconditions See PRE-OV-gagal-kirim-has-items Steps When the 3-day retention period elapses without successful sync (or cache cleared / app uninstalled) Expected Result Then the item is permanently removed from local storage And it disappears from Gagal Kirim And it is NOT moved to Riwayat (not recoverable) And the homepage count updates Source Traceability TSD: PK144 Section: C5 - Expiration & Manual Deletion Scenario: C5.1 - Queue retention rules (3 days) Acceptance Criteria: M.24 AC1–AC6 Evidence Required Instrumented clock evidence of expiry; confirm not in Riwayat. Notes / Gaps Testing Concern #20 (Note): retention period upgradeable post-release. #21 (Critical): timezone for retention calc (device vs server).
▸OV-C5-POS-002	C5.2	mobile	Pre-expiration warning notification fires at D-1 and does not extend retention Verify the D-1 pre-expiration warning content and that it is informational only.	P2	medium	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the D-1 pre-expiration warning content and that it is informational only. Preconditions See PRE-OV-gagal-kirim-has-items And a queue item is 1 day (D-1) before its retention end Steps Observe the notification at the D-1 threshold Expected Result Then a notification fires with title "Data Kunjungan Belum Terkirim" and the body explaining data will be deleted if not sent before retention ends, with guidance to open Gagal Kirim And the warning is informational only — it does NOT extend the retention period Source Traceability TSD: PK144 Section: C5 - Expiration & Manual Deletion Scenario: C5.2 - Pre-expiration warning notification Acceptance Criteria: M.25 AC1–AC4 Evidence Required Screenshot of the notification; confirm retention unchanged. Notes / Gaps Timezone basis for D-1 depends on Concern #21 (Critical).
▸OV-C5-NEG-004	C5.3	mobile	Hapus Semua disabled while any item is in Mengirim status Verify "Hapus Semua" is disabled when a send is in progress.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify "Hapus Semua" is disabled when a send is in progress. Preconditions See PRE-OV-gagal-kirim-has-items And at least one item is in "Mengirim" status Steps Observe the "Hapus Semua" CTA Expected Result Then "Hapus Semua" is DISABLED while any item is "Mengirim" Source Traceability TSD: PK144 Section: C5 - Expiration & Manual Deletion Scenario: C5.3 - Hapus Semua: bulk deletion with confirmation Acceptance Criteria: M.26 AC1–AC6 Evidence Required Screenshot of the disabled CTA with a Mengirim item present. Notes / Gaps No gap.
▸OV-C5-POS-003	C5.3	mobile	Hapus Semua deletes eligible queue items after confirmation Verify bulk deletion of queue items via "Hapus Semua" with confirmation and cancel paths.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify bulk deletion of queue items via "Hapus Semua" with confirmation and cancel paths. Preconditions See PRE-OV-gagal-kirim-has-items And no item is in "Mengirim" status Steps When the employee taps "Hapus Semua" When the employee confirms; in a separate run, when the employee cancels Expected Result Then a confirmation dialog (permanent action warning) appears And on confirm all eligible items are permanently removed And on cancel no deletion occurs And deleted items are NOT moved to Riwayat and are NOT recoverable Source Traceability TSD: PK144 Section: C5 - Expiration & Manual Deletion Scenario: C5.3 - Hapus Semua: bulk deletion with confirmation Acceptance Criteria: M.26 AC1–AC6 Evidence Required Screen recording of confirm and cancel paths. Notes / Gaps Disabled-when-Mengirim is covered by OV-C5-NEG-004.
▸OV-C5-POS-005	C5.4	mobile	Single deletion from Detail Kunjungan with confirmation and Mengirim guard Verify single-item deletion from Detail Kunjungan, including the Mengirim guard and cancel path.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify single-item deletion from Detail Kunjungan, including the Mengirim guard and cancel path. Preconditions See PRE-OV-gagal-kirim-has-items And a queue item is open in Detail Kunjungan Steps Observe the delete action when the item is and is not in "Mengirim" Tap delete and confirm; in a separate run, cancel Expected Result Then the delete action is visible on the detail page, ENABLED when not "Mengirim" and DISABLED when "Mengirim" And on confirm the item is permanently removed and the employee returns to the queue list And on cancel the item remains and the employee stays on / returns to Detail Source Traceability TSD: PK144 Section: C5 - Expiration & Manual Deletion Scenario: C5.4 - Single deletion from Detail Kunjungan Acceptance Criteria: M.27 AC1–AC6 Evidence Required Screen recording of enabled/disabled states, confirm, and cancel. Notes / Gaps No gap.
▸OV-C5-POS-006	C5.5	mobile	Expired queue items do not change local achievement count Verify achievement count is unaffected by queue expiry and only corrected on successful sync.	P2	medium	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify achievement count is unaffected by queue expiry and only corrected on successful sync. Preconditions See PRE-OV-gagal-kirim-has-items And a visitation is counted as an achievement locally Steps When the queue item expires before successful sync Expected Result Then the local achievement count is UNCHANGED And the count is only corrected upon successful backend sync confirmation Source Traceability TSD: PK144 Section: C5 - Expiration & Manual Deletion Scenario: C5.5 - Expired items don't affect achievements Acceptance Criteria: M.24 AC6 Evidence Required Achievement count before/after expiry. Notes / Gaps Testing Concern #22 (Medium): achievement count reconciliation (cross-PRD).
▸C6 Failed Sync Detail, Modification & Resync mobile
▸OV-C6-POS-001	C6.1	mobile	Failure reason classified by fixability and stored as latest only Verify failed submissions are classified by fixability and that only the latest failure reason is stored.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
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 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.
▸OV-C6-POS-002	C6.2	mobile	Failed sync detail page shows status, data, and plain-language reason Verify the failed sync detail view content and the Aktivitas correction indicator.	P1	medium	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the failed sync detail view content and the Aktivitas correction indicator. Preconditions See PRE-OV-gagal-kirim-has-items And a "Gagal Terkirim" item exists Steps When the employee taps a "Gagal Terkirim" item from the list Expected Result Then Detail Kunjungan opens showing failed status clearly, channel info + photos, check-in/check-out timestamps & coordinates, the assigned task list and submitted form data, the failure reason in plain Bahasa Indonesia, and available actions per status + failure type And the failed activity in Aktivitas is marked with a failed/invalid indicator and the row shows correction required Source Traceability TSD: PK144 Section: C6 - Failed Sync Detail Scenario: C6.2 - View failed sync detail Acceptance Criteria: M.29 AC1–AC4 Evidence Required Screenshot of the failed detail page and Aktivitas row. Notes / Gaps Testing Concern #24 (High): plain-language failure copy mapping.
▸OV-C6-POS-003	C6.3	mobile	Action availability matrix for fixable and retryable failures Verify available actions match queue status and failure type for fixable/retryable cases.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify available actions match queue status and failure type for fixable/retryable cases. Preconditions See PRE-OV-gagal-kirim-has-items Steps Open items in each status/failure combination and inspect available actions Expected Result Then Belum Terkirim (no failure) offers Kirim Ulang, Hapus And Mengirim disables sending and protects destructive actions And Gagal Terkirim with form-validation-fixable failure offers Perbaiki, Simpan, Kirim Ulang, Hapus And Gagal Terkirim with retryable system/network failure offers Kirim Ulang, Hapus Source Traceability TSD: PK144 Section: C6 - Failed Sync Detail Scenario: C6.3 - Action availability matrix per status & failure type Acceptance Criteria: M.29 AC5–AC7 Evidence Required Screenshots of action sets per status/failure type. Notes / Gaps Non-fixable case is covered by OV-C6-POS-004.
▸OV-C6-POS-004	C6.3	mobile	Non-fixable failure offers only Hapus with escalation guidance Verify non-fixable business failures expose no correction path, only deletion with guidance.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify non-fixable business failures expose no correction path, only deletion with guidance. Preconditions See PRE-OV-gagal-kirim-has-items And a Gagal Terkirim item has a non-fixable business failure Steps Open the non-fixable failed item Expected Result Then only Hapus is offered plus escalation guidance And there is no edit/"Perbaiki" action And a message explains the issue cannot be corrected from the app, with guidance to contact supervisor/support Source Traceability TSD: PK144 Section: C6 - Failed Sync Detail Scenario: C6.3 - Action availability matrix per status & failure type Acceptance Criteria: M.29 AC5–AC7 Evidence Required Screenshot of the non-fixable action set and guidance message. Notes / Gaps No gap.
▸OV-C6-NEG-006	C6.4	mobile	Local validation blocks progression until correction passes Verify local validation prevents progression while errors remain.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify local validation prevents progression while errors remain. Preconditions See PRE-OV-gagal-kirim-has-items And the employee is in the Perbaiki form with invalid fields Steps Attempt to progress with errors still present Correct all errors and attempt to progress again Expected Result Then while errors remain the employee cannot proceed and validation messages persist And once validation passes "Selanjutnya" allows progression Source Traceability TSD: PK144 Section: C6 - Modification & Resync Scenario: C6.4 - Modify failed draft: Perbaiki flow Acceptance Criteria: M.30 AC1–AC7 Evidence Required Screen recording of blocked vs allowed progression. Notes / Gaps No gap.
▸OV-C6-POS-005	C6.4	mobile	Perbaiki opens form pre-filled with validation highlights Verify the Perbaiki flow re-opens the form pre-filled with clear validation messaging.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the Perbaiki flow re-opens the form pre-filled with clear validation messaging. Preconditions See PRE-OV-gagal-kirim-has-items And a Gagal Terkirim item has a form-validation-fixable failure Steps When the employee taps "Perbaiki" on the affected activity Expected Result Then the task form opens with previously submitted values pre-filled And a validation alert at top reads "Data invalid, revise highlighted fields" And each invalid field is highlighted with a specific validation message Source Traceability TSD: PK144 Section: C6 - Modification & Resync Scenario: C6.4 - Modify failed draft: Perbaiki flow Acceptance Criteria: M.30 AC1–AC7 Evidence Required Screenshot of the pre-filled form with highlighted invalid fields. Notes / Gaps Progression-blocking is covered by OV-C6-NEG-006.
▸OV-C6-POS-007	C6.5	mobile	Corrected submission saved locally replaces failed payload Verify saving a correction persists locally and re-enables resend.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify saving a correction persists locally and re-enables resend. Preconditions See PRE-OV-gagal-kirim-has-items And the employee has corrected an invalid form Steps When the employee taps "Simpan" after correction Navigate away and restart the app Expected Result Then the revised data is saved locally and replaces the previous failed version as the active submission payload And the item remains "Gagal Terkirim" until resync succeeds And "Kirim Ulang" becomes available And the correction persists across navigation/app restart Source Traceability TSD: PK144 Section: C6 - Modification & Resync Scenario: C6.5 - Save corrected submission locally Acceptance Criteria: M.30 AC8–AC10 Evidence Required Local payload inspection before/after; persistence across restart. Notes / Gaps No gap.
▸OV-C6-POS-008	C6.6	mobile	Resync of corrected submission is atomic with reason update on failure Verify resend eligibility rules and atomic resync outcomes for a corrected submission.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify resend eligibility rules and atomic resync outcomes for a corrected submission. Preconditions See PRE-OV-gagal-kirim-has-items And a corrected submission is ready to resend Steps Verify "Kirim Ulang" eligibility per failure type When the employee taps "Kirim Ulang" Expected Result Then "Kirim Ulang" requires a saved valid correction for validation failures, is directly available for retryable system/network failures, and is NOT available for non-fixable (only Hapus) And on tap, resync starts for THAT item only, the button becomes "Mengirim" (disabled), and the list item also shows "Mengirim" And on success the item is removed, the visitation appears in Riwayat AND Riwayat Tugas, and the count decreases And on failure it stays in the queue as "Gagal Terkirim" with the failure reason updated to the MOST RECENT And resync remains atomic for the full visitation Source Traceability TSD: PK144 Section: C6 - Modification & Resync Scenario: C6.6 - Resync corrected submission Acceptance Criteria: M.31 AC1–AC7 Evidence Required Screen recording of resync success and failure paths. Notes / Gaps No gap.
▸OV-C6-POS-009	C6.7	mobile	Stored failure reason overwritten (not appended) on repeat failure Verify only the most recent failure reason is retained on repeated failures.	P2	medium	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify only the most recent failure reason is retained on repeated failures. Preconditions See PRE-OV-gagal-kirim-has-items And an item already has a stored failure reason Steps When a later resync attempt fails for a different reason Expected Result Then the stored reason is REPLACED (not appended) And historical failure reasons are NOT retained in this scope Source Traceability TSD: PK144 Section: C6 - Modification & Resync Scenario: C6.7 - Failure reason overwritten on repeat failure Acceptance Criteria: M.31 AC6 scope notes Evidence Required Stored reason before/after the second failure. Notes / Gaps Testing Concern #25 (Note): failure history audit log is out of scope.
▸C7 Network Quality Detection & State-Driven Drawer Mechanics mobile
▸OV-C7-POS-001	C7.1	mobile	Continuous network monitoring is silent unless state changes Verify background network quality checks run at the right moments and only interrupt the UI on state change.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify background network quality checks run at the right moments and only interrupt the UI on state change. Preconditions See PRE-OV-logged-in-online Steps When the employee navigates between pages OR triggers a backend-heavy action Expected Result Then the system performs a network quality check at that moment And classifies GOOD → live-backend Fully Online, NO CONNECTION → routes based on downloaded data existence And when state is UNCHANGED the check is silent with no UI interruption And when state CHANGES it triggers the appropriate downstream UI per the routing matrix Source Traceability TSD: PK144 Section: C7 - Network Quality Detection & State-Driven Drawer Mechanics Scenario: C7.1 - Continuous network monitoring (background) Acceptance Criteria: E1.US-1 AC1–AC5 Evidence Required Instrumented logs of checks on navigation/backend actions; UI silent when unchanged. Notes / Gaps Testing Concern #26 (Medium): battery impact. #27 (Medium): check frequency (interval vs event-driven). #29 (Medium): session boundary definition.
▸OV-C7-POS-002	C7.2	mobile	Platform-specific signal computation yields identical downstream behavior Verify iOS and Android compute signal differently but produce identical NO CONNECTION classification and downstream behavior.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify iOS and Android compute signal differently but produce identical NO CONNECTION classification and downstream behavior. Preconditions See PRE-OV-logged-in-online (run on both Android and iOS) Steps Compare classification when the device reports no network (no cellular, no Wi-Fi, airplane mode) on each platform Expected Result Then Android uses speed test + signal strength + signal type and iOS uses signal type only And both detect NO CONNECTION when the device reports no network And downstream behavior is identical across iOS/Android Source Traceability TSD: PK144 Section: C7 - Network Quality Detection Scenario: C7.2 - Platform-specific signal computation Acceptance Criteria: E1.US-1 / US-2 engineering notes Evidence Required Side-by-side iOS/Android behavior under identical no-network conditions. Notes / Gaps Testing Concern #28 (Critical): network classification threshold X value undefined — GOOD-vs-NO-CONNECTION boundary on weak signal is not deterministically testable yet.
▸OV-C7-POS-003	C7.3	mobile	Drawer routing matrix resolves UI from network, bundle, and Mode Luring Verify the 2-state routing matrix selects the correct resulting UI and re-evaluates on the right triggers.	P0	critical	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the 2-state routing matrix selects the correct resulting UI and re-evaluates on the right triggers. Preconditions See PRE-OV-logged-in-online (vary network/bundle/Mode Luring per row) Steps Exercise each matrix row and each re-evaluation trigger Expected Result Then GOOD (any bundle, Mode Luring OFF) → Fully Online experience And NO CONNECTION + NO bundle + Mode Luring OFF → "Koneksi Tidak Stabil" And NO CONNECTION + bundle EXISTS + Mode Luring OFF → "Tidak ada Koneksi" And Mode Luring ON (any network/bundle) → Mode Luring (S3) And re-evaluation fires on network transitions, Mode Luring activation/deactivation, and bundle added/removed Source Traceability TSD: PK144 Section: C7 - Network Quality Detection Scenario: C7.3 - Drawer routing matrix (2-state model) Acceptance Criteria: E2.US-2 routing decision matrix Evidence Required Screenshots of resulting UI per matrix row. Notes / Gaps The two drawers' contents are covered by OV-C7-POS-004/005 (Koneksi Tidak Stabil) and OV-C7-POS-007/008 (Tidak ada Koneksi).
▸OV-C7-POS-004	C7.4	mobile	Koneksi Tidak Stabil drawer offers download via storage pre-check Verify the "Koneksi Tidak Stabil" drawer content and the "Unduh Data" path with no existing bundle.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the "Koneksi Tidak Stabil" drawer content and the "Unduh Data" path with no existing bundle. Preconditions See PRE-OV-logged-in-online And the device is NO CONNECTION with no downloaded bundle (Mode Luring OFF) Steps When the drawer fires When the employee taps "Unduh Data" Expected Result Then the drawer shows a warning icon, title "Koneksi Tidak Stabil", and 3 CTAs: "Unduh Data", "Kembali", "Abaikan, Jangan Tampilkan Lagi" And "Unduh Data" triggers the storage pre-check (per M.4) routing to full bundle / Limited-Reference Consent / Gagal Mengunduh Source Traceability TSD: PK144 Section: C7 - Drawer Mechanics Scenario: C7.4 - "Koneksi Tidak Stabil" drawer (NO CONN + no bundle) Acceptance Criteria: E1.US-3 / US-5 Evidence Required Screenshot of the drawer and the storage pre-check routing. Notes / Gaps Storage routing branches are covered by OV-C1-POS-009 / EDGE-010 / NEG-011.
▸OV-C7-POS-005	C7.4	mobile	Koneksi Tidak Stabil drawer dismiss suppresses for the session Verify dismissing the "Koneksi Tidak Stabil" drawer suppresses it while monitoring continues.	P2	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify dismissing the "Koneksi Tidak Stabil" drawer suppresses it while monitoring continues. Preconditions See PRE-OV-logged-in-online And the "Koneksi Tidak Stabil" drawer is shown Steps When the employee taps "Kembali" or "Abaikan, Jangan Tampilkan Lagi" Expected Result Then the drawer dismisses And it is suppressed for the rest of the session And backend connectivity monitoring continues Source Traceability TSD: PK144 Section: C7 - Drawer Mechanics Scenario: C7.4 - "Koneksi Tidak Stabil" drawer (NO CONN + no bundle) Acceptance Criteria: E1.US-3 / US-5 Evidence Required Screen recording of dismiss + suppression within the session. Notes / Gaps Re-fire and suppression-reset rules are covered by OV-C7-POS-006.
▸OV-C7-POS-006	C7.5	mobile	Connectivity drawer re-fires on triggers and resets suppression correctly Verify drawer re-fire conditions, suppression reset boundaries, and per-drawer suppression isolation.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify drawer re-fire conditions, suppression reset boundaries, and per-drawer suppression isolation. Preconditions See PRE-OV-logged-in-online And a connectivity drawer was previously suppressed in this session Steps Briefly go GOOD then back to NO CONNECTION Tap Simpan to save a draft; tap Kirim to complete a visitation Force-quit + relaunch; log out and back in Expected Result Then the drawer re-fires on network state change, on Simpan, and on Kirim And suppression resets after app restart (force-quit + relaunch) and after logout/login And suppression does NOT carry over between drawers (Koneksi Tidak Stabil ≠ Tidak ada Koneksi) Source Traceability TSD: PK144 Section: C7 - Drawer Mechanics Scenario: C7.5 - Drawer re-fire conditions Acceptance Criteria: M.5 AC7 Evidence Required Screen recording covering each re-fire trigger and reset boundary. Notes / Gaps Testing Concern #29 (Medium): session boundary definition affects suppression reset.
▸OV-C7-POS-007	C7.6	mobile	Tidak ada Koneksi drawer: Aktifkan Mode Luring and Coba Lagi paths Verify the "Tidak ada Koneksi" drawer content and its Aktifkan Mode Luring / Coba Lagi paths.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the "Tidak ada Koneksi" drawer content and its Aktifkan Mode Luring / Coba Lagi paths. Preconditions See PRE-OV-logged-in-online And the device is NO CONNECTION with a downloaded bundle present (Mode Luring OFF) Steps When the drawer fires When the employee taps "Aktifkan Mode Luring" In a separate run, when the employee taps "Coba Lagi" Expected Result Then the drawer shows a no-signal icon, title "Tidak ada Koneksi", and 3 CTAs: "Aktifkan Mode Luring", "Coba Lagi", "Abaikan, Jangan Tampilkan Lagi" And "Aktifkan Mode Luring" navigates to Account → Mode Luring where the employee must EXPLICITLY toggle ON And "Coba Lagi" re-checks connectivity: GOOD → drawer dismisses and Fully Online resumes silently; still NO CONNECTION → drawer remains Source Traceability TSD: PK144 Section: C7 - Drawer Mechanics Scenario: C7.6 - "Tidak ada Koneksi" drawer (NO CONN + bundle exists) Acceptance Criteria: E1.US-4 / US-6 Evidence Required Screen recording of the drawer and both CTA paths. Notes / Gaps "Abaikan" path is covered by OV-C7-POS-008.
▸OV-C7-POS-008	C7.6	mobile	Tidak ada Koneksi Abaikan keeps Fully Online; backend actions blocked, local works Verify dismissing the "Tidak ada Koneksi" drawer via Abaikan leaves the employee online with backend actions blocked.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify dismissing the "Tidak ada Koneksi" drawer via Abaikan leaves the employee online with backend actions blocked. Preconditions See PRE-OV-logged-in-online And the "Tidak ada Koneksi" drawer is shown Steps When the employee taps "Abaikan, Jangan Tampilkan Lagi" Attempt a backend-dependent action and a local-only action Expected Result Then the drawer dismisses and is suppressed for the session And the employee remains in Fully Online (Mode Luring NOT activated) And backend-dependent actions are blocked until connection returns And local-only actions continue working during NO CONNECTION Source Traceability TSD: PK144 Section: C7 - Drawer Mechanics Scenario: C7.6 - "Tidak ada Koneksi" drawer (NO CONN + bundle exists) Acceptance Criteria: E1.US-4 / US-6 Evidence Required Screen recording showing blocked backend action and working local action. Notes / Gaps No gap.
▸C8 Mode Luring State Management mobile
▸OV-C8-POS-001	C8.1	mobile	Mode Luring activates only via explicit toggle from two entry paths Verify the two Mode Luring activation paths, explicit toggle requirement, and persistence.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify the two Mode Luring activation paths, explicit toggle requirement, and persistence. Preconditions See PRE-OV-logged-in-online (Mode Luring default OFF) Steps Activate via Account → Mode Luring toggle ON Activate via "Tidak ada Koneksi" drawer → "Aktifkan Mode Luring" → Account screen, then toggle ON Restart the app Expected Result Then both paths require the employee to EXPLICITLY toggle ON (drawer path navigates to Account, does not auto-enable) And Mode Luring persists ON across app sessions until explicitly turned off And it never auto-activates And the "Unduh Otomatis" second toggle is deferred / not active in this scope Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.1 - Activation entry points (2 paths) Acceptance Criteria: E6.US-1 AC1–AC4 Evidence Required Screen recording of both activation paths and persistence across restart. Notes / Gaps No gap.
▸OV-C8-POS-002	C8.2	mobile	Persistent Mode Luring Aktif banner shown on visitation screens Verify the persistent Mode Luring banner across visitation screens and its removal on deactivation.	P2	medium	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify the persistent Mode Luring banner across visitation screens and its removal on deactivation. Preconditions See PRE-OV-mode-luring-active Steps Navigate across Beranda, channel list, Detail Kunjungan, forms, Ringkasan, Gagal Kirim, failed-item detail Deactivate Mode Luring Expected Result Then a top banner shows label "Mode Luring Aktif" with a "Matikan" CTA on the right, visually distinct and non-intrusive (NOT modal) And the banner disappears when Mode Luring is deactivated Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.2 - Persistent "Mode Luring Aktif" banner Acceptance Criteria: E6.US-2 AC1–AC4 Evidence Required Screenshots of the banner on each listed screen. Notes / Gaps The "Matikan" exit flow is covered by OV-C8-POS-007.
▸OV-C8-POS-003	C8.3	mobile	Mode Luring filters channel list and disables backend-only features Verify channel-list filtering and feature availability while Mode Luring is active.	P1	high	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify channel-list filtering and feature availability while Mode Luring is active. Preconditions See PRE-OV-mode-luring-active Steps Inspect the channel list and feature availability Expected Result Then the channel list shows ONLY items where a downloaded bundle is present OR currently "Dalam Proses", hiding items with no bundle and not Dalam Proses And persona behavior is preserved (Non-PJP all authorized; PJP assigned only; "Dijadwalkan" PJP only) And disabled features include the "Peta" map button, History Submission & Visitation, and Add New Channel And the "Gagal Kirim (N)" indicator on homepage remains accessible Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.3 - Feature availability during Mode Luring (filtered channel list) Acceptance Criteria: E6.US-3 AC1–AC5 Evidence Required Screenshots of the filtered list and disabled/accessible features. Notes / Gaps Testing Concern #30 (Cross-ref C1 #4): mixed PJP + non-PJP same employee remains a gap.
▸OV-C8-POS-004	C8.4	mobile	Offline check-in and check-out run on local data without backend Verify offline check-in/check-out using local data, including map-failure resilience.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify offline check-in/check-out using local data, including map-failure resilience. Preconditions See PRE-OV-mode-luring-active And the employee is on Detail Kunjungan with no connection Steps When the employee taps "Check In" Complete the visit and check out Expected Result Then the check-in flow runs using LOCAL data: visitation policy (selfie/geofence) from the bundle, geofence validation against locally stored pinpoint data And if the map fails to load, an "unable to show map" message shows and the flow stays unblocked And it proceeds WITHOUT backend confirmation, transitions to "Dalam Proses" locally, and the timer starts And selfie image, check-in/out GPS coordinates, and validation mark are captured locally And check-out follows the same offline pattern, with backend recording deferred to sync Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.4 - Check-in & check-out offline Acceptance Criteria: E6.US-4 AC1–AC5 Evidence Required Screen recording of offline check-in/out; local capture inspection. Notes / Gaps Selfie/geofence policy detail references PK135 (cross-PRD).
▸OV-C8-POS-005	C8.5	mobile	Form filling under Mode Luring uses cached data with validation intact Verify offline form filling sources options from the cached bundle with full validation and correct target handling.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify offline form filling sources options from the cached bundle with full validation and correct target handling. Preconditions See PRE-OV-mode-luring-active And the employee is filling a task form offline Steps Fill dropdowns and mandatory fields, exercise logic jumps and compound rules Submit against cached and PJP journey-plan targets Expected Result Then ALL dropdowns use the cached subset from the bundle (e.g., 1,000 of 5,700 SKUs) with NO per-action live fallback And limited-reference flagged bundles offer a manual input field for unmatched options, and the employee is NOT told the list is reduced And validation is intact for mandatory questions, logic jumps, compound/nested compound rules, and data format And cached target validates locally while the PJP journey-plan target is SERVER-validated and may reject at sync time And photo capture works offline (stored locally) and drafts persist until synced or manually deleted Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.5 - Form filling under Mode Luring (cached only) Acceptance Criteria: E6.US-5 AC1–AC6 Evidence Required Screen recording of offline form fill; cached option set + validation evidence. Notes / Gaps Testing Concern #31 (Critical): manual input fallback UX (limited-ref only or always offline?). #32 (Medium): "xx items" max display limits unspecified.
▸OV-C8-POS-006	C8.6	mobile	Offline submission counts immediately as achievement, reconciled on sync Verify offline submissions count as achievements immediately and reconcile on sync.	P1	high	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify offline submissions count as achievements immediately and reconcile on sync. Preconditions See PRE-OV-mode-luring-active And the employee submits a visitation in Mode Luring (local save succeeds, queue item created) Steps Observe the calendar achievement count offline Sync and observe reconciliation Expected Result Then the visitation is IMMEDIATELY counted as an achievement on the calendar: Non-PJP single number (e.g., "1", "2", "3"); PJP fraction (e.g., "1/2", "2/2") And the count persists while offline and does NOT reset awaiting sync And on sync, consistent → display unchanged; discrepancy (multi-device conflict) → backend value takes precedence Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.6 - Offline submission counted as achievement Acceptance Criteria: E6.US-8 Evidence Required Achievement count offline vs after sync. Notes / Gaps Testing Concern #33 (Medium): cross-PRD achievement count reconciliation owner.
▸OV-C8-NEG-008	C8.7	mobile	Mode Luring exit blocked while a Dalam Proses visit exists Verify exit from Mode Luring is blocked when an in-progress visit exists, preventing data loss.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify exit from Mode Luring is blocked when an in-progress visit exists, preventing data loss. Preconditions See PRE-OV-mode-luring-active And at least one visitation is in "Dalam Proses" Steps When the employee attempts to toggle Mode Luring OFF Expected Result Then the toggle is DISABLED and data loss is prevented Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.7 - Deliberate exit flow (block exit when Dalam Proses, cross-ref C2.9) Acceptance Criteria: E6.US-7 AC1–AC4 Evidence Required Screenshot of the disabled toggle with a Dalam Proses visit. Notes / Gaps Duplicate-of-behavior with OV-C2-NEG-011 (same rule surfaced from the exit flow); kept distinct for C8.7 traceability.
▸OV-C8-POS-007	C8.7	mobile	Deliberate Mode Luring exit requires manual toggle (intentional friction) Verify the deliberate exit flow from Mode Luring and the patchy-network re-fire edge case.	P1	high	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify the deliberate exit flow from Mode Luring and the patchy-network re-fire edge case. Preconditions See PRE-OV-mode-luring-active And no visitation is in "Dalam Proses" Steps Tap "Matikan" on the banner Manually toggle Mode Luring OFF, then re-establish network Edge: on patchy network, access a visitation without a bundle Expected Result Then tapping "Matikan" navigates to Account → Mode Luring (NOT a one-tap exit — intentional friction) And the employee must manually toggle Mode Luring OFF, then re-establish network connection And in the patchy-network edge case the "Koneksi Tidak Stabil" drawer re-fires and the employee is prompted to save data locally Source Traceability TSD: PK144 Section: C8 - Mode Luring State Management Scenario: C8.7 - Deliberate exit flow Acceptance Criteria: E6.US-7 AC1–AC4 Evidence Required Screen recording of the multi-step exit and the edge-case drawer re-fire. Notes / Gaps Blocked-exit-when-Dalam-Proses is covered by OV-C8-NEG-008 (cross-ref C2.9).
▸C9 Multi-device Race Conditions, Persona & Target Rules mobile
▸OV-C9-POS-001	C9.1	mobile	Persona is backend-sourced, single-value, and never inferred on mobile Verify persona is determined by backend configuration, persisted per session, and treated as a single value.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify persona is determined by backend configuration, persisted per session, and treated as a single value. Preconditions See PRE-OV-logged-in-online Steps Inspect persona resolution at login and across offline operations Expected Result Then persona (PJP or Non-PJP) is determined by account config and backend journey-plan assignment, never inferred or overridden on mobile And it is fetched at login, persisted for the session, and refreshed on subsequent logins / server-side config changes And offline routing uses the most recently fetched persona, and offline operations are NOT blocked by stale persona data And persona is single-value (exactly one persona at any moment; no hybrid or per-channel persona) And persona is NOT displayed as a UI label — reflected through behavior only Source Traceability TSD: PK144 Section: C9 - Multi-device Race Conditions, Persona & Target Rules Scenario: C9.1 - Persona identification (source of truth) Acceptance Criteria: E2.US-1 AC1–AC6 Evidence Required Persona value source trace at login and offline. Notes / Gaps Testing Concern #34 (Critical): persona change mid-session (BE update). #35 (Critical): hybrid persona open (cross-ref C1 #4).
▸OV-C9-POS-002	C9.2	mobile	Persona drives filtering, download scope, and sync rejection rules Verify persona value consistently drives downstream behavior across connectivity states.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify persona value consistently drives downstream behavior across connectivity states. Preconditions See PRE-OV-logged-in-online Steps Observe channel filtering, download scope, and sync rejection rules for each persona across S1/S2/S3 Expected Result Then persona is used for channel list filtering & badge display (Dijadwalkan PJP only), download scope (per channel reusable / per visitation single-use), and sync rejection rules (multi-device race) And behavior is preserved across S1/S2/S3 And active connectivity affects data sourcing & submission but does NOT change persona behavior Source Traceability TSD: PK144 Section: C9 - Persona & Target Rules Scenario: C9.2 - Persona-driven downstream routing Acceptance Criteria: E2.US-3 AC1–AC5 Evidence Required Behavior matrix per persona across connectivity states. Notes / Gaps No gap.
▸OV-C9-POS-003	C9.3	mobile	Non-PJP multi-device: both submissions persist as separate records Verify Non-PJP re-visits from two devices both record as separate visitations.	P1	high	draft	planned	PRE-OV-logged-in-online	md
Objective Verify Non-PJP re-visits from two devices both record as separate visitations. Preconditions See PRE-OV-logged-in-online And a Non-PJP employee uses the same account on Device A and Device B Steps Device A completes a visitation online (backend records it) Device B holds a separately-initiated visitation for the same channel, then reconnects and syncs Expected Result Then the backend records Device B as a NEW visitation record And re-visits are permitted for Non-PJP — no rejection And both visits appear in Riwayat Source Traceability TSD: PK144 Section: C9 - Multi-device Race Conditions Scenario: C9.3 - Non-PJP multi-device: both submissions succeed Acceptance Criteria: E8.US-5 AC2 Evidence Required Backend records and Riwayat showing both visits. Notes / Gaps Testing Concern #36 (Note): 2-device test environment setup required.
▸OV-C9-NEG-004	C9.4	mobile	PJP multi-device: late sync rejected because target already achieved Verify a PJP single-use target rejects a later sync from a second device while keeping the failed item locally.	P0	critical	draft	planned	PRE-OV-logged-in-online	md
Objective Verify a PJP single-use target rejects a later sync from a second device while keeping the failed item locally. Preconditions See PRE-OV-logged-in-online And a PJP employee has an account on Device A (online) + Device B (offline), PJP target = 1 visit (single-use) Steps Device A completes online → target achieved on backend Device B (offline) attempts to sync the same visitation later Expected Result Then the sync FAILS with reason "Target already achieved via Device A" And the item is kept in Device B's Gagal Kirim queue (Gagal Terkirim) with standard 1-day retention And manual delete via "Hapus Draf" is allowed And manual "Kirim Ulang" is allowed but continues to fail Source Traceability TSD: PK144 Section: C9 - Multi-device Race Conditions Scenario: C9.4 - PJP multi-device: sync rejected, target achieved Acceptance Criteria: E8.US-5 AC3 Evidence Required Backend rejection reason; Device B queue state. Notes / Gaps No gap.
▸OV-C9-NEG-005	C9.5	mobile	Same visitation ID: sync rejected on backend status conflict Verify status-conflict rejection when the same visitation advances on another device.	P0	critical	draft	planned	PRE-OV-logged-in-online	md
Objective Verify status-conflict rejection when the same visitation advances on another device. Preconditions See PRE-OV-logged-in-online And a visitation is already "Dalam Proses" on backend at Device B offline start And Device A completes/submits the SAME visitation online (backend status → Selesai) Steps When Device B reconnects and syncs its offline submission Expected Result Then the sync FAILS with reason "Visitation status moved past expected state" And this applies REGARDLESS of whether the form has a visitation target And for a compound failure (same visitation ID + form target), both status-conflict and target-achievement reasons apply, though the sync would already fail on status conflict alone Source Traceability TSD: PK144 Section: C9 - Multi-device Race Conditions Scenario: C9.5 - Same visitation ID: status conflict rejection Acceptance Criteria: E8.US-5 AC4, AC5 Evidence Required Backend rejection reason for the status conflict. Notes / Gaps No gap.
▸OV-C9-POS-006	C9.6	mobile	Multi-device failures follow non-blocking silent retry with clear reason Verify user-facing behavior for multi-device failure cases is non-blocking and explained.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify user-facing behavior for multi-device failure cases is non-blocking and explained. Preconditions See PRE-OV-gagal-kirim-has-items And a multi-device failure has occurred Steps Observe queue and detail behavior after a multi-device failure Expected Result Then the Device B item is kept in Gagal Kirim (Gagal Terkirim) with standard 1-day retention, manual "Hapus Draf" allowed, and manual "Kirim Ulang" allowed but expected to fail And there is NO special error UI; the existing non-blocking silent retry policy is followed And the user sees the item in the queue (not blocked) and the detail page failure reason explains the cause (non-fixable) Source Traceability TSD: PK144 Section: C9 - Multi-device Race Conditions Scenario: C9.6 - Failure handling & user-facing behavior Acceptance Criteria: E8.US-5 AC6, AC7 Evidence Required Queue + detail screenshots for a multi-device failure. Notes / Gaps No gap.
▸OV-C9-POS-007	C9.7	mobile	Downloaded bundles are device-local and not shared across devices Verify downloaded bundles and queues are scoped per device.	P2	medium	draft	planned	PRE-OV-logged-in-online	md
Objective Verify downloaded bundles and queues are scoped per device. Preconditions See PRE-OV-logged-in-online And the same account is used on Device A and Device B Steps Download a bundle on Device A and inspect Device B Expected Result Then the bundle is stored on Device A only and is NOT synced/shared across devices And Device B must download its own bundle if needed And each device tracks its own bundles and its own Gagal Kirim queue, with backend reconciliation only at sync time Source Traceability TSD: PK144 Section: C9 - Multi-device Race Conditions Scenario: C9.7 - Device-local bundle scoping Acceptance Criteria: E8.US-5 AC1 Evidence Required Bundle presence on Device A vs absence on Device B. Notes / Gaps No gap.
▸C10 Cross-cutting Edge Cases & Failure Recovery mobile
▸OV-C10-EDGE-001	C10.1	mobile	Force-quit during download leaves no partial bundle (atomicity preserved) Verify force-quitting during a download preserves bundle atomicity.	P1	high	draft	planned	PRE-OV-download-center-open	md
Objective Verify force-quitting during a download preserves bundle atomicity. Preconditions See PRE-OV-download-center-open And a download is in progress Steps Force-quit the app during the download, then relaunch Expected Result Then there is NO partial bundle on next launch And the channel reverts to a NOT-downloaded state And atomicity is preserved Source Traceability TSD: PK144 Section: C10 - Cross-cutting Edge Cases & Failure Recovery Scenario: C10.1 - Force-quit recovery: clean state Acceptance Criteria: E11.US-1 AC1–AC4 Evidence Required Storage inspection on relaunch; channel state. Notes / Gaps Mirrors C1.16 mid-download handling; here the trigger is a force-quit.
▸OV-C10-EDGE-002	C10.1	mobile	Force-quit during silent sync resumes safely without duplicate records Verify force-quitting during silent sync resumes safely with no duplicate backend submissions.	P0	critical	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify force-quitting during silent sync resumes safely with no duplicate backend submissions. Preconditions See PRE-OV-gagal-kirim-has-items And a silent sync is in progress Steps Force-quit during the silent sync, then relaunch with a connection Expected Result Then the queue is re-evaluated on next launch + connection And pending items resume sync automatically (if Auto-Sync ON) And there are NO duplicate backend submissions Source Traceability TSD: PK144 Section: C10 - Cross-cutting Edge Cases & Failure Recovery Scenario: C10.1 - Force-quit recovery: clean state Acceptance Criteria: E11.US-1 AC1–AC4 Evidence Required Backend record count before/after; relaunch resume behavior. Notes / Gaps Idempotency contract (Concern #19, Critical) underpins duplicate prevention.
▸OV-C10-EDGE-003	C10.1	mobile	Force-quit during form filling preserves the in-progress draft Verify force-quitting while filling a form keeps the in-progress draft recoverable.	P1	high	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify force-quitting while filling a form keeps the in-progress draft recoverable. Preconditions See PRE-OV-mode-luring-active And a visitation is "Dalam Proses" with a form being filled Steps Force-quit during form filling, then relaunch Expected Result Then the in-progress draft (Dalam Proses) is still available in "Aktivitas" And data is preserved up to the last auto-save point And drafts respect end-of-day retention Source Traceability TSD: PK144 Section: C10 - Cross-cutting Edge Cases & Failure Recovery Scenario: C10.1 - Force-quit recovery: clean state Acceptance Criteria: E11.US-1 AC1–AC4 Evidence Required Aktivitas draft recovery after relaunch. Notes / Gaps Testing Concern #37 (cross-ref C2 #12): auto-save cadence determines the recovery point.
▸OV-C10-EDGE-004	C10.1	mobile	Force-quit with Mode Luring active keeps it active on relaunch Verify Mode Luring survives a force-quit and does not silently switch off.	P1	high	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify Mode Luring survives a force-quit and does not silently switch off. Preconditions See PRE-OV-mode-luring-active Steps Force-quit the app with Mode Luring active, then relaunch Expected Result Then Mode Luring REMAINS ACTIVE on relaunch And the persistent banner still displays And offline mode does NOT silently switch off Source Traceability TSD: PK144 Section: C10 - Cross-cutting Edge Cases & Failure Recovery Scenario: C10.1 - Force-quit recovery: clean state Acceptance Criteria: E11.US-1 AC1–AC4 Evidence Required Mode Luring state + banner after relaunch. Notes / Gaps No gap.
▸OV-C10-EDGE-005	C10.2	mobile	Auth token expiry does not disrupt offline work; sync holds until re-auth Verify offline operations are protected when the auth token expires, and sync resumes after re-authentication.	P0	critical	draft	planned	PRE-OV-mode-luring-active	md
Objective Verify offline operations are protected when the auth token expires, and sync resumes after re-authentication. Preconditions See PRE-OV-mode-luring-active And the backend session token has expired while working offline Steps Continue working with downloaded data while offline Let the network recover and a silent sync attempt run with the expired token Re-authenticate via the standard login flow Expected Result Then no re-authentication is prompted offline (no login screens or session-expiry popups) and the visit can be completed using local data And when sync attempts and auth fails, sync HOLDS pending items, waits for re-authentication, and items remain in Gagal Kirim (Gagal Terkirim), NOT marked as permanent failure And after re-authentication queued items resume sync automatically with no manual action And the non-blocking silent retry policy applies Source Traceability TSD: PK144 Section: C10 - Cross-cutting Edge Cases & Failure Recovery Scenario: C10.2 - Auth token expiry: offline operations protected Acceptance Criteria: E11.US-2 AC1–AC4 Evidence Required Behavior trace across offline work, failed sync hold, and post-re-auth resume. Notes / Gaps Testing Concern #38 (High): auth token refresh boundary contract (cross-PRD).
▸OV-C10-EDGE-006	C10.3	mobile	Cache clear or uninstall permanently deletes local unsynced data Verify the data-loss warning and behavior for cache clear / uninstall, plus reinstall recovery.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify the data-loss warning and behavior for cache clear / uninstall, plus reinstall recovery. Preconditions See PRE-OV-gagal-kirim-has-items And downloaded bundles and in-progress drafts exist Steps Read the Gagal Kirim warning Clear app cache (OS-level) Uninstall, then reinstall and log in Expected Result Then the Gagal Kirim page displays the warning that clearing cache OR uninstalling permanently deletes all queued submissions And clearing cache permanently removes all downloaded bundles, all in-progress drafts (Aktivitas reset), and all Gagal Kirim queue items And uninstalling causes the same data loss, with NONE restored on reinstall, and the app does not interfere with OS-level flows And on reinstall the employee must re-authenticate, backend-side data syncs back (channel list, journey plan, history), and only locally-captured unsynced data is permanently lost Source Traceability TSD: PK144 Section: C10 - Cross-cutting Edge Cases & Failure Recovery Scenario: C10.3 - Cache clear & uninstall: data loss expected Acceptance Criteria: E11.US-3 AC1–AC4 Evidence Required Before/after storage state for cache clear and uninstall/reinstall. Notes / Gaps Bundle-only counterpart is OV-C1-EDGE-021; this case covers the full queue + drafts.
▸OV-C10-POS-007	C10.4	mobile	Status and presence indicators stay consistent across surfaces with live updates Verify cross-surface consistency of status/presence indicators and live updates without page refresh.	P1	high	draft	planned	PRE-OV-gagal-kirim-has-items	md
Objective Verify cross-surface consistency of status/presence indicators and live updates without page refresh. Preconditions See PRE-OV-gagal-kirim-has-items Steps Exercise download completion, auto-purge/manual delete, and queue add/remove while observing all surfaces Expected Result Then queue status is consistent between list view and detail view And the homepage Gagal Kirim count matches the actual queue And the cloud-icon on cards matches the Download Center bundle list And live updates (no page refresh) occur for: download completion → cloud-icon appears; auto-purge or manual delete → cloud-icon disappears; queue item add/remove → count + list update Source Traceability TSD: PK144 Section: C10 - Cross-cutting Edge Cases & Failure Recovery Scenario: C10.4 - Cross-cutting: status consistency between surfaces Acceptance Criteria: Cross-cutting from multiple ACs Evidence Required Screen recording showing synchronized live updates across surfaces. Notes / Gaps Testing Concern #39 (Critical): race condition protection (delete/sync/purge concurrent).

Sections — what each C-group tests

Coverage by C-section

Distribution

Precondition composition

Flows — journeys

Suites — run sets

Testcases

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps

Expected Result

Source Traceability

Evidence Required

Notes / Gaps

Objective

Preconditions

Steps