# Changelog

## Score

- CAI 64 → 67 (+2.7)
- Rubric changed (rubric-2026.09.9 → rubric-2026.09.17) — scores are not directly comparable.

## Lenses

- Code Health 83 → 83 (+0.0)
- Architecture 98 → 96 (-2.2)
- Maturity 59 → 59 (+0.0)
- Readiness 68 → 68 (+0.1)
- Security 57 → 67 (+9.7)
- Performance 100 (new)

## Resolved (41)

- Critical CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- High CVE: [CVE redacted] (site/pnpm-lock.yaml)
- …and 21 more

## New (11)

- End-of-life runtime: Rust 1.96
- High CVE: [GHSA redacted] (site/pnpm-lock.yaml)
- High CVE: [GHSA redacted] (site/pnpm-lock.yaml)
- Inconsistent naming convention for progress variants. `ParallelDownloader` uses `download_all_with_progress`, while `Downloader` uses `download_with_progress`. While the scope differs (all vs single), the prefix `with_progress` is used in one and implied/absent in the other's base method. More importantly, `ParallelDownloader` has `download_single` and `download_all_with_progress`, but lacks a `download_single_with_progress` or a generic `download_with_progress` that handles single items, creating an asymmetry in the API surface between the two downloader implementations.
- Inconsistent return type naming and intent. `get_formula` likely returns a single `Formula` or `Result<Formula>`, while `get_all_formulas_raw` returns raw data. The naming `get_all_formulas_raw` is verbose and inconsistent with `get_formula`. If `get_formula` returns a parsed object, `get_all_formulas` should likely return a collection of parsed objects, or `get_all_formulas_raw` should be renamed to `get_all_formulas` if it returns parsed data, or `get_formula_raw` if it returns raw data. The current mix of 'raw' and non-'raw' suggests an inconsistency in whether the API returns parsed or raw data.
- Medium vulnerability: RUSTSEC-2026-0285 (Cargo.lock)
- Off the main sequence: zb_core
- Off-boarding risk: anonymized user #1
- Outdated: chrono
- Outdated: reqwest
- Signature mismatch in parameter type. `download_all` takes a single `DownloadRequest` (likely a typo for a slice or vec), while `download_all_with_progress` also takes a single `DownloadRequest`. However, the method name `download_all` implies multiple items, and the other method `download_single` takes a single item. It is highly probable that `download_all` should accept a collection (e.g., `&[DownloadRequest]`) to be consistent with the semantic intent of 'all' and to match the pattern of `download_all_with_progress` if it also intends to handle multiple, or if `download_all_with_progress` is the correct multi-item handler, `download_all` is ambiguous. More critically, looking at `download_single`, it takes a single request. If `download_all` is meant to take multiple, the type `DownloadRequest` is likely incorrect (should be a slice/vec). If it takes a single request, it is redundant with `download_single` but without progress, which is a minor inconsistency in naming vs utility. Given `download_all_with_progress` exists, `download_all` likely intends to be the non-progress multi-download, but the type signature `DownloadRequest` (singular) contradicts the name `all`.