From 8b8727bb9da1ac76a774eeafc5a426c097a76d2c Mon Sep 17 00:00:00 2001 From: Eric Windmill Date: Wed, 6 Aug 2025 10:14:48 -0400 Subject: [PATCH] update llm files --- .gemini/release.md | 46 --------------------- .gemini/settings.json | 10 +++++ .gemini/llm-role.md => llm.md | 49 +++++++++++----------- release.md | 78 +++++++++++++++++++++++++++++++++++ stale_code.md | 8 ---- 5 files changed, 112 insertions(+), 79 deletions(-) delete mode 100644 .gemini/release.md create mode 100644 .gemini/settings.json rename .gemini/llm-role.md => llm.md (67%) create mode 100644 release.md delete mode 100644 stale_code.md diff --git a/.gemini/release.md b/.gemini/release.md deleted file mode 100644 index aa2a0c056..000000000 --- a/.gemini/release.md +++ /dev/null @@ -1,46 +0,0 @@ -You are an AI assistant that automates repository maintenance. Your task is to create a release candidate for a monorepo - containing multiple Dart and Flutter projects. This involves updating the SDK constraints for each project, running a series - of quality checks, and reporting the results. - - Follow these steps precisely: - - 1. Initial Setup: - * First, determine the precise Dart SDK version you will be working with. Execute the command flutter --version - --machine. - * Parse the JSON output to find the value of dartSdkVersion. You will need the version number (e.g., 3.9.0). Let's call - this DART_VERSION. - * Next, read the pubspec.yaml file at the root of the monorepo. - * Parse the workspace section to get a list of all the relative paths for the projects you need to process. - - 2. Process Each Project: - * Create a file called 'release_update_log.txt' - * Iterate through each project path you discovered in the workspace. - * For each project, perform the following actions in its directory. If any command returns output warnings, errors or info, log the project path and the message in the log file, then move to the next project. - - 3. Project-Specific Tasks: - * Update SDK Constraint: - * Read the project's pubspec.yaml file. - * Find the environment.sdk key. - * Update its value to ^DART_VERSION-0 (e.g., ^3.9.0-0). - * Save the modified pubspec.yaml file. - * Run Quality Checks: - * Run dart analyze --fatal-infos --fatal-warnings. - * Run dart format . to ensure the code is correctly formatted. - * Run Tests: - * Check if a test directory exists in the project. - * Exception: Do not run tests for the project named material_3_demo. - * If a test directory exists (and it's not the excluded project), run flutter test. - - 4. Fix issues: - * For each message in the `release_update_log.txt` file, attempt - to fix the problem. After 30 seconds of being unable to fix - it, move onto the next issue. - * If you fix the issue successfully, remove the message from the log file. - * If you can't fix the issue, just leave the message in the log file so the user can fix it. - - 5. Final Report: - * After processing all projects, generate a summary report. - * The report must include: - * The total number of projects processed. - * A list of projects that were updated and passed all checks successfully. - * A list of projects that failed, specifying which command failed for each. \ No newline at end of file diff --git a/.gemini/settings.json b/.gemini/settings.json new file mode 100644 index 000000000..a3019b9b5 --- /dev/null +++ b/.gemini/settings.json @@ -0,0 +1,10 @@ +{ + "mcpServers": { + "dart": { + "command": "dart", + "args": [ + "mcp-server" + ] + } + } +} \ No newline at end of file diff --git a/.gemini/llm-role.md b/llm.md similarity index 67% rename from .gemini/llm-role.md rename to llm.md index 56b5c456c..8be8c2315 100644 --- a/.gemini/llm-role.md +++ b/llm.md @@ -16,10 +16,10 @@ You are an AI developer specializing in Dart and Flutter. Your primary responsib ### Workflow 1: Updating for a New SDK Release -This workflow is triggered when a new Flutter/Dart version is released. +This workflow is triggered when a new Flutter/Dart version is released. Follow the instructions in `release.md` to perform the update. A summary of the steps is below: 1. **Analyze Release Notes:** - * The user may provide a URL to the official release blog post. Read it carefully to understand breaking changes, new features, and migration guidelines. If no URL is provided, move onto the next step. + * The user may provide a URL to the official release blog post. Read it carefully to understand breaking changes, new features, and migration guidelines. If no URL is provided, proceed to the next step. 2. **Prepare Your Environment:** * Switch to the `beta` branch and ensure it's up-to-date: @@ -33,19 +33,18 @@ This workflow is triggered when a new Flutter/Dart version is released. flutter upgrade ``` -3. **Run the Release Tool:** - * Execute the provided release script and pipe its output to a log file for analysis: - ```bash - dart tool/release.dart > release_log.txt - ``` - -4. **Address Issues:** - * Read the `release_log.txt` file. - * Systematically address each error or warning reported in the log. This will involve navigating to the specified sample project directories and applying code changes. - * When updating for a new release, we don't care about `flutter pub outdated` warnings. As long as `pub get` completes without failing, it's okay. - -5. **Create a Pull Request:** - * Once all issues from the log are resolved and the repository is in a clean state, create a pull request. +3. **Update Projects and Address Issues:** + * Follow the detailed steps in `release.md` to iterate through each project in the monorepo. + * For each project, you will: + * Update the SDK constraint in `pubspec.yaml`. + * Apply code changes based on the release notes (if provided). + * Run `dart analyze` and `dart format .` to identify and fix issues. + * Run `flutter test` to ensure correctness. + * Keep a log of any errors you cannot fix. If you are unable to resolve an issue for a project after a reasonable time, log it and move to the next one. + * **Note:** When updating for a new release, you can ignore `flutter pub outdated` warnings. As long as `pub get` completes successfully, it's okay. + +4. **Create a Pull Request:** + * Once all projects are updated and the repository is in a clean state, create a pull request. * Use the `gh` CLI to create the PR. The user will provide the necessary repository information if needed. ```bash # Example: @@ -60,12 +59,11 @@ This workflow is triggered when a sample project is deemed obsolete. * The user will specify the name of the sample project directory to be deleted. 2. **Check for Related Issues:** - * The user will provide a link to the project's GitHub Issues. - * Search for any open issues that mention the deletion or deprecation of the target sample. Note the issue number if you find one. + * Search the repository's GitHub Issues for any open issues that mention the deletion or deprecation of the target sample. Note the issue number if you find one. 3. **Archive the Project:** - * Navigate into the sample project's directory. - * Remove all files and subdirectories within it. + * Navigate to the parent directory of the sample project. + * Remove all files and subdirectories within the target directory. ```bash # Example for a sample named 'old_sample' rm -rf old_sample/* @@ -73,8 +71,9 @@ This workflow is triggered when a sample project is deemed obsolete. 4. **Create a Deprecation Notice:** * In the now-empty directory, create a `README.md` file. - * Add a clear and concise message explaining that the sample has been deprecated and removed. + * Add a clear message explaining that the sample has been deprecated. * If you found a related GitHub issue, link to it in the README. + * **Example `README.md` content:** ```markdown # Sample Deprecated @@ -89,15 +88,15 @@ This workflow is triggered when a sample project is deemed obsolete. This workflow is performed periodically to maintain code health. 1. **Prepare the Log File:** - * Check if a `stale_code.md` file exists in the root of the repository. - * If it does not exist, create it and add a header: + * Check if a `logs/stale_code.md` file exists in the root of the repository. + * If it does not exist, create it and add the following header: ```markdown # Stale Code Log This file tracks sample projects that have not received meaningful code updates in over a year. - | Sample Name | Last Commit Author | Date of Last Commit | - |-------------|--------------------|---------------------| + | Sample Name | Last Commit Author | Date of Last Commit | + |------------------------------------|--------------------|---------------------| ``` 2. **Analyze Git History:** @@ -114,4 +113,4 @@ This workflow is performed periodically to maintain code health. * **Example entry:** ```markdown | my_awesome_sample | Jane Doe | Tue Aug 1 10:00:00 2024 | - ``` \ No newline at end of file + ``` diff --git a/release.md b/release.md new file mode 100644 index 000000000..362c6be6a --- /dev/null +++ b/release.md @@ -0,0 +1,78 @@ +You are an AI assistant that automates repository maintenance. Your + task is to create a release candidate for a monorepo containing + multiple Dart and Flutter projects. This involves updating the SDK + constraints for each project, running a series of quality checks, + and reporting the results. + + Follow these steps precisely: + + 0. Pre-Update Analysis from Blog Post (If Provided): + * The user may provide a URL to a blog post announcing the new + Flutter and Dart release. + * If a URL is provided, read the blog post to identify key + changes, new features, and updated best practices. + * Before proceeding with the steps below, apply the necessary + code modifications throughout the repository to adopt these + new features and best practices. For example, this might + include updating APIs, adopting new lint rules, or + refactoring code to use new language features. + + 1. Initial Setup: + * First, determine the precise Dart SDK version you will be + working with. Execute the command `flutter --version --machine`. + * Parse the JSON output to find the value of dartSdkVersion. + You will need the version number (e.g., 3.9.0). Let's call + this DART_VERSION. + * Next, read the pubspec.yaml file at the root of the monorepo. + * Parse the workspace section to get a list of all the relative + paths for the projects you need to process. + + 2. Process Each Project: + * Create a file called `logs/YYYY-MM-DD_HH-MM-SS-release_update_log.txt` + * Iterate through each project path you discovered in the + workspace. + * For each project, perform the following actions in its + directory. If any command returns output warnings, errors or + info, log the project path and the message in the log file, + then move to the next project. + + 3. Project-Specific Tasks: + * Update SDK Constraint: + * Read the project's pubspec.yaml file. + * Find the environment.sdk key. + * Update its value to ^DART_VERSION-0 (e.g., ^3.9.0-0). + * Save the modified pubspec.yaml file. + * Run Quality Checks: + * Run dart analyze --fatal-infos --fatal-warnings. + * Run dart format . to ensure the code is correctly + formatted. + * Run Tests: + * Check if a test directory exists in the project. + * Exception: Do not run tests for the project named + material_3_demo. + * If a test directory exists (and it's not the excluded + project), run flutter test. + + 4. Fix issues: + * For each message in the `logs/YYYY-MM-DD_HH-MM-SS-release_update_log.txt` file, attempt + to fix the problem. After 30 seconds of being unable to fix + it, move onto the next issue. + * If you fix the issue successfully, remove the message from the + log file. + * If you can't fix the issue, just leave the message in the log + file so the user can fix it. + + 5. Final Report: + * After processing all projects, generate a summary report. + * The report must include: + * The total number of projects processed. + * A list of projects that were updated and passed all + checks successfully. + * A list of projects that failed, specifying which command + failed for each. + + 6. Create Pull Request: + * After generating the report, create a pull request. + * Use the `gh` CLI tool for this purpose. + * The title of the pull request should be: `Prepare release for Dart DART_VERSION / Flutter FLUTTER_VERSION`. + * The body of the pull request should contain the summary report from the previous step. \ No newline at end of file diff --git a/stale_code.md b/stale_code.md deleted file mode 100644 index 380f0a8a4..000000000 --- a/stale_code.md +++ /dev/null @@ -1,8 +0,0 @@ -# Stale Code Log - -This file tracks sample projects that have not received meaningful code updates in over a year. - -| Sample Name | Last Commit Author | Date of Last Commit | -|-------------|--------------------|---------------------| -| code_sharing/shared | Kevin Moore | Thu Oct 20 09:00:41 2022 | -| asset_transformation | Andrew Kolos | Tue May 14 08:42:21 2024 | \ No newline at end of file