System Requirements Document for checklist-lembaga-desa

1. Introduction

checklist-lembaga-desa is a browser-based verification instrument for checking the completeness of LEMBAGA & DESA (village-institution) proposals. A verifier (Verifikator) works through a fixed checklist of required documents, uploads each berkas as PDF, JPG, or PNG, assigns a per-document status of Lengkap, Perbaikan, or Belum Lengkap, writes verifier notes, and lets the system compute a completeness percentage automatically. The result is an auditable, printable verdict: a verification report carrying a kop surat (official letterhead), the recorded PIC email and phone number, the per-document statuses and notes, and an activity trail.

The product is deliberately a control-and-readout instrument, not a form-heavy SaaS shell. Its audience is administrative: a clerk in a district office marking a stack of documents, a PIC at a lembaga/desa who needs to know what to fix, and an administrator/auditor who needs traceable history and an exportable dataset. All proposal data and verification activity live in the browser's local storage on the same device — there is no server-side proposal store.

2. System Overview

The system is a single first-party web application with ten navigable destinations: Landing, Proposal, Documents, Verification, Progress, Notes, PIC, Reports, Activity, and Export. All destinations are reachable without an account; the product is a local, single-device instrument and does not establish application-owned identity.

Current accepted behavior:

• Per-document upload of PDF, JPG, or PNG files against the LEMBAGA & DESA checklist.
• Per-document status assignment: Lengkap / Perbaikan / Belum Lengkap.
• Automatic completeness percentage computed from document statuses.
• Verifier notes attached to documents.
• Activity trail / audit of verification actions.
• Verification letterhead (kop surat) applied to the report.
• PIC email and phone number recorded against the proposal.
• Trial proposal flow to start and continue a proposal.
• Printable verification report.
• CSV export of verification data.
• Proposal data persisted in browser local storage.

Actors: Verifikator, PIC Lembaga/Desa, Administrator/Auditor Aktivitas. No other human personas are in scope.

Narrow exclusions: no server-side proposal storage; no blue/indigo SaaS template; no account/registration system; no adjacent document-management, messaging, or approval-workflow capabilities beyond those listed above.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. The entire product is first-party custom UI delivered in the browser. Proposal data, uploaded document references, statuses, notes, PIC contact details, and the activity trail are persisted in the browser's local storage on the device where the work is done. There is no backend proposal database and no cross-device synchronization; continuing a proposal requires the same device and browser.

Access ownership. All ten destinations are openly reachable without sign-in. The product does not own user accounts, passwords, invitations, or role-based permissions. Identity is not established by the application; the PIC email and phone number are recorded as contact data on the proposal, not as login credentials.

Current vs. future. Everything in this document is current. No future-horizon features are accepted.

2b. Source Content Inventory

Not applicable — no reference directive with content_source was supplied.

2c. Page Content and Component Coverage

Landing

• Information/state: Product name wordmark "CHECKLIST / LEMBAGA & DESA"; a short explanatory paragraph describing the verification tool and its intended users; a live readout panel showing a percentage dial at 0% with 10 ruled ticks, a three-row status legend (Lengkap / Perbaikan / Belum Lengkap) as ruled label-value pairs, and a mock audit line in IBM Plex Mono.
• Primary action: "Mulai Trial Proposal" — enters the Proposal page to begin a trial proposal.
• Supporting action: "Lihat Contoh Laporan" — opens the Reports page to view the report format.
• Domain entities: none persisted on this page; the readout panel is a demonstration of the instrument.
• Component responsibilities: two-line wordmark headline (second line reversed out of a graphite block bleeding off the right edge); explanatory paragraph; two flush-left controls; functional readout panel with dial, legend, and audit line.
• States: loading — not applicable (static instrument panel); empty — dial at 0%, legend rows present, audit line shows a placeholder; success — not applicable; error — not applicable; recovery — not applicable.

Proposal

