The active Phase 16 implementation has strong fixture coverage and the full Swift suite passes, but three high-impact runtime/spec gaps remain before the cookie-auth milestone should be considered shippable.
Verification run: swift test from apps/pitwall-local passed 414 tests.
ChromeCookieDecryptor.decryptChromeCookieValue always throws notImplemented, while the app composes the live source with that decryptor. Fixture tests pass because they inject a stub decryptor, but real Chrome cookie extraction cannot satisfy the Phase 16 acceptance criteria.
Fix: implement macOS Keychain/Security + AES-CBC decryption behind the existing protocol and add coverage for the live decryptor seam.
The settings action calls discovery and updates CookieAuthSettingsViewModel, but it never persists the discovered secret through CookieAuthSource.saveClaudeCookieCredential or auto-populates the credential draft. Users can see a successful source badge without Pitwall storing usable credentials.
Fix: connect the consented settings action to the validated save path or a real credential-draft update, then test persisted .cookieSourced state.
The spec requires cookie expiry to feed AuthHealthWarning.expiringSoon(estimatedExpiry:). Current refresh logic only uses generic Claude session age and sets the estimated expiry to nil, ignoring cookie-sourced expiresAt metadata.
Fix: derive auth health from CredentialSourceMetadata.cookieSourced.expiresAt for cookie credentials and keep the existing session-age warning as fallback.
Manual credential entry remaining the default is intentional and documented in README.md, specs/codexbar-competitive-parity.md, and Phase 16. This was not treated as a usability defect.