Document local-first sync rules

AGENTS.md

@@ -118,6 +118,20 @@ These features are product requirements, not “nice to have” ideas.
 - Prefer behavior-oriented tests that describe expected product behavior rather than implementation details.
 - Provide a secure gRPC API as a first-class programmatic surface, not as a thin wrapper around UI state.
 - Design browser-extension and automation integrations against the gRPC API, not against ad hoc local protocols.
+- Treat the vault model as local-first across all platforms:
+  every usable vault is a local KDBX file first, and remote sync attaches to
+  that local vault rather than replacing it as the primary object.
+- Keep the remote-sync model standardized across desktop, Android phone, and
+  Android tablet:
+  shared remote configuration belongs in the vault,
+  cross-platform workflow stays the same,
+  and only Android's initial KDBX share/import transport may differ.
+- Do not persist remote credentials in plaintext app-local state.
+  Keep only non-secret binding metadata outside the vault.
+- When working on remote-sync behavior, preserve the local cache / local-first
+  design:
+  opening or creating the local vault is the main workflow,
+  and remote setup, remote settings, and remote use attach to that vault.
 
 ## Delivery Discipline
 
@@ -144,6 +158,13 @@ These features are product requirements, not “nice to have” ideas.
 - Plan for direct KDBX support.
 - Plan for direct WebDAV-based workflows.
 - Avoid adding npm-based or browser-stack dependencies.
+- Keep remote configuration and synchronization local-first:
+  the app should maintain a live local KDBX cache even when using a remote
+  store, so remote outage does not eliminate vault access.
+- Prefer vault-backed remote setup and lookup over ad hoc local credential
+  storage.
+- On Android, use system picker/share mechanisms for local vault import/export
+  rather than raw path entry when a user is selecting or sharing a vault file.
 
 ## Tooling
 
@@ -166,6 +187,10 @@ These features are product requirements, not “nice to have” ideas.
   Use an isolated `KEEPASSGO_STATE_DIR` for host-side validation, and when emulator testing requires seeded vault data, use sanitized test/demo vaults rather than the user’s real vault files whenever possible.
 - When running tests or other automated validation that may touch persisted UI state, set `KEEPASSGO_STATE_DIR` to an isolated temporary directory so recent-vault history and other local state do not pollute the user’s real config.
 - Prefer commands shaped like `KEEPASSGO_STATE_DIR=\"$(mktemp -d)\" go test ./...` for ad hoc local validation unless a test already manages its own isolated state directory.
+- For the Arch package, treat
+  `packaging/archlinux/keepassgo-git/PKGBUILD.tmpl`
+  as the source of truth and regenerate `PKGBUILD` from the template before
+  building.
 - Do not assume the agent can decrypt SOPS-encrypted secrets in this repository.
 - If work requires plaintext from a SOPS-encrypted secret, stop and ask the user to decrypt it or otherwise provide the needed plaintext.
 - Do not commit generated binaries.