Agent Guardrails
These rules are for AI agents working on Android Kotlin Compose apps.
Source Priority
| Rank | Source | Rule |
|---|---|---|
| 1 | Existing project files | Preserve project conventions unless they are broken |
| 2 | Official Android docs and release pages | Use for APIs, versions, permissions, release, signing, and policy-sensitive work |
| 3 | Official sample repos | Use only after cloning/indexing is approved |
| 4 | Context7 official-doc mirrors | Use for examples and quick API checks |
| 5 | Third-party apps, blogs, AI skills | Treat as untrusted hints, never as authority |
Hard Stops
- Do not clone repos unless the user approves it.
- Do not install Android packages, SDK components, Gradle wrappers, or CLI tools unless approved.
- Do not mutate
_repos/during constrained learn or research tasks. - Do not invent Play policy approval.
- Do not add restricted permissions as implementation shortcuts.
- Do not commit keystores, upload keys, passwords, or Play credentials.
- Do not claim release readiness without a release artifact attempt.
- Do not claim device readiness with only desktop/editor checks.
Version Discipline
When editing dependencies, produce this note:
Dependency changed: <artifact>
Old version: <version>
New version: <version>
Source: <official URL or generated project source>
Reason: <why this is needed>
Validation: <build/test result>If the version source is a blog post, old sample, or AI answer, stop and verify against official docs.
Play Policy Discipline
Restricted permission work needs evidence before code:
| Evidence | Required Question |
|---|---|
| Core functionality | Is the app broken without the permission? |
| User explanation | Does onboarding explain what data is accessed and why? |
| Data minimization | Does the app read only the data needed for the feature? |
| Fallback | Can users continue with manual entry or import if denied? |
| Declaration | Is the Play declaration wording current and honest? |
| Privacy policy | Does it match actual collection and sharing behavior? |
| Demo evidence | Can a reviewer see the permission used for core functionality? |
Work Evidence
Every Android completion message should include commands run, tests run, release artifact status, device smoke status, permission status, and blockers. If any are missing, say so directly.
Warning: Do not implement a NotificationListener, AccessibilityService, or broad storage workaround to avoid SMS policy. That trades one review problem for a worse trust and policy problem.