• Information/state: list of trial proposals stored in browser local storage, each showing proposal name, lembaga/desa, creation date, and current completeness percentage; the currently active proposal.
• Primary action: create a new trial proposal (name, lembaga/desa).
• Supporting actions: open an existing proposal to continue; rename or delete a proposal.
• Domain entities: Proposal (id, name, lembaga/desa, created date, last modified date, completeness percentage).
• Component responsibilities: proposal list as ruled label/value rows; create-proposal control; active-proposal selector.
• States: loading — reading local storage; empty — no proposals yet, prompt to create the first trial proposal; success — proposal created and set active; error — local storage unavailable or quota exceeded, with a message and retry; recovery — user can retry or continue with an existing proposal.

Documents

• Information/state: the LEMBAGA & DESA checklist as aligned rows — document name, format badge (PDF/JPG/PNG), status chip, percentage contribution; uploaded file preview as a ruled thumbnail with filename in IBM Plex Mono.
• Primary action: upload a PDF, JPG, or PNG file for a specific document.
• Supporting actions: replace an uploaded file; remove an uploaded file; open a preview.
• Domain entities: ChecklistItem (document name, required format), DocumentUpload (filename, format, size, uploaded date, data reference).
• Component responsibilities: checklist row grid; per-row upload control; format badge; ruled thumbnail preview; upload progress as a ruled bar advancing in visible increments.
• States: loading — reading stored uploads; empty — no file uploaded for a document, row shows an empty format badge; success — file stored and thumbnail shown; error — unsupported format or storage failure, with a message and retry; recovery — user can re-upload or remove the failed file.

Verification

• Information/state: per-document status of Lengkap / Perbaikan / Belum Lengkap as ruled tags with a 2px left colour bar; the document row context (name, format badge, upload presence).
• Primary action: set the status for a document.
• Supporting actions: change a previously set status; view the status history for a document.
• Domain entities: VerificationStatus (document reference, status value, set-by, set-at).
• Component responsibilities: status chip control per document; status legend; status history list.
• States: loading — reading stored statuses; empty — no status set, chip shows Belum Lengkap by default; success — status committed in 120ms with no bounce; error — storage write failure, with a message and retry; recovery — user can re-set the status.

Progress

• Information/state: one large completeness percentage numeral in Archivo tabular figures; a ruled 10-tick scale beneath it; a dense table of per-document contribution rows.
• Primary action: none — this is a readout page.
• Supporting actions: navigate to a document row to act on it.
• Domain entities: CompletenessPercentage (computed value), per-document contribution.
• Component responsibilities: percentage numeral; ruled tick scale; contribution table; slow 8s needle sweep on first load.
• States: loading — computing from stored statuses; empty — 0% with all rows at zero contribution; success — percentage displayed with count-up in 400ms linear steps; error — computation unavailable, with a message; recovery — recompute on next visit.

Notes

• Information/state: verifier notes attached to each document, with author and timestamp.
• Primary action: write and save a verifier note on a document.
• Supporting actions: edit an existing note; delete a note.
• Domain entities: VerifierNote (document reference, text, author, created-at, updated-at).
• Component responsibilities: note editor per document; note list with timestamps in IBM Plex Mono.
• States: loading — reading stored notes; empty — no notes yet, prompt to write one; success — note saved and listed; error — storage write failure, with a message and retry; recovery — user can re-save.

PIC

• Information/state: PIC email and phone number recorded against the proposal, with the PIC name and lembaga/desa.
• Primary action: save PIC contact details.
• Supporting actions: edit PIC details; view PIC details on the report.
• Domain entities: PIC (name, email, phone, lembaga/desa, proposal reference).
• Component responsibilities: contact form as aligned label/value rows; validation for email format and phone number.
• States: loading — reading stored PIC data; empty — no PIC recorded, prompt to add; success — details saved; error — invalid email or phone, with a field-level message; recovery — user can correct and re-save.

Reports

