Skip to content

docs(architecture): commit to a capture-first field client - #2

Merged
NCHILLC merged 2 commits into
mainfrom
docs/capture-first-client
Sep 7, 2026
Merged

NCHILLC merged 2 commits into
mainfrom
docs/capture-first-client

Conversation

@NCHILLC

@NCHILLC NCHILLC commented Sep 7, 2026

Copy link
Copy Markdown
Owner

Summary

The "Future app path" section listed a native client as "direction, unspecified", leaving the one question that decides its shape unanswered: is capture the client's primary job, or a feature of a client that mostly edits reports?

This records the answer — capture is the primary job — and the reasoning that makes it a decision rather than a preference.

What changes

Documentation only. No code, no behavior.

  • Item 2 of the app path becomes a capture-first native client (decided 2026-09-07): photos, findings and voice notes written to device storage at the moment of capture with no server round trip, sync afterwards. Report editing, templates and admin stay on the web surface. Local storage, sync ordering, de-duplication and conflict resolution are that client's architecture, not features added to it later.
  • Adds a short paragraph on why it is built early rather than after the web app matures: the two driving requirements — capture where there is no signal, and sync that lands offline work in order and without duplicates — are structural, cheap to design in and expensive to retrofit. useOfflineQueue is named as today's light version of the second, a fallback around a server-first data path.
  • The existing Capacitor paragraph is unchanged except its closing line, which now refers to the capture-first client by name.

Type of change

  • Documentation only

Test plan

  • Pre-commit gates green (20/20 selected)
  • verify reports on this PR

Follow-up (not in this PR)

The next step is a spike under docs/develop/spikes/ answering only the two structural questions before any client code exists: the on-device store, and the sync/conflict model. Both are decisions useOfflineQueue currently makes implicitly as a fallback.

Per the maintainer note in the PR template: merge, do not squash.

🤖 Generated with Claude Code

NCHILLC and others added 2 commits September 7, 2026 08:05
The app path listed a native client as "direction, unspecified", which
left the one question that decides its shape unanswered: is capture the
client's primary job, or a feature of a client that mostly edits reports.

It is the primary job. Photos, findings and voice notes are written to
device storage at the moment of capture with no server round trip; report
editing, templates and admin stay on the web surface. Local storage, sync
ordering, de-duplication and conflict resolution are that client's
architecture rather than later additions to it.

Recorded here because both driving requirements — capture with no signal,
and sync that lands offline work in order and without duplicates — are
structural, cheap to design in and expensive to retrofit. `useOfflineQueue`
is today's light version of the second, a fallback around a server-first
data path.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@NCHILLC
NCHILLC merged commit 6536c4e into main Sep 7, 2026
17 checks passed
@NCHILLC
NCHILLC deleted the docs/capture-first-client branch September 7, 2026 19:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant