Merge branch 'main' into pyush/refactor/settings-4

Author: psinha40898

…ni/commands/review-frontend-and-fix.toml .gemini/commands/review-and-fix.toml.gemini/commands/review-frontend-and-fix.toml renamed to .gemini/commands/review-and-fix.toml .gemini/commands/review-frontend-and-fix.toml renamed to .gemini/commands/review-and-fix.toml

@@ -1,6 +1,6 @@
-description = "Reviews a frontend PR or staged changes and automatically initiates a Pickle Fix loop for findings."
+description = "Reviews a PR or staged changes and automatically initiates a Pickle Fix loop for findings."
 prompt = """
-You are an expert Frontend Reviewer and Pickle Rick Worker.
+You are an expert Reviewer and Pickle Rick Worker.
 
 Target: {{args}}
 
@@ -56,8 +56,6 @@ Follow these steps to conduct a thorough review:
        pollution.
      * Use `vi.useFakeTimers()` for tests involving time-based logic to avoid
        flakiness.
-     * Avoid using `any` in tests; prefer proper types or `unknown` with
-       narrowing.
      * When creating parameterized tests, give the parameters types to ensure
        that the tests are type-safe.
 8. Evaluate all react logic carefully keeping in mind that the author of the
@@ -105,7 +103,20 @@ Follow these steps to conduct a thorough review:
       to include the new property or propose a new provider to add if the
       property drilling is excessive. Only use providers for properties that are
       consistent for the entire application.
-9. General Gemini CLI design principles:
+9. Evaluate `packages/core` (Services, Tools, Utilities):
+    * Ensure services are implemented as classes with clear lifecycle management (e.g., `initialize()` methods).
+    * Verify that `debugLogger` from `packages/core/src/utils/debugLogger.ts` is used for internal logging instead of `console`.
+    * Ensure all shell operations use `spawnAsync` from `packages/core/src/utils/shell-utils.ts` for consistent error handling and promise management.
+    * Check that filesystem errors are handled gracefully using `isNodeError` from `packages/core/src/utils/errors.ts`.
+    * Verify that new tools are added to `packages/core/src/tools/` and registered in `packages/core/src/tools/tool-registry.ts`.
+    * Ensure all new public services, utilities, and types are exported from `packages/core/src/index.ts`.
+    * Check that services are stateless where possible, or use the centralized `Storage` service for persistence.
+    * **Cross-Service Communication**: Prefer using the `coreEvents` bus (from `packages/core/src/utils/events.ts`) for asynchronous communication between services or to notify the UI of state changes. Avoid tight coupling between services.
+10. Architectural Audit (Package Boundaries):
+    * **Logic Placement**: Non-UI logic (e.g., model orchestration, tool implementation, git/filesystem operations) MUST reside in `packages/core`. `packages/cli` should only contain UI/Ink components, command-line argument parsing, and user interaction logic.
+    * **Environment Isolation**: Core logic should not assume a TUI environment. Use the `ConfirmationBus` or `Output` abstractions for communicating with the user from Core.
+    * **Decoupling**: Actively look for opportunities to decouple services by using `coreEvents`. If a service is importing another service just to notify it of a change, it should probably be using an event instead.
+11. General Gemini CLI design principles:
     * Make sure that settings are only used for options that a user might
       consider changing.
     * Do not add new command line arguments and suggest settings instead.
@@ -125,17 +136,23 @@ Follow these steps to conduct a thorough review:
       meta key shortcuts are supported on Mac.
     * Be skeptical of function keys and keyboard shortcuts that are commonly
       bound in VSCode as they may conflict.
-10. TypeScript Best Practices:
+12. TypeScript Best Practices:
     * Use 'checkExhaustive' in the 'default' clause of 'switch' statements to
       ensure all cases are handled.
     * Avoid using the non-null assertion operator ('!') unless absolutely
       necessary and you are confident the value is not null.
-11. Summarize all actionable findings into a concise but comprehensive directive output this to frontend_review.md and advance to phase 2.
+    * **STRICT TYPING**: Strictly forbid 'any' and 'unknown' in both CLI and Core
+      packages. 'unknown' is only allowed if it is immediately narrowed using
+      type guards or Zod validation. Reject any code that uses 'any' or
+      'unknown' without narrowing.
+13. **Ruthless Cleanup**:
+    * If you identify significant code duplication, technical debt, or "AI Slop" (boilerplate, redundant comments), explicitly suggest initiating a `ruthless-refactorer` loop to clean it up.
+14. Summarize all actionable findings into a concise but comprehensive directive output this to review_findings.md and advance to phase 2.
 
 Remember to use the GitHub CLI (`gh`) for all GitHub-related tasks, and local `git` commands if the target is 'staged'.
 
 Phase 2:
-You are initiating Pickle Rick - the ultimate coding agent.
+You are initiating Pickle Rick - the ultimate engineering agent.
 
 **Step 0: Persona Injection**
 First, you **MUST** activate your persona.
@@ -160,7 +177,7 @@ bash "${extensionPath}/scripts/setup.sh" $ARGUMENTS
 pwsh -File "${extensionPath}/scripts/setup.ps1" $ARGUMENTS
 ```
 
-**CRITICAL**: Your request is to fix all findings in frontend_review.md
+**CRITICAL**: Your request is to fix all findings in review_findings.md
 
 **Step 2: Execution (Management)**
 After setup, read the output to find the path to `state.json`.
@@ -188,11 +205,14 @@ Between each step, you **MUST** explicitly state what you are doing (e.g., "Movi
     *   **Validation**: IGNORE worker logs. DIRECTLY verify:
         1. `git status` (Check for file changes)
         2. `git diff` (Check code quality)
-        3. Run tests/build (Check functionality)
+        3. `npm run build` (Ensure the project still builds)
+        4. `npm run test` (Ensure no regressions)
+        5. `npm run lint` (Ensure code style is maintained)
+        6. `npm run typecheck` (Ensure type safety)
     *   **Cleanup**: If validation fails, REVERT changes (`git reset --hard`). If it passes, COMMIT changes.
     *   **Next Ticket**: Pick the next ticket and repeat.
 4.  **Cleanup**:
-    *   **Action**: After all tickets are completed delete `frontend_review.md`.
+    *   **Action**: After all tickets are completed delete `review_findings.md`.
 
 **Loop Constraints:**
 - **Iteration Count**: Monitor `"iteration"` in `state.json`. If `"max_iterations"` (if > 0) is reached, you must stop.

.gemini/settings.json

@@ -0,0 +1,7 @@
+{
+  "experimental": {
+    "toolOutputMasking": {
+      "enabled": true
+    }
+  }
+}

.gemini/skills/docs-changelog/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: docs-changelog
+description: Provides a step-by-step procedure for generating Gemini CLI changelog files based on github release information.
+---
+
+# Procedure: Updating Changelog for New Releases
+
+The following instructions are run by Gemini CLI when processing new releases.
+
+## Objective
+
+To standardize the process of updating the Gemini CLI changelog files for a new
+release, ensuring accuracy, consistency, and adherence to project style
+guidelines.
+
+## Release Types
+
+This skill covers two types of releases:
+
+*   **Standard Releases:** Regular, versioned releases that are announced to all
+    users. These updates modify `docs/changelogs/latest.md` and
+    `docs/changelogs/index.md`.
+*   **Preview Releases:** Pre-release versions for testing and feedback. These
+    updates only modify `docs/changelogs/preview.md`.
+
+Ignore all other releases, such as nightly releases.
+
+### Expected Inputs
+
+Regardless of the type of release, the following information is expected:
+
+*   **New version number:** The version number for the new release
+    (e.g., `v0.27.0`).
+*   **Release date:** The date of the new release (e.g., `2026-02-03`).
+*   **Raw changelog data:** A list of all pull requests and changes
+    included in the release, in the format `description by @author in
+    #pr_number`.
+*   **Previous version number:** The version number of the last release can be
+    calculated by decreasing the minor version number by one and setting the
+    patch or bug fix version number.
+
+## Procedure
+
+### Initial Setup
+
+1.  Identify the files to be modified: 
+
+    For standard releases, update `docs/changelogs/latest.md` and
+    `docs/changelogs/index.md`. For preview releases, update
+    `docs/changelogs/preview.md`.
+
+2.  Activate the `docs-writer` skill.
+
+### Analyze Raw Changelog Data
+
+1.  Review the complete list of changes. If it is a patch or a bug fix with few
+    changes, skip to the "Update `docs/changelogs/latest.md` or
+    `docs/changelogs/preview.md`" section.
+
+2.  Group related changes into high-level categories such as
+    important features, "UI/UX Improvements", and "Bug Fixes". Use the existing
+    announcements in `docs/changelogs/index.md` as an example.
+
+### Create Highlight Summaries
+
+Create two distinct versions of the release highlights.
+
+**Important:** Carefully inspect highlights for "experimental" or
+"preview" features before public announcement, and do not include them.
+
+#### Version 1: Comprehensive Highlights (for `latest.md` or `preview.md`)
+
+Write a detailed summary for each category focusing on user-facing
+impact.
+
+#### Version 2: Concise Highlights (for `index.md`)
+
+Skip this step for preview releases.
+
+Write concise summaries including the primary PR and author
+(e.g., `([#12345](link) by @author)`).
+
+### Update `docs/changelogs/latest.md` or `docs/changelogs/preview.md`
+
+1. Read current content and use `write_file` to replace it with the new
+  version number, and date.
+  
+  If it is a patch or bug fix with few changes, simply add these
+  changes to the "What's Changed" list. Otherwise, replace comprehensive
+  highlights, and the full "What's Changed" list. 
+
+2. For each item in the "What's Changed" list, keep usernames in plaintext, and
+  add github links for each issue number. Example:
+
+  "- feat: implement /rewind command by @username in
+  [#12345](https://github.com/google-gemini/gemini-cli/pull/12345)"
+
+3. Skip entries by @gemini-cli-robot.
+
+4. Do not add the "New Contributors" section.
+
+5. Update the "Full changelog:" link by doing one of following:
+
+   If it is a patch or bug fix with few changes, retain the original link
+   but replace the latter version with the new version. For example, if the
+   patch is version is "v0.28.1", replace the latter version:
+   "https://github.com/google-gemini/gemini-cli/compare/v0.27.0...v0.28.0" with
+   "https://github.com/google-gemini/gemini-cli/compare/v0.27.0...v0.28.1".
+   
+   Otherwise, for minor and major version changes, replace the link with the
+   one included at the end of the changelog data.
+
+6. Ensure lines are wrapped to 80 characters.
+
+### Update `docs/changelogs/index.md`
+
+Skip this step for patches, bug fixes, or preview releases.
+
+Insert a new "Announcements" section for the new version directly
+above the previous version's section. Ensure lines are wrapped to
+80 characters.
+
+### Finalize
+
+Run `npm run format` to ensure consistency.