mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-02 03:35:09 +02:00
Garry Tan
9ca8f1d7a9
* feat: add test_stub optional field to specialist finding schema All specialist prompts now document test_stub as an optional output field, enabling specialists to suggest test code alongside findings. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: adaptive gating + test framework detection for review army Adds gstack-specialist-stats binary for tracking specialist hit rates. Resolver now detects test framework for test_stub generation, applies adaptive gating to skip silent specialists, and compiles per-specialist stats for the review-log entry. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: cross-review finding dedup + test stub override + enriched review-log Step 5.0 suppresses findings previously skipped by the user when the relevant code hasn't changed. Test stub findings force ASK classification so users approve test creation. Review-log now includes quality_score, per-specialist stats, and per-finding action records. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: bump version and changelog (v0.15.2.0) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * fix: bash operator precedence in test framework detection [ -f a ] || [ -f b ] && X="y" evaluates as A || (B && C), so the assignment only runs when the second test passes. Wrap the OR group in braces: { [ -f a ] || [ -f b ]; } && X="y". Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
47 lines
2.3 KiB
Markdown
47 lines
2.3 KiB
Markdown
# Maintainability Specialist Review Checklist
|
|
|
|
Scope: Always-on (every review)
|
|
Output: JSON objects, one finding per line. Schema:
|
|
{"severity":"INFORMATIONAL","confidence":N,"path":"file","line":N,"category":"maintainability","summary":"...","fix":"...","fingerprint":"path:line:maintainability","specialist":"maintainability"}
|
|
Optional: line, fix, fingerprint, evidence, test_stub.
|
|
If no findings: output `NO FINDINGS` and nothing else.
|
|
|
|
---
|
|
|
|
## Categories
|
|
|
|
### Dead Code & Unused Imports
|
|
- Variables assigned but never read in the changed files
|
|
- Functions/methods defined but never called (check with Grep across the repo)
|
|
- Imports/requires that are no longer referenced after the change
|
|
- Commented-out code blocks (either remove or explain why they exist)
|
|
|
|
### Magic Numbers & String Coupling
|
|
- Bare numeric literals used in logic (thresholds, limits, retry counts) — should be named constants
|
|
- Error message strings used as query filters or conditionals elsewhere
|
|
- Hardcoded URLs, ports, or hostnames that should be config
|
|
- Duplicated literal values across multiple files
|
|
|
|
### Stale Comments & Docstrings
|
|
- Comments that describe old behavior after the code was changed in this diff
|
|
- TODO/FIXME comments that reference completed work
|
|
- Docstrings with parameter lists that don't match the current function signature
|
|
- ASCII diagrams in comments that no longer match the code flow
|
|
|
|
### DRY Violations
|
|
- Similar code blocks (3+ lines) appearing multiple times within the diff
|
|
- Copy-paste patterns where a shared helper would be cleaner
|
|
- Configuration or setup logic duplicated across test files
|
|
- Repeated conditional chains that could be a lookup table or map
|
|
|
|
### Conditional Side Effects
|
|
- Code paths that branch on a condition but forget a side effect on one branch
|
|
- Log messages that claim an action happened but the action was conditionally skipped
|
|
- State transitions where one branch updates related records but the other doesn't
|
|
- Event emissions that only fire on the happy path, missing error/edge paths
|
|
|
|
### Module Boundary Violations
|
|
- Reaching into another module's internal implementation (accessing private-by-convention methods)
|
|
- Direct database queries in controllers/views that should go through a service/model
|
|
- Tight coupling between components that should communicate through interfaces
|