mirror of
https://github.com/garrytan/gstack.git
synced 2026-05-01 19:25:10 +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>
50 lines
2.3 KiB
Markdown
50 lines
2.3 KiB
Markdown
# API Contract Specialist Review Checklist
|
|
|
|
Scope: When SCOPE_API=true
|
|
Output: JSON objects, one finding per line. Schema:
|
|
{"severity":"CRITICAL|INFORMATIONAL","confidence":N,"path":"file","line":N,"category":"api-contract","summary":"...","fix":"...","fingerprint":"path:line:api-contract","specialist":"api-contract"}
|
|
Optional: line, fix, fingerprint, evidence, test_stub.
|
|
If no findings: output `NO FINDINGS` and nothing else.
|
|
|
|
---
|
|
|
|
## Categories
|
|
|
|
### Breaking Changes
|
|
- Removed fields from response bodies (clients may depend on them)
|
|
- Changed field types (string → number, object → array)
|
|
- New required parameters added to existing endpoints
|
|
- Changed HTTP methods (GET → POST) or status codes (200 → 201)
|
|
- Renamed endpoints without maintaining the old path as a redirect/alias
|
|
- Changed authentication requirements (public → authenticated)
|
|
|
|
### Versioning Strategy
|
|
- Breaking changes made without a version bump (v1 → v2)
|
|
- Multiple versioning strategies mixed in the same API (URL vs header vs query param)
|
|
- Deprecated endpoints without a sunset timeline or migration guide
|
|
- Version-specific logic scattered across controllers instead of centralized
|
|
|
|
### Error Response Consistency
|
|
- New endpoints returning different error formats than existing ones
|
|
- Error responses missing standard fields (error code, message, details)
|
|
- HTTP status codes that don't match the error type (200 for errors, 500 for validation)
|
|
- Error messages that leak internal implementation details (stack traces, SQL)
|
|
|
|
### Rate Limiting & Pagination
|
|
- New endpoints missing rate limiting when similar endpoints have it
|
|
- Pagination changes (offset → cursor) without backwards compatibility
|
|
- Changed page sizes or default limits without documentation
|
|
- Missing total count or next-page indicators in paginated responses
|
|
|
|
### Documentation Drift
|
|
- OpenAPI/Swagger spec not updated to match new endpoints or changed params
|
|
- README or API docs describing old behavior after changes
|
|
- Example requests/responses that no longer work
|
|
- Missing documentation for new endpoints or changed parameters
|
|
|
|
### Backwards Compatibility
|
|
- Clients on older versions: will they break?
|
|
- Mobile apps that can't force-update: does the API still work for them?
|
|
- Webhook payloads changed without notifying subscribers
|
|
- SDK or client library changes needed to use new features
|