# MYINFO v1.2 — PROJECT TASKS

**Status:** IMPLEMENTATION PLAN  
**Source of Truth:** `MYINFO_BLUEPRINT_FINAL_v1.2.md`  
**Target:** Android Native Kotlin + PHP 8.x + MySQL + Bootstrap 5  
**Principle:** Existing production database on hosting is authoritative. Do not redesign master tables unless explicitly approved.

---

# 0. WORKING RULES

## 0.1 General Rules

Every implementation task MUST:

1. Read this task file and the Blueprint before coding.
2. Respect dependencies.
3. Reuse existing code where possible.
4. Never hardcode production secrets.
5. Never connect Android directly to MySQL.
6. Never alter master production schema without explicit migration approval.
7. Never bypass Draft → Review → Publish for Admin data changes.
8. Keep Wilayah and Bank as separate modules.
9. Keep search module-scoped, not global cross-module.
10. Preserve backward compatibility unless a task explicitly introduces a breaking version.
11. Treat shared hosting + cPanel + Terminal as the production baseline.
12. Do not require permanent daemons/workers for core production operation.
13. Keep Commercial Data API completely separate from Android user authentication.
14. Never allow Commercial Submit API to bypass Draft → Review → Publish.

## 0.2 Required Task Output

For every completed PT, Claude Code / implementation agent must provide:

```text
SUMMARY
FILES CHANGED
DATABASE CHANGES
API CHANGES
SECURITY IMPACT
TESTS PERFORMED
KNOWN LIMITATIONS
DEFINITION OF DONE STATUS
```

## 0.3 Environment

Minimum environments:

```text
development
staging
production
```

Production credentials MUST NOT be committed.

---

# PHASE 1 — PROJECT FOUNDATION

## PT-001 · Repository & Project Bootstrap

**Goal.** Create the base repository structure for Backend, Admin Dashboard, Android, documentation, and environment templates.

**Scope.**
- Create top-level project structure.
- Add `.gitignore`.
- Add environment example files.
- Add README referencing the Blueprint and PT file.
- Prepare folders for backend/admin/android/docs.

**Files/Areas.**
```text
/
├── backend/
├── android/
├── docs/
├── scripts/
├── .gitignore
├── .env.example
└── README.md
```

**Depends on:** None.

**Implementation Notes.**
- Do not include secrets.
- Do not create speculative framework dependencies not required by Blueprint.
- Backend remains PHP 8.x.
- Admin remains Bootstrap 5.
- Android remains Kotlin native.

**Acceptance Criteria.**
- Repository structure exists.
- README identifies Blueprint as source of truth.
- No production secrets exist in repository.

**Definition of Done.**
Project can be cloned safely and each major component has a defined working area.

---

## PT-002 · Backend Environment & Database Connection Abstraction

**Goal.** Prepare PHP database connectivity without embedding hosting credentials.

