Skip to content

chore(deps): bump docker/setup-buildx-action from 3.11.1 to 3.12.0 #807

chore(deps): bump docker/setup-buildx-action from 3.11.1 to 3.12.0

chore(deps): bump docker/setup-buildx-action from 3.11.1 to 3.12.0 #807

name: "+ Claude Code / Automation / PR Review"
on:
pull_request:
types: [opened, reopened, synchronize, ready_for_review, labeled]
workflow_dispatch:
concurrency:
group: ${{ github.workflow }}-${{ github.ref_name }}-${{ github.event.pull_request.number || github.sha }}
cancel-in-progress: true
jobs:
claude-review:
if: |
contains(github.event.pull_request.labels.*.name, 'claude') ||
github.event.action == 'ready_for_review'
uses: ./.github/workflows/_claude-code.yml
with:
mode: 'automation'
allowed_tools: 'mcp__github_inline_comment__create_inline_comment,Read,Write,Edit,MultiEdit,Glob,Grep,LS,WebFetch,WebSearch,Bash(git:*),Bash(bun:*),Bash(npm:*),Bash(npx:*),Bash(gh:*),Bash(uv:*),Bash(make:*)'
track_progress: ${{ github.event_name == 'pull_request' && contains(fromJSON('["opened", "synchronize", "ready_for_review", "reopened"]'), github.event.action) }}
use_sticky_comment: true
prompt: |
# PR REVIEW FOR AIGNOSTICS PYTHON SDK
**REPO**: ${{ github.repository }}
**PR**: #${{ github.event.pull_request.number }}
**BRANCH**: ${{ github.head_ref }}
## Context
This is a **medical device software SDK** for computational pathology. You are reviewing code that:
- Processes whole slide images (WSI) - gigapixel medical images
- Integrates with FDA/MDR regulated AI/ML applications
- Handles sensitive medical data (HIPAA compliance required)
- Follows a **modulith architecture** with strict module boundaries
## Documentation References
**IMPORTANT**: This repository has comprehensive documentation you MUST reference:
- **CLAUDE.md** (root) - Architecture, testing workflow, development standards
- **.github/CLAUDE.md** - Complete CI/CD guide (19 workflows, test strategy)
- **src/aignostics/*/CLAUDE.md** - Module-specific implementation guides
Read these files and apply their guidance throughout your review.
## CRITICAL CHECKS (BLOCKING - Must Pass)
### 1. Test Markers (CRITICAL!)
**EVERY test MUST have at least one marker: `unit`, `integration`, or `e2e`**
Tests without these markers will **NOT run in CI** because the pipeline explicitly filters by markers.
```bash
# Find unmarked tests (should return 0 tests):
uv run pytest -m "not unit and not integration and not e2e" --collect-only
# If unmarked tests found, check the specific files changed in this PR:
uv run pytest tests/aignostics/<module>/<file>_test.py --collect-only
```
**Action if violations found**:
- List all test files missing markers with file paths and line numbers
- Provide exact decorator to add (e.g., `@pytest.mark.unit`)
- Reference `.github/CLAUDE.md` test categorization guide
### 2. Test Coverage (85% Minimum)
If coverage drops below 85%, identify which new code lacks tests.
### 3. Code Quality (Must Pass)
```bash
# Check linting:
make lint
# Runs: ruff format, ruff check, pyright (basic), mypy (strict)
```
All 4 checks must pass. If failures occur, provide specific fixes.
### 4. Conventional Commits
All commits must follow: `type(scope): description`
Valid types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`, `ci`, `perf`, `build`
```bash
# Check commit messages:
git log --oneline origin/main..HEAD
```
## Repository-Specific Review Areas
### 5. Architecture Compliance
**Modulith Principles**:
- Each module is self-contained (Service + optional CLI + optional GUI)
- **CRITICAL**: CLI and GUI must NEVER depend on each other
- Both depend on Service layer only
- No circular dependencies between modules
**Service Pattern**:
- All services inherit from `BaseService` (from `utils`)
- Must implement `health()` → `Health` and `info()` → `dict`
- Use dependency injection via `locate_implementations(BaseService)`
- No decorator-based DI
**Check**:
```bash
# Find all service implementations:
grep -r "class.*Service.*BaseService" src/aignostics/
# Check for circular imports:
# Look for cross-module imports that shouldn't exist
```
### 6. Testing Strategy
**Test Categories** (see `.github/CLAUDE.md` for full details):
- `unit`: Isolated, no external deps, <10s timeout, sequential (XDIST_WORKER_FACTOR=0.0)
- `integration`: Mocked external services, <5min, limited parallel (0.2)
- `e2e`: Real API calls, staging environment, full parallel (1.0)
- `long_running`: E2E tests ≥5min, aggressive parallel (2.0), opt-out with label
- `very_long_running`: E2E tests ≥60min, only run when explicitly enabled
**For new tests, verify**:
- Correct marker applied based on test characteristics
- Timeout set if >10s (use `@pytest.mark.timeout(60)`)
- E2E tests only run against staging (never production in PR CI)
### 7. Medical Device & Security
**Check for**:
- Secrets/tokens in code or commits (use .env, never hardcode)
- Sensitive data masking in logs (use `mask_secrets=True`)
- Medical data handling (DICOM compliance, proper anonymization)
- OAuth token management (refresh before 5min expiry)
**WSI Processing**:
- Large images processed in tiles (never load full image in memory)
- Proper cleanup of temp files
- Progress tracking for long operations
### 8. Breaking Changes
**Check if PR introduces**:
- API client method signature changes
- CLI command changes (breaking user scripts)
- Environment variable changes
- Configuration file format changes
- OpenAPI model changes (from codegen)
If breaking changes detected, verify:
- Proper deprecation warnings added
- Migration guide in PR description
- Version bump appropriate (major vs minor)
### 9. CI/CD Impact
**If workflow files changed** (`.github/workflows/*.yml`):
- Verify syntax is correct
- Check reusable workflow inputs/secrets match
- Validate test marker filtering logic
- Ensure BetterStack heartbeats still work
**If new tests added**:
- Are they categorized correctly for CI execution?
- Do they need to be scheduled tests?
- Is XDIST_WORKER_FACTOR appropriate?
### 10. Documentation Updates
**If new features added**:
- Is CLAUDE.md updated? (root or module-specific)
- Are docstrings added (Google style)?
- Is README updated if user-facing change?
- Are type hints complete?
## Code Quality Standards
- **Type Checking**: Dual checking (MyPy strict + PyRight basic) - both must pass
- **Line Length**: 120 chars max
- **Imports**: stdlib → 3rd-party → local, use relative imports within modules
- **Docstrings**: Google style for all public APIs
- **Error Handling**: Custom exceptions from `system/_exceptions.py`
- **Logging**: Structured logging via `get_logger(__name__)`
## Review Output Format
For each issue found, provide:
1. **Location**: `file_path:line_number` (e.g., `src/aignostics/platform/_client.py:123`)
2. **Issue**: Clear description with reference to CLAUDE.md section
3. **Reproduce**: Exact command to reproduce (e.g., `uv run pytest tests/...`)
4. **Fix**: Concrete code example or command
5. **Verify**: Command to verify fix works (e.g., `make lint && make test`)
**Use inline comments** for specific code issues.
**Use PR-level comment** for:
- Summary of findings (blocking vs suggestions)
- Overall architecture feedback
- Praise for excellent work
- Missing CLAUDE.md updates needed
## Final Steps
After completing your review:
1. **Summarize findings** in PR comment using `gh pr comment`
2. **Categorize issues**: Blocking (must fix) vs Suggestions (nice to have)
3. **Provide commands** to fix all blocking issues in one go if possible
4. **Reference documentation**: Link to relevant CLAUDE.md sections
Use `gh pr comment` with your Bash tool to leave your comprehensive review as a comment on the PR.
---
**Remember**: This is medical device software. Insist on highest standards. Be thorough, actionable, and kind.
secrets:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}