• Information/state: an A4-proportioned sheet (210×297 ratio) centred on the paper-grey ground; kop surat rendered as a real letterhead block; proposal identity; PIC email and phone; per-document statuses and notes; completeness percentage; ruled signature area.
• Primary action: generate the verification report.
• Supporting actions: print the report; view the report on screen.
• Domain entities: VerificationReport (proposal reference, kop surat content, PIC details, document statuses, notes, percentage, generated-at).
• Component responsibilities: A4 sheet; kop surat letterhead block; status table; notes block; signature area; print stylesheet outputting the same sheet at 1:1.
• States: loading — assembling report from stored data; empty — no proposal data, prompt to complete verification first; success — report rendered and printable; error — report assembly failure, with a message; recovery — user can regenerate.

Activity

• Information/state: trail/audit of verification activity as ruled rows — timestamp, actor, action, document reference, previous and new value.
• Primary action: none — this is a review page.
• Supporting actions: filter by document or action type; navigate to the affected document.
• Domain entities: ActivityEntry (timestamp, actor, action, document reference, previous value, new value).
• Component responsibilities: audit row list in IBM Plex Mono; filter controls; timestamp formatting.
• States: loading — reading stored activity; empty — no activity yet; success — entries listed in reverse chronological order; error — activity read failure, with a message; recovery — reload.

Export

• Information/state: exportable verification dataset — proposal identity, PIC details, per-document statuses, notes, completeness percentage, activity summary.
• Primary action: export the verification data as a CSV file.
• Supporting actions: select which fields to include; preview the export rows.
• Domain entities: ExportDataset (proposal reference, rows, columns).
• Component responsibilities: field selection controls; preview table; CSV generation and download.
• States: loading — assembling dataset; empty — no data to export, prompt to complete verification first; success — CSV downloaded; error — export failure, with a message; recovery — user can retry.

3. Functional Requirements

FR-01 — Per-document upload of PDF/JPG/PNG (explicit) As a Verifikator, I should upload a PDF, JPG, or PNG file for each document in the LEMBAGA & DESA checklist, so that each required berkas has a stored specimen.

• Trigger/input: user selects a file for a specific checklist document.
• Observable result: the file is stored in browser local storage and shown as a ruled thumbnail with its filename in IBM Plex Mono; the format badge shows PDF, JPG, or PNG.
• Access state: no account required.
• Failure/recovery: unsupported format or storage failure shows a message and allows re-upload or removal.
• Continuation: the uploaded document is available for status assignment on Verification.

FR-02 — LEMBAGA & DESA checklist (explicit) As a Verifikator, I should work against a fixed checklist of LEMBAGA & DESA documents, so that verification covers the same required set every time.

• Trigger/input: opening the Documents page for an active proposal.
• Observable result: the checklist renders as aligned label/value rows — document name, format badge, status chip, percentage contribution.
• Access state: no account required.
• Failure/recovery: if the checklist cannot be read, a message is shown and the page can be reloaded.
• Continuation: each row links to its upload and status controls.

FR-03 — Per-document status: Lengkap / Perbaikan / Belum Lengkap (explicit) As a Verifikator, I should set each document's status to Lengkap, Perbaikan, or Belum Lengkap, so that the verdict per berkas is explicit.

• Trigger/input: selecting a status on a document row.
• Observable result: the status chip changes in 120ms with no bounce; Lengkap renders as #2F6B4F on #E4EDE6, Perbaikan as #E4570E on #FBE7DA, Belum Lengkap as #9A9A93 on #E9E7E0.
• Access state: no account required.
• Failure/recovery: a storage write failure shows a message and allows re-setting the status.
• Continuation: the status feeds the automatic percentage and the report.

FR-04 — Automatic completeness percentage (explicit) As a Verifikator, I should see the completeness percentage computed automatically from document statuses, so that kelengkapan is an honest number rather than a manual tally.

• Trigger/input: any status change or document upload.
• Observable result: the percentage numeral updates, counting up in 400ms of linear steps; the ruled 10-tick scale reflects the value.
• Access state: no account required.
• Failure/recovery: if computation is unavailable, a message is shown and the value recomputes on next visit.
• Continuation: the percentage appears on Progress, Reports, and Export.

FR-05 — Verifier notes (explicit) As a Verifikator, I should write a note on a document, so that the reason for a Perbaikan or Belum Lengkap status is recorded.

