## Problem CLI-created community corpus items (tier 3) were stored correctly but invisible via API queries. Two issues blocked discoverability: 1. **Prefix mismatch**: API hardcoded 'community://pattern/' for aggregated patterns, but CLI creates 'community://rust/http/...' URIs 2. **Query parameter parsing**: Axum's default parser doesn't support bracket notation (?sources[]=value) used by the dashboard Result: 0/22 CLI-created items were queryable. ## Solution ### Fix 1: Broaden Community Prefix - Changed: 'community://pattern/' → 'community://' in corpus handler - Impact: Now matches both aggregated patterns AND CLI-created items - Backward compatible: Broader prefix includes narrower results ### Fix 2: Add QsQuery Extractor - Added: serde_qs dependency + custom QsQuery extractor - Supports: Bracket notation for array parameters (?sources[]=a&sources[]=b) - Compatible: Works with JavaScript URLSearchParams standard - Tested: 3 new unit tests for extractor behavior ## Verification - ✅ All 22 CLI-created community items now queryable (was 0) - ✅ Source filtering works: community (22), RFC (2), vendor (5) - ✅ Multi-source queries work: ?sources[]=community&sources[]=rfc → 24 - ✅ All 89 API tests pass + 3 new extractor tests - ✅ Clippy clean (0 warnings) - ✅ No regressions in existing functionality ## Files Changed - crates/stemedb-api/Cargo.toml: Add serde_qs dependency - crates/stemedb-api/src/extractors.rs: New QsQuery extractor (117 lines) - crates/stemedb-api/src/handlers/aphoria/corpus.rs: Use QsQuery, broaden prefix - crates/stemedb-api/src/lib.rs: Export extractors module Also includes: Scale-adaptive thresholds, wiki corpus extraction, documentation updates, and dashboard UI improvements from prior work. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
7.4 KiB
7.4 KiB
Documentation Audit Summary: Corpus Endpoint & Multi-Project Architecture
Date: 2026-02-09 Trigger: Implemented Phase 1-3 (corpus endpoint, per-project databases, corpus database) Files Analyzed: 39 markdown files, 12,104 total lines
Changes Implemented
Code Changes (Already Complete)
- ✅ Phase 1:
/v1/aphoria/corpusendpoint (returns RFC/OWASP/Community best practices) - ✅ Phase 2: Per-project database default (
.aphoria/dbinstead of~/.aphoria/db) - ✅ Phase 3: Corpus database architecture (
~/.aphoria/corpus-dbfor aggregated patterns)
Documentation Updates (This Session)
UPDATED Files
-
guides/the-first-scan.md:45✅- Before:
~/.aphoria/db(stale path) - After:
.aphoria/db+ note about override for shared mode - Impact: Users no longer misled about default database location
- Before:
-
cli-reference.md✅- Added: Database architecture explanation in
aphoria initsection - Added: Configuration section at end with quick example
- Added: Link to new
configuration.md - Impact: Users can discover configuration options
- Added: Database architecture explanation in
CREATED Files
configuration.md✅ (NEW - 397 lines)- Purpose: Complete
aphoria.tomlreference - Sections:
- Database configuration (per-project vs shared)
- All config sections with examples
- Environment variables
- Migration guide from legacy home-based database
- Impact: Canonical configuration documentation
- Purpose: Complete
Issues Found
High Priority (Fixed)
- ✅ Stale database path in
the-first-scan.md- Fixed - ✅ Missing configuration docs - Created
configuration.md - ✅ No CLI reference link to config - Added
Medium Priority (Deferred)
-
⚠️ Dashboard references (6 mentions in
phase-17-summary.md)- Status: Dashboard exists but not documented as user-facing feature
- Decision Needed: Is dashboard production-ready for user docs?
- Recommendation: Add to CLI reference when ready, or mark as "internal/beta"
-
⚠️ Multi-project architecture guide (not created yet)
- Status: Configuration explains database paths, but no dedicated architecture guide
- Decision Needed: Is a separate guide needed, or is
configuration.mdsufficient? - Recommendation: Defer until users ask for it (YAGNI)
Low Priority (No Action)
- No stale planning docs found - All planning docs appear current or properly archived
- No duplicate content detected - "Claims vs Observations" appears once (README.md)
- No old terminology - No references to deprecated terms found
Verification
Examples Tested
✅ All bash examples in updated docs tested:
aphoria init # ✓ Creates .aphoria/db/ by default
aphoria scan . # ✓ Works
aphoria claims create # ✓ Works
Cross-Links Verified
✅ All new cross-links resolve:
cli-reference.md→configuration.md✓the-first-scan.mdreferences correct path ✓configuration.md→cli-reference.md,scale-adaptive-thresholds.md, etc. ✓
Terminology Check
✅ No old terminology found:
! grep -r "~/.aphoria/db" applications/aphoria/docs/guides/*.md
# Only 1 reference in the-first-scan.md (correctly documented as override)
Files Modified
Updated (3 files)
applications/aphoria/docs/guides/the-first-scan.md(+2 lines)applications/aphoria/docs/cli-reference.md(+19 lines)
Created (2 files)
applications/aphoria/docs/configuration.md(+397 lines, NEW)applications/aphoria/docs/DOC-UPDATE-2026-02-09.md(audit plan, reference only)
Total Impact
- Lines added: 418 lines
- Stale references fixed: 1
- New canonical documentation: 1 (configuration.md)
Outstanding Decisions
1. Dashboard Documentation
Question: Should we create guides/dashboard-setup.md?
Options:
- A. Yes - If dashboard is user-facing and production-ready
- B. Add brief section to CLI reference - If dashboard is beta/internal
- C. No - If dashboard is for developers only
Current State: Dashboard is mentioned in implementation docs but not user guides.
Recommendation: Option B - Add brief section to CLI reference:
## Dashboard (Beta)
Start the Aphoria dashboard:
```bash
cd applications/aphoria-dashboard
npm install
npm run dev
Note: Dashboard is in beta. For production use, query via API.
### 2. Multi-Project Architecture Guide
**Question:** Do we need a dedicated guide explaining dual-database architecture?
**Options:**
- **A. Yes** - Create `guides/multi-project-architecture.md`
- **B. No** - `configuration.md` already explains database paths
**Current State:** Configuration guide covers database paths with examples.
**Recommendation:** Option B (YAGNI) - Only create if users request it. Current docs are sufficient.
### 3. Migration Guide
**Question:** Do we need a migration guide for upgrading from old `~/.aphoria/db`?
**Options:**
- **A. Yes** - Create migration guide
- **B. No** - Users can override via config
**Current State:** `configuration.md` includes "Migration Guide" section explaining override.
**Recommendation:** Option B - Current approach (override via config) is simple and documented.
---
## Quality Metrics
### Before
- Stale references: 1 (database path in `the-first-scan.md`)
- Configuration coverage: Partial (scattered across CLI reference)
- Cross-references: Some broken (config not documented)
### After
- Stale references: 0 ✅
- Configuration coverage: Complete (dedicated `configuration.md`) ✅
- Cross-references: All working ✅
### Coverage
- Database architecture: **100%** (configuration.md, cli-reference.md, the-first-scan.md)
- Corpus endpoint: **0%** (API-only, not user-facing yet)
- Multi-project workflows: **50%** (config explains, no workflow guide)
---
## Next Steps
### Immediate (Complete)
- ✅ Fix stale database path
- ✅ Create configuration reference
- ✅ Update CLI reference with config section
### Follow-Up (When Dashboard Ready)
- [ ] Decide on dashboard documentation strategy (user-facing vs internal)
- [ ] Add dashboard section to CLI reference (if beta) or create guide (if production)
### Future (As Needed)
- [ ] Consider `guides/multi-project-architecture.md` if users request workflow examples
- [ ] Update when `/v1/aphoria/corpus` becomes user-facing (CLI wrapper or dashboard integration)
---
## Testing Checklist
Completed:
- ✅ All bash examples tested and working
- ✅ Cross-links verified (configuration.md ↔ cli-reference.md)
- ✅ No old terminology (`~/.aphoria/db` only mentioned as override)
- ✅ Examples match current CLI output
- ✅ Configuration options match code (verified against `config/defaults.rs`)
---
## Conclusion
**Documentation is now aligned with Phase 1-3 implementation.**
Key improvements:
1. ✅ Stale database path fixed (users won't be confused)
2. ✅ Complete configuration reference created (canonical source)
3. ✅ CLI reference updated to guide users to config docs
**No regressions detected:**
- All existing docs still accurate
- No broken cross-links introduced
- No old terminology found
**Outstanding work is low-priority:**
- Dashboard docs (when ready)
- Multi-project architecture guide (if requested)
The documentation now correctly reflects the new per-project database architecture and provides clear guidance for users who need to customize it.