ci: harden release gate required check matching

Author: justin808

.claude/hooks/main-ci-status.sh

@@ -158,32 +158,49 @@ checks_jsonl=$(gh api \
 # that each define a `detect-changes` job). Mirrors the Ruby dedup in
 # `validate_main_ci_status!` (rakelib/release.rake). Keep the two in sync.
 checks_json=$(echo "${checks_jsonl}" | jq -s '
-  [.[] | {id, name, status, conclusion, html_url, suite_id: (.check_suite.id // .id)}]
-  | group_by([.suite_id, .name])
+  [.[] | {id, name, status, conclusion, html_url, suite_id: (.check_suite.id // .id), app_id: (.app.id // null)}]
+  | group_by([.suite_id, .name, .app_id])
   | map(max_by(.id))
 ' 2>/dev/null) || fail_open "jq slurp failed"
 
 required_json=$(gh api \
   "repos/${repo_slug}/branches/main/protection/required_status_checks" \
-  --jq '(.contexts // []) + (.checks // [] | map(.context)) | unique' \
+  --jq '{contexts: (.contexts // []), checks: (.checks // [] | map({context, app_id}))}' \
   2>/dev/null || echo "null")
 case "${required_json}" in
-  \[*\]) ;;
+  \{*\}) ;;
   *) required_json="null" ;;
 esac
 
 # Aggregate counts with jq. `success`, `skipped`, `neutral` are all "passing".
 # Anything completed with another conclusion is a failure. Anything not yet
 # completed is in_progress.
 summary=$(echo "${checks_json}" | jq -r --argjson required_names "${required_json}" '
+  def app_wildcard($app_id): $app_id == null or $app_id == -1;
+  def check_matches($required):
+    .name == $required.context and (app_wildcard($required.app_id) or .app_id == $required.app_id);
+  def required_check_label:
+    if app_wildcard(.app_id) then .context else "\(.context) (app_id: \(.app_id))" end;
+
   . as $all
-  | ($all | map(.name)) as $observed_names
   | {
       total: length,
       passed: [.[] | select(.status == "completed" and (.conclusion | IN("success", "skipped", "neutral")))] | length,
       failed: [.[] | select(.status == "completed" and (.conclusion | IN("success", "skipped", "neutral") | not))],
       in_progress: [.[] | select(.status != "completed")],
-      missing_required: (if $required_names == null then [] else ($required_names - $observed_names) end)
+      missing_required: (
+        if $required_names == null then []
+        else
+          # NOTE: commit statuses are not fetched here; this hook is a fail-open
+          # display tool. The Ruby release gate owns legacy status enforcement.
+          (($required_names.contexts // [])
+            | map(select(. as $context | ($all | any(.name == $context) | not))))
+          +
+          (($required_names.checks // [])
+            | map(select(. as $required | ($all | any(. as $run | ($run | check_matches($required))) | not)))
+            | map(required_check_label))
+        end
+      )
     }
   | "TOTAL=\(.total)",
     "PASSED=\(.passed)",

analysis/vm-script-caching-investigation-2026-06-07.md

@@ -4,11 +4,11 @@ Related issue: [#3282](https://github.com/shakacode/react_on_rails/issues/3282)
 
 ## Verdict
 
-| Area | Status | Finding |
-|------|--------|---------|
-| vm.Script caching benefit | **Not needed** | Execution time dominates; compile overhead is negligible for real workloads |
-| Hypothesis from #3282 | Refuted | Expected ~3ms savings not achievable — real compile cost is <15μs even for 500KB code |
-| Implementation effort | Not justified | Adds complexity for <0.01% improvement on actual render paths |
+| Area                      | Status         | Finding                                                                               |
+| ------------------------- | -------------- | ------------------------------------------------------------------------------------- |
+| vm.Script caching benefit | **Not needed** | Execution time dominates; compile overhead is negligible for real workloads           |
+| Hypothesis from #3282     | Refuted        | Expected ~3ms savings not achievable — real compile cost is <15μs even for 500KB code |
+| Implementation effort     | Not justified  | Adds complexity for <0.01% improvement on actual render paths                         |
 
 ## Executive Summary
 
@@ -19,6 +19,7 @@ Issue #3282 proposed caching pre-compiled `vm.Script` objects to save the ~3ms "
 3. **The 3ms observed** was likely execution time, not parse time
 
 Caching `vm.Script` is only beneficial for scripts that:
+
 - Execute in <1μs (trivial expressions)
 - Run 100+ times with identical code
 - Have minimal actual computation
@@ -36,26 +37,26 @@ The render template in react_on_rails_pro does real work (React rendering, props
 
 ### 1. Compilation Cost vs Code Size
 
-| Code Size | Compile Time | Cached Exec | Uncached Exec | Speedup |
-|-----------|--------------|-------------|---------------|---------|
-| 60 chars | 0.54μs | 0.62μs | 1.37μs | **2.2x** |
-| 8 KB | 0.54μs | 38.04μs | 38.54μs | **1.01x** |
-| 69 KB | 2.75μs | 400.12μs | 404.00μs | **1.01x** |
-| 650 KB | 0.83μs | 2016.46μs | 2016.25μs | **1.00x** |
+| Code Size | Compile Time | Cached Exec | Uncached Exec | Speedup   |
+| --------- | ------------ | ----------- | ------------- | --------- |
+| 60 chars  | 0.54μs       | 0.62μs      | 1.37μs        | **2.2x**  |
+| 8 KB      | 0.54μs       | 38.04μs     | 38.54μs       | **1.01x** |
+| 69 KB     | 2.75μs       | 400.12μs    | 404.00μs      | **1.01x** |
+| 650 KB    | 0.83μs       | 2016.46μs   | 2016.25μs     | **1.00x** |
 
 **Observation**: For scripts with real execution time (38μs+), caching provides <1% improvement because compilation (0.5-3μs) is noise compared to execution.
 
 ### 2. Parse Complexity Analysis
 
 Different AST patterns were tested to find maximum parse cost:
 
-| Pattern | Code Size | Compile Time | Size Needed for 1ms Compile |
-|---------|-----------|--------------|----------------------------|
-| Nested objects | 2.7 KB | 1.0μs | **2.6 MB** |
-| Generators | 9 KB | 1.2μs | 7.3 MB |
-| Class definitions | 16 KB | 1.4μs | 11.2 MB |
-| Regex literals | 29 KB | 1.8μs | 15.4 MB |
-| String literals | 111 KB | 3.8μs | 27.6 MB |
+| Pattern           | Code Size | Compile Time | Size Needed for 1ms Compile |
+| ----------------- | --------- | ------------ | --------------------------- |
+| Nested objects    | 2.7 KB    | 1.0μs        | **2.6 MB**                  |
+| Generators        | 9 KB      | 1.2μs        | 7.3 MB                      |
+| Class definitions | 16 KB     | 1.4μs        | 11.2 MB                     |
+| Regex literals    | 29 KB     | 1.8μs        | 15.4 MB                     |
+| String literals   | 111 KB    | 3.8μs        | 27.6 MB                     |
 
 **Observation**: Even the most expensive parsing pattern (deeply nested objects) requires 2.6 MB of code to reach 1ms compile time. This is unrealistic for render templates.
 
@@ -64,33 +65,35 @@ Different AST patterns were tested to find maximum parse cost:
 How much time is saved across N executions of a trivial script (32 chars)?
 
 | Executions | Cached Total | Uncached Total | Time Saved |
-|------------|--------------|----------------|------------|
-| 10 | 15μs | 33μs | 18μs |
-| 100 | 112μs | 183μs | 71μs |
-| 1,000 | 627μs | 1,410μs | 784μs |
-| 10,000 | 3,844μs | 11,043μs | **7.2ms** |
+| ---------- | ------------ | -------------- | ---------- |
+| 10         | 15μs         | 33μs           | 18μs       |
+| 100        | 112μs        | 183μs          | 71μs       |
+| 1,000      | 627μs        | 1,410μs        | 784μs      |
+| 10,000     | 3,844μs      | 11,043μs       | **7.2ms**  |
 
 **Observation**: Need ~10,000 executions of trivial scripts to save 7ms total. The render template runs once per request — no amortization possible.
 
 ### 4. Heavy Computation Scripts
 
 Scripts that do real work (object creation, loops, array operations):
 
-| Script Type | Cached/exec | Uncached/exec | Speedup |
-|-------------|-------------|---------------|---------|
-| Trivial (return 1+1) | 0.37μs | 1.05μs | 2.8x |
-| Light (loop 10x) | 0.47μs | 1.17μs | 2.5x |
-| Medium (100 sqrt calls) | 12.87μs | 13.80μs | **1.07x** |
-| Heavy (1000 objects) | 39.15μs | 39.99μs | **1.02x** |
+| Script Type             | Cached/exec | Uncached/exec | Speedup   |
+| ----------------------- | ----------- | ------------- | --------- |
+| Trivial (return 1+1)    | 0.37μs      | 1.05μs        | 2.8x      |
+| Light (loop 10x)        | 0.47μs      | 1.17μs        | 2.5x      |
+| Medium (100 sqrt calls) | 12.87μs     | 13.80μs       | **1.07x** |
+| Heavy (1000 objects)    | 39.15μs     | 39.99μs       | **1.02x** |
 
 **Observation**: The moment execution time exceeds ~5μs, caching benefit drops to noise levels.
 
 ## Why the Original 3ms Estimate Was Wrong
 
 Issue #3282 stated:
+
 > Per-request JS-parse cost: ~3 ms
 
 This measurement likely included:
+
 1. **React component evaluation** (function execution, not parsing)
 2. **Props serialization** (JSON stringify/parse overhead)
 3. **Context creation** (`vm.createContext` cost, not `vm.Script` compile)
@@ -101,18 +104,20 @@ Our isolated benchmark shows V8 parses 1MB of JavaScript in ~26μs. A 200-byte t
 ## Scripts That Would Benefit (Not Our Use Case)
 
 Caching helps when:
+
 ```js
 // Config literals — 2-3x faster
 const config = new vm.Script(`({ apiUrl: "...", timeout: 5000 })`);
 
-// Simple expressions — 2-3x faster  
+// Simple expressions — 2-3x faster
 const formula = new vm.Script(`price * quantity * (1 - discount)`);
 
 // Feature flags — 2x faster
 const check = new vm.Script(`user.role === "admin"`);
 ```
 
 Caching does NOT help when:
+
 ```js
 // Data transformation — 1.05x (no real gain)
 const transform = new vm.Script(`
@@ -127,13 +132,13 @@ const render = new vm.Script(`
 
 ## Decision Framework
 
-| Condition | Cache vm.Script? |
-|-----------|------------------|
-| Script execution < 1μs | Yes |
-| Script execution > 10μs | No |
-| Script runs 1x per request | No |
-| Script is pure config/expression | Yes |
-| Script does React rendering | **No** |
+| Condition                        | Cache vm.Script? |
+| -------------------------------- | ---------------- |
+| Script execution < 1μs           | Yes              |
+| Script execution > 10μs          | No               |
+| Script runs 1x per request       | No               |
+| Script is pure config/expression | Yes              |
+| Script does React rendering      | **No**           |
 
 ## Recommendation
 
@@ -147,13 +152,15 @@ The optimization targets the wrong layer. V8's JIT compiler is not the bottlenec
 4. Reducing React reconciliation work
 
 Adding `vm.Script` caching would:
+
 - Add code complexity (cache invalidation, memory management)
 - Provide <0.01% improvement on real workloads
 - Create false confidence that "we optimized the VM layer"
 
 ## Artifacts
 
 Benchmark scripts and raw data available at:
+
 - Original experiment: `vm-script-cache/tmp/experiments/20260607T083551Z-vm-script-cache/`
 
 ### Raw Benchmark Output (Summary)