Fix AI instruction quality and bump apm-cli to 0.12.4

.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
 

.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)

.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

.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