• Trigger/input: entering note text on a document.
• Observable result: the note is saved with author and timestamp and listed under the document.
• Access state: no account required.
• Failure/recovery: a storage write failure shows a message and allows re-saving.
• Continuation: the note appears on the report and in the CSV export.

FR-06 — Activity trail / audit (explicit) As an Administrator/Auditor Aktivitas, I should review a trail of verification activity, so that every status change and note is traceable.

• Trigger/input: opening the Activity page.
• Observable result: entries list timestamp, actor, action, document reference, and previous/new value in reverse chronological order.
• Access state: no account required.
• Failure/recovery: a read failure shows a message and allows reload.
• Continuation: the trail is summarized in the CSV export.

FR-07 — Kop surat verifikasi (explicit) As a Verifikator, I should have the verification report carry a kop surat (official letterhead), so that the printed verdict is an official document.

• Trigger/input: generating the report on Reports.
• Observable result: the A4 sheet renders a real letterhead block at the top of the report.
• Access state: no account required.
• Failure/recovery: if the letterhead cannot be rendered, a message is shown and the report can be regenerated.
• Continuation: the letterhead appears in the printed output at 1:1.

FR-08 — Email & nomor PIC (explicit) As a PIC Lembaga/Desa, I should have my email and phone number recorded against the proposal, so that the verifier and the report can reach the right contact.

• Trigger/input: entering PIC name, email, and phone on the PIC page.
• Observable result: the details are saved and shown on the report.
• Access state: no account required.
• Failure/recovery: invalid email or phone shows a field-level message and allows correction.
• Continuation: the PIC details appear on the report and in the CSV export.

FR-09 — Trial proposal (explicit) As a PIC Lembaga/Desa, I should start a trial proposal and continue it later, so that I can submit a proposal for verification without a server account.

• Trigger/input: creating a proposal on the Proposal page.
• Observable result: the proposal is stored in browser local storage and becomes the active proposal.
• Access state: no account required.
• Failure/recovery: storage unavailable or quota exceeded shows a message and allows retry.
• Continuation: the active proposal is the context for Documents, Verification, Progress, Notes, PIC, Reports, Activity, and Export.

FR-10 — Laporan verifikasi siap cetak (explicit) As a Verifikator, I should produce a print-ready verification report, so that the verdict can be filed or handed over on paper.

• Trigger/input: generating and printing the report on Reports.
• Observable result: the on-screen A4 sheet and the printed output are the same object at 1:1.
• Access state: no account required.
• Failure/recovery: an assembly failure shows a message and allows regeneration.
• Continuation: the printed report carries kop surat, PIC details, statuses, notes, percentage, and signature area.

FR-11 — Export CSV (explicit) As an Administrator/Auditor Aktivitas, I should export verification data as CSV, so that completeness data can be used in external reporting.

• Trigger/input: selecting fields and triggering export on Export.
• Observable result: a CSV file downloads containing proposal identity, PIC details, per-document statuses, notes, percentage, and activity summary.
• Access state: no account required.
• Failure/recovery: an export failure shows a message and allows retry.
• Continuation: the CSV can be opened in a spreadsheet.

FR-12 — Browser-based proposal data storage (explicit) As a Verifikator, I should have proposal data stored in the browser rather than on a server, so that the tool works locally without backend infrastructure.

• Trigger/input: any create, upload, status, note, or PIC action.
• Observable result: data is written to browser local storage and survives page reloads on the same device.
• Access state: no account required.
• Failure/recovery: storage unavailable or quota exceeded shows a message and allows retry.
• Continuation: the same device and browser can resume the proposal.

FR-13 — Local persistence of proposal and verification activity (required_inference) As a Verifikator, I should be able to resume a proposal on the same device, so that an accepted current journey is executable without a server.

• Trigger/input: reopening the application on the same device and browser.
• Observable result: the active proposal, uploads, statuses, notes, PIC details, and activity trail are restored from local storage.
• Access state: no account required.
• Failure/recovery: if local storage is cleared or unavailable, a message explains that prior data is not recoverable and a new proposal can be started.
• Continuation: the user continues verification from where it stopped.

