{"owner":"thunderbird","repo":"thunderbird-android","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AI Agent Guide for Thunderbird for Android\n\nThis file defines requirements for AI coding agents and automated systems contributing to this repository.\n\nAI-generated or AI-assisted contributions are acceptable only if they comply with these rules and meet the same\nstandards as human-written contributions.\n\n## Applicability\n\nThese requirements apply to:\n\n- All modules in this repository\n- All pull requests created fully or partially using AI tools\n- Automated refactoring, formatting, or code generation\n\n## Repository Context\n\nThunderbird for Android is a privacy-focused email client.\n\nThe repository implements a white-label architecture producing:\n\n- `app-thunderbird`: Thunderbird for Android\n- `app-k9mail`: K-9 Mail\n\nProject documentation resides in the `docs/` directory.\nArchitectural Decision Records (ADRs) are located in `docs/engineering/adr/`.\n\nAgents MUST consult relevant documentation before making architectural or structural changes.\n\n## Required Agent Workflow\n\nBefore making changes, agents MUST:\n\n### 1. Understand the Request\n\n- Confirm that requirements are clear and consistent with project rules\n- If requirements are incomplete, ambiguous, or conflicting:\n  - **Do NOT guess**\n  - Document assumptions\n  - Request clarification before proceeding\n\n### 2. Research Context\n\n- Read `README.md`, `docs/CONTRIBUTING.md`, and relevant documentation in `docs/`\n- Review existing implementations in affected modules\n- Check for related ADRs in `docs/engineering/adr/`\n- Understand the module's role in the white-label architecture\n\n### 3. Make Changes\n\n- Modify **only** files directly related to the requested change\n- Follow existing patterns and conventions in the affected modules\n- Maintain consistency with the established architecture\n\n### 4. Verify Changes\n\n- Run appropriate Gradle tasks (see [Build and Verification Requirements](#build-and-verification-requirements))\n- Ensure all checks pass before proposing changes\n\n## Architectural Requirements\n\n### Module Types\n\n- `app-*` — Application entry points (`app-thunderbird`, `app-k9mail`)\n- `app-common` — Wiring layer for features and dependency injection\n- `feature:*` — User-facing features (split into `:api` and `:internal` modules per ADR-0009)\n- `core:*` — Shared infrastructure and utilities (split into `:api` and `:internal` modules per ADR-0009)\n- `library:*` — Reusable libraries\n- `legacy:*` — Migration targets (contains original K-9 Mail codebase; avoid adding new logic here)\n\n### API / Internal Boundary\n\nAgents MUST:\n\n- Depend only on other modules' `:api` modules\n- Never depend on another module's `:internal` or `:internal-*` modules\n- Only `app-common`, `app-thunderbird`, and `app-k9mail` may depend on `:internal` modules (for DI wiring)\n- Keep implementation details internal using the `internal` modifier\n- Bind implementations in `app-common` or app modules only\n\nNew code MUST NOT violate the API/internal boundary, see [ADR-0009](docs/engineering/adr/0009-api-internal-split.md).\n\nIf existing code violates this boundary, agents MUST NOT replicate the pattern and SHOULD move the code toward the\nintended architecture when modifying it.\n\nAgents MUST NOT change module structure, dependency graphs, or architectural boundaries unless explicitly requested.\n\n## Technology Requirements\n\nAgents MUST use:\n\n- Kotlin for new code\n- Jetpack Compose for UI (mandatory for new features)\n- Atomic Design system components (see `docs/architecture/design-system.md`)\n- Koin for dependency injection (constructor injection)\n- Coroutines and Flow for concurrency\n- MVI (Unidirectional Data Flow) pattern (see `docs/architecture/ui-architecture.md`)\n\nTesting libraries:\n\n- `assertk`\n- `kotlinx-coroutines-test`\n- Turbine\n\nTesting policy:\n\n- Prefer **fakes over mocks** (see [Testing Guide](docs/contributing/testing-guide.md))\n- Avoid mocking frameworks unless strongly justified\n- Use Arrange-Act-Assert (AAA) pattern\n- Name the object under test `testSubject`\n\nAgents MUST NOT introduce alternative frameworks.\n\n## Coding Requirements\n\nAgents MUST:\n\n- Make small, focused, reviewable changes\n- Prioritize privacy, security, and correctness over convenience or shorter code\n- Modify only files directly related to the requested change\n- Follow the exact naming and formatting conventions of the file and module being modified\n- NOT reformat, modernize, or clean up unrelated code\n- Avoid speculative refactoring\n\n### UI Constraints\n\n- Use Atomic Design components from the design system (see `docs/architecture/design-system.md`)\n- Raw Material components are NOT allowed outside design system modules and the catalog app\n- For existing View-based code, maintain consistency using legacy design system components\n- Do NOT introduce new design systems; extend the existing system within its modules\n\n### Logging and Privacy\n\nPrivacy is a core value of this project.\n\nAgents MUST:\n\n- Use `net.thunderbird.core.logging.Logger` via dependency injection\n- NEVER log PII (Personally Identifiable Information)\n- NEVER log credentials, passwords, or authentication tokens\n- NEVER log message content or email addresses\n\n## Security Requirements\n\nThis is a privacy-focused email client. Security is non-negotiable.\n\nAgents MUST NOT:\n\n- Add telemetry, analytics, ads, or tracking of any kind\n- Add permissions without explicit request and justification\n- Introduce insecure cryptography or unsafe networking\n- Hardcode secrets, credentials, API keys, or tokens\n- Modify OAuth configuration unless explicitly instructed\n- Change licensing headers or license terms\n- Introduce dependencies with known vulnerabilities\n\nAll external input MUST be treated as untrusted. Validate and sanitize user input.\n\n## Build and Verification Requirements\n\nBefore proposing changes, agents MUST run the narrowest relevant Gradle tasks and ensure they pass.\n\n### Build\n\n- `./gradlew assemble`\n- `./gradlew build`\n- `./gradlew :app-thunderbird:assembleDebug`\n- `./gradlew :app-k9mail:assembleDebug`\n\n### Tests\n\n- `./gradlew test`\n- `./gradlew connectedAndroidTest`\n\n### Code Quality\n\n- `./gradlew lint`\n- `./gradlew detekt`\n- `./gradlew spotlessCheck`\n- `./gradlew spotlessApply` (to fix formatting issues)\n\n### Bug Fix Requirements\n\nWhen fixing bugs, agents MUST:\n\n- Add or update tests to cover the bug\n- Ensure tests **fail before the fix** (when applicable)\n- Ensure all relevant tasks **pass after the fix**\n- Run at least: `./gradlew test lint detekt spotlessCheck`\n\n### Limitations\n\nIf required tasks cannot be executed locally (e.g., no Android device/emulator for `connectedAndroidTest`):\n\n- Agents MUST explicitly state which tasks were not run and why\n- Include this information in the pull request description\n\n## Commit Requirements\n\nThis repository uses Conventional Commits for all commit messages.\n\nAgents MUST:\n\n- Use appropriate prefixes (`feat:`, `fix:`, `refactor:`, `style:`, `test:`, `chore:`)\n- Keep commits small and logically scoped\n- Separate formatting-only changes into `style:` commits\n- Separate refactoring from functional changes\n- Avoid mixing behavior changes and formatting in a single commit\n\n## Pull Request Requirements\n\nPull requests MUST include:\n\n- A clear description of changes\n- The reason for the change\n- Exact Gradle commands used for testing\n- Known risks or trade-offs\n- Disclosure of AI assistance (if applicable)\n\nAI assistance does not reduce review standards.\n\n## Escalation\n\n### When to Stop and Ask\n\nIf uncertain about:\n\n- Requirements (incomplete, ambiguous, or conflicting)\n- Architectural decisions\n- Module boundaries or dependencies\n- Technology choices\n- Security implications\n\n**Then:**\n\n1. Stop — Do not proceed with uncertain changes\n2. Document assumptions — Write down what you understand and what's unclear\n3. Request clarification — Ask specific questions\n\n### What NOT to Do\n\nAgents MUST NOT:\n\n- Invent architecture or design patterns\n- Bypass module boundaries to \"make it work\"\n- Prioritize elegance over established project conventions\n- Guess at requirements or implementation details\n- Make breaking changes without explicit approval\n\nWhen in doubt, ask. It's always better to clarify than to guess wrong.\n"},"files":{"AGENTS.md":"# AI Agent Guide for Thunderbird for Android\n\nThis file defines requirements for AI coding agents and automated systems contributing to this repository.\n\nAI-generated or AI-assisted contributions are acceptable only if they comply with these rules and meet the same\nstandards as human-written contributions.\n\n## Applicability\n\nThese requirements apply to:\n\n- All modules in this repository\n- All pull requests created fully or partially using AI tools\n- Automated refactoring, formatting, or code generation\n\n## Repository Context\n\nThunderbird for Android is a privacy-focused email client.\n\nThe repository implements a white-label architecture producing:\n\n- `app-thunderbird`: Thunderbird for Android\n- `app-k9mail`: K-9 Mail\n\nProject documentation resides in the `docs/` directory.\nArchitectural Decision Records (ADRs) are located in `docs/engineering/adr/`.\n\nAgents MUST consult relevant documentation before making architectural or structural changes.\n\n## Required Agent Workflow\n\nBefore making changes, agents MUST:\n\n### 1. Understand the Request\n\n- Confirm that requirements are clear and consistent with project rules\n- If requirements are incomplete, ambiguous, or conflicting:\n  - **Do NOT guess**\n  - Document assumptions\n  - Request clarification before proceeding\n\n### 2. Research Context\n\n- Read `README.md`, `docs/CONTRIBUTING.md`, and relevant documentation in `docs/`\n- Review existing implementations in affected modules\n- Check for related ADRs in `docs/engineering/adr/`\n- Understand the module's role in the white-label architecture\n\n### 3. Make Changes\n\n- Modify **only** files directly related to the requested change\n- Follow existing patterns and conventions in the affected modules\n- Maintain consistency with the established architecture\n\n### 4. Verify Changes\n\n- Run appropriate Gradle tasks (see [Build and Verification Requirements](#build-and-verification-requirements))\n- Ensure all checks pass before proposing changes\n\n## Architectural Requirements\n\n### Module Types\n\n- `app-*` — Application entry points (`app-thunderbird`, `app-k9mail`)\n- `app-common` — Wiring layer for features and dependency injection\n- `feature:*` — User-facing features (split into `:api` and `:internal` modules per ADR-0009)\n- `core:*` — Shared infrastructure and utilities (split into `:api` and `:internal` modules per ADR-0009)\n- `library:*` — Reusable libraries\n- `legacy:*` — Migration targets (contains original K-9 Mail codebase; avoid adding new logic here)\n\n### API / Internal Boundary\n\nAgents MUST:\n\n- Depend only on other modules' `:api` modules\n- Never depend on another module's `:internal` or `:internal-*` modules\n- Only `app-common`, `app-thunderbird`, and `app-k9mail` may depend on `:internal` modules (for DI wiring)\n- Keep implementation details internal using the `internal` modifier\n- Bind implementations in `app-common` or app modules only\n\nNew code MUST NOT violate the API/internal boundary, see [ADR-0009](docs/engineering/adr/0009-api-internal-split.md).\n\nIf existing code violates this boundary, agents MUST NOT replicate the pattern and SHOULD move the code toward the\nintended architecture when modifying it.\n\nAgents MUST NOT change module structure, dependency graphs, or architectural boundaries unless explicitly requested.\n\n## Technology Requirements\n\nAgents MUST use:\n\n- Kotlin for new code\n- Jetpack Compose for UI (mandatory for new features)\n- Atomic Design system components (see `docs/architecture/design-system.md`)\n- Koin for dependency injection (constructor injection)\n- Coroutines and Flow for concurrency\n- MVI (Unidirectional Data Flow) pattern (see `docs/architecture/ui-architecture.md`)\n\nTesting libraries:\n\n- `assertk`\n- `kotlinx-coroutines-test`\n- Turbine\n\nTesting policy:\n\n- Prefer **fakes over mocks** (see [Testing Guide](docs/contributing/testing-guide.md))\n- Avoid mocking frameworks unless strongly justified\n- Use Arrange-Act-Assert (AAA) pattern\n- Name the object under test `testSubject`\n\nAgents MUST NOT introduce alternative frameworks.\n\n## Coding Requirements\n\nAgents MUST:\n\n- Make small, focused, reviewable changes\n- Prioritize privacy, security, and correctness over convenience or shorter code\n- Modify only files directly related to the requested change\n- Follow the exact naming and formatting conventions of the file and module being modified\n- NOT reformat, modernize, or clean up unrelated code\n- Avoid speculative refactoring\n\n### UI Constraints\n\n- Use Atomic Design components from the design system (see `docs/architecture/design-system.md`)\n- Raw Material components are NOT allowed outside design system modules and the catalog app\n- For existing View-based code, maintain consistency using legacy design system components\n- Do NOT introduce new design systems; extend the existing system within its modules\n\n### Logging and Privacy\n\nPrivacy is a core value of this project.\n\nAgents MUST:\n\n- Use `net.thunderbird.core.logging.Logger` via dependency injection\n- NEVER log PII (Personally Identifiable Information)\n- NEVER log credentials, passwords, or authentication tokens\n- NEVER log message content or email addresses\n\n## Security Requirements\n\nThis is a privacy-focused email client. Security is non-negotiable.\n\nAgents MUST NOT:\n\n- Add telemetry, analytics, ads, or tracking of any kind\n- Add permissions without explicit request and justification\n- Introduce insecure cryptography or unsafe networking\n- Hardcode secrets, credentials, API keys, or tokens\n- Modify OAuth configuration unless explicitly instructed\n- Change licensing headers or license terms\n- Introduce dependencies with known vulnerabilities\n\nAll external input MUST be treated as untrusted. Validate and sanitize user input.\n\n## Build and Verification Requirements\n\nBefore proposing changes, agents MUST run the narrowest relevant Gradle tasks and ensure they pass.\n\n### Build\n\n- `./gradlew assemble`\n- `./gradlew build`\n- `./gradlew :app-thunderbird:assembleDebug`\n- `./gradlew :app-k9mail:assembleDebug`\n\n### Tests\n\n- `./gradlew test`\n- `./gradlew connectedAndroidTest`\n\n### Code Quality\n\n- `./gradlew lint`\n- `./gradlew detekt`\n- `./gradlew spotlessCheck`\n- `./gradlew spotlessApply` (to fix formatting issues)\n\n### Bug Fix Requirements\n\nWhen fixing bugs, agents MUST:\n\n- Add or update tests to cover the bug\n- Ensure tests **fail before the fix** (when applicable)\n- Ensure all relevant tasks **pass after the fix**\n- Run at least: `./gradlew test lint detekt spotlessCheck`\n\n### Limitations\n\nIf required tasks cannot be executed locally (e.g., no Android device/emulator for `connectedAndroidTest`):\n\n- Agents MUST explicitly state which tasks were not run and why\n- Include this information in the pull request description\n\n## Commit Requirements\n\nThis repository uses Conventional Commits for all commit messages.\n\nAgents MUST:\n\n- Use appropriate prefixes (`feat:`, `fix:`, `refactor:`, `style:`, `test:`, `chore:`)\n- Keep commits small and logically scoped\n- Separate formatting-only changes into `style:` commits\n- Separate refactoring from functional changes\n- Avoid mixing behavior changes and formatting in a single commit\n\n## Pull Request Requirements\n\nPull requests MUST include:\n\n- A clear description of changes\n- The reason for the change\n- Exact Gradle commands used for testing\n- Known risks or trade-offs\n- Disclosure of AI assistance (if applicable)\n\nAI assistance does not reduce review standards.\n\n## Escalation\n\n### When to Stop and Ask\n\nIf uncertain about:\n\n- Requirements (incomplete, ambiguous, or conflicting)\n- Architectural decisions\n- Module boundaries or dependencies\n- Technology choices\n- Security implications\n\n**Then:**\n\n1. Stop — Do not proceed with uncertain changes\n2. Document assumptions — Write down what you understand and what's unclear\n3. Request clarification — Ask specific questions\n\n### What NOT to Do\n\nAgents MUST NOT:\n\n- Invent architecture or design patterns\n- Bypass module boundaries to \"make it work\"\n- Prioritize elegance over established project conventions\n- Guess at requirements or implementation details\n- Make breaking changes without explicit approval\n\nWhen in doubt, ask. It's always better to clarify than to guess wrong.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AI Agent Guide for Thunderbird for Android\n\nThis file defines requirements for AI coding agents and automated systems contributing to this repository.\n\nAI-generated or AI-assisted contributions are acceptable only if they comply with these rules and meet the same\nstandards as human-written contributions.\n\n## Applicability\n\nThese requirements apply to:\n\n- All modules in this repository\n- All pull requests created fully or partially using AI tools\n- Automated refactoring, formatting, or code generation\n\n## Repository Context\n\nThunderbird for Android is a privacy-focused email client.\n\nThe repository implements a white-label architecture producing:\n\n- `app-thunderbird`: Thunderbird for Android\n- `app-k9mail`: K-9 Mail\n\nProject documentation resides in the `docs/` directory.\nArchitectural Decision Records (ADRs) are located in `docs/engineering/adr/`.\n\nAgents MUST consult relevant documentation before making architectural or structural changes.\n\n## Required Agent Workflow\n\nBefore making changes, agents MUST:\n\n### 1. Understand the Request\n\n- Confirm that requirements are clear and consistent with project rules\n- If requirements are incomplete, ambiguous, or conflicting:\n  - **Do NOT guess**\n  - Document assumptions\n  - Request clarification before proceeding\n\n### 2. Research Context\n\n- Read `README.md`, `docs/CONTRIBUTING.md`, and relevant documentation in `docs/`\n- Review existing implementations in affected modules\n- Check for related ADRs in `docs/engineering/adr/`\n- Understand the module's role in the white-label architecture\n\n### 3. Make Changes\n\n- Modify **only** files directly related to the requested change\n- Follow existing patterns and conventions in the affected modules\n- Maintain consistency with the established architecture\n\n### 4. Verify Changes\n\n- Run appropriate Gradle tasks (see [Build and Verification Requirements](#build-and-verification-requirements))\n- Ensure all checks pass before proposing changes\n\n## Architectural Requirements\n\n### Module Types\n\n- `app-*` — Application entry points (`app-thunderbird`, `app-k9mail`)\n- `app-common` — Wiring layer for features and dependency injection\n- `feature:*` — User-facing features (split into `:api` and `:internal` modules per ADR-0009)\n- `core:*` — Shared infrastructure and utilities (split into `:api` and `:internal` modules per ADR-0009)\n- `library:*` — Reusable libraries\n- `legacy:*` — Migration targets (contains original K-9 Mail codebase; avoid adding new logic here)\n\n### API / Internal Boundary\n\nAgents MUST:\n\n- Depend only on other modules' `:api` modules\n- Never depend on another module's `:internal` or `:internal-*` modules\n- Only `app-common`, `app-thunderbird`, and `app-k9mail` may depend on `:internal` modules (for DI wiring)\n- Keep implementation details internal using the `internal` modifier\n- Bind implementations in `app-common` or app modules only\n\nNew code MUST NOT violate the API/internal boundary, see [ADR-0009](docs/engineering/adr/0009-api-internal-split.md).\n\nIf existing code violates this boundary, agents MUST NOT replicate the pattern and SHOULD move the code toward the\nintended architecture when modifying it.\n\nAgents MUST NOT change module structure, dependency graphs, or architectural boundaries unless explicitly requested.\n\n## Technology Requirements\n\nAgents MUST use:\n\n- Kotlin for new code\n- Jetpack Compose for UI (mandatory for new features)\n- Atomic Design system components (see `docs/architecture/design-system.md`)\n- Koin for dependency injection (constructor injection)\n- Coroutines and Flow for concurrency\n- MVI (Unidirectional Data Flow) pattern (see `docs/architecture/ui-architecture.md`)\n\nTesting libraries:\n\n- `assertk`\n- `kotlinx-coroutines-test`\n- Turbine\n\nTesting policy:\n\n- Prefer **fakes over mocks** (see [Testing Guide](docs/contributing/testing-guide.md))\n- Avoid mocking frameworks unless strongly justified\n- Use Arrange-Act-Assert (AAA) pattern\n- Name the object under test `testSubject`\n\nAgents MUST NOT introduce alternative frameworks.\n\n## Coding Requirements\n\nAgents MUST:\n\n- Make small, focused, reviewable changes\n- Prioritize privacy, security, and correctness over convenience or shorter code\n- Modify only files directly related to the requested change\n- Follow the exact naming and formatting conventions of the file and module being modified\n- NOT reformat, modernize, or clean up unrelated code\n- Avoid speculative refactoring\n\n### UI Constraints\n\n- Use Atomic Design components from the design system (see `docs/architecture/design-system.md`)\n- Raw Material components are NOT allowed outside design system modules and the catalog app\n- For existing View-based code, maintain consistency using legacy design system components\n- Do NOT introduce new design systems; extend the existing system within its modules\n\n### Logging and Privacy\n\nPrivacy is a core value of this project.\n\nAgents MUST:\n\n- Use `net.thunderbird.core.logging.Logger` via dependency injection\n- NEVER log PII (Personally Identifiable Information)\n- NEVER log credentials, passwords, or authentication tokens\n- NEVER log message content or email addresses\n\n## Security Requirements\n\nThis is a privacy-focused email client. Security is non-negotiable.\n\nAgents MUST NOT:\n\n- Add telemetry, analytics, ads, or tracking of any kind\n- Add permissions without explicit request and justification\n- Introduce insecure cryptography or unsafe networking\n- Hardcode secrets, credentials, API keys, or tokens\n- Modify OAuth configuration unless explicitly instructed\n- Change licensing headers or license terms\n- Introduce dependencies with known vulnerabilities\n\nAll external input MUST be treated as untrusted. Validate and sanitize user input.\n\n## Build and Verification Requirements\n\nBefore proposing changes, agents MUST run the narrowest relevant Gradle tasks and ensure they pass.\n\n### Build\n\n- `./gradlew assemble`\n- `./gradlew build`\n- `./gradlew :app-thunderbird:assembleDebug`\n- `./gradlew :app-k9mail:assembleDebug`\n\n### Tests\n\n- `./gradlew test`\n- `./gradlew connectedAndroidTest`\n\n### Code Quality\n\n- `./gradlew lint`\n- `./gradlew detekt`\n- `./gradlew spotlessCheck`\n- `./gradlew spotlessApply` (to fix formatting issues)\n\n### Bug Fix Requirements\n\nWhen fixing bugs, agents MUST:\n\n- Add or update tests to cover the bug\n- Ensure tests **fail before the fix** (when applicable)\n- Ensure all relevant tasks **pass after the fix**\n- Run at least: `./gradlew test lint detekt spotlessCheck`\n\n### Limitations\n\nIf required tasks cannot be executed locally (e.g., no Android device/emulator for `connectedAndroidTest`):\n\n- Agents MUST explicitly state which tasks were not run and why\n- Include this information in the pull request description\n\n## Commit Requirements\n\nThis repository uses Conventional Commits for all commit messages.\n\nAgents MUST:\n\n- Use appropriate prefixes (`feat:`, `fix:`, `refactor:`, `style:`, `test:`, `chore:`)\n- Keep commits small and logically scoped\n- Separate formatting-only changes into `style:` commits\n- Separate refactoring from functional changes\n- Avoid mixing behavior changes and formatting in a single commit\n\n## Pull Request Requirements\n\nPull requests MUST include:\n\n- A clear description of changes\n- The reason for the change\n- Exact Gradle commands used for testing\n- Known risks or trade-offs\n- Disclosure of AI assistance (if applicable)\n\nAI assistance does not reduce review standards.\n\n## Escalation\n\n### When to Stop and Ask\n\nIf uncertain about:\n\n- Requirements (incomplete, ambiguous, or conflicting)\n- Architectural decisions\n- Module boundaries or dependencies\n- Technology choices\n- Security implications\n\n**Then:**\n\n1. Stop — Do not proceed with uncertain changes\n2. Document assumptions — Write down what you understand and what's unclear\n3. Request clarification — Ask specific questions\n\n### What NOT to Do\n\nAgents MUST NOT:\n\n- Invent architecture or design patterns\n- Bypass module boundaries to \"make it work\"\n- Prioritize elegance over established project conventions\n- Guess at requirements or implementation details\n- Make breaking changes without explicit approval\n\nWhen in doubt, ask. It's always better to clarify than to guess wrong.\n","category":"root","tokens":2038}]}