From 9aa668092454ca5536167856f3b549b79fe61277 Mon Sep 17 00:00:00 2001 From: Stephen Benjamin Date: Sat, 9 May 2026 17:31:57 -0400 Subject: [PATCH 1/4] Fix instruction positioning and hedging in AI config files Addresses 10 skillsaw lint warnings across .coderabbit.yaml and .apm/prompts/ by: - Removing hedging language ("ideally", "where possible") in favor of direct requirements - Moving critical instructions (NEVER, MUST, CRITICAL, IMPORTANT) out of the attention dead zone (20-80% of file) to the first or last 20% where LLMs pay more attention Based on attention research (lost-in-the-middle) showing that LLMs attend less to instructions in the middle of long contexts. Co-Authored-By: Claude Opus 4.6 --- .../sippy-generate-release-views.prompt.md | 6 +++-- .../sippy-update-ga-release-views.prompt.md | 4 ++-- .../sippy-update-job-variant.prompt.md | 24 +++++++++---------- .coderabbit.yaml | 4 ++-- 4 files changed, 20 insertions(+), 18 deletions(-) diff --git a/.apm/prompts/sippy-generate-release-views.prompt.md b/.apm/prompts/sippy-generate-release-views.prompt.md index eb2794764..27b4085eb 100644 --- a/.apm/prompts/sippy-generate-release-views.prompt.md +++ b/.apm/prompts/sippy-generate-release-views.prompt.md @@ -5,6 +5,8 @@ input: [source-release, target-release] # Generate Release Views +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + This command generates new component readiness views for a new release by copying and updating existing views from a previous release. ## Arguments (all optional) @@ -37,7 +39,7 @@ If any arguments are not provided, you will prompt the user interactively. - **Base Release**: - If base = sample (same-release comparison), both become target - If base != sample (cross-release comparison), increment base by one minor version - - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` 5. **Verify Output**: Show a diff of the changes made to views.yaml @@ -56,7 +58,7 @@ When copying a view from source release to target release: 3. **Base Release Update**: Depends on the original relationship - **Same-release views** (base = sample): Both become target - **Cross-release views** (base != sample): Base increments by one - - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` ## Examples diff --git a/.apm/prompts/sippy-update-ga-release-views.prompt.md b/.apm/prompts/sippy-update-ga-release-views.prompt.md index 5bbac6b10..e5a16244e 100644 --- a/.apm/prompts/sippy-update-ga-release-views.prompt.md +++ b/.apm/prompts/sippy-update-ga-release-views.prompt.md @@ -44,8 +44,6 @@ If the argument is not provided, you will prompt the user interactively. **F. Decrease pass_rate_required_new_tests**: - Set `pass_rate_required_new_tests` to `90` (from 95) - - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) - 4. **Verify Output**: Show a diff of the changes made to views.yaml 5. **Run Validation Test**: @@ -71,3 +69,5 @@ This command is part of the release lifecycle workflow: - Use the Edit tool for each change to preserve exact YAML formatting - Always verify the diff to ensure only expected changes were made - This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) diff --git a/.apm/prompts/sippy-update-job-variant.prompt.md b/.apm/prompts/sippy-update-job-variant.prompt.md index 84dc45ed2..d958e6359 100644 --- a/.apm/prompts/sippy-update-job-variant.prompt.md +++ b/.apm/prompts/sippy-update-job-variant.prompt.md @@ -50,8 +50,8 @@ You will guide the user through the following steps (skipping steps where argume - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) - Add an entry to the pattern matching logic in that function with the pattern and new value - Follow the existing code style and pattern structure (see examples in the file) - - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. - - More specific patterns MUST come before more generic patterns + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point @@ -78,16 +78,6 @@ You will guide the user through the following steps (skipping steps where argume - Always commit both the Go code changes AND the regenerated snapshot.yaml - Pattern matching is done with `strings.Contains(jobNameLower, pattern)` -### Pattern Ordering is CRITICAL -- **The setter functions use early return - the FIRST matching pattern wins** -- More specific patterns MUST appear before more generic patterns -- Common examples to learn from: - - `-rosa` before `-aws` (ROSA jobs contain "aws") - - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") - - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") - - `-perfscale` before `-qe` (perfscale jobs may contain "qe") -- Always verify the diff doesn't show unintended changes to other jobs - ## Helper Commands ### Extracting Variant Categories @@ -109,3 +99,13 @@ go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "S ```bash grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort ``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs diff --git a/.coderabbit.yaml b/.coderabbit.yaml index ba56755e4..a211f683b 100644 --- a/.coderabbit.yaml +++ b/.coderabbit.yaml @@ -37,7 +37,7 @@ reviews: explaining the purpose of each major query section (CTEs, JOINs, window functions, WHERE clauses). Abbreviations like CTE, matview, etc. should be expanded on first use. Functions that construct queries - should ideally stay under 200 lines; extract sub-queries or CTEs into + must stay under 200 lines; extract sub-queries or CTEs into helper functions when they grow beyond that. - path: "pkg/apis/**/*.go" instructions: | @@ -105,7 +105,7 @@ reviews: - name: "Test Coverage for New Features" mode: warning instructions: | - New or modified functionality should include test coverage where possible: + New or modified functionality must include test coverage: - New Go functions and methods should have corresponding unit tests - Bug fixes should include a regression test that fails without the fix - Pure functions (no DB/external dependencies) should always be tested From ea5118aa798c75a27ca3eb1e5b604f9e4ddf5ec2 Mon Sep 17 00:00:00 2001 From: Stephen Benjamin Date: Sat, 9 May 2026 17:48:52 -0400 Subject: [PATCH 2/4] Bump apm-cli to 0.12.4 and update apm.yml config format Update apm.yml to use the new 0.12.4 config schema (targets list, structured dependencies) and bump the Makefile pin. Recompile all generated output. Co-Authored-By: Claude Opus 4.6 --- .../commands/sippy-generate-release-views.md | 10 +- .../commands/sippy-update-ga-release-views.md | 9 +- .claude/commands/sippy-update-job-variant.md | 31 +++--- .../sippy-generate-release-views.toml | 2 +- .../sippy-update-ga-release-views.toml | 2 +- .../commands/sippy-update-job-variant.toml | 2 +- .../commands/sippy-generate-release-views.md | 10 +- .../commands/sippy-update-ga-release-views.md | 9 +- .../commands/sippy-update-job-variant.md | 31 +++--- AGENTS.md | 4 +- CLAUDE.md | 4 +- GEMINI.md | 4 +- Makefile | 4 +- apm.lock.yaml | 96 ++++++++++--------- apm.yml | 10 +- mcp/AGENTS.md | 4 +- mcp/CLAUDE.md | 4 +- sippy-ng/AGENTS.md | 4 +- sippy-ng/CLAUDE.md | 4 +- 19 files changed, 144 insertions(+), 100 deletions(-) diff --git a/.claude/commands/sippy-generate-release-views.md b/.claude/commands/sippy-generate-release-views.md index 88e270fbb..4737cda7d 100644 --- a/.claude/commands/sippy-generate-release-views.md +++ b/.claude/commands/sippy-generate-release-views.md @@ -1,9 +1,15 @@ --- +argument-hint: +arguments: +- source-release +- target-release description: Generate new component readiness views for a new release --- # Generate Release Views +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + This command generates new component readiness views for a new release by copying and updating existing views from a previous release. ## Arguments (all optional) @@ -36,7 +42,7 @@ If any arguments are not provided, you will prompt the user interactively. - **Base Release**: - If base = sample (same-release comparison), both become target - If base != sample (cross-release comparison), increment base by one minor version - - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` 5. **Verify Output**: Show a diff of the changes made to views.yaml @@ -55,7 +61,7 @@ When copying a view from source release to target release: 3. **Base Release Update**: Depends on the original relationship - **Same-release views** (base = sample): Both become target - **Cross-release views** (base != sample): Base increments by one - - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` ## Examples diff --git a/.claude/commands/sippy-update-ga-release-views.md b/.claude/commands/sippy-update-ga-release-views.md index 0a737a518..15b5aa6c4 100644 --- a/.claude/commands/sippy-update-ga-release-views.md +++ b/.claude/commands/sippy-update-ga-release-views.md @@ -1,4 +1,7 @@ --- +argument-hint: +arguments: +- release description: Update component readiness views when a release goes GA --- @@ -43,8 +46,6 @@ If the argument is not provided, you will prompt the user interactively. **F. Decrease pass_rate_required_new_tests**: - Set `pass_rate_required_new_tests` to `90` (from 95) - - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) - 4. **Verify Output**: Show a diff of the changes made to views.yaml 5. **Run Validation Test**: @@ -69,4 +70,6 @@ This command is part of the release lifecycle workflow: - Views where `sample_release.release` equals the GA release (sensitivity reductions) - Use the Edit tool for each change to preserve exact YAML formatting - Always verify the diff to ensure only expected changes were made -- This is typically run once when a release goes GA \ No newline at end of file +- This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) \ No newline at end of file diff --git a/.claude/commands/sippy-update-job-variant.md b/.claude/commands/sippy-update-job-variant.md index f5e0ab057..0c5dad130 100644 --- a/.claude/commands/sippy-update-job-variant.md +++ b/.claude/commands/sippy-update-job-variant.md @@ -1,4 +1,9 @@ --- +argument-hint: +arguments: +- job-pattern +- category +- value description: Interactively update variants for a CI job --- @@ -49,8 +54,8 @@ You will guide the user through the following steps (skipping steps where argume - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) - Add an entry to the pattern matching logic in that function with the pattern and new value - Follow the existing code style and pattern structure (see examples in the file) - - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. - - More specific patterns MUST come before more generic patterns + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point @@ -77,16 +82,6 @@ You will guide the user through the following steps (skipping steps where argume - Always commit both the Go code changes AND the regenerated snapshot.yaml - Pattern matching is done with `strings.Contains(jobNameLower, pattern)` -### Pattern Ordering is CRITICAL -- **The setter functions use early return - the FIRST matching pattern wins** -- More specific patterns MUST appear before more generic patterns -- Common examples to learn from: - - `-rosa` before `-aws` (ROSA jobs contain "aws") - - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") - - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") - - `-perfscale` before `-qe` (perfscale jobs may contain "qe") -- Always verify the diff doesn't show unintended changes to other jobs - ## Helper Commands ### Extracting Variant Categories @@ -107,4 +102,14 @@ go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "S ### Finding Setter Functions ```bash grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort -``` \ No newline at end of file +``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs \ No newline at end of file diff --git a/.gemini/commands/sippy-generate-release-views.toml b/.gemini/commands/sippy-generate-release-views.toml index d381e0f5c..a94fbe27c 100644 --- a/.gemini/commands/sippy-generate-release-views.toml +++ b/.gemini/commands/sippy-generate-release-views.toml @@ -1,2 +1,2 @@ description = "Generate new component readiness views for a new release" -prompt = "# Generate Release Views\n\nThis command generates new component readiness views for a new release by copying and updating existing views from a previous release.\n\n## Arguments (all optional)\n\n- `[source-release]`: Source release version to copy views from (e.g., `4.21`)\n- `[target-release]`: Target release version to create views for (e.g., `4.22`)\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for Source Release**: Ask the user for the source release version (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Prompt for Target Release**: Ask the user for the target release version (e.g., `4.22`)\n - Format must be X.Y (e.g., 4.22, 4.23)\n\n3. **Preview Changes**: Run the script in preview mode:\n - Execute: `python3 scripts/generate_release_views.py `\n - Ask for confirmation before proceeding\n\n4. **Apply Changes**: If confirmed, run with --apply flag:\n - Execute: `python3 scripts/generate_release_views.py --apply`\n - The script will:\n - Read `config/views.yaml`\n - Find all views where `sample_release.release` equals the source release\n - Create new views with updated releases and add them to the TOP of the views list\n - **Name**: Replace source release with target release\n - **Sample Release**: Update to target release\n - **Base Release**:\n - If base = sample (same-release comparison), both become target\n - If base != sample (cross-release comparison), increment base by one minor version\n - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end\n\n5. **Verify Output**: Show a diff of the changes made to views.yaml\n\n6. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n - If the test fails, the views.yaml has errors that must be fixed before committing\n\n7. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## View Update Logic\n\nWhen copying a view from source release to target release:\n\n1. **Name Update**: Replace all occurrences of source release in the name\n2. **Sample Release Update**: Always set to target release\n3. **Base Release Update**: Depends on the original relationship\n - **Same-release views** (base = sample): Both become target\n - **Cross-release views** (base != sample): Base increments by one\n - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates\n\n## Examples\n\n### Creating 4.22 views from 4.21\n\n- `4.21-main` (base: 4.20, sample: 4.21) -> `4.22-main` (base: 4.21, sample: 4.22)\n - `relative_start: \"ga-30d\"` -> `relative_start: \"now-30d\"` (because base now references 4.21)\n- `4.21-x86-vs-multi-arm` (base: 4.21, sample: 4.21) -> `4.22-x86-vs-multi-arm` (base: 4.22, sample: 4.22)\n\n## Important Notes\n\n- The script preserves all other view settings (variant_options, advanced_options, etc.)\n- Release versions must be in format X.Y (e.g., 4.21)\n- YAML formatting should be preserved using proper YAML libraries\n- Always verify the diff before committing" +prompt = "# Generate Release Views\n\n> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end`\n\nThis command generates new component readiness views for a new release by copying and updating existing views from a previous release.\n\n## Arguments (all optional)\n\n- `[source-release]`: Source release version to copy views from (e.g., `4.21`)\n- `[target-release]`: Target release version to create views for (e.g., `4.22`)\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for Source Release**: Ask the user for the source release version (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Prompt for Target Release**: Ask the user for the target release version (e.g., `4.22`)\n - Format must be X.Y (e.g., 4.22, 4.23)\n\n3. **Preview Changes**: Run the script in preview mode:\n - Execute: `python3 scripts/generate_release_views.py `\n - Ask for confirmation before proceeding\n\n4. **Apply Changes**: If confirmed, run with --apply flag:\n - Execute: `python3 scripts/generate_release_views.py --apply`\n - The script will:\n - Read `config/views.yaml`\n - Find all views where `sample_release.release` equals the source release\n - Create new views with updated releases and add them to the TOP of the views list\n - **Name**: Replace source release with target release\n - **Sample Release**: Update to target release\n - **Base Release**:\n - If base = sample (same-release comparison), both become target\n - If base != sample (cross-release comparison), increment base by one minor version\n - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end`\n\n5. **Verify Output**: Show a diff of the changes made to views.yaml\n\n6. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n - If the test fails, the views.yaml has errors that must be fixed before committing\n\n7. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## View Update Logic\n\nWhen copying a view from source release to target release:\n\n1. **Name Update**: Replace all occurrences of source release in the name\n2. **Sample Release Update**: Always set to target release\n3. **Base Release Update**: Depends on the original relationship\n - **Same-release views** (base = sample): Both become target\n - **Cross-release views** (base != sample): Base increments by one\n - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end`\n\n## Examples\n\n### Creating 4.22 views from 4.21\n\n- `4.21-main` (base: 4.20, sample: 4.21) -> `4.22-main` (base: 4.21, sample: 4.22)\n - `relative_start: \"ga-30d\"` -> `relative_start: \"now-30d\"` (because base now references 4.21)\n- `4.21-x86-vs-multi-arm` (base: 4.21, sample: 4.21) -> `4.22-x86-vs-multi-arm` (base: 4.22, sample: 4.22)\n\n## Important Notes\n\n- The script preserves all other view settings (variant_options, advanced_options, etc.)\n- Release versions must be in format X.Y (e.g., 4.21)\n- YAML formatting should be preserved using proper YAML libraries\n- Always verify the diff before committing" diff --git a/.gemini/commands/sippy-update-ga-release-views.toml b/.gemini/commands/sippy-update-ga-release-views.toml index c3ce8645b..5d69b95bc 100644 --- a/.gemini/commands/sippy-update-ga-release-views.toml +++ b/.gemini/commands/sippy-update-ga-release-views.toml @@ -1,2 +1,2 @@ description = "Update component readiness views when a release goes GA" -prompt = "# Update GA Release Views\n\nThis command updates component readiness views when a release goes GA by converting 'now' references to 'ga' in base_release relative dates and reducing sensitivity parameters.\n\n## Arguments (optional)\n\n- `[release]`: Release version that just went GA (e.g., `4.21`)\n\nIf the argument is not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for GA Release**: Ask the user which release just went GA (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Find Affected Views**: Search config/views.yaml to identify affected views:\n - Views where `base_release.release` equals the GA release (for date updates)\n - Views where `sample_release.release` equals the GA release (for sensitivity reductions)\n - Show the user the affected views and ask for confirmation\n\n3. **Apply Updates**: For each affected view:\n\n **A. Update base_release dates** (views comparing newer releases to the GA release):\n - Replace 'now' with 'ga' in `relative_start` (e.g., `now-30d` -> `ga-30d`)\n - Replace 'now' with 'ga' in `relative_end` (e.g., `now` -> `ga`)\n\n **B. Disable automate_jira** (views of the GA release itself):\n - Change `automate_jira.enabled` from `true` to `false`\n\n **C. Disable multi-release analysis**:\n - Change `include_multi_release_analysis` from `true` to `false`\n\n **D. Increase pity_factor**:\n - Set `pity_factor` to `10` (from 5)\n\n **E. Increase minimum_failure**:\n - Set `minimum_failure` to `4` (from 3)\n\n **F. Decrease pass_rate_required_new_tests**:\n - Set `pass_rate_required_new_tests` to `90` (from 95)\n\n - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation)\n\n4. **Verify Output**: Show a diff of the changes made to views.yaml\n\n5. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n\n6. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## Use Case\n\nThis command is part of the release lifecycle workflow:\n\n1. **Before GA**: New release (e.g., 4.22) is created with views comparing to previous release (4.21)\n - Views use `base_release: {release: \"4.21\", relative_start: \"now-30d\", relative_end: \"now\"}`\n2. **When 4.21 goes GA**: Run this command\n - Changes to `base_release: {release: \"4.21\", relative_start: \"ga-30d\", relative_end: \"ga\"}`\n - Reduces sensitivity for the GA release's own views\n\n## Important Notes\n\n- This command affects two sets of views:\n - Views where `base_release.release` equals the GA release (date updates)\n - Views where `sample_release.release` equals the GA release (sensitivity reductions)\n- Use the Edit tool for each change to preserve exact YAML formatting\n- Always verify the diff to ensure only expected changes were made\n- This is typically run once when a release goes GA" +prompt = "# Update GA Release Views\n\nThis command updates component readiness views when a release goes GA by converting 'now' references to 'ga' in base_release relative dates and reducing sensitivity parameters.\n\n## Arguments (optional)\n\n- `[release]`: Release version that just went GA (e.g., `4.21`)\n\nIf the argument is not provided, you will prompt the user interactively.\n\n## Workflow\n\n1. **Prompt for GA Release**: Ask the user which release just went GA (e.g., `4.21`)\n - Format must be X.Y (e.g., 4.21, 4.20)\n\n2. **Find Affected Views**: Search config/views.yaml to identify affected views:\n - Views where `base_release.release` equals the GA release (for date updates)\n - Views where `sample_release.release` equals the GA release (for sensitivity reductions)\n - Show the user the affected views and ask for confirmation\n\n3. **Apply Updates**: For each affected view:\n\n **A. Update base_release dates** (views comparing newer releases to the GA release):\n - Replace 'now' with 'ga' in `relative_start` (e.g., `now-30d` -> `ga-30d`)\n - Replace 'now' with 'ga' in `relative_end` (e.g., `now` -> `ga`)\n\n **B. Disable automate_jira** (views of the GA release itself):\n - Change `automate_jira.enabled` from `true` to `false`\n\n **C. Disable multi-release analysis**:\n - Change `include_multi_release_analysis` from `true` to `false`\n\n **D. Increase pity_factor**:\n - Set `pity_factor` to `10` (from 5)\n\n **E. Increase minimum_failure**:\n - Set `minimum_failure` to `4` (from 3)\n\n **F. Decrease pass_rate_required_new_tests**:\n - Set `pass_rate_required_new_tests` to `90` (from 95)\n\n4. **Verify Output**: Show a diff of the changes made to views.yaml\n\n5. **Run Validation Test**:\n - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/`\n\n6. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master).\n\n## Use Case\n\nThis command is part of the release lifecycle workflow:\n\n1. **Before GA**: New release (e.g., 4.22) is created with views comparing to previous release (4.21)\n - Views use `base_release: {release: \"4.21\", relative_start: \"now-30d\", relative_end: \"now\"}`\n2. **When 4.21 goes GA**: Run this command\n - Changes to `base_release: {release: \"4.21\", relative_start: \"ga-30d\", relative_end: \"ga\"}`\n - Reduces sensitivity for the GA release's own views\n\n## Important Notes\n\n- This command affects two sets of views:\n - Views where `base_release.release` equals the GA release (date updates)\n - Views where `sample_release.release` equals the GA release (sensitivity reductions)\n- Use the Edit tool for each change to preserve exact YAML formatting\n- Always verify the diff to ensure only expected changes were made\n- This is typically run once when a release goes GA\n\n**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation)" diff --git a/.gemini/commands/sippy-update-job-variant.toml b/.gemini/commands/sippy-update-job-variant.toml index 2de3407dd..fbaf08227 100644 --- a/.gemini/commands/sippy-update-job-variant.toml +++ b/.gemini/commands/sippy-update-job-variant.toml @@ -1,2 +1,2 @@ description = "Interactively update variants for a CI job" -prompt = "# Update Job Variant\n\nThis command provides an interactive workflow to update variant assignments for CI jobs by modifying the variant registry Go code.\n\n## Arguments (all optional)\n\n- `[job-pattern]`: Pattern (substring or full job name) that identifies the CI job(s) to update (e.g., `-hypershift-`, `-metal-ipi-`, or full job name like `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`)\n- `[category]`: Variant category to update (e.g., Platform, Architecture, Topology)\n- `[value]`: New value to set for the variant category\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n**IMPORTANT: Argument Parsing**\nBefore starting the workflow, check if the user provided any arguments:\n\n1. Parse the command invocation to extract any provided arguments\n2. If all three arguments (job-pattern, category, value) are provided:\n - Validate the category exists in the snapshot file\n - Skip the corresponding prompting steps\n - Use the provided values directly\n3. If some arguments are missing, prompt only for the missing ones\n4. If no arguments are provided, follow the full interactive workflow below\n\nYou will guide the user through the following steps (skipping steps where arguments were provided):\n\n1. **Prompt for a Job Pattern**: Ask the user to enter a pattern that identifies the CI job(s) they want to update. This can be either a full job name or a substring. This will be used to add pattern matching logic to the Go code.\n - Example full job name: `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`\n - Example substrings: `-hypershift-`, `-metal-ipi-`, `-fips-`\n - **Important**: Both full job names and substrings are acceptable. Accept whatever the user provides without asking for clarification.\n - Advise the user that more specific patterns avoid unintended matches (e.g., `-metal-ipi-ovn-ipv6-` instead of just `-metal-`)\n\n2. **Select Variant Category**: Extract variant categories programmatically and present as a numbered list:\n - Run: `grep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u`\n - This extracts all unique variant categories from the snapshot file\n - Present the list with numbers (1, 2, 3, etc.) and ask the user to select by number\n\n3. **Select New Value**: Based on the chosen category, extract possible values programmatically and present as a numbered list:\n - For most categories, extract values from the snapshot: `grep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u`\n - Present the unique values as a numbered list and ask the user to select by number\n - For Release-related variants (Release, FromRelease, FromReleaseMajor, FromReleaseMinor, ReleaseMajor, ReleaseMinor), allow free-text input instead of showing a numbered list\n\n4. **Modify the Go Code**: Update `pkg/variantregistry/ocp.go` to add the pattern matching logic:\n - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.)\n - Add an entry to the pattern matching logic in that function with the pattern and new value\n - Follow the existing code style and pattern structure (see examples in the file)\n - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins.\n - More specific patterns MUST come before more generic patterns\n - Example: In `setPlatform`, \"-rosa\" must come before \"-aws\" because ROSA jobs contain \"aws\"\n - Example: In `setOwner`, \"-perfscale\" must come before \"-qe\" because perfscale jobs may contain \"qe\"\n - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point\n - Check if the new pattern might overlap with existing patterns and ensure correct precedence\n\n5. **Preview Changes with Test**: Run the variant snapshot test to see what will change:\n - Execute: `go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"`\n - Parse this output to extract the variant category changed, old/new values, affected jobs, and total count\n - Display the summary to the user\n\n6. **Apply Changes**: Execute `make update-variants` to regenerate `pkg/variantregistry/snapshot.yaml`\n\n7. **Verify Unintended Changes** (optional manual step):\n - Suggest the user review `git diff pkg/variantregistry/snapshot.yaml` to ensure only expected jobs changed\n\n8. **Offer to Commit**: Ask the user if they want to commit the changes. If yes, commit both the Go code and the regenerated snapshot.\n\n## Important Notes\n\n- The variant logic is defined in `pkg/variantregistry/ocp.go` in setter functions\n- Each variant category has its own setter function with a pattern matching list\n- The `make update-variants` command runs `./sippy variants snapshot --config ./config/openshift.yaml`\n- This regenerates `pkg/variantregistry/snapshot.yaml` based on the Go code logic\n- Always commit both the Go code changes AND the regenerated snapshot.yaml\n- Pattern matching is done with `strings.Contains(jobNameLower, pattern)`\n\n### Pattern Ordering is CRITICAL\n- **The setter functions use early return - the FIRST matching pattern wins**\n- More specific patterns MUST appear before more generic patterns\n- Common examples to learn from:\n - `-rosa` before `-aws` (ROSA jobs contain \"aws\")\n - `-azure-aro-hcp` before `-azure` (ARO jobs contain \"azure\")\n - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain \"gcp\")\n - `-perfscale` before `-qe` (perfscale jobs may contain \"qe\")\n- Always verify the diff doesn't show unintended changes to other jobs\n\n## Helper Commands\n\n### Extracting Variant Categories\n```bash\ngrep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u\n```\n\n### Extracting Values for a Specific Category\n```bash\ngrep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u\n```\n\n### Previewing Changes\n```bash\ngo test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"\n```\n\n### Finding Setter Functions\n```bash\ngrep -E \"^func set[A-Z]\" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort\n```" +prompt = "# Update Job Variant\n\nThis command provides an interactive workflow to update variant assignments for CI jobs by modifying the variant registry Go code.\n\n## Arguments (all optional)\n\n- `[job-pattern]`: Pattern (substring or full job name) that identifies the CI job(s) to update (e.g., `-hypershift-`, `-metal-ipi-`, or full job name like `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`)\n- `[category]`: Variant category to update (e.g., Platform, Architecture, Topology)\n- `[value]`: New value to set for the variant category\n\nIf any arguments are not provided, you will prompt the user interactively.\n\n## Workflow\n\n**IMPORTANT: Argument Parsing**\nBefore starting the workflow, check if the user provided any arguments:\n\n1. Parse the command invocation to extract any provided arguments\n2. If all three arguments (job-pattern, category, value) are provided:\n - Validate the category exists in the snapshot file\n - Skip the corresponding prompting steps\n - Use the provided values directly\n3. If some arguments are missing, prompt only for the missing ones\n4. If no arguments are provided, follow the full interactive workflow below\n\nYou will guide the user through the following steps (skipping steps where arguments were provided):\n\n1. **Prompt for a Job Pattern**: Ask the user to enter a pattern that identifies the CI job(s) they want to update. This can be either a full job name or a substring. This will be used to add pattern matching logic to the Go code.\n - Example full job name: `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`\n - Example substrings: `-hypershift-`, `-metal-ipi-`, `-fips-`\n - **Important**: Both full job names and substrings are acceptable. Accept whatever the user provides without asking for clarification.\n - Advise the user that more specific patterns avoid unintended matches (e.g., `-metal-ipi-ovn-ipv6-` instead of just `-metal-`)\n\n2. **Select Variant Category**: Extract variant categories programmatically and present as a numbered list:\n - Run: `grep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u`\n - This extracts all unique variant categories from the snapshot file\n - Present the list with numbers (1, 2, 3, etc.) and ask the user to select by number\n\n3. **Select New Value**: Based on the chosen category, extract possible values programmatically and present as a numbered list:\n - For most categories, extract values from the snapshot: `grep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u`\n - Present the unique values as a numbered list and ask the user to select by number\n - For Release-related variants (Release, FromRelease, FromReleaseMajor, FromReleaseMinor, ReleaseMajor, ReleaseMinor), allow free-text input instead of showing a numbered list\n\n4. **Modify the Go Code**: Update `pkg/variantregistry/ocp.go` to add the pattern matching logic:\n - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.)\n - Add an entry to the pattern matching logic in that function with the pattern and new value\n - Follow the existing code style and pattern structure (see examples in the file)\n - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins.\n - More specific patterns come before more generic patterns\n - Example: In `setPlatform`, \"-rosa\" must come before \"-aws\" because ROSA jobs contain \"aws\"\n - Example: In `setOwner`, \"-perfscale\" must come before \"-qe\" because perfscale jobs may contain \"qe\"\n - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point\n - Check if the new pattern might overlap with existing patterns and ensure correct precedence\n\n5. **Preview Changes with Test**: Run the variant snapshot test to see what will change:\n - Execute: `go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"`\n - Parse this output to extract the variant category changed, old/new values, affected jobs, and total count\n - Display the summary to the user\n\n6. **Apply Changes**: Execute `make update-variants` to regenerate `pkg/variantregistry/snapshot.yaml`\n\n7. **Verify Unintended Changes** (optional manual step):\n - Suggest the user review `git diff pkg/variantregistry/snapshot.yaml` to ensure only expected jobs changed\n\n8. **Offer to Commit**: Ask the user if they want to commit the changes. If yes, commit both the Go code and the regenerated snapshot.\n\n## Important Notes\n\n- The variant logic is defined in `pkg/variantregistry/ocp.go` in setter functions\n- Each variant category has its own setter function with a pattern matching list\n- The `make update-variants` command runs `./sippy variants snapshot --config ./config/openshift.yaml`\n- This regenerates `pkg/variantregistry/snapshot.yaml` based on the Go code logic\n- Always commit both the Go code changes AND the regenerated snapshot.yaml\n- Pattern matching is done with `strings.Contains(jobNameLower, pattern)`\n\n## Helper Commands\n\n### Extracting Variant Categories\n```bash\ngrep -E \"^ [A-Z]\" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u\n```\n\n### Extracting Values for a Specific Category\n```bash\ngrep \"^ :\" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/\"//g' | sort -u\n```\n\n### Previewing Changes\n```bash\ngo test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 \"Summary of changes:\"\n```\n\n### Finding Setter Functions\n```bash\ngrep -E \"^func set[A-Z]\" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort\n```\n\n### Pattern Ordering is CRITICAL\n- **The setter functions use early return - the FIRST matching pattern wins**\n- More specific patterns MUST appear before more generic patterns\n- Common examples to learn from:\n - `-rosa` before `-aws` (ROSA jobs contain \"aws\")\n - `-azure-aro-hcp` before `-azure` (ARO jobs contain \"azure\")\n - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain \"gcp\")\n - `-perfscale` before `-qe` (perfscale jobs may contain \"qe\")\n- Always verify the diff doesn't show unintended changes to other jobs" diff --git a/.opencode/commands/sippy-generate-release-views.md b/.opencode/commands/sippy-generate-release-views.md index 88e270fbb..4737cda7d 100644 --- a/.opencode/commands/sippy-generate-release-views.md +++ b/.opencode/commands/sippy-generate-release-views.md @@ -1,9 +1,15 @@ --- +argument-hint: +arguments: +- source-release +- target-release description: Generate new component readiness views for a new release --- # Generate Release Views +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + This command generates new component readiness views for a new release by copying and updating existing views from a previous release. ## Arguments (all optional) @@ -36,7 +42,7 @@ If any arguments are not provided, you will prompt the user interactively. - **Base Release**: - If base = sample (same-release comparison), both become target - If base != sample (cross-release comparison), increment base by one minor version - - **IMPORTANT**: When base becomes source release, replace 'ga' with 'now' in relative_start and relative_end + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` 5. **Verify Output**: Show a diff of the changes made to views.yaml @@ -55,7 +61,7 @@ When copying a view from source release to target release: 3. **Base Release Update**: Depends on the original relationship - **Same-release views** (base = sample): Both become target - **Cross-release views** (base != sample): Base increments by one - - **CRITICAL**: When base becomes source release, replace 'ga' with 'now' in relative dates + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` ## Examples diff --git a/.opencode/commands/sippy-update-ga-release-views.md b/.opencode/commands/sippy-update-ga-release-views.md index 0a737a518..15b5aa6c4 100644 --- a/.opencode/commands/sippy-update-ga-release-views.md +++ b/.opencode/commands/sippy-update-ga-release-views.md @@ -1,4 +1,7 @@ --- +argument-hint: +arguments: +- release description: Update component readiness views when a release goes GA --- @@ -43,8 +46,6 @@ If the argument is not provided, you will prompt the user interactively. **F. Decrease pass_rate_required_new_tests**: - Set `pass_rate_required_new_tests` to `90` (from 95) - - **IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) - 4. **Verify Output**: Show a diff of the changes made to views.yaml 5. **Run Validation Test**: @@ -69,4 +70,6 @@ This command is part of the release lifecycle workflow: - Views where `sample_release.release` equals the GA release (sensitivity reductions) - Use the Edit tool for each change to preserve exact YAML formatting - Always verify the diff to ensure only expected changes were made -- This is typically run once when a release goes GA \ No newline at end of file +- This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) \ No newline at end of file diff --git a/.opencode/commands/sippy-update-job-variant.md b/.opencode/commands/sippy-update-job-variant.md index f5e0ab057..0c5dad130 100644 --- a/.opencode/commands/sippy-update-job-variant.md +++ b/.opencode/commands/sippy-update-job-variant.md @@ -1,4 +1,9 @@ --- +argument-hint: +arguments: +- job-pattern +- category +- value description: Interactively update variants for a CI job --- @@ -49,8 +54,8 @@ You will guide the user through the following steps (skipping steps where argume - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) - Add an entry to the pattern matching logic in that function with the pattern and new value - Follow the existing code style and pattern structure (see examples in the file) - - **CRITICAL**: Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. - - More specific patterns MUST come before more generic patterns + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point @@ -77,16 +82,6 @@ You will guide the user through the following steps (skipping steps where argume - Always commit both the Go code changes AND the regenerated snapshot.yaml - Pattern matching is done with `strings.Contains(jobNameLower, pattern)` -### Pattern Ordering is CRITICAL -- **The setter functions use early return - the FIRST matching pattern wins** -- More specific patterns MUST appear before more generic patterns -- Common examples to learn from: - - `-rosa` before `-aws` (ROSA jobs contain "aws") - - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") - - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") - - `-perfscale` before `-qe` (perfscale jobs may contain "qe") -- Always verify the diff doesn't show unintended changes to other jobs - ## Helper Commands ### Extracting Variant Categories @@ -107,4 +102,14 @@ go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "S ### Finding Setter Functions ```bash grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort -``` \ No newline at end of file +``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index ae7664418..cab6d021f 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `**` diff --git a/CLAUDE.md b/CLAUDE.md index afe148eea..58c4341d6 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards diff --git a/GEMINI.md b/GEMINI.md index 123ba5eb3..f933b9480 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -1,6 +1,6 @@ # GEMINI.md - - + + @./AGENTS.md diff --git a/Makefile b/Makefile index 0cb140d4a..ac4456878 100644 --- a/Makefile +++ b/Makefile @@ -62,8 +62,8 @@ clean: rm -rf sippy-ng/node_modules apm: - uvx --from apm-cli@0.11.0 apm install - uvx --from apm-cli@0.11.0 apm compile + uvx --from apm-cli@0.12.4 apm install + uvx --from apm-cli@0.12.4 apm compile verify-apm: apm @if ! git diff --quiet HEAD -- .claude .cursor .gemini .opencode AGENTS.md CLAUDE.md GEMINI.md sippy-ng/AGENTS.md sippy-ng/CLAUDE.md mcp/AGENTS.md mcp/CLAUDE.md; then \ diff --git a/apm.lock.yaml b/apm.lock.yaml index 21694e4fc..39999d874 100644 --- a/apm.lock.yaml +++ b/apm.lock.yaml @@ -7,7 +7,6 @@ local_deployed_files: - .claude/commands/sippy-dev-frontend.md - .claude/commands/sippy-dev-migrate.md - .claude/commands/sippy-dev-regression-cache.md -- .claude/commands/sippy-dev-restore-prodlike.md - .claude/commands/sippy-dev-serve.md - .claude/commands/sippy-dev-setup.md - .claude/commands/sippy-dev-tests.md @@ -16,14 +15,22 @@ local_deployed_files: - .claude/commands/sippy-update-job-variant.md - .claude/rules/backend.md - .claude/rules/dev-commands.md -- .claude/rules/docs.md - .claude/rules/frontend.md - .claude/rules/general.md - .claude/rules/mcp.md - .claude/rules/testing.md +- .cursor/commands/sippy-dev-app.md +- .cursor/commands/sippy-dev-frontend.md +- .cursor/commands/sippy-dev-migrate.md +- .cursor/commands/sippy-dev-regression-cache.md +- .cursor/commands/sippy-dev-serve.md +- .cursor/commands/sippy-dev-setup.md +- .cursor/commands/sippy-dev-tests.md +- .cursor/commands/sippy-generate-release-views.md +- .cursor/commands/sippy-update-ga-release-views.md +- .cursor/commands/sippy-update-job-variant.md - .cursor/rules/backend.mdc - .cursor/rules/dev-commands.mdc -- .cursor/rules/docs.mdc - .cursor/rules/frontend.mdc - .cursor/rules/general.mdc - .cursor/rules/mcp.mdc @@ -32,7 +39,6 @@ local_deployed_files: - .gemini/commands/sippy-dev-frontend.toml - .gemini/commands/sippy-dev-migrate.toml - .gemini/commands/sippy-dev-regression-cache.toml -- .gemini/commands/sippy-dev-restore-prodlike.toml - .gemini/commands/sippy-dev-serve.toml - .gemini/commands/sippy-dev-setup.toml - .gemini/commands/sippy-dev-tests.toml @@ -43,7 +49,6 @@ local_deployed_files: - .opencode/commands/sippy-dev-frontend.md - .opencode/commands/sippy-dev-migrate.md - .opencode/commands/sippy-dev-regression-cache.md -- .opencode/commands/sippy-dev-restore-prodlike.md - .opencode/commands/sippy-dev-serve.md - .opencode/commands/sippy-dev-setup.md - .opencode/commands/sippy-dev-tests.md @@ -51,50 +56,55 @@ local_deployed_files: - .opencode/commands/sippy-update-ga-release-views.md - .opencode/commands/sippy-update-job-variant.md local_deployed_file_hashes: - .claude/commands/sippy-dev-app.md: sha256:656276ed961940c137dde32ecdb0501427d4d811502a27125ba073adc770d266 + .claude/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 .claude/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a - .claude/commands/sippy-dev-migrate.md: sha256:80160e88e0cc0fc09ab3dd9cc6fc496fe87dd8873800eb65d700868034d59da2 - .claude/commands/sippy-dev-regression-cache.md: sha256:683448f4a553c4511c909fc2711b13edb7ee27d0c437aa9e7689bc9ba6fc0b6a - .claude/commands/sippy-dev-restore-prodlike.md: sha256:868d480aa0f338acdd766332dd37b5ba07cbbb4b79bb2a078c9d8f0eb7c714a4 - .claude/commands/sippy-dev-serve.md: sha256:24d61d9b5d3d6b2fdcfbf8fb8e97da3b633293adb31e6df061d61170de826f35 - .claude/commands/sippy-dev-setup.md: sha256:68a019dbf60081e3b4e0c751413f96406c29c13912bb55c3492b48c913f7f74f - .claude/commands/sippy-dev-tests.md: sha256:d76061fc3ee9478207d120436c016b3651c19c4f3f5fcb61a630462a9d9e5622 - .claude/commands/sippy-generate-release-views.md: sha256:e8a283e43f84777e6da34c10f1b18de2c41baa4525a7e40317bddd0c61b75553 - .claude/commands/sippy-update-ga-release-views.md: sha256:c7adb0f649455fa7c12c94454220fc87f182d49b820a2683ca733401cbfeb9b0 - .claude/commands/sippy-update-job-variant.md: sha256:ef00ec3a3b01556b33243d3e17ab1ace23879a8ef10dfd2e501a0fda2291fb97 + .claude/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b + .claude/commands/sippy-dev-regression-cache.md: sha256:4e9fc3ed63927c84c30554929768a3b0e760264925f55c9dbbdafabf2361bee2 + .claude/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 + .claude/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f + .claude/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 + .claude/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a + .claude/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 + .claude/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 .claude/rules/backend.md: sha256:c57f9ef479340d977f06266779cacc8cd0a67cf045a58d30757a0c494354081a - .claude/rules/dev-commands.md: sha256:eb32bdc640add2044138807572ea1afb73ee1bba038f5098032a89987a7ddc04 - .claude/rules/docs.md: sha256:7c4967f4c8a479f54a158b1e3ea3061b72cb78d920f46f0be820f9bd09a00689 + .claude/rules/dev-commands.md: sha256:4508eaad3d835305b68106ed5b270ced97c93e4a42ee94d1bcac5ea7b056bc5d .claude/rules/frontend.md: sha256:ff22046c5b951769218bbdf36499e67c70896811b8ef161ca6d3729a3423997d - .claude/rules/general.md: sha256:997f68e86cb43485ec5f108be3417f9bbb43ae1faffd660d598f18260f5df3ce - .claude/rules/mcp.md: sha256:ddfe965e7cf8cddbba1374c6ae582a20ac0af17c958bf10e1a4edff6ff2ad0b8 + .claude/rules/general.md: sha256:9238d053e2d6a1703728c2bb165de93658b47c3152dfac16169ff9db9c6f716c + .claude/rules/mcp.md: sha256:73735078b3b1a8597b91b49821ba05cdb338144ea00c1eea9e9f4de38d0241a3 .claude/rules/testing.md: sha256:57834092f6732d17f8c1812d25290cfc1cfbbbeb6eae1561ba2240973c651866 + .cursor/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 + .cursor/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a + .cursor/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b + .cursor/commands/sippy-dev-regression-cache.md: sha256:4e9fc3ed63927c84c30554929768a3b0e760264925f55c9dbbdafabf2361bee2 + .cursor/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 + .cursor/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f + .cursor/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 + .cursor/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a + .cursor/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 + .cursor/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 .cursor/rules/backend.mdc: sha256:fb466b896d76ea1730c23d6c3fc783adf2cd5502c1cbb36e5b3d30c01531e4c1 - .cursor/rules/dev-commands.mdc: sha256:3dc8a3ef5cbb22ebb09b7fe3785f24a32ab2baa4488c5514c9c6210b0af6c4eb - .cursor/rules/docs.mdc: sha256:a9cbd6965f8f4eb4ee2c97473b1cfaf739e4c5967d90a67f2772a3cee84e1512 + .cursor/rules/dev-commands.mdc: sha256:c69ca93db9b6c68f9aeb6567289dc5baef805520e8636a1e3e848793f67450e6 .cursor/rules/frontend.mdc: sha256:497f39372724f1ae127181fe3dac9ea9a95a51c532b68ccfee6080832cf9c556 - .cursor/rules/general.mdc: sha256:5bc6e1e12d53d85656248c9dc1239c74bcc0df29d5987f3b08e3d79e3df413b7 - .cursor/rules/mcp.mdc: sha256:c02472afd46e4c89f71d4487dcd5da98b0c1bcbcf7f9cbc4d7ed4e7d3a206ec1 + .cursor/rules/general.mdc: sha256:671e94d8251783ecfb70d16e6e8d60dc42752ecfbe90919006b908b8a751595d + .cursor/rules/mcp.mdc: sha256:268557cc3bdd9c8f7401f9ea80ac342ff2688f1d563b10880177ca586d7d30bb .cursor/rules/testing.mdc: sha256:e5ce80313a812750404d45355b462c2e3a6458f5bc20ad7996a5da1b169a4703 - .gemini/commands/sippy-dev-app.toml: sha256:fc28174eeab4e440694a823bd838d429241997a018d8a13f32e0f67ca4d973c5 + .gemini/commands/sippy-dev-app.toml: sha256:afc6fe75647832aa571c63d8229d151820c54535cdb695b96f8400c1d7b3bd16 .gemini/commands/sippy-dev-frontend.toml: sha256:ec4ab5e1fb7581f09473e33b3ed4f53ce40509f23aac581e3b100ad1f59de5e5 - .gemini/commands/sippy-dev-migrate.toml: sha256:25c98ba4bfdb95270dfcb4238ae688f9a66f0e645d8a4a6c5e03b1cf8db5cb7e - .gemini/commands/sippy-dev-regression-cache.toml: sha256:e00021f336c5d35c8d23d87c230530145734ab68ac183fb2a462dd375bcde2ff - .gemini/commands/sippy-dev-restore-prodlike.toml: sha256:9cff208d06fe3dbaa153b9b18424e5c79bcf4fffe45b51b6216f13fd17087da9 - .gemini/commands/sippy-dev-serve.toml: sha256:3584c3e96e633685e906198095457fada19e95b4e611ed12e1c6f846ca4ce5d4 - .gemini/commands/sippy-dev-setup.toml: sha256:b76f21c8dc144e8ddab8d47e58ee80cfb8bf53116e16b53ecf0c6d1ab3974387 - .gemini/commands/sippy-dev-tests.toml: sha256:be46cf9c4ce1857a82c1f911c838b05c430a0be5c2d21128b88d5c1bb3a4832c - .gemini/commands/sippy-generate-release-views.toml: sha256:4759f4547c05631d2e83a5859172421ea3d6ec794dd887756a90bbe0fd2732c1 - .gemini/commands/sippy-update-ga-release-views.toml: sha256:71a60dfe068bdc59645b8d0069c93c65f2df30c5172da3389df2a80d86410ae9 - .gemini/commands/sippy-update-job-variant.toml: sha256:71c9c7548a1a4b829e970d76504ef981ea05fecf8052cdb86859d96ad52cb2b2 - .opencode/commands/sippy-dev-app.md: sha256:656276ed961940c137dde32ecdb0501427d4d811502a27125ba073adc770d266 + .gemini/commands/sippy-dev-migrate.toml: sha256:e699558eb27c294327a092bfcd3e76b576087ad29d9a3a9b000cfd9e7c6b4774 + .gemini/commands/sippy-dev-regression-cache.toml: sha256:cd2c9017e5e976750839c712b42d10046d1d04fabaa749ffda6fd1abaf776d7a + .gemini/commands/sippy-dev-serve.toml: sha256:adff646a493861ca4bb5246fb32b6eb69dc77829d05b74b8e7c241cb08dff808 + .gemini/commands/sippy-dev-setup.toml: sha256:bb56074029f5a73075f7d8b5e971ad2621d0517ea29a90bbb1e11f989bd6295c + .gemini/commands/sippy-dev-tests.toml: sha256:0b5f406eac7adca8ee4db287973368b9dea048f89f0fdf86e3fc9730646c8d47 + .gemini/commands/sippy-generate-release-views.toml: sha256:9173d7507f469eda21a19f7e5ec47bce0c6ce87a73c1f5c10594a89417332927 + .gemini/commands/sippy-update-ga-release-views.toml: sha256:662ac8d503d883cf6142c801b79e46616afb3d806e1d936e952d918b257ddf73 + .gemini/commands/sippy-update-job-variant.toml: sha256:3b044dfaddeafa1a6d375918d5860785f8d315b593c355bbb7293a87c50361b8 + .opencode/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 .opencode/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a - .opencode/commands/sippy-dev-migrate.md: sha256:80160e88e0cc0fc09ab3dd9cc6fc496fe87dd8873800eb65d700868034d59da2 - .opencode/commands/sippy-dev-regression-cache.md: sha256:683448f4a553c4511c909fc2711b13edb7ee27d0c437aa9e7689bc9ba6fc0b6a - .opencode/commands/sippy-dev-restore-prodlike.md: sha256:868d480aa0f338acdd766332dd37b5ba07cbbb4b79bb2a078c9d8f0eb7c714a4 - .opencode/commands/sippy-dev-serve.md: sha256:24d61d9b5d3d6b2fdcfbf8fb8e97da3b633293adb31e6df061d61170de826f35 - .opencode/commands/sippy-dev-setup.md: sha256:68a019dbf60081e3b4e0c751413f96406c29c13912bb55c3492b48c913f7f74f - .opencode/commands/sippy-dev-tests.md: sha256:d76061fc3ee9478207d120436c016b3651c19c4f3f5fcb61a630462a9d9e5622 - .opencode/commands/sippy-generate-release-views.md: sha256:e8a283e43f84777e6da34c10f1b18de2c41baa4525a7e40317bddd0c61b75553 - .opencode/commands/sippy-update-ga-release-views.md: sha256:c7adb0f649455fa7c12c94454220fc87f182d49b820a2683ca733401cbfeb9b0 - .opencode/commands/sippy-update-job-variant.md: sha256:ef00ec3a3b01556b33243d3e17ab1ace23879a8ef10dfd2e501a0fda2291fb97 + .opencode/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b + .opencode/commands/sippy-dev-regression-cache.md: sha256:4e9fc3ed63927c84c30554929768a3b0e760264925f55c9dbbdafabf2361bee2 + .opencode/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 + .opencode/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f + .opencode/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 + .opencode/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a + .opencode/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 + .opencode/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 diff --git a/apm.yml b/apm.yml index 66d9d274f..0fefeac4d 100644 --- a/apm.yml +++ b/apm.yml @@ -1,9 +1,15 @@ name: sippy version: 1.0.0 description: CI analysis and release health monitoring for OpenShift -target: [claude, cursor, gemini, opencode] +targets: + - claude + - cursor + - gemini + - opencode -dependencies: {} +dependencies: # External dependencies can be pulled from GitHub, e.g.: # apm: # - openshift-eng/ai-helpers/plugins/bigquery + apm: [] + mcp: [] diff --git a/mcp/AGENTS.md b/mcp/AGENTS.md index ced7fd74e..a31e275ca 100644 --- a/mcp/AGENTS.md +++ b/mcp/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `mcp/**` diff --git a/mcp/CLAUDE.md b/mcp/CLAUDE.md index 949c96f45..9d4eb3754 100644 --- a/mcp/CLAUDE.md +++ b/mcp/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards diff --git a/sippy-ng/AGENTS.md b/sippy-ng/AGENTS.md index 8cc348b84..e715c721a 100644 --- a/sippy-ng/AGENTS.md +++ b/sippy-ng/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `sippy-ng/**` diff --git a/sippy-ng/CLAUDE.md b/sippy-ng/CLAUDE.md index 97779f3d4..3f9a23ec1 100644 --- a/sippy-ng/CLAUDE.md +++ b/sippy-ng/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards From d92d9ad4be9213ef4819727af88be16fab727575 Mon Sep 17 00:00:00 2001 From: Stephen Benjamin Date: Sat, 9 May 2026 17:51:42 -0400 Subject: [PATCH 3/4] Add cursor commands generated by APM compile These were generated but never committed. Co-Authored-By: Claude Opus 4.6 --- .cursor/commands/sippy-dev-app.md | 12 ++ .cursor/commands/sippy-dev-frontend.md | 13 ++ .cursor/commands/sippy-dev-migrate.md | 20 +++ .../commands/sippy-dev-regression-cache.md | 13 ++ .../commands/sippy-dev-restore-prodlike.md | 34 ++++++ .cursor/commands/sippy-dev-serve.md | 15 +++ .cursor/commands/sippy-dev-setup.md | 114 +++++++++++++++++ .cursor/commands/sippy-dev-tests.md | 27 ++++ .../commands/sippy-generate-release-views.md | 79 ++++++++++++ .../commands/sippy-update-ga-release-views.md | 75 ++++++++++++ .cursor/commands/sippy-update-job-variant.md | 115 ++++++++++++++++++ AGENTS.md | 2 +- CLAUDE.md | 2 +- apm.lock.yaml | 62 +++++----- mcp/AGENTS.md | 2 +- mcp/CLAUDE.md | 2 +- 16 files changed, 553 insertions(+), 34 deletions(-) create mode 100644 .cursor/commands/sippy-dev-app.md create mode 100644 .cursor/commands/sippy-dev-frontend.md create mode 100644 .cursor/commands/sippy-dev-migrate.md create mode 100644 .cursor/commands/sippy-dev-regression-cache.md create mode 100644 .cursor/commands/sippy-dev-restore-prodlike.md create mode 100644 .cursor/commands/sippy-dev-serve.md create mode 100644 .cursor/commands/sippy-dev-setup.md create mode 100644 .cursor/commands/sippy-dev-tests.md create mode 100644 .cursor/commands/sippy-generate-release-views.md create mode 100644 .cursor/commands/sippy-update-ga-release-views.md create mode 100644 .cursor/commands/sippy-update-job-variant.md diff --git a/.cursor/commands/sippy-dev-app.md b/.cursor/commands/sippy-dev-app.md new file mode 100644 index 000000000..22e9d874a --- /dev/null +++ b/.cursor/commands/sippy-dev-app.md @@ -0,0 +1,12 @@ +--- +description: Start both Sippy backend and frontend dev servers +--- + +# Sippy dev — backend + frontend + +Start the full local Sippy stack using two MCP tool calls (server: **`sippy-dev`**). Run them in order — backend first, then frontend. + +1. **`sippy_serve`** — defaults are derived from `SIPPY_DATA_MODE` (`seed` or `prod-like`). In `prod-like` mode, pass **`bigquery_credentials_file`** when `SIPPY_BIGQUERY_CREDENTIALS_FILE` / `GOOGLE_APPLICATION_CREDENTIALS` are not set. +2. **`sippy_ng_start`** + +Each tool returns listen hints (typically **8080** / **3000**) and log paths. If a tool reports already running, ask the user if they want to restart it. If yes, call the tool again with **`restart=True`**. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-frontend.md b/.cursor/commands/sippy-dev-frontend.md new file mode 100644 index 000000000..53b16d603 --- /dev/null +++ b/.cursor/commands/sippy-dev-frontend.md @@ -0,0 +1,13 @@ +--- +description: Start the sippy-ng React dev server via the sippy-dev MCP tool +--- + +# Sippy dev — frontend (sippy-ng) + +Use the **`sippy_ng_start`** MCP tool (server: **`sippy-dev`**). Do not run `npm start` in `sippy-ng` manually — the MCP tool handles background process management, log routing, and duplicate detection. + +**`open_browser`** defaults to **`false`**. Typical URL: **`http://127.0.0.1:3000`**. Log: **`sippy-dev-logs/sippy_ng_start.log`**. + +If the dev server is already running, the tool will report it. Ask the user if they want to restart, and if so call again with **`restart=True`**. + +See **`mcp/server.py`** for all parameters. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-migrate.md b/.cursor/commands/sippy-dev-migrate.md new file mode 100644 index 000000000..5958e5025 --- /dev/null +++ b/.cursor/commands/sippy-dev-migrate.md @@ -0,0 +1,20 @@ +--- +description: Run Sippy PostgreSQL schema migration +--- + +# Sippy dev — migrate + +The devcontainer has two databases: **seed** (`postgres`) and **prod-like** (`prodlike`). To migrate both: + +```bash +go run ./cmd/sippy migrate --database-dsn "$SIPPY_SEED_DATABASE_DSN" +go run ./cmd/sippy migrate --database-dsn "$SIPPY_PRODLIKE_DATABASE_DSN" +``` + +Or to migrate just the active database (based on `SIPPY_DATA_MODE`): + +```bash +go run ./cmd/sippy migrate --database-dsn "$SIPPY_DATABASE_DSN" +``` + +If no env vars are set, the dev default is: `postgresql://postgres:password@localhost:5432/postgres` \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-regression-cache.md b/.cursor/commands/sippy-dev-regression-cache.md new file mode 100644 index 000000000..9602e1a3e --- /dev/null +++ b/.cursor/commands/sippy-dev-regression-cache.md @@ -0,0 +1,13 @@ +--- +description: Run the Sippy regression-cache loader (BigQuery + Redis + DB) +--- + +# Sippy dev — regression-cache + +Use the **`regression_cache`** MCP tool (server: **`sippy-dev`**). Do not run `go run ./cmd/sippy load --loader regression-cache` manually — the MCP tool handles credentials, logging, and timeouts. + +**`bigquery_credentials_file`**: path to BigQuery-capable SA JSON (e.g. `sippy-bigquery-job-importer-key.json`); optional if `SIPPY_BIGQUERY_CREDENTIALS_FILE` or `GOOGLE_APPLICATION_CREDENTIALS` is set. + +Always targets the **prod-like database** (`prodlike`) regardless of `SIPPY_DATA_MODE`. Pass `database_dsn` explicitly to override. + +See **`mcp/server.py`** for all parameters. Log: **`sippy-dev-logs/regression_cache.log`**. Typical duration is many minutes. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-restore-prodlike.md b/.cursor/commands/sippy-dev-restore-prodlike.md new file mode 100644 index 000000000..91e921b15 --- /dev/null +++ b/.cursor/commands/sippy-dev-restore-prodlike.md @@ -0,0 +1,34 @@ +--- +description: Restore prod-like PostgreSQL from a backup file +--- + +# Sippy dev — restore prod-like DB + +Restore the **`prodlike`** database from a backup that lives **under the repo root** (path relative to checkout, no `..`). + +## Preconditions + +- **`SIPPY_PRODLIKE_DATABASE_DSN`** must end with **`/prodlike`** and use host **`localhost`** or **`sippy-postgres`** (script refuses other hosts). +- Stop **`sippy serve`** (and anything else connected to `prodlike`) so `DROP DATABASE` can run. +- **`pg_restore`** must match the dump format (devcontainer: PostgreSQL 17 client on `PATH`). + +## Steps + +1. **CLI** (from repo root): + + ```bash + scripts/restore_prodlike_db.sh + ``` + + Examples: `backups/sippy-prodlike.dump`, `sippy-backup-dev-2026-05-07.dump` if that file is in the repo. + + - Custom / directory format: **`pg_restore`** + - **`*.sql`**: **`psql -f`** + +2. **MCP** (server **`sippy-dev`**): call **`restore_prodlike_db`** with **`backup_file`** set to the same repo-relative path. Large dumps: **`timeout_seconds=0`**. Log: **`sippy-dev-logs/restore_prodlike_db.log`**. + +3. After restore, migrate if the schema might be behind: + + ```bash + go run ./cmd/sippy migrate --database-dsn "$SIPPY_PRODLIKE_DATABASE_DSN" + ``` \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-serve.md b/.cursor/commands/sippy-dev-serve.md new file mode 100644 index 000000000..ed63c8a3f --- /dev/null +++ b/.cursor/commands/sippy-dev-serve.md @@ -0,0 +1,15 @@ +--- +description: Start the Sippy HTTP API server via the sippy-dev MCP tool +--- + +# Sippy dev — serve + +Use the **`sippy_serve`** MCP tool (server: **`sippy-dev`**). Do not run `go run ./cmd/sippy serve` manually — the MCP tool handles background process management, log routing, and duplicate detection. + +Defaults are derived from **`SIPPY_DATA_MODE`** (`seed` or `prod-like`). In **seed** mode (default), the server uses `data_provider=postgres` with seed data and **does not require BigQuery credentials**. In **prod-like** mode, it uses `data_provider=bigquery` with `views_file=config/views.yaml` and the prod-like database (`prodlike`). Switch modes by setting `SIPPY_DATA_MODE=prod-like` in the environment. + +Explicit parameter values always override mode-derived defaults. + +If the server is already running, the tool will report it. Ask the user if they want to restart, and if so call again with **`restart=True`**. + +See **`mcp/server.py`** for all parameters. Typical listen address: **`:8080`**. Log: **`sippy-dev-logs/sippy_serve.log`**. \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-setup.md b/.cursor/commands/sippy-dev-setup.md new file mode 100644 index 000000000..4c16a1a6a --- /dev/null +++ b/.cursor/commands/sippy-dev-setup.md @@ -0,0 +1,114 @@ +--- +description: Set up the Sippy devcontainer (Podman, env, GCP auth) +--- + +# Sippy dev — devcontainer setup + +Interactive setup for the Sippy devcontainer. Automates what can be detected, prompts for what can't. + +## Workflow + +### 1. Detect OS + +```bash +uname -s +``` + +- **Darwin** = macOS +- **Linux** = Linux + +### 2. Check prerequisites + +Verify each tool is installed. Report any that are missing and stop. + +```bash +command -v podman +command -v devcontainer +``` + +If `devcontainer` is missing, tell the user: `npm install -g @devcontainers/cli` + +### 3. macOS: Podman machine + +If macOS, check if podman machine is running: + +```bash +podman machine info +``` + +If not initialized or not running, run: + +```bash +podman machine init # only if no machine exists +podman machine start +``` + +### 4. Linux: Podman socket + +If Linux, check if the socket is active: + +```bash +systemctl --user is-active podman.socket +``` + +If not active, run: + +```bash +systemctl --user enable --now podman.socket +``` + +Also check for `podman-docker`: + +```bash +command -v docker +``` + +If missing, suggest installing `podman-docker` (dnf or apt depending on `/etc/os-release`). + +### 5. Environment file + +Check if `.devcontainer/.env` exists: + +```bash +test -f .devcontainer/.env +``` + +If missing, copy from the example: + +```bash +cp .devcontainer/.env.example .devcontainer/.env +``` + +Then read `.devcontainer/.env` and check for empty required values. If any are blank (e.g. `ANTHROPIC_VERTEX_PROJECT_ID`), tell the user which values need to be filled in and ask them to edit `.devcontainer/.env` and let you know when they're done. **Do not** ask for the values directly or write to the file yourself — the user should edit it. Wait for them to confirm before continuing. + +### 6. Start the container + +Determine the right command based on OS: + +- **macOS**: `devcontainer up --workspace-folder . --docker-path podman` +- **Linux** (with `podman-docker`): `devcontainer up --workspace-folder .` +- **Linux** (without `podman-docker`): `devcontainer up --workspace-folder . --docker-path podman` + +Run it. This triggers `init-services.sh` (PostgreSQL + Redis) and `post-create.sh` (Go tools, npm, MCP venv). + +### 7. GCP authentication + +GCP credentials are mounted from the host's `~/.config/gcloud` directory. If the user hasn't authenticated on the host yet, tell them to run on the host (not inside the container): + +```bash +gcloud auth application-default login +``` + +The credentials will be available inside the container automatically after restart. + +### 8. Summary + +Print a summary of what was set up: + +- Container status +- PostgreSQL: `localhost:5432` (databases: `postgres` for seed data, `prodlike` for prod-like data) +- Data mode: `SIPPY_DATA_MODE` (default: `seed`; set to `prod-like` for BigQuery-backed operation) +- Redis: `localhost:6379` +- API server: `localhost:8080` (start with `/sippy-dev-serve`) +- React dev server: `localhost:3000` (start with `/sippy-dev-frontend`) +- GCP auth status \ No newline at end of file diff --git a/.cursor/commands/sippy-dev-tests.md b/.cursor/commands/sippy-dev-tests.md new file mode 100644 index 000000000..564d20a58 --- /dev/null +++ b/.cursor/commands/sippy-dev-tests.md @@ -0,0 +1,27 @@ +--- +description: Run lint, unit tests, and e2e in order (full local CI suite) +--- + +# Sippy dev — full test suite + +Run these three steps in order. Stop if any step fails. + +1. **Lint** — run directly: + + ```bash + make lint + ``` + +2. **Unit tests** — run directly: + + ```bash + make test + ``` + +3. **E2e** — run directly: + + ```bash + make e2e + ``` + + Works both on the host (starts its own PostgreSQL/Redis containers via Podman) and inside the devcontainer (creates a temporary `sippy_e2e` database on the existing PostgreSQL). \ No newline at end of file diff --git a/.cursor/commands/sippy-generate-release-views.md b/.cursor/commands/sippy-generate-release-views.md new file mode 100644 index 000000000..4737cda7d --- /dev/null +++ b/.cursor/commands/sippy-generate-release-views.md @@ -0,0 +1,79 @@ +--- +argument-hint: +arguments: +- source-release +- target-release +description: Generate new component readiness views for a new release +--- + +# Generate Release Views + +> **IMPORTANT**: When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + +This command generates new component readiness views for a new release by copying and updating existing views from a previous release. + +## Arguments (all optional) + +- `[source-release]`: Source release version to copy views from (e.g., `4.21`) +- `[target-release]`: Target release version to create views for (e.g., `4.22`) + +If any arguments are not provided, you will prompt the user interactively. + +## Workflow + +1. **Prompt for Source Release**: Ask the user for the source release version (e.g., `4.21`) + - Format must be X.Y (e.g., 4.21, 4.20) + +2. **Prompt for Target Release**: Ask the user for the target release version (e.g., `4.22`) + - Format must be X.Y (e.g., 4.22, 4.23) + +3. **Preview Changes**: Run the script in preview mode: + - Execute: `python3 scripts/generate_release_views.py ` + - Ask for confirmation before proceeding + +4. **Apply Changes**: If confirmed, run with --apply flag: + - Execute: `python3 scripts/generate_release_views.py --apply` + - The script will: + - Read `config/views.yaml` + - Find all views where `sample_release.release` equals the source release + - Create new views with updated releases and add them to the TOP of the views list + - **Name**: Replace source release with target release + - **Sample Release**: Update to target release + - **Base Release**: + - If base = sample (same-release comparison), both become target + - If base != sample (cross-release comparison), increment base by one minor version + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + +5. **Verify Output**: Show a diff of the changes made to views.yaml + +6. **Run Validation Test**: + - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/` + - If the test fails, the views.yaml has errors that must be fixed before committing + +7. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master). + +## View Update Logic + +When copying a view from source release to target release: + +1. **Name Update**: Replace all occurrences of source release in the name +2. **Sample Release Update**: Always set to target release +3. **Base Release Update**: Depends on the original relationship + - **Same-release views** (base = sample): Both become target + - **Cross-release views** (base != sample): Base increments by one + - When base_release becomes the sample release (not yet GA), replace 'ga' with 'now' in `relative_start` and `relative_end` + +## Examples + +### Creating 4.22 views from 4.21 + +- `4.21-main` (base: 4.20, sample: 4.21) -> `4.22-main` (base: 4.21, sample: 4.22) + - `relative_start: "ga-30d"` -> `relative_start: "now-30d"` (because base now references 4.21) +- `4.21-x86-vs-multi-arm` (base: 4.21, sample: 4.21) -> `4.22-x86-vs-multi-arm` (base: 4.22, sample: 4.22) + +## Important Notes + +- The script preserves all other view settings (variant_options, advanced_options, etc.) +- Release versions must be in format X.Y (e.g., 4.21) +- YAML formatting should be preserved using proper YAML libraries +- Always verify the diff before committing \ No newline at end of file diff --git a/.cursor/commands/sippy-update-ga-release-views.md b/.cursor/commands/sippy-update-ga-release-views.md new file mode 100644 index 000000000..15b5aa6c4 --- /dev/null +++ b/.cursor/commands/sippy-update-ga-release-views.md @@ -0,0 +1,75 @@ +--- +argument-hint: +arguments: +- release +description: Update component readiness views when a release goes GA +--- + +# Update GA Release Views + +This command updates component readiness views when a release goes GA by converting 'now' references to 'ga' in base_release relative dates and reducing sensitivity parameters. + +## Arguments (optional) + +- `[release]`: Release version that just went GA (e.g., `4.21`) + +If the argument is not provided, you will prompt the user interactively. + +## Workflow + +1. **Prompt for GA Release**: Ask the user which release just went GA (e.g., `4.21`) + - Format must be X.Y (e.g., 4.21, 4.20) + +2. **Find Affected Views**: Search config/views.yaml to identify affected views: + - Views where `base_release.release` equals the GA release (for date updates) + - Views where `sample_release.release` equals the GA release (for sensitivity reductions) + - Show the user the affected views and ask for confirmation + +3. **Apply Updates**: For each affected view: + + **A. Update base_release dates** (views comparing newer releases to the GA release): + - Replace 'now' with 'ga' in `relative_start` (e.g., `now-30d` -> `ga-30d`) + - Replace 'now' with 'ga' in `relative_end` (e.g., `now` -> `ga`) + + **B. Disable automate_jira** (views of the GA release itself): + - Change `automate_jira.enabled` from `true` to `false` + + **C. Disable multi-release analysis**: + - Change `include_multi_release_analysis` from `true` to `false` + + **D. Increase pity_factor**: + - Set `pity_factor` to `10` (from 5) + + **E. Increase minimum_failure**: + - Set `minimum_failure` to `4` (from 3) + + **F. Decrease pass_rate_required_new_tests**: + - Set `pass_rate_required_new_tests` to `90` (from 95) + +4. **Verify Output**: Show a diff of the changes made to views.yaml + +5. **Run Validation Test**: + - Run: `go test -v -run TestProductionViewsConfiguration ./pkg/flags/` + +6. **Offer to Commit**: Ask the user if they want to commit the changes (warn if on main/master). + +## Use Case + +This command is part of the release lifecycle workflow: + +1. **Before GA**: New release (e.g., 4.22) is created with views comparing to previous release (4.21) + - Views use `base_release: {release: "4.21", relative_start: "now-30d", relative_end: "now"}` +2. **When 4.21 goes GA**: Run this command + - Changes to `base_release: {release: "4.21", relative_start: "ga-30d", relative_end: "ga"}` + - Reduces sensitivity for the GA release's own views + +## Important Notes + +- This command affects two sets of views: + - Views where `base_release.release` equals the GA release (date updates) + - Views where `sample_release.release` equals the GA release (sensitivity reductions) +- Use the Edit tool for each change to preserve exact YAML formatting +- Always verify the diff to ensure only expected changes were made +- This is typically run once when a release goes GA + +**IMPORTANT**: Preserve YAML formatting (double quotes, `{ }` spacing, indentation) \ No newline at end of file diff --git a/.cursor/commands/sippy-update-job-variant.md b/.cursor/commands/sippy-update-job-variant.md new file mode 100644 index 000000000..0c5dad130 --- /dev/null +++ b/.cursor/commands/sippy-update-job-variant.md @@ -0,0 +1,115 @@ +--- +argument-hint: +arguments: +- job-pattern +- category +- value +description: Interactively update variants for a CI job +--- + +# Update Job Variant + +This command provides an interactive workflow to update variant assignments for CI jobs by modifying the variant registry Go code. + +## Arguments (all optional) + +- `[job-pattern]`: Pattern (substring or full job name) that identifies the CI job(s) to update (e.g., `-hypershift-`, `-metal-ipi-`, or full job name like `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn`) +- `[category]`: Variant category to update (e.g., Platform, Architecture, Topology) +- `[value]`: New value to set for the variant category + +If any arguments are not provided, you will prompt the user interactively. + +## Workflow + +**IMPORTANT: Argument Parsing** +Before starting the workflow, check if the user provided any arguments: + +1. Parse the command invocation to extract any provided arguments +2. If all three arguments (job-pattern, category, value) are provided: + - Validate the category exists in the snapshot file + - Skip the corresponding prompting steps + - Use the provided values directly +3. If some arguments are missing, prompt only for the missing ones +4. If no arguments are provided, follow the full interactive workflow below + +You will guide the user through the following steps (skipping steps where arguments were provided): + +1. **Prompt for a Job Pattern**: Ask the user to enter a pattern that identifies the CI job(s) they want to update. This can be either a full job name or a substring. This will be used to add pattern matching logic to the Go code. + - Example full job name: `periodic-ci-openshift-hypershift-release-4.16-periodics-e2e-aws-ovn` + - Example substrings: `-hypershift-`, `-metal-ipi-`, `-fips-` + - **Important**: Both full job names and substrings are acceptable. Accept whatever the user provides without asking for clarification. + - Advise the user that more specific patterns avoid unintended matches (e.g., `-metal-ipi-ovn-ipv6-` instead of just `-metal-`) + +2. **Select Variant Category**: Extract variant categories programmatically and present as a numbered list: + - Run: `grep -E "^ [A-Z]" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u` + - This extracts all unique variant categories from the snapshot file + - Present the list with numbers (1, 2, 3, etc.) and ask the user to select by number + +3. **Select New Value**: Based on the chosen category, extract possible values programmatically and present as a numbered list: + - For most categories, extract values from the snapshot: `grep "^ :" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/"//g' | sort -u` + - Present the unique values as a numbered list and ask the user to select by number + - For Release-related variants (Release, FromRelease, FromReleaseMajor, FromReleaseMinor, ReleaseMajor, ReleaseMinor), allow free-text input instead of showing a numbered list + +4. **Modify the Go Code**: Update `pkg/variantregistry/ocp.go` to add the pattern matching logic: + - Find the appropriate setter function for the selected variant category (e.g., `setPlatform`, `setArchitecture`, `setTopology`, etc.) + - Add an entry to the pattern matching logic in that function with the pattern and new value + - Follow the existing code style and pattern structure (see examples in the file) + - Pay special attention to pattern ordering! The functions use early return, so the first matching pattern wins. + - More specific patterns come before more generic patterns + - Example: In `setPlatform`, "-rosa" must come before "-aws" because ROSA jobs contain "aws" + - Example: In `setOwner`, "-perfscale" must come before "-qe" because perfscale jobs may contain "qe" + - Before adding the new pattern, analyze existing patterns in the function to determine the correct insertion point + - Check if the new pattern might overlap with existing patterns and ensure correct precedence + +5. **Preview Changes with Test**: Run the variant snapshot test to see what will change: + - Execute: `go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "Summary of changes:"` + - Parse this output to extract the variant category changed, old/new values, affected jobs, and total count + - Display the summary to the user + +6. **Apply Changes**: Execute `make update-variants` to regenerate `pkg/variantregistry/snapshot.yaml` + +7. **Verify Unintended Changes** (optional manual step): + - Suggest the user review `git diff pkg/variantregistry/snapshot.yaml` to ensure only expected jobs changed + +8. **Offer to Commit**: Ask the user if they want to commit the changes. If yes, commit both the Go code and the regenerated snapshot. + +## Important Notes + +- The variant logic is defined in `pkg/variantregistry/ocp.go` in setter functions +- Each variant category has its own setter function with a pattern matching list +- The `make update-variants` command runs `./sippy variants snapshot --config ./config/openshift.yaml` +- This regenerates `pkg/variantregistry/snapshot.yaml` based on the Go code logic +- Always commit both the Go code changes AND the regenerated snapshot.yaml +- Pattern matching is done with `strings.Contains(jobNameLower, pattern)` + +## Helper Commands + +### Extracting Variant Categories +```bash +grep -E "^ [A-Z]" pkg/variantregistry/snapshot.yaml | cut -d: -f1 | sed 's/^ //' | sort -u +``` + +### Extracting Values for a Specific Category +```bash +grep "^ :" pkg/variantregistry/snapshot.yaml | cut -d: -f2 | sed 's/^ //' | sed 's/"//g' | sort -u +``` + +### Previewing Changes +```bash +go test -v -run TestVariantsSnapshot ./pkg/variantregistry 2>&1 | grep -A 200 "Summary of changes:" +``` + +### Finding Setter Functions +```bash +grep -E "^func set[A-Z]" pkg/variantregistry/ocp.go | sed 's/func set//' | sed 's/(.*//' | sort +``` + +### Pattern Ordering is CRITICAL +- **The setter functions use early return - the FIRST matching pattern wins** +- More specific patterns MUST appear before more generic patterns +- Common examples to learn from: + - `-rosa` before `-aws` (ROSA jobs contain "aws") + - `-azure-aro-hcp` before `-azure` (ARO jobs contain "azure") + - `-osd-ccs-gcp` before `-gcp` (OSD GCP jobs contain "gcp") + - `-perfscale` before `-qe` (perfscale jobs may contain "qe") +- Always verify the diff doesn't show unintended changes to other jobs \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index cab6d021f..2a95723a6 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,6 +1,6 @@ # AGENTS.md - + diff --git a/CLAUDE.md b/CLAUDE.md index 58c4341d6..3eac0a35f 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,6 +1,6 @@ # CLAUDE.md - + # Project Standards diff --git a/apm.lock.yaml b/apm.lock.yaml index 39999d874..2f6dfe6f2 100644 --- a/apm.lock.yaml +++ b/apm.lock.yaml @@ -23,6 +23,7 @@ local_deployed_files: - .cursor/commands/sippy-dev-frontend.md - .cursor/commands/sippy-dev-migrate.md - .cursor/commands/sippy-dev-regression-cache.md +- .cursor/commands/sippy-dev-restore-prodlike.md - .cursor/commands/sippy-dev-serve.md - .cursor/commands/sippy-dev-setup.md - .cursor/commands/sippy-dev-tests.md @@ -56,55 +57,56 @@ local_deployed_files: - .opencode/commands/sippy-update-ga-release-views.md - .opencode/commands/sippy-update-job-variant.md local_deployed_file_hashes: - .claude/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 + .claude/commands/sippy-dev-app.md: sha256:656276ed961940c137dde32ecdb0501427d4d811502a27125ba073adc770d266 .claude/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a - .claude/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b - .claude/commands/sippy-dev-regression-cache.md: sha256:4e9fc3ed63927c84c30554929768a3b0e760264925f55c9dbbdafabf2361bee2 - .claude/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 - .claude/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f - .claude/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 + .claude/commands/sippy-dev-migrate.md: sha256:80160e88e0cc0fc09ab3dd9cc6fc496fe87dd8873800eb65d700868034d59da2 + .claude/commands/sippy-dev-regression-cache.md: sha256:683448f4a553c4511c909fc2711b13edb7ee27d0c437aa9e7689bc9ba6fc0b6a + .claude/commands/sippy-dev-serve.md: sha256:24d61d9b5d3d6b2fdcfbf8fb8e97da3b633293adb31e6df061d61170de826f35 + .claude/commands/sippy-dev-setup.md: sha256:68a019dbf60081e3b4e0c751413f96406c29c13912bb55c3492b48c913f7f74f + .claude/commands/sippy-dev-tests.md: sha256:d76061fc3ee9478207d120436c016b3651c19c4f3f5fcb61a630462a9d9e5622 .claude/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a .claude/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 .claude/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 .claude/rules/backend.md: sha256:c57f9ef479340d977f06266779cacc8cd0a67cf045a58d30757a0c494354081a - .claude/rules/dev-commands.md: sha256:4508eaad3d835305b68106ed5b270ced97c93e4a42ee94d1bcac5ea7b056bc5d + .claude/rules/dev-commands.md: sha256:eb32bdc640add2044138807572ea1afb73ee1bba038f5098032a89987a7ddc04 .claude/rules/frontend.md: sha256:ff22046c5b951769218bbdf36499e67c70896811b8ef161ca6d3729a3423997d - .claude/rules/general.md: sha256:9238d053e2d6a1703728c2bb165de93658b47c3152dfac16169ff9db9c6f716c - .claude/rules/mcp.md: sha256:73735078b3b1a8597b91b49821ba05cdb338144ea00c1eea9e9f4de38d0241a3 + .claude/rules/general.md: sha256:997f68e86cb43485ec5f108be3417f9bbb43ae1faffd660d598f18260f5df3ce + .claude/rules/mcp.md: sha256:ddfe965e7cf8cddbba1374c6ae582a20ac0af17c958bf10e1a4edff6ff2ad0b8 .claude/rules/testing.md: sha256:57834092f6732d17f8c1812d25290cfc1cfbbbeb6eae1561ba2240973c651866 - .cursor/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 + .cursor/commands/sippy-dev-app.md: sha256:656276ed961940c137dde32ecdb0501427d4d811502a27125ba073adc770d266 .cursor/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a - .cursor/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b - .cursor/commands/sippy-dev-regression-cache.md: sha256:4e9fc3ed63927c84c30554929768a3b0e760264925f55c9dbbdafabf2361bee2 - .cursor/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 - .cursor/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f - .cursor/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 + .cursor/commands/sippy-dev-migrate.md: sha256:80160e88e0cc0fc09ab3dd9cc6fc496fe87dd8873800eb65d700868034d59da2 + .cursor/commands/sippy-dev-regression-cache.md: sha256:683448f4a553c4511c909fc2711b13edb7ee27d0c437aa9e7689bc9ba6fc0b6a + .cursor/commands/sippy-dev-restore-prodlike.md: sha256:868d480aa0f338acdd766332dd37b5ba07cbbb4b79bb2a078c9d8f0eb7c714a4 + .cursor/commands/sippy-dev-serve.md: sha256:24d61d9b5d3d6b2fdcfbf8fb8e97da3b633293adb31e6df061d61170de826f35 + .cursor/commands/sippy-dev-setup.md: sha256:68a019dbf60081e3b4e0c751413f96406c29c13912bb55c3492b48c913f7f74f + .cursor/commands/sippy-dev-tests.md: sha256:d76061fc3ee9478207d120436c016b3651c19c4f3f5fcb61a630462a9d9e5622 .cursor/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a .cursor/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 .cursor/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 .cursor/rules/backend.mdc: sha256:fb466b896d76ea1730c23d6c3fc783adf2cd5502c1cbb36e5b3d30c01531e4c1 - .cursor/rules/dev-commands.mdc: sha256:c69ca93db9b6c68f9aeb6567289dc5baef805520e8636a1e3e848793f67450e6 + .cursor/rules/dev-commands.mdc: sha256:3dc8a3ef5cbb22ebb09b7fe3785f24a32ab2baa4488c5514c9c6210b0af6c4eb .cursor/rules/frontend.mdc: sha256:497f39372724f1ae127181fe3dac9ea9a95a51c532b68ccfee6080832cf9c556 - .cursor/rules/general.mdc: sha256:671e94d8251783ecfb70d16e6e8d60dc42752ecfbe90919006b908b8a751595d - .cursor/rules/mcp.mdc: sha256:268557cc3bdd9c8f7401f9ea80ac342ff2688f1d563b10880177ca586d7d30bb + .cursor/rules/general.mdc: sha256:5bc6e1e12d53d85656248c9dc1239c74bcc0df29d5987f3b08e3d79e3df413b7 + .cursor/rules/mcp.mdc: sha256:c02472afd46e4c89f71d4487dcd5da98b0c1bcbcf7f9cbc4d7ed4e7d3a206ec1 .cursor/rules/testing.mdc: sha256:e5ce80313a812750404d45355b462c2e3a6458f5bc20ad7996a5da1b169a4703 - .gemini/commands/sippy-dev-app.toml: sha256:afc6fe75647832aa571c63d8229d151820c54535cdb695b96f8400c1d7b3bd16 + .gemini/commands/sippy-dev-app.toml: sha256:fc28174eeab4e440694a823bd838d429241997a018d8a13f32e0f67ca4d973c5 .gemini/commands/sippy-dev-frontend.toml: sha256:ec4ab5e1fb7581f09473e33b3ed4f53ce40509f23aac581e3b100ad1f59de5e5 - .gemini/commands/sippy-dev-migrate.toml: sha256:e699558eb27c294327a092bfcd3e76b576087ad29d9a3a9b000cfd9e7c6b4774 - .gemini/commands/sippy-dev-regression-cache.toml: sha256:cd2c9017e5e976750839c712b42d10046d1d04fabaa749ffda6fd1abaf776d7a - .gemini/commands/sippy-dev-serve.toml: sha256:adff646a493861ca4bb5246fb32b6eb69dc77829d05b74b8e7c241cb08dff808 - .gemini/commands/sippy-dev-setup.toml: sha256:bb56074029f5a73075f7d8b5e971ad2621d0517ea29a90bbb1e11f989bd6295c - .gemini/commands/sippy-dev-tests.toml: sha256:0b5f406eac7adca8ee4db287973368b9dea048f89f0fdf86e3fc9730646c8d47 + .gemini/commands/sippy-dev-migrate.toml: sha256:25c98ba4bfdb95270dfcb4238ae688f9a66f0e645d8a4a6c5e03b1cf8db5cb7e + .gemini/commands/sippy-dev-regression-cache.toml: sha256:e00021f336c5d35c8d23d87c230530145734ab68ac183fb2a462dd375bcde2ff + .gemini/commands/sippy-dev-serve.toml: sha256:3584c3e96e633685e906198095457fada19e95b4e611ed12e1c6f846ca4ce5d4 + .gemini/commands/sippy-dev-setup.toml: sha256:b76f21c8dc144e8ddab8d47e58ee80cfb8bf53116e16b53ecf0c6d1ab3974387 + .gemini/commands/sippy-dev-tests.toml: sha256:be46cf9c4ce1857a82c1f911c838b05c430a0be5c2d21128b88d5c1bb3a4832c .gemini/commands/sippy-generate-release-views.toml: sha256:9173d7507f469eda21a19f7e5ec47bce0c6ce87a73c1f5c10594a89417332927 .gemini/commands/sippy-update-ga-release-views.toml: sha256:662ac8d503d883cf6142c801b79e46616afb3d806e1d936e952d918b257ddf73 .gemini/commands/sippy-update-job-variant.toml: sha256:3b044dfaddeafa1a6d375918d5860785f8d315b593c355bbb7293a87c50361b8 - .opencode/commands/sippy-dev-app.md: sha256:44a111c7cbd34d2480658b39f9b01a18cb80e0f50b4a652cae4c255d123595a4 + .opencode/commands/sippy-dev-app.md: sha256:656276ed961940c137dde32ecdb0501427d4d811502a27125ba073adc770d266 .opencode/commands/sippy-dev-frontend.md: sha256:42eae4b3bc610c9fcb43533a6fed229a6d1c409d279f3d6f93672986ede62e3a - .opencode/commands/sippy-dev-migrate.md: sha256:5704945283027398bbe4a54eb4d97295059bd64a47e86e97a58665338ec62c8b - .opencode/commands/sippy-dev-regression-cache.md: sha256:4e9fc3ed63927c84c30554929768a3b0e760264925f55c9dbbdafabf2361bee2 - .opencode/commands/sippy-dev-serve.md: sha256:89a89448d948c68304471f7d872e8cb3395b83895f5d0a051f57a07252f50c34 - .opencode/commands/sippy-dev-setup.md: sha256:276c708371bebcdbe8602df22ca482e59c2eab0bbc7ecacf1b49acd0a99d966f - .opencode/commands/sippy-dev-tests.md: sha256:26dfc22708d0e3bd4879640b4b9f090fc0b3fcaa21957ca0e4a52305bc9cb593 + .opencode/commands/sippy-dev-migrate.md: sha256:80160e88e0cc0fc09ab3dd9cc6fc496fe87dd8873800eb65d700868034d59da2 + .opencode/commands/sippy-dev-regression-cache.md: sha256:683448f4a553c4511c909fc2711b13edb7ee27d0c437aa9e7689bc9ba6fc0b6a + .opencode/commands/sippy-dev-serve.md: sha256:24d61d9b5d3d6b2fdcfbf8fb8e97da3b633293adb31e6df061d61170de826f35 + .opencode/commands/sippy-dev-setup.md: sha256:68a019dbf60081e3b4e0c751413f96406c29c13912bb55c3492b48c913f7f74f + .opencode/commands/sippy-dev-tests.md: sha256:d76061fc3ee9478207d120436c016b3651c19c4f3f5fcb61a630462a9d9e5622 .opencode/commands/sippy-generate-release-views.md: sha256:eb4c9eeeea2ab2a90e8a8839147d8a1a309ea6ce3dafd397c6d2485c93068a9a .opencode/commands/sippy-update-ga-release-views.md: sha256:4a5589bacc05127e427a2de4d34a8f13e05e297bdf6ebf7473c9e71f47a6b4f4 .opencode/commands/sippy-update-job-variant.md: sha256:f88742dddeec5024931959a8330fdce362ffdd9b8825e808830ac346605cbd16 diff --git a/mcp/AGENTS.md b/mcp/AGENTS.md index a31e275ca..223f6001a 100644 --- a/mcp/AGENTS.md +++ b/mcp/AGENTS.md @@ -1,6 +1,6 @@ # AGENTS.md - + diff --git a/mcp/CLAUDE.md b/mcp/CLAUDE.md index 9d4eb3754..479826d5f 100644 --- a/mcp/CLAUDE.md +++ b/mcp/CLAUDE.md @@ -1,6 +1,6 @@ # CLAUDE.md - + # Project Standards From 487ddddcc652e1b3f9c8cb517eb4d5f50e506b65 Mon Sep 17 00:00:00 2001 From: Stephen Benjamin Date: Fri, 15 May 2026 06:37:25 -0400 Subject: [PATCH 4/4] Bump apm-cli from 0.12.4 to 0.13.0 Co-Authored-By: Claude Opus 4.6 --- AGENTS.md | 4 ++-- CLAUDE.md | 4 ++-- GEMINI.md | 4 ++-- Makefile | 4 ++-- mcp/AGENTS.md | 4 ++-- mcp/CLAUDE.md | 4 ++-- sippy-ng/AGENTS.md | 4 ++-- sippy-ng/CLAUDE.md | 4 ++-- 8 files changed, 16 insertions(+), 16 deletions(-) diff --git a/AGENTS.md b/AGENTS.md index 2a95723a6..ba5c9d265 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `**` diff --git a/CLAUDE.md b/CLAUDE.md index 3eac0a35f..a498d2700 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards diff --git a/GEMINI.md b/GEMINI.md index f933b9480..6b1d3f4bc 100644 --- a/GEMINI.md +++ b/GEMINI.md @@ -1,6 +1,6 @@ # GEMINI.md - - + + @./AGENTS.md diff --git a/Makefile b/Makefile index ac4456878..6cefb01ef 100644 --- a/Makefile +++ b/Makefile @@ -62,8 +62,8 @@ clean: rm -rf sippy-ng/node_modules apm: - uvx --from apm-cli@0.12.4 apm install - uvx --from apm-cli@0.12.4 apm compile + uvx --from apm-cli@0.13.0 apm install + uvx --from apm-cli@0.13.0 apm compile verify-apm: apm @if ! git diff --quiet HEAD -- .claude .cursor .gemini .opencode AGENTS.md CLAUDE.md GEMINI.md sippy-ng/AGENTS.md sippy-ng/CLAUDE.md mcp/AGENTS.md mcp/CLAUDE.md; then \ diff --git a/mcp/AGENTS.md b/mcp/AGENTS.md index 223f6001a..a6be6a915 100644 --- a/mcp/AGENTS.md +++ b/mcp/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `mcp/**` diff --git a/mcp/CLAUDE.md b/mcp/CLAUDE.md index 479826d5f..53bc2760c 100644 --- a/mcp/CLAUDE.md +++ b/mcp/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards diff --git a/sippy-ng/AGENTS.md b/sippy-ng/AGENTS.md index e715c721a..c0f03915d 100644 --- a/sippy-ng/AGENTS.md +++ b/sippy-ng/AGENTS.md @@ -1,7 +1,7 @@ # AGENTS.md - - + + ## Files matching `sippy-ng/**` diff --git a/sippy-ng/CLAUDE.md b/sippy-ng/CLAUDE.md index 3f9a23ec1..a409d35af 100644 --- a/sippy-ng/CLAUDE.md +++ b/sippy-ng/CLAUDE.md @@ -1,7 +1,7 @@ # CLAUDE.md - - + + # Project Standards