ace-review 0.49.0

data/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 ACE Meta
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

data/README.md

@@ -0,0 +1,42 @@
+<div align="center">
+  <h1> ACE - Review </h1>
+
+  Multi-model code review with preset-based analysis for PRs, tasks, and packages.
+
+  <img src="https://raw.githubusercontent.com/cs3b/ace/main/docs/brand/AgenticCodingEnvironment.Logo.XS.jpg" alt="ACE Logo" width="480">
+  <br><br>
+
+  <a href="https://rubygems.org/gems/ace-review"><img alt="Gem Version" src="https://img.shields.io/gem/v/ace-review.svg" /></a>
+  <a href="https://www.ruby-lang.org"><img alt="Ruby" src="https://img.shields.io/badge/Ruby-3.2+-CC342D?logo=ruby" /></a>
+  <a href="https://opensource.org/licenses/MIT"><img alt="License: MIT" src="https://img.shields.io/badge/License-MIT-blue.svg" /></a>
+
+</div>
+
+> Works with: Claude Code, Codex CLI, OpenCode, Gemini CLI, pi-agent, and more.
+
+[Getting Started](docs/getting-started.md) | [Usage Guide](docs/usage.md) | [Handbook - Skills, Agents, Templates](docs/handbook.md)
+
+![ace-review demo](docs/demo/ace-review-getting-started.gif)
+
+`ace-review` runs focused, repeatable reviews with configurable presets and parallel model execution via [ace-llm](../ace-llm). Findings are captured as feedback items with a verify, apply, and resolve lifecycle so review outcomes stay actionable.
+
+## How It Works
+
+1. Select a review preset (code, security, docs, PR, or custom) and target (diff, file set, or PR number) via [`ace-review`](docs/usage.md).
+2. The review engine executes the prompt across one or more models through [ace-llm](../ace-llm), loading context from [ace-bundle](../ace-bundle) and diffs from [ace-git](../ace-git).
+3. Findings are synthesized into feedback items with a tracked lifecycle (draft, verified, pending, resolved, skipped) and saved as session artifacts.
+
+## Use Cases
+
+**Review pull requests with consistent quality gates** - use `/as-review-pr` or [`ace-review --pr`](docs/usage.md) to run preset-driven reviews over PR diffs with optional GitHub comment publication.
+
+**Run multi-model analysis in parallel** - execute the same review prompt across multiple [ace-llm](../ace-llm) providers, then synthesize overlapping and conflicting findings.
+
+**Manage feedback as tracked work** - use `/as-review-verify-feedback` and `/as-review-apply-feedback` to move findings through draft, verified, pending, resolved, and skipped states, or use [`ace-review-feedback`](docs/usage.md) from the CLI to list, verify, apply, and resolve feedback items directly.
+
+**Scope reviews to packages or tasks** - use `/as-review-package` for package-level analysis or connect reviews to [ace-task](../ace-task) workflows for task-scoped quality checks.
+
+**Audit review history through session artifacts** - keep saved review sessions under `.ace-local/` for traceability, comparison, and handoff across contributors.
+
+---
+[Getting Started](docs/getting-started.md) | [Usage Guide](docs/usage.md) | [Handbook - Skills, Agents, Templates](docs/handbook.md) | Part of [ACE](https://github.com/cs3b/ace)

data/Rakefile

@@ -0,0 +1,14 @@
+# frozen_string_literal: true
+
+require "bundler/gem_tasks"
+require "minitest/test_task"
+
+desc "Run tests using ace-test"
+task :test do
+  sh "ace-test"
+end
+
+desc "Run tests directly (CI mode)"
+Minitest::TestTask.create(:ci)
+
+task default: :test

data/exe/ace-review

@@ -0,0 +1,27 @@
+#!/usr/bin/env ruby
+# frozen_string_literal: true
+
+# Ace Review - Automated review tool
+#
+# This executable provides review functionality for the ACE framework.
+# It supports preset-based reviews with configurable focus areas using LLM analysis.
+
+# Use absolute path resolution to support execution from any directory
+lib_path = File.expand_path("../lib", __dir__)
+$LOAD_PATH.unshift lib_path unless $LOAD_PATH.include?(lib_path)
+
+require "ace/review"
+require "ace/support/cli"
+
+# Pre-process array options before passing to ace-support-cli
+# (ace-support-cli only captures the last occurrence of --subject/--model flags)
+args = Ace::Review::CLI.preprocess_array_options(ARGV)
+args = ["--help"] if args.empty?
+
+# Start ace-support-cli single-command entrypoint with exception-based exit code handling (per ADR-023)
+begin
+  Ace::Support::Cli::Runner.new(Ace::Review::CLI::Commands::Review).call(args: args)
+rescue Ace::Support::Cli::Error => e
+  warn e.message
+  exit(e.exit_code)
+end

data/exe/ace-review-feedback

@@ -0,0 +1,17 @@
+#!/usr/bin/env ruby
+# frozen_string_literal: true
+
+require_relative "../lib/ace/review"
+require_relative "../lib/ace/review/cli/feedback_cli"
+
+# No args → show help
+args = ARGV.dup
+args = ["--help"] if args.empty?
+
+# Start ace-support-cli with exception-based exit code handling (per ADR-023)
+begin
+  Ace::Support::Cli::Runner.new(Ace::Review::FeedbackCLI).call(args: args)
+rescue Ace::Support::Cli::Error => e
+  warn e.message
+  exit(e.exit_code)
+end

data/handbook/guides/code-review-process.g.md

@@ -0,0 +1,234 @@
+---
+doc-type: guide
+title: Code Review Process
+purpose: Documentation for ace-review/handbook/guides/code-review-process.g.md
+ace-docs:
+  last-updated: 2026-01-08
+  last-checked: 2026-03-21
+---
+
+# Code Review Process
+
+## Goal
+
+This guide establishes the principles and high-level process for conducting comprehensive code reviews that cover code quality, testing, and documentation. It defines the systematic approach for ensuring code changes meet project standards and maintain consistency across all aspects of the codebase.
+
+## Overview
+
+Effective code review ensures that changes meet quality standards across multiple dimensions: code quality, test coverage, and documentation accuracy. This guide provides a systematic approach to:
+
+- Conduct comprehensive multi-focus reviews (code, tests, docs)
+- Maintain consistency between implementation and documentation
+- Apply consistent quality standards across all changes
+- Generate actionable feedback with clear priorities
+
+## Core Principles
+
+1. **Multi-Dimensional Review**: Every change should be evaluated for code quality, test impact, and documentation consistency
+2. **Systematic Analysis**: Follow a structured process to ensure comprehensive coverage
+3. **Priority-Based Action**: Not all issues are equally urgent - focus on critical items first
+4. **Evidence-Based Decisions**: Reviews should provide specific, actionable feedback with clear rationale
+
+## The Code Review Process
+
+### Review Focus Areas
+
+Code reviews should systematically evaluate three key dimensions:
+
+**Code Quality Review**
+
+- Architecture and design patterns
+- Security and performance considerations  
+- Ruby/language best practices
+- Code organization and maintainability
+
+**Testing Review**
+
+- Test coverage for new and modified functionality
+- Test quality and maintainability
+- Integration with existing test suite
+- Performance test considerations
+
+**Documentation Review**
+
+- Impact on user-facing documentation
+- Architecture decision records (ADRs)
+- Code examples and API documentation
+- Cross-reference integrity
+
+### Review Methodology
+
+**Structured Analysis**
+
+- Categorize changes by type (new features, modifications, breaking changes)
+- Assess impact across all three focus areas
+- Identify dependencies and cross-cutting concerns
+- Document architectural decisions and trade-offs
+
+**Multi-Model Approach**
+
+- Leverage multiple AI models for comprehensive analysis
+- Compare findings to identify consensus vs. unique insights
+- Synthesize results into unified recommendations
+- Validate findings against project standards
+
+### Priority Framework
+
+Organize review findings by impact and urgency:
+
+**🔴 Critical** (Must be done immediately)
+
+- Security vulnerabilities or unsafe patterns
+- Breaking changes affecting user workflows  
+- Logic errors or incorrect implementations
+
+**🟡 High Priority** (Should be done soon)
+
+- Significant architectural concerns
+- Missing test coverage for critical paths
+- User-facing documentation gaps
+
+**🟢 Medium Priority** (Should be done eventually)
+
+- Code quality improvements
+- Test maintainability enhancements
+- Documentation clarity improvements
+
+**🔵 Low Priority** (Nice to have)
+
+- Style and consistency improvements
+- Performance optimizations
+- Minor documentation updates
+
+### Implementation Approach
+
+Effective code review produces actionable outcomes:
+
+1. **Specific Feedback**: Clear identification of issues with exact locations
+2. **Rationale**: Explanation of why changes are needed
+3. **Recommendations**: Concrete suggestions for improvement
+4. **Priority Guidance**: Clear indication of what to address first
+5. **Validation Criteria**: How to verify that issues are resolved
+
+## Review Tools and Automation
+
+### Unified Review Workflow
+
+The project uses a structured review system that supports:
+
+- **Multi-focus reviews**: Code, tests, and documentation in a single workflow
+- **Flexible targets**: Git ranges, file patterns, or specific files
+- **Contextual analysis**: Automatic project context loading
+- **Multi-model execution**: Comparative analysis across different AI models
+- **Structured output**: Organized session directories with synthesis capabilities
+
+### Review Execution
+
+Reviews are executed through standardized commands that create organized sessions with input files, prompts, model reports, and synthesis results. The system handles both general code reviews and specialized handbook reviews with appropriate templates and context.
+
+## Integration with Development Workflow
+
+### Development Phases
+
+**Pre-Development**
+
+- Consider review scope and potential impact areas
+- Plan for documentation and testing requirements
+- Identify architectural decisions that will need documentation
+
+**During Implementation**
+
+- Make incremental commits that are easy to review
+- Document design decisions as they are made
+- Keep test coverage aligned with code changes
+
+**Post-Implementation**
+
+- Execute comprehensive reviews across all focus areas
+- Address critical and high-priority findings
+- Validate that all aspects meet project standards
+
+### Release Integration
+
+**Pre-Release**
+
+- Comprehensive review of all changes since last release
+- Validation of documentation accuracy and completeness
+- Synthesis of findings across multiple reviews
+
+**Release Process**
+
+- Final validation of critical issues resolution
+- Documentation of breaking changes and migration paths
+- Quality assurance checklist completion
+
+## Best Practices
+
+### Effective Review Execution
+
+- **Scope appropriately**: Focus reviews on meaningful change sets
+- **Provide context**: Include rationale for changes, not just implementation details
+- **Be systematic**: Follow consistent process across all review types
+- **Synthesize findings**: Combine multiple perspectives for comprehensive analysis
+- **Act on results**: Prioritize and address findings systematically
+
+### Review Quality
+
+- **Consistency**: Apply same standards across all changes
+- **Completeness**: Cover all relevant aspects (code, tests, docs)
+- **Actionability**: Provide specific, implementable recommendations
+- **Validation**: Verify that addressed issues are actually resolved
+
+### Process Improvement
+
+- **Learn from reviews**: Identify patterns in issues found
+- **Refine standards**: Update review criteria based on experience
+- **Automate where possible**: Leverage tools to improve efficiency
+- **Track metrics**: Monitor review effectiveness and process health
+
+## Quality Standards
+
+### Review Completeness
+
+- All critical and high-priority findings addressed
+- Code changes align with architectural standards
+- Test coverage adequate for risk level
+- Documentation accurately reflects implementation
+
+### Code Quality
+
+- Follows established patterns and conventions
+- Security considerations appropriately addressed
+- Performance implications considered
+- Maintainability and readability optimized
+
+### Testing Standards
+
+- Appropriate test coverage for change scope
+- Tests are maintainable and reliable
+- Integration with existing test suite verified
+- Edge cases and error conditions covered
+
+### Documentation Standards
+
+- User-facing changes properly documented
+- Technical decisions recorded in ADRs
+- Cross-references and examples updated
+- Migration paths provided for breaking changes
+
+## Related Resources
+
+### Implementation Workflows
+
+- [Review Code Workflow](../workflow-instructions/review-code.wf.md) - Detailed review execution process
+- [Synthesize Reviews Workflow](../workflow-instructions/synthesize-reviews.wf.md) - Multi-report analysis
+
+### Standards and Guidelines  
+
+- [Documentation Guide](./documentation.g.md) - Documentation standards and practices
+- [Quality Assurance Guide](./quality-assurance.g.md) - Overall quality standards
+- [Version Control Git Guide](./version-control-system-git.g.md) - Git workflow integration
+
+---
+
+*Effective code review is a cornerstone of software quality, ensuring that changes meet standards across code, tests, and documentation while maintaining long-term maintainability.*

data/handbook/prompts/base/sections.md

@@ -0,0 +1,23 @@
+# SECTION LIST ─ DO NOT CHANGE NAMES
+
+## 1. Executive Summary
+
+## 2. Architectural Compliance
+
+## 3. Best Practices Assessment
+
+## 4. Test Quality & Coverage
+
+## 5. Security Assessment
+
+## 6. API & Interface Review
+
+## 7. Detailed File-by-File Feedback
+
+## 8. Prioritised Action Items
+
+## 9. Performance Notes
+
+## 10. Risk Assessment
+
+## 11. Approval Recommendation

data/handbook/prompts/base/system.md

@@ -0,0 +1,60 @@
+# Code Review System Prompt Base
+
+You are a senior software engineer conducting a thorough code review.
+Your task: perform a *structured* code review on the diff (or repo snapshot) supplied by the user.
+
+## Core Review Principles
+
+Your review must be:
+1. **Constructive**: Focus on improvement, not criticism
+2. **Specific**: Provide exact locations and examples
+3. **Actionable**: Every issue should have a suggested fix
+4. **Educational**: Help the author learn best practices
+5. **Balanced**: Acknowledge both strengths and weaknesses
+
+## Review Approach
+
+- Be specific with line numbers and file references
+- Provide code examples for suggested improvements
+- Explain the "why" behind your feedback
+- Balance criticism with recognition of good work
+- Consider the PR's scope and avoid scope creep
+- Check for consistency with existing codebase patterns
+
+## Accuracy Requirements
+
+**File Presence Verification:**
+- Only flag a file as "missing" if you have evidence it was referenced but not included
+- Do not assume files are missing based on partial context
+- If uncertain about file presence, state "unable to verify" rather than claiming it's missing
+
+**Diff-Based Review:**
+- Review the *actual changed lines* in the diff, not inferred state
+- Do not assume methods still exist or don't exist without seeing the changed code
+- When a method call is in the diff, verify it's actually changed before flagging
+
+**Scope Boundaries:**
+- Changes outside the stated PR scope should be noted as "out of scope" observations, not code issues
+- Configuration file changes (e.g., provider configs, CI settings) may be intentional; note without flagging
+- Distinguish between "this is wrong" and "this is unrelated to the PR"
+
+## Severity Classification
+
+Use consistent severity levels:
+- **Critical/Blocking**: Breaks functionality, security vulnerability, data loss risk
+- **High**: Significant bugs, performance regression, missing error handling
+- **Medium**: Code quality issues, minor bugs, inconsistencies
+- **Low**: Style issues, documentation gaps, suggestions for improvement
+
+**Speculation vs Findings:**
+- "Finding": Issue verified in the actual diff code
+- "Suggestion": Improvement idea not tied to a specific bug
+- "Future consideration": Speculative improvement for later - do NOT include in action items
+
+## Output Constraints
+
+Output MUST follow the exact section order and Markdown anchors given below so that automated comparison scripts can parse it.
+If a section has nothing to report, write "*No issues found*".
+
+Tone: concise, professional, actionable.
+Assume reviewers will aggregate multiple provider outputs; avoid personal opinions or references to other models.

data/handbook/prompts/focus/architecture/atom.md

@@ -0,0 +1,30 @@
+---
+name: atom
+description: ATOM architecture compliance review focus
+last-updated: '2026-01-08'
+---
+
+# ATOM Architecture Focus
+
+## Architectural Compliance (ATOM)
+
+The project follows the ATOM architecture (Atoms → Molecules → Organisms → Ecosystem).
+
+### Review Requirements
+- Verify ATOM pattern adherence across all layers
+- Check component boundaries and responsibilities
+- Assess dependency injection and testing patterns
+- Validate separation of concerns
+- Ensure proper layering: Atoms have no dependencies, Molecules depend only on Atoms, etc.
+
+### Critical Success Factors
+- **Atoms**: Pure, stateless, single-responsibility units
+- **Molecules**: Composable business logic components
+- **Organisms**: Complex features combining molecules
+- **Ecosystem**: Application-level orchestration
+
+### Common Issues to Check
+- Atoms containing business logic (should be pure)
+- Molecules with external dependencies (should use injection)
+- Organisms directly accessing atoms (should go through molecules)
+- Circular dependencies between layers

data/handbook/prompts/focus/architecture/reflection.md

@@ -0,0 +1,60 @@
+---
+name: reflection
+description: Architecture reflection focus for pre-PR self-assessment
+last-updated: '2026-02-19'
+---
+
+# Architecture Reflection Focus
+
+## Purpose
+
+Self-assessment of implementation before PR creation. Categorize findings into actionable refactoring items vs. acceptable trade-offs.
+
+## Review Requirements
+
+### Over-Engineering Detection
+- Unnecessary abstractions (helpers/utilities for one-time operations)
+- Premature generalization (configurability nobody asked for)
+- Feature flags or backward-compatibility shims when direct changes suffice
+- Extra error handling for impossible scenarios
+- Layers of indirection that add complexity without value
+
+### Missing Abstractions
+- Repeated patterns across 3+ locations that should be extracted
+- Inline logic that belongs in a dedicated atom or molecule
+- Configuration values hardcoded in multiple places
+- Shared behavior duplicated instead of composed
+
+### ATOM Layer Compliance
+- Atoms must be pure, stateless, single-responsibility
+- Molecules compose atoms with controlled side effects
+- Organisms orchestrate molecules for business logic
+- No layer-skipping (organisms should not directly use atoms)
+- No circular dependencies between layers
+
+### Scope Discipline
+- Changes stay within the task scope (no drive-by refactoring)
+- No unrelated "improvements" bundled with the implementation
+- Comments and docstrings only where logic is non-obvious
+
+## Output Format
+
+Categorize each finding as one of:
+
+### Refactor (actionable, bounded)
+Items that should be fixed before shipping. Each must be:
+- Concrete (specific file and location)
+- Bounded (completable in a single pass)
+- Testable (won't break existing tests, or test changes are clear)
+
+### Accept (correct as-is)
+Items reviewed and confirmed appropriate:
+- Intentional trade-offs with clear reasoning
+- Patterns that match project conventions
+- Complexity justified by requirements
+
+### Skip (out of scope or too risky)
+Items identified but deferred:
+- Would require significant rework beyond task scope
+- Risk of introducing regressions outweighs benefit
+- Better addressed in a dedicated follow-up task

data/handbook/prompts/focus/frameworks/rails.md

@@ -0,0 +1,40 @@
+---
+name: rails
+description: Ruby on Rails framework review focus
+last-updated: '2026-01-08'
+---
+
+# Ruby on Rails Focus
+
+## Rails Framework Review
+
+You are reviewing Ruby on Rails application code.
+
+### Rails Best Practices
+- **MVC Pattern**: Proper separation of concerns
+- **RESTful Design**: Resource-based routing
+- **Active Record**: Query optimization and N+1 prevention
+- **Security**: CSRF, SQL injection, XSS protection
+
+### Rails-Specific Areas
+- **Controllers**: Thin controllers, proper filters
+- **Models**: Business logic, validations, callbacks
+- **Views**: Minimal logic, proper helpers
+- **Routes**: RESTful conventions, constraints
+- **Migrations**: Reversible, atomic changes
+- **Jobs**: Background processing patterns
+- **Mailers**: Email delivery and templates
+
+### Performance Considerations
+- Database query optimization
+- Caching strategies (fragment, Russian doll)
+- Asset pipeline optimization
+- Eager loading associations
+- Background job processing
+
+### Testing Approach
+- Request specs for integration
+- Model specs for business logic
+- System specs for user flows
+- Proper use of factories
+- Database cleaner strategies

data/handbook/prompts/focus/frameworks/vue-firebase.md

@@ -0,0 +1,45 @@
+---
+name: vue-firebase
+description: Vue 3 + Firebase platform review focus
+last-updated: '2026-01-08'
+---
+
+# Vue.js with Firebase Focus
+
+## Vue 3 & Firebase Platform Review
+
+You are reviewing a Vue 3 Progressive Web App using Firebase platform (Firestore, Auth, Storage).
+
+### Vue.js 3 Best Practices
+- **Component Architecture**: Composition API with `<script setup>`
+- **State Management**: Pinia/Vuex patterns
+- **Reactivity**: Efficient reactive data usage
+- **Performance**: Bundle size, lazy loading, code splitting
+
+### Firebase Integration
+- **Security Rules**: Firestore and Storage rules validation
+- **Authentication**: Auth flow implementation and security
+- **Data Modeling**: Firestore structure and query optimization
+- **Offline Support**: Data synchronization strategies
+- **Cloud Functions**: Serverless function patterns (if applicable)
+
+### PWA Compliance
+- **Service Worker**: Implementation and caching strategies
+- **App Manifest**: Configuration and icons
+- **Offline Functionality**: Coverage and fallbacks
+- **Core Web Vitals**: Performance metrics
+- **Mobile Experience**: Touch interactions and responsiveness
+
+### Component Review
+- Props and emits validation
+- Component composition and reusability
+- Event handling patterns
+- Accessibility (a11y) compliance
+- TypeScript usage (if applicable)
+
+### Security Considerations
+- XSS and CSRF protection
+- Input validation and sanitization
+- Client-side data exposure
+- API key and secret management
+- Firebase Security Rules coverage

data/handbook/prompts/focus/languages/ruby.md

@@ -0,0 +1,50 @@
+---
+name: ruby
+description: Ruby language review focus with idioms and best practices
+last-updated: '2026-01-08'
+---
+
+# Ruby Language Focus
+
+## Ruby-Specific Review Criteria
+
+You are reviewing Ruby code with expertise in Ruby best practices and idioms.
+
+### Ruby Gem Best Practices
+- Proper gem structure and organization
+- Semantic versioning compliance
+- Dependency management and version constraints
+- README and documentation standards
+
+### Code Quality Standards
+- **Style**: StandardRB compliance (note justified exceptions)
+- **Idioms**: Ruby idioms and conventions
+- **Performance**: Efficient use of Ruby features
+- **Memory**: Proper object lifecycle management
+
+### Testing with Minitest
+- Target: 90%+ test coverage
+- Test organization and naming conventions (flat structure: test/atoms/, test/molecules/)
+- Proper use of Minitest features (setup, teardown, assertions)
+- Mock and stub usage appropriateness (use stub() for thread-safe test mocking)
+
+### Ruby-Specific Checks
+- Proper use of blocks, procs, and lambdas
+- Metaprogramming appropriateness
+- Module and class design
+- Exception handling patterns
+- String interpolation vs concatenation
+- Symbol vs string usage
+- Enumerable method selection
+- Proper use of attr_accessor/reader/writer
+
+### Ruby 3+ Features
+Review for appropriate use of modern Ruby features:
+- **Pattern Matching** (`case...in`): Prefer for complex destructuring, avoid for simple conditionals
+- **Endless Methods** (`def method = expr`): Use for single-expression methods, keep readable
+- **Numbered Block Parameters** (`_1`, `_2`): Use only for simple, short blocks
+- **Hash Shorthand** (`{x:, y:}`): Use when variable name matches key name
+- **Rightward Assignment** (`expr => var`): Use sparingly for destructuring results
+- **Data Classes** (`Data.define`): Prefer over Struct for immutable value objects (requires Ruby 3.2+; project uses 3.4+)
+- **Keyword Argument Forwarding** (`def foo(**) = bar(**)`)
+- **Ractor**: Review thread-safety implications when used