james.maesandClaude Sonnet 5.5
df0ff73dae
Document the current local server, semantic contract, accepted TC22 tests and signed APK status. Separate production follow-up from the working demo and archive superseded logs. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2.1 KiB
Contributing
Use Java 21 and the checked-in Maven wrapper. Clone this repository and the companion qqq-android on Gitea (the primary forge; GitHub is a shadow/archive) when changing the mobile/server contract. No Android SDK is needed for server-only changes.
Create feature/, fix/, docs/ or chore/ branches from develop and open pull requests into develop. Use Conventional Commit subjects and describe the resulting behavior, relevant verification and compatibility changes. Request review from the code owner; do not merge with failing required checks.
Local checks
From the repository root:
./mvnw --batch-mode verify install
./mvnw --batch-mode -f demo/pom.xml verify
On Windows, use .\mvnw.cmd. The root build verifies Checkstyle, H2 behavior and QBit guardrails; the separate demo verifies native login, enrollment, approval, scanner metadata, asynchronous capture, retries and revocation over HTTP. Tests use synthetic data and isolated databases.
For a physical handheld, follow TC22 acceptance. State clearly whether a change was tested on a device, in an emulator, or only through automated tests.
Style and design
Follow the existing Kingsrook Java style: three-space indentation, Allman braces, banner documentation, explicit imports and Apache-2.0 SPDX headers. The checked-in Checkstyle configuration owns the formatting rules. Prefer ordinary QQQ metadata, actions and authentication integrations over duplicate infrastructure.
Retain the online-only contract and acknowledge scans only after persistence succeeds. Add meaningful regression coverage for permission, device identity, retry, schema or protocol changes. Keep device tokens out of process values, logs and fixtures. Use generated examples instead of production barcodes or identities.
The CI and release guide explains the shared CircleCI profile and publication enablement. Report vulnerabilities privately through SECURITY.md, and follow the Code of Conduct.