Imported from arthurschaab-bit/Noiseprotocol_Android (AGENTS.md). Install upstream with npx skills add arthurschaab-bit/Noiseprotocol_Android. Copyright stays with the author.

AGENTS.md — Lärmprotokoll (Noiseprotocol_Android)

Instructions for every coding agent working in this repository (Claude Code, Codex, Antigravity/Gemini). Read this file completely before touching any code. It is the single source of truth for working rules; the content of the work is defined in docs/.

1. What this project is

Android app that documents noise events: records an audio clip with pre-roll when a level threshold is exceeded, classifies the sound with YAMNet (TFLite), and stores everything as a searchable log in Room. Current initiative: connect an external sound level meter PCE-323 via Bluetooth LE to replace the uncalibrated microphone level with calibrated dBA values.

State as of 04.09.2026: the Bluetooth work (M1–M8), alerting on connection loss, the Google Drive sync, the AI rebuild and M11 (photo documentation and video evidence) are all implemented and merged. What remains is device verification — see docs/CHECKLISTE_GERAETETEST.md, part F, for the list of things that are built but have never been seen on hardware.

2. Where the truth lives — read in this order

1. README.md — status overview, what works, what is open.
2. docs/IMPLEMENTIERUNGSPLAN_PCE-323_BLUETOOTH.md — the decided plan (~1,230 lines). Sections 0 (inventory, findings B-1..B-11), 2 (device protocol), 4 (target architecture), 11 (test strategy), 12 (milestones), 13 (open decisions).
3. docs/PROMPT_UMSETZUNG.md, docs/PROMPT_M1.md — concrete task briefs per milestone. The most recent ones are docs/PROMPT_M11_FOTO_VIDEO.md (photos and video evidence, including the binding owner decisions E1, E4, E8 and E9) and docs/PROMPT_BUGFIX_TRIGGER.md.
4. docs/PROMPT_REVIEW.md — the review checklist a separate reviewer session runs.

The plan is decided. Your job is to execute it, not to redesign it. If your task contradicts the plan, follow the plan and report the contradiction. If you hit a decision marked open in plan section 13, do not decide — ask the owner.

Docs are in German. Keep them in German. Code identifiers are English, UI strings are German.

3. Stack

Kotlin 2.2 · Jetpack Compose · Room 2.8, schema version 19 (KSP, exported schemas in app/schemas/) · Navigation-Compose · MediaPipe Tasks Audio for YAMNet (replaced TFLite Task Audio, see B-11) · CameraX for the video evidence (M11 B) · Robolectric for JVM tests. Hand-written fakes only — no Mockito, no MockK anywhere in this repository. AGP 9.2 · Gradle 9.4 · Java toolchain 21, jvmTarget 17 · compileSdk/targetSdk 36 · minSdk 29 (the planned bump to 31 did not happen — the code still targets 29). Single Gradle module app, package com.example.lrmprotokoll. No DI framework — a manual AppContainer (plan 4.2). No Hilt.

4. Build & test commands

./gradlew assembleDebug          # must pass after every change
./gradlew test                   # JVM unit tests incl. Room migration tests — must be green
./gradlew connectedAndroidTest   # only if a device/emulator is available
./gradlew installDebug

If JAVA_HOME is missing:

• Windows: $env:JAVA_HOME="C:\Program Files\Android\Android Studio\jbr"
• Linux/macOS: export JAVA_HOME=/opt/android-studio/jbr (or any JDK 21)

If no Android SDK is present (cloud sandboxes): sdkmanager "platforms;android-36" "build-tools;36.0.0" "platform-tools" and point local.properties (sdk.dir=...) at it. local.properties is git-ignored — never commit it.

5. Working rules