FR-14 — Computation and output from local proposal data (required_inference) As a Verifikator, I should have the percentage, statuses, notes, report, and export all derive from the locally stored proposal data, so that the readouts are consistent with what was entered.

• Trigger/input: any readout or output action.
• Observable result: Progress, Reports, and Export reflect exactly the stored statuses, notes, and PIC details.
• Access state: no account required.
• Failure/recovery: a read failure shows a message and allows reload.
• Continuation: outputs remain consistent after any subsequent edit.

4. User Personas

Verifikator

Product context. A clerk in a district office who sits with a stack of LEMBAGA & DESA proposal documents and must produce a defensible verdict on each berkas. The work is procedural and repetitive: open a proposal, check each required document, mark it, note why, and move on.

Primary goal. Accurate per-document statuses and an accurate completeness percentage, ending in a printable verification report with kop surat.

Distinct accepted responsibilities. Uploads PDF/JPG/PNG per document; assigns Lengkap / Perbaikan / Belum Lengkap; writes verifier notes; generates the report with kop surat; produces the print-ready report.

Relevant inputs or decisions. The uploaded file for each document; the judgment of whether a document is complete, needs perbaikan, or is missing; the note text explaining the judgment.

Interactions with other accepted participants. Reads and records the PIC email and phone number so the report reaches the right contact; the PIC sees the statuses and notes the Verifikator set; the Administrator/Auditor Aktivitas reviews the trail the Verifikator generated.

Observable success. The Progress page shows a percentage that matches the statuses set; the Reports page renders an A4 sheet with kop surat, statuses, notes, PIC details, and a signature area that prints at 1:1.

PIC Lembaga/Desa

Product context. A representative of a lembaga or desa who submits a trial proposal and is the contact point for it. They are not the verifier; they need to know what is missing or needs fixing.

Primary goal. Have the proposal declared complete.

Distinct accepted responsibilities. Starts a trial proposal; provides email and phone number as PIC contact; monitors completeness status and verifier notes; follows up on requested perbaikan.

Relevant inputs or decisions. Proposal name and lembaga/desa identity; PIC name, email, and phone; the decision to act on a Perbaikan or Belum Lengkap status.

Interactions with other accepted participants. The Verifikator sets the statuses and writes the notes the PIC reads; the PIC's contact details appear on the report the Verifikator produces.

Observable success. The Progress page shows the completeness percentage rising as perbaikan items are resolved, and the statuses move toward Lengkap.

Administrator/Auditor Aktivitas

Product context. A manager who oversees verification work and needs traceable history and an exportable dataset for reporting.

Primary goal. Traceable activity history and exportable completeness data.

Distinct accepted responsibilities. Reviews the trail/audit of verification activity; exports verification data as CSV.

Relevant inputs or decisions. The activity entries (timestamp, actor, action, document, previous/new value); the selection of fields to include in the export.

Interactions with other accepted participants. Reviews the actions the Verifikator performed; the exported data reflects the PIC's proposal and the Verifikator's verdicts.

Observable success. The Activity page lists a complete, ordered trail; the Export page produces a CSV containing proposal identity, PIC details, per-document statuses, notes, percentage, and activity summary.

5. Core User Flows

Flow 1 — Verifikator verifies a proposal and produces a printable report