**Scope.**
- Create configuration loader.
- Support `DB_HOST`, `DB_PORT`, `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `DB_CHARSET`.
- Add safe error handling.
- Add development connection test endpoint/script not exposed in production.

**Files/Areas.**
```text
backend/config/
backend/src/Database/
backend/scripts/
.env.example
```

**Depends on:** PT-001.

**Implementation Notes.**
- Use PDO with prepared statements.
- Default charset `utf8mb4`.
- Production error messages must not expose credentials or SQL internals.

**Acceptance Criteria.**
- Backend can connect when valid parameters are supplied.
- Connection fails safely when configuration is invalid.
- No credentials are committed.

**Definition of Done.**
Database connection can be established by only supplying environment parameters later.

---

## PT-003 · Existing Database Schema Inspector

**Goal.** Inspect and document the actual existing hosting database before implementation depends on assumed columns.

**Scope.**
- Read schema metadata for:
  - `tbl_propinsi`
  - `tbl_kabkota`
  - `tbl_kecamatan`
  - `tbl_kelurahan`
  - `tbl_bank`
  - `tbl_cabang`
- Produce schema report.
- Detect existing indexes and primary keys.
- Detect whether `Latitude` and `Longitude` already exist.

**Files/Areas.**
```text
backend/scripts/inspect_schema.php
docs/DATABASE_EXISTING_SCHEMA.md
```

**Depends on:** PT-002.

**Implementation Notes.**
- Read only.
- Do not alter production.
- Record actual field names, types, collations, indexes, nullable/default values.

**Acceptance Criteria.**
- Schema report matches actual database.
- Differences from Blueprint assumptions are clearly flagged.

**Definition of Done.**
All later database tasks can use confirmed schema instead of guesses.

---

## PT-004 · System Tables Migration Plan

**Goal.** Define non-master tables required by MyInfo without touching authoritative master data.

**Scope.**
Prepare migrations for:
- users
- user auth providers
- user sessions/devices
- login log
- admin users
- change requests
- audit log
- releases
- sync changes
- application/settings/config
- optional password reset/OTP storage
- rate-limit storage if DB-backed

**Files/Areas.**
```text
backend/migrations/
docs/SYSTEM_TABLES.md
```

**Depends on:** PT-003.

**Implementation Notes.**
- Migrations must be additive.
- Do not rename or rewrite master tables.
- Use timestamps consistently.
- JSON columns may be used when supported by actual MySQL version.

**Acceptance Criteria.**
- Migration files are idempotent or versioned.
- Rollback plan is documented.
- Master data is untouched.

**Definition of Done.**
System-layer schema is ready for controlled deployment.

---

## PT-005 · Backend Routing & API v1 Skeleton

**Goal.** Create the `/api/v1/` foundation.

**Scope.**
- HTTP router.
- JSON response format.
- Error format.
- Request parsing.
- Authentication middleware hook.
- Rate-limit middleware hook.
- API version namespace.

**Files/Areas.**
```text
backend/public/index.php
backend/src/Http/
backend/src/Middleware/
backend/src/Api/V1/
```

**Depends on:** PT-002.

**Implementation Notes.**
Standard response envelope:

```json
{
  "success": true,
  "data": {},
  "meta": {},
  "error": null
}
```

**Acceptance Criteria.**
- `/api/v1/health` works.
- Unknown endpoint returns structured 404.
- Invalid method returns structured 405.

**Definition of Done.**
API v1 can accept future modules without routing rewrites.

---

## PT-006 · Admin Dashboard Shell

**Goal.** Create the Bootstrap 5 Admin shell.

**Scope.**
- Login layout placeholder.
- Sidebar.
- Topbar.
- Responsive desktop-first content area.
- Role-aware navigation hooks.
- Theme-ready CSS.

**Files/Areas.**
```text
backend/admin/
backend/public/admin/
backend/public/assets/css/
backend/public/assets/js/
```

**Depends on:** PT-001.

**Implementation Notes.**
- Settings menu must be renderable only for Superadmin later.
- Mobile responsive, but desktop-first.

**Acceptance Criteria.**
- Dashboard shell works on desktop and mobile.
- Navigation component supports role filtering.

**Definition of Done.**
Admin pages can be added without rebuilding layout.

---

# PHASE 2 — ADMIN AUTH & SECURITY FOUNDATION

## PT-007 · Admin Authentication

**Goal.** Implement Admin email/password authentication.

**Scope.**
- Login.
- Logout.
- Password hashing.
- Session creation.
- ACTIVE/DISABLED handling.
- CSRF protection.

**Files/Areas.**
```text
backend/admin/auth/
backend/src/Auth/Admin/
```

**Depends on:** PT-004, PT-006.

**Implementation Notes.**
- No OTP for Admin v1.
- Use secure password hashing.
- Regenerate session identifier on login.

**Acceptance Criteria.**
- Valid admin can login.
- Invalid/disabled admin cannot login.
- Logout destroys session.

**Definition of Done.**
Admin Dashboard is protected by authenticated session.

---

## PT-008 · Admin Role Authorization

**Goal.** Implement `SUPERADMIN` and `EDITOR`.

**Scope.**
- Backend role middleware.
- Role-aware menu.
- 403 handling.
- Settings invisible to Editor.

**Files/Areas.**
```text
backend/src/Auth/Admin/
backend/admin/layout/
backend/admin/settings/
```

**Depends on:** PT-007.

**Implementation Notes.**
UI hiding is not sufficient. Server authorization is mandatory.

**Acceptance Criteria.**
- Editor cannot access Settings URL directly.
- Superadmin can.
- Editor sees no Settings menu.

**Definition of Done.**
Role enforcement exists at both UI and backend layers.

---

## PT-009 · Admin Session Timeout & Sensitive Re-auth

**Goal.** Secure long-lived Admin sessions.

**Scope.**
- Idle timeout ~30 minutes.
- Absolute session ~8–12 hours.
- Password re-auth for:
  - Publish
  - Rollback
  - API key changes
  - Wablas config
  - Google config
  - Security config

**Files/Areas.**
```text
backend/src/Auth/Admin/
backend/admin/components/
```

**Depends on:** PT-007.

**Acceptance Criteria.**
- Idle sessions expire.
- Sensitive actions require recent password confirmation.

**Definition of Done.**
Admin session security matches Blueprint.

---

# PHASE 3 — REMOTE CONFIG & APP CONTROL

## PT-010 · Settings Storage

**Goal.** Implement structured backend settings.

**Scope.**
Settings categories:
- Authentication
- Application
- Modules
- Maps
- Wablas
- Google
- Sync
- Versions
- Security

**Files/Areas.**
```text
backend/src/Settings/
backend/admin/settings/
```

**Depends on:** PT-004, PT-008.

**Implementation Notes.**
Sensitive values must not be returned in public config API.

**Acceptance Criteria.**
- Superadmin can read/update settings.
- Editor cannot access.
- Sensitive values are masked.

**Definition of Done.**
Server-controlled settings are persistent and secure.

---

## PT-011 · Remote Config API

**Goal.** Expose safe Android configuration.

**Scope.**
Return:
- application enabled
- maintenance
- auth mode
- login providers ON/OFF
- module Wilayah ON/OFF
- module Bank ON/OFF
- Nearby ON/OFF
- Maps ON/OFF
- latest/minimum app version
- store URL

**Files/Areas.**
```text
backend/src/Api/V1/Config/
```

**Depends on:** PT-005, PT-010.

**Acceptance Criteria.**
- `/api/v1/config` returns only client-safe values.
- Server secrets never appear.

**Definition of Done.**
Android behavior can be changed without rebuilding APK.

---

## PT-012 · Admin App Control UI

**Goal.** Allow Superadmin to control authentication and modules.

**Scope.**
UI controls:
```text
Application Enabled
Maintenance Mode
Auth Mode: REQUIRED / OPTIONAL / DISABLED
Email Login ON/OFF
Google Login ON/OFF
WhatsApp Login ON/OFF
Wilayah ON/OFF
Bank ON/OFF
Nearby ON/OFF
Maps ON/OFF
```

**Files/Areas.**
```text
backend/admin/settings/app-control/
```

**Depends on:** PT-010.

**Acceptance Criteria.**
- Changes persist.
- Remote config reflects changes.
- Editor cannot access.

**Definition of Done.**
App control is manageable from Dashboard.

---

# PHASE 4 — USER AUTHENTICATION BACKEND

## PT-013 · User Account Core

**Goal.** Implement user account model and status.

**Scope.**
- `ACTIVE`
- `SUSPENDED`
- `DISABLED`
- profile data
- verified email/phone timestamps

**Files/Areas.**
```text
backend/src/Auth/User/
```

**Depends on:** PT-004, PT-005.

**Acceptance Criteria.**
- User can be created/read/updated safely.
- Disabled/suspended rules are enforced.

**Definition of Done.**
MyInfo has a canonical user identity layer.

---

## PT-014 · Email/Password Login API

**Goal.** Implement Email + Password auth.

**Scope.**
- Register if enabled.
- Login.
- Password hashing.
- Email uniqueness.
- Error handling.
- Password reset foundation.

**Files/Areas.**
```text
backend/src/Api/V1/Auth/
backend/src/Auth/User/
```

**Depends on:** PT-013.

**Acceptance Criteria.**
- Valid credentials work.
- Invalid credentials fail safely.
- Disabled provider follows remote config.

**Definition of Done.**
Email authentication works end-to-end at API level.

---

## PT-015 · Access & Refresh Token System

**Goal.** Implement API session tokens.

**Scope.**
- Short-lived access token.
- Refresh token up to 30 days.
- Secure refresh storage.
- Rotation/revocation.
- Max 3 active devices.

**Files/Areas.**
```text
backend/src/Auth/Token/
backend/src/Middleware/Auth/
```

**Depends on:** PT-013.

**Acceptance Criteria.**
- Access token validates.
- Refresh works.
- Revoked tokens fail.
- Fourth device is blocked until a device is revoked.

**Definition of Done.**
User sessions are secure and device-aware.

---

## PT-016 · Device Session Management API

**Goal.** Let users/admins view and revoke device sessions.

**Scope.**
- List devices.
- Revoke selected device.
- Logout all devices.
- Store device model, Android version, app version, IP, last active.

**Files/Areas.**
```text
backend/src/Api/V1/Profile/Devices/
backend/admin/android-users/
```

**Depends on:** PT-015.

**Acceptance Criteria.**
- User sees own sessions only.
- Admin can revoke user sessions.
- Revoked device loses API access.

**Definition of Done.**
Device management works for max-3-device policy.

---

## PT-017 · Password Change Session Revocation

**Goal.** Revoke all other devices after password change.

**Scope.**
- Change password endpoint.
- Preserve current session.
- Revoke other refresh sessions.

**Depends on:** PT-015.

**Acceptance Criteria.**
- Current device remains authenticated.
- Other devices are revoked.

**Definition of Done.**
Password-change security behavior matches Blueprint.

---

## PT-018 · Wablas OTP Service

**Goal.** Implement server-side WhatsApp OTP through Wablas.

**Scope.**
- Generate 6-digit OTP.
- Hash OTP at rest.
- 5-minute expiry.
- 60-second resend cooldown.
- Attempt limit.
- Wablas API integration.
- Provider ON/OFF support.

**Files/Areas.**
```text
backend/src/Services/Wablas/
backend/src/Api/V1/Auth/Otp/
```

**Depends on:** PT-010, PT-013.

**Implementation Notes.**
Wablas keys remain server-only.

**Acceptance Criteria.**
- OTP sends.
- OTP expires.
- Wrong attempts are limited.
- Disabled provider returns controlled response.

**Definition of Done.**
WhatsApp OTP login backend is production-ready.

---

## PT-019 · Google Login Verification Backend

**Goal.** Verify Google identity and map to MyInfo user.

**Scope.**
- Accept Google credential from Android.
- Verify on backend.
- Create/link MyInfo user.
- Require verified phone number before complete access.

**Files/Areas.**
```text
backend/src/Api/V1/Auth/Google/
backend/src/Auth/Google/
```

**Depends on:** PT-013.

**Acceptance Criteria.**
- Invalid credential rejected.
- Valid Google identity maps to correct user.
- New Google account enters phone verification flow.

**Definition of Done.**
Google auth backend is ready for Android integration.

---

## PT-020 · Account Linking Rules

**Goal.** Support one MyInfo user with EMAIL/GOOGLE/PHONE providers.

**Scope.**
- Link verified phone.
- Link verified Google identity.
- Prevent automatic merge on conflicts.
- Create conflict response flow.

**Depends on:** PT-014, PT-018, PT-019.

**Acceptance Criteria.**
- Same verified phone maps to existing user where safe.
- Conflicting identities are not auto-merged.

**Definition of Done.**
Account linking is deterministic and safe.

---

## PT-021 · Login Audit Log

**Goal.** Record authentication events.

**Scope.**
Store:
- User
- Provider
- IP
- Device
- Android version
- App version
- Success/Failed
- Timestamp

**Depends on:** PT-014, PT-018, PT-019.

**Acceptance Criteria.**
- Successful and failed login attempts are logged.
- Superadmin can view them.

**Definition of Done.**
Authentication troubleshooting and security history are available.

---

# PHASE 5 — WILAYAH BACKEND

## PT-022 · Wilayah Repository Adapter

**Goal.** Create PHP read adapters for existing Wilayah tables.

**Scope.**
- `tbl_propinsi`
- `tbl_kabkota`
- `tbl_kecamatan`
- `tbl_kelurahan`

**Files/Areas.**
```text
backend/src/Modules/Wilayah/
```

**Depends on:** PT-003.

**Implementation Notes.**
Use actual schema names from PT-003.

**Acceptance Criteria.**
- Hierarchical reads work.
- No production schema changes required.

**Definition of Done.**
Backend can read authoritative Wilayah data safely.

---

## PT-023 · Wilayah Hierarchy API

**Goal.** Expose hierarchical data endpoints.

**Scope.**
- Provinces.
- Kab/Kota by province.
- Kecamatan by kab/kota.
- Kelurahan by kecamatan.

**Files/Areas.**
```text
backend/src/Api/V1/Wilayah/
```

**Depends on:** PT-005, PT-022.

**Acceptance Criteria.**
- Parent filters return correct children.
- Codes remain strings.

**Definition of Done.**
Android can browse Wilayah hierarchy via API.

---

## PT-024 · Wilayah Search API

**Goal.** Provide server-side module-scoped Wilayah search for sync/admin/fallback use.

**Scope.**
Search:
- names
- codes
- postal codes

**Depends on:** PT-022.

**Acceptance Criteria.**
- Search does not return Bank data.
- Duplicate postal codes can return multiple kelurahan.

**Definition of Done.**
Wilayah search behavior matches data model.

---

# PHASE 6 — BANK BACKEND

## PT-025 · Bank Repository Adapter

**Goal.** Read `tbl_bank` and `tbl_cabang` without redesigning them.

**Scope.**
- Banks.
- Branches.
- Status filter.
- Wilayah joins.
- Postal code resolution from `tbl_kelurahan`.

**Files/Areas.**
```text
backend/src/Modules/Bank/
```

**Depends on:** PT-003, PT-022.

**Acceptance Criteria.**
- Branch detail includes full address hierarchy.
- Kode Pos comes from Wilayah master.

**Definition of Done.**
Bank backend reads authoritative master correctly.

---

## PT-026 · Bank & Branch API

**Goal.** Expose Bank module endpoints.

**Scope.**
- list banks
- bank detail
- list/search branches
- branch detail
- filter by bank
- filter by wilayah
- filter by type

**Files/Areas.**
```text
backend/src/Api/V1/Bank/
```

**Depends on:** PT-005, PT-025.

**Acceptance Criteria.**
- Search remains Bank-only.
- Filters combine correctly.
- INACTIVE branches are excluded from public results by default.

**Definition of Done.**
Bank data is consumable by Android.

---

## PT-027 · Latitude/Longitude Schema Migration

**Goal.** Ensure `tbl_cabang` can store coordinates.

**Scope.**
- Check PT-003 result.
- If missing, create approved additive migration:
  - `Latitude DECIMAL(10,8) NULL`
  - `Longitude DECIMAL(11,8) NULL`
- Add appropriate index only if useful.

**Depends on:** PT-003.

**Implementation Notes.**
Do not execute against production without explicit approval.

**Acceptance Criteria.**
- Migration is additive.
- Existing rows are preserved.

**Definition of Done.**
Branch coordinates can be stored safely.

---

## PT-028 · Plus Code Decoder Service

**Goal.** Convert full/global Plus Code to coordinate center without external API.

**Scope.**
- Validate Plus Code.
- Decode full code.
- Return center latitude/longitude.
- Return validation errors.

**Files/Areas.**
```text
backend/src/Services/Location/PlusCode/
```

**Depends on:** PT-025.

**Acceptance Criteria.**
- Valid full Plus Codes decode.
- Invalid codes fail safely.
- Service is unit-tested.

**Definition of Done.**
Full Plus Code can populate coordinates server-side.

---

## PT-029 · Short Plus Code Fallback Service

**Goal.** Resolve short/compound Plus Code when direct decode is insufficient.

**Scope.**
- Use address/wilayah context.
- Integrate Google geocoding fallback when configured.
- Handle provider-disabled state.

**Files/Areas.**
```text
backend/src/Services/Location/Geocoding/
```

**Depends on:** PT-010, PT-028.

**Acceptance Criteria.**
- Short code with sufficient context can resolve.
- Google key remains server/config controlled.
- Errors are structured.

**Definition of Done.**
Short Plus Codes have a controlled fallback path.

---

## PT-030 · Admin Button “Update Lat/Lng dari Plus Code”

**Goal.** Add branch-form action to calculate Latitude/Longitude.

**Scope.**
Button:
```text
[ UPDATE LAT/LNG DARI PLUS CODE ]
```

Flow:
- Read CodePlus.
- Validate.
- Decode / fallback resolve.
- Fill Latitude/Longitude form fields.
- Refresh map preview.
- Do not publish automatically.

**Files/Areas.**
```text
backend/admin/bank/cabang/
backend/public/assets/js/
```

**Depends on:** PT-028, PT-029.

**Acceptance Criteria.**
- Full Plus Code fills coordinates.
- Error shown for invalid code.
- Map preview refreshes.

**Definition of Done.**
Admin can derive coordinates from pasted Plus Code safely.

---

## PT-031 · Admin Map Preview & Location Validation

**Goal.** Let Admin visually confirm branch coordinates.

**Scope.**
- Embedded map.
- Marker.
- Current CodePlus/lat/lng display.
- “Buka di Google Maps”.
- “Validate Location” state.

**Depends on:** PT-030.

**Acceptance Criteria.**
- Marker reflects form coordinates.
- Admin can visually validate before save.

**Definition of Done.**
Location data can be checked before entering Draft workflow.

---

## PT-032 · Bulk Missing Lat/Lng Update

**Goal.** Process branches with CodePlus but missing coordinates.

**Scope.**
Select:
```sql
CodePlus IS NOT NULL
AND (Latitude IS NULL OR Longitude IS NULL)
```

Results:
```text
SUCCESS
INVALID CODE
NEEDS CONTEXT
API ERROR
UNCHANGED
```

**Depends on:** PT-028, PT-029.

**Implementation Notes.**
Results must become Draft changes, never direct production publish.

**Acceptance Criteria.**
- Bulk process is resumable or bounded.
- Summary and row-level result are available.
- No direct production write bypasses workflow.

**Definition of Done.**
Large branch datasets can be enriched efficiently and safely.

---

## PT-033 · Nearby Branch Query Service

**Goal.** Return nearby branches using stored coordinates.

**Scope.**
- Radius: 1/2/5/10/25 km.
- Default 5 km.
- Optional bank filter.
- ACTIVE only.
- Sort nearest first.

**Depends on:** PT-027, PT-025.

**Acceptance Criteria.**
- Distances are correct within expected tolerance.
- Radius/filter behavior works.

**Definition of Done.**
Backend can support Nearby if Android requires remote fallback.

---

# PHASE 7 — ADMIN DATA WORKFLOW

## PT-034 · Generic Change Request Engine

**Goal.** Implement staging without duplicate draft tables.

**Scope.**
Create/use `tbl_change_request` with:
- module
- table
- record key
- action
- old JSON
- new JSON
- status
- creator/reviewer/publish timestamps

**Depends on:** PT-004, PT-008.

**Acceptance Criteria.**
- INSERT/UPDATE/DELETE can be represented.
- Production remains unchanged until Publish.

**Definition of Done.**
Draft workflow foundation works generically.

---

## PT-035 · Wilayah Admin CRUD to Draft

**Goal.** Add Wilayah management that writes Change Requests, not production.

**Scope.**
- Provinsi.
- Kab/Kota.
- Kecamatan.
- Kelurahan.
- Insert/update/delete draft.

**Depends on:** PT-022, PT-034.

**Acceptance Criteria.**
- Editing creates Draft.
- Production values remain unchanged.

**Definition of Done.**
Editor can prepare Wilayah changes safely.

---

## PT-036 · Bank Admin CRUD to Draft

**Goal.** Add Bank/Cabang management using Change Requests.

**Scope.**
- `tbl_bank`.
- `tbl_cabang`.
- Map/location fields.
- ACTIVE/INACTIVE.

**Depends on:** PT-025, PT-031, PT-034.

**Acceptance Criteria.**
- Branch edits create Draft.
- Production remains unchanged.

**Definition of Done.**
Editor can prepare Bank changes safely.

---

## PT-037 · Review Queue

**Goal.** Let Superadmin review submitted Drafts.

**Scope.**
- WAITING_REVIEW list.
- Old vs New comparison.
- Approve.
- Reject with reason.
- Filter by module/user/date.

**Depends on:** PT-034.

**Acceptance Criteria.**
- Superadmin can approve/reject.
- Editor cannot publish.

**Definition of Done.**
Review stage is functional.

---

## PT-038 · Publish Engine

**Goal.** Apply approved Change Requests transactionally to production.

**Scope.**
- Validate again before write.
- Apply changes.
- Audit.
- Sync change generation.
- Release/version bump.
- Mark PUBLISHED.

**Depends on:** PT-037, PT-044, PT-047.

**Acceptance Criteria.**
- Failed publish rolls back transaction.
- Successful publish updates production + logs atomically.

**Definition of Done.**
Approved data can safely reach production.

---

# PHASE 8 — CSV IMPORT

## PT-039 · CSV Upload & Parser

**Goal.** Upload CSV without direct database writes.

**Scope.**
- Wilayah import.
- Bank/Cabang import.
- File validation.
- Column mapping foundation.

**Depends on:** PT-006.

**Acceptance Criteria.**
- Invalid file rejected.
- Parsed data is staged in memory/temp storage only.

**Definition of Done.**
CSV can be safely parsed.

---

## PT-040 · CSV Validation & Compare

**Goal.** Classify import rows before commit.

**Scope.**
Statuses:
```text
NEW
UPDATE
UNCHANGED
ERROR
DUPLICATE
```

Validation:
- unique keys
- required fields
- parent relationships
- existing production comparison

**Depends on:** PT-039, PT-022, PT-025.

**Acceptance Criteria.**
- Duplicate code detected.
- Missing parent detected.
- Unchanged rows do not create Draft.

**Definition of Done.**
Admin sees exact impact before import.

---

## PT-041 · CSV Preview UI

**Goal.** Show validation summary and row differences.

**Scope.**
- Counts by status.
- Error details.
- Old/New diff for UPDATE.
- Filter result category.

**Depends on:** PT-040.

**Acceptance Criteria.**
- Admin can inspect errors and updates.
- No commit button if blocking errors remain, unless policy allows valid-row partial staging.

**Definition of Done.**
Import is reviewable before staging.

---

## PT-042 · Commit CSV to Draft

**Goal.** Convert valid NEW/UPDATE rows into Change Requests.

**Depends on:** PT-034, PT-041.

**Acceptance Criteria.**
- Only eligible rows become Draft.
- Production remains untouched.

**Definition of Done.**
CSV import integrates with standard review workflow.

---

# PHASE 9 — AUDIT, RELEASE & ROLLBACK

## PT-043 · Admin Audit Log

**Goal.** Record admin data actions.

**Scope.**
Fields:
- admin
- table
- record key
- action
- old JSON
- new JSON
- IP
- user agent
- timestamp

**Depends on:** PT-004, PT-007.

**Acceptance Criteria.**
- Insert/update/delete/publish events are traceable.

**Definition of Done.**
Administrative history is durable.

---

## PT-044 · Audit Log UI

**Goal.** Provide role-aware audit viewer.

**Scope.**
- Editor: own activity.
- Superadmin: all.
- Filters by admin/module/table/action/date/key.

**Depends on:** PT-043.

**Acceptance Criteria.**
- Permissions enforced.
- Old/New comparison readable.

**Definition of Done.**
Audit trail is usable operationally.

---

## PT-045 · Module Release Versioning

**Goal.** Maintain independent versions.

**Scope.**
- Wilayah version.
- Bank version.
- Release metadata.
- Publish linkage.

**Depends on:** PT-004.

**Acceptance Criteria.**
- Wilayah and Bank version independently.
- Version only increments forward.

**Definition of Done.**
Every publish can produce a module release.

---

## PT-046 · Rollback Engine

**Goal.** Restore a selected prior release as a new version.

**Scope.**
Example:
```text
v28
v29 bad
rollback -> v30 containing restored state
```

**Depends on:** PT-045, PT-043.

**Acceptance Criteria.**
- Version never decreases.
- Rollback is audited.
- Sync sees rollback as forward change.

**Definition of Done.**
Operational rollback is safe for Android sync.

---

# PHASE 10 — SYNC BACKEND

## PT-047 · Sync Change Log

**Goal.** Generate machine-readable changes for Android.

**Scope.**
`INSERT`, `UPDATE`, `DELETE` tombstones with:
- SyncID
- module
- table
- record key
- data version
- timestamp

**Depends on:** PT-004, PT-045.

**Acceptance Criteria.**
- Every published data mutation creates sync entry.

**Definition of Done.**
Incremental sync has a canonical source.

---

## PT-048 · Sync Status API

**Goal.** Tell Android current versions and recommended update strategy.

**Scope.**
Return:
- current Wilayah version
- current Bank version
- incremental/snapshot strategy
- optional minimum sync requirements

**Depends on:** PT-047.

**Acceptance Criteria.**
- Android can compare local/server versions.

**Definition of Done.**
Client knows whether it needs updates.

---

## PT-049 · Incremental Sync API

**Goal.** Return changes after a client SyncID.

**Scope.**
- Pagination/batching.
- Module filtering.
- Tombstones.
- Integrity metadata.

**Depends on:** PT-047.

**Acceptance Criteria.**
- Client can catch up without full download.
- Ordering is deterministic.

**Definition of Done.**
Incremental sync is complete.

---

## PT-050 · Snapshot Builder

**Goal.** Build full module snapshots for outdated clients.

**Scope.**
- Wilayah snapshot.
- Bank snapshot.
- Version metadata.
- checksum/hash.
- compressed download format.

**Depends on:** PT-022, PT-025, PT-045.

**Acceptance Criteria.**
- Snapshot can rebuild client local DB.
- Checksum validation works.

**Definition of Done.**
Full reset/update path exists.

---

## PT-051 · Snapshot Sync API

**Goal.** Serve current snapshot metadata/files securely.

**Depends on:** PT-050.

**Acceptance Criteria.**
- Client receives correct module snapshot.
- Version/checksum included.

**Definition of Done.**
Server supports full snapshot update.

---

# PHASE 11 — ANDROID FOUNDATION

## PT-052 · Android Project Bootstrap

**Goal.** Create Kotlin Android app foundation.

**Scope.**
- package namespace.
- app modules/packages.
- Material-style theme.
- min/target SDK decision documented.
- dependency management.

**Files/Areas.**
```text
android/
```

**Depends on:** PT-001.

**Acceptance Criteria.**
- App builds.
- No production secrets embedded.

**Definition of Done.**
Android foundation is ready.

---

## PT-053 · Android Theme & Design Tokens

**Goal.** Implement Light/Dark/System theme.

**Scope.**
- typography.
- spacing.
- shapes.
- component styling.
- System default.

**Depends on:** PT-052.

**Acceptance Criteria.**
- Light/Dark/System works.
- UI remains readable.

**Definition of Done.**
Design baseline exists.

---

## PT-054 · Android Navigation Shell

**Goal.** Implement Bottom Navigation.

**Scope.**
```text
HOME
WILAYAH
BANK
FAVORIT
PROFIL
```

**Depends on:** PT-052, PT-053.

**Acceptance Criteria.**
- Back stack behaves correctly.
- State hooks prepared.

**Definition of Done.**
Primary navigation works.

---

## PT-055 · Android Remote Config Client

**Goal.** Load `/api/v1/config`.

**Scope.**
- cache config locally.
- auth mode.
- provider toggles.
- feature/module toggles.
- maintenance.
- app versions.

**Depends on:** PT-011, PT-052.

**Acceptance Criteria.**
- UI responds to config.
- Last known safe config available offline.

**Definition of Done.**
Server-controlled behavior works on client.

---

## PT-056 · Android Secure Token Storage

**Goal.** Store access/refresh tokens outside Room.

**Scope.**
- encrypted/secure Android storage.
- token clear on logout/revoke.

**Depends on:** PT-052, PT-015.

**Acceptance Criteria.**
- Tokens are not stored in plaintext Room/preferences.

**Definition of Done.**
Auth secrets are stored safely.

---

# PHASE 12 — ANDROID AUTH

## PT-057 · Android Email Login

**Goal.** Implement email/password UI and API flow.

**Depends on:** PT-014, PT-055, PT-056.

**Acceptance Criteria.**
- Provider hidden if disabled.
- Login stores session securely.

**Definition of Done.**
Email auth works on device.

---

## PT-058 · Android WhatsApp OTP Login

**Goal.** Implement phone + OTP flow.

**Scope.**
- input phone.
- request OTP.
- resend countdown.
- verify OTP.
- no Phone/SMS/Contacts permission.

**Depends on:** PT-018, PT-055, PT-056.

**Acceptance Criteria.**
- OTP login works without sensitive phone permissions.

**Definition of Done.**
WhatsApp auth works on Android.

---

## PT-059 · Android Google Login

**Goal.** Implement Google authentication using current recommended Android credential flow.

**Scope.**
- Google sign-in.
- send credential to backend.
- handle required phone verification.

**Depends on:** PT-019, PT-020, PT-055, PT-056.

**Acceptance Criteria.**
- Google identity is verified by backend.
- phone verification is enforced for new accounts.

**Definition of Done.**
Google auth works end-to-end.

---

## PT-060 · Android Auth Mode Routing

**Goal.** Enforce REQUIRED/OPTIONAL/DISABLED.

**Depends on:** PT-055, PT-057, PT-058, PT-059.

**Acceptance Criteria.**
- REQUIRED blocks Home until authenticated.
- OPTIONAL supports Guest.
- DISABLED hides login.

**Definition of Done.**
Auth routing matches Dashboard config.

---

## PT-061 · Android Device Management

**Goal.** Show user’s active devices and revoke sessions.

**Depends on:** PT-016, PT-056.

**Acceptance Criteria.**
- Current and other devices shown.
- Device revoke works.

**Definition of Done.**
3-device account management is usable.

---

# PHASE 13 — ANDROID LOCAL DATABASE

## PT-062 · Encrypted Room Database Foundation

**Goal.** Create encrypted local data layer.

**Scope.**
Entities:
- Province
- KabKota
- Kecamatan
- Kelurahan
- Bank
- Cabang
- sync metadata
- Favorite
- Search History

**Depends on:** PT-052.

**Acceptance Criteria.**
- DB file is not plain SQLite-readable without required key mechanism.
- DB opens reliably.

**Definition of Done.**
Offline encrypted storage exists.

---

## PT-063 · Bundled Initial Snapshot Import

**Goal.** Ship initial Wilayah + Bank data with APK.

**Scope.**
- import packaged snapshot.
- validate version/checksum.
- initialize Room.

**Depends on:** PT-050, PT-062.

**Acceptance Criteria.**
- Fresh install works offline immediately.

**Definition of Done.**
No first-launch master download is required.

---

# PHASE 14 — ANDROID WILAYAH

## PT-064 · Wilayah Local Repository & DAO

**Goal.** Implement local hierarchy/search access.

**Depends on:** PT-062.

**Acceptance Criteria.**
- Parent-child queries fast.
- Postal code query can return multiple kelurahan.

**Definition of Done.**
Wilayah module is local-first.

---

## PT-065 · Wilayah Landing Screen

**Goal.** Implement:
```text
[ Cari Wilayah / Kode ]
[ TELUSURI WILAYAH ]
```

**Depends on:** PT-054, PT-064.

**Acceptance Criteria.**
- Two paths clearly separated.

**Definition of Done.**
Wilayah module entry is complete.

---

## PT-066 · Wilayah Real-time Search

**Goal.** Search local DB while typing.

**Scope.**
- name
- codes
- postal code
- 2–3 character threshold where appropriate
- debounce

**Depends on:** PT-064, PT-065.

**Acceptance Criteria.**
- No network required.
- Results appear quickly.

**Definition of Done.**
Realtime Wilayah search works offline.

---

## PT-067 · Wilayah Hierarchical Browse

**Goal.** Implement separate screens:
```text
Provinsi -> Kab/Kota -> Kecamatan -> Kelurahan
```

**Depends on:** PT-064.

**Acceptance Criteria.**
- Search available per level.
- Back retains selection/scroll.

**Definition of Done.**
Browse hierarchy is complete.

---

## PT-068 · Wilayah Detail

**Goal.** Display all administrative names/codes and postal code.

**Scope.**
- Copy.
- Share.
- Favorite.

**Depends on:** PT-067, PT-073.

**Acceptance Criteria.**
- All codes visible.
- Share text readable.

**Definition of Done.**
Wilayah detail fulfills product purpose.

---

# PHASE 15 — ANDROID BANK

## PT-069 · Bank Local Repository & DAO

**Goal.** Support bank/branch local queries and filters.

**Depends on:** PT-062.

**Acceptance Criteria.**
- Bank search is module-only.
- ACTIVE filtering supported.

**Definition of Done.**
Bank module is local-first.

---

## PT-070 · Bank Landing Screen

**Goal.** Implement:
```text
[ CARI CABANG ]
[ PILIH BANK ]
[ BANK TERDEKAT ]
```

**Depends on:** PT-054, PT-069.

**Definition of Done.**
Bank entry provides required two paths + Nearby.

---

## PT-071 · Bank Search & Filters

**Goal.** Search:
- KodeBank
- NamaBank
- KodeCabang
- NamaCabang

Filter:
- Bank
- Wilayah
- Type

**Depends on:** PT-069, PT-070.

**Acceptance Criteria.**
- Filters persist on Back.
- No Wilayah global search blending.

**Definition of Done.**
Bank discovery works offline.

---

## PT-072 · Branch Detail + Embedded Map

**Goal.** Show full branch data and embedded map.

**Scope.**
- bank code
- branch code
- type
- address
- full wilayah
- postal code
- Plus Code
- favorite/copy/share
- map marker

**Depends on:** PT-069, PT-074.

**Acceptance Criteria.**
- Text detail appears even if map tiles fail.
- Map obeys feature kill switch.

**Definition of Done.**
Branch detail matches Blueprint.

---

# PHASE 16 — FAVORITE & HISTORY

## PT-073 · Favorite Local Storage

**Goal.** Save Wilayah and Cabang favorites locally.

**Scope.**
- namespace by local UserID/Guest.
- list/remove.
- no server sync.

**Depends on:** PT-062.

**Acceptance Criteria.**
- Different local users do not see each other’s favorites.

**Definition of Done.**
Favorite behavior matches privacy design.

---

## PT-074 · Search History Local Storage

**Goal.** Store module search history locally.

**Scope.**
- Wilayah history.
- Bank history.
- clear item/all.
- user/guest namespace.

**Depends on:** PT-062.

**Definition of Done.**
History works locally without server.

---

# PHASE 17 — MAPS & NEARBY ANDROID

## PT-075 · Location Permission Flow

**Goal.** Request location only when Nearby is used.

**Scope.**
- coarse/fine location.
- rationale UI.
- denied state.
- no background location.

**Depends on:** PT-070.

**Acceptance Criteria.**
- No location prompt at splash/login.
- Denial does not block other modules.

**Definition of Done.**
Permission behavior is policy-compliant and user-friendly.

---

## PT-076 · Nearby Distance Engine

**Goal.** Calculate branch distance using local coordinates.

**Scope.**
- 1/2/5/10/25 km.
- default 5 km.
- bank filter.
- sort ascending distance.

**Depends on:** PT-069, PT-075.

**Acceptance Criteria.**
- Works offline if location available.
- Excludes missing coordinates gracefully.

**Definition of Done.**
Nearby list logic works locally.

---

## PT-077 · Nearby Map + List UI

**Goal.** Render embedded map above sorted branch list.

**Scope.**
- user marker.
- branch markers.
- bank/radius filters.
- marker/list interaction.

**Depends on:** PT-076.

**Acceptance Criteria.**
- Map and list remain synchronized.
- List works if map tiles unavailable.

**Definition of Done.**
Nearby UX matches Blueprint.

---

# PHASE 18 — ANDROID SYNC

## PT-078 · Android Sync Metadata

**Goal.** Store per-module versions and last SyncID.

**Depends on:** PT-062.

**Definition of Done.**
Client can track Wilayah and Bank independently.

---

## PT-079 · Incremental Sync Client

**Goal.** Apply server changes transactionally.

**Scope.**
- INSERT
- UPDATE
- DELETE tombstone
- batching
- retry

**Depends on:** PT-049, PT-078.

**Acceptance Criteria.**
- Failed batch does not corrupt local DB.
- Ordering preserved.

**Definition of Done.**
Incremental updates work safely.

---

## PT-080 · Full Snapshot Replacement Client

**Goal.** Replace outdated local module data from snapshot.

**Scope.**
- download
- checksum
- decrypt/import as required
- transactional replace
- version update

**Depends on:** PT-051, PT-078.

**Acceptance Criteria.**
- Interrupted update leaves old valid data usable.
- Successful update switches atomically.

**Definition of Done.**
Long-outdated clients can recover.

---

## PT-081 · Silent Background Sync

**Goal.** Check/apply normal data updates without blocking Home.

**Depends on:** PT-079, PT-080, PT-055.

**Acceptance Criteria.**
- User can use app during normal sync.
- Force app update remains separate.

**Definition of Done.**
Sync behaves silently by default.

---

# PHASE 19 — APP VERSION & OFFLINE MODES

## PT-082 · Android App Version Enforcement

**Goal.** Apply latest/minimum version policy.

**Scope.**
- optional update.
- forced update.
- Play Store URL.

**Depends on:** PT-055.

**Acceptance Criteria.**
- App below minimum is blocked until update.
- Supported older version can continue if force not required.

**Definition of Done.**
Server controls APK compatibility.

---

## PT-083 · Maintenance Mode Screen

**Goal.** Respect server maintenance state.

**Depends on:** PT-055.

**Acceptance Criteria.**
- Screen is clear.
- Offline behavior follows configured policy.

**Definition of Done.**
Maintenance is controllable without rebuild.

---

## PT-084 · Offline Mode Handling

**Goal.** Keep static modules usable when server is unavailable.

**Scope.**
Available:
- Wilayah
- Bank
- Search
- Favorite
- History
- Nearby local distance

Unavailable:
- login new
- OTP
- Google auth
- sync
- online map tiles

**Depends on:** PT-060, PT-062.

**Acceptance Criteria.**
- Network failure does not close app.

**Definition of Done.**
Offline-first promise is met.

---

# PHASE 20 — ADMIN DASHBOARD OPERATIONS

## PT-085 · Dashboard Statistics

**Goal.** Show data and Android user statistics.

**Scope.**
- province/kabkota/kecamatan/kelurahan counts.
- banks/branches.
- drafts/review.
- last publish.
- total users.
- active today/7/30 days.

**Depends on:** PT-013, PT-034, PT-045.

**Definition of Done.**
Dashboard provides operational overview.

---

## PT-086 · Android User Management UI

**Goal.** Show user/account/device information.

**Scope.**
- name
- email
- phone
- provider
- last IP
- login
- active
- app version
- data version
- status
- device revoke/logout all
- suspend/disable

**Depends on:** PT-016, PT-021.

**Definition of Done.**
Superadmin can manage Android users.

---

# PHASE 21 — SECURITY HARDENING

## PT-087 · API Rate Limiting

**Goal.** Protect auth, OTP, reset, sync and normal APIs.

**Scope.**
Rate by:
- IP
- UserID
- phone
- endpoint

**Depends on:** PT-005.

**Acceptance Criteria.**
- Abuse receives controlled 429 response.
- OTP cannot be spammed.

**Definition of Done.**
Baseline API abuse protection is active.

---

## PT-088 · HTTPS & Cleartext Enforcement

**Goal.** Enforce HTTPS.

**Scope.**
- backend redirects/rejects HTTP where appropriate.
- Android cleartext disabled.

**Depends on:** PT-005, PT-052.

**Definition of Done.**
Production traffic uses HTTPS only.

---

## PT-089 · Secrets & Configuration Audit

**Goal.** Verify secrets never leak.

**Scope.**
- DB password.
- Wablas secret.
- Google private config.
- signing credentials.
- token/JWT secrets.

**Depends on:** PT-010, PT-052.

**Acceptance Criteria.**
- Secret scan finds no committed credential.

**Definition of Done.**
Repository passes secret-handling review.

---

## PT-090 · Permission Audit

**Goal.** Ensure Android requests only approved permissions.

**Allowed:**
```text
INTERNET
ACCESS_COARSE_LOCATION
ACCESS_FINE_LOCATION
POST_NOTIFICATIONS
```

**Forbidden unless future approved PT:**
```text
READ_PHONE_NUMBERS
READ_PHONE_STATE
READ_SMS
READ_CONTACTS
CALL_LOG
ACCESS_BACKGROUND_LOCATION
CAMERA
MICROPHONE
```

**Depends on:** PT-075.

**Definition of Done.**
Manifest and runtime flows match approved permission matrix.

---

# PHASE 22 — QA

## PT-091 · Backend Unit & Integration Tests

**Goal.** Test core backend modules.

**Scope.**
- auth
- OTP
- account linking
- wilayah hierarchy
- bank filters
- Plus Code
- sync
- publish
- rollback

**Depends on:** Relevant backend PTs.

**Definition of Done.**
Critical backend behavior has automated coverage.

---

## PT-092 · Android Unit & Repository Tests

**Goal.** Test local repositories and sync logic.

**Scope.**
- hierarchy.
- search.
- favorite/history isolation.
- nearby distance.
- incremental sync.
- snapshot replace.

**Depends on:** Relevant Android PTs.

**Definition of Done.**
Critical offline/local logic is covered.

---

## PT-093 · End-to-End Auth QA

**Goal.** Test all auth modes/providers.

**Cases.**
```text
REQUIRED + Email
REQUIRED + Google
REQUIRED + WhatsApp
OPTIONAL Guest
DISABLED
Provider toggle OFF
3-device maximum
Password change revoke
Suspended user
```

**Definition of Done.**
Auth matrix passes.

---

## PT-094 · End-to-End Data QA

**Goal.** Validate Wilayah and Bank against production/staging source.

**Scope.**
- hierarchy.
- duplicate postal codes.
- bank/cabang joins.
- CodePlus.
- coordinates.
- map marker.

**Definition of Done.**
Data shown in Android matches authoritative source.

---

## PT-095 · Offline & Recovery QA

**Goal.** Test loss of server/network safely.

**Cases.**
- startup offline after prior login.
- sync interrupted.
- snapshot interrupted.
- map offline.
- server 500.
- config unavailable.

**Definition of Done.**
App remains usable and database is not corrupted.

---

## PT-096 · Publish/Rollback QA

**Goal.** Test full Admin data lifecycle.

**Flow.**
```text
Edit
Draft
Review
Publish
Sync Android
Rollback
New Version
Sync Android
```

**Definition of Done.**
Data workflow is reversible and fully audited.

---

# PHASE 23 — RELEASE

## PT-097 · Staging Deployment

**Goal.** Deploy backend/admin/API to staging.

**Scope.**
- staging DB connection.
- HTTPS.
- Wablas test config.
- Google test config.
- staging Android API base URL.

**Depends on:** Core backend completion.

**Definition of Done.**
Full staging environment is operational.

---

## PT-098 · Production Deployment Preparation

**Goal.** Prepare production without exposing credentials.

**Scope.**
- production env values.
- migrations.
- backup.
- rollback plan.
- SSL.
- log rotation.
- error logging.
- scheduled backup check.

**Depends on:** PT-097.

**Definition of Done.**
Production deployment checklist passes.

---

## PT-099 · Google Play Release Preparation

**Goal.** Prepare Android listing/release package.

**Scope.**
- final package ID.
- signing.
- version code/name.
- privacy policy URL.
- permissions declaration.
- screenshots/listing assets.
- Play Store URL saved to Remote Config.

**Depends on:** Android QA completion.

**Definition of Done.**
Release candidate is Play Store ready.

---

## PT-100 · MyInfo v1 Production Release

**Goal.** Release MyInfo v1.

**Scope.**
- production backend.
- production config.
- final snapshot bundled.
- Google Play rollout.
- website Download/Get App redirects to Play Store.
- monitor API/auth/sync/error logs.

**Depends on:** PT-098, PT-099.

**Acceptance Criteria.**
- Production app launches.
- Auth modes work.
- Wilayah works offline.
- Bank works offline.
- Nearby works.
- Sync works.
- Admin workflow works.
- Force update config works.

**Definition of Done.**
MyInfo v1 is live and meets Blueprint v1.1.

---


---

# PHASE 24 — COMMERCIAL DATA API

> **Important:** This is a separate backend product surface. It does not replace, wrap, meter, or authenticate the Android APK.

## PT-101 · Commercial API Foundation

**Goal.** Create a separate Commercial Data API namespace and middleware chain.

**Scope.**
- Namespace `/api/v1/data/`.
- API-key authentication hook.
- Scope authorization hook.
- Commercial rate/quota hook.
- Separate usage logging.
- No dependency on Android user sessions.

**Files/Areas.**
```text
backend/src/Api/V1/Data/
backend/src/Auth/ApiKey/
backend/src/Middleware/CommercialApi/
```

**Depends on:** PT-005, PT-010.

**Implementation Notes.**
- App API access/refresh tokens must not authenticate Commercial API.
- Commercial API keys must not authenticate APK endpoints.

**Acceptance Criteria.**
- Commercial namespace is isolated.
- Missing/invalid API key returns controlled 401.
- Android bearer token alone cannot access paid API.

**Definition of Done.**
Commercial API has its own security boundary.

---

## PT-102 · Commercial API Client Management

**Goal.** Allow Superadmin to manage external API clients.

**Scope.**
Store/manage:
```text
ClientID
ClientName
Company
Contact
Status
PlanID
CreatedAt
UpdatedAt
```

Statuses:
```text
ACTIVE
SUSPENDED
DISABLED
```

**Files/Areas.**
```text
backend/src/CommercialApi/Clients/
backend/admin/api-commercial/clients/
```

**Depends on:** PT-004, PT-008, PT-101.

**Acceptance Criteria.**
- Superadmin can create/update/suspend client.
- Editor cannot access API Commercial administration unless explicitly granted in future.

**Definition of Done.**
Commercial identities exist independently from APK users.

---

## PT-103 · Commercial API Key Generator & Rotation

**Goal.** Generate secure API keys for Commercial API clients.

**Scope.**
- `mi_live_*` and optionally `mi_test_*` prefixes.
- Display raw key only once.
- Store prefix + secure hash, not raw key.
- Revoke.
- Rotate.
- Expiry.
- LastUsedAt.

**Files/Areas.**
```text
backend/src/Auth/ApiKey/
backend/admin/api-commercial/keys/
```

**Depends on:** PT-102.

**Acceptance Criteria.**
- Raw key cannot be recovered from DB.
- Revoked/expired key fails authentication.
- Rotation does not expose old raw key.

**Definition of Done.**
Commercial credential lifecycle is safe.

---

## PT-104 · Commercial API Plans, Scopes, Quota & Rate Limit

**Goal.** Implement paid-plan access control independent of APK.

**Scope.**
Plans:
```text
FREE
BASIC
PRO
ENTERPRISE
```

Scopes:
```text
wilayah.read
bank.read
branch.read
wilayah.submit
bank.submit
branch.submit
```

Controls:
```text
requests per minute/hour
monthly quota
status
expiry
```

**Files/Areas.**
```text
backend/src/CommercialApi/Plans/
backend/src/CommercialApi/Quota/
backend/admin/api-commercial/plans/
```

**Depends on:** PT-101, PT-102, PT-103.

**Implementation Notes.**
- Must operate on PHP + MySQL without mandatory Redis.
- Concurrency-safe counters/usage logic required.
- 429 response for exceeded rate/quota.

**Acceptance Criteria.**
- Scope denial returns 403.
- Quota/rate breach returns 429.
- APK traffic is not counted.

**Definition of Done.**
Commercial metering works independently.

---

## PT-105 · Commercial Wilayah Read API

**Goal.** Sell controlled read access to Wilayah data.

**Scope.**
Example endpoints:
```text
GET /api/v1/data/wilayah/provinsi
GET /api/v1/data/wilayah/kabkota
GET /api/v1/data/wilayah/kecamatan
GET /api/v1/data/wilayah/kelurahan
GET /api/v1/data/wilayah/search
GET /api/v1/data/wilayah/kodepos/{kodepos}
```

**Depends on:** PT-022, PT-101, PT-104.

**Acceptance Criteria.**
- Requires `wilayah.read`.
- Quota/rate limit applied.
- Codes remain strings.
- One kode pos may return multiple kelurahan.

**Definition of Done.**
Paid Wilayah reads are production-ready.

---

## PT-106 · Commercial Bank Read API

**Goal.** Sell controlled Bank/Cabang read access.

**Scope.**
Example:
```text
GET /api/v1/data/banks
GET /api/v1/data/banks/{kodebank}
GET /api/v1/data/branches
GET /api/v1/data/branches/{kodecabang}
```

Filters may include:
```text
bank
wilayah
type
status
```

**Depends on:** PT-025, PT-101, PT-104.

**Acceptance Criteria.**
- Requires bank/branch read scope.
- Uses authoritative Wilayah joins.
- Public default exposes ACTIVE branch unless endpoint contract says otherwise.

**Definition of Done.**
Paid Bank reads are production-ready.

---

## PT-107 · Commercial Submit API

**Goal.** Allow specifically authorized partners to submit proposed data changes.

**Scope.**
Example:
```text
POST /api/v1/data/wilayah/submit
POST /api/v1/data/bank/submit
POST /api/v1/data/branch/submit
```

Flow:
```text
API Client
-> validate
-> Change Request
-> Draft
-> Review
-> Publish
```

**Depends on:** PT-034, PT-101, PT-104.

**Implementation Notes.**
- No endpoint may direct-update production.
- Store submitting ClientID in Change Request/audit metadata.
- Idempotency key recommended for partner submissions.

**Acceptance Criteria.**
- Submit scope required.
- Valid submission creates Draft/Change Request.
- Production remains unchanged before Publish.

**Definition of Done.**
Partner write-like capability is safe and review-gated.

---

## PT-108 · Commercial API Usage Logging & Aggregation

**Goal.** Track API consumption without requiring permanent workers.

**Scope.**
Capture/aggregate:
```text
ClientID
KeyID
Endpoint
Method
StatusCode
RequestCount
Timestamp bucket
Latency
```

Use cPanel Cron for aggregation/cleanup.

**Files/Areas.**
```text
backend/src/CommercialApi/Usage/
backend/cron/api_usage_aggregate.php
backend/cron/api_log_cleanup.php
```

**Depends on:** PT-101, PT-104.

**Implementation Notes.**
- Raw log retention must be configurable.
- Cron scripts must be resumable/idempotent.
- Avoid unbounded table growth.

**Acceptance Criteria.**
- Monthly usage is accurate.
- Cron can run from cPanel.
- Failure can resume next run.

**Definition of Done.**
Commercial usage is measurable on shared hosting.

---

## PT-109 · Commercial API Dashboard

**Goal.** Provide Superadmin operational visibility.

**Scope.**
Display:
```text
Client
Plan
Status
Requests Today
Requests This Month
Quota
Last Request
Top Endpoint
2xx/4xx/5xx
429 Count
```

Actions:
```text
create/revoke key
change plan
suspend client
view usage
```

**Depends on:** PT-102, PT-103, PT-104, PT-108.

**Acceptance Criteria.**
- Commercial dashboard is separate from Android User dashboard.
- Editor cannot access unless future policy changes.

**Definition of Done.**
Commercial API can be operated from Admin.

---

## PT-110 · Commercial API Billing Foundation

**Goal.** Prepare plan/payment status without requiring payment gateway v1.2.

**Scope.**
Store/manage:
```text
PlanID
BillingStatus
PeriodStart
PeriodEnd
Notes
```

Statuses:
```text
TRIAL
ACTIVE
PAST_DUE
SUSPENDED
CANCELLED
```

**Depends on:** PT-102, PT-104.

**Acceptance Criteria.**
- Superadmin can activate/suspend based on billing state.
- No payment credentials are required.

**Definition of Done.**
Future paid subscription integration has a stable foundation.

---

## PT-111 · Shared Hosting Cron & Operations Baseline

**Goal.** Ensure all recurring backend operations work on cPanel shared hosting without permanent workers.

**Scope.**
Document/create bounded Cron jobs for:
```text
OTP/session cleanup
Commercial usage aggregation
Commercial raw-log cleanup
API key expiry maintenance
snapshot generation if scheduled
integrity checks
other approved maintenance
```

**Files/Areas.**
```text
backend/cron/
docs/SHARED_HOSTING_OPERATIONS.md
```

**Depends on:** PT-018, PT-050, PT-108.

**Implementation Notes.**
- Use PHP CLI.
- Use lock/checkpoint to prevent overlap.
- Bound rows/time per run where appropriate.
- Log outcome safely.
- No daemon assumption.

**Acceptance Criteria.**
- Commands are documented for cPanel Cron.
- Repeat run is safe.
- Interrupted job can recover.

**Definition of Done.**
MyInfo backend is operationally compatible with the actual hosting environment.


---

# POST-v1 BACKLOG — NOT PART OF CURRENT SCOPE

Do not implement unless separately approved:

```text
Jadwal Kereta
Transportasi
ATM Directory
Cloud Favorite Sync
Cloud Search History
User Data Correction Reports
Background Location
Additional public information modules
```

---

# FINAL IMPLEMENTATION GATE

Before PT-100 can be marked done:

```text
[ ] Blueprint v1.1 unchanged or formally revised
[ ] Existing production master DB preserved
[ ] No secrets committed
[ ] HTTPS only
[ ] Encrypted Android local DB
[ ] Wilayah offline works
[ ] Bank offline works
[ ] Plus Code -> Lat/Lng workflow works
[ ] Embedded Map works
[ ] Nearby works
[ ] Incremental Sync works
[ ] Full Snapshot works
[ ] Draft -> Review -> Publish works
[ ] Audit Log works
[ ] Rollback creates forward version
[ ] Auth REQUIRED/OPTIONAL/DISABLED works
[ ] Email/Google/WhatsApp providers togglable
[ ] Max 3 devices enforced
[ ] Remote logout works
[ ] Module kill switch works
[ ] Minimum app version works
[ ] Play Store release ready
[ ] Commercial App/API auth boundaries are separate
[ ] Commercial API key storage is hashed
[ ] Commercial scopes/plans/quota/rate-limit work
[ ] Commercial submit uses Draft -> Review -> Publish
[ ] cPanel Cron operational baseline documented
```

**END — MYINFO v1.2 PROJECT TASKS**