# Changelog

> **This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.**

## Score

- CAI 61 → 69 (+7.4)
- Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

## Lenses

- Code Health 94 → 96 (+2.1)
- Architecture 89 → 96 (+7.1)
- Maturity 46 → 63 (+17.6)
- Readiness 54 → 57 (+3.3)
- Security 100 → 92 (-8.0)

## Resolved (8)

- Dependency hygiene PARTLY measured — SwiftPM pinning read, dependency currency NOT established
- FakeRequest.find (cognitive 42) (Sources/Networking/FakeRequest.swift)
- FakeRequest.find (cyclomatic 18) (Sources/Networking/FakeRequest.swift)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- High: security finding (details withheld)
- TooManyMethods: Networking (Sources/Networking/Networking.swift)

## New (8)

- Coverage not measured — Swift suite
- DecodingError.detailedMessage (cognitive 18) (Sources/Networking/NetworkingError.swift)
- Duplicate intent with different generic constraints. One overload takes a concrete array of URLQueryItems, the other takes a generic type Q. Without seeing the implementation of Q, it is unclear if this is a convenience for encoding structs vs manual query building, or if it's redundant. If Q is just a wrapper or protocol implemented by [URLQueryItem], it's confusing. If Q is a distinct encoding mechanism, the naming doesn't reflect that distinction clearly.
- Duplicated block (7 lines × 4) (Sources/Networking/NetworkingError.swift)
- High: security finding (details withheld)
- Inconsistent authorization configuration API. The first two methods imply specific auth schemes (Basic and Bearer/Token), while the third is a generic header setter. This forces users to know the internal implementation details of how 'token' auth is handled versus generic headers, and creates ambiguity about precedence or behavior.
- Inconsistent fake/mock API design. The fake methods have three distinct overloads for different response sources (Encodable object, raw headers/status, file path). This is inconsistent with the real API which uses a unified `post/get` with body/query parameters. The fake API forces users to choose a response format at the call site in a way that doesn't mirror the production API's structure, making mocking harder to reason about.
- Inconsistent return types for similar operations. `downloadImage` returns `Result<T, NetworkingError>` (where T is likely Image based on context, but the signature is generic T), while `downloadData` also returns `Result<T, NetworkingError>`. However, looking at `ImageResponse` and `DataResponse`, there are specific response types. The generic `T` in the download methods is ambiguous. Does `downloadImage` return `Result<Image, ...>`? If so, why is it generic? If `downloadData` returns `Result<Data, ...>`, why is it generic? This suggests a lack of specific typing for these domain-specific downloads.

## Changes since last survey

- 8 commits — 8 feature/other, 0 fixes

## By area

- (root) — 2 commits
- .github/workflows — 2 commits
- Sources/Networking — 2 commits
- Tests/NetworkingTests — 2 commits

## Notable commits

- change: Drop the config that 0.16.0 and swift-format already say (#332)
- change: Lint gets its own workflow, and the checkout is a commit (#337)
- change: Lint with oida, at zero baseline (#331)
- change: One line length across every repo (#334)
- change: The cancel path keeps its selection, not a void helper (#335)
- change: The doc link check reads markdown, so it reads it on Linux (#339)
- change: oida 0.16.1, and the isolation hop stops needing a disable (#336)
- change: oida 0.17.1 (#338)