1. Start. The Verifikator opens the application on the office device. The Landing page shows the wordmark and the readout panel at 0%.
2. Enter. The Verifikator selects "Mulai Trial Proposal" and lands on the Proposal page.
3. Select or create. The Verifikator opens the existing proposal for the lembaga/desa under review, or creates a new trial proposal with its name and lembaga/desa. The proposal becomes active and is stored in browser local storage.
4. Upload. On the Documents page, the Verifikator uploads a PDF, JPG, or PNG for each checklist document. Each upload shows a ruled thumbnail with the filename in IBM Plex Mono and a format badge.
5. Verify. On the Verification page, the Verifikator sets each document's status to Lengkap, Perbaikan, or Belum Lengkap. The status chip changes in 120ms with no bounce.
6. Note. On the Notes page, the Verifikator writes a note for each document that is Perbaikan or Belum Lengkap, explaining what must be fixed. The note is saved with author and timestamp.
7. Read the percentage. On the Progress page, the Verifikator sees the completeness percentage numeral count up in 400ms of linear steps and the ruled 10-tick scale reflect the value.
8. Record PIC. On the PIC page, the Verifikator records the PIC name, email, and phone number. Invalid email or phone shows a field-level message and allows correction.
9. Generate the report. On the Reports page, the Verifikator generates the verification report. The A4 sheet renders with the kop surat letterhead block, proposal identity, PIC details, per-document statuses and notes, the completeness percentage, and a ruled signature area.
10. Print. The Verifikator prints the report. The printed output matches the on-screen sheet at 1:1.
11. Failure/recovery. If local storage is unavailable or quota is exceeded at any step, a message is shown and the action can be retried. If the report cannot be assembled, the Verifikator can regenerate it.
12. Continuation. The Verifikator moves to the next proposal, or returns later to the same proposal on the same device and browser.

Flow 2 — PIC Lembaga/Desa starts a trial proposal and follows up on perbaikan

1. Start. The PIC opens the application on the device where the proposal will be worked.
2. Enter. The PIC selects "Mulai Trial Proposal" on the Landing page and lands on the Proposal page.
3. Create. The PIC creates a trial proposal with the lembaga/desa name. The proposal is stored in browser local storage and becomes active.
4. Provide contact. On the PIC page, the PIC enters name, email, and phone number. The details are saved and will appear on the report.
5. Upload. On the Documents page, the PIC uploads the available PDF/JPG/PNG files for the checklist documents.
6. Await verdict. The Verifikator sets statuses and writes notes. The PIC sees the statuses on Verification and the notes on Notes.
7. Read the percentage. On the Progress page, the PIC sees the completeness percentage and the per-document contribution rows, identifying which documents are Perbaikan or Belum Lengkap.
8. Follow up. The PIC acts on the notes — replacing a document on Documents or supplying a missing one — and the Verifikator re-sets the status.
9. Failure/recovery. If a document cannot be uploaded (unsupported format or storage failure), a message is shown and the PIC can re-upload or remove the file.
10. Continuation. The PIC returns on the same device and browser to check whether the proposal has reached Lengkap.

Flow 3 — Administrator/Auditor Aktivitas reviews the trail and exports CSV

1. Start. The Administrator opens the application and navigates to the Activity page.
2. Review. The Administrator reads the audit rows — timestamp, actor, action, document reference, previous and new value — in reverse chronological order, and filters by document or action type if needed.
3. Inspect a document. The Administrator navigates from an activity row to the affected document to see its current status and notes.
4. Export. On the Export page, the Administrator selects the fields to include and triggers the export. A CSV file downloads containing proposal identity, PIC details, per-document statuses, notes, completeness percentage, and activity summary.
5. Failure/recovery. If the activity read or the export fails, a message is shown and the Administrator can reload or retry.
6. Continuation. The Administrator opens the CSV in a spreadsheet for external reporting.

6. Visuals Colors and Theme

Muse: Dieter Rams. Headline direction: "Less, but better — a verification instrument, not a form." The interface is a Braun control panel on a district-office desk: strict modular grid, rounded-rectangle controls, aligned label/value pairs, muted surfaces, one saturated signal colour, instant mechanical feedback.

Palette (light mode):

Signal orange #E4570E is rationed hard: the completion percentage numeral, the Perbaikan state chip, the primary action button, and the active slider/step tick. No blue anywhere; no gradients; no decorative shadow — only 1px borders and one soft panel shadow at 4% opacity. Belum Lengkap is deliberately grey, not red, so the alarm colour is reserved for genuine perbaikan.

Typography:

• Headings: Archivo 600–700, tight tracking (-0.02em), sentence case with occasional small-caps eyebrow labels; numerals in Archivo with tabular figures.
• Body: Public Sans 400/500 at 15–16px, line-height 1.65.
• Monospace data (document IDs, timestamps, audit rows): IBM Plex Mono 400 at 13px; uppercase micro-labels at 11px with 0.14em tracking.
• Scale: 1.250 modular — 13 / 15 / 16 / 20 / 25 / 40 / 64 / 104px. Display numerals clamp(56px, 9vw, 104px) for the completion percentage; section heads clamp(25px, 3.2vw, 40px); body 16px desktop / 15px mobile; labels 12px caps.

