S.H.O.N.A.R./CONTRIBUTING.md
avi aad7cad78d P3-M7: providers, background sync, AI pipeline
P3 CustomShonarProvider (auth, chunked uploads, secure token store).
P4 NextcloudProvider (login flow v2, DAV, chunking) + FolderSyncProvider
(Syncthing-style). P5 TOFU pinning + redacting logger + leak tests.
P6a generic hosted setup (Start9/Umbrel URL + auto-detect). P7 provider
switching (Room v2 slot, Storage screen, foreground migrator). M5
WorkManager drain (Room v3 backoff). M7 AI pipeline (4 adapters, arq
worker, transcript/summary/jobs endpoints). Docs updated throughout.
2026-09-12 11:29:55 -05:00

1.7 KiB

Contributing to S.H.O.N.A.R.

Thanks for your interest in improving S.H.O.N.A.R.!

Ground rules

  1. Original code only. Do not submit code, assets, names, logos, or API details derived from proprietary voice-note products (Plaud or otherwise). This project is Apache-2.0 and must stay clean-room.
  2. Privacy is a feature. Changes must not add telemetry, analytics, or undisclosed network calls. Any new external service integration requires explicit configuration and in-app disclosure.
  3. Never commit secrets. Configuration goes through environment variables (SHONAR_*) — never hard-coded credentials.
  4. Keep main buildable. Every PR must pass lint and tests.

Development setup

# Backend
./scripts/dev_bootstrap.sh
cd backend
.venv/bin/uvicorn shonar.main:app --reload
.venv/bin/pytest && .venv/bin/ruff check .

# Android
cd android
./gradlew test assembleDebug

Pull request checklist

  • ruff check . and pytest pass (backend)
  • ./gradlew test passes (Android, if touched)
  • API changes regenerate shared/openapi.json (scripts/gen_openapi.sh)
  • New endpoints have tests, including authorization checks
  • Docs updated when behaviour or configuration changes
  • Commit per logical unit; imperative-mess-free messages ("Add X", not "added x")

Style

  • Python 3.11+, type hints everywhere, 100-col, ruff format.
  • Kotlin with Compose; follow existing MVVM structure (ui → viewmodel → repository → data source).
  • Error messages shown to users must be safe: no stack traces, no internal paths, no information leakage about other users' data.

Reporting issues

Use the issue templates. For security issues, see SECURITY.md — do not open a public issue.