• Scope: Work only the milestone / task you were given. No look-ahead into later milestones, no drive-by refactoring, no "while I'm here" cleanups.
• Branches: New branch from main, name feature/m<N>-<short-description> (or fix/<short-description>). Never commit or push directly to main.
• Commits: Small, one per completed sub-step. Commit messages in German.
• Style: Match the existing code — comment density, naming, formatting. English identifiers, German UI strings.
• Room: Table names, column names and identityHash must never change accidentally. Migration tests are the proof. fallbackToDestructiveMigration() is forbidden.
• Do not touch: .idea/, manifest_error.txt, gradle/wrapper/*, app/schemas/*.json contents (only rename per plan when a class moves), unless the task explicitly says so.
• Crypto/BLE-Sicherheitscode (M6, Owner-Klarstellung 10.09.2026): Es gibt in diesem Repo keine selbstgeschriebene Kryptographie — alle Verschlüsselung läuft über androidx.security.crypto (Tink) mit Schlüsseln im Android Keystore (SettingsManager.kt); BLE-Sicherheit ist App-Logik (Geräte-Pinning, Stream-Plausibilisierung — GeraetePinning.kt, ConnectionSupervisor.kt), keine Kryptographie. Änderungen an diesem Code werden deshalb nicht als "Crypto-Review", sondern anhand von docs/CHECKLISTE_M6_SICHERHEITSREVIEW.md geprüft (Teil 1: korrekte Keystore/EncryptedSharedPreferences-Nutzung, Teil 2: Plausibilität der BLE-Sicherheitslogik gegen das Bedrohungsmodell aus Plan Abschnitt 6) — das kann der Owner ohne Krypto-Hintergrundwissen selbst durchgehen. Jede Abweichung vom Plan explizit im PR flaggen. Sollte künftig tatsächlich eine neue kryptographische Primitive nötig werden (nicht nur ein Aufruf von Keystore/Tink), ist das kein Fall für diese Checkliste, sondern ein offener Punkt für den Owner (Abschnitt 8a) — niemals selbst entscheiden oder implementieren.

6. Verification — non-negotiable

• After every change ./gradlew assembleDebug must pass. If it doesn't, the step is not done.
• New logic gets unit tests. ./gradlew test must be green.
• Never claim something works without having run it. If you could not verify something (no device, no SDK, no hardware), write exactly that.
• Show command output in the PR, not a summary of it.

7. Definition of Done for any task

1. assembleDebug and test green — output shown.
2. Both existing Room migration tests still green.
3. Acceptance criteria of the task brief met, each one addressed.
4. Branch pushed, Draft PR against main opened. PR body contains: what changed · what was verified (command + result) · what was deliberately left open · any plan contradiction or open decision encountered.
5. Short summary to the owner: done / not done / noticed.

8a. Clarify before implementing (owner instruction, 10.09.2026)

• Before building anything non-trivial, clarify open questions with the owner in detail first — do not guess at intent and implement something that might not match what the owner actually pictured. This generalizes section 2's rule for open decisions in the BLE plan (§13) to the whole project, not just that plan.
• If something genuinely cannot be decided yet (e.g. still under investigation, waiting on something else to resolve), do not silently guess and move on. Instead agree with the owner on a concrete checkpoint/milestone at which to come back and ask again — an open question should have an owner and a point where it gets revisited, not drift unaddressed.

8b. Emulator/instrumented tests for classes of bugs already hit once

• When a bug like #129 (android.permission.CAMERA declared in the manifest but not granted at runtime, silently breaking an implicit camera intent) ships and gets fixed, consider whether an instrumented test on the emulator (connectedAndroidTest) could have caught it and would catch a recurrence — not just a Robolectric/JVM unit test of the surrounding logic. Propose the test approach and get the owner's sign-off on it (per 8a) before writing it, since the right level of investment (a narrow regression test for this one bug vs. a broader test-strategy change) is itself a decision worth clarifying first.

9. Which agent does what (owner's convention)

• Codex: implementation of well-specified, hardware-free milestones (M1, B-11, later M4/M7/M7b), automatic PR review.
• Antigravity: UI-heavy work with emulator/visual feedback; second-opinion review using docs/PROMPT_REVIEW.md in a fresh session (different model than the implementer).
• Claude Code: GATT-dump interpretation after M0, M2 (BLE transport / state machine), open decisions (plan §13), tie-breaks when reviews disagree.

A reviewer never reviews its own implementation.