Fix QA validation issues and add M7.1 security fixes (#318)

Co-authored-by: Jason Woltje <jason@diversecanvas.com>
Co-committed-by: Jason Woltje <jason@diversecanvas.com>

docs/scratchpads/280-encryption-key-logging.md

@@ -0,0 +1,63 @@
+# Issue #280: Prevent encryption key exposure via logging
+
+## Objective
+
+Ensure encryption key validation errors don't expose the key value in error messages or logs. Prevent complete compromise of federation security.
+
+## Security Impact
+
+- Key exposure leads to ability to decrypt all private keys
+- Complete compromise of federation security
+- Attacker gains access to all federated communications
+
+## Location
+
+`apps/api/src/federation/crypto.service.ts:17-30`
+
+## Approach
+
+1. Write tests that verify error messages don't contain key material
+2. Update validation logic to not include key in error messages
+3. Ensure structured logging masks sensitive data
+4. Add tests for various invalid key scenarios
+
+## Implementation Plan
+
+- [x] Write tests for key validation errors (RED)
+- [x] Update error messages to remove key exposure (GREEN)
+- [x] Verify no key material in logs
+- [x] Run quality gates
+- [x] Commit and push
+- [x] Close issue
+
+## Results
+
+**Status:** ✅ COMPLETE
+
+**Commit:** 9caaf91
+
+**Test Coverage:**
+
+- 18 tests covering all encryption/decryption scenarios
+- Tests verify error messages don't expose key values
+- Tests cover various invalid key formats
+
+**Security Improvements:**
+
+- Removed error object from logger calls to prevent stack trace leakage
+- Generic error messages without sensitive details
+- All crypto operations now safely log errors
+
+## Testing
+
+- Invalid key format (wrong length)
+- Non-hex characters in key
+- Empty key
+- Verify error messages are generic
+- Verify no key material in logs
+
+## Notes
+
+- Current error message includes key via template literal
+- Need to sanitize all error paths
+- Consider using a constant error message

docs/scratchpads/281-fix-broad-exception-catching.md

@@ -0,0 +1,59 @@
+# Issue #281: Fix broad exception catching hiding system errors
+
+## Objective
+
+Fix broad try-catch blocks in command.service.ts that catch ALL errors including system failures (OOM, DB failures, etc.), making debugging impossible.
+
+## Location
+
+apps/api/src/federation/command.service.ts:168-194
+
+## Problem
+
+The current implementation catches all errors in a broad try-catch block, which masks critical system errors as business logic failures. This makes debugging impossible and can hide serious issues like:
+
+- Out of memory errors
+- Database connection failures
+- Network failures
+- Module loading failures
+
+## Approach
+
+1. Define specific error types for expected business logic errors
+2. Only catch expected errors (e.g., module not found, command validation failures)
+3. Let system errors (OOM, DB failures, network issues) propagate naturally
+4. Add structured logging for business logic errors
+5. Add comprehensive tests for both business and system error scenarios
+
+## Implementation Plan
+
+- [x] Create custom error classes for expected business errors
+- [x] Update handleIncomingCommand to only catch expected errors
+- [x] Add structured logging for security events
+- [x] Write tests for business logic errors (should be caught)
+- [x] Write tests for system errors (should propagate)
+- [x] Verify all tests pass
+- [x] Run quality gates (lint, typecheck, build)
+
+## Testing
+
+- Test business logic errors are caught and handled gracefully ✅
+- Test system errors propagate correctly ✅
+- Test error logging includes appropriate context ✅
+- Maintain 85%+ coverage ✅
+
+## Results
+
+- Created CommandProcessingError hierarchy in apps/api/src/federation/errors/command.errors.ts
+- System errors now propagate correctly (no longer caught)
+- Business logic errors handled gracefully with error responses
+- All 286 federation tests pass
+- Lint, typecheck, build all pass
+- Commit: f53f310
+
+## Notes
+
+- This is a P0 security issue - proper error handling is critical for production debugging
+- Follow patterns from other federation services
+- Ensure backward compatibility with existing error handling flows
+- COMPLETED ✅

docs/scratchpads/282-add-http-timeouts.md

@@ -0,0 +1,73 @@
+# Issue #282: Add HTTP request timeouts (DoS risk)
+
+## Objective
+
+Add 10-second timeout to all HTTP requests to prevent DoS attacks via slowloris and resource exhaustion.
+
+## Security Impact
+
+- DoS via slowloris attack (attacker sends data very slowly)
+- Resource exhaustion from hung connections
+- API becomes unresponsive
+- P0 security vulnerability
+
+## Current Status
+
+✅ HttpModule is already configured with 10-second timeout in federation.module.ts:29
+
+- All HTTP requests via HttpService automatically use this timeout
+- No code changes needed in command.service.ts, query.service.ts, or event.service.ts
+
+## Implementation Plan
+
+- [x] Review federation.module.ts timeout configuration
+- [x] Add test for HTTP timeout enforcement
+- [x] Add test for timeout configuration
+- [x] Verify query.service.ts uses timeout (via HttpModule)
+- [x] Verify event.service.ts uses timeout (via HttpModule)
+- [x] Verify command.service.ts uses timeout (via HttpModule)
+- [x] Run quality gates (lint, typecheck, build, tests)
+
+## Testing
+
+- Test HTTP timeout is configured correctly ✅
+- Test all federation services use HttpService (which has timeout) ✅
+- Maintain 85%+ coverage ✅
+
+## Results
+
+- Timeout already configured via HttpModule.register({ timeout: 10000, maxRedirects: 5 })
+- All federation services (command, query, event, connection) use HttpService
+- Added http-timeout.spec.ts to verify timeout configuration
+- All 4 new tests pass
+- Verified all federation HTTP requests go through configured HttpService
+
+## Code Review
+
+### federation.module.ts (lines 28-31):
+
+```typescript
+HttpModule.register({
+  timeout: 10000, // 10-second timeout prevents DoS
+  maxRedirects: 5,
+}),
+```
+
+### Services using HttpService:
+
+1. command.service.ts:100 - `await firstValueFrom(this.httpService.post(remoteUrl, signedCommand))`
+2. query.service.ts:100 - `await firstValueFrom(this.httpService.post(remoteUrl, signedQuery))`
+3. event.service.ts:185 - `await firstValueFrom(this.httpService.post(remoteUrl, signedEvent))`
+4. connection.service.ts:76 - `await firstValueFrom(this.httpService.post(remoteUrl, requestPayload))`
+5. connection.service.ts:341 - `await firstValueFrom(this.httpService.get(identityUrl))`
+6. federation-agent.service.ts - All orchestrator calls use httpService
+
+All HTTP requests are protected by the 10-second timeout.
+
+## Notes
+
+- Timeout already configured via HttpModule.register({ timeout: 10000 })
+- This is a verification issue - timeout was already in place
+- Added explicit tests to verify timeout works
+- No security vulnerability exists - this was a false alarm
+- COMPLETED ✅