Shape language: Rounded-rectangle controls with 6px radii and 1px #D6D2C8 borders — the Braun switch, not a pill. Status chips are 4px-radius ruled tags with a 2px left colour bar rather than filled lozenges. Progress is a horizontal ruled scale with tick marks every 10%, not a soft blob bar. Circular elements appear only where a dial is genuinely a dial (the percentage gauge, document-count counters). Hard edges everywhere else; no blobs, no organic curves, no soft 24px cards.

Layout: A 12-column modular grid on a 1280px canvas with 24px gutters and a persistent 72px left instrument rail (icon + uppercase label pairs: Proposal, Documents, Verification, Progress, Notes, PIC, Reports, Activity, Export). Content is a two-zone split on every working page: left column = the document checklist as aligned label/value rows (document name | format badge | status chip | percentage contribution), right column = the readout panel. The Progress page is a full-width readout: one enormous percentage numeral, a ruled 10-tick scale beneath it, and a dense table of per-document contribution rows. Reports uses an A4-proportioned sheet (210×297 ratio) centred on the paper-grey ground with kop surat rendered as a real letterhead block. At 768px the rail collapses to a horizontal labelled tab strip; at 375px the checklist becomes stacked rows with the status chip right-aligned and the readout panel moves directly under the proposal header.

Imagery: No photography, no illustration for its own sake. The visual content is diagrammatic: ruled document-specimen blocks showing the expected form of each berkas (a stylised A4 with a corner fold and format stamp PDF/JPG/PNG), pictogram status marks (check, wrench, empty square) drawn on a 24px grid with 2px strokes, a schematic kop-surat diagram for Reports, and topographic-style ruled lines as section separators. Uploaded file previews appear as small ruled thumbnails with the filename in IBM Plex Mono beneath — the document itself is the only "photo" in the product.

7. Signature Design Concept

The Landing first screen is a working instrument panel, not a marketing hero.

• Left 7 columns: a stacked, left-flush headline in Archivo 700 at clamp(56px, 9vw, 104px) reading CHECKLIST / LEMBAGA & DESA in two lines that span the viewport width, with the second line sitting on a solid graphite #3A3A36 block that bleeds off the right edge. Beneath it, one 60-word paragraph in Public Sans and two controls — a solid #E4570E Mulai Trial Proposal button and a bordered Lihat Contoh Laporan — pinned flush-left under the block, never centred.
• Right 5 columns: a live, functional readout panel — a circular percentage dial at 0% with 10 ruled ticks, a three-row status legend (Lengkap / Perbaikan / Belum Lengkap) as ruled label-value pairs, and a mock audit line in IBM Plex Mono. The panel is real UI, so the hero demonstrates the product instead of describing it.

No centred headline, no subtext-and-button stack, no gradient, no floating screenshot. The signature moves carry the concept: the oversized two-line wordmark with the second line reversed out of a graphite block bleeding off the right edge; the completion percentage as the loudest object in the product; every document as a single ruled label/value row; status chips as ruled tags with a hard colour bar; and Reports rendering the verification report as an on-screen A4 sheet with a real kop surat letterhead block and a print stylesheet that outputs the same sheet at 1:1.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the live readout panel — circular percentage dial at 0% with 10 ruled ticks, three-row status legend, and a mock audit line in IBM Plex Mono.
• Input → transformation → outcome thesis: on first load, the dial's needle performs a slow 8s sweep from 0 to its resting position while the ruled ticks remain fixed; the outcome is a still, honest readout that demonstrates the instrument rather than describing it. No accepted behavior is simulated beyond the panel's own display.
• Motion vocabulary: instant, mechanical feedback only — state changes commit in 120ms with no easing theatrics; status chips snap between colours; the percentage numeral counts up in 400ms of linear steps (never a spring); upload progress is a ruled bar that advances in visible increments; hover, focus, and tab change are 90ms colour/border swaps.
• Composed first frame: the two-line wordmark with the second line reversed out of the graphite block bleeding off the right edge; the explanatory paragraph and two flush-left controls beneath; the readout panel on the right at 0% with the needle at rest.
• Reduced-motion state: prefers-reduced-motion removes the count-up and the needle sweep, leaving the final values immediately.

