chore(repo): refine Gemini review style guide

Author: dackers86

.gemini/styleguide.md

@@ -6,18 +6,27 @@ If no root `AGENTS.md` file exists, use the guidance below.
 
 ## Review priorities
 
-- Prioritize correctness, regressions, and unsafe changes over style-only feedback.
-- Prefer concise, actionable comments with specific suggestions.
-- Avoid low-value nits unless they materially affect readability or consistency.
+- Prioritize correctness, regressions, crash risks, unsafe assumptions, and API mismatches over style-only feedback.
+- Prefer concise, actionable comments with concrete suggestions.
+- Avoid low-value nits unless they materially affect readability, consistency, or user-facing meaning.
 
-## Repository expectations
+## React Native Firebase expectations
 
 - Prefer consistency with existing patterns already used in the affected package or area.
-- Flag public API changes that should also update types, tests, or documentation.
-- Flag platform gaps when a change appears to require both iOS and Android support.
-- Prefer alignment with the Firebase Web SDK where that is the established project pattern.
+- Prefer alignment with the Firebase Web SDK for public API shape and behavior unless a difference is intentional and documented.
+- Flag public API changes that should also update TypeScript types, docs, and tests.
+- Flag platform gaps when a feature or fix appears to require both iOS and Android support.
+- If an API is platform-specific, check that the documentation and typings make that clear.
+- Prefer native method names that match the JavaScript API name where practical.
 
 ## Testing expectations
 
 - Suggest tests when behavior changes or regression risk increases.
+- Prefer focused tests near the changed package rather than broad new coverage.
 - Avoid asking for redundant tests when existing coverage already appears sufficient.
+
+## Comment behavior
+
+- Do not prioritize naming, formatting, or markdown wording comments ahead of correctness issues.
+- Do not comment on docs-only wording unless it changes meaning or could mislead users.
+- When a public API changes, prefer one combined comment covering types, docs, and tests instead of multiple fragmented comments.