157dbbb9eb
## Phase 8: Enterprise Extractor Improvements ✅ - 14 security extractors (TLS, JWT, SQL injection, XSS, etc.) - 10 framework-specific extractors (Spring, Django, Rails, etc.) - Config file security detection (YAML, TOML) ## Phase 9: Autonomous Extractor Generation ✅ - Shadow mode executor with TP/FP tracking - Graduation pipeline with confidence thresholds - Auto-rollback on regression detection - Cross-project pattern syncing ## UAT Suite Complete (14 scripts, 90 tests) - test-core-detection.sh (6 tests) - test-declarative-extractors.sh (5 tests) - test-domain-frameworks.sh (5 tests) - test-domain-unreal.sh (3 tests) - test-llm-extraction.sh (6 tests) - test-eval-harness.sh (5 tests) - test-cross-language.sh (3 tests) - test-precommit-performance.sh (4 tests) - test-output-formats.sh (8 tests) - test-drift-detection.sh (6 tests) - test-exit-codes.sh (12 tests) + 3 more scripts ## Other Changes - Updated roadmap to mark Phase 8-9 complete - Added .gitignore entries for build artifacts - Updated pre-commit: 800 line limit, exclude tests/data/cmd Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
50 lines
1.8 KiB
Markdown
50 lines
1.8 KiB
Markdown
# aphoria-code-patterns
|
|
|
|
## AUDIT (2026-02-06)
|
|
|
|
### Pattern 1: Unwrap/Expect Isolation
|
|
**Finding:** NOT APPLICABLE
|
|
|
|
- **Total unwrap() calls:** 72
|
|
- **Total expect() calls:** 890 (mostly from stemedb crates, not aphoria)
|
|
- **In test code:** ALL 72 unwrap() calls are within `#[test]` functions
|
|
- **In production code:** 0
|
|
|
|
Analysis:
|
|
- `promotion/version.rs:490` - test function `test_changelog_entry_with_metrics`
|
|
- `research/gap_store.rs:365-390` - test functions `test_gap_store_*`
|
|
- `research/tests.rs` - all test code
|
|
- `types/language.rs:220-230` - test assertions
|
|
|
|
**Decision:** No fix needed. Clippy's `clippy::unwrap_used` is at `warn` level for crates, but test code is exempt by design. All 72 instances are in test functions where unwrap is acceptable for test assertions.
|
|
|
|
### Pattern 2: JSON Construction Consistency
|
|
**Finding:** 27 instances of `serde_json::json!` macro
|
|
|
|
**Categories:**
|
|
|
|
1. **Source metadata construction (5 files):**
|
|
- `bridge.rs:52` - claim_to_assertion
|
|
- `episteme/corpus.rs:191` - corpus building
|
|
- `llm/extractor.rs:431` - LLM extraction
|
|
- `llm/prompt.rs:97` - prompt building
|
|
- `llm/ontology.rs:243` - ontology extraction
|
|
|
|
2. **Report generation (10 instances):**
|
|
- `report/sarif.rs` - 5 instances (SARIF format requires specific structure)
|
|
- `report/json.rs` - 5 instances (dynamic conflict reports)
|
|
|
|
3. **Other (7 instances):**
|
|
- `policy_ops.rs:238` - ack payload (recent addition)
|
|
- `report/mod.rs:56` - single value conversion
|
|
- `eval/matcher.rs:328` - test fixture
|
|
- `eval/harness.rs` - 4 test fixtures
|
|
|
|
**Analysis:**
|
|
The `json!` macro is used appropriately for:
|
|
- Dynamic JSON construction where struct serialization doesn't apply
|
|
- SARIF format which has strict schema requirements
|
|
- Test fixtures where convenience matters
|
|
|
|
This is NOT tech debt - it's appropriate usage. The audit finding was overly aggressive.
|