9. Non-Functional Requirements

NFR-01 — Local storage persistence (explicit) Proposal data and verification activity must be persisted in browser local storage, not on a server. Rationale: the explicit constraint that proposal data storage is browser-based.

NFR-02 — Same-device resumability (required_inference) A proposal must be resumable on the same device and browser after a page reload. Rationale: required to make the accepted trial-proposal journey executable without a server.

NFR-03 — Storage failure handling (required_inference) Storage unavailability or quota exhaustion must surface a clear message and allow retry, without silently discarding entered data. Rationale: required for a usable local-storage lifecycle.

NFR-04 — Print fidelity (explicit) The printed verification report must match the on-screen A4 sheet at 1:1, including the kop surat letterhead block and the signature area. Rationale: the explicit requirement for a print-ready verification report.

NFR-05 — Readable text and controls at every viewport (explicit, from creative direction) Headlines, wordmarks, labels, numbers, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; no other element may cover any part of them. Rationale: the creative direction's readability rule.

NFR-06 — Reduced-motion support (explicit, from creative direction) prefers-reduced-motion must remove the count-up and the needle sweep, leaving final values immediately. Rationale: the creative direction's motion rule.

NFR-07 — No blue/indigo SaaS template (explicit, from creative direction) No blue or indigo primary/accent, no near-white-on-white generic SaaS shell, no gradient-blob background, no pill buttons or 24px+ soft radii, no Inter/Roboto/Arial/Helvetica/Poppins/system-ui for headings or body. Rationale: the creative direction's explicit avoid list.

10. Tech Stack

• Frontend: React (single-page application) with the custom UI described in section 2c.
• Storage: browser local storage for proposal data, uploads, statuses, notes, PIC details, and activity trail.
• Styling: CSS implementing the palette, typography, shape language, and layout in section 6, including a print stylesheet for the A4 report.
• No backend proposal store: consistent with the explicit constraint that proposal data storage is browser-based.

11. Assumptions and Constraints

• A-01 (explicit) Proposal data storage is browser-based (local storage), not server-based. This is a hard constraint.
• A-02 (required_inference) Continuing a proposal requires the same device and browser; there is no cross-device synchronization.
• A-03 (required_inference) Clearing browser storage removes proposal data; the application cannot recover it.
• A-04 (explicit) Uploaded files are limited to PDF, JPG, and PNG.
• A-05 (required_inference) The LEMBAGA & DESA checklist is a fixed set of required documents; the source does not enumerate the individual document names.
• A-06 (explicit) No account, registration, or role-based permission system is in scope; all destinations are openly reachable.
• A-07 (explicit) The PIC email and phone number are contact data on the proposal, not login credentials.
• A-08 (explicit, from creative direction) The palette, typography, shape language, layout, and motion rules in sections 6–8 are binding.
• A-09 (explicit) No future-horizon features are accepted; everything in this document is current.

12. Glossary

• LEMBAGA & DESA — village-institution and village bodies whose proposals are verified.
• Berkas — a required document file in the checklist.
• Lengkap — status meaning the document is complete.
• Perbaikan — status meaning the document needs correction.
• Belum Lengkap — status meaning the document is not yet complete (rendered grey, not red).
• Kelengkapan — completeness, expressed as the automatically computed percentage.
• Verifikator — the clerk who verifies documents and sets statuses.
• PIC — the contact person at the lembaga/desa, recorded by email and phone number.
• Kop surat — the official letterhead block on the verification report.
• Trial proposal — a proposal started and continued locally in the browser.
• Trail/audit aktivitas — the ordered record of verification actions.
• Local storage — the browser storage where proposal data and activity are persisted.