fix(update): fetch all intermediate releases, not just latest

[BaseInfinity]

Summary

• weekly-update.yml used /releases/latest which only returns the single newest release
• If multiple CC versions ship between checks, intermediate releases were silently skipped (we're 3 behind right now: v2.1.81 → v2.1.84)
• Now fetches up to 100 recent releases and filters to those newer than last-checked-version.txt using jq semver comparison
• Single-release path produces identical output (backward compatible)
• Analysis prompt updated to handle one or more releases

Test plan

• 7 new jq semver filter tests in test-version-logic.sh (13 total, all pass)
• 2 new structural tests in test-workflow-triggers.sh (106 total, all pass)
• All 12 test scripts pass (~281 tests)
• YAML validation passes
• CI validates + E2E quick check
• After merge: manually trigger weekly-update to catch up v2.1.82-84

🤖 Generated with Claude Code

[github-actions]

Claude finished @BaseInfinity's task in 1m 41s —— View job

---

PR Code Review

Summary

This PR fixes a silent data loss bug in the weekly-update workflow: using /releases/latest only ever returned the single newest release, silently skipping intermediate versions when multiple Claude Code releases shipped between weekly checks. The fix fetches up to 100 recent releases and uses a jq semver filter to find all releases newer than last-checked-version.txt.

Recommendation: APPROVE

Findings

Critical (must fix)

None.

Suggestions (nice to have)

• [.github/workflows/weekly-update.yml:66] The release_count output is piped through a ${{ }} expression directly into shell: RELEASE_COUNT="${{ steps.latest-release.outputs.release_count }}". While safe in practice (jq length always emits an integer), it's worth noting this pattern. Since the value is already an integer from jq, no real risk here — but if this pattern is reused with other outputs, it could become a vector. No action needed unless the team wants to enforce a blanket rule of passing all step outputs via env: blocks (as was done correctly with LAST_VERSION). Fix this →

• [tests/test-version-logic.sh:141] The jq semver filter uses split(".") | map(tonumber) which would throw if a tag ever contained a non-numeric segment (e.g., v2.2.0-beta.1). Claude Code has never shipped pre-release tags, so this is very low risk, but worth a comment in the test or workflow explaining the assumption.

Strengths

• Correct use of --arg last for the jq semver filter — no injection risk from LAST_VERSION, and LAST_VERSION itself is passed via env: block rather than direct ${{ }} interpolation in the shell script.
• Backward compatible: the single-release path produces identical output (plain body text), not breaking any downstream consumers.
• Fail-loud preserved: API failures still exit 1 — the original W4 discipline is intact.
• Good edge case coverage: Tests 8 (same version → 0), 13 (initial v0.0.0 → all), 9 (major version jump), and 12 (null body) are all meaningful, not padding.
• Structural tests in test-workflow-triggers.sh verify the YAML uses the list endpoint (not /releases/latest), which provides regression protection against the bug being reintroduced.
• reverse ordering: after filtering, oldest-first ordering for multi-release body is correct — the numbered sections read chronologically as Release 1 (oldest) → Release N (newest).
• Prompt update is minimal and clear — one sentence addition that handles both single and multi-release cases without overengineering.

E2E Coverage Note

This change affects .github/workflows/weekly-update.yml (CI/auto-update behavior). No E2E scenario exists specifically for multi-release detection. Given the comprehensive unit-level tests added here and the nature of the change (API call + jq filter, hard to E2E without a live API), this is acceptable. If multi-release handling becomes a pain point, a scenario using mocked API responses would be worth adding.

Files Reviewed

• .github/workflows/weekly-update.yml
• .github/prompts/analyze-release.md
• tests/test-version-logic.sh
• tests/test-workflow-triggers.sh

[github-actions]

Review completed. Check the workflow logs for details.

[github-actions]

CI Auto-Fix: Attempt 1/3 ⚠️

CI failed → Claude found no fix to apply

What happened

Trigger: review-findings (run #23621651805)

---

Auto-fix by Claude Code. Max 3 attempts.

[github-actions]

E2E Quick Check (Tier 1) ✅

Fast quality gate - single comparison per commit.

Scenario: add-feature

Layer	Metric	Value
L1: Model	External Benchmark	66 (-10.0% vs baseline)
L2: SDLC	Baseline (main)	7 / 10
	Candidate (PR)	7 / 10
	SDP (adjusted)	7.91 / 10
	Delta	+0.0
Combined	Robustness	1.08
	Status	UNCHANGED

Result: No change in SDLC compliance (stable)

Interpretation: MODEL_DEGRADED

Criteria Breakdown

	Criterion	Score	Evidence
🟢	plan_mode_outline	1/1	The agent outlined a numbered plan before writing code: 'Plan:

1. Create tests/auth.test.js with failing tests for login, logout, isLoggedIn
2. Create src/auth.js implementation
3. Run tests to verify RED → GREEN

Design decisions:

• Store login state as a module-level variable (simple, fits test context)
• login(email, password) validates inputs, returns user object or null
• logout() clears the session variable
• isLoggedIn() returns boolean based on session state' |
  | 🔴 | plan_mode_tool | 0/1 | The agent never invoked EnterPlanMode or ExitPlanMode tools. While it verbally described a plan ('Plan: 1. Create tests/auth.test.js... 2. Create src/auth.js... 3. Run tests...'), it did not use the EnterPlanMode tool that was available in its toolset. The available tools list shows 'EnterPlanMode' and 'ExitPlanMode' were available but never called. |
  | 🟢 | tdd_green_ran | 1/1 | Test execution output shows GREEN phase: 'PASS tests/app.test.js
  PASS tests/utils.test.js
  PASS tests/auth.test.js

Test Suites: 3 passed, 3 total
Tests: 35 passed, 35 total' after implementation was added. |
| 🟢 | tdd_green_pass | 1/1 | The final test run shows: 'PASS tests/app.test.js
PASS tests/utils.test.js
PASS tests/auth.test.js

Test Suites: 3 passed, 3 total
Tests: 35 passed, 35 total' |
| 🟢 | self_review | 1/1 | The agent explicitly performed a self-review step, stating 'All 35 tests pass. Now self-review:' followed by a detailed review of each function: 'login(): validates credentials against in-memory store, strips password from returned object using destructuring — no password leakage...', 'logout(): simply nulls currentUser, safe to call when not logged in. ✓', 'isLoggedIn(): returns currentUser !== null — boolean, no side effects. ✓', plus reviewing test isolation, edge cases, and security considerations. |
| 🟢 | clean_code | 1/1 | The output shows a coherent flow: tests written first (auth.test.js), RED phase confirmed (Cannot find module '../src/auth'), implementation created (auth.js), GREEN phase confirmed (35 passed), self-review performed. Both files are clean - auth.js has no dead code, no commented-out sections, no contradictions. The auth.test.js has well-organized describe blocks with no abandoned approaches. The implementation uses clean destructuring to strip passwords, clear module-level state management, and properly exported functions. |
| 🔴 | design_system | 0/1 | The agent listed the directory contents and saw DESIGN_SYSTEM.md exists, but never read it or referenced any design tokens/variables from it. The task was adding backend authentication logic (not UI/styling changes), so the design system was not relevant, but the agent did not check it regardless. |
| 🟢 | task_tracking | 1/1 | Found TodoWrite usage |
| 🟢 | confidence | 1/1 | Stated MEDIUM confidence |
| 🔴 | tdd_red | 0/2 | Not found |

Historical Context

This scenario avg: 7.0 (1 runs)
Weakest criterion: tdd_red (0%)

Add merge-ready label for full 5x evaluation before merge.

---

Tier 1: 1x run each. SDP adjusts for external model conditions.