tidaldb/.sdlc/features/m10-signal-revocation-controls/qa-results.md

46 lines
1.8 KiB
Markdown

# QA Results: Signal Revocation Controls
## Test Execution Summary
| Suite | Tests | Result |
|---|---|---|
| `cargo test --lib` | 1355 | PASS |
| `tests/m10_revocation.rs` | 10 | PASS |
| `tests/m10_community_policy.rs` | 10 | PASS |
| `tests/m9_leave_revocation.rs` | 7 | PASS |
**Total: 1355 lib + 27 integration tests, all passing. Zero failures.**
## Static Analysis
- `cargo clippy -- -D warnings`: clean (fixed two `assigning_clones` and `const_fn` warnings in `schema/validation/builders/mod.rs`)
- `cargo fmt --check`: clean
## QA Plan Coverage
| Scenario | Test | Result |
|---|---|---|
| QA-1: SignalType revocation suppresses sort score | R1 | PASS |
| QA-2: TimeRange revocation suppresses in-window signals | R2 | PASS |
| QA-3: Cancel revocation restores ranking | R3 | PASS |
| QA-4: Non-revoked signal types unaffected | R4 | PASS |
| QA-5: List includes active + cancelled | R5 | PASS |
| QA-6: User isolation — revocation scoped to one user | R6 | PASS |
| QA-7: Multiple overlapping revocations (union) | R7 | PASS |
| QA-8: Durability across DB reopen | R8 | PASS |
| QA-9: Cancellation durability | R9 | PASS |
| QA-10: Anonymous query bypass | R10 | PASS |
## Regression Check
No regressions in M9 or M10 community policy suites. The revocation wiring in `ProfileExecutor` and `RetrieveExecutor` is opt-in (both `revocation_index` and `for_user_revocation` must be set) — existing code paths that don't wire revocations are unaffected.
## Performance
- Fast path (no user revocations): single DashMap miss in `RevocationIndex::is_suppressed`, effectively O(1).
- Slow path (R active revocations): O(R) linear scan per signal per entity. At R=5 and typical candidate set sizes, this is within the latency budget with no measurable impact on existing benchmarks.
## Verdict
**PASSED.** Feature is complete, correct, and regression-free.