specflow-cc 1.5.1 → 1.5.3

package/CHANGELOG.md

@@ -5,6 +5,27 @@ All notable changes to SpecFlow will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.5.3] - 2026-01-22
+
+### Changed
+
+- `spec-auditor` now checks 8 quality dimensions (added: architecture fit, non-duplication, cognitive load)
+- `impl-reviewer` now checks 8 quality dimensions (added: architecture, non-duplication, cognitive load)
+- Enhanced integration checks for natural codebase fit
+- Reviewers verify code doesn't reinvent existing solutions
+- Both agents evaluate maintainability and developer experience
+
+---
+
+## [1.5.2] - 2026-01-22
+
+### Fixed
+
+- `/sf:review` now offers `/sf:fix` option when APPROVED with minor issues
+- impl-reviewer agent output distinguishes "no issues" vs "with minor issues"
+
+---
+
 ## [1.5.1] - 2026-01-22
 
 ### Added

package/agents/impl-reviewer.md

@@ -49,9 +49,12 @@ You audit with NO knowledge of HOW the code was written. This ensures:
 
 1. **Compliance:** Does it meet the specification?
 2. **Quality:** Is the code clean and maintainable?
-3. **Integration:** Does it fit the existing codebase?
+3. **Integration:** Does it fit naturally with existing codebase?
 4. **Security:** Are there vulnerabilities?
 5. **Completeness:** Are all files/deletions handled?
+6. **Architecture:** Does it follow established patterns?
+7. **Non-duplication:** Does it reuse existing solutions where appropriate?
+8. **Cognitive load:** Is it easy for other developers to understand?
 
 </philosophy>
 
@@ -121,8 +124,29 @@ For each created/modified file:
 ### 4.4 Integration Check
 
 - [ ] Matches existing code style
-- [ ] Uses existing utilities (no reinventing)
 - [ ] Proper imports/exports
+- [ ] Fits naturally with surrounding code
+
+### 4.5 Architecture Check
+
+- [ ] Follows established patterns from PROJECT.md
+- [ ] No conflicting architectural decisions
+- [ ] Proper separation of concerns
+- [ ] Dependencies flow in correct direction
+
+### 4.6 Non-Duplication Check
+
+- [ ] Uses existing utilities/helpers (no reinventing)
+- [ ] No copy-paste of existing code that could be reused
+- [ ] Leverages existing abstractions where appropriate
+
+### 4.7 Cognitive Load Check
+
+- [ ] Code is as simple as possible for the task
+- [ ] Naming is clear and consistent with codebase
+- [ ] No unnecessary abstractions or indirection
+- [ ] Logic flow is easy to follow
+- [ ] Future maintainers can understand without extensive context
 
 ## Step 5: Categorize Findings
 
@@ -246,9 +270,16 @@ Return review result:
 
 ## Next Step
 
-{If APPROVED:} `/sf:done` — finalize and archive
+{If APPROVED with NO minor issues:}
+`/sf:done` — finalize and archive
 
-{If CHANGES_REQUESTED:} `/sf:fix` — address issues
+{If APPROVED WITH minor issues:}
+Choose one:
+• `/sf:done` — finalize as-is (minor issues are optional)
+• `/sf:fix` — address minor issues first
+
+{If CHANGES_REQUESTED:}
+`/sf:fix` — address issues
 
 Options:
 - `/sf:fix all` — apply all fixes
@@ -265,6 +296,9 @@ Options:
 - [ ] No lingering references to deleted code
 - [ ] Code quality evaluated
 - [ ] Security checked
+- [ ] Architecture alignment verified
+- [ ] No unnecessary duplication
+- [ ] Cognitive load acceptable
 - [ ] Findings categorized
 - [ ] Review recorded in spec
 - [ ] STATE.md updated

package/agents/spec-auditor.md

@@ -45,6 +45,9 @@ You are intentionally given NO context about how the spec was created. This ensu
 3. **Testability:** Can each criterion be verified?
 4. **Scope:** Is the boundary clear?
 5. **Feasibility:** Is this achievable as specified?
+6. **Architecture fit:** Does approach align with existing codebase patterns?
+7. **Non-duplication:** Does this avoid reinventing existing solutions?
+8. **Cognitive load:** Will this be easy for developers to understand and maintain?
 
 </philosophy>
 
@@ -94,6 +97,23 @@ Evaluate each dimension:
 - [ ] Assumptions are reasonable
 - [ ] No impossible requirements
 
+### Architecture Fit Check
+- [ ] Approach aligns with existing codebase patterns
+- [ ] Uses established conventions from PROJECT.md
+- [ ] Integrates naturally with existing modules
+- [ ] Doesn't introduce conflicting patterns
+
+### Non-Duplication Check
+- [ ] Doesn't duplicate existing functionality in codebase
+- [ ] Reuses existing utilities/helpers where appropriate
+- [ ] No "reinventing the wheel" when solution exists
+
+### Cognitive Load Check
+- [ ] Solution is as simple as possible for the task
+- [ ] Naming is clear and consistent with codebase
+- [ ] No unnecessary abstractions or indirection
+- [ ] Future maintainers can understand the approach
+
 ## Step 4: Categorize Issues
 
 Separate findings into:
@@ -188,7 +208,7 @@ Return formatted audit result:
 <success_criteria>
 - [ ] Specification fully read
 - [ ] PROJECT.md context loaded
-- [ ] All 5 dimensions evaluated
+- [ ] All 8 dimensions evaluated (clarity, completeness, testability, scope, feasibility, architecture, duplication, cognitive load)
 - [ ] Issues categorized (critical vs recommendations)
 - [ ] Audit recorded in spec's Audit History
 - [ ] STATE.md updated

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specflow-cc",
-  "version": "1.5.1",
+  "version": "1.5.3",
   "description": "Spec-driven development system for Claude Code — quality-first workflow with explicit audit cycles",
   "bin": {
     "specflow-cc": "bin/install.js"